您好,登錄后才能下訂單哦!
本篇內(nèi)容主要講解“微服務(wù)架構(gòu)的RPC細節(jié)有哪些”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學(xué)習(xí)“微服務(wù)架構(gòu)的RPC細節(jié)有哪些”吧!
服務(wù)化有什么好處?
服務(wù)化的一個好處就是,不限定服務(wù)的提供方使用什么技術(shù)選型,能夠?qū)崿F(xiàn)大公司跨團隊的技術(shù)解耦,如下圖所示:
服務(wù)A:歐洲團隊維護,技術(shù)背景是Java
服務(wù)B:美洲團隊維護,用C++實現(xiàn)
服務(wù)C:中國團隊維護,技術(shù)棧是go
服務(wù)的上游調(diào)用方,按照接口、協(xié)議即可完成對遠端服務(wù)的調(diào)用。
但實際上,大部分互聯(lián)網(wǎng)公司,研發(fā)團隊規(guī)模有限,大都使用同一套技術(shù)體系來實現(xiàn)服務(wù):
這樣的話,如果沒有統(tǒng)一的服務(wù)框架,各個團隊的服務(wù)提供方就需要各自實現(xiàn)一套序列化、反序列化、網(wǎng)絡(luò)框架、連接池、收發(fā)線程、超時處理、狀態(tài)機等“業(yè)務(wù)之外”的重復(fù)技術(shù)勞動,造成整體的低效。
因此,統(tǒng)一服務(wù)框架把上述“業(yè)務(wù)之外”的工作統(tǒng)一實現(xiàn),是服務(wù)化首要解決的問題。
什么是RPC?
Remote Procedure Call Protocol,遠程過程調(diào)用。
什么是“遠程”,為什么“遠”?
先來看下什么是“近”,即“本地函數(shù)調(diào)用”。
當(dāng)我們寫下:
int result = Add(1, 2);
這行代碼的時候,到底發(fā)生了什么?
傳遞兩個入?yún)?/p>
調(diào)用了本地代碼段中的函數(shù),執(zhí)行運算邏輯
返回一個出參
這三個動作,都發(fā)生在同一個進程空間里,這是本地函數(shù)調(diào)用。
那有沒有辦法,調(diào)用一個跨進程的函數(shù)呢?
典型的,這個進程部署在另一臺服務(wù)器上。
最容易想到的,兩個進程約定一個協(xié)議格式,使用Socket通信,來傳輸:
入?yún)?/p>
調(diào)用哪個函數(shù)
出參
如果能夠?qū)崿F(xiàn),那這就是“遠程”過程調(diào)用。
Socket通信只能傳遞連續(xù)的字節(jié)流,如何將入?yún)?、函?shù)都放到連續(xù)的字節(jié)流里呢?
假設(shè),設(shè)計一個11字節(jié)的請求報文:
前3個字節(jié)填入函數(shù)名“add”
中間4個字節(jié)填入第一個參數(shù)“1”
末尾4個字節(jié)填入第二個參數(shù)“2”
同理,可以設(shè)計一個4字節(jié)響應(yīng)報文:
4個字節(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個步驟是:
(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);
這個5個步驟也很好理解:
(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)用方;
這個過程用一張圖描述如下:
調(diào)用方與服務(wù)方的處理步驟都是非常清晰。
這個過程存在最大的問題是什么呢?
調(diào)用方太麻煩了,每次都要關(guān)注很多底層細節(jié):
入?yún)⒌阶止?jié)流的轉(zhuǎn)化,即序列化應(yīng)用層協(xié)議細節(jié)
socket發(fā)送,即網(wǎng)絡(luò)傳輸協(xié)議細節(jié)
socket接收
字節(jié)流到出參的轉(zhuǎn)化,即反序列化應(yīng)用層協(xié)議細節(jié)
能不能調(diào)用層不關(guān)注這個細節(jié)?
可以,RPC框架就是解決這個問題的,它能夠讓調(diào)用方“像調(diào)用本地函數(shù)一樣調(diào)用遠端的函數(shù)(服務(wù))”。
講到這里,是不是對RPC,對序列化范序列化有點感覺了?往下看,有更多的底層細節(jié)。
RPC框架的職責(zé)是什么?
RPC框架,要向調(diào)用方屏蔽各種復(fù)雜性,要向服務(wù)提供方也屏蔽各類復(fù)雜性:
服務(wù)調(diào)用方client感覺就像調(diào)用本地函數(shù)一樣,來調(diào)用服務(wù)
服務(wù)提供方server感覺就像實現(xiàn)一個本地函數(shù)一樣,來實現(xiàn)服務(wù)
所以整個RPC框架又分為client部分與server部分,實現(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é)是,中間大藍框的部分:
client端:序列化、反序列化、連接池管理、負載均衡、故障轉(zhuǎn)移、隊列管理,超時管理、異步管理等等
server端:服務(wù)端組件、服務(wù)端收發(fā)包隊列、io線程、工作線程、序列化反序列化等
server端的技術(shù)大家了解的比較多,接下來重點講講client端的技術(shù)細節(jié)。
先來看看RPC-client部分的“序列化反序列化”部分。
為什么要進行序列化?
工程師通常使用“對象”來進行數(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)需要對數(shù)據(jù)進行存儲或者傳輸時,“對象”就不這么好用了,往往需要把數(shù)據(jù)轉(zhuǎn)化成連續(xù)空間的“二進制字節(jié)流”,一些典型的場景是:
數(shù)據(jù)庫索引的磁盤存儲:數(shù)據(jù)庫的索引在內(nèi)存里是b+樹,但這個格式是不能夠直接存儲到磁盤上的,所以需要把b+樹轉(zhuǎn)化為連續(xù)空間的二進制字節(jié)流,才能存儲到磁盤上
緩存的KV存儲:redis/memcache是KV類型的緩存,緩存存儲的value必須是連續(xù)空間的二進制字節(jié)流,而不能夠是User對象
數(shù)據(jù)的網(wǎng)絡(luò)傳輸:socket發(fā)送的數(shù)據(jù)必須是連續(xù)空間的二進制字節(jié)流,也不能是對象
所謂序列化(Serialization),就是將“對象”形態(tài)的數(shù)據(jù)轉(zhuǎn)化為“連續(xù)空間二進制字節(jié)流”形態(tài)數(shù)據(jù)的過程。這個過程的逆過程叫做反序列化。
怎么進行序列化?
這是一個非常細節(jié)的問題,要是讓你來把“對象”轉(zhuǎn)化為字節(jié)流,你會怎么做?很容易想到的一個方法是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類的一個對象序列化為xml,服務(wù)方收到xml二進制流之后,也很容易將其范序列化為User對象。
畫外音:語言支持反射時,這個工作很容易
第二個方法是自己實現(xiàn)二進制協(xié)議來進行序列化,還是以上面的User對象為例,可以設(shè)計一個這樣的通用協(xié)議:
頭4個字節(jié)表示序號
序號后面的4個字節(jié)表示key的長度m
接下來的m個字節(jié)表示key的值
接下來的4個字節(jié)表示value的長度n
接下來的n個字節(jié)表示value的值
像xml一樣遞歸下去,直到描述完整個對象
上面的User對象,用這個協(xié)議描述出來可能是這樣的:
第一行:序號4個字節(jié)(設(shè)0表示類名),類名長度4個字節(jié)(長度為4),接下來4個字節(jié)是類名(”User”),共12字節(jié)
第二行:序號4個字節(jié)(1表示第一個屬性),屬性長度4個字節(jié)(長度為9),接下來9個字節(jié)是屬性名(”user_name”),屬性值長度4個字節(jié)(長度為8),屬性值8個字節(jié)(值為”shenjian”),共29字節(jié)
第三行:序號4個字節(jié)(2表示第二個屬性),屬性長度4個字節(jié)(長度為7),接下來7個字節(jié)是屬性名(”user_id”),屬性值長度4個字節(jié)(長度為8),屬性值8個字節(jié)(值為123),共27字節(jié)
第四行:序號4個字節(jié)(3表示第三個屬性),屬性長度4個字節(jié)(長度為8),接下來8個字節(jié)是屬性名(”user_name”),屬性值長度4個字節(jié)(長度為4),屬性值4個字節(jié)(值為35),共24字節(jié)
整個二進制字節(jié)流共12+29+27+24=92字節(jié)。
實際的序列化協(xié)議要考慮的細節(jié)遠比這個多,例如:強類型的語言不僅要還原屬性名,屬性值,還要還原屬性類型;復(fù)雜的對象不僅要考慮普通類型,還要考慮對象嵌套類型等。無論如何,序列化的思路都是類似的。
序列化協(xié)議要考慮什么因素?
不管使用成熟協(xié)議xml/json,還是自定義二進制協(xié)議來序列化對象,序列化協(xié)議設(shè)計時都需要考慮以下這些因素。
解析效率:這個應(yīng)該是序列化協(xié)議應(yīng)該首要考慮的因素,像xml/json解析起來比較耗時,需要解析doom樹,二進制自定義協(xié)議解析起來效率就很高
壓縮率,傳輸有效性:同樣一個對象,xml/json傳輸起來有大量的xml標(biāo)簽,信息有效性低,二進制自定義協(xié)議占用的空間相對來說就小多了
擴展性與兼容性:是否能夠方便的增加字段,增加字段后舊版客戶端是否需要強制升級,都是需要考慮的問題,xml/json和上面的二進制協(xié)議都能夠方便的擴展
可讀性與可調(diào)試性:這個很好理解,xml/json的可讀性就比二進制協(xié)議好很多
跨語言:上面的兩個協(xié)議都是跨語言的,有些序列化協(xié)議是與開發(fā)語言緊密相關(guān)的,例如dubbo的序列化協(xié)議就只能支持Java的RPC調(diào)用
通用性:xml/json非常通用,都有很好的第三方解析庫,各個語言解析起來都十分方便,上面自定義的二進制協(xié)議雖然能夠跨語言,但每個語言都要寫一個簡易的協(xié)議客戶端
有哪些常見的序列化方式?
xml/json:解析效率,壓縮率都較差,擴展性、可讀性、通用性較好
thrift
protobuf:Google出品,必屬精品,各方面都不錯,強烈推薦,屬于二進制協(xié)議,可讀性差了點,但也有類似的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)用兩種方式,下面一一來進行介紹。
畫外音:搞通透RPC-client確實不容易。
同步調(diào)用的代碼片段為:
Result = Add(Obj1, Obj2);// 得到Result之前處于阻塞狀態(tài)
異步調(diào)用的代碼片段為:
Add(Obj1, Obj2, callback);// 調(diào)用后直接返回,不等結(jié)果
處理結(jié)果通過回調(diào)為:
callback(Result){// 得到處理結(jié)果后會調(diào)用這個回調(diào)函數(shù) … }
這兩類調(diào)用,在RPC-client里,實現(xiàn)方式完全不一樣。
RPC-client同步調(diào)用架構(gòu)如何?
所謂同步調(diào)用,在得到結(jié)果之前,一直處于阻塞狀態(tài),會一直占用一個工作線程,上圖簡單的說明了一下組件、交互、流程步驟:
左邊大框,代表了調(diào)用方的一個工作線程
左邊粉色中框,代表了RPC-client組件
右邊橙色框,代表了RPC-server
藍色兩個小框,代表了同步RPC-client兩個核心組件,序列化組件與連接池組件
白色的流程小框,以及箭頭序號1-10,代表整個工作線程的串行執(zhí)行步驟:
1)業(yè)務(wù)代碼發(fā)起RPC調(diào)用:
Result=Add(Obj1,Obj2)
2)序列化組件,將對象調(diào)用序列化成二進制字節(jié)流,可理解為一個待發(fā)送的包packet1;
3)通過連接池組件拿到一個可用的連接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對象返回給調(diào)用方;
10)業(yè)務(wù)代碼獲取Result結(jié)果,工作線程繼續(xù)往下走;
畫外音:請對照架構(gòu)圖中的1-10步驟閱讀。
連接池組件有什么作用?
RPC框架鎖支持的負載均衡、故障轉(zhuǎn)移、發(fā)送超時等特性,都是通過連接池組件去實現(xiàn)的。
典型連接池組件對外提供的接口為:
int ConnectionPool::init(…); Connection ConnectionPool::getConnection(); int ConnectionPool::putConnection(Connection t);
init做了些什么?
和下游RPC-server(一般是一個集群),建立N個tcp長連接,即所謂的連接“池”。
getConnection做了些什么?
從連接“池”中拿一個連接,加鎖(置一個標(biāo)志位),返回給調(diào)用方。
putConnection做了些什么?
將一個分配出去的連接放回連接“池”中,解鎖(也是置一個標(biāo)志位)。
如何實現(xiàn)負載均衡?
連接池中建立了與一個RPC-server集群的連接,連接池在返回連接的時候,需要具備隨機性。
如何實現(xiàn)故障轉(zhuǎn)移?
連接池中建立了與一個RPC-server集群的連接,當(dāng)連接池發(fā)現(xiàn)某一個機器的連接異常后,需要將這個機器的連接排除掉,返回正常的連接,在機器恢復(fù)后,再將連接加回來。
如何實現(xiàn)發(fā)送超時?
因為是同步阻塞調(diào)用,拿到一個連接后,使用帶超時的send/recv即可實現(xiàn)帶超時的發(fā)送和接收。
總的來說,同步的RPC-client的實現(xiàn)是相對比較容易的,序列化組件、連接池組件配合多工作線程數(shù),就能夠?qū)崿F(xiàn)。
遺留問題,工作線程數(shù)設(shè)置為多少最合適?
這個問題在《工作線程數(shù)究竟要設(shè)置為多少最合適?》中討論過,此處不再深究。
RPC-client異步回調(diào)架構(gòu)如何?
所謂異步回調(diào),在得到結(jié)果之前,不會處于阻塞狀態(tài),理論上任何時間都沒有任何線程處于阻塞狀態(tài),因此異步回調(diào)的模型,理論上只需要很少的工作線程與服務(wù)連接就能夠達到很高的吞吐量,如上圖所示:
左邊的框框,是少量工作線程(少數(shù)幾個就行了)進行調(diào)用與回調(diào)
中間粉色的框框,代表了RPC-client組件
右邊橙色框,代表了RPC-server
藍色六個小框,代表了異步RPC-client六個核心組件:上下文管理器,超時管理器,序列化組件,下游收發(fā)隊列,下游收發(fā)線程,連接池組件
白色的流程小框,以及箭頭序號1-17,代表整個工作線程的串行執(zhí)行步驟:
1)業(yè)務(wù)代碼發(fā)起異步RPC調(diào)用;
Add(Obj1,Obj2, callback)
2)上下文管理器,將請求,回調(diào),上下文存儲起來;
3)序列化組件,將對象調(diào)用序列化成二進制字節(jié)流,可理解為一個待發(fā)送的包packet1;
4)下游收發(fā)隊列,將報文放入“待發(fā)送隊列”,此時調(diào)用返回,不會阻塞工作線程;
5)下游收發(fā)線程,將報文從“待發(fā)送隊列”中取出,通過連接池組件拿到一個可用的連接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ā)線程,將報文放入“已接受隊列”,通過連接池組件,將conneciont放回連接池;
11)下游收發(fā)隊列里,報文被取出,此時回調(diào)將要開始,不會阻塞工作線程;
12)序列化組件,將packet2范序列化為Result對象;
13)上下文管理器,將結(jié)果,回調(diào),上下文取出;
14)通過callback回調(diào)業(yè)務(wù)代碼,返回Result結(jié)果,工作線程繼續(xù)往下走;
如果請求長時間不返回,處理流程是:
15)上下文管理器,請求長時間沒有返回;
16)超時管理器拿到超時的上下文;
17)通過timeout_cb回調(diào)業(yè)務(wù)代碼,工作線程繼續(xù)往下走;
畫外音:請配合架構(gòu)圖仔細看幾遍這個流程。
序列化組件和連接池組件上文已經(jīng)介紹過,收發(fā)隊列與收發(fā)線程比較容易理解。下面重點介紹上下文管理器與超時管理器這兩個總的組件。
為什么需要上下文管理器?
由于請求包的發(fā)送,響應(yīng)包的回調(diào)都是異步的,甚至不在同一個工作線程中完成,需要一個組件來記錄一個請求的上下文,把請求-響應(yīng)-回調(diào)等一些信息匹配起來。
如何將請求-響應(yīng)-回調(diào)這些信息匹配起來?
這是一個很有意思的問題,通過一條連接往下游服務(wù)發(fā)送了a,b,c三個請求包,異步的收到了x,y,z三個響應(yīng)包:
怎么知道哪個請求包與哪個響應(yīng)包對應(yīng)?
怎么知道哪個響應(yīng)包與哪個回調(diào)函數(shù)對應(yīng)?
可以通過“請求id”來實現(xiàn)請求-響應(yīng)-回調(diào)的串聯(lián)。
整個處理流程如上,通過請求id,上下文管理器來對應(yīng)請求-響應(yīng)-callback之間的映射關(guān)系:
1)生成請求id;
2)生成請求上下文context,上下文中包含發(fā)送時間time,回調(diào)函數(shù)callback等信息;
3)上下文管理器記錄req-id與上下文context的映射關(guān)系;
4)將req-id打在請求包里發(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帶回,推動業(yè)務(wù)的進一步執(zhí)行;
如何實現(xiàn)負載均衡,故障轉(zhuǎn)移?
與同步的連接池思路類似,不同之處在于:
同步連接池使用阻塞方式收發(fā),需要與一個服務(wù)的一個ip建立多條連接
異步收發(fā),一個服務(wù)的一個ip只需要建立少量的連接(例如,一條tcp連接)
如何實現(xiàn)超時發(fā)送與接收?
超時收發(fā),與同步阻塞收發(fā)的實現(xiàn)就不一樣了:
同步阻塞超時,可以直接使用帶超時的send/recv來實現(xiàn)
異步非阻塞的nio的網(wǎng)絡(luò)報文收發(fā),由于連接不會一直等待回包,超時是由超時管理器實現(xiàn)的
超時管理器如何實現(xiàn)超時管理?
超時管理器,用于實現(xiàn)請求回包超時回調(diào)處理。
每一個請求發(fā)送給下游RPC-server,會在上下文管理器中保存req-id與上下文的信息,上下文中保存了請求很多相關(guān)信息,例如req-id,回包回調(diào),超時回調(diào),發(fā)送時間等。
超時管理器啟動timer對上下文管理器中的context進行掃描,看上下文中請求發(fā)送時間是否過長,如果過長,就不再等待回包,直接超時回調(diào),推動業(yè)務(wù)流程繼續(xù)往下走,并將上下文刪除掉。
如果超時回調(diào)執(zhí)行后,正常的回包又到達,通過req-id在上下文管理器里找不到上下文,就直接將請求丟棄。
畫外音:因為已經(jīng)超時處理了,無法恢復(fù)上下文。
無論如何,異步回調(diào)和同步回調(diào)相比,除了序列化組件和連接池組件,會多出上下文管理器,超時管理器,下游收發(fā)隊列,下游收發(fā)線程等組件,并且對調(diào)用方的調(diào)用習(xí)慣有影響。
畫外音:編程習(xí)慣,由同步變?yōu)榱嘶卣{(diào)。
異步回調(diào)能提高系統(tǒng)整體的吞吐量,具體使用哪種方式實現(xiàn)RPC-client,可以結(jié)合業(yè)務(wù)場景來選取。
到此,相信大家對“微服務(wù)架構(gòu)的RPC細節(jié)有哪些”有了更深的了解,不妨來實際操作一番吧!這里是億速云網(wǎng)站,更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢,關(guān)注我們,繼續(xù)學(xué)習(xí)!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。