一類是跟某種特定語言平臺綁定的,另外一類是與語言無關即跨語言平臺的。
跟語言平臺綁定的開源 RPC 框架主要有下面幾種。
-
Dubbo:國內最先開源的 RPC 框架,由阿里巴巴公司開發並於 2011 年底對外開源,僅支持 Java 語言。
-
Motan:微博內部使用的 RPC 框架,於 2016 年對外開源,僅支持 Java 語言。
-
Tars:騰訊內部使用的 RPC 框架,於 2017 年對外開源,僅支持 C++ 語言。
-
Spring Cloud:國外 Pivotal 公司 2014 年對外開源的 RPC 框架,僅支持 Java 語言
若是你的業務場景僅僅侷限於一種語言的話,能夠選擇跟語言綁定的 RPC 框架中的一種;
若是涉及多個語言平臺之間的相互調用,就應該選擇跨語言平臺的 RPC 框架。
2、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++ 語言,它的架構圖以下。
-
服務發佈流程:在 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 等。
3、最後
歡迎你們一塊兒交流,喜歡文章記得點個贊喲,感謝支持!