概要
RPC は Remote Processing Call、リモート プロシージャ コールです。主な目的は、ますます拡大するサービス背景におけるサービス間の通話通信を解決することです。
構成
RPC は、サービスの呼び出し元 (クライアント)、サービスの呼び出し先 (サーバー、つまりサービス プロバイダー)、およびサービス登録センター (サーバー登録センター) の 3 つの部分で構成されます。この 3 つは互いに連携してサービス RPC 呼び出しを完了します。
プロシージャの呼び出し
- クライアントはリモートサーバー上のサービスを呼び出す必要があります
- クライアントは、呼び出す必要があるサービス情報をパッケージ化してクライアント スタブ (スタブ) に送信します。クライアント スタブは、独自のメカニズムのいくつかを使用して、呼び出し情報を渡せるメッセージ本文に変換し、その情報を添付します。呼び出されたサービスを外部に送信し、これらの情報をサーバー登録センターに送信します。
- レジスターは、クライアントによって呼び出されるサービス情報を抽出し、処理するサービスへの負荷分散 (端的に言うと、サービス ノードの選択) を担当します。
- レジスターはサービスを選択した後、クライアント スタブによって渡されたメッセージ本文を特定のサービスのサーバー スタブに送信する役割を果たします。
- サーバー スタブはメッセージ本文を解析し、解析完了後にメッセージ本文をサーバーに送信します。
- サーバーは対応するサービス処理を実行し、結果パッケージをサーバー スタブに返します。
- サーバスタブは、サービスの実行結果を受け取り、メッセージボディ（このメッセージボディとは、ネットワーク通信により送信可能なデータのこと）に詰めて、サーバ登録センターに送信する。
- サーバー登録センターはクライアント サーバーへの負荷分散を行い、メッセージ本文をクライアント スタブに渡します。
- クライアント スタブは、サーバー登録センターから渡された結果を解析し、結果をクライアント サーバーに送信します。
10. クライアントはそれに応じて処理します。
注: 上記の手順には誤解があります。つまり、多くの人はクライアント サーバーが 1 つしかないと考えています。実際、RPC の 3 つの主要コンポーネントは、1 つ以上のクラスターにデプロイされます。A クライアントが送信した RPC リクエストは、サービス結果を受信した後、B クライアントで処理できます。(実際には、これは個人のコード設計に依存します)
HTTPとRPCの違い
-
転送プロトコル
- RPC は TCP プロトコルまたは HTTP プロトコルに基づくことができます
- HTTP、HTTP プロトコルに基づく
-
伝達効率
- カスタム TCP プロトコルを使用する RPC では、リクエスト メッセージのサイズを小さくしたり、HTTP2 プロトコルを使用したりできます。これにより、メッセージの量が削減され、送信効率も向上します。
- HTTP、HTTP1.1 プロトコルに基づいている場合、リクエストには多くの無駄なコンテンツが含まれます。HTTP2.0 に基づいている場合、次の単純なカプセル化を RPC として使用できます。現時点では標準の RPC フレームワークです。サービスガバナンスの強化
-
パフォーマンスの消費 (主に時間のかかるシリアル化と逆シリアル化による)
- 倹約に基づいた効率的なバイナリ伝送を実現できるRPC
- HTTP は主に json を通じて実装されており、バイト サイズとシリアル化時間の消費は節約よりもパフォーマンスを消費します。
-
負荷分散
- RPC には基本的に負荷分散戦略が組み込まれています
- HTTP、実現するにはNginx、HAProxyを構成する必要があります
-
サービス ガバナンス (ダウンストリーム サービスの追加、再起動、オフライン時にアップストリームの呼び出し元に影響を与えない方法)
- RPC は上流に影響を与えることなく自動通知を実現できます。
- HTTP、事前通知が必要、Nginx/HAProxy 構成を変更
実際、率直に言うと、RPC はバックエンド サービス間の通信用に設計されているのに対し、Http はフロントエンドとバックエンドの通信用に設計されています (範囲が異なります)。RPC は http を使用して実装できます。RPC は高速ですが、HTTP はわずかに遅くなります。