歡迎光臨
每天分享高質量文章

離不開的微服務架構,脫不開的RPC細節(值得收藏)!!!

點擊▲關註 “資料和雲”   給公眾號標星置頂

更多精彩 第一時間直達

 

微服務離不開RPC框架,RPC框架的原理、實踐及細節,是本篇要分享的內容。

服務化有什麼好處?

服務化的一個好處就是,不限定服務的提供方使用什麼技術選型,能夠實現大公司跨團隊的技術解耦,如下圖所示:

  • 服務A:歐洲團隊維護,技術背景是Java

  • 服務B:美洲團隊維護,用C++實現

  • 服務C:中國團隊維護,技術棧是go

服務的上游呼叫方,按照接口、協議即可完成對遠端服務的呼叫。

 

但實際上,大部分互聯網公司,研發團隊規模有限,大都使用同一套技術體系來實現服務


這樣的話,如果沒有統一的服務框架,各個團隊的服務提供方就需要各自實現一套序列化、反序列化、網絡框架、連接池、收發執行緒、超時處理、狀態機等“業務之外”的重覆技術勞動,造成整體的低效。

因此,統一服務框架把上述“業務之外”的工作統一實現,是服務化首要解決的問題。

什麼是RPC?

Remote Procedure Call Protocol,遠程過程呼叫。

什麼是“遠程”,為什麼“遠”?

先來看下什麼是“近”,即“本地函式呼叫”。

當我們寫下:

int result = Add(12);

這行代碼的時候,到底發生了什麼?

  • 傳遞兩個入參

  • 呼叫了本地代碼段中的函式,執行運算邏輯

  • 傳回一個出參

這三個動作,都發生在同一個行程空間里,這是本地函式呼叫

 

那有沒有辦法,呼叫一個跨行程的函式呢?

典型的,這個行程部署在另一臺服務器上。


 

最容易想到的,兩個行程約定一個協議格式,使用Socket通信,來傳輸:

  • 入參

  • 呼叫哪個函式

  • 出參

如果能夠實現,那這就是“遠程”過程呼叫。

Socket通信只能傳遞連續的位元組流,如何將入參、函式都放到連續的位元組流里呢?

假設,設計一個11位元組的請求報文:

  • 前3個位元組填入函式名“add”

  • 中間4個位元組填入第一個引數“1”

  • 末尾4個位元組填入第二個引數“2”

同理,可以設計一個4位元組響應報文:

  • 4個位元組填入處理結果“3”

呼叫方的代碼可能變為:

request = MakePacket(“add”, 1, 2);

SendRequest_ToService_B(request);

response = RecieveRespnse_FromService_B();

int result = unMakePacket(respnse);

這4個步驟是:

(1)將傳入引數變為位元組流;

(2)將位元組流發給服務B;

(3)從服務B接受傳回位元組流;

(4)將傳回位元組流變為傳出引數;

 

服務方的代碼可能變為:

request = RecieveRequest();

args/function = unMakePacket(request);

result = Add(1, 2);

response = MakePacket(result);

SendResponse(response);

 

這個5個步驟也很好理解:

(1)服務端收到位元組流;

(2)將位元組流轉為函式名與引數;

(3)本地呼叫函式得到結果;

(4)將結果轉變為位元組流;

(5)將位元組流發送給呼叫方;

 

這個過程用一張圖描述如下:


呼叫方與服務方的處理步驟都是非常清晰。

這個過程存在最大的問題是什麼呢?

呼叫方太麻煩了,每次都要關註很多底層細節:

  • 入參到位元組流的轉化,即序列化應用層協議細節

  • socket發送,即網絡傳輸協議細節

  • socket接收

  • 位元組流到出參的轉化,即反序列化應用層協議細節

 

能不能呼叫層不關註這個細節?

可以,RPC框架就是解決這個問題的,它能夠讓呼叫方“像呼叫本地函式一樣呼叫遠端的函式(服務)”。

