RPCの起源
インターネットの発展に伴い、Webアプリケーションは、従来の縦型アプリケーションアーキテクチャのサイズは対処することができなかった拡張分散型サービスアーキテクチャとアーキテクチャの不可欠の計算流れ続けるアーキテクチャの秩序ある発展を確保するための制御システムを必要としています。
- シングルアプリケーションアーキテクチャ
- サイトのトラフィックが少ない場合には、一つだけのアプリケーションは、すべての機能は、コストとデプロイ・ノードを削減するために一緒に配備されています。
- この場合には、CRUDを簡略化するため、データ・アクセス・フレーム（ORM）がキーであるワークロード。
- 縦型アプリケーションアーキテクチャ
- トラフィックが徐々に増加すると、ますます小さくなって加速を高めるために、マシンをもたらすために、単一のアプリケーションは、アプリケーションがスプリットは、効率を改善するために、いくつかの異なるアプリケーションにあります。
- この場合、フロントページ（MVC）の開発を加速するためのWebフレームワークが鍵となります。
- 分散型サービスアーキテクチャ
- より多くの垂直アプリケーションとして、アプリケーション間の必然的な相互作用は、変化する市場の要求に迅速に対応する独立したサービスとして、コアビジネスから引き出され、徐々に安定したサービスセンターを形成し、フロントエンドアプリケーションされます。
- この場合には、統一されたサービスを提供するために、分散サービス・フレームワーク（RPC）サービスの多重化および統合を改善するためのキーです。
たとえば：各チームのサービスプロバイダは、全体的に低い結果として、技術的な作業の重複「を超えて事業」シリアライズ、デシリアライゼーションの、ネットワークフレームワーク、接続プーリング、トランシーバスレッド、タイムアウト処理、状態および他の独自のセットを実現していません効果。
したがって、解決のRPCへの統一されたフレームワークは、統一されたサービスを提供しています。
以下は、私は、次の4つの側面から各RPCを説明します。
RPCの原則
これは、アプリケーションサーバAに配備、二つのサーバA、Bである、それはメモリではありませんので、直接呼び出すことはありません、アプリケーションが提供するサーバー上の関数/メソッドBを呼び出すしたい、ネットワークのセマンティクスによって呼び出される必要があるとデータコールを伝えます。
たとえば、サーバーB上のメソッドをコールするサーバー：
従業員getEmployeeByName（文字列のfullName）
主に次のような工程を経て全体の呼処理、：
1、通信を確立
、あなたがBを呼び出したいマシンですマシン第1の通信リンクを確立する必要があります：私たちは、最初の通信の問題を解決しなければなりません。
主に、これに関連して、TCPコネクションの確立を介してすべてのデータ交換に、クライアントとサーバ間のリモートプロシージャコールを送信しています。接続は、同じ接続を共有するコールの終了を切断した後、それは長い接続することができ、必要に応じて接続され、複数のリモート・プロシージャ・コールすることができます。
アドレッシング2.サービス
アプリケーションサーバAのTELLに、ある取り扱う問題を解決するためにどのように根本的なRPCフレームワーク、そしてどのような特定のポートの名前の名前、イエスの方法（例えばホストやIPアドレスなど）のサーバBに接続する方法。
通常の状況下で、我々は、サービスコールを完了するように、パラメータへのメソッドまたは関数呼び出しとパラメータ情報の名前を指定し、Bのマシン（ホスト名またはIPアドレス）と、特定のポートを提供する必要があります。
（主に発見サービスを提供するために）対処する確実な方法は、RPCの礎石である、例えば、Redisの飼育係やサービスを登録するために使用することができます。
- ビューのサービス提供者のポイントの視点から：プロバイダサービスは、レジストリへの自動登録サービスの必要性を開始します。
- サービスプロバイダが停止した場合、レジストリにサービスをログオフする必要があります。
- プロバイダが定期的に登録センターにハートビートを送信する必要があります後、一定の期間は、サービスプロバイダが停止したことをプロバイダからのハートビートを受信しなかった、レジストリ対応サービスから取り出されました。
- ビューの呼び出し側の視点から：発信者がメッセージを開始すると、レジストリを購読し、レジストリから、プロバイダのアドレスを取得します。
- ラインまたはオフラインプロバイダレジストリ知らせる呼び出し元がある場合。
- ときに組立ラインオフ、発信者、購読中止。
図3に示すように、ネットワーク伝送
3.1シリアル
ネットワークプロトコルは、バイナリに基づいているので、A機が開始基準情報にRPCコール、コール方法および上のアプリケーションは、基本的なネットワークプロトコルを介してマシンBにTCPのような送信するときに、私たちの伝送の全てのパラメータデータをするために必要とされますバイナリにフォームの配列（シリアライズ）または成る（マーシャル）は、ネットワークに送信されます。次いで、ネットワークを介して伝送バイナリシーケンスのデータまたはアドレス指定動作のグループ化とは、B機に送られます。
3.2直列化復元
マシンB Aマシンがアプリケーションによって送信された要求を受信し、情報が必要なときにドッキングパラメータは、次に、受信した操作（逆演算のシーケンス）、メモリ内の表現に対して、すなわちバイナリ情報バックをデシリアライズこの方法は、ローカルコールの対応する（アドレスの一部）を見つけるために、（通常呼にプロキシプロキシを生成することによって、
コールの戻りの後に与えるために、通常、JDKの動的プロキシ、CGLIBの動的プロキシ、Javassistのバイトコード生成技術、等があります）。
4、サービスコール
戻り値を取得する（プロキシプロキシを介して）ローカル電話機Bの後に、この時間が必要で、戻り値は、次にデータがバイナリAマシンに返送するためにネットワークを介しても操作のシーケンスを通過する必要があり、機械に送り返され、その後送信さ値への復帰を受信した後、再びデシリアライズマシンは、式をメモリに復元させた最終的マシン上のアプリケーションに行う相関処理（通常、サービスロジック処理動作）。
一般的に、以上の4つのステップの後に、完全なRPC呼び出しが完了します。
PRCアーキテクチャコンポーネント
少なくとも、次の4つのコンポーネントが含まれている必要があり、基本的なRPCフレームワーク：
1、クライアント（クライアント）：サービス（サービスコンシューマ）への発信者
図2に示すように、クライアント・スタブ（クライアントスタブ）：サーバーのアドレス情報を格納し、データ要求パラメータ情報は、ネットワーク伝送を介してサーバに送信する前に、クライアントのネットワークメッセージに詰め
図3は、サーバ・スタブ（サーバスタブ）：クライアントから送信された要求を受信し、メッセージをアンパックして、ローカルサービスコール処理
4、サーバー（サーバー）：真のサービスプロバイダ
RPCのプロシージャコール
1、サービスコンシューマ（クライアントクライアント）は、ローカルコールの方法でサービスを呼び出します
図2に示すように、メッセージの本体に（組）の参照配列にメソッド要求が担当して呼び出し、およびその他の情報を受信した後、クライアント・スタブ（クライアント・スタブ）は、ネットワークを介して送信することができます
3、リモートサービスのアドレスを見つけるために、クライアントのスタブ（クライアントスタブ）、およびネットワーク上のサーバーにメッセージを送信
メッセージを受信した後、図4に示すように、サーバ・スタブ（サーバ・スタブ）復号化（デシリアライズ）
図5は、サーバ・スタブ（サーバ・スタブ）は、相関処理のデコード結果に基づいて、ローカルサービスを呼び出し
図6に示すように、ローカルサービスおよび特定のサービスロジックの実装では、サーバ・スタブ（サーバ・スタブ）に処理結果を返します
図7は、サーバ・スタブ（サーバ・スタブ）は、結果メッセージが（直列化）に再パッケージ戻り、ネットワークを介して消費者に送られます。
図8に示すように、クライアント・スタブ（クライアント・スタブ）は、メッセージ、および復号（デシリアライズ）を受信します
最終的な結果を得るために9、サービスコンシューマ