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

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

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

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

Part1前言 扯一扯RPC的蛋

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

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

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

常見RPC有哪些？?

出鏡最多的要數(shù)dubbo，因?yàn)榭偙幻嬖嚬賳柕剑?/p>性能優(yōu)良的grpc，google出品，可以在任何環(huán)境下運(yùn)行；

美團(tuán)的OCTO和pigeon，一個(gè)章魚水里游，一個(gè)鴿子天上飛；

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

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

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

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

Stub 存根

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

路由尋址和負(fù)載均衡

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

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

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

序列化和反序列化

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

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

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

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

編碼 解碼

序列化之后為啥還要進(jìn)行編碼呢？

序列化其實(shí)是為了將待傳輸?shù)膶?duì)象轉(zhuǎn)化成標(biāo)準(zhǔn)二進(jìn)制信息，為傳遞做準(zhǔn)備，同時(shí)盡可能壓縮大小，方便傳輸。

而編碼，是為了通信高效，一般的，都會(huì)加上超時(shí)策略、請(qǐng)求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)品功能特性實(shí)現(xiàn)上，而不是重復(fù)地一遍遍制造通信框架的輪子。

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

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

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

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

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

‘建連’，一般因?yàn)槲覀儾捎瞄L連接心跳檢測(cè)，是可以保證這個(gè)時(shí)間相對(duì)穩(wěn)定。

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

Part4總結(jié)

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

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

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