ヘッドpicture.png

著者|張元正
出典|アリババクラウドネイティブ公式アカウント

はじめに：Dubboは分散型マイクロサービスフレームワークであり、多くの企業が実際にDubboに基づく分散型システムアーキテクチャを実装しています。オープンソースを再開した後、Dubbo 3.0の最新のロードマップがリリースされただけでなく、 Alibabaが独自のeコマースでDubboと内部HSFの統合を促進し始め、Double11でDubbo3.0の使用を開始しました。この記事は、Dubboに基づいてICBCによって構築された金融マイクロサービスアーキテクチャの共有であり、主にサービス検出の対応戦略と結果について説明します。フォローアップでは、ICBCの大規模なサービス監視とガバナンスの実践、および企業の観点からDubboを再開発する方法について説明します。。フォローへようこそ。

背景と概要

ICBCの従来のビジネスシステムは、一般にJEEモノリシックアーキテクチャに基づいています。金融ビジネスのオンラインで多様化した開発トレンドに直面して、従来のアーキテクチャはもはやビジネスニーズを満たすことができません。そのため、2014年以降、ICBCはサービス指向の試みとしてビジネスシステムを選択し、当時のいくつかの分散サービスフレームワークを検証、評価、比較し、最終的に多くの国内企業ですでに使用されている比較的完全なものを選択しました。ダボ。同時に、ICBCは、このビジネスシステムがサービス指向の実装を完了するのを支援するためにDubboをカスタマイズし、オンラインになった後も非常に良い結果を受け取りました。

ICBCは、2015年にサービスアーキテクチャの範囲を拡大し始め、一方では従来のビジネスシステムの構造を変革するのに役立ちましたが、一方で、ビジネスシステムの迅速なサービスの組み合わせと再利用をサポートするために、ミドルオフィスと同様の超大規模なサービスグループを徐々に生み出しました。ICBCは、経験の蓄積とともに、Dubboの最適化とカスタマイズを繰り返し続けてきましたが、同時に、サービスを中心とした包括的なサービスエコシステムを徐々に構築してきました。

2019年には、ICBCのマイクロサービスシステムも正式にICBCのオープンプラットフォームコアバンキングシステムの主要機能の1つにアップグレードされ、ICBCのITアーキテクチャが真に分散された変革を実現できるようになりました。

ICBCのマイクロサービスシステムの構成を次の図に示します。

インフラストラクチャに関しては、ビジネスシステムのサービスノードとマイクロサービスプラットフォームの作業ノードの両方がICBCクラウドプラットフォームに展開されています。
サービスの登録と検出に関しては、従来のサービス登録センターに加えて、ノードによるサービスの登録と検出を実装するためのメタデータセンターも展開されています。
サービス構成に関しては、外部の分散構成センターを通じて、さまざまな動的パラメータの統合管理と配布を実現できます。
サービスモニタリングに関しては、さまざまなサービスインジケータの統合された収集と保存を実現し、エンタープライズモニタリングプラットフォームに接続します。
サービス追跡に関しては、主にサービスの全体的なリンクをリアルタイムで追跡するために使用され、ビジネスシステムが障害のポイントを迅速に特定し、障害の範囲を正確に評価するのに役立ちます。
サービスゲートウェイは、従来のビジネスシステムのサービス要件を満たすためのものです。DubboサービスサブスクリプションおよびRPC機能に加えて、新しいサービスおよび新しいバージョン（HTTPプロトコルからRPCプロトコル）の自動検出、自動サブスクリプション、およびプロトコル変換機能を実現し、7倍を実現します。 24時間の中断のない操作。
サービス管理プラットフォームは、運用および保守担当者と開発テスターにワンストップの管理、監視、および照会プラットフォームを提供して、日常のサービス管理の効率を向上させます。

最大の課題

ICBCでの長年の実践の後、この記事では、次の2つの側面における最大の課題を要約します。

