《微服務(wù)架構(gòu)的六大好處，這一篇就夠用了》中提到，隨著數(shù)據(jù)量、并發(fā)量、業(yè)務(wù)復(fù)雜度的增長(zhǎng)，服務(wù)化是架構(gòu)演進(jìn)必由之路。

服務(wù)化離不開(kāi)RPC框架，今天和大家聊一聊RPC框架的原理、實(shí)踐及細(xì)節(jié)。萬(wàn)字長(zhǎng)文，建議提前收藏。

服務(wù)化有什么好處？

服務(wù)化的一個(gè)好處就是，不限定服務(wù)的提供方使用什么技術(shù)選型，能夠?qū)崿F(xiàn)大公司跨團(tuán)隊(duì)的技術(shù)解耦，如下圖所示：

• 服務(wù)A：歐洲團(tuán)隊(duì)維護(hù)，技術(shù)背景是Java；
• 服務(wù)B：美洲團(tuán)隊(duì)維護(hù)，用C++實(shí)現(xiàn)；
• 3服務(wù)C：中國(guó)團(tuán)隊(duì)維護(hù)，技術(shù)棧是go；

服務(wù)的上游調(diào)用方，按照接口、協(xié)議即可完成對(duì)遠(yuǎn)端服務(wù)的調(diào)用。

但實(shí)際上，大部分互聯(lián)網(wǎng)公司，研發(fā)團(tuán)隊(duì)規(guī)模有限，大都使用同一套技術(shù)體系來(lái)實(shí)現(xiàn)服務(wù)：

這樣的話，如果沒(méi)有統(tǒng)一的服務(wù)框架，各個(gè)團(tuán)隊(duì)的服務(wù)提供方就需要各自實(shí)現(xiàn)一套序列化、反序列化、網(wǎng)絡(luò)框架、連接池、收發(fā)線程、超時(shí)處理、狀態(tài)機(jī)等“業(yè)務(wù)之外”的重復(fù)技術(shù)勞動(dòng)，造成整體的低效。

因此，統(tǒng)一服務(wù)框架把上述“業(yè)務(wù)之外”的工作統(tǒng)一實(shí)現(xiàn)，是服務(wù)化首要解決的問(wèn)題。

什么是RPC？

Remote Procedure Call Protocol，遠(yuǎn)程過(guò)程調(diào)用。

什么是“遠(yuǎn)程”，為什么“遠(yuǎn)”？

先來(lái)看下什么是“近”，即“本地函數(shù)調(diào)用”。

當(dāng)我們寫下：

int result = Add(1, 2);

這行代碼的時(shí)候，到底發(fā)生了什么？

• 傳遞兩個(gè)入?yún)ⅲ?/li>
• 調(diào)用了本地代碼段中的函數(shù)，執(zhí)行運(yùn)算邏輯；
• 返回一個(gè)出參；

這三個(gè)動(dòng)作，都發(fā)生在同一個(gè)進(jìn)程空間里，這是本地函數(shù)調(diào)用。

那有沒(méi)有辦法，調(diào)用一個(gè)跨進(jìn)程的函數(shù)呢？

典型的，這個(gè)進(jìn)程部署在另一臺(tái)服務(wù)器上。

最容易想到的，兩個(gè)進(jìn)程約定一個(gè)協(xié)議格式，使用Socket通信，來(lái)傳輸：

• 入?yún)ⅲ?/li>
• 調(diào)用哪個(gè)函數(shù)；
• 出參；

如果能夠?qū)崿F(xiàn)，那這就是“遠(yuǎn)程”過(guò)程調(diào)用。

Socket通信只能傳遞連續(xù)的字節(jié)流，如何將入?yún)?、函?shù)都放到連續(xù)的字節(jié)流里呢？

假設(shè)，設(shè)計(jì)一個(gè)11字節(jié)的請(qǐng)求報(bào)文：