講到這裡,是不是對RPC,對序列化範序列化有點感覺了?往下看,有更多的底層細節。

 

RPC框架的職責是什麼?

RPC框架,要向呼叫方屏蔽各種複雜性,要向服務提供方也屏蔽各類複雜性:

  • 服務呼叫方client感覺就像呼叫本地函式一樣,來呼叫服務

  • 服務提供方server感覺就像實現一個本地函式一樣,來實現服務

所以整個RPC框架又分為client部分server部分,實現上面的標的,把複雜性屏蔽,就是RPC框架的職責。


如上圖所示,業務方的職責是:

  • 呼叫方A,傳入引數,執行呼叫,拿到結果

  • 服務方B,收到引數,執行邏輯,傳回結果

RPC框架的職責是,中間大藍框的部分:

  • client端:序列化、反序列化、連接池管理、負載均衡、故障轉移、佇列管理,超時管理、異步管理等等

  • server端:服務端組件、服務端收發包佇列、io執行緒、工作執行緒、序列化反序列化等

 

server端的技術大家瞭解的比較多,接下來重點講講client端的技術細節。

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

 

為什麼要進行序列化?

工程師通常使用“物件”來進行資料的操縱:

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);

 

但當需要對資料進行儲存或者傳輸時,“物件”就不這麼好用了,往往需要把資料轉化成連續空間的“二進制位元組流”,一些典型的場景是:

  • 資料庫索引的磁盤儲存:資料庫的索引在記憶體里是b+樹,但這個格式是不能夠直接儲存到磁盤上的,所以需要把b+樹轉化為連續空間的二進制位元組流,才能儲存到磁盤上

  • 快取的KV儲存:redis/memcache是KV型別的快取,快取儲存的value必須是連續空間的二進制位元組流,而不能夠是User物件

  • 資料的網絡傳輸:socket發送的資料必須是連續空間的二進制位元組流,也不能是物件

 

所謂序列化(Serialization),就是將“物件”形態的資料轉化為“連續空間二進制位元組流”形態資料的過程。這個過程的逆過程叫做反序列化

 

怎麼進行序列化?

這是一個非常細節的問題,要是讓你來把“物件”轉化為位元組流,你會怎麼做?很容易想到的一個方法是xml(或者json)這類具有自描述特性的標記性語言:

<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>

 

規定好轉換規則,發送方很容易把User類的一個物件序列化為xml,服務方收到xml二進制流之後,也很容易將其範序列化為User物件。

畫外音:語言支持反射時,這個工作很容易。

 

第二個方法是自己實現二進制協議來進行序列化,還是以上面的User物件為例,可以設計一個這樣的通用協議:

  • 頭4個位元組表示序號

  • 序號後面的4個位元組表示key的長度m

  • 接下來的m個位元組表示key的值

  • 接下來的4個位元組表示value的長度n

  • 接下來的n個位元組表示value的值

  • 像xml一樣遞迴下去,直到描述完整個物件

 

上面的User物件,用這個協議描述出來可能是這樣的:

  • 第一行:序號4個位元組(設0表示類名),類名長度4個位元組(長度為4),接下來4個位元組是類名(”User”),共12位元組

  • 第二行:序號4個位元組(1表示第一個屬性),屬性長度4個位元組(長度為9),接下來9個位元組是屬性名(”user_name”),屬性值長度4個位元組(長度為8),屬性值8個位元組(值為”shenjian”),共29位元組

  • 第三行:序號4個位元組(2表示第二個屬性),屬性長度4個位元組(長度為7),接下來7個位元組是屬性名(”user_id”),屬性值長度4個位元組(長度為8),屬性值8個位元組(值為123),共27位元組

  • 第四行:序號4個位元組(3表示第三個屬性),屬性長度4個位元組(長度為8),接下來8個位元組是屬性名(”user_name”),屬性值長度4個位元組(長度為4),屬性值4個位元組(值為35),共24位元組

整個二進制位元組流共12+29+27+24=92位元組。

 

