西寧ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)建站的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！

首先了解什么叫RPC，為什么要RPC，RPC是指遠程過程調(diào)用，也就是說兩臺服務(wù)器A，B，一個應(yīng)用部署在A服務(wù)器上，想要調(diào)用B服務(wù)器上應(yīng)用提供的函數(shù)/方法，由于不在一個內(nèi)存空間，不能直接調(diào)用，需要通過網(wǎng)絡(luò)來表達調(diào)用的語義和傳達調(diào)用的數(shù)據(jù)。

RPC 功能目標(biāo)

RPC 的主要功能目標(biāo)是讓構(gòu)建分布式計算（應(yīng)用）更容易，在提供強大的遠程調(diào)用能力時不損失本地調(diào)用的語義簡潔性。為實現(xiàn)該目標(biāo)，RPC 框架需提供一種透明調(diào)用機制讓使用者不必顯式的區(qū)分本地調(diào)用和遠程調(diào)用，在前文《淺出篇》中給出了一種實現(xiàn)結(jié)構(gòu)，基于 stub 的結(jié)構(gòu)來實現(xiàn)。下面我們將具體細化 stub 結(jié)構(gòu)的實現(xiàn)。

RPC 調(diào)用分類

RPC 調(diào)用分以下兩種：

?

1. 同步調(diào)用 ?
? 客戶方等待調(diào)用執(zhí)行完成并返回結(jié)果。?
2. 異步調(diào)用 ?
? 客戶方調(diào)用后不用等待執(zhí)行結(jié)果返回，但依然可以通過回調(diào)通知等方式獲取返回結(jié)果。?
? 若客戶方不關(guān)心調(diào)用返回結(jié)果，則變成單向異步調(diào)用，單向調(diào)用不用返回結(jié)果。

異步和同步的區(qū)分在于是否等待服務(wù)端執(zhí)行完成并返回結(jié)果。

RPC 結(jié)構(gòu)拆解

《淺出篇》給出了一個比較粗粒度的 RPC 實現(xiàn)概念結(jié)構(gòu)，這里我們進一步細化它應(yīng)該由哪些組件構(gòu)成，如下圖所示。