パフォーマンス容量に関しては、現在のオンラインサービスの数（つまり、Dubboコンセプトのサービスインターフェイスの数）が20,000を超え、各レジストリのプロバイダーエントリの数（つまり、各サービスのすべてのプロバイダーの累積数）が70を超えています。百万。評価によると、将来的には、各レジストリで100,000レベルのサービスと500万レベルのプロバイダーエントリをサポートできる必要があります。
高可用性の観点から、ICBCの目標は次のとおりです。マイクロサービスプラットフォームのノード障害がオンライントランザクションに影響を与えることはありません。銀行のビジネスシステムは7×24時間稼働しています。バージョンの制作時間枠内でも、各ビジネスシステムの制作時間はずれています。プラットフォーム自体のノードをアップグレードする必要があります。オンライントランザクション、特に登録センターへの影響を回避する方法独自のバージョンの更新。

この記事では、最初に、サービス検出の観点からICBCの対応戦略と有効性を共有します。

サービス発見の難しさと最適化

1.はじめに

Dubboでは、サービスの登録、サブスクリプション、および呼び出しが標準のパラダイムです。サービスプロバイダーはサービスが初期化されるときに登録し、サービスコンシューマーはサービスが初期化されるときにサブスクライブして、プロバイダーの完全なリストを取得します。運用中にサービスプロバイダーが変更されると、サービスコンシューマーは最新のプロバイダーリストを取得できます。レジストリを経由せずに、コンシューマーとプロバイダー間のポイントツーポイントRPC呼び出し。

登録センターの選択に関して、ICBCは2014年にZookeeperを選択しました。Zookeeperは、業界のさまざまなシナリオで大規模なアプリケーションを備えており、クラスター化された展開をサポートします。ノード間のデータの一貫性は、CPモードによって保証されます。

Zookeeper内では、Dubboはサービスに応じて異なるノードを確立します。各サービスノードには、プロバイダー、コンシューマー、構成、ルーターの4つのバイトがあります。

プロバイダー一時ノード：サービスプロバイダーのリストを記録します。プロバイダーのオフラインの子ノードは自動的に削除されます。Zookeeperの監視メカニズムにより、消費者はプロバイダーリストが変更されたことをすぐに知ることができます。
消費者：一時ノード：主にサービスガバナンス中に消費者にクエリを実行するために使用される消費者のリストを記録します。
構成永続ノード：主に、サービス管理中に調整する必要のあるサービスパラメーターを保存します。
ルーター：子ノードは永続ノードであり、主にサービスの動的ルーティング戦略を構成するために使用されます。

オンライン実稼働環境では、Zookeeperはデータセンターに複数のクラスターを展開し、各クラスターは5つの選択ノードと複数のオブザーバーノードで構成されます。オブザーバーノードは、Zookeeper 3.3.3バージョンで導入された新しいノードタイプです。選挙には参加せず、投票結果をリッスンするだけです。その他の機能は、フォロワーノードと同じです。オブザーバーノードには、次の利点があります。

シャントネットワークのプレッシャー：サービスノードの増加に伴い、クライアントが選択ノードに接続されている場合、選択ノードがネットワーク接続と要求を処理するために大量のCPUを消費します。ただし、選択ノードはどのレベルでも拡張できません。選択ノードが多いほど、トランザクションの投票プロセスが長くなり、同時書き込みのパフォーマンスが高くなります。
都市間およびDC間登録とサブスクリプショントラフィックの削減：100人の消費者が都市間で同じサービスにサブスクライブする必要がある場合、オブザーバーは都市間ネットワークトラフィックのこの部分を統一された方法で処理して、都市間ネットワーク帯域幅への圧力を回避できます。
クライアントの分離：ネットワークトラフィックの分離を確実にするために、いくつかのオブザーバーノードを主要なアプリケーションに割り当てることができます。

2.問題分析

近年のZookeeperのオンライン使用の悲しい歴史に基づいて、ICBCは、Zookeeperがサービス登録センターとして機能するときに直面した問題を要約しました。

