MSE 自律サービスは、Dubbo の重複サブスクリプションによって引き起こされる RPC サービス登録の失敗の問題を迅速に特定して解決するのに役立ちます

15159205:

作者: ジクイ

バックグラウンド

Dubbo は、マイクロサービス アーキテクチャの下でサービス ガバナンスと通信の問題を解決するために使用される RPC サービス開発フレームワークであり、使いやすさ、超大規模なマイクロサービスの実践、クラウド ネイティブのインフラストラクチャへの適応、およびセキュリティの特徴を備えていますただし、Dubbo の使用姿勢が正しくないと、Dubbo アプリケーションと ZooKeeper 登録センターで安定性の問題が発生する可能性があります。最近、最前線の顧客がリリースすると、Dubbo Reference の繰り返しの初期化が原因で ZooKeeper が利用できなくなり、サービス登録のサブスクリプションが失敗し、ビジネスの大部分が失敗します。

ZooKeeper 例外ログ ↓

画像

画像.png

また、ZooKeeper クラスターは引き続き利用できないため、自動的に修復できません。

原因分析

Dubbo Reference は、Dubbo フレームワークの呼び出し元におけるサービス プロバイダーのプロキシ実装です。Dubbo Reference を初期化すると、コンシューマ自体がサブスクライブされたサービスのコンシューマ リストに登録されます。複数の同じインターフェイスがアプリケーション Dubbo Reference でインスタンス化される場合、その場合、ZooKeeper 内の対応するサブスクライブ済みサービス コンシューマー リストにも、このアプリケーションのサブスクリプションによって生成された複数の Znode ノードが含まれ、これらの Znode ノードのパスは、タイムスタンプ フィールドを除いて一貫しています。

画像

画像

Dubbo 自体はこのように実際のサブスクリプション関係を表現しますが、クライアントがこれを誤って使用すると、Dubbo アプリケーション自体や ZooKeeper の安定性の問題が発生する可能性があります。

https://github.com/apache/dubbo/issues/4587

たとえば、Dubbo 2.7.9 より前のバージョンでは、アプリケーション内で同じインターフェイスを使用して複数の Dubbo Reference を初期化すると、メモリ オーバーフローが発生する可能性があります。

ZooKeeper クラスターについては、jute.maxbuffer のチューニングに関する前回の記事で、ZooKeeper サーバー間のデータ同期が実行されるときに、サーバー間の同期に使用されるデータ パケットのサイズがジュートの制限に従って厳密に検証されることが分析されています。 .maxbuffer. データパケットの制限を超えるとフォロワーとリーダー間の接続が切断されます。Dubbo Reference のアプリケーションが誤った使用により同じインターフェイスを継続的に初期化する場合、アプリケーションがクラッシュした後、アプリケーションによって作成された多数の一時ノードにより ZooKeeper クラスターがクラッシュし続けます。

トラブルシューティングと解決策

登録設定センターの場合

ZooKeeper を登録設定センターとして使用する場合、記事 jute.maxbuffer の提案に従ってパラメータ jute.maxbuffer の値を増やすことで問題を遅らせることができますが、問題を根本的に解決することはできません。MSE ZooKeeper は、クライアントの誤用や予期しない例外が発生した場合に、クライアントが同じコンシューマを繰り返し登録することを制限して、ZooKeeper クラスタの安定性を確保するために、このような問題に対応する電流制限メカニズムを特別に設計しました。 MSE ZooKeeper の観察 特定のアプリケーションの登録情報を簡単に確認できるシステムです。

MSE ZooKeeper を使用したトラブルシューティング手順:

画像.png

たとえば、アプリケーション テストの無理な初期化方法により、アプリケーションはインターフェイス com.demo.provider の Dubbo Reference の初期化を繰り返し、アプリケーションが起動してしばらくすると登録でエラーが報告されます。このとき、MSE はZooKeeper は、ZooKeeper サーバー自体の安定性を確保するために、このクライアントの登録動作を制限しています。現時点では、モニタリングとプッシュ トラック情報に基づいて、MSE コンソールで問題のあるアプリケーションのトラブルシューティングを行うことができます。

まず、MSE コンソールに対応するインスタンスの詳細ページに入り、[Observation Analysis] -> [Monitoring Center] -> [TopN Monitoring] を開きます。

画像.png

TopN監視でクライアントTPS TopNを通じてその期間に頻繁に書き込まれたSessionIdを見つけ、このSessionIdを使用してデータ管理→データトラックでSessionIdに対応するデータ操作レコードを問い合わせます。

画像.png

クエリ結果から、特定のマシンが複数のコンシューマ登録を実行したことがわかります。

画像

Dubbo アプリケーション自体の場合

Dubbo のバージョンを最新の安定版にアップグレードすると同時に、同一インターフェースの不要な複数の Dubbo Reference を減らすために、使用中の Dubbo Reference の初期化方法に注意する必要があります Dubbo Reference 自体は比較的重いため、複数の Dubbo Reference参照自体がマシン リソースを消費します。

要約する

通常のビジネス開発では、フレームワークの誤用やバグが原因で、ビジネスとビジネスが依存するミドルウェアの安定性を確保するには、トラブルシューティングを行い、原因を特定し、時間内に止血するための迅速な方法が必要です。MSE ZooKeeper が提供するのは、さまざまなデータ統計と集計機能は、ユーザーのトラブルシューティングの効率を向上させるのに役立ち、ZooKeeper のさまざまな使用シナリオに対する豊富な監視指標、Dragonwell JDK に基づく詳細な最適化、マルチアベイラビリティ ゾーンの災害復旧機能、自由な操作およびメンテナンス、高可用性、その他の機能により、ユーザーが安定した効率的なマイクロサービス アプリケーションを構築できるようになります。

Microservice Engine MSE 製品の詳細については、ここをクリックしてください。

{{名前}}
{{名前}}

おすすめ

転載: my.oschina.net/u/3874284/blog/8881799