Java Dubbo アーキテクチャの全体的な設計方法は何ですか?

#1. Dubbo 呼び出し関係の説明

##1.1 コンポーネント

主に次のとおりです4 つの部分で構成されます:

# プロバイダー: サービスを公開するサービスプロバイダー

プロトコル: プロバイダーとコンシューマー間のプロトコル対話データを担当します

サービス: 実際のビジネス サービス情報はインターフェイスと実装として理解できます
コンテナ: Dubbo の動作環境
#コンシューマ: リモート サービスを呼び出すサービス コンシューマ
プロトコル: プロバイダとコンシューマの間のプロトコル対話データを担当します
クラスター: プロバイダー側​​でリスト情報を認識します。
プロキシ: プロバイダーのサービス呼び出しプロキシとして理解でき、コンシューマーのインターフェイス呼び出しロジックを引き継ぎます。
● 登録: 登録センター。サービスの検出と登録に使用されます。ルーティング設定など。ワーク、プロバイダー、コンシューマーがここに登録されます
# モニター: 呼び出し頻度、成功数と失敗数など、プロバイダーとコンシューマーに関するデータ統計に使用されます。

1.2 開始

#● プロバイダー側​​が開始すると、コンテナーはサービス情報をロードし、プロトコルを介して登録センターに登録します。

#● コンシューマー側が開始すると、コンテナーは、プロバイダー リストをリッスンしてプロバイダー情報を取得し、プロバイダーが変更されると、登録センターを通じてコン​​シューマーにただちに通知されます。

# コンシューマーはプロキシ モジュールを通じてリクエストを開始します。

# コンシューマーはクラスター モジュールを使用して選択します。呼び出される実際のプロバイダー;
● コンシューマー コンシューマーのプロトコルを使用して、情報をプロバイダーに送信します。
# プロバイダーは、プロトコル モジュールを通じてコン​​シューマー情報を処理します。
# 最後に、プロバイダーのサービス ハンドル処理

2. 全体的な呼び出しリンク

説明: 薄緑色はサービス プロデューサーのスコープを表し、水色はサービス コンシューマーのスコープを表します。赤い矢印は呼び出しの方向を表します: ビジネス ロジック層 -> RPC 層 (リモート プロシージャ コール) -> リモート処理 (リモート データ送信)

全体的な呼び出しプロセスは次のとおりです。

#● コンシューマは Interface を通じてメソッドを呼び出し、統一されます コンシューマ側の Proxy に引き渡され、ProxyFactory を通じてプロキシ オブジェクトが作成されます ここでは jdk の javassist 技術が使用されます #これは、統合フィルタリング要求を行うために Filter モジュールに渡されます# 次に、最も重要な Invoker 呼び出しロジックです

○ Directory を通じて設定から情報を読み取り、最後に list メソッドを通じてすべての Invoker を取得します

○ Cluster モジュールを通じて、選択した特定のルーティング ルールに従って起動者リストを選択します。
○ LoadBalance モジュールを通じて、負荷分散ポリシーに従って、リクエストを処理する特定の起動者を選択します。
○ 実行中にエラーが発生した場合、再試行メカニズムが Consumer ステージで構成されている場合、実行は再試行されます。
# フィルターを使用して前後の実行関数をカプセル化し続けます。呼び出し側は特定の呼び出し側を選択します。 プロトコルを実行します。
# クライアントエンコードとシリアル化を実行し、データを送信します
# プロバイダーのサーバー層に到達して、受信したデータをデコードしてシリアル化します
# エクスポーターを使用してエグゼキューターを選択します
● フィルターにプロバイダー側​​の処理を実行させます
# Invoker を介してインターフェイスの特定の実装を呼び出し、その結果を返す
#3. Dubbo の全体的な設計

# 凡例:

## 図では、左側の水色の背景はサービス コンシューマが使用するインターフェイス、右側の薄緑色の背景はサービス コンシューマが使用するインターフェイスです。中心軸にあるインターフェースは、サービスプロバイダーとサービスプロバイダーの両方によって使用されます。

# 図は上から下まで 10 層に分かれており、各層は一方向の依存関係を持っています。右側の黒い矢印は層間の依存関係を示しています。各層は上位層から剥がして再利用できます。それら、Service 層と Config 層は API、他のすべての層は SPI

#● 図の緑のブロックは拡張インターフェイス、青のブロックは実装クラスです。図では、それぞれを関連付けるために使用される実装クラスのみを示していますレイヤー# 図中の青いブロックは 点線は初期化処理、つまり起動時のアセンブリチェーン 赤の実線はメソッド呼び出し処理、つまりランタイムコールチェーン 紫色の矢印は継承です。サブクラスは親クラスの同じノードとみなすことができます。行上のテキストは呼び出しメソッドです。

Dubbo ソース コードの全体的な設計は、呼び出しリンクと非常によく似ています。ただし、ここではインターフェイスの具体的な実装と、左側にさらに詳細な階層区分が表示されており、後続のソース コード分析では、より重要なモジュールの実装にも焦点を当てます。

以下は階層的な紹介です

1. ビジネス ロジック層
# サービス ビジネス層: インターフェイスや実装クラスなどのビジネス コードを含む
2. RPC 層: リモート プロシージャ コール層
# 構成設定層。 ServiceConfig と ReferenceConfig はコアであり、構成クラスを直接初期化したり、構成ファイルを解析したりできます
# プロキシ サービス エージェント層は、プロデューサかコンシューマかに関係なく、フレームワークによってプロキシ クラスが生成されます。プロセスは上位層とビジネス層に対して透過的です。 リモート呼び出しは影響を受けません。
# サービス URL をセンターとして、サービス アドレスの登録と検出をカプセル化する登録センター層です。
# クラスター ルーティング層 (クラスター フォールト トレラント層)、複数のプロバイダーにルーティングと負荷を提供します。バランスが取れており、Invoker を中心として登録センターをブリッジします。
# 監視層、RPC 呼び出し関連情報 (呼び出し数、障害状況など) を監視します。 、呼び出し時間、その他の統計情報はこの層で完成します
# プロトコル リモート RPC 呼び出しをカプセル化する呼び出し層は、サービス公開であろうとサービス参照であろうと、主な機能として Invoker のライフ サイクル全体を担当します。プロトコルの入口。Dubbo のすべてのモデルは呼び出し側に近づきます。
3. Rmoting 層: リモート データ送信層
#交換情報交換層、リクエストとレスポンス モードをカプセル化し、リクエストを同期から非同期に変換します
● トランスポート ネットワークのトランスポート層。Netty や mina などのネットワーク送信インターフェイスを 1 つのネットワークに統合します。 送信インターフェイス
# データ シリアル化層。フレームワーク全体でのデータ送信のシリアル化と逆シリアル化の管理を担当します。

以上がJava Dubbo アーキテクチャの全体的な設計方法は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。