rpc框架yar之源碼解析-入門和原理介紹-創(chuàng)新互聯(lián)

關(guān)于rpc的文章，網(wǎng)上的內(nèi)容很多，但我還是準(zhǔn)備寫一下，主要是自己的理解吧。算是公眾號(hào)的第一篇技術(shù)類文章吧。

成都創(chuàng)新互聯(lián)長(zhǎng)期為成百上千家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺(tái)，與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為寧鄉(xiāng)企業(yè)提供專業(yè)的網(wǎng)站建設(shè)、網(wǎng)站制作，寧鄉(xiāng)網(wǎng)站改版等技術(shù)服務(wù)。擁有10年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。

上周給團(tuán)隊(duì)小伙伴分享了也是下面基礎(chǔ)入門的內(nèi)容，本文主要結(jié)合一個(gè)簡(jiǎn)單框架yar的原理和源碼來說明詳細(xì)情況。

RPC的定義

RPC，即 Remote Procedure Call（遠(yuǎn)程過程調(diào)用），調(diào)用遠(yuǎn)程計(jì)算機(jī)上的服務(wù)，就像調(diào)用本地服務(wù)一樣。

RPC可以很好的解耦系統(tǒng)，如WebService就是一種基于Http協(xié)議的RPC。

RPC的框架

各種架構(gòu)都是在一定環(huán)境背景下產(chǎn)生的，有跨語言的，java語言的，有php的，有基于http的，有基于http2的。如下：

Thrift, gRPC, rpcx, motan, dubbox

Phprpc, yar, swoole, Hprose

RPC調(diào)用

這里以dubbo的架構(gòu)圖為例，dubbo主要分成4個(gè)角色：消費(fèi)者(Consumer)，生產(chǎn)者(Provider)，監(jiān)控中心(Monitor)，注冊(cè)中心(Registry)。

Provider: 暴露服務(wù)的服務(wù)提供方，生產(chǎn)者。 
Consumer: 調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方。 
Registry: 服務(wù)注冊(cè)與發(fā)現(xiàn)的注冊(cè)中心。 
Monitor: 統(tǒng)計(jì)服務(wù)的調(diào)用次數(shù)和調(diào)用時(shí)間的監(jiān)控中心。

調(diào)用方法如下：

0. 服務(wù)容器啟動(dòng)，加載，運(yùn)行服務(wù)提供者(server端)。 
1.服務(wù)提供者在啟動(dòng)時(shí)，向注冊(cè)中心注冊(cè)自己提供的服務(wù)。 
2.服務(wù)消費(fèi)者在啟動(dòng)時(shí)，向注冊(cè)中心訂閱自己所需的服務(wù)。 
3.注冊(cè)中心返回服務(wù)提供者地址列表給消費(fèi)者，如果有變更，注冊(cè)中心將基于長(zhǎng)連接推送變更數(shù)據(jù)給消費(fèi)者。 
4.服務(wù)消費(fèi)者，從提供者地址列表中，根據(jù)指定的負(fù)載均衡算法，選一臺(tái)提供者進(jìn)行調(diào)用，如果調(diào)用失敗，再選另一臺(tái)調(diào)用。 
5.服務(wù)消費(fèi)者和提供者，在內(nèi)存中累計(jì)調(diào)用次數(shù)和調(diào)用時(shí)間，定時(shí)每分鐘發(fā)送一次統(tǒng)計(jì)數(shù)據(jù)到監(jiān)控中心。

以上是從網(wǎng)上其他帖子上找的調(diào)用內(nèi)容。基本上涵蓋了rpc框架的基本思路，monitor和registry不是必須的，如果有其他方式替代, 也可省略或者換成其他可以實(shí)現(xiàn)功能的方式，如集中處理日志。下面是我們?cè)趯?shí)際使用中用到的內(nèi)容。

業(yè)務(wù)背景：在DAU過億的某博，基礎(chǔ)數(shù)據(jù)獨(dú)立成平臺(tái)，這樣返回的PC，手機(jī)，H5其實(shí)是基礎(chǔ)數(shù)據(jù)，要想被手機(jī)端所用，實(shí)際上需要加工然后傳到端上展示。而為了統(tǒng)一化管理，網(wǎng)頁版和手機(jī)app版盡量使用同一套解析。業(yè)務(wù)需求產(chǎn)生，在一定的歷史背景下，產(chǎn)生了rpc的調(diào)用模式。條條大路通羅馬，問題不止一個(gè)解決方案，我們只是采用了一種，即結(jié)合http,nginx ,php-fpm等使用yar這個(gè)php擴(kuò)展模塊實(shí)現(xiàn)這個(gè)業(yè)務(wù)。