サービスとサービスプロバイダーノードの数が増えると、サービスによってプッシュされるデータの量が爆発的に増加します。たとえば、サービスには100のプロバイダーがあります。プロバイダーが起動すると、ZookeeperのCP機能により、プロバイダーがオンラインになるたびに、コンシューマーはイベント通知を受信し、Zookeeperから現在のすべてのサービスを読み取ります。プロバイダーのリストを表示してから、ローカルキャッシュを更新します。このシナリオでは、理論的には、各消費者は合計100のイベント通知を受信し、Zookeeperからサービスプロバイダーのリストを100回読み取り、1 + 2 + 3 + ... + 100、合計5050のプロバイダーデータを受け取りました。この問題は、ビジネスシステムの生産のピーク時に特に顕著であり、Zookeeperクラスターネットワークが簡単にいっぱいになり、サービスサブスクリプションの効率が極端に低下し、サービス登録のパフォーマンスにさらに影響を与える可能性があります。
Zookeeperに書き込まれるノードの数が増えると、Zookeeperのスナップショットファイルは増え続けます。スナップショットがディスクに書き込まれるたびに、ディスクIOチャージが発生します。生産のピーク時には、トランザクション量が多いため、スナップショットファイルを書き込む頻度も非常に高く、インフラストラクチャに大きなリスクをもたらします。同時に、スナップショットファイルが大きいほど、Zookeeperノードの障害後の回復に時間がかかります。
Zookeeper選出ノードが再選出されると、オブザーバーノードは新しいリーダーノードからのトランザクション全体を同期する必要があります。このフェーズに時間がかかりすぎると、オブザーバーノードに接続されているクライアントセッションがタイムアウトし、対応するプロバイダーノードが作成されます。一時ノードはすべて削除されます。つまり、レジストリの観点から、これらのサービスはすべてオフラインであり、プロバイダーがないという消費者側の例外レポートがあります。その後すぐに、これらのプロバイダーはZookeeperに再接続してサービスを再登録します。このような大規模なサービスの短期間の登録ロールオーバーの現象は、多くの場合、より深刻なサービス登録プッシュパフォーマンスの問題を引き起こします。

要約すると、Zookeeperはまだレジストリとして比較的有能であるという結論を導き出すことができますが、大規模なサービス量のシナリオでは、さらなる最適化が必要です。

3.最適化計画

ICBCの最も重要な最適化手段には、サブスクリプション遅延の更新、登録センターが複数モードを採用する、ノードによる登録へのアップグレードなどの側面が含まれます。

1）サブスクリプションの遅延更新

ICBCは、Zookeeperクライアントコンポーネントzkclientを最適化し、イベント通知を受信した後、消費者がプロバイダーリストを取得するのを少し遅らせました。

zkclientがchildchangeワンタイムイベントを受信すると、installWatch（）はEventThreadを介してノードの監視を復元し、同時にgetChildren（）を使用してノードの下のすべての子ノードを読み取り、プロバイダーリストを取得し、ローカルサービスプロバイダーキャッシュを更新します。。これが前述の「5050データ」問題の原因です。

zkclientがchildchange（）イベントを受信した後、ICBCは、installWatch（）に想定どおりの処理を実行させる前に待機遅延を作成しました。この待機プロセス中にサービスプロバイダーが変更された場合、childchangeイベントは生成されません。

これが動物園の飼育係のCPモデルに違反しているかどうかを尋ねる人もいるかもしれませんが、実際はそうではありません。飼育係のサーバー上のデータは非常に一貫しています。消費者もイベント通知を受け取りました。プロバイダーリストの読み取りを遅らせてgetChildren（）、zookeeperの最新データは既に読み込まれているので、問題ありません。

内圧テストの結果によると、サービスプロバイダーが大規模にオンラインになった場合、最適化の前に、各コンシューマーはプロバイダーノードから合計422万のデータ量を受け取り、1秒の遅延後にデータ量は260,000になりました。、チャイルドチェンジイベントとネットワークトラフィックの数は元の約5％になりました。この最適化の後、ピーク生産期間中に多数のサービスのオンラインとオフラインを落ち着いて処理できます。

2）マルチモード

ICBCは、複数の登録センターのシナリオでサービスサブスクリプションを最適化するために、新しいバージョンのDubboでregistry-multipleのSPI実装を採用および最適化しました。

