クラウドネイティブAPI Gatewayは、単一サービスルーティング、パーセンテージベースのルーティング、タグベースのルーティング、モックルーティング、リダイレクトなど、複数のルーティングモードをサポートしています。
単一サービスルーティング
クラウドネイティブゲートウェイは、ルーティングルールに基づいてバックエンドサービスにリクエストを転送します。 Cloud-native API Gatewayのサービス設定の詳細については、「サービスの管理」をご参照ください。
ゲートウェイは、設定したルーティングルールに基づいてリクエストを照合します。 設定例：
ゲートウェイは、/userルーティングルールに一致するすべての要求をユーザーサービスに転送します。
ゲートウェイは、/orderルーティングルールに一致するすべての要求を注文サービスに転送します。
パーセンテージベースのルーティング
クラウドネイティブゲートウェイは、リクエストを複数のバックエンドサービスに転送します。 トラフィックは、各サービスに設定した重みに基づいてバックエンドサービスに配信されます。 次のシナリオでは、マルチサービスルーティングを使用できます。
レジストリの変更
ビジネスが成長するにつれて、新しいテクノロジーが継続的に統合され、レジストリの変更を実行する必要があります。 レジストリの変更を実行するときにビジネスの継続性を確保するために、サービスのレプリカがデプロイされます。 レプリカは新しいレジストリを使用します。 元のサービスと元のレジストリは保持されます。 トラフィックは、元のサービスから新しいサービスに徐々に転送されます。 新しいサービスの安定性を確認した後、ゲートウェイはすべての着信トラフィックを新しいサービスに転送できます。 サービス移行プロセスはロールバックをサポートしています。 新しいサービスが要件を満たしていない場合は、トラフィックを元のサービスにロールバックできます。
サービスレジストリの変更例を次の図に示します。 この例では、アプリケーションシステムのユーザーサービスがNacosから組み込みのCoreDNS for Kubernetesに切り替わります。 サービスリソースと一緒に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プラットフォームに移行されます。
タグベースのルーティング
クラウドネイティブゲートウェイは、同じまたは異なるサービスの異なるバージョンに要求を転送する。 トラフィックは、サービスバージョンごとに設定した重みに基づいて分散されます。 Cloud-native API Gatewayのサービスバージョン設定の詳細については、「サービスバージョンの管理」をご参照ください。 次のシナリオでは、タグベースのルーティングを使用できます。
カナリアリリース
サービスの新しいバージョンは、開発ライフサイクル全体で頻繁にリリースされます。 カナリアリリースポリシーを使用して、サービスの安定性と継続性を確保しながら、サービスのアップグレードを展開できます。 カナリアリリースでは、少量のトラフィックが最初に検証のために新しいバージョンのサービスに転送されます。 結果が予想を満たす場合、残りのトラフィックは徐々に新しいバージョンのサービスに移行されます。
例えば、サービス発見は、以下のアプリケーションシステムにおいてACKクラスタにデプロイされたユーザサービスに対して実行される。 サービスは現在v1バージョンを実行しており、新しいバージョンv2がリリースされて起動される予定です。 次のいずれかの項目に基づいてカナリアリリースを実行できます。
パーセンテージ
タグベースのルーティングは、/ユーザの要求をユーザサービスv1に転送するために使用される。 Microservices Engine (MSE) コンソールのサービス管理ページでユーザーサービスv2を追加し、タグベースのルーティングの宛先サービスにユーザーサービスv2を追加できます。 重みを設定して、ユーザーサービスv2に転送されるトラフィックの割合を決定できます。
[タグ]
タグベースルーティングは、/ユーザの要求をユーザサービスv1に転送するために使用される。 /userルートを追加し、このルートがカナリアリリースに使用されることを示すタグを設定できます。 例えば、タグは、グレー値を有するステージヘッダであり得る。 ルートは、そのようなヘッダを有する要求をユーザサービスv2に転送するために使用される。
ラベルベースのルーティング
本番環境では、サービスの複数のバージョンが長期間並行して存在する可能性があり、サービスの機能と適用可能な要求はバージョンによって異なります。 たとえば、同じAPI操作が呼び出されると、異なるヘッダー値を持つリクエストが異なるバージョンのサービスに転送されます。 タグベースのルーティングは、複数の開発環境 (テスト、ステージング、および本番環境) が共存するシナリオでも使用されます。 タグは、異なる環境のサービス向けの要求を区別するために使用されます。
たとえば、次のアプリケーションシステムでは、ACKクラスターにデプロイされた3つのバージョンのユーザーサービスでサービス検出が実行されます。 サービスバージョンは、それぞれテスト、ステージング、および実稼働環境に対応しています。 /userリクエストの場合:
stageヘッダーの値がtestの場合、トラフィックはテスト環境のユーザーサービスに転送されます。
ステージヘッダーの値がpreの場合、トラフィックはステージング環境のユーザーサービスに転送されます。
ステージヘッダーの値がオンラインの場合、トラフィックは本番環境のユーザーサービスに転送されます。
高可用性デプロイメント
サービスの可用性を確保するために、同一のサービスを複数のKubernetesクラスターにデプロイできます。 ノードのクラスターメタデータに基づいて、クラスターごとにすべてのサービスインスタンスを管理できます。 重みを調整して、トラフィックをクラスターに分散することもできます。 クラスターに障害が発生した場合、そのクラスターのトラフィック分散重みを0に設定し、すべてのトラフィックが他のクラスターに転送されます。
例えば、以下のアプリケーションシステムにおいて、サービス発見は、ACKクラスタA及びB上に配備されたユーザサービスに対して実行される。/userのリクエストの場合、80% トラフィックはクラスターAにデプロイされたユーザーサービスに転送され、20% トラフィックはクラスターBにデプロイされたユーザーサービスに転送されます。
模擬ルーティング
通常、デバッグには模擬ルーティングが使用されます。 ルートの固定レスポンスを設定して、リクエストが適切に転送されているかどうかを確認できます。 これにより、フロントエンドとバックエンドの開発を並行して進めることができ、開発の反復が高速化されます。
たとえば、次のアプリケーションシステムでは、バックエンドのユーザーサービスが完了していない場合、ユーザーサービスのAPI操作に対して固定応答が設定されます。 フロントエンド開発者は、ルーティングプロセスをテストおよびデバッグできます。 バックエンドユーザーサービスが完了したら、Typeパラメーターの値をMockからユーザーサービスに変更し、フロントエンドとバックエンドの担当者が共同デバッグを実行できます。
リダイレクション
クラウドネイティブゲートウェイは、リクエストを別のドメイン名またはパスにリダイレクトできます。 リダイレクトは、ドメイン名の転送やAPIの変更のシナリオでよく使用されます。
たとえば、現在のサービスドメイン名iがs old.example.com、現在のパスは /testです。 クラウドネイティブゲートウェイは、o new.example.com/dev. からのリクエストをリダイレクトm old.example.com/test