Javaベースの分散サービスフレームワークDubboの原理と事例分析-＆＃＆チュートリアル-php.cn

まえがき

Dubbo を紹介する前に、まず基本的な概念を理解しましょう:

Dubbo は RPC フレームワークです。 .RPC、つまり Remote Procedure Call (リモートプロシージャコール)、その反対はローカルプロシージャコールです。分散アーキテクチャが登場する前は、シングルアプリケーションアーキテクチャと垂直アプリケーションアーキテクチャでローカルプロシージャが使用されていました。電話。これにより、プログラマがリモート呼び出しの詳細を明示的にコーディングすることなく、プログラムが別のアドレス空間 (通常はネットワーク上で共有される別のマシン) にあるプロシージャまたは関数を呼び出すことができます。

分散アーキテクチャアプリケーション間のリモート呼び出しには、RPC フレームワークが必要です。目的は、リモート呼び出しをローカル呼び出しと同じくらい単純にすることです。

Javaベースの分散サービスフレームワークDubboの原理と事例分析

Dubbo フレームワークには次のコンポーネントがあります

Consumer

つまり、リモートサービスを呼び出すサービスコンシューマです。インターフェイスプログラミングでは、どのインターフェイスを呼び出すことができるかを知っています。特定の実装では、フレームワークがインターフェイスの特定の実装を提供するプロキシクラスを提供する必要があるため、コンシューマはどのインターフェイスを呼び出すだけで済み、特定の実装の取得はによって処理されます。プロキシクラス。

コンシューマは、呼び出しメソッド名とメソッドパラメータ値も指定する必要があります。

しかし、プロキシクラスは、この時点でサーバー上のどのリモートメソッドを呼び出す必要があるのかをまだ認識していません。この時点で、呼び出すことができるリモートサービスのリストを取得するために登録センターが必要です。

リモートサーバーは通常、クラスター内に展開されるため、どのサーバーを呼び出すかについては、呼び出すのに最適なサーバーを選択するために負荷分散が必要です。

同時に、クラスターのフォールトトレラントメカニズムも必要です。さまざまな理由により、リモート呼び出しが失敗する可能性があります。このとき、安定性を確保するために呼び出しを再試行するには、フォールトトレラントメカニズムが必要です。リモート通話の。

同時に、通信とデータ送信を容易にするために、通信プロトコルとシリアル化形式がサービスプロバイダーと合意されます。

プロバイダー

つまり、サービスを公開するサービスプロバイダーです。サービスプロバイダーは、特定のインターフェイスを内部で実装し、そのインターフェイスを公開して、登録センターにサービスを登録します。サービスコンシューマはサービスを呼び出します。プロバイダは呼び出しリクエストを受信すると、合意された通信プロトコルを通じてリクエストを処理し、デシリアライズします。完了後、リクエストをスレッドプールに入れて処理します。スレッドはリクエストを受信し、対応するインターフェイス実装呼び出しを行い、呼び出しの結果を返します。

レジストリ

サービスの登録と検出のための登録センターです。登録センターは、サービスディレクトリに相当するサービスアドレスの登録と検索を担当します。サービスプロバイダーと消費者開始時にのみ相互に登録されます。センターの対話、登録センターはリクエストを転送せず、プレッシャーは低いです。

Javaベースの分散サービスフレームワークDubboの原理と事例分析

#レジストリは、構成処理を一元化し、サブスクライバに変更を動的に通知することもできます。

しかし、なぜ登録センターが必要なのでしょうか?登録センターがないと無理なのでしょうか？

登録センターがない場合、サービス間の呼び出し関係は次のようになります。

Javaベースの分散サービスフレームワークDubboの原理と事例分析

サービスが増えると、サービス URL 構成管理が必要になります。ハードウェアロードバランサーへのシングルポイントプレッシャーも高まっています登録センターを利用することでサービスの一元管理、ソフトロードバランシングの実現、ハードウェアコストの削減が可能となります。登録センターの概略図:

Javaベースの分散サービスフレームワークDubboの原理と事例分析

Monitor

は、サービスのコール数とコール時間をカウントする監視センターです。洗練された監視と便利な操作とメンテナンスが不可欠であり、これは後のメンテナンスにとって非常に重要です。

Container

は、サービスが実行されるコンテナです。

#アーキテクチャ

Javaベースの分散サービスフレームワークDubboの原理と事例分析

図内の各ノードが果たす役割を紹介しました。各ノード間の呼び出し関係は次のとおりです:

コンテナ サービスコンテナは、起動、読み込み、実行を担当します。

プロバイダサービスプロバイダプロバイダサービスプロバイダが起動するときは、次のことを行う必要があります。リモートサーバーは、提供するサービスを検出し、Registry 登録センターに登録できます。

コンシューマサービスコンシューマが開始されると、# に登録されます。 ##Registry 登録センター。必要なサービスへの加入

Registry

登録センターは、サービスプロバイダーのリストを消費者に返します。同時に、変更が発生した場合は、登録センターは、長時間の接続に基づいてリアルタイムデータを消費者にプッシュします<p>サービスコンシューマがリモートサービスを呼び出す必要がある場合、ロードバランシングアルゴリズムに基づいて、プロバイダのアドレスリストからプロバイダサーバーを選択して呼び出します。呼び出しが失敗した場合、クラスタのフォールトトレランスに基づいて呼び出しが再試行されます。戦略</p> <p>サービス利用者とプロバイダーは、メモリ内の呼び出し数と呼び出し時間をカウントし、そのデータを <code>Monitor監視センター

