必須知道的 RPC 內核細節
微服務分層架構,之前聊得很多了,微服務離不開 RPC 框架,RPC 框架的原理、實踐及細節,今天和大家聊一聊。
服務化有什麼好處?
服務化的一個好處就是,不限定服務的提供方使用什麼技術選型,能夠實現大公司跨團隊的技術解耦,如下圖所示:
(1)服務 A:歐洲團隊維護,技術背景是 Java;
(2)服務 B:美洲團隊維護,用 C++ 實現;
(3)服務 C:中國團隊維護,技術棧是 go;
服務的上游調用方,按照接口、協議即可完成對遠端服務的調用。
但實際上,大部分互聯網公司,研發團隊規模有限,大都使用同一套技術體系來實現服務:
這樣的話,如果沒有統一的服務框架,各個團隊的服務提供方就需要各自實現一套序列化、反序列化、網絡框架、連接池、收發線程、超時處理、狀態機等 “業務之外” 的重複技術勞動,造成整體的低效。
因此,統一服務框架把上述 “業務之外” 的工作統一實現,是服務化首要解決的問題。
什麼是 RPC?
Remote Procedure Call Protocol,遠程過程調用。
什麼是 “遠程”,爲什麼 “遠”?
先來看下什麼是 “近”,即 “本地函數調用”。
當我們寫下:
int result = Add(1, 2);
這行代碼的時候,到底發生了什麼?
(1)傳遞兩個入參;
(2)調用了本地代碼段中的函數,執行運算邏輯;
(3)返回一個出參;
這三個動作,都發生在同一個進程空間裏,這是本地函數調用。
那有沒有辦法,調用一個跨進程的函數呢?
典型的,這個進程部署在另一臺服務器上。
最容易想到的,兩個進程約定一個協議格式,使用 Socket 通信,來傳輸:
(1)入參;
(2)調用哪個函數;
(3)出參;
如果能夠實現,那這就是 “遠程” 過程調用。
Socket 通信只能傳遞連續的字節流,如何將入參、函數都放到連續的字節流裏呢?
假設,設計一個 11 字節的請求報文:
(1)前 3 個字節填入函數名 “add”;
(2)中間 4 個字節填入第一個參數 “1”;
(3)末尾 4 個字節填入第二個參數 “2”;
同理,可以設計一個 4 字節響應報文:
(1)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)將字節流發送給調用方;
這個過程用一張圖描述如下:
調用方與服務方的處理步驟都是非常清晰。
這個過程存在最大的問題是什麼呢?
調用方太麻煩了,每次都要關注很多底層細節:
(1)入參到字節流的轉化,即序列化應用層協議細節;
(2)socket 發送,即網絡傳輸協議細節;
(3)socket 接收;
(4)字節流到出參的轉化,即反序列化應用層協議細節;
能不能調用層不關注這個細節?
可以,RPC 框架就是解決這個問題的,它能夠讓調用方 “像調用本地函數一樣調用遠端的函數(服務)”。
講到這裏,是不是對 RPC,對序列化範序列化有點感覺了?往下看,有更多的底層細節。
RPC 框架的職責是什麼?
RPC 框架,要向調用方屏蔽各種複雜性,要向服務提供方也屏蔽各類複雜性:
(1)服務調用方 client 感覺就像調用本地函數一樣,來調用服務;
(2)服務提供方 server 感覺就像實現一個本地函數一樣,來實現服務;
所以整個 RPC 框架又分爲 client 部分與 server 部分,實現上面的目標,把複雜性屏蔽,就是 RPC 框架的職責。
如上圖所示,業務方的職責是:
(1)調用方 A,傳入參數,執行調用,拿到結果;
(2)服務方 B,收到參數,執行邏輯,返回結果;
RPC 框架的職責是,中間大藍框的部分:
(1)client 端:序列化、反序列化、連接池管理、負載均衡、故障轉移、隊列管理,超時管理、異步管理等等;
(2)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);
但當需要對數據進行存儲或者傳輸時,“對象” 就不這麼好用了,往往需要把數據轉化成連續空間的 “二進制字節流”,一些典型的場景是:
(1)數據庫索引的磁盤存儲:數據庫的索引在內存裏是 b + 樹,但這個格式是不能夠直接存儲到磁盤上的,所以需要把 b + 樹轉化爲連續空間的二進制字節流,才能存儲到磁盤上;
(2)緩存的 KV 存儲:redis/memcache 是 KV 類型的緩存,緩存存儲的 value 必須是連續空間的二進制字節流,而不能夠是 User 對象;
(3)數據的網絡傳輸:socket 發送的數據必須是連續空間的二進制字節流,也不能是對象;
所謂序列化(Serialization),就是將 “對象” 形態的數據轉化爲 “連續空間二進制字節流” 形態數據的過程。這個過程的逆過程叫做反序列化。
怎麼進行序列化?
這是一個非常細節的問題,要是讓你來把 “對象” 轉化爲字節流,你會怎麼做?很容易想到的一個方法是 xml(或者 json)這類具有自描述特性的標記性語言:
規定好轉換規則,發送方很容易把 User 類的一個對象序列化爲 xml,服務方收到 xml 二進制流之後,也很容易將其範序列化爲 User 對象。
畫外音:語言支持反射時,這個工作很容易。
第二個方法是自己實現二進制協議來進行序列化,還是以上面的 User 對象爲例,可以設計一個這樣的通用協議:
(1)頭 4 個字節表示序號;
(2)序號後面的 4 個字節表示 key 的長度 m;
(3)接下來的 m 個字節表示 key 的值;
(4)接下來的 4 個字節表示 value 的長度 n;
(5)接下來的 n 個字節表示 value 的值;
(6)像 xml 一樣遞歸下去,直到描述完整個對象;
上面的 User 對象,用這個協議描述出來可能是這樣的:
(1)第一行:序號 4 個字節(設 0 表示類名),類名長度 4 個字節(長度爲 4),接下來 4 個字節是類名(”User”),共 12 字節;
(2)第二行:序號 4 個字節(1 表示第一個屬性),屬性長度 4 個字節(長度爲 9),接下來 9 個字節是屬性名(”user_name”),屬性值長度 4 個字節(長度爲 8),屬性值 8 個字節(值爲”shenjian”),共 29 字節;
(3)第三行:序號 4 個字節(2 表示第二個屬性),屬性長度 4 個字節(長度爲 7),接下來 7 個字節是屬性名(”user_id”),屬性值長度 4 個字節(長度爲 8),屬性值 8 個字節(值爲 123),共 27 字節;
(4)第四行:序號 4 個字節(3 表示第三個屬性),屬性長度 4 個字節(長度爲 8),接下來 8 個字節是屬性名(”user_name”),屬性值長度 4 個字節(長度爲 4),屬性值 4 個字節(值爲 35),共 24 字節;
整個二進制字節流共 12+29+27+24=92 字節。
實際的序列化協議要考慮的細節遠比這個多,例如:強類型的語言不僅要還原屬性名,屬性值,還要還原屬性類型;複雜的對象不僅要考慮普通類型,還要考慮對象嵌套類型等。無論如何,序列化的思路都是類似的。
序列化協議要考慮什麼因素?
不管使用成熟協議 xml/json,還是自定義二進制協議來序列化對象,序列化協議設計時都需要考慮以下這些因素。
(1)解析效率:這個應該是序列化協議應該首要考慮的因素,像 xml/json 解析起來比較耗時,需要解析 doom 樹,二進制自定義協議解析起來效率就很高;
(2)壓縮率,傳輸有效性:同樣一個對象,xml/json 傳輸起來有大量的 xml 標籤,信息有效性低,二進制自定義協議佔用的空間相對來說就小多了;
(3)擴展性與兼容性:是否能夠方便的增加字段,增加字段後舊版客戶端是否需要強制升級,都是需要考慮的問題,xml/json 和上面的二進制協議都能夠方便的擴展;
(4)可讀性與可調試性:這個很好理解,xml/json 的可讀性就比二進制協議好很多;
(5)跨語言:上面的兩個協議都是跨語言的,有些序列化協議是與開發語言緊密相關的,例如 dubbo 的序列化協議就只能支持 Java 的 RPC 調用;
(6)通用性:xml/json 非常通用,都有很好的第三方解析庫,各個語言解析起來都十分方便,上面自定義的二進制協議雖然能夠跨語言,但每個語言都要寫一個簡易的協議客戶端;
有哪些常見的序列化方式?
(1)xml/json:解析效率,壓縮率都較差,擴展性、可讀性、通用性較好;
(2)thrift;
(3)protobuf:Google 出品,必屬精品,各方面都不錯,強烈推薦,屬於二進制協議,可讀性差了點,但也有類似的 to-string 協議幫助調試問題;
(4)Avro;
(5)CORBA;
(6)mc_pack:懂的同學就懂,不懂的就不懂了,09 年用過,傳說各方面都超越 protobuf,懂行的同學可以說一下現狀;
(7)…
RPC-client 除了:
(1)序列化反序列化的部分(上圖中的 1、4)
還包含:
(2)發送字節流與接收字節流的部分(上圖中的 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 帶回,推動業務的進一步執行;
如何實現負載均衡,故障轉移?
與同步的連接池思路類似,不同之處在於:
(1)同步連接池使用阻塞方式收發,需要與一個服務的一個 ip 建立多條連接;
(2)異步收發,一個服務的一個 ip 只需要建立少量的連接(例如,一條 tcp 連接);
如何實現超時發送與接收?
超時收發,與同步阻塞收發的實現就不一樣了:
(1)同步阻塞超時,可以直接使用帶超時的 send/recv 來實現;
(2)異步非阻塞的 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 觸發超時回調,推進業務流程的超時處理。
思路比結論重要。
架構師之路 - 分享技術思路
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/9GZtmV4HIgg0o2OcZiqXgw