分布式微服務(wù)治理的核心在于: 微服務(wù)和分布式

(微服務(wù)框架)微服務(wù)的最優(yōu)技術(shù)實(shí)現(xiàn)目前是: SpringBoot

(RPC 框架)分布式的最優(yōu)技術(shù)實(shí)現(xiàn)目前是: Thrift,Motan,Dubbo,Spring Cloud(Netflix OSS),Finagle,gRPC

RPC 是什么

RPC 的全稱是 Remote Procedure Call ，是一種進(jìn)程間通信方式。

它允許進(jìn)程調(diào)用另一個(gè)地址空間的過程或函數(shù)，而不用進(jìn)程員顯式編碼這個(gè)遠(yuǎn)程調(diào)用的細(xì)節(jié)，進(jìn)程員無論是調(diào)用本地的還是遠(yuǎn)程的，本質(zhì)上編寫的調(diào)用代碼基本相同。

說兩臺(tái)服務(wù)器 A、B，一個(gè)應(yīng)用部署在 A 服務(wù)器上，想要調(diào)用 B 服務(wù)器上應(yīng)用提供的函數(shù)/方法，由于不在一個(gè)內(nèi)存空間，不能直接調(diào)用，需要通過網(wǎng)絡(luò)來表達(dá)調(diào)用的語義和傳達(dá)調(diào)用的數(shù)據(jù)。

Remote Procedure Call，翻譯過來應(yīng)該是 “遠(yuǎn)程進(jìn)程調(diào)用”，目前業(yè)內(nèi)通用的翻譯是 “遠(yuǎn)程過程調(diào)用”，但是 “過程” 這個(gè)詞很容易造成誤解，翻譯成 “進(jìn)程” 更好理解 RPC 的意義。

RPC 協(xié)議說了什么

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

RPC 這個(gè)概念術(shù)語在上世紀(jì) 80 年代由 Bruce Jay Nelson 提出的，在 Nelson 的論文 “Implementing Remote Procedure Calls” 中，他提到了幾個(gè)RPC的特點(diǎn)：

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

高效：過程調(diào)用看起來十分簡(jiǎn)單而且高效。

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

除此之外，這位大佬還給出了實(shí)現(xiàn) RPC 框架的詳細(xì)架構(gòu)圖：

結(jié)合上圖，Nelson 的論文中指出實(shí)現(xiàn) RPC 的進(jìn)程包括 5 個(gè)部分：

User

User-stub

RPCRuntime

Server-stub

Server

User 是調(diào)用方

User-stub 負(fù)責(zé)將調(diào)用的接口、方法和參數(shù)通過約定的協(xié)議規(guī)范進(jìn)行編碼

RPCRuntime 負(fù)責(zé)將本地?cái)?shù)據(jù)傳輸?shù)竭h(yuǎn)端的 RPCRuntime

Server-stub 負(fù)責(zé)根據(jù)約定的協(xié)議規(guī)范進(jìn)行解碼

Server 是被調(diào)用方

所以這架構(gòu)圖的意思是：當(dāng) user 想發(fā)起一個(gè)遠(yuǎn)程調(diào)用時(shí)，它實(shí)際是通過本地調(diào)用 User-stub。并通過本地的 RPCRuntime 傳輸 。遠(yuǎn)端 RPCRuntime 實(shí)例收到請(qǐng)求后交給 Server-stub 進(jìn)行解碼后發(fā)起本地端調(diào)用，調(diào)用結(jié)果再返回給 User 端。

實(shí)現(xiàn) RPC 協(xié)議需要什么

看完協(xié)議內(nèi)容，跟著就得實(shí)現(xiàn)這個(gè)協(xié)議啦，這時(shí)候你是不是發(fā)現(xiàn)了問題的嚴(yán)重性：自！己！一！點(diǎn)！思！路！都！沒！有！

序列化協(xié)議和傳輸協(xié)議

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

將調(diào)用的接口、方法和參數(shù)通過約定的協(xié)議規(guī)范進(jìn)行編碼/解碼(User-stub/Server-stub)

將本地?cái)?shù)據(jù)傳輸?shù)竭h(yuǎn)端 (RPCRuntime)