• 前3個(gè)字節(jié)填入函數(shù)名“add”；
• 中間4個(gè)字節(jié)填入第一個(gè)參數(shù)“1”；
• 末尾4個(gè)字節(jié)填入第二個(gè)參數(shù)“2”；

同理，可以設(shè)計(jì)一個(gè)4字節(jié)響應(yīng)報(bào)文：

1. 4個(gè)字節(jié)填入處理結(jié)果“3”；

調(diào)用方的代碼可能變?yōu)椋?/p>

request = MakePacket(“add”, 1, 2);
SendRequest_ToService_B(request);
response = RecieveRespnse_FromService_B();
int result = unMakePacket(respnse);

這4個(gè)步驟是：

• 將傳入?yún)?shù)變?yōu)樽止?jié)流；
• 將字節(jié)流發(fā)給服務(wù)B；
• 從服務(wù)B接受返回字節(jié)流；
• 將返回字節(jié)流變?yōu)閭鞒鰠?shù)；

服務(wù)方的代碼可能變?yōu)椋?/p>

request = RecieveRequest();
args/function = unMakePacket(request);
result = Add(1, 2);
response = MakePacket(result);
SendResponse(response);

這個(gè)5個(gè)步驟也很好理解：

• 服務(wù)端收到字節(jié)流；
• 將字節(jié)流轉(zhuǎn)為函數(shù)名與參數(shù)；
• 本地調(diào)用函數(shù)得到結(jié)果；
• 將結(jié)果轉(zhuǎn)變?yōu)樽止?jié)流；
• 將字節(jié)流發(fā)送給調(diào)用方；

這個(gè)過(guò)程用一張圖描述如下：

調(diào)用方與服務(wù)方的處理步驟都是非常清晰。

這個(gè)過(guò)程存在最大的問(wèn)題是什么呢？

調(diào)用方太麻煩了，每次都要關(guān)注很多底層細(xì)節(jié)：

• 入?yún)⒌阶止?jié)流的轉(zhuǎn)化，即序列化應(yīng)用層協(xié)議細(xì)節(jié)；
• socket發(fā)送，即網(wǎng)絡(luò)傳輸協(xié)議細(xì)節(jié)；
• socket接收；
• 字節(jié)流到出參的轉(zhuǎn)化，即反序列化應(yīng)用層協(xié)議細(xì)節(jié)；

能不能調(diào)用層不關(guān)注這個(gè)細(xì)節(jié)？

可以，RPC框架就是解決這個(gè)問(wèn)題的，它能夠讓調(diào)用方“像調(diào)用本地函數(shù)一樣調(diào)用遠(yuǎn)端的函數(shù)（服務(wù)）”。

講到這里，是不是對(duì)RPC，對(duì)序列化反序列化有點(diǎn)感覺(jué)了？往下看，有更多的底層細(xì)節(jié)。

RPC框架的職責(zé)是什么？

RPC框架，要向調(diào)用方屏蔽各種復(fù)雜性，要向服務(wù)提供方也屏蔽各類復(fù)雜性：

• 服務(wù)調(diào)用方client感覺(jué)就像調(diào)用本地函數(shù)一樣，來(lái)調(diào)用服務(wù)；
• 服務(wù)提供方server感覺(jué)就像實(shí)現(xiàn)一個(gè)本地函數(shù)一樣，來(lái)實(shí)現(xiàn)服務(wù)；

所以整個(gè)RPC框架又分為client部分與server部分，實(shí)現(xiàn)上面的目標(biāo)，把復(fù)雜性屏蔽，就是RPC框架的職責(zé)。

如上圖所示，業(yè)務(wù)方的職責(zé)是：

• 調(diào)用方A，傳入?yún)?shù)，執(zhí)行調(diào)用，拿到結(jié)果；
• 服務(wù)方B，收到參數(shù)，執(zhí)行邏輯，返回結(jié)果；

RPC框架的職責(zé)是，中間大藍(lán)框的部分：

