RPC（つまり、リモートプロシージャコール、リモートプロシージャコール）と HTTP（ハイパーテキスト転送プロトコル、ハイパーテキスト転送プロトコル）、それらの間の最も本質的な違いは、あるされて TCPプロトコルの上のRPCの主要な作業ながら、 HTTPサービスのHTTPプロトコルに主に取り組んで HTTPプロトコルの上でTCPトランスポート層プロトコルであるので、ビューの効率は、その後、RPCが優れていることはもちろんであることを私たちは皆知っています。
1、RPCサービス
（1）RPCアーキテクチャ
クライアントである4つのコアコンポーネント、サーバー、クライアントスタブとサーバスタブを含む完全なRPCアーキテクチャ、スタブは、我々はスタブとしてこれを理解することができます。それぞれ、これらのコンポーネントについて話をします：
-
1）クライアント（クライアント）、呼び出し側のサービス。
-
2）サーバー（サーバー）、真のサービスプロバイダ。
-
3）クライアント・スタブ、メッセージサーバの格納アドレス、クライアントのリクエストパラメータとネットワークメッセージにパッケージ化し、リモートを介してサービングネットワークに送信されます。
- 4）サーバ・スタブは、クライアントから送信されたメッセージを受信し、メッセージをアンパックし、ローカルメソッド呼び出しです。
RPCは、主にシステム内の多くの大企業は、非常に重要な部分のビジネスの複雑さと効率の利点ラインは、この時間RPCの利点はより明白であるため、大規模な企業で使用されています。実際の開発は、それほど一般的でプロジェクトを管理するために、Mavenの使用を行うことです。例えば、我々は、第二者ライブラリーの導入のサーバ側は、その後実現（これは、特にインタフェースのJavaを参照している）、その後、プロジェクト全体は、JARパッケージとしてパッケージされたサービス注文処理システムを有しており、そのすべてのインターフェイスを宣言する対応する機能は、クライアント側だけが第二者を呼び出すことができ、このライブラリーを導入する必要があります。なぜこれを行いますか？パッケージ化され、すべての時間がリリースされているため、主のjarパッケージサイズのクライアント側を減らすために、瓶あまりにも多くのパケットは、常に効率に影響を与えます。さらにまた、デカップルクライアントとサーバとは、コードの移植性を向上します。
（2）同期呼び出しと非同期呼び出し
- 同期呼び出しは何ですか？
コールが完了実行して結果を返すようにするために、クライアントが待機する同期呼び出し。
- 非同期呼び出しは何ですか？
非同期呼び出しは、クライアントが呼び出しが結果の実装を完了するために戻るのを待ちませんが、それでもコールバック関数などによって返される結果の通知を受け取ることができます。
クライアントは結果を気にしない場合、それは一方通行通話になることができます。このプロセスでは、我々はあなたが、実装の結果を知る必要がある場合、あなたは呼び出し可能インターフェースを使用することができ、そして未来のクラスによって非同期実行結果情報を取得することができ、非同期で実行、呼び出し可能と実行可能なインターフェースでJavaに似ています。それは当然のことながら、結果を返さないので、あなたは、インプリメンテーションの結果、その上に直接実行可能なインターフェイスを気にしないのであれば、可能性も呼び出し可能な、将来は、我々はそれを得ることはありません。
（3）人気のRPCフレームワーク
RPC人気のあるオープンソースのフレームワーク、またはそれ以上。私たちは、次の3つの方法に焦点を当てます：
1）gRPCは、最新のHTTP2.0プロトコル、およびサポート多くの一般的なプログラミング言語に基づいて、Googleの最近リリースされたオープンソースソフトウェアです。
我々HTTP2.0を知っているが、HTTPのバイナリプロトコルアップグレード版に基づいており、現在の主要なブラウザはフルスピードで可能に支持されています。RPCフレームワークは、基礎となる網状フレームワークの使用をサポートするために、HTTPプロトコルの実装に基づいています。
2）スリフトFacebookは、オープンソースプロジェクトである、主にクロス言語サービス開発フレームワークです。
このIDL定義ファイルは、自動的にそのサービスコードフレームの定義を生成するコードジェネレータを持っています。長いライン上のユーザの二次開発のような従来のように、下層のRPC通信には透明です。しかし、ユーザーのためのこの必要性は、言語、特定のフィールドの後、特性を学習し、または特定のコストを持っています。
3）ダボアリグループは、広く多くのインターネット企業やエンタープライズアプリケーションで使用されている非常によく知られているオープンソースのRPCフレームワークです。
そしてシリアル化フレームワーク契約はプラグと異なる特性であることができます。同じリモートインタフェースは、Javaインターフェースに基づいて、開発を容易にするために、スプリングフレームワークに依存しています。簡単に単一のファイルにパッケージ化することができ、別々のプロセスは現在のマイクロサービス契約の概念を実行している、と。
2、HTTPサービス
（1）HTTPインターフェイス
RPCを比較すると、HTTPインタフェースの開発は、私たちはしばしば、RESTfulなサービス・インターフェースのためにそれを言うことです。;実際、システムに以下のシステムが相互作用し、頻繁に使用される初期情報の島々を解決するための通信手段の場合のインタフェースの多くの利点そのシンプルな、直接、簡単に開発。既存の伝送httpプロトコルの使用。インターフェイスのドキュメントを記述する必要は、入力または出力のために厳密に何であるかを識別するとき、バックグラウンド・インターフェースの開発を行いますか？それは各インターフェイスリクエストメソッド、リクエストパラメータだけでなく、必要性の注意事項ことを明確にします。
このような本例のように：POST http://www.httpexample.com/restful/buyer/info/share
インターフェイスJSON文字列またはXML文書を返すことができます。次に、クライアントは、比較的迅速に開発することができ、この情報に対処するために再び戻ります。
しかし、大企業のために、複数の内部サブシステム、インタフェースの多くの下で、RPCフレームのメリットショーに、
- 最初に長いリンクは、常にネットワークのオーバーヘッドを減らすこと、何3ウェイハンドシェイクのように、HTTPなどの通信を持っていません。
- 第二は、監視及び管理の富があり、RPCフレームワークは、一般的に、レジストリを有しています。
- 放出は、組立ラインインタフェースオフ、発呼者の動的拡張が認識し、統一された操作ではありません。
（2）安らか。
中国のスタイルを対応する残りの部分であり、RESTfulなWebサービスは、残りの一般的なアプリケーションであり、残りはWebサービスのスタイルに準拠して、RESTスタイルのWebサービスは、ROA（リソース指向アーキテクチャ）である （ リソース指向アーキテクチャ）。そこにRESTfulなのはなぜですか？
1）繧の動作に先立っ：
http://127.0.0.1/user/query GET問合せユーザIDのユーザデータに基づいて、
新しいユーザPOST http://127.0.0.1/user/save
http://127.0.0.1/user /更新POSTは、ユーザ情報変更
http://127.0.0.1/user/delete GET / POST削除ユーザ情報
：2）のRESTful使用
http://127.0.0.1/userをユーザに係る上述のID GETクエリのユーザデータ上
のhttp：//127.0。 0.1 /ユーザーPOST新しいユーザー
http://127.0.0.1/userのPUTは、ユーザー情報の変更
、削除、削除、ユーザ情報http://127.0.0.1/userを
操作は問題ではありません前に、偉大な神が何を持って、問題があると思います説明問題？インタフェースまたはアドレスあなたが要求するたびに、そのようなクエリとクエリ、新しい時間は、私がget要求がポストを使用して、クエリにある使用し、実際には、必要がない、保存したときのように、やっていますリクエストは、安らか持っている理由である説明を行う必要は、ありません、私の意図は明確である、新しい要求です。
3、要約
RPCサービスおよびHTTPサービスは、主に大企業のための多くの違い、一般的には、RPCサービスがあり、まだある、とので、HTTPサービスは主に、中小企業を目指している高効率のRPC、およびHTTPサービスの開発が速く、反復されます。要するに、どのようなフレームワークの選択は市場に従うものではなく、人気が決めるが、慎重にプロジェクトの影響のための2つの開発フレームワークを比較し、そして最後のために最善であるかを決定、プロジェクト全体の完全な評価を行うためにこのプロジェクト。各プロジェクトでのRPCおよびRPCを使用していますが、地域の状況に、特定の条件にしないでください。