上述兩點(diǎn)其實(shí)是實(shí)現(xiàn) RPC 協(xié)議的兩大要素：序列化協(xié)議和傳輸協(xié)議。

本地與遠(yuǎn)程調(diào)用的對(duì)比

因?yàn)?RPC 本質(zhì)上是進(jìn)程間通信，而 “本地調(diào)用和遠(yuǎn)程調(diào)用的對(duì)比” 實(shí)際上就是 “進(jìn)程內(nèi)通信和進(jìn)程間通信的對(duì)比”。通過兩者的對(duì)比，我們才能理解到序列化協(xié)議和傳輸協(xié)議的作用，如下圖：

理解單點(diǎn)式 RPC 框架和分布式 RPC 框架的區(qū)別

最基本的 RPC 框架就是單點(diǎn)式的，因?yàn)?A 服務(wù)直接調(diào)用 B 服務(wù)，不經(jīng)過第三方，這種是最簡(jiǎn)單的。但是必須是 A 和 B 同時(shí)部署一套，A1 只能調(diào)用 B1，A2 只能調(diào)用 B2。

假設(shè)現(xiàn)在 B 服務(wù)出現(xiàn)了性能瓶頸，部署多臺(tái) B 服務(wù)的同時(shí)，也只能部署多臺(tái) A 服務(wù)，很浪費(fèi)資源。

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

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

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

實(shí)現(xiàn)分布式 RPC 框架需要什么

單點(diǎn) RPC 框架只需要：

序列化協(xié)議

傳輸協(xié)議

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

序列化協(xié)議

傳輸協(xié)議

服務(wù)注冊(cè)發(fā)現(xiàn)中心

實(shí)際上在生產(chǎn)環(huán)境中，我們需要實(shí)時(shí)監(jiān)控服務(wù)的調(diào)用情況，所以需要一個(gè)微服務(wù)管理中心，甚至是一個(gè)自動(dòng)化運(yùn)維的管理中心，所以需要：

序列化協(xié)議

傳輸協(xié)議

服務(wù)注冊(cè)發(fā)現(xiàn)中心

服務(wù)監(jiān)控管理中心

在文章的第二節(jié)我們看到大佬論文中對(duì) RPC 的總結(jié)，其中一個(gè)很重要的一點(diǎn)：“通用”。

對(duì)的，30 年前的初衷更大的是需要解決異構(gòu)系統(tǒng)的服務(wù)調(diào)用問題，序列化協(xié)議和傳輸協(xié)議必須是通用的才是好的 RPC 框架，你總不能只能 Java 用，然后 C# 用不了，Scala 用不了，Go 用不了吧。

比如某個(gè)服務(wù)的并發(fā)需求高需要用 GO 來解決，因?yàn)橐郧坝玫?Java 性能低下。然后你的 RPC 框架不支持 GO，完蛋啦，中間的一個(gè)服務(wù)是 GO 寫的，上層服務(wù)是 Java 來調(diào)用的，不支持跨語言的 RPC，Go 語言寫的新服務(wù)完全用不了，那還玩?zhèn)€雞兒。

所以我們需要：

序列化協(xié)議

傳輸協(xié)議

服務(wù)注冊(cè)發(fā)現(xiàn)中心

服務(wù)監(jiān)控管理中心

能跨語言調(diào)用(無關(guān)語言)

對(duì)的，能實(shí)現(xiàn)上述五點(diǎn)的，才是一個(gè)合格的 RPC 框架，但還不是優(yōu)秀，因?yàn)槲覀冞€要考慮下性能。

說下業(yè)內(nèi)流行的 RPC 框架和性能問題

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

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

在網(wǎng)上找到了個(gè)圖，但是沒有提到 SpringCloud，暫且看看先，因?yàn)橛行┎徽J(rèn)為是對(duì)的：

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

性能問題

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

綜合來說，在性能上 rpcx 是首選，但是考慮到框架的生態(tài)，其實(shí)還是推薦 Dubbo 或者 SpringCloud 的，因?yàn)槌诵阅?#xff0c;成本也是很重要的，無論是學(xué)習(xí)成本還是研發(fā)成本。

感謝

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。