すべてのプロダクト
Search
ドキュメントセンター

Microservices Engine:ルーティングモード

最終更新日:Feb 13, 2025

Microservices Engine(MSE)のクラウドネイティブゲートウェイは、単一サービスルーティング、パーセンテージベースルーティング、タグベースルーティング、モックルーティング、リダイレクトなど、複数のルーティングモードをサポートしています。

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

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

ゲートウェイは、設定したルーティングルールに基づいてリクエストを照合します。次に例を示します。

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

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

单服务路由

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

クラウドネイティブゲートウェイは、複数のバックエンドサービスにリクエストを転送します。トラフィックは、各サービスに設定した重みに基づいて、バックエンドサービスに分散されます。複数サービスルーティングは、次のシナリオで使用できます。

  • レジストリの変更

    ビジネスの成長に伴い、新しいテクノロジーが継続的に統合され、レジストリの変更が必要になる場合があります。レジストリの変更を実行する際にビジネスの継続性を確保するために、サービスのレプリカがデプロイされます。レプリカは新しいレジストリを使用します。元のサービスと元のレジストリは保持されます。トラフィックは元のサービスから新しいサービスに徐々に転送されます。新しいサービスの安定性を確認した後、ゲートウェイはすべての着信トラフィックを新しいサービスに転送できます。サービス移行プロセスはロールバックをサポートしています。新しいサービスが要件を満たしていない場合は、トラフィックを元のサービスにロールバックできます。

    次の図は、サービスレジストリを変更する例を示しています。この例では、アプリケーションシステムのユーザーサービスが Nacos から Kubernetes の組み込み CoreDNS に切り替わります。サービスリソースと共に CoreDNS を使用する必要があります。

    不同的注册中心

  • O&Mシステムの変更

    従来、ほとんどのサービスは、Alibaba Cloud Elastic Compute Service(ECS)インスタンスなどの仮想マシンにデプロイされていました。近年、Kubernetes は、簡素化された O&M と高い弾力性を備えた代替デプロイメントソリューションとして登場しました。ますます多くの企業が、Alibaba Cloud Container Service for Kubernetes(ACK)などの Kubernetes ベースの管理プラットフォームにサービスを移行しています。シームレスなサービス移行を確保するために、サービスのレプリカを Kubernetes クラスタにデプロイし、レジストリに新しい名前で登録できます。この場合、レジストリには同じ機能を持つ 2 つのサービスが存在します。1 つは ECS インスタンスにデプロイされて実行されており、もう 1 つは Kubernetes クラスタにあります。トラフィックは ECS インスタンス上のサービスから Kubernetes クラスタ上のサービスに転送されます。移行中に、転送されるトラフィックの割合を調整したり、すべてのトラフィックを ECS インスタンス上のサービスにロールバックしたりすることもできます。

    次の図は、O&M システムを変更する例を示しています。レジストリとして Nacos を使用するアプリケーションシステムでは、ユーザーサービスは ECS インスタンスから ACK プラットフォームに移行されます。

    不同的运维体系

タグベースルーティング

クラウドネイティブゲートウェイは、同じサービスまたは異なるサービスの異なるバージョンにリクエストを転送します。トラフィックは、各サービスバージョンに設定した重みに基づいて分散されます。クラウドネイティブゲートウェイのサービスバージョンを設定する方法の詳細については、サービスバージョンの管理をご参照ください。タグベースルーティングは、次のシナリオで使用できます。

  • カナリアリリース

    サービスの新しいバージョンは、開発ライフサイクル全体で頻繁にリリースされます。カナリアリリースポリシーを使用すると、サービスの安定性と継続性を確保しながら、サービスのアップグレードをロールアウトできます。カナリアリリースでは、まず少量のトラフィックが新しいバージョンのサービスに転送され、検証されます。結果が期待どおりであれば、残りのトラフィックが新しいバージョンのサービスに徐々に移行されます。

    たとえば、次のアプリケーションシステムでは、ACK クラスタにデプロイされたユーザーサービスでサービスディスカバリが実行されます。サービスは現在 v1 バージョンを実行しており、新しいバージョン v2 のリリースと起動が計画されています。次のいずれかの項目に基づいてカナリアリリースを実行できます。

    • パーセンテージ

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

      按比例标签路由

    • タグ

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

      按内容标签路由

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

    本番環境では、サービスの複数のバージョンが長期間にわたって並行して存在する場合があり、サービスの機能と適用されるリクエストはバージョンによって異なります。たとえば、同じ API 操作が呼び出された場合、異なるヘッダー値を持つリクエストは異なるバージョンのサービスに転送されます。タグベースルーティングは、複数の開発環境(テスト、ステージング、本番)が共存するシナリオでも使用されます。タグは、異なる環境のサービスを対象としたリクエストを区別するために使用されます。

    たとえば、次のアプリケーションシステムでは、ACK クラスタにデプロイされた 3 つのバージョンのユーザーサービスでサービスディスカバリが実行されます。サービスバージョンは、それぞれテスト、ステージング、本番環境に対応しています。/user リクエストの場合:

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

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

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

    标签路由

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

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

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

    高可用部署路由

モックルーティング

モックルーティングは通常、デバッグに使用されます。ルートに対して固定レスポンスを設定して、リクエストが正しく転送されているかどうかを確認できます。これにより、フロントエンドとバックエンドの開発を並行して進めることができ、開発の反復を加速できます。

たとえば、次のアプリケーションシステムでは、バックエンドユーザーサービスが完了していない場合、ユーザーサービスの API 操作に対して固定レスポンスが設定されます。これにより、フロントエンド開発者はルーティングプロセスをテストおよびデバッグできます。バックエンドユーザーサービスが完了したら、Type パラメータの値を Mock からユーザーサービスに変更し、フロントエンドとバックエンドの担当者が共同デバッグを実行できます。

Mock路由

リダイレクト

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

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

重定向路由