[[321773]]

服務(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)
• 服務(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ù)體系來實(shí)現(xiàn)服務(wù)：

 

 

這樣的話，如果沒有統(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ù)化首要解決的問題。

什么是RPC?

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

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

先來看下什么是“近”，即“本地函數(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)用。

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

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

 

 

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

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

如果能夠?qū)崿F(xiàn)，那這就是“遠(yuǎn)程”過程調(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)文：

• 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è)步驟是：

(1)將傳入?yún)?shù)變?yōu)樽止?jié)流;

(2)將字節(jié)流發(fā)給服務(wù)B;

(3)從服務(wù)B接受返回字節(jié)流;

(4)將返回字節(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è)步驟也很好理解：

(1)服務(wù)端收到字節(jié)流;

(2)將字節(jié)流轉(zhuǎn)為函數(shù)名與參數(shù);

(3)本地調(diào)用函數(shù)得到結(jié)果;

(4)將結(jié)果轉(zhuǎn)變?yōu)樽止?jié)流;

(5)將字節(jié)流發(fā)送給調(diào)用方;

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

 

 

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

這個(gè)過程存在最大的問題是什么呢?

調(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è)問題的，它能夠讓調(diào)用方“像調(diào)用本地函數(shù)一樣調(diào)用遠(yuǎn)端的函數(shù)(服務(wù))”。

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

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

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

• 服務(wù)調(diào)用方client感覺就像調(diào)用本地函數(shù)一樣，來調(diào)用服務(wù)
• 服務(wù)提供方server感覺就像實(shí)現(xiàn)一個(gè)本地函數(shù)一樣，來實(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ù)大家了解的比較多，接下來重點(diǎn)講講client端的技術(shù)細(xì)節(jié)。

先來看看RPC-client部分的“序列化反序列化”部分。

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

工程師通常使用“對(duì)象”來進(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ù)庫索引的磁盤存儲(chǔ)：數(shù)據(jù)庫的索引在內(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ù)的過程。這個(gè)過程的逆過程叫做反序列化。

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

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

<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ì)象。

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

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

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

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

 

 

• 第一行：序號(hào)4個(gè)字節(jié)(設(shè)0表示類名)，類名長(zhǎng)度4個(gè)字節(jié)(長(zhǎng)度為4)，接下來4個(gè)字節(jié)是類名(”User”)，共12字節(jié)
• 第二行：序號(hào)4個(gè)字節(jié)(1表示第一個(gè)屬性)，屬性長(zhǎng)度4個(gè)字節(jié)(長(zhǎng)度為9)，接下來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)，接下來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)，接下來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)類型的語言不僅要還原屬性名，屬性值，還要還原屬性類型;復(fù)雜的對(duì)象不僅要考慮普通類型，還要考慮對(duì)象嵌套類型等。無論如何，序列化的思路都是類似的。

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

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

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

有哪些常見的序列化方式?

• xml/json：解析效率，壓縮率都較差，擴(kuò)展性、可讀性、通用性較好
• thrift
• protobuf：Google出品，必屬精品，各方面都不錯(cuò)，強(qiáng)烈推薦，屬于二進(jìn)制協(xié)議，可讀性差了點(diǎn)，但也有類似的to-string協(xié)議幫助調(diào)試問題
• Avro
• CORBA
• mc_pack：懂的同學(xué)就懂，不懂的就不懂了，09年用過，傳說各方面都超越protobuf，懂行的同學(xué)可以說一下現(xiàn)狀
• …

 

 

RPC-client除了：

• 序列化反序列化的部分(上圖中的1、4)

還包含：

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

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

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

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

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

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

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

處理結(jié)果通過回調(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)單的說明了一下組件、交互、流程步驟：

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

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

Result=Add(Obj1,Obj2)

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

3)通過連接池組件拿到一個(gè)可用的連接connection;

4)通過連接connection將包packet1發(fā)送給RPC-server;

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

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

7)通過連接connection從RPC-server收取響應(yīng)包packet2;

8)通過連接池組件，將conneciont放回連接池;

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

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

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

連接池組件有什么作用?

RPC框架鎖支持的負(fù)載均衡、故障轉(zhuǎn)移、發(fā)送超時(shí)等特性，都是通過連接池組件去實(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ù)后，再將連接加回來。

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

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

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

遺留問題，工作線程數(shù)設(shè)置為多少最合適?

這個(gè)問題在《工作線程數(shù)究竟要設(shè)置為多少最合適?》中討論過，此處不再深究。

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

 

 

所謂異步回調(diào)，在得到結(jié)果之前，不會(huì)處于阻塞狀態(tài)，理論上任何時(shí)間都沒有任何線程處于阻塞狀態(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í)行步驟：

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

Add(Obj1,Obj2, callback)

2)上下文管理器，將請(qǐng)求，回調(diào)，上下文存儲(chǔ)起來;

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

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

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

6)通過連接connection將包packet1發(fā)送給RPC-server;

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

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

9)通過連接connection從RPC-server收取響應(yīng)包packet2;

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

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

12)序列化組件，將packet2范序列化為Result對(duì)象;

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

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

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

15)上下文管理器，請(qǐng)求長(zhǎng)時(shí)間沒有返回;

16)超時(shí)管理器拿到超時(shí)的上下文;

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

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

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

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

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

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

這是一個(gè)很有意思的問題，通過一條連接往下游服務(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)?

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

 

 

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

1)生成請(qǐng)求id;

2)生成請(qǐng)求上下文context，上下文中包含發(fā)送時(shí)間time，回調(diào)函數(shù)callback等信息;

3)上下文管理器記錄req-id與上下文context的映射關(guān)系;

4)將req-id打在請(qǐng)求包里發(fā)給RPC-server;

5)RPC-server將req-id打在響應(yīng)包里返回;

6)由響應(yīng)包中的req-id，通過上下文管理器找到原來的上下文context;

7)從上下文context中拿到回調(diào)函數(shù)callback;

8)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來實(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í)間是否過長(zhǎng)，如果過長(zhǎng)，就不再等待回包，直接超時(shí)回調(diào)，推動(dòng)業(yè)務(wù)流程繼續(xù)往下走，并將上下文刪除掉。

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

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

無論如何，異步回調(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)景來選取。

總結(jié)

什么是RPC調(diào)用?

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

為什么需要RPC框架?

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

什么是序列化?為什么需要序列化?

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

同步RPC-client的核心組件是什么?

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

異步RPC-client的核心組件是什么?

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