Dubbo ソースコードの簡単な分析 (1) - RPC フレームワークと Dubbo | JD Cloud テクニカル チーム

1. RPC とは何ですか?

1.1 RPCの概念

RPC (リモート プロシージャ コール) は、ローカル サービス コールである LPC (ローカル プロシージャ コール) とは対照的に、リモート プロシージャ コールです。ローカル サービス コールは、より一般的に使用されます。たとえば、アプリケーションの内部プログラム (これはメソッドではなくプログラムであることに注意してください。プログラムにはメソッドが含まれています) は相互に呼び出します。これがローカル プロシージャ コールであり、リモート プロシージャ コールです。リモート プロシージャをローカルで呼び出すことを指します。

RPC フレームワークは、ローカル プロシージャを呼び出すのと同じくらい便利にリモート プロシージャをローカルで呼び出すのに役立ちます。

1.2 RPC と HTTP の関係

一言でまとめるとこうなります。

RPC は概念、http はプロトコルであり、http は Rpc の実装であると考えることも、Rpc には http が含まれると考えることもできます。平等ではなく包含と言っている理由は、Rpc には Dubbo などの多くのカスタム Tcp ベースのプロトコルもあり、私たちがよく rpc と呼ぶものは Http に加えて TCP ベースのカスタム プロトコルを指すためです。

1.3 RPC についての考え方

RPC と Http に関する関連記事はインターネット上に数多くありますが、RPC の概念を説明するとき、リモート実行の方法であると述べて、RPC には http が含まれると直接結論付ける人が多くいます。実際、この概念に従って考えると、HTTP が Rpc の実装であると結論付けることはできません。ユーザーの観点から見た http 呼び出しの方法は、そのメソッドを直接呼び出すことではなく、特定の方法で http リクエストを完了し、それをデータ送信のためにローカル クライアントに渡すことであるためです。

対照的に、Dubbo などの関連する Rpc フレームワークを使用している場合は、ローカル メソッドを呼び出すのと同じようにリモート メソッドを直接呼び出すことができます。HTTP 呼び出しメソッドは、メソッドではなく、サービス呼び出しとみなすことができます。

この記事の著者は RPC の使用経験があるはずなので、少し先入観があるように感じます。では、rpc と http の関係は何でしょうか? 私も長い間考えましたが、定義から始めるべきであることがわかりました。Rpc とは何かについて議論しているのですから、最も単純な定義をどうやって無視することができますか。

Remote Procedure Call"Procedure"Google 翻訳によると、これには次のような説明があります。程序、过程、步骤実際にはそうではありません方法(Method)。むしろ、程序それは包括的であり方法、同時に を含みます服务。したがって、これは方法ではなく手順またはプロセスであることが上記で強調されています。

1.4 Rpc フレームワーク

Rpc フレームワークは、ローカル サービスがリモート サービスを呼び出すときにローカル サービスを呼び出すのと同じくらい簡単にするために役立ちます。その基礎となる実装について気にする必要はありません。対応する情報と RPC フレームワークを構成するだけで済みます。私たちのためにこれらのことをやってくれます。たとえば、ダボでは、対応する登録センターと呼び出したいメソッドを設定するだけで、ローカル通話と同じ方法でリモートサービスを呼び出すことができます。

1.5 概要

上記の検討プロセスによれば、Rpc は 2 つの主要な実装を備えた概念であると考えることができます。1 つはhttp を介したサービス呼び出しで、もう 1 つはdubbo プロトコルなどのカスタム Tcp プロトコルを介したメソッド呼び出しです。 rpc フレームワークは http プロトコルもサポートします。もちろん、どの方法を使用しても、最終的には Tcp/Udp モードで送信されます。

2.Rpcフレームワーク

2.1 ダボとは

Rpc フレームワークを使用すると、ローカル サービスを呼び出すのと同じくらい簡単にリモート サービスを呼び出すことができると上で説明しましたが、Dubbo は Alibaba がオープンソース化した RPC フレームワークです。

