今日では、いくつかの実用的なマイクロは、サービス、最初の作品、原則と実践のRPCフレームワーク、なぜマイクロサービスアーキテクチャを取得する必要があり、それを得るためにRPCフレームワークを話し始めましたか？
原点まず、需要
以下に示すようにサービスの利点の一つは、どのような技術選択を使用する技術を、デカップリングチーム間の大企業を有効にするには、サービスプロバイダに限定されるものではありません。
サービスチームは、ヨーロッパでサービスを提供するために、技術的背景のヨーロッパのチームはJavaは、Javaがサービスを実現するために使用することができることです。
アメリカでサービスを提供するために、Bのサービスチーム、サービスは、C ++を使用して実装することができます。
Cは、移動サービスを実現することができるサービスを提供するために、中国のサービスチームです。
呼び出し側とサービスの上流で、インタフェースプロトコルに従ってリモートサービスへの呼び出しを完了します。
しかし、実際には、会社のチームの限られたサイズの99.9％は、技術チームのサイズは基本的に通話サービスを提供するための技術やシステムの同じセットを使用して、制限されています。
この場合、均一なサービスフレームワーク、RPCフレームワーク、サービスプロバイダーのさまざまなチームが存在しない場合、私たちは、それぞれが直列化、直列化復元、ネットワークのフレームワーク、接続プーリング、トランシーバスレッド、タイムアウト処理、状態の他、「ビジネスのセットを実装必要外の「全体的な非効率が生じ、熟練労働者を繰り返します。そのため、「外事業」へのRPC統一されたフレームワークは、技術的な仕事は、集中主要な問題のサービスを述べました。
単純なポイントと同じ前提の下で、[「統一されたフレームワークを使用してRPC、」これが正しい道である]、技術についてのこの記事を達するには、共通の人気の言語RPCフレームワークを実現するには、期待を概説しました。
二、RPCの背景とプロセス
RPC（リモートプロシージャコールプロトコル）、リモートプロシージャコールとは何ですか？
私たちが書いたローカル関数呼び出しが何であるかではまず見て、：
INT結果=（1、2）を加えます。
このコードは、我々は二つのパラメータに、1、2を通過していることを知っている場合は、ネイティブコードセグメントが結果にパラメータを取得する関数を追加呼び出します。この場合、受信データ、送信データ、ローカル関数呼び出しであり、同一のプロセス空間内のコードセグメント。
私たちは、クロスプロセス（そう、別のサーバーにデプロイこのプロセスの典型的な、「リモート」と呼ばれる）関数を呼び出すことができるという方法はありませんか？
考えることはほとんどの場合、2つのプロセスが上院[] [] [これのうち、関数呼び出しのパラメータ]に送信するために、プロトコル形式、ソケット通信の使用を合意しました。
プロトコル要求パケットは、バイト11バイトのストリームと仮定されます。
（1）充填関数名の最初の3つのバイト
（2）中間の最初の4つのバイトは、パラメータを埋めます
（3）4バイトの端部は、第2のパラメータを満たします
応答パケットを設計することができるが、プロトコルは、4バイトのバイトストリームです。
このプロセスは結果。
発信者コードがなる可能性があります：
リクエスト= MakePacket（2、1を「追加」）。
SendRequest_ToService_B（リクエスト）。
応答= RecieveRespnse_FromService_B（）。
INT結果= unMakePacket（respnse）。
簡単な説明：
（1）受信バイト・ストリーム・パラメータとなる話します
サービスBに送信される（2）バイトストリーム
（3）バイトストリームサービスBからのリターンを受信します
（4）発信レオロジーパラメータのバイトを返します
サービス側のコードはなることがあります。
リクエスト= RecieveRequest（）。
引数/関数= unMakePacket（リクエスト）。
結果=（1、2）を加えます。
応答= MakePacket（結果）。
SendResponse（応答）。
このプロセスは、よく理解されています。
（1）サーバは、バイトストリームを受け取り、
（2）パラメータ名の関数としてのバイト転送
（3）関数の呼び出しは、ローカルな結果を得るために
（4）結果をバイトストリームに変換されます
（5）、呼び出し元にバイトストリームを送信します
マップを用いて、上述したプロセス、ステップ、発信者サービス側の処理は非常に明確です。それが存在している。このプロセスの最大の問題は何ですか？
回答：呼び出し側あまりにも面倒、毎回多くの低レベルの詳細の懸念
（1）バイトストリームへの変換への参照を、アプリケーション層のプロトコルの詳細のすなわち配列
（2）ソケット伝送、すなわち、ネットワーク伝送プロトコルの詳細
（3）ソケットが受け付け
（4）フローバイト変換パラメータ、即ち、アプリケーション層プロトコルデシリアライゼーションの詳細
この層は、それについての詳細を気にしません呼び出すことができませんか？
回答：はい、RPCフレームワークは、この問題を解決することであり、それは、呼び出し元できる「リモートファンクションコール（サービス）としてローカル関数を呼び出すように。」
三、RPCフレームワーク業務
上記の議論では、RPCフレームワークの呼び出し側は、サービスプロバイダーはまた、複雑さのすべての種類を保護したい、様々な複雑さを保護したいと思います：
（1）の発信者は次のように、ローカル関数を呼び出すように感じています
（2）サービスプロバイダは、サービスを実装するために、ローカル関数として達成するように感じています
だから、全体のRPCフレームワークは、（1）（2）シールドの様々なタイプの複雑さのため、これらの複雑責任のRPCフレームワークであり、全体の非を担当し、クライアントとサーバーの一部の部分に分かれています。
いくつかのさらなる改良、クライアント側と含まれています：シリアライズ、デシリアライゼーションの、接続プールの管理、負荷分散、フェイルオーバー、キュー管理、残業管理、非同期管理およびそんなに多くの責任。
エンドサーバであって、サーバー・コンポーネント、サーバーの送信およびパケットキュー、IOスレッド、ワーカースレッド、シーケンスのデシリアライゼーション、コンテキストマネージャ、タイムアウトの管理、非同期コールバック関数、などなどを受け取ります。
しかし、紙面の都合で、これらの詳細は、道の下でうまくやっていません