高可用性

#に送信します。

##監視センターがダウンしても、サービスには影響しませんが、一部の統計データは失われます。
センタークラスターの登録後他の登録センターに自動的に切り替える
すべての登録センターがダウンした場合でも、サービスプロバイダーとコンシューマはローカルキャッシュを介して通信できます。お互いの情報を記録しますが、一方が変更を加えた場合、もう一方はそれを検出できません。
サービスプロバイダーはステートレスです。サーバーがダウンしても、サーバーには影響しません。サービスを提供する他のサービスプロバイダーがあります
すべてのサービスプロバイダーがダウンすると、サービスコンシューマは通常どおりに使用できなくなり、サービスプロバイダーが再接続して回復するまで無期限に再接続することになります。

フレームワーク設計

Javaベースの分散サービスフレームワークDubboの原理と事例分析

主な層は、ビジネス (ビジネスロジック層)、RPC 層、およびリモート層です。

さらに細分化すると、Dubbo には合計 10 層のアーキテクチャがあり、その機能は次のとおりです。

サービス、ビジネス層、つまりビジネスロジック日常の開発におけるレイヤー

Config、構成レイヤー、ServiceConfig と ReferenceConfig を中心とする外部構成インターフェイスは、構成クラスを直接初期化できます。または、構成クラス

Proxy、サービスプロキシ層、サービスインターフェイス透過プロキシ、サービスクライアント Stub およびクライアント Skeleton を生成する Spring の構成解析を通じて生成できます。 、リモート呼び出しと返される結果を担当します。

Registry、登録センター層は、サービス URL を中心として、サービスアドレスの登録と検出をカプセル化します。インターフェイスは RegistryFactory、 Registry、RegistryService

Cluster ルーティングおよびクラスターのフォールトトレランス層は、ルーティング、負荷分散をカプセル化します。複数のプロバイダーのクラスターフォールトトレランスと、登録センターのブリッジを行います。ロードバランシングを通じて呼び出す特定のノードの選択、特別な呼び出しリクエストの処理、およびリモート呼び出しの失敗に対するフォールトトレランス措置を講じます。

Monitor、監視層、RPC 呼び出しの数と呼び出し時間の監視とカウントを担当します

Portocol、リモート呼び出し層、主に RPC リモート呼び出しメソッド

Exchange、要求応答モデルのカプセル化に使用される情報交換層

Transport、ネットワークトランスポート層、抽象ネットワーク送信統合インターフェイス、Mina と Netty が利用可能です

# Serialize

(シリアル化レイヤー) は、送信のためにデータをバイナリストリームにシリアル化し、データを逆シリアル化して受信することもできますサービス公開プロセス

最初にプロバイダーが開始され、プロキシエージェントを通じてプロトコルが必要になります。公開されたインターフェイスは、実行可能本体である Invoker にカプセル化され、次に Exporter を通じてパッケージ化されて送信されます。登録センターに送信して登録を完了すると、サービスが公開されます。

#サービス利用プロセス Javaベースの分散サービスフレームワークDubboの原理と事例分析

注: 上の図の青い部分はサービス利用者、緑の部分はサービス利用者です。部分はサービスプロバイダーです。 Javaベースの分散サービスフレームワークDubboの原理と事例分析

サービスコンシューマが開始すると、登録センターをサブスクライブし、必要なサービスプロバイダー情報を取得し、それをローカルキャッシュに保存します。したがって、すべての登録センターがダウンしている場合でも、サービスプロバイダーとサービスはローカルキャッシュを介して通信することもできますが、一方が情報に変更を加えた場合、もう一方はそれを検出できませんが、サービスの進行には影響しません。

その後、サービス消費プロセス全体が図のプロキシから開始され、プロキシクラスによって処理され、透明性と認識性が実現されます。

ProxyFactory

Proxy プロキシクラスを生成します。プロキシは、Invoker 実行可能オブジェクトを保持します。invoke を呼び出した後、Cluster を渡す必要があります。 Directory からすべての呼び出し可能なリモートサービス呼び出し元のリストを取得します。特定のルーティングルールが設定されている場合は、呼び出し元リストを再度フィルターする必要があります。 残りの呼び出し元は、LoadBalance

を通じてロードバランシングのために選択され、一部のデータ統計はフィルターを通じて実行する必要があります。その後、データが保存されて

Monitor# に送信されます。定期的に。＃＃。次に、データ送信には Client を使用します。通常は

Netty

を使用して送信します。送信には、Codec インターフェイスを介したプロトコル構築、次に

Serialization

を介したシリアル化が必要で、最後にシリアル化されたバイナリストリームが対応するサービスプロバイダー By に送信されます。 <p>バイナリストリームを受信した後、サービスプロバイダーもコーデックプロトコル処理を実行し、デシリアライズ (ここでの処理は送信前の処理と対称です) してから、リクエストを処理のためにスレッドプールに入れます。リクエストに従って対応する <code>Exporter を呼び出し、それを Filter でレイヤーごとにフィルターして Invoker を取得し、最後に対応する実装クラスを呼び出して元の方法で結果を返します。

以上がJavaベースの分散サービスフレームワークDubboの原理と事例分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。