實際的序列化協議要考慮的細節遠比這個多,例如:強型別的語言不僅要還原屬性名,屬性值,還要還原屬性型別;複雜的物件不僅要考慮普通型別,還要考慮物件嵌套型別等。無論如何,序列化的思路都是類似的。

 

序列化協議要考慮什麼因素?

不管使用成熟協議xml/json,還是自定義二進制協議來序列化物件,序列化協議設計時都需要考慮以下這些因素。

  • 解析效率:這個應該是序列化協議應該首要考慮的因素,像xml/json解析起來比較耗時,需要解析doom樹,二進制自定義協議解析起來效率就很高

  • 壓縮率,傳輸有效性:同樣一個物件,xml/json傳輸起來有大量的xml標簽,信息有效性低,二進制自定義協議占用的空間相對來說就小多了

  • 擴展性與兼容性:是否能夠方便的增加欄位,增加欄位後舊版客戶端是否需要強制升級,都是需要考慮的問題,xml/json和上面的二進制協議都能夠方便的擴展

  • 可讀性與可除錯性:這個很好理解,xml/json的可讀性就比二進制協議好很多

  • 跨語言:上面的兩個協議都是跨語言的,有些序列化協議是與開發語言緊密相關的,例如dubbo的序列化協議就只能支持Java的RPC呼叫

  • 通用性:xml/json非常通用,都有很好的第三方解析庫,各個語言解析起來都十分方便,上面自定義的二進制協議雖然能夠跨語言,但每個語言都要寫一個簡易的協議客戶端

 

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

  • xml/json:解析效率,壓縮率都較差,擴展性、可讀性、通用性較好

  • thrift

  • protobuf:Google出品,必屬精品,各方面都不錯,強烈推薦,屬於二進制協議,可讀性差了點,但也有類似的to-string協議幫助除錯問題

  • Avro

  • CORBA

  • mc_pack:懂的同學就懂,不懂的就不懂了,09年用過,傳說各方面都超越protobuf,懂行的同學可以說一下現狀


RPC-client除了:

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

還包含:

  • 發送位元組流與接收位元組流的部分(上圖中的2、3)

這一部分,又分為同步呼叫與異步呼叫兩種方式,下麵一一來進行介紹。

畫外音:搞通透RPC-client確實不容易。

 

同步呼叫的代碼片段為:

Result = Add(Obj1, Obj2);// 得到Result之前處於阻塞狀態

異步呼叫的代碼片段為:

Add(Obj1, Obj2, callback);// 呼叫後直接傳回,不等結果

 

處理結果通過回呼為:

callback(Result){// 得到處理結果後會呼叫這個回呼函式

         …

}

這兩類呼叫,在RPC-client里,實現方式完全不一樣。

 

RPC-client同步呼叫架構如何?


所謂同步呼叫,在得到結果之前,一直處於阻塞狀態,會一直占用一個工作執行緒,上圖簡單的說明瞭一下組件、交互、流程步驟:

  • 左邊大框,代表了呼叫方的一個工作執行緒

  • 左邊粉色中框,代表了RPC-client組件

  • 右邊橙色框,代表了RPC-server

  • 藍色兩個小框,代表了同步RPC-client兩個核心組件,序列化組件連接池組件

  • 白色的流程小框,以及箭頭序號1-10,代表整個工作執行緒的串行執行步驟

1)業務代碼發起RPC呼叫:

Result=Add(Obj1,Obj2)

2)序列化組件,將物件呼叫序列化成二進制位元組流,可理解為一個待發送的包packet1;

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

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

5)發送包在網絡傳輸,發給RPC-server;

6)響應包在網絡傳輸,發回給RPC-client;

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

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

9)序列化組件,將packet2範序列化為Result物件傳回給呼叫方;

10)業務代碼獲取Result結果,工作執行緒繼續往下走;

畫外音:請對照架構圖中的1-10步驟閱讀。

連接池組件有什麼作用?

