分布式微服務治理的核心在于: 微服務和分布式

(微服務框架)微服務的最優技術實現目前是: SpringBoot

(RPC 框架)分布式的最優技術實現目前是: Thrift,Motan,Dubbo,Spring Cloud(Netflix OSS),Finagle,gRPC

RPC 是什么

RPC 的全稱是 Remote Procedure Call ，是一種進程間通信方式。

它允許進程調用另一個地址空間的過程或函數，而不用進程員顯式編碼這個遠程調用的細節，進程員無論是調用本地的還是遠程的，本質上編寫的調用代碼基本相同。

說兩臺服務器 A、B，一個應用部署在 A 服務器上，想要調用 B 服務器上應用提供的函數/方法，由于不在一個內存空間，不能直接調用，需要通過網絡來表達調用的語義和傳達調用的數據。

Remote Procedure Call，翻譯過來應該是 “遠程進程調用”，目前業內通用的翻譯是 “遠程過程調用”，但是 “過程” 這個詞很容易造成誤解，翻譯成 “進程” 更好理解 RPC 的意義。

RPC 協議說了什么

一般所謂的 XX 協議就是個文檔，類似于我們的需求文檔，只說了要做什么，但是具體怎么做是由各大開源大佬做的。一般情況下都會實現核心功能，不同的開源在細節上實現都會不一樣，這個需要注意！

RPC 這個概念術語在上世紀 80 年代由 Bruce Jay Nelson 提出的，在 Nelson 的論文 “Implementing Remote Procedure Calls” 中，他提到了幾個RPC的特點：

簡單：RPC 概念的語義十分清晰和簡單，這樣建立分布式計算就更容易。

高效：過程調用看起來十分簡單而且高效。

通用：在單機計算中過程往往是不同算法部分間最重要的通信機制。

除此之外，這位大佬還給出了實現 RPC 框架的詳細架構圖：

結合上圖，Nelson 的論文中指出實現 RPC 的進程包括 5 個部分：

User

User-stub

RPCRuntime

Server-stub

Server

User 是調用方

User-stub 負責將調用的接口、方法和參數通過約定的協議規范進行編碼

RPCRuntime 負責將本地數據傳輸到遠端的 RPCRuntime

Server-stub 負責根據約定的協議規范進行解碼

Server 是被調用方

所以這架構圖的意思是：當 user 想發起一個遠程調用時，它實際是通過本地調用 User-stub。并通過本地的 RPCRuntime 傳輸 。遠端 RPCRuntime 實例收到請求后交給 Server-stub 進行解碼后發起本地端調用，調用結果再返回給 User 端。

實現 RPC 協議需要什么

看完協議內容，跟著就得實現這個協議啦，這時候你是不是發現了問題的嚴重性：自！己！一！點！思！路！都！沒！有！

序列化協議和傳輸協議

所以我們需要再理解一下 RPC 協議，根據 Nelson 的論文知道我們要做的兩件事：

將調用的接口、方法和參數通過約定的協議規范進行編碼/解碼(User-stub/Server-stub)

將本地數據傳輸到遠端 (RPCRuntime)

上述兩點其實是實現 RPC 協議的兩大要素：序列化協議和傳輸協議。

本地與遠程調用的對比

因為 RPC 本質上是進程間通信，而 “本地調用和遠程調用的對比” 實際上就是 “進程內通信和進程間通信的對比”。通過兩者的對比，我們才能理解到序列化協議和傳輸協議的作用，如下圖：

理解單點式 RPC 框架和分布式 RPC 框架的區別

最基本的 RPC 框架就是單點式的，因為 A 服務直接調用 B 服務，不經過第三方，這種是最簡單的。但是必須是 A 和 B 同時部署一套，A1 只能調用 B1，A2 只能調用 B2。

假設現在 B 服務出現了性能瓶頸，部署多臺 B 服務的同時，也只能部署多臺 A 服務，很浪費資源。

所以需要一臺 A 服務對多臺 B 服務，利用第三方服務 (注冊中心) 找到其他 B 服務，而不是寫死 B 服務的地址。這種 RPC 才是分布式RPC，也是業內主流。

單點式 RPC 框架(自己玩自己)：

分布式 RPC 框架 (自己玩自己，還能玩別人)：

實現分布式 RPC 框架需要什么

單點 RPC 框架只需要：

序列化協議

傳輸協議

但是我們要做分布式的啊，所以需要：

序列化協議

傳輸協議

服務注冊發現中心

實際上在生產環境中，我們需要實時監控服務的調用情況，所以需要一個微服務管理中心，甚至是一個自動化運維的管理中心，所以需要：

序列化協議

傳輸協議

服務注冊發現中心

服務監控管理中心

在文章的第二節我們看到大佬論文中對 RPC 的總結，其中一個很重要的一點：“通用”。

對的，30 年前的初衷更大的是需要解決異構系統的服務調用問題，序列化協議和傳輸協議必須是通用的才是好的 RPC 框架，你總不能只能 Java 用，然后 C# 用不了，Scala 用不了，Go 用不了吧。

比如某個服務的并發需求高需要用 GO 來解決，因為以前用的 Java 性能低下。然后你的 RPC 框架不支持 GO，完蛋啦，中間的一個服務是 GO 寫的，上層服務是 Java 來調用的，不支持跨語言的 RPC，Go 語言寫的新服務完全用不了，那還玩個雞兒。

所以我們需要：

序列化協議

傳輸協議

服務注冊發現中心

服務監控管理中心

能跨語言調用(無關語言)

對的，能實現上述五點的，才是一個合格的 RPC 框架，但還不是優秀，因為我們還要考慮下性能。

說下業內流行的 RPC 框架和性能問題

先打個底，目前流行的 RPC 框架大多都是多管閑事，不單單只是 RPC 框架，你可以看看 Dubbo 和 SpringCloud 中除了 RPC 還有什么騷功能。

可以看看別人的各種 RPC 框架總結：http://www.cnblogs.com/moonandstar08/p/6291283.html

在網上找到了個圖，但是沒有提到 SpringCloud，暫且看看先，因為有些不認為是對的：

我們可以看到各個 RPC 框架使用的序列化協議，注冊中心，管理中心，是否跨語言，但是傳輸協議沒有提到。

性能問題

參考這篇博客：http://blog.csdn.net/jek123456/article/details/70208049

綜合來說，在性能上 rpcx 是首選，但是考慮到框架的生態，其實還是推薦 Dubbo 或者 SpringCloud 的，因為除了性能，成本也是很重要的，無論是學習成本還是研發成本。

感謝

總結

以上是生活随笔為你收集整理的rpc协议微服务器,RPC协议及实现方式(分布式微服务治理的核心)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。