分布式微服務(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 的全稱(chēng)是 Remote Procedure Call ，是一種進(jìn)程間通信方式澳骤。
• 它允許程序調(diào)用另一個(gè)地址空間的過(guò)程或函數(shù)晋渺，而不用程序員顯式編碼這個(gè)遠(yuǎn)程調(diào)用的細(xì)節(jié)，程序員無(wú)論是調(diào)用本地的還是遠(yuǎn)程的朝卒，本質(zhì)上編寫(xiě)的調(diào)用代碼基本相同。
• 說(shuō)兩臺(tái)服務(wù)器A乐埠、B抗斤，一個(gè)應(yīng)用部署在A服務(wù)器上，想要調(diào)用B服務(wù)器上應(yīng)用提供的函數(shù)/方法丈咐，由于不在一個(gè)內(nèi)存空間瑞眼，不能直接調(diào)用，需要通過(guò)網(wǎng)絡(luò)來(lái)表達(dá)調(diào)用的語(yǔ)義和傳達(dá)調(diào)用的數(shù)據(jù)棵逊。

Remote Procedure Call伤疙，翻譯過(guò)來(lái)應(yīng)該是“遠(yuǎn)程程序調(diào)用”，目前業(yè)內(nèi)通用的翻譯是“遠(yuǎn)程過(guò)程調(diào)用”辆影，但是“過(guò)程”這個(gè)詞很容易造成誤解掩浙，翻譯成“程序”更好理解RPC的意義。

RPC協(xié)議說(shuō)了什么

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

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

1. 簡(jiǎn)單：RPC 概念的語(yǔ)義十分清晰和簡(jiǎn)單，這樣建立分布式計(jì)算就更容易造虎。
2. 高效：過(guò)程調(diào)用看起來(lái)十分簡(jiǎn)單而且高效傅蹂。
3. 通用：在單機(jī)計(jì)算中過(guò)程往往是不同算法部分間最重要的通信機(jī)制。

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

image.png

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

1. User
2. User-stub
3. RPCRuntime
4. Server-stub
5. Server

1. User 是調(diào)用方
2. User-stub 負(fù)責(zé)將調(diào)用的接口、方法和參數(shù)通過(guò)約定的協(xié)議規(guī)范進(jìn)行編碼
3. RPCRuntime 負(fù)責(zé)將本地?cái)?shù)據(jù)傳輸?shù)竭h(yuǎn)端的RPCRuntime
4. Server-stub 負(fù)責(zé)根據(jù)約定的協(xié)議規(guī)范進(jìn)行解碼
5. Server 是被調(diào)用方

所以這架構(gòu)圖的意思是：當(dāng) user 想發(fā)起一個(gè)遠(yuǎn)程調(diào)用時(shí)氓轰，它實(shí)際是通過(guò)本地調(diào)用 User-stub婚夫。并通過(guò)本地的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)了問(wèn)題的嚴(yán)重性：自时捌！己！一炉抒！點(diǎn)奢讨！思！路端礼！都禽笑！沒(méi)入录！有蛤奥！

image.png

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

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

1. 將調(diào)用的接口僚稿、方法和參數(shù)通過(guò)約定的協(xié)議規(guī)范進(jìn)行編碼/解碼（User-stub/Server-stub）
2. 將本地?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)镽PC本質(zhì)上是進(jìn)程間通信，而“本地調(diào)用和遠(yuǎn)程調(diào)用的對(duì)比”實(shí)際上就是“進(jìn)程內(nèi)通信和進(jìn)程間通信的對(duì)比”蚀同。通過(guò)兩者的對(duì)比缅刽，我們才能理解到序列化協(xié)議和傳輸協(xié)議的作用，如下圖：

image.png

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

最基本的RPC框架就是單點(diǎn)式的蠢络，因?yàn)锳服務(wù)直接調(diào)用B服務(wù)衰猛，不經(jīng)過(guò)第三方，這種是最簡(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ù)，而不是寫(xiě)死B服務(wù)的地址徐鹤。這種RPC才是分布式RPC垃环，也是業(yè)內(nèi)主流。

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

  
  
  image.png

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

  
  
  image.png

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

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

1. 序列化協(xié)議
2. 傳輸協(xié)議

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

1. 序列化協(xié)議
2. 傳輸協(xié)議
3. 服務(wù)注冊(cè)發(fā)現(xiàn)中心

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

1. 序列化協(xié)議
2. 傳輸協(xié)議
3. 服務(wù)注冊(cè)發(fā)現(xiàn)中心
4. 服務(wù)監(jiān)控管理中心

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

• 對(duì)的，30年前的初衷更大的是需要解決異構(gòu)系統(tǒng)的服務(wù)調(diào)用問(wèn)題预厌，序列化協(xié)議和傳輸協(xié)議必須是通用的才是好的RPC框架阿迈，你總不能只能Java用，然后C#用不了轧叽，Scala用不了苗沧，Go用不了吧。
• 比如某個(gè)服務(wù)的并發(fā)需求高需要用GO來(lái)解決炭晒，因?yàn)橐郧坝玫腏ava性能低下待逞。然后你的RPC框架不支持GO，完蛋啦网严，中間的一個(gè)服務(wù)是GO寫(xiě)的识樱，上層服務(wù)是Java來(lái)調(diào)用的，不支持跨語(yǔ)言的RPC震束，Go語(yǔ)言寫(xiě)的新服務(wù)完全用不了怜庸，那還玩?zhèn)€雞兒。

所以我們需要：

1. 序列化協(xié)議
2. 傳輸協(xié)議
3. 服務(wù)注冊(cè)發(fā)現(xiàn)中心
4. 服務(wù)監(jiān)控管理中心
5. 能跨語(yǔ)言調(diào)用（無(wú)關(guān)語(yǔ)言）

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

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

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

尤其是SpringCloud，很難分類(lèi)涌献，自己就是一個(gè)集成框架胚宦，把微服務(wù)框架SpringBoot集成進(jìn)來(lái)了，把別人的注冊(cè)發(fā)現(xiàn)服務(wù)集成進(jìn)來(lái)了燕垃，本身自己又支持RPC枢劝，所以這貨壓根就不是一個(gè)單純的RPC框架，簡(jiǎn)直就是一整套分布式微服務(wù)治理的解決方案卜壕！

可以看看別人的各種RPC框架總結(jié)：http://www.cnblogs.com/moonandstar08/p/6291283.html
在網(wǎng)上找到了個(gè)圖您旁，但是沒(méi)有提到SpringCloud，暫且看看先轴捎，因?yàn)橛行┎徽J(rèn)為是對(duì)的：

image.png

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

性能問(wèn)題

參考這篇博客：http://blog.csdn.net/jek123456/article/details/70208049
綜合來(lái)說(shuō)秦驯，在性能上rpcx是首選尺碰，但是考慮到框架的生態(tài)，其實(shí)還是推薦Dubbo或者SpringCloud的译隘，因?yàn)槌诵阅芮浊牛杀疽彩呛苤匾模瑹o(wú)論是學(xué)習(xí)成本還是研發(fā)成本固耘。

感謝

• moonandstar08
• NullPointerExcept
• mindwind