只要涉及到分布式服務(wù)，就繞不開RPC調(diào)用。RPC是什么，我認為大部分同學都能說出個一二三。

那么RPC一次調(diào)用，到底經(jīng)歷了哪些過程？

一直在說RPC耗時優(yōu)化，那到底時間耗在了哪里？?

本篇帶大家一起來梳理清晰。再遇到面試官問RPC，直接滅丫

Part1前言 扯一扯RPC的蛋

RPC ？（Remote Procedure Call） 遠程過程調(diào)用，目的是讓調(diào)用遠程服務(wù)的體驗，就像調(diào)用本地方法一樣簡單。

已經(jīng)有了HTTP，為啥還要實現(xiàn)個RPC？ 首先，兩者不在一個水平面，不好比較。http是一種傳輸協(xié)議，RPC由TCP傳輸協(xié)議和其他部分組成，算是一種架構(gòu)；再者，效率和性能有所差異，Http相比tcp傳輸更耗性能；再再者，定位不同，Rpc一般用于實現(xiàn)內(nèi)部網(wǎng)絡(luò)各服務(wù)間的高性能調(diào)用，Http一般用于跨環(huán)境的數(shù)據(jù)傳輸和接口調(diào)用。

RPC亙古不變的三個主題？ 客戶端、服務(wù)端、注冊中心。后續(xù)包括服務(wù)注冊、服務(wù)發(fā)現(xiàn)、路由尋址、序列化、IO模型等等事項，都是在圍繞三者之間的合作和交互來進行的。

常見RPC有哪些？?

出鏡最多的要數(shù)dubbo，因為總被面試官問到；

性能優(yōu)良的grpc，google出品，可以在任何環(huán)境下運行；

美團的OCTO和pigeon，一個章魚水里游，一個鴿子天上飛；

京東之前的saf，是對dubbo的定制化開發(fā)，后面升級到了自研的jsf框架，其作者之一的章老板之前就已經(jīng)是螞蟻的P8大佬了；

螞蟻自研的sofaRPC也有章老板的參與，由于設(shè)計初衷和螞蟻內(nèi)部的使用規(guī)模，功能豐富度和服務(wù)穩(wěn)定性上，那是相當不錯，目前也已經(jīng)開源。

Part2一次RPC調(diào)用的心路歷程

如上圖所示，一次rpc調(diào)用的過程，基本都囊括在內(nèi)：

Stub 存根

處于真正調(diào)用之前。進行場景判斷、條件過濾等，以dubbo為例，可以用于壓測場景的數(shù)據(jù)mock等功能支持。

路由尋址和負載均衡

上面的圖其實有點不太準確，路由尋址和服務(wù)節(jié)點的負載均衡應該是一起完成的，在選定provider之后就是直連了。圖里只是為了對稱一些好看。

尋址： 以safa為例，支持直連和注冊中心尋址。實現(xiàn)方案是在地址維護器中按配置加載直連分組和集群分組，在客戶端指定路由策略時，進行分別獲取。

負載均衡： safa在負載算法上要支持的相對更全面一些：一致性hash、本機優(yōu)先、隨機負載、輪詢負載、加權(quán)一致性hash、加權(quán)輪詢。

序列化和反序列化

序列化方式有很多種，包括jdk原生，kryo、hessian、protoStuff,thrift，JSON等。

這里挑兩個經(jīng)常使用，但是經(jīng)常遇坑的來說下：

hessian： 相比于Java原生序列化，效率更高、數(shù)據(jù)更小，但是需要注意，hessian反序列化時，是將屬性都取出來放到map里，因此，如果父類和子類有name相同的屬性，子類的會被覆蓋，因此，使用hessian時，要注意父子類不能有相同的屬性名。

protoStuff： ?相比Protobuf，stuff不需要寫.proto文件，效率上甚至比Protobuf更快。而快的原因之一，就是因為其序列化方式是按對象屬性的順序來執(zhí)行的，所以，如果順序變了，就會反序列化失敗。因此，在對使用了protoStuff序列化方式的對象新增字段時，最好是加到最后。

編碼 解碼

序列化之后為啥還要進行編碼呢？

序列化其實是為了將待傳輸?shù)膶ο筠D(zhuǎn)化成標準二進制信息，為傳遞做準備，同時盡可能壓縮大小，方便傳輸。

而編碼，是為了通信高效，一般的，都會加上超時策略、請求ID、網(wǎng)絡(luò)協(xié)議等信息。

網(wǎng)絡(luò)傳輸

一般大部分的RPC都選netty作為通信框架，而在底層是TCP的傳輸協(xié)議，而在上層，還有一層通信協(xié)議：

• Bolt，RPC私有協(xié)議，sofa所屬
• Dubbo，RPC私有化協(xié)議
• Hessian，RPC公有化協(xié)議
• thrift，F(xiàn)acebook出品，
• 還有如RESTful等其他通信協(xié)議

通信協(xié)議的目的，是為了讓中間件開發(fā)者能將更多的精力放在產(chǎn)品功能特性實現(xiàn)上，而不是重復地一遍遍制造通信框架的輪子。

Part3RPC執(zhí)行耗時都耗在了哪里

從上圖分析中可以看出一次rpc調(diào)用的具體耗時節(jié)點。

對于客戶端來說，耗時主要由：建連時間? 序列化時間? 等待服務(wù)端處理時間 組成；

對于服務(wù)端來說，耗時主要由：線程池等待時間 ?服務(wù)處理時間 ?結(jié)果序列化時間 組成。

所以，對于我們一線開發(fā)，如果要對RPC耗時進行調(diào)優(yōu)，最需要關(guān)注的，有客戶端的路由尋址、序列化方式，有服務(wù)端的服務(wù)線程池等待、反序列化、服務(wù)端處理速率、結(jié)果序列化 這幾塊。

‘建連’，一般因為我們采用長連接心跳檢測，是可以保證這個時間相對穩(wěn)定。

比如，借鑒sofa，用增量更新的直接分組，來加速路由尋址；采用速度更快的序列化策略；調(diào)整服務(wù)端線程池到合適的大小，即能滿足請求處理，又不至于增加過多的線程切換損耗；用異步調(diào)用的方式替代同步阻塞等等。

Part4總結(jié)

本文從RPC的一次調(diào)用觸發(fā)，結(jié)合一些開源的框架代碼，給大家梳理了RPC的調(diào)用過程和耗時分析。讓大家對RPC調(diào)用有一個更直觀的體會。特別是耗時分析這一部分，對我們一線研發(fā)的開發(fā)有些直接的指導意義。

希望大家能有所得，有任何問題，歡迎留言指正、探討~

題外話：不知道大家有沒有發(fā)現(xiàn)，我們平常接觸的框架、系統(tǒng)，好大一部分都來自阿里，為什么呢？一方面是因為技術(shù)確實不錯，畢竟龐大的用戶群和復雜的業(yè)務(wù)場景對任何系統(tǒng)、任何技術(shù)人都是非常好的磨刀石；不過我覺得，其他大廠的框架應該也不會差多少。只不過阿里有一群專門的人出來到處演講、吹牛逼，我們親切的稱其為"布道者"。。。O(∩_∩)O~ ?純屬瞎扯，娛樂一下~