マイクロサービスガバナンスが直面する課題
ビジネスの初期段階では、人員が限られており、製品を迅速に開発して発売したいため、多くのチームが開発に単一のアーキテクチャを使用しています。しかし、会社の発展に伴い、新しいビジネス機能がシステムに継続的に追加されます。システムはますます大きくなり、需要は増え続けます。開発チームに参加する人はますます増え、コードベースも増えます。ゆっくりとモノリシックなアプリケーションはますます肥大化し、保守性と柔軟性は徐々に低下し、保守コストはますます高くなっています。
現時点では、多くのチームがモノリシックアプリケーションアーキテクチャをマイクロサービスアーキテクチャに変更して、モノリシックアプリケーションの問題を解決します。しかし、マイクロサービスが増えるにつれ、運用と保守への投資が増え、数十または数百ものサービスの正常な運用と連携を確保する必要があります。これは運用と保守に大きな課題をもたらします。ソフトウェアの寿命は次のとおりです。サイクルこれらの課題を次の観点から分析します。
- 開発テストの状態
- 開発、テスト、およびオンライン環境を分離する方法は？
- ローカルの変更をすばやくデバッグする方法は？
- ローカルの変更をすばやく展開するにはどうすればよいですか？
- リリース状態
- サービスリリース戦略を設計する方法は？
- 古いバージョンのサービスを失うことなく非アクティブ化するにはどうすればよいですか？
- 新しいバージョンのサービスのグレースケールテストを実装するにはどうすればよいですか？
- 実行状態
- オンラインの問題をトラブルシューティングする方法は？どのようなツールを使用できますか？
- サービス品質の低いノードを処理するにはどうすればよいですか？
- まったく機能していないインスタンスからどのように回復しますか？
上記の問題に直面して、サーバーレスアプリケーションエンジンはこの点でどのような作業を行いましたか？
サーバーレスアプリケーションエンジン
上の図に示すように、サーバーレスアプリケーションエンジン（SAE）は、Dragon + ECI + VPC + SLB + NASなどのIaaSリソースに基づいてKubernetesクラスターを構築し、アプリケーション管理とマイクロサービスガバナンスのためのいくつかの機能を提供します。Spring Cloudアプリケーション、Dubboアプリケーション、HSFアプリケーション、Webアプリケーション、多言語アプリケーションなど、さまざまなアプリケーションタイプで管理できます。また、Cloudtoolkitプラグイン、クラウドエフェクトRDC / Jenkinsなどの開発者ツールをサポートします。サーバーレスアプリケーションエンジンでは、ゼロコード変換により、Javaマイクロサービスのアプリケーションをサーバーレスに移行できます。
一般に、サーバーレスアプリケーションエンジンは、より費用効果が高く効率的なワンストップアプリケーションホスティングソリューションを提供できます。ゼロしきい値、ゼロ変換、ゼロコンテナ基盤により、サーバーレス+ K8s +マイクロサービスによってもたらされる技術的なメリットを享受できます。
マイクロサービスガバナンスの実践
1.開発の実践
1）マルチ環境管理
- マルチテナントは登録センターを共有し、トラフィックは異なるテナントによって分離されます。さらに、環境はネットワークVPCを介して分離できます。
- ワンクリックで停止して環境全体をプルアップするなど、環境レベルの操作および保守操作を提供します。
- 環境レベルの構成管理を提供します。
- 環境レベルのゲートウェイルーティングトラフィック管理を提供します。
2）クラウド共同デバッグ
Alibaba CloudToolkitプラグイン+スプリングボードに基づくサーバーレスアプリケーションエンジン（SAE）は、次のことを実現できます。
- クラウドSAEの組み込み登録センターへのローカルサービスのサブスクリプションと登録。
- ローカルサービスは、クラウドSAEサービスを使用して相互に呼び出すことができます。
上の図に示すように、ユーザーは実装時にECSプロキシサーバーを持っている必要があります。実際の登録はSAEレジストリへのECSプロキシサーバーです。Cloudtoolkitプラグインをインストールした後、IDEAは起動時にチャネルサービスをローカルにプルアップします。プロセス。、このチャネルサービスはECSプロキシサーバーに接続され、すべてのローカルリクエストはECSプロキシサーバーに転送され、サービスへのクラウド呼び出しもECSプロキシを介してローカルに転送されるため、最新のコードはローカルブレークポイントでデバッグできます。これは、クラウド共同デバッグの実現です。
3）迅速な開発システムを構築する
コードをローカルに統合した後、MavenプラグインとIDEAプラグインを介してクラウド開発環境に迅速にデプロイする必要があります。
2.リリース練習
1）アプリケーションリリース3軸
- グレースケールにすることができます：アプリケーションリリースのプロセス中、運用および保守プラットフォームには、シングルバッチ、バッチ、カナリアなどのリリース戦略を含むリリース戦略が必要です。同時に、トラフィックのグレースケールをサポートする必要があります。自動バッチも許可する必要があります。/手動で選択します。
- 観察可能：リリースプロセスを監視でき、リリースされたログと結果を白い画面でリアルタイムに表示して、問題を時間内に特定できます。
- ロールバック：リリースプロセスを制御するための手動介入を可能にします：異常終了、ワンクリックロールバック。
これらの3つのポイントを通じて、アプリケーションのリリースはグレースケール、監視可能、およびロールバックになります。
2）マイクロサービスのロスレスオフライン
バージョン交換の過程で、SAEはどのようにして古いバージョンのマイクロサービストラフィックを損失なくドロップできるようにしますか？
上の図は、マイクロサービスの登録と発行のプロセス全体です。この図には、サービスコンシューマーとサービスプロバイダーがあります。サービスプロバイダーには2つのインスタンスB1とB2があり、サービスコンシューマーにはそれぞれ2つのインスタンスA1とA2があります。
B1とB2は登録センターに登録します。消費者は登録センターからサービスリストを更新し、サービスプロバイダーB1とB2を見つけます。通常の状況では、消費者はB1またはB2に電話をかけ始めます。サービスプロバイダーBは新しいバージョンをリリースする必要があります。 B1などのノードのうち、最初にJavaプロセスを停止します。サービス停止プロセスはアクティブ破棄とパッシブ破棄に分けられます。アクティブ破棄は準リアルタイムです。パッシブ破棄の時間はさまざまな登録センターによって決定されます。最悪の場合1分かかる場合があります。
アプリケーションが正常に停止していれば、Spring CloudとDubboフレームワークのShutdownHookは正常に実行でき、このステップの時間消費は基本的にごくわずかです。Kill-9を直接停止するなど、アプリケーションが異常に停止した場合、またはDockerイメージがビルドされた場合、Javaプロセスは最初のプロセスではなく、Killシグナルがアプリケーションに渡されない場合、サービスプロバイダーは主導権を握ってノードからログアウトすると、レジストリがサービスのプロセスをオフラインで検出して受動的に認識するのを待ちます。
マイクロサービスレジストリは、サービスがオフラインであることを検知すると、サービスノードの1つがオフラインになったことをサービスコンシューマに通知します。レジストリからのプッシュとコンシューマラウンドロビンの2つの方法があります。レジストリはサービスのリストを更新し、プロバイダーがノードをオフラインにしていることを認識します。この手順はDubboフレームワークには存在しませんが、SpringCloudの場合の最悪の更新時間は30秒です。コンシューマーのサービスリストが更新されると、オフラインノードBは呼び出されなくなります。手順2から手順6まで、登録センターがユーレカの場合、最悪の場合2分、ナコスの場合、最悪の場合50秒かかります。
この間、リクエストに問題が発生する可能性があるため、公開時にさまざまなエラーが表示されます。
上記の分析の後、従来の公開プロセスでは、クライアントにサーバー呼び出しエラー期間があります。これは、クライアントがサーバーのオフラインインスタンスを時間内に認識できないことが原因です。この状況は主に、サービスプロバイダーがマイクロサービスを使用していることが原因で通知が発生しているためです。消費者は、サービスによって提供されるリストを更新します。
登録センターをバイパスして、サービスプロバイダーがサービスコンシューマーに直接通知することはできますか？答えはイエスです。SAEは2つのことを行いました。まず、アプリケーションがリリースされる前に、サービスプロバイダーが主導権を握って、サービスレジストリからアプリケーションの登録を解除し、アプリケーションをオフラインとしてマークし、元の停止したプロセスステージの登録解除をpreStopステージの登録解除に変更します。処理する。
サービスコンシューマーのリクエストを受信すると、最初に通常どおりリクエストを処理し、ノードがオフラインになったことをサービスコンシューマーに通知します。その後、コンシューマーは通知を受信するとすぐにサービスリストを更新します。サービスコンシューマーは送信しなくなります。サービスプロバイダーB1のインスタンスへのリクエスト。
上記のスキームにより、オフラインの認識時間が元の分レベルから準リアルタイムに大幅に短縮され、アプリケーションがオフライン時にロスレスでビジネスを実現できるようになります。
3）タグに基づくグレースケールパブリッシング
リリース戦略は、バッチリリースとグレーリリースに分けられます。トラフィックのグレーレベルを達成するにはどうすればよいですか。上記のアーキテクチャ図からわかるように、アプリケーションがリリースされる前に、グレースケールルールを構成する必要があります。たとえば、グレーフロールールとしてuid = 20のモジュラスに従って、アプリケーションがリリースされると、次のようになります。ノードはグレーバージョンとして識別されます。この場合、トラフィックが着信すると、マイクロサービスゲートウェイとコンシューマーの両方が、構成センターを介してガバナンスセンターで構成されたグレールールを取得します。
コンシューマーのエージェントは、依存するサービスに関する情報もレジストリから取得します。トラフィックがコンシューマーに入ると、グレースケールルールに従って一致します。グレースケールトラフィックの場合は、変換されます。通常のフローの場合は通常のマシンに転送されます。これは、ラベルに基づくグレースケールパブリッシングの特定のロジックです。
3.運用慣行
1）強力なアプリケーション監視および診断機能
実行中のインスタンスの場合、サービスの運用中に何らかの問題が発生します。トラブルシューティングと解決方法を教えてください。
トラブルシューティングと解決の前提条件は、強力なアプリケーション監視機能と診断機能を備えていることです。SAEはクラウド製品ARMSを統合します。これにより、SAEで実行されているJavaマイクロサービスがアプリケーションの呼び出し関係トポロジマップを確認でき、MySQLの低速サービスを見つけることができます。メソッドのスタックを呼び出してから、コードレベルで問題を特定します。
たとえば、リクエストの応答が遅く、ビジネスに問題があり、どのリクエスト、どのサービス、どのサービスラインに問題があるかを特定できるため、問題の解決に非常に便利です。一般に、サービス運用プロセスの問題をより適切に診断できるように、最初に監視と警告を行う機能が必要です。
2）障害の切り分けとサービスの回復
前述のように、監視とアラームを使用して、発生した問題のトラブルシューティングと解決を行います。システムが主導権を握って何かを実行できますか？サーバーレスプラットフォームとして、SAEには多くの自己運用および保守機能があります。次の図には2つのシナリオがあります。
- シナリオ1：アプリケーションの操作中に、ディスクがいっぱいであるかホストリソースの競合が原因で、特定のマシンの負荷が高いかネットワークステータスが低く、クライアントで呼び出しタイムアウトまたはエラーが発生している。
この状況に直面して、SAEはサービスガバナンス機能、つまり外れ値の削除を提供します。これは構成可能です。ネットワークタイムアウトが深刻な場合、またはバックエンドサービスの5xxエラーが特定の割合に達した場合は、ノードを削除することを選択できます。その結果、問題のマシンはビジネスリクエストに応答しなくなり、ビジネスのSLAが十分に保証されます。
- シナリオ2：アプリケーションの実行中に、バーストトラフィックのためにメモリが使い果たされ、OOMがトリガーされます。
この場合、SAEなどのサーバーレスアプリケーションエンジンを使用すると、ノードがヘルスチェックで構成された後、ノード内のコンテナーを再度プルアップして、プロセスを迅速に復元できます。
3）正確な容量+電流制限劣化+極端な柔軟性
サーバーレスPaasプラットフォームSAEと他の製品との相互作用に基づいて、運用および保守状態全体の閉ループを実現します。
ユーザーがそれを使用すると、PTS圧力測定ツールを使用してシーンを構築し、いくつかのしきい値を取得できます。たとえば、ピークトラフィックによって消費されるリソースを見積もることができ、これらのしきい値に基づいて柔軟な戦略を設計できます。ビジネスシステムが要求率に達すると、設定された弾力性のある戦略に従って、自社のマシンを拡張および縮小できます。
時間的には、拡大・縮小が大量のリクエストの処理に追いつかない場合がありますが、現時点では、AHASとの連携により、電流制限や劣化を設定する機能を設定できます。大量のトラフィックがバーストした場合、最初にAHASの機能を使用して一部のトラフィックをブロックし、次にSAEに適用される拡張戦略をトリガーして、インスタンスを同時に拡張できます。これらのインスタンスの拡張が完了すると、マシン全体の平均負荷が低下し、フローが再び戻ってきます。大規模なトラフィックのバーストから、電流制限と劣化、容量拡張、そして最終的には通常の状態に達するフローまで、これは「正確な容量+電流制限と劣化+極端な柔軟性」のベストプラクティスモデルです。
総括する
この記事では、最初に、質問を提起して問題を解決するというアイデアに従ってマイクロサービスの開発、リリース、運用の問題を解決する方法について説明し、次にサーバーレス製品を介して他の製品と対話して、正確なトラフィック、電流制限の低下、および極端な柔軟性を実現する方法を紹介します。 。
- 開発テストの状態
- レジストリを介してマルチテナント環境とネットワーク環境を分離し、環境レベルの機能を提供します。
- クラウド共同デバッグテクノロジーにより、ローカルの変更をすばやく調整します。
- IDEプラグインがローカルの変更をすばやく展開する場合。
- リリース状態
- 運用および保守プラットフォームは、アプリケーションのリリースのために、灰色で、観察可能で、ロールバックする必要があります。
- MSEエージェント機能を介してオフラインでロスレスサービスを実現します。
- ラベルルーティングは、オンライントラフィックのグレースケールをテストする機能を提供します。
- 実行状態
- 強力なアプリケーション監視および診断機能を確立します。
- サービス品質の低いノードの外れ値を削除する機能。
- 動作しなくなったインスタンスのヘルスチェックを構成することで、インスタンスを再起動および再開できます。
- 正確な容量+電流制限劣化+極端な柔軟性モデルを提供します。
著者プロフィール：Wang Kehuai、花名：Xingsong、Aliyun SAEテクノロジーの研究開発、SAE製品のランタイムレイヤーテクノロジーアーキテクチャの設計を担当し、マイクロサービス、サーバーレス、アプリケーションホスティングの分野に焦点を当て、新しいものを継続的に構築していますクラウドネイティブテクノロジーに基づくアプリケーションホスティングプラットフォームの生成。
この記事はAlibabaCloudのオリジナルのコンテンツであり、許可なく複製することはできません。