• client端：序列化、反序列化、連接池管理、負(fù)載均衡、故障轉(zhuǎn)移、隊(duì)列管理，超時(shí)管理、異步管理等等；
• server端：服務(wù)端組件、服務(wù)端收發(fā)包隊(duì)列、io線程、工作線程、序列化反序列化等；

server端的技術(shù)大家了解的比較多，接下來(lái)重點(diǎn)講講client端的技術(shù)細(xì)節(jié)。

先來(lái)看看RPC-client部分的“序列化反序列化”部分。

為什么要進(jìn)行序列化？

工程師通常使用“對(duì)象”來(lái)進(jìn)行數(shù)據(jù)的操縱：

class User{
         std::String user_name;
         uint64_t user_id;
         uint32_t user_age;
}; 

User u = new User(“shenjian”);
u.setUid(123);
u.setAge(35);

但當(dāng)需要對(duì)數(shù)據(jù)進(jìn)行存儲(chǔ)或者傳輸時(shí)，“對(duì)象”就不這么好用了，往往需要把數(shù)據(jù)轉(zhuǎn)化成連續(xù)空間的“二進(jìn)制字節(jié)流”，一些典型的場(chǎng)景是：

• 數(shù)據(jù)庫(kù)索引的磁盤存儲(chǔ)：數(shù)據(jù)庫(kù)的索引在內(nèi)存里是b+樹，但這個(gè)格式是不能夠直接存儲(chǔ)到磁盤上的，所以需要把b+樹轉(zhuǎn)化為連續(xù)空間的二進(jìn)制字節(jié)流，才能存儲(chǔ)到磁盤上；
• 緩存的KV存儲(chǔ)：redis/memcache是KV類型的緩存，緩存存儲(chǔ)的value必須是連續(xù)空間的二進(jìn)制字節(jié)流，而不能夠是User對(duì)象；
• 數(shù)據(jù)的網(wǎng)絡(luò)傳輸：socket發(fā)送的數(shù)據(jù)必須是連續(xù)空間的二進(jìn)制字節(jié)流，也不能是對(duì)象；

所謂序列化（Serialization），就是將“對(duì)象”形態(tài)的數(shù)據(jù)轉(zhuǎn)化為“連續(xù)空間二進(jìn)制字節(jié)流”形態(tài)數(shù)據(jù)的過(guò)程。這個(gè)過(guò)程的逆過(guò)程叫做反序列化。

怎么進(jìn)行序列化？

這是一個(gè)非常細(xì)節(jié)的問(wèn)題，要是讓你來(lái)把“對(duì)象”轉(zhuǎn)化為字節(jié)流，你會(huì)怎么做？很容易想到的一個(gè)方法是xml（或者json）這類具有自描述特性的標(biāo)記性語(yǔ)言：

<class name=”User”>
<element name=”user_name” type=”std::String” value=”shenjian” />
<element name=”user_id” type=”uint64_t” value=”123” />
  <element name=”user_age” type=”uint32_t” value=”35” />
</class>

規(guī)定好轉(zhuǎn)換規(guī)則，發(fā)送方很容易把User類的一個(gè)對(duì)象序列化為xml，服務(wù)方收到xml二進(jìn)制流之后，也很容易將其反序列化為User對(duì)象。

畫外音：語(yǔ)言支持反射時(shí)，這個(gè)工作很容易。

第二個(gè)方法是自己實(shí)現(xiàn)二進(jìn)制協(xié)議來(lái)進(jìn)行序列化，還是以上面的User對(duì)象為例，可以設(shè)計(jì)一個(gè)這樣的通用協(xié)議：

• 頭4個(gè)字節(jié)表示序號(hào)；
• 序號(hào)后面的4個(gè)字節(jié)表示key的長(zhǎng)度m；
• 接下來(lái)的m個(gè)字節(jié)表示key的值；
• 接下來(lái)的4個(gè)字節(jié)表示value的長(zhǎng)度n；
• 接下來(lái)的n個(gè)字節(jié)表示value的值；
• 像xml一樣遞歸下去，直到描述完整個(gè)對(duì)象；

