Microservices Engine:ルーティング

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

クラウドネイティブゲートウェイは、ルーティングルールに基づいて、リクエストを特定のバックエンドサービスに転送します。サービスの設定の詳細については、「サービスの追加」をご参照ください。

ゲートウェイは、設定済みのルーティングルールとリクエストを照合します。例：

• ゲートウェイは、/user ルーティングルールに一致するすべてのリクエストを user サービスに転送します。

• ゲートウェイは、/order ルーティングルールに一致するすべてのリクエストを order サービスに転送します。

加重ルーティング

クラウドネイティブゲートウェイは、各サービスに設定された重みに基づいて、リクエストを複数のバックエンドサービスに分散します。一般的なシナリオは次のとおりです。

• [複数のサービスレジストリ]

  サービスレジストリを変更する際、新しいレジストリを使用するサービスのレプリカをデプロイしながら、元のサービスとレジストリを保持できます。トラフィックは元のサービスから新しいサービスへ徐々に切り替えられます。新しいサービスの安定性を確認した後、すべてのトラフィックを新しいサービスに転送できます。新しいサービスが要件を満たさない場合、移行をロールバックできます。

  次の図は、user サービスが Nacos から Kubernetes の組み込み CoreDNS に切り替える例を示しています。CoreDNS はサービスリソースと組み合わせて使用する必要があります。

  

• [実行環境の差異]

  従来、ほとんどのサービスは Alibaba Cloud Elastic Compute Service (ECS) インスタンスなどの仮想マシン上で実行されています。より多くの企業が Alibaba Cloud Container Service for Kubernetes (ACK) などの Kubernetes ベースのプラットフォームに移行するにつれて、Kubernetes クラスターにサービスのレプリカをデプロイし、レジストリに新しい名前で登録できます。これにより、同一機能を持つ 2 つのサービス (1 つは ECS インスタンス上、もう 1 つは Kubernetes クラスター上) が存在することになります。トラフィックは ECS から Kubernetes へ徐々に切り替えられ、いつでも比率を調整したり、ロールバックしたりできます。

  例えば、Nacos をレジストリとして使用する user サービスを ECS から ACK プラットフォームに移行するとします。

  

タグベースルーティング

クラウドネイティブゲートウェイは、リクエストのタグ (ヘッダーやクエリパラメータなど) に基づいて、リクエストをサービスの異なるバージョンに転送します。サービスバージョンの設定の詳細については、「サービスバージョンの管理」をご参照ください。一般的なシナリオは次のとおりです。

• [カナリアリリース]

  カナリアリリースは、新しいサービスバージョンに少量のトラフィックを転送して検証します。結果が期待どおりであれば、残りのトラフィックを新しいバージョンに徐々に移行します。

  例えば、ACK クラスターにデプロイされた user サービスが現在 v1 で実行されており、v2 のリリースが予定されているとします。カナリアリリースは次のいずれかの方法で実行できます。

  • [比率による方法]

    タグベースルーティングを使用して、/user リクエストを user サービス v1 に転送します。Microservices Engine (MSE) コンソールのサービス管理ページで user サービス v2 を追加し、タグベースルーティングの宛先サービスとして user サービス v2 を追加できます。重みを設定して、user サービス v2 に転送されるトラフィックの割合を決定できます。

    

  • [タグによる方法]

    タグベースルーティングを使用して、/user リクエストを user サービス v1 に転送します。/user ルートを追加し、このルートがカナリアリリースに使用されることを示すタグを設定できます。例えば、タグは、値が gray の stage ヘッダーとすることができます。このルートは、そのようなヘッダーを持つリクエストを user サービス v2 に転送するために使用されます。

    

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

  本番環境では、サービスの複数のバージョンが長期間共存する場合があり、各バージョンは異なるタイプのリクエストを処理します。例えば、異なるヘッダー値を持つリクエストを異なるサービスバージョンに転送できます。タグベースルーティングは、複数の環境 (テスト、ステージング、本番) が共存する場合にも適用され、タグを使用して各環境のリクエストを区別します。

  例えば、次のアプリケーションでは、user サービスはサービスディスカバリに K8s コンテナサービスを使用し、3 つの開発環境 (test、pre、online) があります。/user へのリクエストの設定は次のとおりです。

  • stage ヘッダーの値が test の場合、トラフィックはテスト環境の user サービスに転送されます。

  • stage ヘッダーの値が pre の場合、トラフィックはステージング環境の user サービスに転送されます。

  • stage ヘッダーの値が online の場合、トラフィックは本番環境の user サービスに転送されます。

  

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

  サービスの可用性を確保するために、同一のサービスを複数の Kubernetes クラスターにデプロイできます。ノードメタデータに基づいてクラスター単位でサービスインスタンスを管理し、重みを調整してクラスター間でトラフィックを分散できます。クラスターに障害が発生した場合、その重みを 0 に設定して、すべてのトラフィックを残りのクラスターに転送できます。

  例えば、次のアプリケーションシステムでは、ACK クラスター A と B にデプロイされた user サービスでサービスディスカバリが実行されます。/user リクエストでは、トラフィックの 80% がクラスター A にデプロイされた user サービスに転送され、20% がクラスター B にデプロイされた user サービスに転送されます。

  

モックルーティング

モックルーティングは、リクエストを実際のバックエンドサービスに転送する代わりに、ルートに対して定義済みの固定レスポンスを返します。これにより、フロントエンドとバックエンドの開発を並行して進めることができます。

例えば、バックエンドの user サービスがまだ完成していない場合、その API に対して固定レスポンスを設定することで、フロントエンド開発者はバックエンドサービスに依存せずに開発とテストを進めることができます。バックエンドサービスの準備が整ったら、ルートタイプをモックから実際のサービスに変更して、結合デバッグを実施します。

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

クラウドネイティブゲートウェイは、リクエストを別のドメイン名またはパスにリダイレクトできます。これは、ドメイン名の移行や API の変更によく使用されます。

例えば、現在のサービスドメイン名が old.example.com で、現在のパスが /test の場合、クラウドネイティブゲートウェイは old.example.com/test へのリクエストを new.example.com/dev にリダイレクトします。