開源 RPC 框架有哪些呢？
一類是跟某種特定語言平臺綁定的，另一類是與語言無關即跨語言平臺的。
跟語言平臺綁定的開源 RPC 框架主要有下面幾種。
Dubbo：國內最早開源的 RPC 框架，由阿里巴巴公司開發並於 2011 年末對外開源，僅支持 Java 語言。
Motan：微博內部使用的 RPC 框架，於 2016 年對外開源，僅支持 Java 語言。
Tars：騰訊內部使用的 RPC 框架，於 2017 年對外開源，僅支持 C++ 語言。
Spring Cloud：國外 Pivotal 公司 2014 年對外開源的 RPC 框架，僅支持 Java 語言
而跨語言平臺的開源 RPC 框架主要有以下幾種。
gRPC：Google 於 2015 年對外開源的跨語言 RPC 框架，支持多種語言。
Thrift：最初是由 Facebook 開發的內部系統跨語言的 RPC 框架，2007 年貢獻給了 Apache 基金，成爲 Apache 開源項目之一，支持多種語言。
如果你的業務場景僅僅侷限於一種語言的話，可以選擇跟語言綁定的 RPC 框架中的一種；
如果涉及多個語言平臺之間的相互調用，就應該選擇跨語言平臺的 RPC 框架。
RPC 框架，它們具體有何區別？
1. Dubbo
先來聊聊 Dubbo，Dubbo 可以說是國內開源最早的 RPC 框架了，目前只支持 Java 語言，它的架構可以用下面這張圖展示。
從圖中你能看到，Dubbo 的架構主要包含四個角色，其中 Consumer 是服務消費者，Provider 是服務提供者，Registry 是註冊中心，Monitor 是監控系統。
具體的交互流程是 Consumer 一端通過註冊中心獲取到 Provider 節點後，通過 Dubbo 的客戶端 SDK 與 Provider 建立連接，併發起調用。Provider 一端通過 Dubbo 的服務端 SDK 接收到 Consumer 的請求，處理後再把結果返回給 Consumer。
2. Motan
Motan 是國內另外一個比較有名的開源的 RPC 框架，同樣也只支持 Java 語言實現，它的架構可以用下面這張圖描述。
Motan 與 Dubbo 的架構類似，都需要在 Client 端（服務消費者）和 Server 端（服務提供者）引入 SDK，其中 Motan 框架主要包含下面幾個功能模塊。
register：用來和註冊中心交互，包括註冊服務、訂閱服務、服務變更通知、服務心跳發送等功能。
protocol：用來進行 RPC 服務的描述和 RPC 服務的配置管理，這一層還可以添加不同功能的 filter 用來完成統計、併發限制等功能。
serialize：將 RPC 請求中的參數、結果等對象進行序列化與反序列化
transport：用來進行遠程通信，默認使用 Netty NIO 的 TCP 長鏈接方式。
cluster：請求時會根據不同的高可用與負載均衡策略選擇一個可用的 Server 發起遠程調用。
3. Tars
Tars 是騰訊根據內部多年使用微服務架構的實踐，總結而成的開源項目，僅支持 C++ 語言，它的架構圖如下。
Tars 的架構交互主要包括以下幾個流程：
服務發佈流程：在 web 系統上傳 server 的發佈包到 patch，上傳成功後，在 web 上提交發布 server 請求，由 registry 服務傳達到 node，然後 node 拉取 server 的發佈包到本地，拉起 server 服務。
管理命令流程：web 系統上的可以提交管理 server 服務命令請求，由 registry 服務傳達到 node 服務，然後由 node 向 server 發送管理命令。
心跳上報流程：server 服務運行後，會定期上報心跳到 node，node 然後把服務心跳信息上報到 registry 服務，由 registry 進行統一管理。
信息上報流程：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 等。
關於微服務我總結了一個技術路線，分享給大家
最後
歡迎大家一起交流，喜歡文章記得關注我點個贊喲，感謝支持！