嚴(yán)格意義上講yar不能獨(dú)立使用的，沒有dubbo，motan等那種自己獨(dú)立成框架體系。有些部分交給使用者自己實(shí)現(xiàn)，如日志記錄，我們的日志記錄實(shí)際與yar關(guān)系不大?？蚣軘?shù)據(jù)傳輸方式還是借助http，結(jié)合nginx，php-fpm等內(nèi)容，基礎(chǔ)還是個(gè)http的請(qǐng)求。(curl和sockert兩種方式，sockert目前我們沒有使用)。沒有注冊(cè)發(fā)現(xiàn)服務(wù)的具體使用，這個(gè)完全由lvs給我們解決，服務(wù)的可用完全交給了運(yùn)維。

了解了各個(gè)角色，我們來看下核心內(nèi)容，Yar實(shí)現(xiàn)了rpc的基礎(chǔ)部分，即數(shù)據(jù)的譯碼/解碼和傳輸，我感覺這兩部分是這個(gè)框架的核心。下面是流程圖：

請(qǐng)求過程：

Client需要遠(yuǎn)程調(diào)用的時(shí)候，先初始化數(shù)據(jù)，數(shù)據(jù)主要包括三個(gè)部分header, packager_name，request_body，然后根據(jù)配置中的方式從pack_list選擇合適的序列化方式(msgpack，json，php)

對(duì)request_body進(jìn)行序列化。 然后進(jìn)行傳輸，傳輸方式 同樣是采用工廠方法，從已有的方式中選擇Curl/sockert方式進(jìn)行傳輸數(shù)據(jù)，傳輸數(shù)據(jù)的過程實(shí)際就是發(fā)送一個(gè)http請(qǐng)求(我們以curl為例)。

服務(wù)器端監(jiān)聽端口，底層網(wǎng)絡(luò)實(shí)現(xiàn)都利用現(xiàn)有的nginx, php-fpm。在PHP代碼中，實(shí)現(xiàn)的地方實(shí)例化一個(gè)類，然后根據(jù)request的內(nèi)容，解析body，然后去初始化header, 獲得packager_name，根據(jù)packer_name解析yar_body的內(nèi)容。

以下是每次request和response的數(shù)據(jù)情況。以request為例傳輸?shù)腷ody數(shù)據(jù)包含三個(gè)部分，82byte的頭部，packager_name，和經(jīng)過packager_name序列化的string。當(dāng)這段數(shù)據(jù)傳到server端，按照固定的結(jié)構(gòu)解析出來即可。

PACK過程是對(duì)數(shù)據(jù)作如下處理的過程。以msgpack為例，對(duì)中間部分的數(shù)據(jù)進(jìn)行序列化。生成最右邊的內(nèi)容(序列化后的字符串有最右有差別，這里只是拿json舉例)。

傳輸

yar目前有兩種傳輸方式，這個(gè)在之前提到過curl和socket方式。因?yàn)閟ocket實(shí)際沒有用過所以這里主要介紹curl。

curl的模塊主要以來底層的CURL模塊，主要封裝了如下方法。其中multi系列主要是解決并行請(qǐng)求的方案。

php_yar_curl_open

這個(gè)方法主要是用CURL創(chuàng)建一個(gè)連接對(duì)象。這里有個(gè)復(fù)用的機(jī)制，當(dāng)options &

YAR_PROTOCOL_PERSISTENT(0x1) 為true的時(shí)候，會(huì)去已經(jīng)使用的連接中找一下，如果存在并且沒有在用則復(fù)用。

php_yar_curl_send

這個(gè)函數(shù)主要是把request需要的數(shù)據(jù)，轉(zhuǎn)成字符串，然后放在請(qǐng)求的postfield里面。

php_yar_curl_exec

將postfield內(nèi)容，通過http請(qǐng)求發(fā)送出去。獲得返回的內(nèi)容。然后按照上述內(nèi)容解析出結(jié)果。

本來還想分享grpc的protobuf和htt2，鑒于粗淺學(xué)習(xí)階段，網(wǎng)上的其他博客文章更詳細(xì)，這里就不寫了，等我實(shí)際有自己的理解再說啦。

凡事都沒有完美，也碰到過yar的不足之處，比如server的handle方法，解析post數(shù)據(jù)，執(zhí)行對(duì)應(yīng)的方法返回都在這里了。沒有將請(qǐng)求的實(shí)際方法暴露，這樣在server端統(tǒng)計(jì)起來比較困難。曾試圖在源碼中加個(gè)getCallMethod方法去標(biāo)記這個(gè)內(nèi)容，不過只是自己玩玩，沒有實(shí)際應(yīng)用...

有同學(xué)問我為啥我們當(dāng)時(shí)要用yar，也許別的框架也能滿足我們的需求，一定的歷史背景決定一定的技術(shù)架構(gòu)。技術(shù)的選型更多傾向于開發(fā)者的水平----即選擇自己駕馭的技術(shù)，站在巨人的肩膀上展望遠(yuǎn)處。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

本文題目：rpc框架yar之源碼解析-入門和原理介紹-創(chuàng)新互聯(lián)
URL標(biāo)題：http://www.bm7419.com/article16/dcdodg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信公眾號(hào)、品牌網(wǎng)站建設(shè)、App設(shè)計(jì)、面包屑導(dǎo)航、關(guān)鍵詞優(yōu)化、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)