上面的User對(duì)象，用這個(gè)協(xié)議描述出來(lái)可能是這樣的：

• 第一行：序號(hào)4個(gè)字節(jié)（設(shè)0表示類名），類名長(zhǎng)度4個(gè)字節(jié)（長(zhǎng)度為4），接下來(lái)4個(gè)字節(jié)是類名（”User”），共12字節(jié)；
• 第二行：序號(hào)4個(gè)字節(jié)（1表示第一個(gè)屬性），屬性長(zhǎng)度4個(gè)字節(jié)（長(zhǎng)度為9），接下來(lái)9個(gè)字節(jié)是屬性名（”user_name”），屬性值長(zhǎng)度4個(gè)字節(jié)（長(zhǎng)度為8），屬性值8個(gè)字節(jié)（值為”shenjian”），共29字節(jié)；
• 第三行：序號(hào)4個(gè)字節(jié)（2表示第二個(gè)屬性），屬性長(zhǎng)度4個(gè)字節(jié)（長(zhǎng)度為7），接下來(lái)7個(gè)字節(jié)是屬性名（”user_id”），屬性值長(zhǎng)度4個(gè)字節(jié)（長(zhǎng)度為8），屬性值8個(gè)字節(jié)（值為123），共27字節(jié)；
• 第四行：序號(hào)4個(gè)字節(jié)（3表示第三個(gè)屬性），屬性長(zhǎng)度4個(gè)字節(jié)（長(zhǎng)度為8），接下來(lái)8個(gè)字節(jié)是屬性名（”user_name”），屬性值長(zhǎng)度4個(gè)字節(jié)（長(zhǎng)度為4），屬性值4個(gè)字節(jié)（值為35），共24字節(jié)；

整個(gè)二進(jìn)制字節(jié)流共12+29+27+24=92字節(jié)。

實(shí)際的序列化協(xié)議要考慮的細(xì)節(jié)遠(yuǎn)比這個(gè)多，例如：強(qiáng)類型的語(yǔ)言不僅要還原屬性名，屬性值，還要還原屬性類型；復(fù)雜的對(duì)象不僅要考慮普通類型，還要考慮對(duì)象嵌套類型等。無(wú)論如何，序列化的思路都是類似的。

序列化協(xié)議要考慮什么因素？

不管使用成熟協(xié)議xml/json，還是自定義二進(jìn)制協(xié)議來(lái)序列化對(duì)象，序列化協(xié)議設(shè)計(jì)時(shí)都需要考慮以下這些因素：

• 解析效率：這個(gè)應(yīng)該是序列化協(xié)議應(yīng)該首要考慮的因素，像xml/json解析起來(lái)比較耗時(shí)，需要解析doom樹，二進(jìn)制自定義協(xié)議解析起來(lái)效率就很高；
• 壓縮率，傳輸有效性：同樣一個(gè)對(duì)象，xml/json傳輸起來(lái)有大量的xml標(biāo)簽，信息有效性低，二進(jìn)制自定義協(xié)議占用的空間相對(duì)來(lái)說(shuō)就小多了；
• 擴(kuò)展性與兼容性：是否能夠方便的增加字段，增加字段后舊版客戶端是否需要強(qiáng)制升級(jí)，都是需要考慮的問(wèn)題，xml/json和上面的二進(jìn)制協(xié)議都能夠方便的擴(kuò)展；
• 可讀性與可調(diào)試性：這個(gè)很好理解，xml/json的可讀性就比二進(jìn)制協(xié)議好很多；
• 跨語(yǔ)言：上面的兩個(gè)協(xié)議都是跨語(yǔ)言的，有些序列化協(xié)議是與開(kāi)發(fā)語(yǔ)言緊密相關(guān)的，例如dubbo的序列化協(xié)議就只能支持Java的RPC調(diào)用；
• 通用性：xml/json非常通用，都有很好的第三方解析庫(kù)，各個(gè)語(yǔ)言解析起來(lái)都十分方便，上面自定義的二進(jìn)制協(xié)議雖然能夠跨語(yǔ)言，但每個(gè)語(yǔ)言都要寫一個(gè)簡(jiǎn)易的協(xié)議客戶端；