RPC 服務(wù)方通過?RpcServer?去導(dǎo)出（export）遠程接口方法，而客戶方通過?RpcClient?去引入（import）遠程接口方法?？蛻舴较裾{(diào)用本地方法一樣去調(diào)用遠程接口方法，RPC 框架提供接口的代理實現(xiàn)，實際的調(diào)用將委托給代理RpcProxy?。代理封裝調(diào)用信息并將調(diào)用轉(zhuǎn)交給RpcInvoker?去實際執(zhí)行。在客戶端的RpcInvoker?通過連接器RpcConnector?去維持與服務(wù)端的通道RpcChannel，并使用RpcProtocol?執(zhí)行協(xié)議編碼（encode）并將編碼后的請求消息通過通道發(fā)送給服務(wù)方。

RPC 服務(wù)端接收器?RpcAcceptor?接收客戶端的調(diào)用請求，同樣使用RpcProtocol?執(zhí)行協(xié)議解碼（decode）。解碼后的調(diào)用信息傳遞給RpcProcessor?去控制處理調(diào)用過程，最后再委托調(diào)用給RpcInvoker?去實際執(zhí)行并返回調(diào)用結(jié)果。

RPC 組件職責(zé)

上面我們進一步拆解了 RPC 實現(xiàn)結(jié)構(gòu)的各個組件組成部分，下面我們詳細說明下每個組件的職責(zé)劃分。

?

1. RpcServer ?
? 負(fù)責(zé)導(dǎo)出（export）遠程接口 ?
2. RpcClient ?
? 負(fù)責(zé)導(dǎo)入（import）遠程接口的代理實現(xiàn) ?
3. RpcProxy ?
? 遠程接口的代理實現(xiàn) ?
4. RpcInvoker ?
? 客戶方實現(xiàn)：負(fù)責(zé)編碼調(diào)用信息和發(fā)送調(diào)用請求到服務(wù)方并等待調(diào)用結(jié)果返回 ?
? 服務(wù)方實現(xiàn)：負(fù)責(zé)調(diào)用服務(wù)端接口的具體實現(xiàn)并返回調(diào)用結(jié)果 ?
5. RpcProtocol ?
? 負(fù)責(zé)協(xié)議編/解碼 ?
6. RpcConnector ?
? 負(fù)責(zé)維持客戶方和服務(wù)方的連接通道和發(fā)送數(shù)據(jù)到服務(wù)方 ?
7. RpcAcceptor ?
? 負(fù)責(zé)接收客戶方請求并返回請求結(jié)果 ?
8. RpcProcessor ?
? 負(fù)責(zé)在服務(wù)方控制調(diào)用過程，包括管理調(diào)用線程池、超時時間等 ?
9. RpcChannel ?
? 數(shù)據(jù)傳輸通道 ?

RPC 實現(xiàn)分析

在進一步拆解了組件并劃分了職責(zé)之后，這里以在 java 平臺實現(xiàn)該 RPC 框架概念模型為例，詳細分析下實現(xiàn)中需要考慮的因素。

導(dǎo)出遠程接口

導(dǎo)出遠程接口的意思是指只有導(dǎo)出的接口可以供遠程調(diào)用，而未導(dǎo)出的接口則不能。在 java 中導(dǎo)出接口的代碼片段可能如下：

?

DemoService demo ? = new ...; ?
RpcServer ? server = new ...; ?
server.export(DemoService.class, demo, options); ? ?

我們可以導(dǎo)出整個接口，也可以更細粒度一點只導(dǎo)出接口中的某些方法，如：

?

// 只導(dǎo)出 DemoService 中簽名為 hi(String s) 的方法 ?
server.export(DemoService.class, demo, "hi", new Class<?>[] { String.class }, options); ? ?

java 中還有一種比較特殊的調(diào)用就是多態(tài)，也就是一個接口可能有多個實現(xiàn)，那么遠程調(diào)用時到底調(diào)用哪個？這個本地調(diào)用的語義是通過 jvm 提供的引用多態(tài)性隱式實現(xiàn)的，那么對于 RPC 來說跨進程的調(diào)用就沒法隱式實現(xiàn)了。如果前面DemoService?接口有 2 個實現(xiàn)，那么在導(dǎo)出接口時就需要特殊標(biāo)記不同的實現(xiàn)，如：

?

DemoService demo ? = new ...; ?
DemoService demo2 ?= new ...; ?
RpcServer ? server = new ...; ?
server.export(DemoService.class, demo, options); ?
server.export("demo2", DemoService.class, demo2, options); ? ?

上面 demo2 是另一個實現(xiàn)，我們標(biāo)記為 "demo2" 來導(dǎo)出，那么遠程調(diào)用時也需要傳遞該標(biāo)記才能調(diào)用到正確的實現(xiàn)類，這樣就解決了多態(tài)調(diào)用的語義。

導(dǎo)入遠程接口與客戶端代理

導(dǎo)入相對于導(dǎo)出遠程接口，客戶端代碼為了能夠發(fā)起調(diào)用必須要獲得遠程接口的方法或過程定義。目前，大部分跨語言平臺 RPC 框架采用根據(jù) IDL 定義通過 code generator 去生成 stub 代碼，這種方式下實際導(dǎo)入的過程就是通過代碼生成器在編譯期完成的。我所使用過的一些跨語言平臺 RPC 框架如 CORBAR、WebService、ICE、Thrift 均是此類方式。

代碼生成的方式對跨語言平臺 RPC 框架而言是必然的選擇，而對于同一語言平臺的 RPC 則可以通過共享接口定義來實現(xiàn)。在 java 中導(dǎo)入接口的代碼片段可能如下：

?

RpcClient client = new ...; ?
DemoService demo = client.refer(DemoService.class); ?
demo.hi("how are you?"); ? ? ?

在 java 中 'import' 是關(guān)鍵字，所以代碼片段中我們用 refer 來表達導(dǎo)入接口的意思。這里的導(dǎo)入方式本質(zhì)也是一種代碼生成技術(shù)，只不過是在運行時生成，比靜態(tài)編譯期的代碼生成看起來更簡潔些。java 里至少提供了兩種技術(shù)來提供動態(tài)代碼生成，一種是 jdk 動態(tài)代理，另外一種是字節(jié)碼生成。動態(tài)代理相比字節(jié)碼生成使用起來更方便，但動態(tài)代理方式在性能上是要遜色于直接的字節(jié)碼生成的，而字節(jié)碼生成在代碼可讀性上要差很多。兩者權(quán)衡起來，個人認(rèn)為犧牲一些性能來獲得代碼可讀性和可維護性顯得更重要。

協(xié)議編解碼

客戶端代理在發(fā)起調(diào)用前需要對調(diào)用信息進行編碼，這就要考慮需要編碼些什么信息并以什么格式傳輸?shù)椒?wù)端才能讓服務(wù)端完成調(diào)用。出于效率考慮，編碼的信息越少越好（傳輸數(shù)據(jù)少），編碼的規(guī)則越簡單越好（執(zhí)行效率高）。我們先看下需要編碼些什么信息：