Dubboのサービスコンシューマーの元の処理ロジックは次のとおりです。複数の登録センターがある場合、コンシューマーは登録センターに対応する呼び出し元キャッシュに従ってプロバイダーを選択し、最初の登録センターに対応するキャッシュに見つからない場合は、 2番目のレジストリに対応するキャッシュを見つけます。この時点で最初のレジストリに可用性の問題があり、コンシューマーにプッシュされたデータが欠落しているか、空でさえある場合、プロバイダーのない例外、不均衡な通話負荷など、コンシューマーのスクリーニングプロセスに影響します。

複数のレジストリは、複数のレジストリによってプッシュされたデータをマージしてからキャッシュを更新するため、単一のレジストリに障害が発生した場合でも、他のレジストリのデータが完全である限り、プッシュされたデータは不完全または空です。最後にマージされたデータに影響します。

さらに、複数の登録センターメカニズムは、異種の登録センターのシナリオでも使用されます。登録センターは、問題が発生したときにいつでもオフラインにすることができます。このプロセスは、サービスノードのサービス呼び出しに対して完全に透過的であり、グレースケールパイロットまたは緊急切り替えに適しています。

さらに、追加の利点があります。消費者側の参照オブジェクトはJVMメモリを消費します。複数レジストリモードは、消費者が呼び出し元オブジェクトのコストの半分を節約するのに役立ちます。したがって、複数のレジストリシナリオで複数モードを使用することを強くお勧めします。。

3）ノードごとに登録する

ICBCは、「ノードごとの登録」のサービス登録-検出モデルを使用して、Dubbo2.7およびDubbo3.0のサービス検出ロジックを逆移植します。構成センター、メタデータセンター、登録センターの鉄の三角形の組み合わせは次のとおりです。

構成センター：主に、ノードレベルで動的パラメーターを保存するために使用されます。また、Zookeeperで最初に作成されたサービスの構成やルーターなどの永続的なノードデータも保存します。
メタデータセンター：ノードメタデータ、つまり、各サービスノード名（アプリケーション名）とそれが提供するサービス間のマッピング関係、および各メソッドの入力および出力パラメータ情報など、各サービスのクラス定義情報を格納します。。
レジストリ：現時点では、レジストリはサービスプロバイダーのノード名と実際のIPポートの間の関係を保存するだけで済みます。

このモデルの変更は、消費者のサービスコールに影響を与えません。メタデータセンターの「サービスノード名」と「サービス」の関係、およびレジストリの「サービスノード名」と実際のIPポートの関係に応じて、コンシューマ側はインベントリモードと互換性のあるサービスプロバイダー呼び出しキャッシュを生成します。

圧力テストの結果は、ノードごとに登録すると、登録センターのデータ量が元の1.68％になる可能性があることを示しています。この量は、サービス量が100,000、ノードが100,000のオンラインZookeeperに圧力をかけません。金額は簡単にサポートできます。

将来の計画

将来的には、ICBCは外出してコミュニティに深く参加し、Dubbo、Zookeeperサーバー、zkclientで独自の優れた機能を提供する機会を得ることも望んでいます。たとえば、上記の最適化ポイントに加えて、ICBCはDubboでもそれを行っています。 RPC結果の洗練された識別、PAAS適応、同じポートでのマルチプロトコル、自己分離、およびその他の機能、および登録ヒューズメカニズムがZookeeperに追加されました。同時に、完全なデータ同期によって引き起こされる一連の問題を回避するために、オブザーバー同期メカニズムが研究されています。

さらに、マイクロサービスの開発の観点から、メッシュはすでに現在のホットスポットの1つです。ICBCの主な問題点は、サービスSDKバージョンのアップグレードです。Istioは最新ではなく、MCPはまだ生きているか死んでいます。既存のDubboサービスをMESHアーキテクチャにスムーズに移行する方法は予備的なものですが、克服すべき技術的な問題はまだたくさんあります。

大規模なシナリオで問題と経験について話し合い、共同でDubboの企業の着陸を改善する練習をしたDubboの学生を歓迎します！

Dubbo-ServiceDiscoveryに基づいて金融マイクロサービスアーキテクチャを構築するICBCの慣行