RPC-client除了：

• 序列化反序列化的部分（上圖中的1、4）；

還包含：

• 發(fā)送字節(jié)流與接收字節(jié)流的部分（上圖中的2、3）；

這一部分，又分為同步調(diào)用與異步調(diào)用兩種方式，下面一一來(lái)進(jìn)行介紹。

畫外音：搞通透RPC-client確實(shí)不容易。

同步調(diào)用的代碼片段為：

Result = Add(Obj1, Obj2);// 得到Result之前處于阻塞狀態(tài)

異步調(diào)用的代碼片段為：

Add(Obj1, Obj2, callback);// 調(diào)用后直接返回，不等結(jié)果

處理結(jié)果通過(guò)回調(diào)為：

callback(Result){// 得到處理結(jié)果后會(huì)調(diào)用這個(gè)回調(diào)函數(shù)
         …
}

這兩類調(diào)用，在RPC-client里，實(shí)現(xiàn)方式完全不一樣。

RPC-client同步調(diào)用架構(gòu)如何？

所謂同步調(diào)用，在得到結(jié)果之前，一直處于阻塞狀態(tài)，會(huì)一直占用一個(gè)工作線程，上圖簡(jiǎn)單的說(shuō)明了一下組件、交互、流程步驟：

• 左邊大框，代表了調(diào)用方的一個(gè)工作線程
• 左邊粉色中框，代表了RPC-client組件
• 右邊橙色框，代表了RPC-server
• 藍(lán)色兩個(gè)小框，代表了同步RPC-client兩個(gè)核心組件，序列化組件與連接池組件
• 白色的流程小框，以及箭頭序號(hào)1-10，代表整個(gè)工作線程的串行執(zhí)行步驟：

①業(yè)務(wù)代碼發(fā)起RPC調(diào)用：

Result=Add(Obj1,Obj2)

②序列化組件，將對(duì)象調(diào)用序列化成二進(jìn)制字節(jié)流，可理解為一個(gè)待發(fā)送的包packet1；

③通過(guò)連接池組件拿到一個(gè)可用的連接connection；

④通過(guò)連接connection將包packet1發(fā)送給RPC-server；

⑤發(fā)送包在網(wǎng)絡(luò)傳輸，發(fā)給RPC-server；

⑥響應(yīng)包在網(wǎng)絡(luò)傳輸，發(fā)回給RPC-client；

⑦通過(guò)連接connection從RPC-server收取響應(yīng)包packet2；

⑧通過(guò)連接池組件，將connection放回連接池；

⑨序列化組件，將packet2反序列化為Result對(duì)象返回給調(diào)用方；

⑩業(yè)務(wù)代碼獲取Result結(jié)果，工作線程繼續(xù)往下走；

畫外音：請(qǐng)對(duì)照架構(gòu)圖中的1-10步驟閱讀。

連接池組件有什么作用？

RPC框架鎖支持的負(fù)載均衡、故障轉(zhuǎn)移、發(fā)送超時(shí)等特性，都是通過(guò)連接池組件去實(shí)現(xiàn)的。

典型連接池組件對(duì)外提供的接口為：

int ConnectionPool::init(…);
Connection ConnectionPool::getConnection();
int ConnectionPool::putConnection(Connection t);

init做了些什么？

和下游RPC-server（一般是一個(gè)集群），建立N個(gè)tcp長(zhǎng)連接，即所謂的連接“池”。

getConnection做了些什么？

