rpc 调用webservice怎样传递参数_五分钟让你了解RPC原理详解
歡迎關注專欄【以架構贏天下】——每天持續(xù)分享Java相關知識點
以架構贏天下?zhuanlan.zhihu.com- 以架構贏天下——持續(xù)分享Java相關知識點
- 每篇文章首發(fā)此專欄
- 歡迎各路Java程序員關注及投稿
- 干貨資料大派送<Java相關資料分享>
RPC 功能目標
RPC 的主要功能目標是讓構建分布式計算（應用）更容易，在提供強大的遠程調(diào)用能力時不損失本地調(diào)用的語義簡潔性。 為實現(xiàn)該目標，RPC 框架需提供一種透明調(diào)用機制讓使用者不必顯式的區(qū)分本地調(diào)用和遠程調(diào)用。 下面我們將具體細化 stub 結構的實現(xiàn)。
RPC 調(diào)用分類
RPC 調(diào)用分以下兩種：
- 同步調(diào)用
客戶方等待調(diào)用執(zhí)行完成并返回結果。 - 異步調(diào)用
客戶方調(diào)用后不用等待執(zhí)行結果返回，但依然可以通過回調(diào)通知等方式獲取返回結果。 若客戶方不關心調(diào)用返回結果，則變成單向異步調(diào)用，單向調(diào)用不用返回結果。
異步和同步的區(qū)分在于是否等待服務端執(zhí)行完成并返回結果。
RPC 結構拆解
如下圖所示。
RPC 服務方通過 RpcServer 去導出（export）遠程接口方法，而客戶方通過 RpcClient 去引入（import）遠程接口方法。 客戶方像調(diào)用本地方法一樣去調(diào)用遠程接口方法，RPC 框架提供接口的代理實現(xiàn)，實際的調(diào)用將委托給代理 RpcProxy 。 代理封裝調(diào)用信息并將調(diào)用轉交給 RpcInvoker 去實際執(zhí)行。 在客戶端的 RpcInvoker 通過連接器 RpcConnector 去維持與服務端的通道 RpcChannel， 并使用 RpcProtocol 執(zhí)行協(xié)議編碼（encode）并將編碼后的請求消息通過通道發(fā)送給服務方。
RPC 服務端接收器 RpcAcceptor 接收客戶端的調(diào)用請求，同樣使用 RpcProtocol 執(zhí)行協(xié)議解碼（decode）。 解碼后的調(diào)用信息傳遞給 RpcProcessor 去控制處理調(diào)用過程，最后再委托調(diào)用給 RpcInvoker 去實際執(zhí)行并返回調(diào)用結果。
RPC 組件職責
上面我們進一步拆解了 RPC 實現(xiàn)結構的各個組件組成部分，下面我們詳細說明下每個組件的職責劃分。
- RpcServer
負責導出（export）遠程接口 - RpcClient
負責導入（import）遠程接口的代理實現(xiàn) - RpcProxy
遠程接口的代理實現(xiàn) - RpcInvoker
客戶方實現(xiàn)：負責編碼調(diào)用信息和發(fā)送調(diào)用請求到服務方并等待調(diào)用結果返回
服務方實現(xiàn)：負責調(diào)用服務端接口的具體實現(xiàn)并返回調(diào)用結果 - RpcProtocol
負責協(xié)議編/解碼 - RpcConnector
負責維持客戶方和服務方的連接通道和發(fā)送數(shù)據(jù)到服務方 - RpcAcceptor
負責接收客戶方請求并返回請求結果 - RpcProcessor
負責在服務方控制調(diào)用過程，包括管理調(diào)用線程池、超時時間等 - RpcChannel
數(shù)據(jù)傳輸通道
RPC 實現(xiàn)分析
在進一步拆解了組件并劃分了職責之后，這里以在 java 平臺實現(xiàn)該 RPC 框架概念模型為例，詳細分析下實現(xiàn)中需要考慮的因素。
導出遠程接口
導出遠程接口的意思是指只有導出的接口可以供遠程調(diào)用，而未導出的接口則不能。 在 java 中導出接口的代碼片段可能如下：
DemoService demo = new ...; RpcServer server = new ...; server.export(DemoService.class, demo, options);我們可以導出整個接口，也可以更細粒度一點只導出接口中的某些方法，如：
// 只導出 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)，那么在導出接口時就需要特殊標記不同的實現(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)，我們標記為 demo2 來導出， 那么遠程調(diào)用時也需要傳遞該標記才能調(diào)用到正確的實現(xiàn)類，這樣就解決了多態(tài)調(diào)用的語義。
導入遠程接口與客戶端代理
導入相對于導出遠程接口，客戶端代碼為了能夠發(fā)起調(diào)用必須要獲得遠程接口的方法或過程定義。 目前，大部分跨語言平臺 RPC 框架采用根據(jù) IDL 定義通過 code generator 去生成 stub 代碼， 這種方式下實際導入的過程就是通過代碼生成器在編譯期完成的。 我所使用過的一些跨語言平臺 RPC 框架如 CORBAR、WebService、ICE、Thrift 均是此類方式。
代碼生成的方式對跨語言平臺 RPC 框架而言是必然的選擇，而對于同一語言平臺的 RPC 則可以通過共享接口定義來實現(xiàn)。 在 java 中導入接口的代碼片段可能如下：
RpcClient client = new ...; DemoService demo = client.refer(DemoService.class); demo.hi("how are you?");在 java 中 import 是關鍵字，所以代碼片段中我們用 refer 來表達導入接口的意思。 這里的導入方式本質也是一種代碼生成技術，只不過是在運行時生成，比靜態(tài)編譯期的代碼生成看起來更簡潔些。 java 里至少提供了兩種技術來提供動態(tài)代碼生成，一種是 jdk 動態(tài)代理，另外一種是字節(jié)碼生成。 動態(tài)代理相比字節(jié)碼生成使用起來更方便，但動態(tài)代理方式在性能上是要遜色于直接的字節(jié)碼生成的，而字節(jié)碼生成在代碼可讀性上要差很多。 兩者權衡起來，個人認為犧牲一些性能來獲得代碼可讀性和可維護性顯得更重要。
協(xié)議編解碼
客戶端代理在發(fā)起調(diào)用前需要對調(diào)用信息進行編碼，這就要考慮需要編碼些什么信息并以什么格式傳輸?shù)椒斩瞬拍茏尫斩送瓿烧{(diào)用。 出于效率考慮，編碼的信息越少越好（傳輸數(shù)據(jù)少），編碼的規(guī)則越簡單越好（執(zhí)行效率高）。 我們先看下需要編碼些什么信息：
調(diào)用編碼
- 接口方法
包括接口名、方法名 - 方法參數(shù)
包括參數(shù)類型、參數(shù)值 - 調(diào)用屬性
包括調(diào)用屬性信息，例如調(diào)用附件隱式參數(shù)、調(diào)用超時時間等
返回編碼
- 返回結果
接口方法中定義的返回值 - 返回碼
異常返回碼 - 返回異常信息
調(diào)用異常信息
除了以上這些必須的調(diào)用信息，我們可能還需要一些元信息以方便程序編解碼以及未來可能的擴展。 這樣我們的編碼消息里面就分成了兩部分，一部分是元信息、另一部分是調(diào)用的必要信息。 如果設計一種 RPC 協(xié)議消息的話，元信息我們把它放在協(xié)議消息頭中，而必要信息放在協(xié)議消息體中。 下面給出一種概念上的 RPC 協(xié)議消息設計格式：
消息頭
- magic: 協(xié)議魔數(shù)，為解碼設計
- header size: 協(xié)議頭長度，為擴展設計
- version: 協(xié)議版本，為兼容設計
- st: 消息體序列化類型
- hb: 心跳消息標記，為長連接傳輸層心跳設計
- ow: 單向消息標記，
- rp: 響應消息標記，不置位默認是請求消息
- status code: 響應消息狀態(tài)碼
- reserved: 為字節(jié)對齊保留
- message id: 消息 id
- body size: 消息體長度
消息體
采用序列化編碼，常見有以下格式
- xml: 如 webservie SOAP
- json: 如 JSON-RPC
- binary: 如 thrift; hession; kryo 等
格式確定后編解碼就簡單了，由于頭長度一定所以我們比較關心的就是消息體的序列化方式。 序列化我們關心三個方面：
上面這三點有時是魚與熊掌不可兼得，這里面涉及到具體的序列化庫實現(xiàn)細節(jié)，就不在本文進一步展開分析了。
傳輸服務
協(xié)議編碼之后，自然就是需要將編碼后的 RPC 請求消息傳輸?shù)椒辗?#xff0c;服務方執(zhí)行后返回結果消息或確認消息給客戶方。 RPC 的應用場景實質是一種可靠的請求應答消息流，和 HTTP 類似。 因此選擇長連接方式的 TCP 協(xié)議會更高效，與 HTTP 不同的是在協(xié)議層面我們定義了每個消息的唯一 id，因此可以更容易的復用連接。
既然使用長連接，那么第一個問題是到底 client 和 server 之間需要多少根連接？ 實際上單連接和多連接在使用上沒有區(qū)別，對于數(shù)據(jù)傳輸量較小的應用類型，單連接基本足夠。 單連接和多連接最大的區(qū)別在于，每根連接都有自己私有的發(fā)送和接收緩沖區(qū)， 因此大數(shù)據(jù)量傳輸時分散在不同的連接緩沖區(qū)會得到更好的吞吐效率。 所以，如果你的數(shù)據(jù)傳輸量不足以讓單連接的緩沖區(qū)一直處于飽和狀態(tài)的話，那么使用多連接并不會產(chǎn)生任何明顯的提升， 反而會增加連接管理的開銷。
連接是由 client 端發(fā)起建立并維持。 如果 client 和 server 之間是直連的，那么連接一般不會中斷（當然物理鏈路故障除外）。 如果 client 和 server 連接經(jīng)過一些負載中轉設備，有可能連接一段時間不活躍時會被這些中間設備中斷。 為了保持連接有必要定時為每個連接發(fā)送心跳數(shù)據(jù)以維持連接不中斷。 心跳消息是 RPC 框架庫使用的內(nèi)部消息，在前文協(xié)議頭結構中也有一個專門的心跳位， 就是用來標記心跳消息的，它對業(yè)務應用透明。
執(zhí)行調(diào)用
client stub 所做的事情僅僅是編碼消息并傳輸給服務方，而真正調(diào)用過程發(fā)生在服務方。 server stub 從前文的結構拆解中我們細分了 RpcProcessor 和 RpcInvoker 兩個組件， 一個負責控制調(diào)用過程，一個負責真正調(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)用控制服務呢？ 下面提出幾點以啟發(fā)思考：
- 效率提升
每個請求應該盡快被執(zhí)行，因此我們不能每請求來再創(chuàng)建線程去執(zhí)行，需要提供線程池服務。 - 資源隔離
當我們導出多個遠程接口時，如何避免單一接口調(diào)用占據(jù)所有線程資源，而引發(fā)其他接口執(zhí)行阻塞。 - 超時控制
當某個接口執(zhí)行緩慢，而 client 端已經(jīng)超時放棄等待后，server 端的線程繼續(xù)執(zhí)行此時顯得毫無意義。
RPC 異常處理
無論 RPC 怎樣努力把遠程調(diào)用偽裝的像本地調(diào)用，但它們依然有很大的不同點，而且有一些異常情況是在本地調(diào)用時絕對不會碰到的。 在說異常處理之前，我們先比較下本地調(diào)用和 RPC 調(diào)用的一些差異：
正是這些區(qū)別決定了使用 RPC 時需要更多考量。 當調(diào)用遠程接口拋出異常時，異常可能是一個業(yè)務異常， 也可能是 RPC 框架拋出的運行時異常（如：網(wǎng)絡中斷等）。 業(yè)務異常表明服務方已經(jīng)執(zhí)行了調(diào)用，可能因為某些原因導致未能正常執(zhí)行， 而 RPC 運行時異常則有可能服務方根本沒有執(zhí)行，對調(diào)用方而言的異常處理策略自然需要區(qū)分。
由于 RPC 固有的消耗相對本地調(diào)用高出幾個數(shù)量級，本地調(diào)用的固有消耗是納秒級，而 RPC 的固有消耗是在毫秒級。 那么對于過于輕量的計算任務就并不合適導出遠程接口由獨立的進程提供服務， 只有花在計算任務上時間遠遠高于 RPC 的固有消耗才值得導出為遠程接口提供服務。
總結
至此我們提出了一個 RPC 實現(xiàn)的概念框架，并詳細分析了需要考慮的一些實現(xiàn)細節(jié)。 無論 RPC 的概念是如何優(yōu)雅，但是“草叢中依然有幾條蛇隱藏著”，只有深刻理解了 RPC 的本質，才能更好地應用。
需獲取資料的關注我的專欄（以架構贏天下）看專欄介紹，或直接（點擊我）即可獲取資料！
海量Java干貨，資訊，關注專欄
以架構贏天下?zhuanlan.zhihu.com千道Java面試真題，百本核心電子書籍，十余年架構精心整理視頻
Java學習筆記，面試，文檔以及視頻領取?shimo.im總結
以上是生活随笔為你收集整理的rpc 调用webservice怎样传递参数_五分钟让你了解RPC原理详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 箱线图的四分位怎么计算_Minitab图
- 下一篇： 东方红LR4MC-T59加什么机油？