?

-- 調(diào)用編碼 -- ?
1. 接口方法 ?
? 包括接口名、方法名 ?
2. 方法參數(shù) ?
? 包括參數(shù)類型、參數(shù)值 ?
3. 調(diào)用屬性 ?
? 包括調(diào)用屬性信息，例如調(diào)用附件隱式參數(shù)、調(diào)用超時時間等 ?
-- 返回編碼 -- ?
1. 返回結(jié)果 ?
? 接口方法中定義的返回值 ?
2. 返回碼 ?
? 異常返回碼 ?
3. 返回異常信息 ?
? 調(diào)用異常信息 ? ? ?

除了以上這些必須的調(diào)用信息，我們可能還需要一些元信息以方便程序編解碼以及未來可能的擴展。這樣我們的編碼消息里面就分成了兩部分，一部分是元信息、另一部分是調(diào)用的必要信息。如果設(shè)計一種 RPC 協(xié)議消息的話，元信息我們把它放在協(xié)議消息頭中，而必要信息放在協(xié)議消息體中。下面給出一種概念上的 RPC 協(xié)議消息設(shè)計格式：

?

-- 消息頭 -- ?
magic ? ? ?: 協(xié)議魔數(shù)，為解碼設(shè)計 ?
header size: 協(xié)議頭長度，為擴展設(shè)計 ?
version ? ?: 協(xié)議版本，為兼容設(shè)計 ?
st ? ? ? ? : 消息體序列化類型 ?
hb ? ? ? ? : 心跳消息標(biāo)記，為長連接傳輸層心跳設(shè)計 ?
ow ? ? ? ? : 單向消息標(biāo)記， ?
rp ? ? ? ? : 響應(yīng)消息標(biāo)記，不置位默認(rèn)是請求消息 ?
status code: 響應(yīng)消息狀態(tài)碼 ?
reserved ? : 為字節(jié)對齊保留 ?
message id : 消息 id ?
body size ?: 消息體長度 ?
-- 消息體 -- ?
采用序列化編碼，常見有以下格式 ?
xml ? : 如 webservie soap ?
json ?: 如 JSON-RPC ?
binary: 如 thrift; hession; kryo 等 ? ? ?

格式確定后編解碼就簡單了，由于頭長度一定所以我們比較關(guān)心的就是消息體的序列化方式。序列化我們關(guān)心三個方面：

1. 序列化和反序列化的效率，越快越好。?
2. 序列化后的字節(jié)長度，越小越好。?
3. 序列化和反序列化的兼容性，接口參數(shù)對象若增加了字段，是否兼容。

上面這三點有時是魚與熊掌不可兼得，這里面涉及到具體的序列化庫實現(xiàn)細節(jié)，就不在本文進一步展開分析了。

傳輸服務(wù)

協(xié)議編碼之后，自然就是需要將編碼后的 RPC 請求消息傳輸?shù)椒?wù)方，服務(wù)方執(zhí)行后返回結(jié)果消息或確認(rèn)消息給客戶方。RPC 的應(yīng)用場景實質(zhì)是一種可靠的請求應(yīng)答消息流，和 HTTP 類似。因此選擇長連接方式的 TCP 協(xié)議會更高效，與 HTTP 不同的是在協(xié)議層面我們定義了每個消息的唯一 id，因此可以更容易的復(fù)用連接。

既然使用長連接，那么第一個問題是到底 client 和 server 之間需要多少根連接？實際上單連接和多連接在使用上沒有區(qū)別，對于數(shù)據(jù)傳輸量較小的應(yīng)用類型，單連接基本足夠。單連接和多連接大的區(qū)別在于，每根連接都有自己私有的發(fā)送和接收緩沖區(qū)，因此大數(shù)據(jù)量傳輸時分散在不同的連接緩沖區(qū)會得到更好的吞吐效率。所以，如果你的數(shù)據(jù)傳輸量不足以讓單連接的緩沖區(qū)一直處于飽和狀態(tài)的話，那么使用多連接并不會產(chǎn)生任何明顯的提升，反而會增加連接管理的開銷。

連接是由 client 端發(fā)起建立并維持。如果 client 和 server 之間是直連的，那么連接一般不會中斷（當(dāng)然物理鏈路故障除外）。如果 client 和 server 連接經(jīng)過一些負(fù)載中轉(zhuǎn)設(shè)備，有可能連接一段時間不活躍時會被這些中間設(shè)備中斷。為了保持連接有必要定時為每個連接發(fā)送心跳數(shù)據(jù)以維持連接不中斷。心跳消息是 RPC 框架庫使用的內(nèi)部消息，在前文協(xié)議頭結(jié)構(gòu)中也有一個專門的心跳位，就是用來標(biāo)記心跳消息的，它對業(yè)務(wù)應(yīng)用透明。

