コアな Java テクノロジーを共有し、金と釣りを共有する男、Wang Youzhiに注目してください。バケツを持って走り回る Java 人のグループに
参加してください。一緒に裕福な Java 人
新しいピットを開いて、みんなと一緒にDubbo 3.Xを学びましょう。Dubbo の使用から始めて、Dubbo の核となる原則を掘り下げて、浅いものから深いものの順に学習します。
今日は Dubbo について知ることから始めます。全体的な内容は 3 つの部分に分けることができます。
-
ダボとは
-
RPCとは
-
ダボの建築
正式にスタートする前に一言しておきますが、通常、インターネット上の多くの資料では、プロトコルとして RPC を参照したり、RPC を HTTP と比較したりすることが多く、現在ではこれが「正しくない」ものの主流となっています。私は個人的に原理主義者であり、RPC の独自の解釈を使用することを好むため、これまでにご覧になった記事の一部とは異なる可能性があります。また、個人の能力には限界があるため、間違いがあれば、遠慮なくご指摘いただければ幸いです。
ヒント: RPC の章では主に、Andrew D. Birrell と Bruce Jay Nelson が発行した論文「[Implementing Remote Procedure Calls] (https://flowus.cn/chang/share/6ec29968-8c6b-465e-bbdd-63fd29ad6825)」を参照しています。 1984年に
【FlowUs フロー】リモート プロシージャ コールの実装.pdf)」に記載されているこの記事が、一般に「現代の」RPC の起源であると考えられています (実際、RPC について議論し始めた文献は 1976 年にありました)。
ダボって何ですか?
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
として拡張インターフェイスはCluster
、、、、、です。Directory
Router
LoadBalance
-
監視監視層: RPC 呼び出し時間と呼び出し時間監視、センター
Statistics
を中心に、内線インターフェイスはMonitorFactory
、、、Monitor
MonitorService
-
プロトコル リモート呼び出し層: を中心とした RPC 呼び出しをカプセル化し
Invocation
、Result
拡張インターフェイスはProtocol
、Invoker
、Exporter
-
交換情報交換層:カプセル化要求応答モード、同期から非同期、を中心とし、
Request
拡張Response
インターフェイスはExchanger
、、、ExchangeChannel
。ExchangeClient
ExchangeServer
-
トランスポートネットワークトランスポート層:MinaとNettyを
Message
中心とした、拡張インターフェースはChannel
、、、、、Transporter
Client
Server
Codec
-
データシリアル化レイヤー: いくつかの再利用可能なツール、拡張インターフェイスは
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 サービスを設計できます。サービスをスタブに保存する方法を検討する必要がありますか? インタラクションにはどちらの方法を使用しますか? インタラクティブなデータ構造はどのように設計すべきでしょうか?
次の記事では、Duubboを一緒に使ってDubboの応用をマスターしましょう。この記事が役に立った場合は、高評価をお願いします。最後に、皆さん、ハードコア テクノロジーを共有する金融漁師。また次回お会いしましょう!