RPC框架鎖支持的負載均衡、故障轉移、發送超時等特性,都是通過連接池組件去實現的。


典型連接池組件對外提供的接口為:

int ConnectionPool::init(…);

Connection ConnectionPool::getConnection();

int ConnectionPool::putConnection(Connection t);

init做了些什麼?

和下游RPC-server(一般是一個集群),建立N個tcp長連接,即所謂的連接“池”。

getConnection做了些什麼?

從連接“池”中拿一個連接,加鎖(置一個標誌位),傳回給呼叫方。

putConnection做了些什麼?

將一個分配出去的連接放回連接“池”中,解鎖(也是置一個標誌位)。

 

如何實現負載均衡?

連接池中建立了與一個RPC-server集群的連接,連接池在傳回連接的時候,需要具備隨機性

 

如何實現故障轉移?

連接池中建立了與一個RPC-server集群的連接,當連接池發現某一個機器的連接異常後,需要將這個機器的連接排除掉,傳回正常的連接,在機器恢復後,再將連接加回來。

 

如何實現發送超時?

因為是同步阻塞呼叫,拿到一個連接後,使用帶超時的send/recv即可實現帶超時的發送和接收。

 

總的來說,同步的RPC-client的實現是相對比較容易的,序列化組件、連接池組件配合多工作執行緒數,就能夠實現。

遺留問題,工作執行緒數設置為多少最合適?

這個問題在《工作執行緒數究竟要設置為多少最合適?》中討論過,此處不再深究。

RPC-client異步回呼架構如何?


所謂異步回呼,在得到結果之前,不會處於阻塞狀態,理論上任何時間都沒有任何執行緒處於阻塞狀態,因此異步回呼的模型,理論上只需要很少的工作執行緒與服務連接就能夠達到很高的吞吐量,如上圖所示:

  • 左邊的框框,是少量工作執行緒(少數幾個就行了)進行呼叫與回呼

  • 中間粉色的框框,代表了RPC-client組件

  • 右邊橙色框,代表了RPC-server

  • 藍色六個小框,代表了異步RPC-client六個核心組件背景關係管理器,超時管理器,序列化組件,下游收發佇列,下游收發執行緒,連接池組件

  • 白色的流程小框,以及箭頭序號1-17,代表整個工作執行緒的串行執行步驟:

1)業務代碼發起異步RPC呼叫;

Add(Obj1,Obj2, callback)

2)背景關係管理器,將請求,回呼,背景關係儲存起來;

3)序列化組件,將物件呼叫序列化成二進制位元組流,可理解為一個待發送的包packet1;

4)下游收發佇列,將報文放入“待發送佇列”,此時呼叫傳回,不會阻塞工作執行緒;

5)下游收發執行緒,將報文從“待發送佇列”中取出,通過連接池組件拿到一個可用的連接connection;

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

7)發送包在網絡傳輸,發給RPC-server;

8)響應包在網絡傳輸,發回給RPC-client;

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

10)下游收發執行緒,將報文放入“已接受佇列”,通過連接池組件,將conneciont放回連接池;

11)下游收發佇列里,報文被取出,此時回呼將要開始,不會阻塞工作執行緒;

12)序列化組件,將packet2範序列化為Result物件;

13)背景關係管理器,將結果,回呼,背景關係取出;

14)通過callback回呼業務代碼,傳回Result結果,工作執行緒繼續往下走;

 

如果請求長時間不傳回,處理流程是:

15)背景關係管理器,請求長時間沒有傳回;

16)超時管理器拿到超時的背景關係;

17)通過timeout_cb回呼業務代碼,工作執行緒繼續往下走;

畫外音:請配合架構圖仔細看幾遍這個流程。

 

序列化組件和連接池組件上文已經介紹過,收發佇列與收發執行緒比較容易理解。下麵重點介紹背景關係管理器超時管理器這兩個總的組件。

為什麼需要背景關係管理器?

