交通量の多いシナリオで気楽にオンラインで公開するにはどうすればよいですか？

序文

この記事では、「高トラフィックシナリオでのシルキースムースリリースの背後にある理由の暴露」の他の部分である、カナリアリリースとも呼ばれるグレースケールリリースについて引き続き説明します。多くのインターネット企業が深夜のリリースを持っていないもう1つの重要な理由は、灰色になる機能、バグまたはその他の理由が新規顧客のオンラインバージョンに影響を与えることです。

デフォルトでは、KubernetesかECSかに関係なく、古いバージョンと新しいバージョンが存在する場合、特定の負荷分散アルゴリズムに従って、それらは異なるインスタンスにランダムにルーティングされます。ランダムとは、問題もランダムに発生することを意味します。グレースケールリリースソリューションを完成させるには、一連の動的ルーティングが必要です。

RPCの分野では、グレーリリースを動的ルーティングと呼びます。動的ルーティングとは、トラフィックを指定されたインスタンスに動的にルーティングできることを意味します。

動的ルーティングシナリオ

動的ルーティングは、マイクロサービスの非常にコアな機能です。トラフィックの動的ルーティングは、多くのことを実行できることを意味します。これから、さまざまなシナリオが導き出されます。

カナリアリリース：特定のルール（クエリパラメータ、HEADER、COOKIEなどの特定のキーが特定の条件を満たす）または固定トラフィック比率を満たすトラフィックのみが新しいバージョンに入り、他のトラフィックは古いバージョンにルーティングされます。

同じコンピュータールームでの優先ルーティング：会社が拡大すると、アプリケーションはコンピュータールーム全体に展開され、高い可用性を実現します。異なる場所のコンピュータルーム間で電話をかけるときに発生するネットワーク遅延の問題のため、サービス利用者が同じコンピュータルームのサービス消費者に優先的に電話をかけることができるようにする必要があります。これには、同じコンピュータルームで優先的にルーティングする機能が必要です。

タグルーティング：カナリアによってリリースされた新しいシーン。カナリアリリースには通常、新旧の2つのバージョンしかありません。タグルーティングでは、複数のバージョンをオンラインで展開でき、各バージョンにタグがあります。
フルリンクグレースケール：ビジネスがより複雑で、サービスコールリンクが長いシナリオでは、アプリケーションごとにルーティングルールを設定するのは非常に面倒です。フルリンクグレースケールは、カナリア/ラベルルーティングに基づいて追加されます。「ラベル透過送信」機能を使用すると、グレースケールトラフィックはグレースケールバージョン間でのみルーティングされます。

次に、これらのシナリオについていくつかの記事で詳しく説明します。今日は、カナリアのリリースについて最初に説明します。カナリアのリリースにより、深夜に公開することを心配することなく、日中のトラフィックのピーク時にオンラインで公開したり、お茶を飲んだり、メロンの種を食べたりすることができます。

トラフィックの多い状況でのアプリケーションの展開ステータス

アプリケーションデモ

デモでは例としてSpringCloudを使用しています。サービスコールのリンクを次の図に示します。

Netflix Zuulに対応する入力からトラフィックが着信すると、SC-Aアプリケーションに対応するサービスを呼び出し、SC-AアプリケーションはSC-Bアプリケーションのサービスを呼び出し、SC-BアプリケーションはSC-Cアプリケーションのサービスを呼び出します。SC-Aには、オンラインバージョンとグレーバージョンの2つのバージョンがあります。

ヘルム展開デモ

デモは、純粋なオープンソースのSpringCloudアーキテクチャです。

展開後、Alibaba Cloud ContainerServiceのワークロードは次のようになります。

「whiletrue; do curl http：// {ip：port} / A / a; echo; done」シェルコマンドを使用して、Spring Cloudサービスに継続的にアクセスします。各サービスの機能は、現在のサービスのIPを出力することだけなので、全体的な通話リンクを確認できます。

while true; do curl http://{ip:port}/A/a;echo;done
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
...

このプロセスから、Netflix Zuul-> SC-Aリンクがランダムにアクセスされていることがはっきりとわかります。SC-Aのオンラインバージョンとグレースケールバージョンにはそれぞれ1つのポッドしかないため、これら2つのPODはランダムに印刷されます。 IP。

オープンソースカナリアの実装

動的ルーティングの本質は、アドレス指定プロセス中に修飾されたインスタンスアドレスを見つけることです。

Apache Dubboは、RouterChainがInvokerリストをフィルタリングする機能を提供します。RouterChainはRouterリストを内部的に維持します。各Routerは、Invokerをフィルタリングするロジックを実行し、最後にLoadBalanceにInvokerリストを配信して、最終的なInvokerを取得します。

組み込みのルーターScriptRouter、ConditionRouter、およびTagRouterはすべて、Dubboの組み込みの動的ルーティング機能です。

Spring Cloudのルーティング機能は、Ribbonによって実装されます。リボンは、サーバーリストを取得するようにILoadBalancerインターフェイスを設計し、最後のサーバーを取得するための負荷分散戦略のために、最終的にこのリストをIRuleに配信しました。この作品は、ダボに比べてデザインに欠陥があります。

Spring Cloud RibbonのILoadBalancerは、Dubbo RouterChainのRouterと同等であり、IRuleはDubboLoadBalanceと同等です。

Spring Cloudの最新バージョンでは、負荷分散のためにリボンの代わりにSpring CloudLoadBalancerコンポーネントが追加されています。SpringCloudLoadBalancerのServiceInstanceListSupplierはインスタンスリスト情報を取得するために使用され、ReactiveLoadBalancerは負荷分散戦略を使用して最後のインスタンスを取得します。

