RPCオープンソースのフレームワーク、何でしょうか？
一つは、他のクロス言語プラットフォームである言語から独立して、特定のプラットフォームの言語バインディングです。
オープンソースプラットフォームの言語バインディングを持つRPCフレームワークには、次のカテゴリです。
ダボ：2011年後半アリババによって開発された最古のオープンソースのRPCフレームワークの一つと外部のオープンソース、唯一のJava言語をサポートしています。
Motan：マイクロボー、2016年の外部売上高の内部使用のためのRPCフレームワーク、唯一のJava言語をサポートしています。
タール：RPCフレームワーク2017年の外国収入のテンセント内部使用のみ、C ++言語をサポートしています。
春の雲：ピボタル外国企業RPC 2014外国オープンソースのフレームワークでは、唯一のJava言語をサポートしています
クロスプラットフォームのオープンソース言語のRPCフレームワークは、以下のとおりです。
2015年にGoogleの、複数の言語をサポートし、外部のオープンソースのクロス言語のRPCフレームワーク：gRPC。
スリフト：もともとFacebookの言語RPCフレームワークによって開発された内部システム間では、2007年には、Apache財団に貢献したApacheのオープンソースプロジェクトの一つとなった、複数の言語をサポートしています。
あなたのビジネスシナリオが一つの言語に限定した場合は、内結合を持つ言語RPCフレームワークを選択することができます。
それは複数の言語プラットフォーム間の相互通話が含まれている場合は、クロスプラットフォームの言語RPCフレームワークを選択する必要があります。
RPCフレームワーク、その具体的な違いは何ですか？
1.ダボ
RPCのための最初のオープンソースのフレームワークで、現在はJava言語をサポートしていダボが言うことができる、ダボについて話を最初に、そのアーキテクチャは、ショーの下にこのチャートを使用することができます。
あなたは、モニタが監視システムで、レジストリは、レジストリで、プロバイダは、サービスプロバイダである、消費者サービスの消費者である、ダボアーキテクチャは4つの主要な文字で構成され、図から見ることができます。
特異的な相互作用プロセスはダボを通じてプロバイダがクライアントSDKとの接続を確立し、消費者エンドノードプロバイダのレジストリを取得することで、通話を開始します。サーバーSDKダボで受信されたプロバイダの消費者終了要求、プロセスは、消費者に結果を返します。
2. Motan
Motanはまた、そのアーキテクチャは、以下の画像を用いて記述することができる、唯一のJava言語をサポートしてよく知られているオープンソースのRPCフレームワークの追加です。
ダボに似Motanアーキテクチャ、我々は、SDKクライアント側（顧客サービス）とサーバー側（サービスプロバイダ）、主に以下の機能モジュールが含まれていMotanフレームワークを導入する必要があります。
登録：登録し、センターを相互作用のために、登録サービス、サブスクリプションサービス、サービス変更通知サービスの送信ハートビートやその他の機能を含みます。
プロトコル：RPCサービスのRPCサービスと構成管理を記述するために使用されるが、この層はまた別の統計を完了するために使用されるフィルタの機能、同時実行の制限や他の機能を追加することができます。
シリアライズ：RPCリクエストオブジェクトのパラメータを、シリアライズとデシリアライズのように
交通：リモート通信、デフォルトのTCPネッティーNIO長い道のりリンクについて。
クラスタ：要求が異なる高可用性と負荷分散ポリシーに基づいている場合は、リモート呼び出しを開始するために利用可能なサーバのいずれかを選択します。
3.タール
タールは、オープンソースプロジェクトの概要から、内部のテンセントのマイクロサービスアーキテクチャを使用するための実践の年に基づいており、唯一そのアーキテクチャを以下に示し、C ++言語をサポートしています。
アーキテクチャのタール相互作用は、次のプロセスが含まれています。
サービス公開プロセス：アップロードサーバのリリースパッケージがノードにレジストリサービスによって搬送された要求を、提出するウェブサーバ上で公開し、アップロードが成功した後、ウェブシステムにパッチを適用し、その後、ローカルサーバーへのノードのプルリリースパッケージには、サーバーのサービスを引き出します。
受注管理プロセス：管理サーバがサービス要求のコマンドを送信することができ、サービスノードにレジストリサービスによって通信は、システムによって、ウェブ上で管理サーバーノードにコマンドを送信します。
ハートビートは、報告プロセス：サーバーサービスが実行された後、定期的にノードにハートビートを報告し、ノードのハートビート情報は、レジストリでサービスレジストリサービス、統合管理に報告されます。
信息上报流程：server 服务运行后，会定期上报统计信息到 stat，打印远程日志到 log，定期上报属性信息到 prop、上报异常信息到 notify、从 config 拉取服务配置信息。
client 访问 server 流程：client 可以通过 server 的对象名 Obj 间接访问 server，client 会从 registry 上拉取 server 的路由信息（如 IP、Port 信息），然后根据具体的业务特性（同步或者异步，TCP 或者 UDP 方式）访问 server（当然 client 也可以通过 IP/Port 直接访问 server）。
4. Spring Cloud
Spring Cloud 利用 Spring Boot 特性整合了开源行业中优秀的组件，整体对外提供了一套在微服务架构中服务治理的解决方案。
只支持 Java 语言平台，它的架构图可以用下面这张图来描述。
由此可见，Spring Cloud 微服务架构是由多个组件一起组成的，各个组件的交互流程如下。
请求统一通过 API 网关 Zuul 来访问内部服务，先经过 Token 进行安全认证。
通过安全认证后，网关 Zuul 从注册中心 Eureka 获取可用服务节点列表。
从可用服务节点中选取一个可用节点，然后把请求分发到这个节点。
整个请求过程中，Hystrix 组件负责处理服务超时熔断，Turbine 组件负责监控服务间的调用和熔断相关指标，Sleuth 组件负责调用链监控，ELK 负责日志分析。
5. gRPC
先来看下 gRPC，它的原理是通过 IDL（Interface Definition Language）文件定义服务接口的参数和返回值类型，然后通过代码生成程序生成服务端和客户端的具体实现代码，这样在 gRPC 里，客户端应用可以像调用本地对象一样调用另一台服务器上对应的方法。
它的主要特性包括三个方面。
HTTP / 2は、接続多重化、双方向の流れ、プッシュサーバ、要求の優先順位、ヘッダ圧縮機構を提供するための通信プロトコルは、HTTP / 2を使用し
IDLはいるProtobufは、Googleによってデータのシリアル化プロトコル、高い圧縮及び伝送効率、単純な構文を開発し、使用しているProtobufを
多言語サポートは、複数の言語を自動的にクライアントとサーバのコードの対応する言語に基づいて生成することができます。
6.スリフト
そして、倹約を見て、スリフトは、最大25個のプログラミング言語をサポートする軽量クロスランゲージRPC通信プログラムです。複数の言語をサポートするために、同じgRPCと、倹約は、独自のインターフェイス定義言語IDLを持つことになり、コード生成器は、したがって、異なる言語間でき確保、プログラミング言語クライアント側およびサーバSDKコードの多様を生成することができ互いに通信します。なお、図1で説明し、図のアーキテクチャで使用することができます。
これは、特徴的なスリフトRPCフレームワークから見ることができます。
複数のフォーマットシーケンスをサポートしています：バイナリ、コンパクト、JSON、多重化が好きです。
これは、複数の通信モードをサポートしています。ソケットは、額縁、ファイル、メモリ、zlibのが好きなように。
サーバーは、様々なトリートメントをサポート：シンプル、プールは、ノンブロッキングなどを通します。
誰もが共有するためのマイクロサービスについて私は、技術的なルートを総括しました
最後に、
私たちは、ヨーヨーは、物品、支援への感謝を覚えている賞賛のポイントのように、交換を歓迎します！