API Gateway:ルーティング

単一サービスルーティング

単一サービスルーティングモードでは、ゲートウェイは受信リクエストを設定済みのルーティングルールと照合し、単一のバックエンドサービスに転送します。例：

• /user ルールに一致するリクエストは、ユーザーサービスに転送されます。

• /order ルールに一致するリクエストは、注文サービスに転送されます。

サービスの構成については、「サービスの管理」をご参照ください。

パーセンテージベースのルーティング

パーセンテージベースのルーティングモードでは、ゲートウェイは設定された重みに基づいて、複数のバックエンドサービスにトラフィックを分割します。このモードは、トラフィックを中断することなく、レジストリ間または運用保守 (O&M) システム間でサービスを移行する場合に使用します。

• 異なるレジストリ

  サービスレジストリをアップグレードする際、新しいレジストリを使用してサービスのレプリカを既存のサービスと並行してデプロイします。重みを調整することで、古いサービスから新しいサービスへと段階的にトラフィックをシフトさせます。新しいサービスが安定したら、すべてのトラフィックを新しいサービスに転送します。新しいサービスで問題が発生した場合は、いつでも古いサービスにトラフィックをロールバックできます。

  例えば、あるユーザーサービスが元々 Nacos をレジストリとして使用しているとします。Service リソースを必要とする Kubernetes (K8s) の組み込み CoreDNS ソリューションに切り替えるには、パーセンテージベースのルーティングを使用してトラフィックを段階的に移行します。

• 異なる O&M システム

  仮想マシンから Kubernetes にサービスを移行する場合、K8s クラスターにレプリカをデプロイし、新しいサービス名で登録します。これにより、サービスレジストリには同じ機能を持つ 2 つのサービスが含まれることになります。1 つは Elastic Compute Service (ECS) インスタンス上に、もう 1 つは Alibaba Cloud Container Service for Kubernetes (ACK) クラスター上にあります。段階的にトラフィックを K8s サービスにシフトさせ、移行中はいつでも重みを調整したり、ロールバックしたりできます。

  例えば、Nacos をレジストリとして使用しているユーザーサービスを ECS インスタンスから ACK に移行する場合です。

タグベースルーティング

タグベースルーティングモードでは、ゲートウェイは設定された重みやリクエスト属性に基づいて、同じまたは異なるサービスの異なるバージョンにリクエストを転送します。このモードは、カナリアリリース、マルチ環境ルーティング、高可用性デプロイメントに使用します。サービスバージョンの設定については、「サービスバージョンの管理」をご参照ください。

• カナリアリリース

  カナリアリリースでは、トラフィックのわずかな割合を新しいバージョンに送り、検証を行います。新しいバージョンが期待どおりに動作すれば、古いバージョンがトラフィックを受け取らなくなるまで、徐々にトラフィックをシフトさせます。タグベースルーティングは、カナリアリリースに対して 2 つのアプローチをサポートしています：

  例えば、あるユーザーサービスがサービス検出に K8s コンテナサービスを使用しているとします。現在のバージョンは v1 で、新しいバージョン v2 のリリース準備ができています。

  • パーセンテージによる

    /user ルートはタグベースルーティングを使用して、リクエストをユーザーサービス v1 に転送します。サービス管理で v2 をサービスバージョンとして追加し、次にルーティングルールでユーザーサービス v2 を送信先として追加し、重みを設定して受信するトラフィックのパーセンテージを制御します。

  • タグによる

    既存の /user ルートはリクエストをユーザーサービス v1 に転送します。カナリアリリースタグを持つ 2 番目の /user ルートを作成します。例えば、 stage という名前のヘッダーに gray という値を持たせます。このヘッダーを含むリクエストは、ユーザーサービス v2 に転送されます。

• タグベースルーティング

  サービスには、長時間実行される複数のバージョンが存在することがあり、それぞれが特定の属性に一致するリクエストを処理します。例えば、特定のヘッダー値を持つリクエストを、特定のサービスバージョンにルーティングできます。これは、単一のゲートウェイ内でテスト、プレリリース、本番などの複数の環境を管理するのに役立ちます。

  例えば、あるユーザーサービスがサービス検出に K8s コンテナサービスを使用しており、テスト、プレリリース、本番の 3 つの環境があるとします。/user ルートへのリクエストは次のようにルーティングされます：

  • stage ヘッダーの値が test の場合、トラフィックはユーザーサービスのテストバージョンに転送されます。

  • stage ヘッダーの値が pre の場合、トラフィックはユーザーサービスのプレリリースバージョンに転送されます。

  • stage ヘッダーの値が online の場合、トラフィックはユーザーサービスの本番バージョンに転送されます。

• 高可用性デプロイメント

  サービス可用性を向上させるために、複数の K8s クラスターにサービスをデプロイし、クラスター関連のノードメタデータを使用してクラスターごとにインスタンスを管理します。各クラスターは、設定可能なトラフィックの重みを持つサービスバージョンにマッピングされます。クラスターに障害が発生した場合は、その重みを 0 に設定して、すべてのトラフィックを残りのクラスターにリダイレクトします。

  例えば、あるユーザーサービスがサービス検出に K8s コンテナサービスを使用し、クラスター A とクラスター B の 2 つの ACK クラスターにデプロイされているとします。/user ルートへのリクエストに対して、トラフィックの 80% がクラスター A に、20% がクラスター B に転送されます。

モックルーティング

モックルーティングは、リクエストをバックエンドサービスに転送せずに、ルートに対して固定レスポンスを返します。バックエンドの準備が整う前にフロントエンド開発のブロックを解除したり、リクエストマッチングルールが正しく機能していることを確認したりするために使用します。

例えば、バックエンドが開発される前にユーザーサービス API に固定レスポンスを設定することで、フロントエンド開発者は独立してテストやデバッグを行うことができます。バックエンドの準備が整ったら、ルートをモックから実際のサービスを指すように切り替えて、エンドツーエンドテストを行います。

リダイレクトルーティング

リダイレクトルーティングは、クライアントを異なるドメイン名またはパスに送信します。ドメイン名の移行や API パスの変更に使用します。

例えば、old.example.com/test へのリクエストがゲートウェイに到着すると、ゲートウェイはそれを new.example.com/dev にリダイレクトします。