由於請求包的發送,響應包的回呼都是異步的,甚至不在同一個工作執行緒中完成,需要一個組件來記錄一個請求的背景關係,把請求-響應-回呼等一些信息匹配起來

 

如何將請求-響應-回呼這些信息匹配起來?

這是一個很有意思的問題,通過一條連接往下游服務發送了a,b,c三個請求包,異步的收到了x,y,z三個響應包:


怎麼知道哪個請求包與哪個響應包對應?

怎麼知道哪個響應包與哪個回呼函式對應?

可以通過“請求id”來實現請求-響應-回呼的串聯。


整個處理流程如上,通過請求id,背景關係管理器來對應請求-響應-callback之間的映射關係:

1)生成請求id;

2)生成請求背景關係context,背景關係中包含發送時間time,回呼函式callback等信息;

3)背景關係管理器記錄req-id與背景關係context的映射關係;

4)將req-id打在請求包里發給RPC-server;

5)RPC-server將req-id打在響應包里傳回;

6)由響應包中的req-id,通過背景關係管理器找到原來的背景關係context;

7)從背景關係context中拿到回呼函式callback;

8)callback將Result帶回,推動業務的進一步執行;

 

如何實現負載均衡,故障轉移?

與同步的連接池思路類似,不同之處在於:

  • 同步連接池使用阻塞方式收發,需要與一個服務的一個ip建立多條連接

  • 異步收發,一個服務的一個ip只需要建立少量的連接(例如,一條tcp連接)

 

如何實現超時發送與接收?

超時收發,與同步阻塞收發的實現就不一樣了:

  • 同步阻塞超時,可以直接使用帶超時的send/recv來實現

  • 異步非阻塞的nio的網絡報文收發,由於連接不會一直等待回包,超時是由超時管理器實現的

 

超時管理器如何實現超時管理?


超時管理器,用於實現請求回包超時回呼處理。

每一個請求發送給下游RPC-server,會在背景關係管理器中儲存req-id與背景關係的信息,背景關係中儲存了請求很多相關信息,例如req-id,回包回呼,超時回呼,發送時間等。

超時管理器啟動timer對背景關係管理器中的context進行掃描,看背景關係中請求發送時間是否過長,如果過長,就不再等待回包,直接超時回呼,推動業務流程繼續往下走,並將背景關係刪除掉。

如果超時回呼執行後,正常的回包又到達,通過req-id在背景關係管理器里找不到背景關係,就直接將請求丟棄。

畫外音:因為已經超時處理了,無法恢復背景關係。

 

無論如何,異步回呼和同步回呼相比,除了序列化組件和連接池組件,會多出背景關係管理器,超時管理器,下游收發佇列,下游收發執行緒等組件,並且對呼叫方的呼叫習慣有影響。

畫外音:編程習慣,由同步變為了回呼。

異步回呼能提高系統整體的吞吐量,具體使用哪種方式實現RPC-client,可以結合業務場景來選取。

總結

什麼是RPC呼叫?

像呼叫本地函式一樣,呼叫一個遠端服務。

為什麼需要RPC框架?

RPC框架用於屏蔽RPC呼叫過程中的序列化,網絡傳輸等技術細節。讓呼叫方只專註於呼叫,服務方只專註於實現呼叫。

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

把物件轉化為連續二進制流的過程,叫做序列化。磁盤儲存,快取儲存,網絡傳輸只能操作於二進制流,所以必須序列化。

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

同步RPC-client的核心組件是序列化組件、連接池組件。它通過連接池來實現負載均衡與故障轉移,通過阻塞的收發來實現超時處理。

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

異步RPC-client的核心組件是序列化組件、連接池組件、收發佇列、收發執行緒、背景關係管理器、超時管理器。它通過“請求id”來關聯請求包-響應包-回呼函式,用背景關係管理器來管理背景關係,用超時管理器中的timer觸發超時回呼,推進業務流程的超時處理。

思路比結論重要。

    赞(0)

    分享創造快樂