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，ProtoBuf 是由 Google 开发的一种数据序列化协议，它的压缩和传输效率极高，语法也简单
多语言支持，能够基于多种语言自动生成对应语言的客户端和服务端的代码。
6. Thrift
再来看下 Thrift，Thrift 是一种轻量级的跨语言 RPC 通信方案，支持多达 25 种编程语言。为了支持多种语言，跟 gRPC 一样，Thrift 也有一套自己的接口定义语言 IDL，可以通过代码生成器，生成各种编程语言的 Client 端和 Server 端的 SDK 代码，这样就保证了不同语言之间可以相互通信。它的架构图可以用下图来描述。
从这张图上可以看出 Thrift RPC 框架的特性。
支持多种序列化格式：如 Binary、Compact、JSON、Multiplexed 等。
支持多种通信方式：如 Socket、Framed、File、Memory、zlib 等。
服务端支持多种处理方式：如 Simple 、Thread Pool、Non-Blocking 等。
关于微服务我总结了一个技术路线，分享给大家
“不积跬步，无以至千里”，希望未来的你能：有梦为马 随处可栖！加油，少年！
关注公众号:「Java 知己」，每天更新 Java 知识哦，期待你的到来！
发送「面试」，领取 BATJ 面试资料、面试视频攻略。
发送「Group」，与 10 万程序员一起进步。
发送「玩转算法」，领取《玩转算法》系列视频教程。
千万不要发送「1024」，否则......