從連接“池”中拿一個(gè)連接，加鎖（置一個(gè)標(biāo)志位），返回給調(diào)用方。

putConnection做了些什么？

將一個(gè)分配出去的連接放回連接“池”中，解鎖（也是置一個(gè)標(biāo)志位）。

如何實(shí)現(xiàn)負(fù)載均衡？

連接池中建立了與一個(gè)RPC-server集群的連接，連接池在返回連接的時(shí)候，需要具備隨機(jī)性。

如何實(shí)現(xiàn)故障轉(zhuǎn)移？

連接池中建立了與一個(gè)RPC-server集群的連接，當(dāng)連接池發(fā)現(xiàn)某一個(gè)機(jī)器的連接異常后，需要將這個(gè)機(jī)器的連接排除掉，返回正常的連接，在機(jī)器恢復(fù)后，再將連接加回來(lái)。

如何實(shí)現(xiàn)發(fā)送超時(shí)？

因?yàn)槭峭阶枞{(diào)用，拿到一個(gè)連接后，使用帶超時(shí)的send/recv即可實(shí)現(xiàn)帶超時(shí)的發(fā)送和接收。

總的來(lái)說(shuō)，同步的RPC-client的實(shí)現(xiàn)是相對(duì)比較容易的，序列化組件、連接池組件配合多工作線程數(shù)，就能夠?qū)崿F(xiàn)。

RPC-client異步回調(diào)架構(gòu)如何？

所謂異步回調(diào)，在得到結(jié)果之前，不會(huì)處于阻塞狀態(tài)，理論上任何時(shí)間都沒(méi)有任何線程處于阻塞狀態(tài)，因此異步回調(diào)的模型，理論上只需要很少的工作線程與服務(wù)連接就能夠達(dá)到很高的吞吐量，如上圖所示：

• 左邊的框框，是少量工作線程（少數(shù)幾個(gè)就行了）進(jìn)行調(diào)用與回調(diào)
• 中間粉色的框框，代表了RPC-client組件
• 右邊橙色框，代表了RPC-server
• 藍(lán)色六個(gè)小框，代表了異步RPC-client六個(gè)核心組件：上下文管理器，超時(shí)管理器，序列化組件，下游收發(fā)隊(duì)列，下游收發(fā)線程，連接池組件
• 白色的流程小框，以及箭頭序號(hào)1-17，代表整個(gè)工作線程的串行執(zhí)行步驟：

①業(yè)務(wù)代碼發(fā)起異步RPC調(diào)用；

Add(Obj1,Obj2, callback)

②上下文管理器，將請(qǐng)求，回調(diào)，上下文存儲(chǔ)起來(lái)；

③序列化組件，將對(duì)象調(diào)用序列化成二進(jìn)制字節(jié)流，可理解為一個(gè)待發(fā)送的包packet1；

④下游收發(fā)隊(duì)列，將報(bào)文放入“待發(fā)送隊(duì)列”，此時(shí)調(diào)用返回，不會(huì)阻塞工作線程；

⑤下游收發(fā)線程，將報(bào)文從“待發(fā)送隊(duì)列”中取出，通過(guò)連接池組件拿到一個(gè)可用的連接connection；

⑥通過(guò)連接connection將包packet1發(fā)送給RPC-server；

⑦發(fā)送包在網(wǎng)絡(luò)傳輸，發(fā)給RPC-server；

⑧響應(yīng)包在網(wǎng)絡(luò)傳輸，發(fā)回給RPC-client；

⑨通過(guò)連接connection從RPC-server收取響應(yīng)包packet2；

⑩下游收發(fā)線程，將報(bào)文放入“已接受隊(duì)列”，通過(guò)連接池組件，將connection放回連接池；

?下游收發(fā)隊(duì)列里，報(bào)文被取出，此時(shí)回調(diào)將要開(kāi)始，不會(huì)阻塞工作線程；

?序列化組件，將packet2反序列化為Result對(duì)象；

