ダボとrpcを知る

新しいピットを開いて、みんなと一緒にDubbo 3.Xを学びましょう。Dubbo の使用から始めて、Dubbo の核となる原則を掘り下げて、浅いものから深いものの順に学習します。

今日は Dubbo について知ることから始めます。全体的な内容は 3 つの部分に分けることができます。

ダボとは
RPCとは
ダボの建築

正式にスタートする前に一言しておきますが、通常、インターネット上の多くの資料では、プロトコルとして RPC を参照したり、RPC を HTTP と比較したりすることが多く、現在ではこれが「正しくない」ものの主流となっています。私は個人的に原理主義者であり、RPC の独自の解釈を使用することを好むため、これまでにご覧になった記事の一部とは異なる可能性があります。また、個人の能力には限界があるため、間違いがあれば、遠慮なくご指摘いただければ幸いです。

ヒント: RPC の章では主に、1984 年に Andrew D. Birrell と Bruce Jay Nelson によって出版された論文「 Implementing Remote Procedure Calls 」を参照しています。一般に、この記事が「現代の」RPC の起源であると考えられています (実際には、 1976 年以降の文書。RPC について議論)。

ダボって何ですか？

Apache Dubbo コミュニティがDubbo をどのように説明しているかを見てみましょう。

Apache Dubbo は、マイクロサービスアーキテクチャの下でサービスガバナンスと通信の問題を解決するために使用されるRPC サービス開発フレームワークであり、Java や Golang などの多言語 SDK 実装を正式に提供します。Dubbo を使用して開発されたマイクロサービスは、ネイティブのリモートアドレス検出機能と相互間の通信機能を備えており、Dubbo が提供する豊富なサービスガバナンス機能を使用して、サービスディスカバリ、ロードバランシング、トラフィックスケジューリングなどのサービスガバナンス要求を実現できます。Dubbo は拡張性が高いように設計されており、ユーザーはトラフィックの傍受や場所の選択のためのさまざまなカスタムロジックを簡単に実装できます。

Dubbo は、高いパフォーマンスとスケーラビリティを備えた RPC フレームワークであり、サービスガバナンス機能も提供します。

Dubbo の「野心」は、完全な RPC 呼び出しとサービスガバナンスフレームワークを提供するだけでなく、Dubbo をプログラミング言語から切り離し、ほとんどの主流言語のバージョンを提供することです。

ヒント: この写真は、ステーション B の Apache Dubbo コミュニティによって発行された「 Quick Understanding of Apache Dubbo in 5 Minutes」から引用したものです。

RPC とは何ですか?

Dubbo の本質は RPC フレームワークであるため、Dubbo について詳しく学ぶ前に、RPC とは何かを理解する必要があります。

RPC (Remote Procedure Call)、つまりリモートプロシージャコール。「リモートプロシージャコールの実装」は次のように説明されています。

リモートプロシージャコール (以下、RPC と呼びます) の考え方は非常にシンプルです。これは、プロシージャコールが、単一のコンピュータ上で実行されるプログラム内で制御とデータを転送するためのよく知られ、よく理解されているメカニズムであるという観察に基づいています。したがって、この同じメカニズムを拡張して、プログラムの転送を提供することが提案されています。通信ネットワークを介した制御とデータ。

RPC のアイデアは、スタンドアロンプログラムでデータを転送および処理するためのプロシージャコールの観察に基づいており、同じメカニズムをリモートネットワーク通信に拡張した結果を示唆しています。

ちょっとわかりにくいですか？それは問題ではありません。もっと簡単な方法で考えて、YouTube ビデオ「What is RPC? gRPC Introduction」で Sahn Lam が説明した説明を見てみましょう。ビデオの中で、彼はローカルプロシージャコールとリモートプロシージャコールを比較して説明しています。

ローカルプロシージャコールは、何らかのコードを実行するためのプロセス内の関数呼び出しです。リモートプロシージャコールを使用すると、ユーザーの観点からはローカル関数呼び出しであるかのように、あるマシンが別のマシン上で何らかのコードを呼び出すことができます。

この説明は非常に明確で、RPC の核心は、リモート呼び出しがローカル関数呼び出しと同じくらい単純であることを期待することです。この目標に基づいて、Birrell と Nelson は RPC サービスの設計リファレンスを提供しました。

