要約： 最初のグローバルコミュニティサミットIstioCon 2021で、Huawei Cloud Application ServiceGridのチーフアーキテクトであるZhangChaomengが、「ベストプラクティス：Spring CloudからIstioまで」に関する基調講演を行い、本番環境で使用されるIstioの実際の事例を共有しました。
リンクをクリックしてトークをご覧ください：https：//events.istio.io/istiocon-2021/sessions/best-practice%EF%BC%9Afrom-spring-cloud-to-istio/
以下はスピーチの全文です
みなさん、こんにちは。私はHuaweiCloudのエンジニアです。生産に使用されたIstioの実際の事例を皆さんと共有する機会を持てたことを光栄に思います。
HUAWEIクラウドアプリケーションサービスグリッドは、2018年にパブリッククラウドで開始されました。世界で最も初期のグリッドサービスの1つとして、グリッドの初期の理解と試行から現在の大規模な使用までのプロセスを経験し、目撃してきました。ますます多くの顧客にサービスを提供し、シナリオはますます複雑になっています。一般的な機能のほとんどは、機能としてIstioコミュニティに提供されており、ソリューションレベルのプラクティスでも、この機会を通じてあなたとコミュニケーションをとることを望んでいます。
今回選んだトピックは、Spring Cloud toIstioです。Springクラウドプロジェクトとお客様からのIstioの組み合わせと移行のケース。
スピーチは主に4つの部分で構成されています。
1）背景紹介
2）Springクラウドマイクロサービスフレームワークを使用するときに発生する問題
3）解決策
4）例を通してプログラムの実際的な詳細を説明する
背景紹介
マイクロサービスをエントリポイントとして採用しているため、マイクロサービスの多くの利点は非常に明白ですが、システム全体に対応する複雑さも非常に重要です。モノリシックシステムが分散された後、ネットワークの問題、サービスが反対側のエンドサービスの検出の問題を見つけてアクセスする方法、ネットワークアクセスのフォールトトレラントな保護の問題など。ログ内のコールスタックを介して達成できる最も単純な問題の場所でさえ、マイクロサービスは分散コールチェーンを介してサポートされる必要があります。マイクロサービスによってもたらされるこれらの課題をどのように解決しますか？
マイクロサービスSDKは、以前は一般的なソリューションでした。マイクロサービスのユニバーサル機能は開発フレームワークにカプセル化されています。開発者はこのフレームワークを使用して独自のビジネスコードを開発および記述し、生成されたマイクロサービスには当然これらの機能が組み込まれています。長い間、このフォームはマイクロサービスガバナンスの標準構成であるため、初心者はこれらのSDKのみがマイクロサービスであると考えています。
サービスグリッドは、別の形式でガバナンス機能を提供します。SDKアプローチとは異なり、サービスガバナンス機能は、開発から完全に切り離された独立したエージェントプロセスで提供されます。写真からは両者の違いはごくわずかですが、アーキテクチャと実際のケースからの設計コンセプトの違いを分析し、前者が開発フレームワークであり、後者がインフラストラクチャであることを理解します。
SDKの形式では、SpringCloudが最も影響力のある代表的なプロジェクトです。Spring Cloudは、リストに示されているように、分散アプリケーションを構築するための一連の開発ツールを提供します。その中で、ほとんどの開発者は、サービス登録検出ユーレカ、構成管理構成、負荷分散リボン、フォールトトレラントHystrixの融合、コールチェーン埋め込みポイントスルース、ゲートウェイzuulまたはSpringクラウドゲートウェイなどのマイクロサービス関連プロジェクトに精通しています。 。この共有で言及されているSpringクラウドは、SpringCloudのマイクロサービス開発キットにも具体的に言及しています。
グリッド形式で最も影響力のあるプロジェクトはIstioです。このIstioのアーキテクチャ図は、このスピーチで頻繁に登場します。この共有の背景として、アーキテクチャがコントロールプレーンとデータプレーンで構成されていることを知っておく必要があります。コントロールプレーンは、グリッド内のサービスとサービス構成のさまざまなルールを管理します。データプレーンでは、各サービス間のアウトバウンドトラフィックとインバウンドトラフィックが、サービスと同じPODのデータプレーンプロキシによってインターセプトされ、トラフィック管理アクションが実行されます。
アーキテクチャに加えて、背景の別の部分として、2つの基本的な機能を選択して少し開き、2つの設計と実装の類似点と相違点を確認します。1つは、サービス検出と負荷分散です。
左側はSpringクラウドです。すべてのマイクロサービスが最初にセンターに登録されます。通常はEurekaがサービス登録を実行し、サービスにアクセスすると、コンシューマーはサービス検出のためにレジストリに移動して、ターゲットサービスのインスタンスのリストを取得します。アクセスする、クライアント側の負荷分散リボンを使用するサービスインスタンスを選択してアクセスを開始します。
右側のIstioは、サービス登録のプロセスを必要としません。実行中のプラットフォームk8sからサービスとインスタンスの関係を取得するだけで済みます。サービスにアクセスすると、データプレーンプロキシEnvoyがトラフィックをインターセプトし、ターゲットを選択します。リクエストを送信するインスタンス。クライアントの負荷分散はサービス検出データに基づいていることがわかります。違いは、サービス検出データのソースが異なり、負荷分散の実行本体が異なることです。
以下はヒューズを比較します：
左側は、古典的なHystrixの状態遷移図です。連続するエラーの数が一定期間しきい値を超えると、インスタンスはヒューズオン状態になり、要求を受け入れません。一定期間の分離後、インスタンスはヒューズ状態からセミヒューズ状態に移行します。正常な場合はヒューズオフ状態になり、リクエストを受信できます。正常でない場合はヒューズオープン状態になります。
Istioはそのような状態図を提供していませんが、Istioのルールと動作に精通している人なら誰でも、IstioのOutlierDectionのしきい値ルールもこのように設計されていることに気付くはずです。2つの違いは、SpringクラウドのサーキットブレーカーがSDKのHystrixによって実行され、Istioのデータプレーンプロキシによって実行されることです。Hystrixを使用すると、ユーザーはビジネスコードのプログラミングを通じてある程度の制御を行うことができます。
上記の分析は、サービスディスカバリ、負荷分散、および融合の機能とメカニズムが類似していることを示しています。ダイアグラムの詳細を無視すると、ブロックダイアグラムモデルは一見まったく同じです。通常、比較テーブルには実行位置が異なる項目が1つだけあります。この違いは、実際のアプリケーションに非常に大きな違いをもたらします。
Springクラウドマイクロサービスフレームワークの使用時に発生する問題
このスピーチの焦点は練習です。以下は、お客様がTOPを見つけた問題の一部であり、従来のマイクロサービスフレームワークを使用するときにユーザーが直面する問題を分析します。これらのほとんどは、グリッドを選択する最大の動機です。
1）多言語の問題
エンタープライズアプリケーション開発では、企業が統一された開発フレームワークを使用することは非常に合理的で一般的です。効率を向上させるために、多くの開発チームは多くの場合、独自の会社またはチームの一般的な開発フレームワークを維持します。もちろん、ほとんどのビジネスシステムはJavaに基づいて開発されているため、Springクラウド開発フレームワークまたはSpringクラウドから派生したさまざまな開発フレームワークが特に広く使用されています。
しかし、クラウドネイティブのシナリオでは、ビジネスは一般により複雑で多様であり、特に多くの既存の既存のシステムが関係しています。マイクロサービスに使用される成熟したサービスのセットをSpringCloudで書き直すことを要求することはできません。ユーザーは、元のシステムを書き直すことなく、アプリケーション層のサービスアクセスを管理する方法があることを強く望んでいます。
2）K8でSpringクラウドマイクロサービスを実行すると、サービスがタイムリーに検出されない可能性が高くなります
前述のように、Springクラウドサービスの検出は、各マイクロサービスが最初にレジストリに登録するデータに基づいて実装されます。従来のSpringクラウドのシナリオでは、マイクロサービスがVMにデプロイされると、サービスの動的変更要件はそれほど高くありません。ほとんどの個別インスタンスは正しく実行されておらず、サービス検出によるヘルスチェックで十分です。ただし、k8sシナリオでは、サービスインスタンスの動的移行はごく普通のシナリオです。図に示すように、プロデューサーの特定のポッドがノード間で移行されています。このとき、新しいpod2のプロデューサーインスタンスをeurekaに登録し、古いインスタンスPod1を登録する必要があります。
これが頻繁に発生する場合、登録センターのデータがタイムリーに維持されないため、サービス検出と古いインスタンスpod1への負荷分散が発生し、アクセスエラーが発生します。
3）サービス管理要件の変更に対応するために、すべてのアプリケーションをアップグレードします
3番目の質問はより典型的な質問です。お客様には、Spring Cloudに基づく独自の開発フレームワークのセットを維持することに専念する公開チームがあります。開発フレームワークをアップグレードするたびに、お客様はビジネスチームに独自のサービスをアップグレードするように依頼する必要があります。SDK自体は多くの場合、多くのワークロードなしで変更およびテストされますが、このSDKに基づいて開発された何千ものサービスを再コンパイル、パッケージ化、およびアップグレードするには長期的なアップグレード計画が必要であり、多くの場合、夜間の変更時にビジネスチームに同行する必要があります。このアップグレードによってもたらされる作業負荷とオンラインリスクを考慮すると、ビジネスチームは変更を加えていないため、通常、動機はありません。
4）モノリシックアーキテクチャからマイクロサービスアーキテクチャへの移行
これは比較的一般的な問題、つまり段階的なマイクロサービスです。Martin Fowlerは、モノリシックとマイクロサービスの分離に関する有名な記事（https://martinfowler.com/articles/break-monolith-into-microservices.html）でも、プログレッシブマイクロサービスのイニシアチブがどのようになり得るかについて言及しました。大企業は分割され、分離され、その後徐々にマイクロサービスになります。Martin Fowlerは、「デカップリングはコードではなくビジネス機能である」と強調しました。偉大な神はコードのデカップリングを開発者に任せました。
しかし、開発者の観点からは、プログレッシブマイクロサービスについて話すのは簡単ではありません。Springクラウドフレームワークに基づくマイクロサービスの開発を例にとると、すべてのマイクロサービス間で統一されたサービス検出、負荷分散、消費、および同じガバナンス戦略の実行を実行するには、すべてのマイクロサービスが同じまたは統合バージョンのSDKを開発します。
もちろん、この場合、お客様もAPIレベルに基づいて適応し、元の非マイクロサービス指向とマイクロサービス指向のものを共存させます。この同様のグレースケール方法を使用すると、実際の操作は非常に面倒です。
ある顧客は、2つのセットをわざわざ行う必要がないか、一部の大きなモノマーをマイクロサービスに直接変換できるかどうか、他のモノマーは時間があるか考えるまで、長い間まったく動かないかどうかを尋ねたことがあります。移動しても安全です。
解決
お客様が実際に遭遇する4つの典型的なマイクロサービスフレームワークの問題について、私たちが推奨するソリューションはすべてサービスグリッドです。Istioが上記の問題をどのように解決するかを見てみましょう。
まず、多言語の問題。サービスグリッドに基づいて、ビジネスデータプレーンとガバナンスデータプレーンを同じプロセスで実行する必要も、一緒にコンパイルする必要もないため、言語とフレームワークのバインドはありません。サービスが開発されている言語に関係なく、外部からアクセスおよび管理できる特定のアプリケーションプロトコル上のポートがあれば、グリッドで管理できます。ユニファイドグリッドコントロールプレーンを介して、ユニファイドガバナンスルールがユニファイドグリッドデータプレーンに発行されて実行され、上記で紹介したグレースケール、トラフィック、セキュリティ、可観測性などのユニファイドガバナンスアクションが実行されます。
SpringクラウドサービスがKubernetesで実行されている場合の、元のサービスのタイムリーでない登録と検出の問題について。根本的な原因は、2セットのサービス検出によって引き起こされる不整合であるため、ソリューションは比較的単純であり、統合されたサービス検出で十分です。K8sはポッドのスケジューリングと同時にサービスとインスタンス間のデータを維持しているため、個別のネームサービスメカニズムを構築する必要はなく、サービスを手間をかけて登録してから検出する必要があります。
Spring Cloud登録で見つかった画像を比較すると、登録センターがなくなり、登録センターに基づくサービス登録とサービス検出アクションは不要になりました。Istioはk8sのサービス検出データを直接使用しますが、アーキテクチャの用語。
また、この問題が発生したシナリオのほとんどは、マイクロサービスフレームワークをVMからk8sに移行するときに発生したことを要約しました。以前のVMとしてコンテナーを少し使用し、コンテナーのデプロイと操作のプラットフォームとして使用したのはk8sのみでした。また、k8sサービスは使用されません。
SDK自体がアップグレードされてすべてのビジネスが再アップグレードされたという問題の解決策は、サービスガバナンスのパブリック機能をビジネスから切り離すことです。グリッドでは、ガバナンス機能をインフラストラクチャにシンクした後、ビジネス開発、展開、およびアップグレードがサービスガバナンスインフラストラクチャから切り離されます。ビジネス開発者は、ビジネス部分に焦点を合わせます。ビジネスコードが変更されていない限り、再コンパイルしてオンラインにする必要はありません。
ガバナンス機能をアップグレードする場合、インフラストラクチャのアップグレードのみが必要であり、インフラストラクチャのアップグレードはユーザーのビジネスにまったく影響を与えません。Huawei Cloud ASMなどのほとんどのグリッドサービスプロバイダーはワンクリックアップグレードを実行でき、ユーザーはこのプロセスにまったく気づいていません。
プログレッシブマイクロサービスの問題に関しては、Isitoサービスメッシュの使用が完璧な解決策になる可能性があります。Istioは、サービス間のアクセスを管理します。サービスが他のサービスによってアクセスされる限り、マイクロサービスであろうとモノリスであろうと、Istioを介して管理できます。Istioがサービストラフィックを引き継いだ後、モノリスとマイクロサービスの両方が統合管理のための統合ルールを受け取ることができます。
図に示すように、マイクロサービスのプロセスでは、ビジネス分割に基づいて単一のアプリケーションsvc1をマイクロサービスに優先順位付けし、3つのマイクロサービスsvc11、svc12、およびsvc13に分割できます。svc1が依存する別の単一アプリケーションsvc2は、次のことができます。変更なしでグリッドで実行される場合、他の3つのマイクロサービスと同様に管理されます。また、一定期間実行した後、svc2サービスを独自のビジネスニーズに応じてマイクロサービスすることができます。大規模なリファクタリングによって引き起こされるワークロードとビジネス移行のリスクを可能な限り回避し、MartinFullerが提唱する段階的なマイクロサービスの実践を真に実現するため。
練習
上記は、実際の作業における顧客のいくつかの典型的な問題に対する解決策です。実際には、これらのソリューションを実装する方法は？以下は、特定の慣行を共有するための実際の顧客事例に基づく要約です。
私たちの主なアイデアは、切り離してアンインストールすることです。元のSDKで開発されていない関数をアンインストールします。SDKは、コードフレームワークやアプリケーションプロトコルなどの開発関数のみを提供します。マイクロサービスガバナンスに関連するすべてのコンテンツは、インフラストラクチャにオフロードされます。
この図から、開発者は開発フレームワークの薄化にさらされており、それに応じて開発者の学習、使用、保守のコストも削減されていることがわかります。インフラストラクチャはより重くなりました。以前に実行する必要のあるサービス操作の基本機能を完了することに加えて、非侵入型のサービスガバナンス機能も含まれています。以前はビジネスと見なされていた機能がますます一般的な機能に洗練され、インフラストラクチャに引き渡されて実行され、クラウドベンダーに引き渡されて実行されます。お客様は、これらの面倒な非ビジネスタスクを取り除き、専念することができます。ビジネスへのより多くの時間とエネルギー。イノベーションと開発。この分業の下で、SDKは実際に開発フレームワークの基本的な機能に戻ります。
グリッドの機能を使用するには、マイクロサービスからのトラフィックがグリッドのデータプレーンに送信できることが前提です。主な移行作業は、マイクロサービスのサービス呼び出し元です。次の3つの手順をお勧めします。
ステップ1：元のマイクロサービスレジストリを破棄し、K8Sサービスを使用します。
ステップ2： SDKのサービス検出と負荷分散のロジックを短絡し、k8sのサービス名とポートを直接使用してターゲットサービスにアクセスします。
ステップ3：独自のプロジェクトのニーズに応じて、グリッドのガバナンス機能を徐々に使用して、元のSDKで提供されている対応する機能を置き換えます。もちろん、このステップはオプションです。コールチェーン埋め込みポイントなどの元の機能は要件を満たすためにも使用されます。これは、アプリケーション自体の機能として予約されています。
上記の移行を実現するために、さまざまなユーザーシナリオに対して2つの方法があります。
1つは、構成のみを変更することです。Eurekaベースのサーバーでのサービス検出のサポートに加えて、SpringCloud自体もリボンの静的サービスインスタンスアドレスを構成できます。このメカニズムを使用して、対応するマイクロサービスのバックエンドインスタンスアドレスにKubernetesサービス名とサービスのポートを設定します。
Springクラウドフレームワークで元のサーバーマイクロサービス名に引き続きアクセスする場合、リクエストはk8sのサービスとポートに転送されます。このようにして、アクセスはグリッドデータサーフェスによってインターセプトされ、グリッドデータサーフェスに到達します。サービスディスカバリの負荷分散とさまざまなトラフィックルールをグリッドの機能に適用できます。
このメソッドは、実際には、最小限の変更でSDKのアクセスリンクとグリッドデータプレーンのアクセスリンクを接続します。プラットフォームで使用する場合、組立ラインツールを使用して、構成ファイルを直接変更する際の作業負荷と操作エラーを減らすことができます。私の実際のプロジェクトでは、プロジェクトのapplication.yaml構成ファイルのみが変更されており、他のコードはすべて変更されていないことがわかります。もちろん、注釈に基づく構成にも同じセマンティック変更を使用できます。
以前の方法では、元のプロジェクトへの変更は比較的少ないですが、SpringCloudのプロジェクト依存関係はまだ残っています。
一部のお客様は、別のより単純で直接的な方法を選択しました。さまざまなサービスガバナンス機能を含む、元のSDKでのサービス検出の負荷分散は不要であるため、これらの依存関係はすべて単純に排除されます。最終的なミラーサイズから判断すると、プロジェクト全体のボリュームも大幅に削減されています。このように、お客様は実際の使用状況に応じてさまざまな調整を行い、最終的にはほとんどのお客様がSpringクラウドをSpringブートに縮退させます。
移行には、マイクロサービスへの外部アクセス用のゲートウェイという特別な部分があります。
Springクラウドには、同様の機能を持つ2つのゲートウェイ、ZuulとSpringクラウドゲートウェイがあります。Eurekaのサービス検出に基づいて、内部マイクロサービスが外部サービスにマッピングされ、セキュリティや配布などの機能が入り口で提供されます。内部サービスと同様に、k8sとIstioに切り替えると、入口での各サービスのサービス検出がk8sに移行されます。
違いは、ユーザーがGatewayで多くのプライベートビジネス関連フィルターを開発する場合、Gatewayは実際にはマイクロサービスのファサードサービスです。ビジネス継続性のために、ソリューションは通常のマイクロサービスとして直接扱い、インターネット上に展開できます。グリッド。
ただし、ほとんどの場合、IstioのIngress Gatewayを使用して、このマイクロサービスゲートウェイを直接置き換え、外部TLSターミネーション、電流制限、およびトラフィックセグメンテーション機能を邪魔にならない方法で提供することをお勧めします。
上記の単純な変換の後、さまざまな言語で開発されたサービスとさまざまな開発フレームワークは、ビジネスプロトコルが接続され、相互にアクセスでき、アクセスプロトコルをグリッドで管理できる限り、Istioを介して均一に管理できます。
統合サービス管理ルールは、コントロールサーフェスで設定できます。データ側では、Envoyは、サービスディスカバリ、負荷分散、その他のトラフィック、セキュリティ、可観測性、およびその他の関連機能に一律に使用されます。データプレーン上のサービスは、コンテナーまたは仮想マシンで実行できます。また、複数のk8sクラスターで実行できます。
もちろん、移行プロセスの途中で、元のマイクロサービスフレームワークのレジストリの段階的な保持もサポートするため、Istioを他のサービス検出と組み合わせて中間状態を使用できるため、グリッド内のサービスでマイクロサービスレジストリのサービスにアクセスします。
これは、グレースケールパブリッシング用にIstioサービスグリッド上で実行されているSpringCloudによって開発されたサービスの例です。上記のログは、サービス呼び出し元のSidecarのログであり、グリッドがさまざまなサービスバックエンドにトラフィックを分散していることがわかります。以下のスクリーンショットは、Huawei Cloud ASMサービスのグレースケール機能を使用しています。このSpringクラウドサービスは、グリッドによって構成されたシャント戦略を通じて、トラフィックの30％をグレースケールバージョンに分散していることがわかります。
次の例は、Istioのサーキットブレーカー機能を使用してSpringCloudによって開発されたサービスです。このプロセスは、前の原則セクションのHystrixの状態遷移図の実践です。違いは、この実装がIstioに基づいていることです。サービスグリッドに基づいて、サービスが開発されている言語やフレームワークに関係なく、アクセスをヒューズで保護できます。
ここでの効果のスクリーンショットは、Huawei Cloud Application Service Grid ASMのアプリケーショントポロジからのものです。サービスレベル、サービスインスタンスレベルのトラフィックの変化、およびサービスとサービスインスタンスのヘルスステータスを非常に新鮮に確認できるため、Springクラウドに障害が発生したことがわかります。インスタンスは分離されています。プロセス全体。トポロジ図から、インスタンスがヒューズのしきい値を異常に満たし、ヒューズがトリガーされていることがわかります。グリッドデータは、この障害のあるインスタンスにトラフィックを分散し、トラフィックがまったくなくなるまで徐々に減少します。つまり、障害のあるインスタンスは分離されました。このヒューズ保護により、サービスアクセス全体の成功率が保証されます。
次の3つのトラフィックトポロジは、障害回復のプロセスを示しています。
見られます：
- 初期状態では、この障害インスタンスは分離されており、トラフィックはありません。
- インスタンス自体が正常な場合、グリッドデータプレーンは、設定された間隔でインスタンスを分離した後、トラフィックを再度割り当てようとします。しきい値の要件が満たされると、インスタンスは正常なインスタンスと見なされ、他の2つのインスタンスと同様にリクエストを受信できます。インスタンス。
- 最後に、3つのインスタンスでバランスの取れた処理要求を確認できます。
- つまり、障害回復が実現されます。
最後に、マイクロサービス、コンテナー、k8s、およびIstioの関係図を通じて、今日のコンテンツを要約します。
- マイクロサービスとコンテナーはどちらも軽量性と俊敏性という同じ特性を備えており、コンテナーはマイクロサービスに非常に適した動作環境です。
- クラウドネイティブシナリオでは、マイクロサービスシナリオでは、コンテナーが独立して存在することはなく、コンテナーをオーケストレーションするためにk8sを使用することはすでに事実上の標準です。
- アーキテクチャとアプリケーションのシナリオでIstioとk8sを緊密に統合することで、エンドツーエンドのマイクロサービス運用とガバナンスプラットフォームが提供されます。
- これは、推奨されるソリューションでもあります。マイクロサービスガバナンスにIstioを使用することは、ますます多くのユーザーにとってテクノロジーの選択肢になりつつあります。
上記の4つの関係を時計回りに組み合わせて、ソリューションの完全な閉ループを構築します。
添付
早くも2018年、HUAWEI CLOUDは、世界初のIstio商用サービスであるApplication Service Mesh（ASM）のリリースを主導しました。HUAWEICLOUDApplicationService Meshは、高性能で信頼性が高く、使いやすいフルマネージドサービスグリッドです。仮想マシンやコンテナなどの複数のインフラストラクチャをサポートし、クロスリージョンのマルチクラウドおよびマルチクラスターサービスの統合管理をサポートします。インフラストラクチャの形で、サービスフロー管理、サービス運用監視、サービスアクセスセキュリティ、およびサービス公開機能をユーザーに提供します。
現在、Huawei Cloud Application Service Gridは、インターネット、自動車、製造、ロジスティクス、政府などの複数の業界で1,000近くの顧客にサービスを提供しており、さまざまな業界の顧客のビジネス需要に対応しています。HUAWEI CLOUDは、このプロセスで蓄積された豊富な経験をコードに変換し、Istioテクノロジーの成熟とコミュニティの急速な発展を大いに促進してきたIstioコミュニティに貢献します。同時に、Huawei Cloudは、サービスグリッドの技術エバンジェリズムにも多額の投資を行い、コミュニティフォーラム、技術会議、ビデオライブ放送、専門書などのさまざまな方法を通じて、サービスグリッドテクノロジーの普及と普及を促進してきました。