?上下文管理器，將結(jié)果，回調(diào)，上下文取出；

?通過(guò)callback回調(diào)業(yè)務(wù)代碼，返回Result結(jié)果，工作線程繼續(xù)往下走；

如果請(qǐng)求長(zhǎng)時(shí)間不返回，處理流程是：

?上下文管理器，請(qǐng)求長(zhǎng)時(shí)間沒(méi)有返回；

?超時(shí)管理器拿到超時(shí)的上下文；

?通過(guò)timeout_cb回調(diào)業(yè)務(wù)代碼，工作線程繼續(xù)往下走；

畫外音：請(qǐng)配合架構(gòu)圖仔細(xì)看幾遍這個(gè)流程。

序列化組件和連接池組件上文已經(jīng)介紹過(guò)，收發(fā)隊(duì)列與收發(fā)線程比較容易理解。下面重點(diǎn)介紹上下文管理器與超時(shí)管理器這兩個(gè)總的組件。

為什么需要上下文管理器？

由于請(qǐng)求包的發(fā)送，響應(yīng)包的回調(diào)都是異步的，甚至不在同一個(gè)工作線程中完成，需要一個(gè)組件來(lái)記錄一個(gè)請(qǐng)求的上下文，把請(qǐng)求-響應(yīng)-回調(diào)等一些信息匹配起來(lái)。

如何將請(qǐng)求-響應(yīng)-回調(diào)這些信息匹配起來(lái)？

這是一個(gè)很有意思的問(wèn)題，通過(guò)一條連接往下游服務(wù)發(fā)送了a，b，c三個(gè)請(qǐng)求包，異步的收到了x，y，z三個(gè)響應(yīng)包：

怎么知道哪個(gè)請(qǐng)求包與哪個(gè)響應(yīng)包對(duì)應(yīng)？

怎么知道哪個(gè)響應(yīng)包與哪個(gè)回調(diào)函數(shù)對(duì)應(yīng)？

可以通過(guò)“請(qǐng)求id”來(lái)實(shí)現(xiàn)請(qǐng)求-響應(yīng)-回調(diào)的串聯(lián)。

整個(gè)處理流程如上，通過(guò)請(qǐng)求id，上下文管理器來(lái)對(duì)應(yīng)請(qǐng)求-響應(yīng)-callback之間的映射關(guān)系：

• 生成請(qǐng)求id；
• 生成請(qǐng)求上下文context，上下文中包含發(fā)送時(shí)間time，回調(diào)函數(shù)callback等信息；
• 上下文管理器記錄req-id與上下文context的映射關(guān)系；
• 將req-id打在請(qǐng)求包里發(fā)給RPC-server；
• RPC-server將req-id打在響應(yīng)包里返回；
• 由響應(yīng)包中的req-id，通過(guò)上下文管理器找到原來(lái)的上下文context；
• 從上下文context中拿到回調(diào)函數(shù)callback；
• callback將Result帶回，推動(dòng)業(yè)務(wù)的進(jìn)一步執(zhí)行；

如何實(shí)現(xiàn)負(fù)載均衡，故障轉(zhuǎn)移？

與同步的連接池思路類似，不同之處在于：

• 同步連接池使用阻塞方式收發(fā)，需要與一個(gè)服務(wù)的一個(gè)ip建立多條連接；
• 異步收發(fā)，一個(gè)服務(wù)的一個(gè)ip只需要建立少量的連接（例如，一條tcp連接）；

如何實(shí)現(xiàn)超時(shí)發(fā)送與接收？

超時(shí)收發(fā)，與同步阻塞收發(fā)的實(shí)現(xiàn)就不一樣了：

• 同步阻塞超時(shí)，可以直接使用帶超時(shí)的send/recv來(lái)實(shí)現(xiàn)；
• 異步非阻塞的nio的網(wǎng)絡(luò)報(bào)文收發(fā)，由于連接不會(huì)一直等待回包，超時(shí)是由超時(shí)管理器實(shí)現(xiàn)的；