Birrell と Nelson の設計はスタブ (スタブ、図のユーザースタブとサーバースタブ) の概念に基づいており、システム全体は次の 5 つの部分で構成されます。

クライアント、サービス呼び出し元。
ユーザー側のスタブ。関数宣言を保存し、リクエストパラメーターのパッケージ化と応答パラメーターのアンパックを担当します。
RPC ランタイム、データを送信するための適切な方法 (プロトコル) を選択します。
関数宣言を保存するサーバー側のスタブは、リクエストパラメータのアンパックとレスポンスパラメータのパッケージ化を担当します。
サーバー、サービスプロバイダー。

クライアント側とサーバー側の開発者は、ターゲット関数が配置されているサーバーのアドレスやデータの送信方法を考慮することなく、スタブからターゲット関数を取得して呼び出すだけで済みます。これは、「」のビジョンに非常に適しています。リモート呼び出しはローカル関数呼び出しと同じくらい簡単です。」

さて、ここで「原理主義的な」RPC について全体的に理解しました。ここで、あまり「深刻ではない」質問に答えます。HTTP があるのに、なぜ RPC が必要なのでしょうか?

これは、RPC と HTTP を同一視する、初心者にとって非常によくある誤解です。まず、RPC はアイデア (リモートサービス呼び出しを簡略化するという目的に近いと思います) であり、HTTP はアプリケーション層の送信プロトコルであり、上図の「2 つ」の RPC ランタイムは送信時に HTTP を使用できます。データ、またはその他の方法でデータ転送が行われる方法。第二に、「現代の」RPC の理論は 1984 年に誕生し、HTTP は 1989 年に開始されたため、この質問を逆に問うのは少し合理的であるように思えます。最後に、HTTP の誕生の目的は、2 つのサーバー間のデータ伝送のアプリケーションではなく、HTML ページの受信と公開、つまりブラウザーとサーバー間のデータ伝送です。

ヒント：

Sahn Lam と Alex Xu は、43 万人のファンを持つ YouTube チャンネル ByteByteGo のマネージャーであり、「System Design Interview」の著者でもあります。
RPC システム設計図は、「リモートプロシージャコールの実装」から引用したものです。
実際のプロジェクトでは、クライアントとサーバーの間に厳密な区別はなく、サービスは外部インターフェイスを提供したり、外部サービスインターフェイスを使用したりできます。

ダボの建築

Dubbo 3.0 以降、Dubbo の公式ドキュメントでは新しい抽象アーキテクチャが使用されています。

Dubbo は全体から 2 つの層に分かれています。

Dubbo データプレーン: RPC 機能のコア部分を提供し、RPC プロトコルを介して通信し、呼び出し仕様を定義し、データ対話のエンコードおよびデコード機能を完了します。
サービスガバナンスコントロールプレーン: 登録センター、トラフィック制御戦略、Dubbo 管理コンソールなどを含むサービスガバナンスの抽象化。

Dubbo 3.0 の前に、公式は Dubbo 2.X の非常に複雑な設計図を提供しました (次の部分は公式テキストです)。

図

図中左側の水色の背景がサービス利用者が利用するインターフェース、右側の薄緑色の背景がサービス提供者が利用するインターフェース、中心軸にあるのがサービス提供者が利用するインターフェースです。双方が使用するインターフェース。
図は下から上に10層に分かれており、各層は一方向の依存関係となっている、右側の黒い矢印は各層間の依存関係を表している、各層は上位層を剥がすことで再利用できる、その中でServiceと構成レイヤーは API であり、他のすべてのレイヤーは SPI です
図中の小さな緑色のブロックは拡張インターフェイス、小さな青いブロックは実装クラスであり、図には各層を関連付けるために使用される実装クラスのみが示されています。
図中の青い点線は初期化処理、つまり起動時のアセンブリチェーン、赤い実線はメソッド呼び出し処理、つまり実行時のタイミングチェーン、紫色の三角矢印は継承であると考えられます。サブクラスは親クラスの同じノードであり、上記のテキストは呼び出すメソッドです。