たとえば、リモート メソッドを呼び出したい場合は、適切な設定を行って直接呼び出すだけで済みますが、Dubbo は中間プロセスを処理するのに役立ちます。

/*
省略相关配置
*/

//将配置注册到spring
@Resource
private QueryPinService queryPinService;

//直接使用远程方法，像调用本地服务一样简单
ueryPinService.getPinWithConfig(paramMap, null);

dubbo の全体的なアーキテクチャ図は次のとおりです。

ノード	説明する
プロバイダー	リモートサービスを提供するサービスプロバイダー
レジストリ	登録センター
消費者	リモートサービスを呼び出す必要があるサービスコンシューマ
容器	サービスが実行されるコンテナ
モニター	監視センター

作業工程は大まかに以下の通りです。

まず、サービスプロバイダーが起動され、提供できるサービスを登録センターに登録します。

サービス消費者消費者は、必要なサービスの登録センターへの加入を開始します。その後、登録センターからプロバイダーのメタ情報がコンシューマに通知され、コンシューマは登録センターからプロバイダのアドレスを取得しているため、ロード バランシングを通じてプロバイダを選択し、直接呼び出すことができます。

サービス プロバイダーのメタデータが後で変更された場合、登録センターはその変更をサービス コンシューマにプッシュします。

サービスプロバイダーと消費者の両方が通話の回数と時間をメモリに記録し、統計データを定期的に監視センターに送信します。

2.2 ダボとスプリングクラウドの違い

まず、どちらも現在主流のマイクロサービス フレームワークですが、それらの間には多くの違いがあります。

1. 初期の位置付けは異なります: SpringCloud は、主にゲートウェイ、登録センター、構成センター、監視センターなどを含むマイクロサービス アーキテクチャの下でのワンストップ ソリューションとして位置付けられていますが、Dubbo は主にサービス呼び出しとガバナンスに焦点を当てており、サービス呼び出しが行われます。もっと核心です。

2. さまざまな生態環境: Spring Cloud は Spring プラットフォームに依存しており、より完全な生態システムを備えていますが、Dubbo は最初は RPC リモート呼び出しのみを行っており、エコシステムは比較的不足していましたが、現在は徐々に充実しています。

3. 呼び出し方法: SpringCloud はリモート呼び出しに Http プロトコルを使用し、インターフェイスは通常、より柔軟な Rest スタイルです。Dubbo は Dubbo プロトコルを使用し、インターフェイスは通常、固定形式の Java の Service インターフェイスです。ただし、呼び出し時には Netty の NIO メソッドが使用され、パフォーマンスが向上します。

両方のコンポーネントの構成:

SpringCloud が dubbo よりも完全な構成を備えており、より強力な機能をサポートしていることは明らかです。

それに比べて、SpringCloud はブランドマシンのようなもので、すべての内部構成が組み立てられており、箱から出してすぐに使用するだけで済みます。Dubbo は組み立てマシンに似ています。構成を自分で選択する必要があります。コアのコンピューティング能力のみを提供し、ディスプレイや電源などは自分で組み立ててデバッグする必要があります。

ユーザーの視点から見ると、初心者にはブランド機の方が適しており、ワンクリック操作で目的の効果を得ることができます。Dubbo は、必要なコンポーネントを組み立ててよりスムーズに使用できる、コンピュータの専門家に適しています。

著者: JD Technology Korea Kai

出典：JD Cloud Developer Community 転載の際は出典を明記してください

200元の罰金と100万元以上の没収 You Yuxi: 高品質の中国語文書の重要性 MuskのJDK 21用ハードコア移行サーバー Solon、仮想スレッドは信じられないほど素晴らしい！！！ TCP 輻輳制御によりインターネットが節約される OpenHarmony 用の Flutter が登場 Linux カーネルの LTS 期間が 6 年から 2 年に復元される Go 1.22 で for ループ変数エラーが修正される Svelte は「新しい車輪」を構築 - ルーン文字 Google が創立 25 周年を祝う

{{名前}}

{{名前}}