超時(shí)管理器如何實(shí)現(xiàn)超時(shí)管理？

超時(shí)管理器，用于實(shí)現(xiàn)請(qǐng)求回包超時(shí)回調(diào)處理。

每一個(gè)請(qǐng)求發(fā)送給下游RPC-server，會(huì)在上下文管理器中保存req-id與上下文的信息，上下文中保存了請(qǐng)求很多相關(guān)信息，例如req-id，回包回調(diào)，超時(shí)回調(diào)，發(fā)送時(shí)間等。

超時(shí)管理器啟動(dòng)timer對(duì)上下文管理器中的context進(jìn)行掃描，看上下文中請(qǐng)求發(fā)送時(shí)間是否過(guò)長(zhǎng)，如果過(guò)長(zhǎng)，就不再等待回包，直接超時(shí)回調(diào)，推動(dòng)業(yè)務(wù)流程繼續(xù)往下走，并將上下文刪除掉。

如果超時(shí)回調(diào)執(zhí)行后，正常的回包又到達(dá)，通過(guò)req-id在上下文管理器里找不到上下文，就直接將請(qǐng)求丟棄。

畫外音：因?yàn)橐呀?jīng)超時(shí)處理了，無(wú)法恢復(fù)上下文。

無(wú)論如何，異步回調(diào)和同步回調(diào)相比，除了序列化組件和連接池組件，會(huì)多出上下文管理器，超時(shí)管理器，下游收發(fā)隊(duì)列，下游收發(fā)線程等組件，并且對(duì)調(diào)用方的調(diào)用習(xí)慣有影響。

畫外音：編程習(xí)慣，由同步變?yōu)榱嘶卣{(diào)。

異步回調(diào)能提高系統(tǒng)整體的吞吐量，具體使用哪種方式實(shí)現(xiàn)RPC-client，可以結(jié)合業(yè)務(wù)場(chǎng)景來(lái)選取。

稍作總結(jié)

(1) 什么是RPC調(diào)用？

像調(diào)用本地函數(shù)一樣，調(diào)用一個(gè)遠(yuǎn)端服務(wù)。

(2) 為什么需要RPC框架？

RPC框架用于屏蔽RPC調(diào)用過(guò)程中的序列化，網(wǎng)絡(luò)傳輸?shù)燃夹g(shù)細(xì)節(jié)。讓調(diào)用方只專注于調(diào)用，服務(wù)方只專注于實(shí)現(xiàn)調(diào)用。

(3) 什么是序列化？為什么需要序列化？

把對(duì)象轉(zhuǎn)化為連續(xù)二進(jìn)制流的過(guò)程，叫做序列化。磁盤存儲(chǔ)，緩存存儲(chǔ)，網(wǎng)絡(luò)傳輸只能操作于二進(jìn)制流，所以必須序列化。

(4) 同步RPC-client的核心組件是什么？

同步RPC-client的核心組件是序列化組件、連接池組件。它通過(guò)連接池來(lái)實(shí)現(xiàn)負(fù)載均衡與故障轉(zhuǎn)移，通過(guò)阻塞的收發(fā)來(lái)實(shí)現(xiàn)超時(shí)處理。

(5) 異步RPC-client的核心組件是什么？

異步RPC-client的核心組件是序列化組件、連接池組件、收發(fā)隊(duì)列、收發(fā)線程、上下文管理器、超時(shí)管理器。它通過(guò)“請(qǐng)求id”來(lái)關(guān)聯(lián)請(qǐng)求包-響應(yīng)包-回調(diào)函數(shù)，用上下文管理器來(lái)管理上下文，用超時(shí)管理器中的timer觸發(fā)超時(shí)回調(diào)，推進(jìn)業(yè)務(wù)流程的超時(shí)處理。

知其然，知其所以然。

思路比結(jié)論更重要。