著者: フアン・シャン
マンバングループは、「インターネット+物流」プラットフォーム企業として、荷主の配送ニーズを引き受ける一方、トラック運転手と連携して貨物物流効率を向上させます。 2021年に米国株式市場に上場する予定で、上場する初のデジタル貨物プラットフォームとなる。同社の年次報告書によると、2021年には350万人以上のトラック運転手がプラットフォーム上で1億2,830万件以上の注文を完了し、総取引額は2,623億元に達し、中国のデジタル貨物プラットフォームシェアの60％以上を占めた。 2022年10月、ユンマンマンのドライバー版のMAUは949万2,100人に達し、ワゴンマンマンのドライバー版のMAUは399万9,100人、オーナー版のユンマンマンのMAUは218万6,800人、ワゴンバンの荷主版のMAUは218万6,000人となった。 637,800でした。(以下の内容は、Zikui と Congyan によってコンパイルおよび出力されます)
ビジネスの成長がサービスの安定性に課題をもたらす
Manbang Group は、ビジネス本番環境に独自のマイクロサービス ゲートウェイを構築し、南北のトラフィック スケジューリング、セキュリティ保護、マイクロサービス ガバナンスを担当すると同時に、マルチアクティブな災害復旧機能を考慮して、次のようなサービスも提供しています。同じコンピュータ ルーム内の優先通話、災害復旧、コンピュータ ルーム間の通話などのメカニズムとして機能します。マイクロサービス ゲートウェイは、マイクロサービス アーキテクチャのフロントエンド コンポーネントとして、すべてのマイクロサービスのトラフィックの入り口として機能します。クライアント要求が受信されると、最初に ALB (負荷分散) に到達し、次に内部ゲートウェイに進み、ゲートウェイを介して特定のビジネス サービス モジュールにルーティングされます。
したがって、ゲートウェイはサービス登録センターを使用して、現在の運用環境にデプロイされているすべてのマイクロサービス インスタンスを動的に検出する必要があります。また、一部のサービス インスタンスが障害によりサービスを提供できない場合、ゲートウェイはサービス登録センターと連携して自動的に転送することもできます。サービス インスタンスでは、フェイルオーバーと弾力性が実現され、サービス登録センターと連携してサービス間呼び出しを実現するために自社開発のフレームワークが使用されます。 Manbang Group は、サービス登録センターと構成センターを構築するためにオープンソースの Eureka と ZooKeeper を初めて採用し、初期段階で Manbang Group の急速なビジネス成長をうまく担いました。
しかし、ビジネス量が徐々に増加するにつれて、ビジネス モジュールがますます増加し、サービス登録インスタンスの数が爆発的に増加します。このアーキテクチャで自社構築された Eureka サービス登録センター クラスタと ZooKeeper クラスタの安定性の問題がますます明らかになりました。 。
運用とメンテナンス中に、Manbang Group の学生は、自社構築した Eureka クラスター内のサービス登録インスタンスの数が 2000 以上に達すると、Eureka クラスター ノード間のインスタンス登録情報の同期により、一部のノードがそれを処理できなくなることに気づきました。ノードがサービスを提供できず、最終的に障害が発生するという問題が発生します。さらに、ZooKeeper には認証と ID 認証がないため、ZooKeeper クラスター内で頻繁に GC が発生し、全体的な安定性に影響を及ぼします。デフォルトで有効になっている機能では、構成ストレージはセキュリティのリスクに直面しており、これらの問題はビジネスの安定的かつ永続的な発展にも大きな課題をもたらします。
ビジネスアーキテクチャのスムーズな移行
上記のビジネス背景の下、Manbang の学生は、 Alibaba Cloud MSE Nacos および MSE ZooKeeper 製品を使用して、元の Eureka クラスターと Zookeeper クラスターを置き換えることで、緊急にクラウドに移行することを選択しました。しかし、低コストで迅速なアーキテクチャのアップグレードもどのように達成できるでしょうか。クラウド移行中のビジネスとして、ロスレスでスムーズなトラフィックの移行についてはどうですか?
この問題に関して、MSE Nacos は、オープン ソースの Eureka ネイティブ プロトコルとの完全な互換性を実現しています。カーネルは引き続き Nacos によって駆動され、Eureka InstanceInfo データ モデルと Nacos データ モデル (サービスとインスタンス) を 1 つずつマッピングします。 Manbang Group が自社構築した Eureka クラスターを引き継いだことは、ビジネス関係者にはすべて完全に透過的です。
つまり、元のビジネス側をコード レベルで変更する必要はなく、Eureka Client によって MSE Nacos のエンドポイントに接続されているサーバー インスタンスのエンドポイント構成を変更するだけで済みます。また、使用方法も非常に柔軟です。ネイティブ Eureka プロトコルを引き続き使用して MSE Nacos インスタンスを Eureka クラスタとして使用することも、Nacos と Eureka クライアントのデュアル プロトコルを使用して、異なるプロトコルのサービス登録情報を共存させることもできます。これにより、ビジネス マイクロサービス呼び出しの接続が確保されます。
さらに、クラウド移行プロセス中に、MSE は、オープンソース Nacos-Sync に基づく最適化された移行サポート データ同期ツールである MSE-Sync ソリューションを正式に提供しました。これは、双方向同期、自動プル サービス、およびワンクリックをサポートします。同期機能。 MSE-Sync を通じて、Manbang の学生は、オリジナルの自社構築 Eureka クラスター上の既存のオンライン サービス登録ストック データを、新しい MSE Nacos クラスターにワンクリックで簡単に移行できます。同時に、古いクラスターに新しく登録された増分データも移行できます。また、ワンクリックで移行することもでき、新しいクラスターに継続的かつ自動的に同期されるため、実際のビジネス フローの移行前に、両側のクラスター サービス登録インスタンス情報が常に完全に一致することが保証されます。データ同期チェックに合格したら、元の Eureka クライアント エンドポイント構成を置き換え、再公開してアップグレードし、新しい MSE Nacos クラスタに正常に移行します。
ネイティブ Eureka クラスター アーキテクチャのパフォーマンスのボトルネックを突破
Manbang Group が MSE チームの協力技術アーキテクチャのアップグレードを見つけたとき、最も重要な要求は、Eureka クラスタ間でサービス登録情報を同期するための高い負荷という元々の問題を解決することでした。これは、Eureka Server が従来のピアツーピア スターであるためです。同期 AP モデルでは、各サーバー ノードの役割は同等であり、各変更 (登録/登録解除/ハートビート更新/サービス ステータスの変更など) に対して、すべてのインスタンス データを同期するために対応する同期タスクが生成されます。このように、同期ジョブの量は、クラスターのサイズとインスタンスの数に直接相関して増加します。
実践を通じて、Manbang Group の学生は、クラスター サービスの登録規模が 2000 以上に達すると、一部のノードの CPU 占有率と負荷が非常に高く、時々死んだふりをしてビジネスの混乱を引き起こすことに気づきました。これは、Eureka の公式ドキュメントにも記載されていますが、オープンソース Eureka のブロードキャスト レプリケーション モデルは、それ自体のアーキテクチャ上の脆弱性を引き起こすだけでなく、クラスターの全体的な水平方向のスケーラビリティにも影響を与えます。
レプリケーション アルゴリズムによりスケーラビリティが制限される: Eureka はブロードキャスト レプリケーション モデルに従います。つまり、すべてのサーバーがデータとハートビートをすべてのピアにレプリケートします。これは、eureka に含まれるデータ セットにとっては簡単で効果的ですが、サーバーが受信するすべての HTTP 呼び出しをそのまますべてのピアに中継することによってレプリケーションが実装されます。すべてのノードが eureka への書き込み負荷全体に耐える必要があるため、これによりスケーラビリティが制限されます。
MSE Nacos は、アーキテクチャの選択時にこの問題を考慮し、スター型同期モデルを保持することに基づいて、すべてのサービスのハッシュ ハッシュと論理データを登録する、より良い解決策を提供しました。シャーディングが実行され、クラスター責任ノードが各サービス インスタンス データに割り当てられます。各サーバー ノードは、データの独自の部分の同期と更新ロジックのみを担当します。同時に、クラスター間のデータ同期の粒度は高くなります。比較的エウレカも小さいです。この利点は、大規模なデプロイメントや大規模なサービス インスタンス データでも、クラスター間の同期タスクの量が比較的制御可能であり、クラスター サイズが大きくなるほど、このモデルによってもたらされるパフォーマンスの向上が明らかであることです。
継続的な反復最適化により究極のパフォーマンスを追求
MSE Nacos と MSE ZooKeeper は、Manbang Group の完全なマイクロサービス登録センター ビジネスを完了した後、その後のアップグレード バージョンで反復的な最適化を継続し、多数のパフォーマンス ストレス テストの比較テストを通じてサーバーのパフォーマンスを細部まで最適化し続けました。ビジネス経験に基づいて、アップグレード バージョンの最適化ポイントを分析して 1 つずつ導入します。
サービス登録の高可用性災害復旧保護
ネイティブ Nacos は、プッシュ保護という高レベルの機能を提供します。サービス利用者 (Consumer) は、登録センターが変更された場合や緊急事態が発生した場合、サービス プロバイダー (プロバイダー) のインスタンス リストに登録します。登録センター ネットワーク、CPU、その他の要因によりセンター間のリンクが不安定になると、サブスクリプション例外が発生し、サービス コンシューマーが空のサービス プロバイダー インスタンス リストを取得する可能性があります。
この問題を解決するには、Nacos クライアントまたは MSE Nacos サーバーでプッシュ保護機能を有効にして、システム全体の可用性を向上させることができます。また、この安定化機能を Eureka のプロトコル サポートに導入しました。MSE Nacos サーバーのデータが異常な場合、Eureka クライアントがサーバーからデータを取得するときに、デフォルトで災害復旧保護サポートが適用され、ビジネスでの使用が保証されます。これにより、期待を満たさないサービス プロバイダー インスタンスのリストが取得されなくなり、ビジネスの失敗が発生します。
さらに、MSE Nacos と MSE ZooKeeper は、複数の高可用性保証メカニズムも提供します。ビジネス側でより高い信頼性とデータ セキュリティの要件がある場合は、インスタンスの作成時に 3 つ以上のノードでデプロイすることを選択できます。いずれかのインスタンスに障害が発生した場合、ノード間の切り替えは数秒以内に完了し、障害が発生したノードは自動的にクラスターから離脱します。同時に、各 MSE リージョンには複数のアベイラビリティ ゾーンが含まれており、同じリージョン内の異なるゾーン間のネットワーク遅延は非常に小さい (3 ミリ秒以内)。アベイラビリティ ゾーン A に障害が発生した場合でも、マルチ アベイラビリティ ゾーン インスタンスはサービス ノードをデプロイできます。 、、トラフィックは短期間で別のアベイラビリティ ゾーン B に切り替えられます。ビジネス側はプロセス全体を認識しておらず、アプリケーションコードレベルも認識しておらず、変更は必要ありません。このメカニズムでは、マルチノード展開を設定するだけで済みます。MSE は、分散したディザスタ リカバリのために複数のアベイラビリティ ゾーンに展開するのに自動的に役立ちます。
データを段階的にプルするための Eureka クライアントのサポート
Manbang の学生が MSE Nacos に移行した後、サーバー インスタンスが停止してサービスを提供できないという当初の問題はうまく解決されましたが、コンピューター ルームのネットワーク帯域幅が高すぎて、帯域幅がいっぱいになる場合があることが判明しました。サービスのピーク時間帯。その後、その理由は、Eureka クライアントが MSE Nacos からサービス登録情報を取得するたびに完全な取得のみをサポートしており、数千レベルのデータが定期的に取得されるため、FGC の数が増加したためであることが判明しました。ゲートウェイレベルがたくさんあります。
この問題を解決するために、MSE Nacos は、クライアントの使用量の調整と併せて、Eureka サービス登録情報の増分プル メカニズムを開始しました。クライアントは、最初の起動後に全量のデータを 1 回だけプルするだけで済み、その後は 2 回だけプルするだけで済みます。増分データに基づいて全量のデータをプルする必要がある。ローカル データとサーバー データの一貫性を維持するために使用され、定期的なフルスケールのプルは必要なくなります。通常の運用環境では、変更される増分データの量は非常に多くなります。これにより、エクスポート帯域幅への圧力が大幅に軽減されます。この最適化されたバージョンにアップグレードした後、Manbang の学生は、帯域幅がアップグレード前の 40MB/s から 200KB/s に突然低下し、全帯域幅の問題が解決されたことに気付きました。
サーバーのパフォーマンスを最適化するための完全なストレス テスト
その後、MSE チームは、MSE Nacos クラスター For Eureka シナリオに対して大規模なパフォーマンス ストレス テストを実施し、さまざまなパフォーマンス分析ツールを使用してビジネス リンク上のパフォーマンスのボトルネックを特定し、さらなるパフォーマンスの最適化と元の機能の最適化を実施しました。レベルのパフォーマンスパラメータの調整。
- サーバー側の完全および増分データ登録情報にはキャッシュが導入されており、変更が発生したかどうかはサーバー側のデータ ハッシュに基づいて判断されます。 Eureka サーバーが読み取りを増やし、書き込みを減らすシナリオでは、返される結果を生成するための CPU 計算のパフォーマンス オーバーヘッドを大幅に削減できます。
- SpringBoot のネイティブ StringHttpMessageConverter には、大規模なデータ リターンを処理する際にパフォーマンスのボトルネックがあることが判明し、文字列データの IO 送信パフォーマンスを最適化するために EnhancedStringHttpMessageConverter が提供されました。
- サーバー側のデータ返しはチャンク化をサポートします。
- Tomcat スレッド プールの数は、コンテナーの構成に応じて適応的に調整されます。
Manbang Group が上記のバージョンの反復アップグレードを完了した後、サーバー側のさまざまなパラメーターも優れた最適化結果を達成しました。
サーバーの CPU 使用率が 13% から 2% に低下
登録センターの RT 読み取り値は、元の 55 ミリ秒から 3 ミリ秒未満に短縮されました。
サーバー側の YGC 数が元の 10 以上から 1 に減少しました
YGC 時間が元の 125 ミリ秒から 10 ミリ秒未満に短縮されました
バイパスの最適化により、高圧下でもクラスターの安定性が確保されます。
Manbang の学生が一定期間 MSE ZooKeeper に移行した後、クラスター内で再びフル GC が発生し、クラスターが不安定になりました。MSE の緊急調査の結果、その原因は、メトリックの監視関連の統計指標であることが判明しました。 ZooKeeper は計算中に現在のノードに保存され、監視データは完全なギャング シナリオでは非常に大きくなり、このようなシナリオではメトリクス計算のコピー監視によって大量のメモリ フラグメントが生成されます。最終クラスターは適格なメモリ リソースを割り当てることができず、最終的にはフル GC になります。
この問題を解決するために、MSE ZooKeeper は、重要でないメトリックに対してダウングレード措置を講じ、これらのメトリックがクラスターの安定性に影響を与えないようにするとともに、データ コピーの計算によって引き起こされるメモリの断片化の問題を回避するために動的取得戦略を採用します。この最適化を適用すると、クラスターの Young GC 時間と数が大幅に減少します。
最適化後、クラスターは 200W QPS をスムーズに処理でき、GC は安定しています。
継続的なパラメーターの最適化により、レイテンシーとスループットの間の最適なバランス ポイントを見つけます。
Manbang の学生が、自作の ZooKeeper を MSE ZooKeeper に移行した後、アプリケーションがリリースされたとき、クライアントによる ZooKeeper のデータ読み取りの遅延が大きすぎ、アプリケーションの起動時に設定の読み取りがタイムアウトになり、アプリケーションの起動タイムアウトが発生することがわかりました。この問題を解決するために、MSE ZooKeeper の対象を絞ったストレス テスト分析により、フルサービス シナリオでは、アプリケーションのリリース時に ZooKeeper が大量のリクエストを処理する必要があり、リクエストによって生成されたオブジェクトが既存のシステムで頻繁な Young GC を引き起こすことが示されました。構成。
このシナリオに対応して、MSE チームは、遅延要件を満たすことを前提として、複数回のストレス テストを通じてクラスター構成を調整し、リクエスト遅延と TPS の間の最適な交差点を見つけました。クラスターの毎日 10w QPS レベルでは、20 ミリ秒のリクエスト遅延が保証され、CPU が 20% から 5% に削減され、クラスターの負荷が大幅に軽減されます。
追記
デジタル貨物業界の熾烈な競争と急速な技術開発を背景に、Manbang Group は独自の技術アーキテクチャのアップグレードに成功し、自社構築の Eureka 登録センターからより効率的で安定した MSE Nacos プラットフォームへスムーズに移行しました。これは、マンバングループの技術革新と事業拡大に対する確固たる決意を示すだけでなく、将来の発展に向けた広範な計画を示すものでもあります。 Manbang Group は、マイクロサービス アーキテクチャの安定性と高性能をデジタル変革の中核と考えています。新しい登録センター アーキテクチャによってもたらされる大幅なパフォーマンスの向上と安定性の強化により、Manbang プラットフォームが成長するビジネスにさらに対応できるようになります。要求を満たし、将来発生する可能性のあるあらゆる課題に対処する力を持っています。
移行プロセス全体にわたる Manbang Group の機敏な対応と技術チームの専門的な実行により、アーキテクチャのアップグレードのペースも加速したことは言及する価値があります。ビジネスプラットフォームの変革の成功は、マンバンのサービスに対するユーザーの信頼を高めるだけでなく、他の企業にも貴重な経験を提供します。今後もマンバンはMSEと緊密に連携し、技術アーキテクチャの安定性、拡張性、パフォーマンスをさらに向上させ、業界のベンチマークを設定し続け、物流業界全体のデジタル変革を推進していきます。
この移行プロセスでは、ビジネスを損失なくスムーズに移行でき、パフォーマンスが大幅に向上しました。これは、サービス登録センターの分野における MSE の優れたパフォーマンスと信頼性を証明しました。 MSE の継続的な進化により、その使いやすさと安定性の継続的な追求は間違いなくより多くの企業に大きな商業的価値をもたらし、企業のデジタル化プロセスにおいてますます重要な役割を果たすことになると私は信じています。
さらに、MSE は、トラフィック保護、フルリンク グレースケール リリースなどのマイクロサービス ガバナンス機能も完全にサポートします。エントランスゲートウェイからバックエンドまで完全に構成された電流制限ルールを適用することで、突然のトラフィックによって引き起こされるシステム安定性リスクが効果的に解決され、システムの継続的かつ安定した運用が確保され、企業はコアビジネスの開発にさらに集中できるようになります。マンバングループの成功事例は、業界に新たなマイルストーンを打ち立てました。より多くの企業がデジタル化への取り組みでさらに輝かしい成果を達成することを期待しています。
Manbang CTO Wang Dong (Dongtian) からのメッセージ:クラウドの機能を十分に理解して活用することで、Manbang 技術チームは下位レベルでの継続的な投資から解放され、より高いレベルのシステムの安定性とエンジニアリング効率に集中し、より良い結果を達成することができます。アーキテクチャレベルが高い。
おすすめのアクティビティ:
Feitian Technology Salon の最初の AI ネイティブ アプリケーション アーキテクチャ セッションに登録するには、ここをクリックしてください。
マイクロソフトの中国AIチームは数百人を巻き込んで米国に渡ったが、 未知のオープンソースプロジェクトはどれだけの収益をもたらすことができるだろうか? 華中科技大学のオープンソースミラーステーション の立場が調整されたとファーウェイが正式に発表した。 外部ネットワークへのアクセスを正式にオープンしました。 詐欺師は TeamViewer を使用して 398 万件を転送しました。リモート デスクトップ ベンダーは何をすべきでしょうか? 初のフロントエンド視覚化ライブラリであり、Baidu の有名なオープンソース プロジェクト ECharts の創設者である - 有名なオープンソース企業の元従業員が「海に行った」というニュースを伝えた: 部下からの挑戦を受けて、技術者はリーダーは激怒し、無礼になり、妊娠中の女性従業員を解雇しました。OpenAI が AI にポルノ コンテンツを生成させることを検討したと 、Rust Foundation に報告されました。time.sleep (6) の役割を教えてください。 ?