Dubbo は非常に豊富なインターフェイスを提供します。これらはユーザーがカスタマイズできる Dubbo の拡張ポイントです。Dubbo 自体も Microkernel+Plugin (マイクロカーネル + 拡張) モデルを採用しており、Microkernel は Dubbo のデフォルトの Plugin 実装をアセンブルすることのみを担当します。

各レイヤーの説明

config 構成レイヤー: ServiceConfig と ReferenceConfig を中心とする外部構成インターフェイス。構成クラスを直接初期化することも、Spring の構成解析を通じて構成クラスを生成することもできます。
プロキシサービスプロキシ層: サービスインターフェイスの透過プロキシ。ServiceProxy を中心として、拡張インターフェイスを ProxyFactory として、サービスクライアントスタブとサーバースケルトンを生成します。
レジストリ登録センター層: サービス URL を中心としたサービスアドレスの登録と検出をカプセル化し、拡張インターフェイスは RegistryFactory、Registry、RegistryService です。
クラスタールーティング層: 複数のプロバイダーのルーティングとロードバランシングをカプセル化し、Invoker を中心として登録センターをブリッジします。拡張インターフェイスはクラスター、ディレクトリ、ルーター、およびロードバランスです。
監視監視層：Statisticsを中心としたRPC呼び出し時間と呼び出し時間監視、拡張インターフェースはMonitorFactory、Monitor、MonitorService
プロトコルリモート呼び出し層: 呼び出しと結果を中心とした RPC 呼び出しをカプセル化します。拡張インターフェイスはプロトコル、呼び出し元、エクスポーターです。
Exchange 情報交換層: カプセル化要求応答モード、同期から非同期、要求と応答を中心とし、拡張インターフェイスは Exchanger、ExchangeChannel、ExchangeClient、ExchangeServer
トランスポートネットワークトランスポート層:MinaとNettyを統合インターフェースとして抽象化し、メッセージを中心とし、チャネル、トランスポーター、クライアント、サーバー、コーデックとして拡張インターフェースを備えます。
データシリアル化レイヤー: いくつかの再利用可能なツール、拡張インターフェイスは Serialization、ObjectInput、ObjectOutput、ThreadPool です。

一部の記事ではサービスを Dubbo の階層構造に組み込んでいますが、実際にはサービスはユーザーのビジネスロジックの一部であり、厳密な意味での Dubbo 自体のコンポーネントではありません。

サポート契約

プロトコルは、データ送信形式を定義する RPC フレームワークの中核機能であり、データそのものに加えて、シリアル化方法、タイムアウト時間などの制御情報も含まれる必要があります。

Dubbo は多くのプロトコルをサポートしていますが、ここではそれらを 5 つのカテゴリに分類します。

Dubbo は多くのプロトコルをサポートしていますが、各プロトコルを詳しく調べる必要はありません。今後、プロトコルを学習する際には、Dubbo プロトコル、Dubbo 3.X が推進する Triple プロトコル、HTTP/2 をサポートする gRPC に焦点を当て、残りのプロトコルの特徴を理解するだけで済みます。。

ヒント: 実は、Dubbo 2.X の公式ドキュメントには非常に詳細な設計ドキュメントが存在しますが、なぜこの部分が Dubbo 3.0 で削除されたのかはわかりません。

エピローグ

さて、ここまでで Dubbo のデザインについて全体的に理解していただけたと思います。設計は複雑で、サポートされているプロトコルも多数ありますが、今日の私たちの目標は「すべてを理解する」ことではありません。私たちは主に RPC と Birrell と Nelson によって与えられた設計を理解することに焦点を当てますが、次に、Dubbo の設計の全体的な理解を確立し、Dubbo が Birrell と Nelson に基づいてどのような拡張を行ったかを確認する必要があります。興味があれば、Birrell と Nelson が提供したアーキテクチャを参照して、独自の RPC サービスを設計できます。サービスをスタブに保存する方法を検討する必要があります。インタラクションにはどちらの方法を使用しますか? インタラクティブなデータ構造はどのように設計すべきでしょうか?

この記事が役に立った場合は、たくさんの賞賛とサポートをお願いします。記事に間違いがあった場合は、批判と修正をお願いします。最後に、皆さんもぜひ、ハードコア Java テクノロジーを共有する金融マン。