共通wx：CodingTechWork
導入
RPC フレームワーク
コンセプト
- RPC (リモート プロシージャ コール プロトコル) リモート プロシージャ コール プロトコル。
- RPC は、基礎となるネットワーク テクノロジの知識を必要とせずに、ネットワーク経由でリモート コンピュータ プログラムにサービスを要求するためのプロトコルです。
- RPC の主な機能は、異なるサービス間のメソッド呼び出しがローカル呼び出しと同じくらい便利であることです。
一般的に使用される RPC テクノロジまたはフレームワーク
- アプリケーションレベルのサービスフレームワーク: Ali's Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。
- リモート通信プロトコル: RMI、ソケット、SOAP(HTTP XML)、REST(HTTP JSON)。
- コミュニケーションフレームワーク：MINAとNetty
メインストリーム gRPC、Thrift、Dubbo
gRPC: gRPC は Google のオープン ソース ソフトウェアであり、gRPC は HTTP2.0 プロトコルに基づいており、HTTP2.0 はバイナリに基づいた HTTP プロトコルのアップグレード バージョンであり、基礎となる層は Netty フレームワークによってサポートされています。Thrift: Thrift は Facebook のオープンソース プロジェクトであり、言語を超えたサービス開発フレームワークです。ユーザーは 2 番目のオープンを実行するだけでよく、これは基礎となる RPC 通信に対して透過的です。Dubbo: Dubbo は Alibaba のオープン ソース コンポーネント プロトコルおよびシリアル化フレームワークであり、Spring フレームワークに基づいてプラグインおよび開発できます。リモート インターフェイスは Java インターフェイスに基づいており、マイクロサービス アーキテクチャに適しています。
なぜ RPC があるのでしょうか?
服务化: マイクロサービス、クロスプラットフォーム サービス間のリモート呼び出し。分布式系统架构: 分散サービスはマシン間でリモート呼び出しを行います。服务可重用: 複数のサービスによるリモート呼び出しのためのパブリック機能サービスを開発します。系统间交互调用: サーバー A と B の 2 台があり、サーバー A のアプリケーション a は、サーバー B のアプリケーション b が提供するメソッドを呼び出す必要がありますが、アプリケーション a とアプリケーション b は同じメモリ空間にないため、直接呼び出すことはできません。ネットワーク送信を通じて表現する必要があります。通話のセマンティクスと転送されるデータが必要です。
使用するシーン
大型网站: 内部的には、多くのサービスとインターフェイスを備えた複数のサブシステムが関与します。注册发现机制: Nacos、Dubbo などのサービスには通常、登録センターがあり、サービスには複数のインスタンスがあり、呼び出し元はどのインスタンスが呼び出されたのかを認識できません。- security`: リソースを公開しません。
服务化治理: マイクロサービス アーキテクチャ、分散アーキテクチャ。
建築
アーキテクチャ図
RPC呼び出しプロセス
- クライアント (Client) は、ローカル呼び出し (インターフェース呼び出し) を通じてサービスを呼び出します。
- 呼び出し要求を受信した後、クライアント スタブ (クライアント スタブ) は、メソッドや入力パラメータなどの情報を組み立てて、ネットワーク送信可能なメッセージ本文にシリアル化します (メッセージ本文オブジェクトをバイナリ ストリームにシリアル化します)。
- クライアント スタブ (クライアント スタブ) はリモート サービス アドレスを見つけ、ネットワーク経由でサーバーにメッセージを送信します (ソケット経由でメッセージを送信します)。
- サーバー スタブ (サーバー スタブ) は、メッセージの受信後に逆シリアル化操作、つまりデコード (バイナリ ストリームをメッセージ オブジェクトに逆シリアル化) を実行します。
- サーバー スタブ (Server Stub) は、デコード結果を通じて関連する処理のためにローカル サービスを呼び出します。
- サーバー (サーバー) ローカル サービス ビジネス処理。
- サーバー (Server) は処理結果をサーバースタブに返します。
- サーバー スタブ (サーバー スタブ) は、処理結果をシリアル化します (結果メッセージ オブジェクトをバイナリ ストリームにシリアル化します)。
- サーバー スタブ (サーバー スタブ) は、シリアル化された結果をネットワーク経由でクライアントに送信します (ソケット経由でメッセージを送信します)。
- クライアント スタブ (サーバー スタブ) はメッセージを受信し、逆シリアル化とデコード (結果のバイナリ ストリームをメッセージ オブジェクトに逆シリアル化) を実行します。
- クライアントは最終結果を取得します。
コア機能
重要なコンポーネント
- クライアント: クライアント、サービス呼び出し元。
- クライアント スタブ: サーバーのアドレス情報を格納するクライアント スタブは、クライアントのリクエスト パラメーター データ情報をネットワーク メッセージに詰め込み、ネットワーク送信を通じてサーバーに送信します。
- サーバー スタブ: サーバー スタブ。クライアントから送信された要求メッセージを受信して解凍し、処理のためにローカル サービスを呼び出します。
- サーバー: サーバー、サービスの実際のプロバイダー。
- newtwork サービス: 基礎となるトランスポート、tcp または http
機能実現
機能実現は主に、サービスアドレッシング機能、シリアル化と逆シリアル化機能、ネットワーク送信機能に分かれます。
サービスアドレッシング機能
コールIDマッピング
- ローカル: ローカルメソッド呼び出しでは、関数ポインタを通じて関数本体を直接指定しますが、リモート呼び出しでは、2つのプロセスのアドレス空間が完全に異なるため、関数ポインタは機能しません。
- リモート: RPC のすべての関数またはメソッドには独自の ID があり、すべてのプロセスで一意です。クライアントがリモート プロシージャ コールを行うときは、この ID を添付する必要があります。つまり、クライアントはテーブルをチェックして対応するコール ID を見つけ、それをサーバーに渡します。また、サーバーもテーブルをチェックして決定します。クライアントが呼び出す必要がある関数を指定し、対応する関数のコードを実行します。
- コール ID マッピング テーブルは通常、ハッシュ テーブルです。
技術例
サービス登録センターを通じて相手のサービスインスタンスを問い合わせる必要があります。
- Nacos は OpenFeign を統合して RPC 呼び出しを実装します。
- Spring Cloud は Dubbo を統合して RPC 呼び出しを実装します。
シリアル化および逆シリアル化関数
概要
- シリアル化: メッセージ オブジェクトをバイナリ ストリームに変換します。
- 逆シリアル化: バイナリ ストリームをメッセージ オブジェクトに変換します。
必要性
- リモート呼び出しにはデータの送信が含まれますが、ローカル呼び出しでは、データをスタックにプッシュし、関数にスタックからデータを読み取らせるだけです。
- ただし、リモートデータ送信の場合、クライアントとサーバーが同一サーバー上になく、別プロセスとなるため、パラメータをメモリ経由で渡すことができないため、クライアント側でリクエストパラメータをバイトストリームに変換（エンコード）し、サーバーに渡すと、サーバーはバイト ストリームを読み取り (デコード) できる形式に変換します。これがシリアル化と逆シリアル化のプロセスです。逆に、サーバーからの戻り値はシリアル化され、逆にクライアントに逆シリアル化されます。
シリアル化のメリット
- メッセージ オブジェクトをバイナリ バイト ストリームに変換します。これはネットワーク送信に便利です。
- クロスプラットフォーム、クロス言語。たとえば、Python で書かれたクライアントは、逆シリアル化のために Java で書かれたサーバーにシリアル化パラメータを送信することを要求します。
ネットワーク送信機能
効果
- クライアントは、コール ID とシリアル化されたパラメーターのバイト ストリームをサーバーに送信します。
- サーバーはシリアル化された呼び出し結果をクライアントに返します。
プロトコル
主に TCP、UDP、HTTP プロトコルがあります。
TCPプロトコルに基づく
- クライアントとサーバーはソケット接続を確立します。
- クライアントは、ソケット経由で呼び出されるインターフェイス名、メソッド名、およびパラメーターをシリアル化し、それをサーバーに渡します。
- サーバーは逆シリアル化し、リフレクションを使用して対応するメソッドを呼び出し、結果をクライアントに返します。
HTTPプロトコルに基づく
- クライアントは、GET、POST、PUT、DELETE などのリクエストをサーバーに送信します。
- サーバーは、さまざまなリクエスト パラメーターとリクエスト URL に従ってメソッド呼び出しを行い、JSON または XML データの結果を返します。
TCPとHTTPの比較
- TCP プロトコルに基づく RPC 呼び出しは、基盤となるプロトコル スタックであるため、プロトコル フィールドをより柔軟にカスタマイズでき、ネットワーク オーバーヘッドを削減し、パフォーマンスを向上させ、より優れたスループットと同時実行性を実現できます。ただし、最下層は複雑で実装コストが高くなります。
- HTTP プロトコルに基づいて実装される RPC 呼び出しはカプセル化およびシリアル化されていますが、HTTP はアプリケーション層プロトコルに属し、HTTP 送信によって占有されるバイト数が TCP よりも多く、送信効率が TCP よりも低くなります。 。
RPC と Restful API の比較
異なるものに焦点を当てる
- RPC は運用に重点を置いています
- Restful はリソースに焦点を当てます
伝達効率
- RPC はより効率的であり、TCP プロトコルをカスタマイズして要求パケットの量を制御できます。
- Restful は効率が低く、HTTP プロトコルに基づいています。
複雑さ
- RPC の実装は複雑で、サービスのアドレッシング、シリアル化と逆シリアル化、ネットワーク送信に注意を払う必要があり、呼び出しプロセスは煩雑です。
- Restful の実装はシンプルで、シリアル化と逆シリアル化、ネットワーク送信に注意を払う必要がなく、呼び出しプロセスが便利です。
使用するシーン
- RPC は、パフォーマンスの消費が低く、伝送効率が高く、実装が複雑な、部門間の異なるプラットフォームでのサービス コールなど、社内のサービス コールに適しています。
- HTTP は主に、外部の異種環境、ブラウザ インターフェイス呼び出し、サードパーティ インターフェイス呼び出しなどで使用されます。