これは、3の対応するコンポーネントの説明です。

Apache Dubboにはさまざまなルーターが組み込まれていますが、実際の使用には多くの問題があります。たとえば、TagRouterはIPにバインドされており、Kubernetesでは機能しません。ScriptRouterはScriptEngineを使用してスクリプト処理を実行するため、パフォーマンスの問題が発生します。DubboAdminのエクスペリエンスは非常に悪いです。

Spring Cloudは、動的ルーティング機能を公式に提供していません。コミュニティ内の一部の開発者のみがこの機能を独自に拡張しており、コミュニティにはUIインタラクションインターフェイスがありません。

現時点で、MSEは、MSEのマイクロサービスソリューションが動的ルーティング機能を提供していることを示しています。OPENAPIまたはUIインタラクションを使用して、コードや構成を変更せずにカナリアリリースを完了することができます。アプリケーションをMSEサービスガバナンスに接続するだけで、カナリア機能を楽しむことができます。

アプリケーションが過去5年以内のSpringCloudまたはDubboのバージョン開発に基づいている限り、コードや構成を変更することなく、完全なMSEマイクロサービスガバナンス機能を直接使用できます。

コードを変更せずに動的ルーティングを実現できるのは良いことではないでしょうか。

MSEカナリア機能

アプリケーションはMSEにアクセスして、コードを変更せずにMSEが提供する動的ルーティング機能を利用できます。

ラベルコンセプトのご紹介

MSEでは、ラベルの概念が導入されています。ルーティングルールはラベルごとに設定できます。ルーティングルールを満たすトラフィックは、このラベルに対応するインスタンスにルーティングされます。Spring Cloud Demoを少し変更し、SC-Aの灰色バージョンに「青」のラベルを付けました（Helmはすでにこのステップを完了しています）。

MSEにアクセスした後、MSEはデフォルトで100％ルーティングルールをマークされていないインスタンスに割り当てます。この時点で、引き続き「while true; do curl http：// {ip：port} / A / a; echo; done」シェルコマンドを実行します。この時点で、SC-Aを呼び出すと、すべてオンラインバージョンのIPが返されます。

while true; do curl http://{ip:port}/A/a;echo;done
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
A[10.0.0.73] -> B[10.0.0.180] -> C[10.0.0.72]
...

カナリアルーティングルールを設定する

カナリアルーティング条件をテストするために、MSEのアプリケーション詳細ページのカナリアタブページのヘッダーでenvのKEY値を設定します。

シェル実行を引き続き使用するには、HEADERを渡します。

while true; do curl -H "env:test" http://139.196.200.40/A/a;echo;done
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
A1[10.0.0.20] -> B[10.0.0.180] -> C[10.0.0.72]
...

現時点では、カナリアルールを満たすすべてのトラフィックがSC-Aのグレースケールバージョンに送信されていることがわかりました。

カナリアルーティングルール分析

ご覧のとおり、カナリアルーティングルールインターフェイスには、トラフィック比率とトラフィックルールという2つの違いがあります。

トラフィックルール：ルールを満たすトラフィックが、対応するラベル（この記事では青が灰色のラベルとして使用されます）インスタンスにルーティングされることを示します。たとえば、この記事の例では、HEADERのenv = testのトラフィックは、確実に青いラベルに対応するインスタンスに移動します。

トラフィックの割合：トラフィックルールを満たさないトラフィックは、トラフィックの割合に従ってルーティングされます。たとえば、この記事の例では、HEADERのenv = testを満たさないトラフィックは、100％ルールでマークされていないインスタンスにルーティングされます。100％であるため、ルールを満たさないすべてのトラフィックはマークされていないインスタンスに送られます（この記事はオンライン版をマークしていません）。

MSEによって提供されるトラフィックルールの条件は、HEADER、Query Parameter、COOKIE、およびRequestBODYをサポートします。

Query Parameter、HEADER、COOKIE、およびRequest Bodyは、通常の演算子をサポートするだけでなく、（ホワイトリスト）、100を法とする値、およびパーセンテージもサポートします。ここでのパーセンテージは、比例ルールの合計トラフィックパーセンテージではなく、対応するパラメータのハッシュ値の係数を参照しているため、固定値は常にルーティング条件を満たすことができます（トラフィック比率に従って、ユーザーAが今回オンラインにアクセスしている場合）バージョン、灰色のバージョンは次回アクセスされる可能性があります）。たとえば、HEADERにユーザーIDがある場合、一部のユーザーが常にグレースケールインスタンスにアクセスできるようにしたいのですが、この時点で、ユーザーIDのハッシュ値を調整して完了することができます（もちろん、これはホワイトリストからも実行できます）。リストの欠点はランダムではありません。各リストを入力する必要があります）。

リクエストボディは現在、次の文字列などのjson文字列の解析をサポートしています。

{  
  "a": "aa",
  "b": [
    1,2,3
  ],
  "c": [
    {
      "d": "dd"
    }
  ],
  "e": {
    "f": "ff"
  }
}

JSONアクセス式.aの値はaaです。
JSONアクセス式.b [0]の値は1です。
JSONアクセス式.c [0] .dの値はddです。
JSONアクセス式.efの値はffです。

総括する

この記事では、マイクロサービスガバナンスの下でのカナリアリリースの機能を紹介し、リリース中に少量のトラフィックで新機能を検証する問題を解決します。アプリケーションはMSEサービス管理にアクセスするだけでよく、操作なしで動的ルーティング機能を楽しむことができます。Canary Releaseは、MSE（Micro Service Engine）に加えて、EDASやSAEなどのクラウド製品とも統合されています。

元のリンク

この記事はAlibabaCloudのオリジナルのコンテンツであり、許可なく複製することはできません。