執(zhí)行調(diào)用

client stub 所做的事情僅僅是編碼消息并傳輸給服務(wù)方，而真正調(diào)用過程發(fā)生在服務(wù)方。server stub 從前文的結(jié)構(gòu)拆解中我們細分了?RpcProcessor?和RpcInvoker?兩個組件，一個負(fù)責(zé)控制調(diào)用過程，一個負(fù)責(zé)真正調(diào)用。這里我們還是以 java 中實現(xiàn)這兩個組件為例來分析下它們到底需要做什么？

java 中實現(xiàn)代碼的動態(tài)接口調(diào)用目前一般通過反射調(diào)用。除了原生的 jdk 自帶的反射，一些第三方庫也提供了性能更優(yōu)的反射調(diào)用，因此?RpcInvoker?就是封裝了反射調(diào)用的實現(xiàn)細節(jié)。

調(diào)用過程的控制需要考慮哪些因素，RpcProcessor?需要提供什么樣地調(diào)用控制服務(wù)呢？下面提出幾點以啟發(fā)思考：

?

1. 效率提升 ?
? 每個請求應(yīng)該盡快被執(zhí)行，因此我們不能每請求來再創(chuàng)建線程去執(zhí)行，需要提供線程池服務(wù)。?
2. 資源隔離 ?
? 當(dāng)我們導(dǎo)出多個遠程接口時，如何避免單一接口調(diào)用占據(jù)所有線程資源，而引發(fā)其他接口執(zhí)行阻塞。?
3. 超時控制 ?
? 當(dāng)某個接口執(zhí)行緩慢，而 client 端已經(jīng)超時放棄等待后，server 端的線程繼續(xù)執(zhí)行此時顯得毫無意義。?

RPC 異常處理

無論 RPC 怎樣努力把遠程調(diào)用偽裝的像本地調(diào)用，但它們依然有很大的不同點，而且有一些異常情況是在本地調(diào)用時絕對不會碰到的。在說異常處理之前，我們先比較下本地調(diào)用和 RPC 調(diào)用的一些差異：

1. 本地調(diào)用一定會執(zhí)行，而遠程調(diào)用則不一定，調(diào)用消息可能因為網(wǎng)絡(luò)原因并未發(fā)送到服務(wù)方。
2. 本地調(diào)用只會拋出接口聲明的異常，而遠程調(diào)用還會跑出 RPC 框架運行時的其他異常。
3. 本地調(diào)用和遠程調(diào)用的性能可能差距很大，這取決于 RPC 固有消耗所占的比重。

正是這些區(qū)別決定了使用 RPC 時需要更多考量。當(dāng)調(diào)用遠程接口拋出異常時，異?？赡苁且粋€業(yè)務(wù)異常，也可能是 RPC 框架拋出的運行時異常（如：網(wǎng)絡(luò)中斷等）。業(yè)務(wù)異常表明服務(wù)方已經(jīng)執(zhí)行了調(diào)用，可能因為某些原因?qū)е挛茨苷?zhí)行，而 RPC 運行時異常則有可能服務(wù)方根本沒有執(zhí)行，對調(diào)用方而言的異常處理策略自然需要區(qū)分。

由于 RPC 固有的消耗相對本地調(diào)用高出幾個數(shù)量級，本地調(diào)用的固有消耗是納秒級，而 RPC 的固有消耗是在毫秒級。那么對于過于輕量的計算任務(wù)就并不合適導(dǎo)出遠程接口由獨立的進程提供服務(wù)，只有花在計算任務(wù)上時間遠遠高于 RPC 的固有消耗才值得導(dǎo)出為遠程接口提供服務(wù)。

總結(jié)

至此我們提出了一個 RPC 實現(xiàn)的概念框架，并詳細分析了需要考慮的一些實現(xiàn)細節(jié)。無論 RPC 的概念是如何優(yōu)雅，但是“草叢中依然有幾條蛇隱藏著”，只有深刻理解了 RPC 的本質(zhì)，才能更好地應(yīng)用。

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

分享名稱：整天跟微服務(wù)打交道，你不會連RPC都不知道吧？-創(chuàng)新互聯(lián)
文章來源：http://jinyejixie.com/article8/csooip.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、手機網(wǎng)站建設(shè)、品牌網(wǎng)站設(shè)計、云服務(wù)器、網(wǎng)站收錄、關(guān)鍵詞優(yōu)化

廣告

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