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

まえがき

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

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

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

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

Consumer

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

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

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

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

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

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

プロバイダー

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

レジストリ

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

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

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

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

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

Monitor

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

Container

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

#アーキテクチャ

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

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

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

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

Registry

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

高可用性

#に送信します。

• ##監視センターがダウンしても、サービスには影響しませんが、一部の統計データは失われます。

• センター クラスターの登録後他の登録センターに自動的に切り替える

• すべての登録センターがダウンした場合でも、サービス プロバイダーとコンシューマはローカル キャッシュを介して通信できます。お互いの情報を記録しますが、一方が変更を加えた場合、もう一方はそれを検出できません。

• サービス プロバイダーはステートレスです。サーバーがダウンしても、サーバーには影響しません。サービスを提供する他のサービス プロバイダーがあります

• すべてのサービス プロバイダーがダウンすると、サービス コンシューマは通常どおりに使用できなくなり、サービス プロバイダーが再接続して回復するまで無期限に再接続することになります。

フレームワーク設計

主な層は、ビジネス (ビジネス ロジック層)、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 を通じてパッケージ化されて送信されます。登録センターに送信して登録を完了すると、サービスが公開されます。

#サービス利用プロセス

注: 上の図の青い部分はサービス利用者、緑の部分はサービス利用者です。部分はサービスプロバイダーです。

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

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

ProxyFactory

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

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

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

Netty

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

Serialization

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

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