RPC的簡介

1.定義：

　　RPC 的全稱是 Remote Procedure Call 是一種進程間通訊方式。它容許程序調用另外一個地址空間（一般是共享網絡的另外一臺機器上）的過程或函數，而不用程序員顯式編碼這個遠程調用的細節。即程序員不管是調用本地的仍是遠程的，本質上編寫的調用代碼基本相同。

2.功能目標：

　　RPC 的主要功能目標是讓構建分佈式計算（應用）更容易，在提供強大的遠程調用能力時不損失本地調用的語義簡潔性。爲實現該目標，RPC 框架需提供一種透明調用機制讓使用者沒必要顯式的區分本地調用和遠程調用。

3.結構：

　　RPC 的程序包括 5 個部分：User、User-stub、RPCRuntime、 Server-stub、Server

　　RPC 服務方經過 RpcServer 去導出（export）遠程接口方法，而客戶方經過 RpcClient 去引入（import）遠程接口方法。客戶方像調用本地方法同樣去調用遠程接口方法，RPC 框架提供接口的代理實現，實際的調用將委託給代理RpcProxy 。代理封裝調用信息並將調用轉交給RpcInvoker 去實際執行。在客戶端的RpcInvoker 經過鏈接器RpcConnector 去維持與服務端的通道RpcChannel，並使用RpcProtocol 執行協議編碼（encode）並將編碼後的請求消息經過通道發送給服務方。RPC 服務端接收器 RpcAcceptor 接收客戶端的調用請求，一樣使用RpcProtocol 執行協議解碼（decode）。解碼後的調用信息傳遞給RpcProcessor 去控制處理調用過程，最後再委託調用給RpcInvoker 去實際執行並返回調用結果。

4.調用分類：

 （1）同步調用 ：     客戶方等待調用執行完成並返回結果。  

 （2）異步調用  ：    客戶方調用後不用等待執行結果返回，但依然能夠經過回調通知等方式獲取返回結果。      若客戶方不關心調用返回結果，則變成單向異步調用，單向調用不用返回結果。

異步和同步的區分在因而否等待服務端執行完成並返回結果。

5.組件分類：

（1） RpcServer      負責導出（export）遠程接口  

（2） RpcClient      負責導入（import）遠程接口的代理實現  

（3）RpcProxy      遠程接口的代理實現  

（4） RpcInvoker      客戶方實現：負責編碼調用信息和發送調用請求到服務方並等待調用結果返回      服務方實現：負責調用服務端接口的具體實現並返回調用結果  

（5） RpcProtocol      負責協議編/解碼  

（6） RpcConnector      負責維持客戶方和服務方的鏈接通道和發送數據到服務方  

（7）RpcAcceptor      負責接收客戶方請求並返回請求結果  

（8）RpcProcessor      負責在服務方控制調用過程，包括管理調用線程池、超時時間等  

（9）RpcChannel      數據傳輸通道

6.導出遠程接口 ：

　　導出遠程接口的意思是指只有導出的接口能夠供遠程調用，而未導出的接口則不能。

7.導入遠程接口與客戶端代理 ：

　　導入相對於導出遠程接口，客戶端代碼爲了可以發起調用必需要得到遠程接口的方法或過程定義。目前，大部分跨語言平臺 RPC 框架採用根據 IDL 定義經過 code generator 去生成 stub 代碼，這種方式下實際導入的過程就是經過代碼生成器在編譯期完成的。我所使用過的一些跨語言平臺 RPC 框架如 CORBAR、WebService、ICE、Thrift 均是此類方式。 代碼生成的方式對跨語言平臺 RPC 框架而言是必然的選擇，而對於同一語言平臺的 RPC 則能夠經過共享接口定義來實現。

8.協議編解碼 ：

　　客戶端代理在發起調用前須要對調用信息進行編碼，這就要考慮須要編碼些什麼信息並以什麼格式傳輸到服務端才能讓服務端完成調用。出於效率考慮，編碼的信息越少越好（傳輸數據少），編碼的規則越簡單越好（執行效率高）。須要的編碼信息： 調用編碼 --   接口方法（接口名、方法名）方法參數（參數類型、參數值）調用屬性（調用屬性信息，例如調用附件隱式參數、調用超時時間等 -- 返回編碼 --   返回結果（接口方法中定義的返回值）返回碼（異常返回碼）返回異常信息（調用異常信息）除了以上這些必須的調用信息，咱們可能還須要一些元信息以方便程序編解碼以及將來可能的擴展。這樣咱們的編碼消息裏面就分紅了兩部分，一部分是元信息、另外一部分是調用的必要信息。若是設計一種 RPC 協議消息的話，元信息咱們把它放在協議消息頭中，而必要信息放在協議消息體中。下面給出一種概念上的 RPC 協議消息設計格式：  

-- 消息頭 --   magic: 協議魔數，爲解碼設計 ； header size: 協議頭長度，爲擴展設計 ；version : 協議版本，爲兼容設計；st  : 消息體序列化類型 ；hb : 心跳消息標記，爲長鏈接傳輸層心跳設計 ； ow  : 單向消息標記； rp  : 響應消息標記，不置位默認是請求消息 ；status code: 響應消息狀態碼； reserved : 爲字節對齊保留；message id : 消息 id；body size : 消息體長度 ；

-- 消息體 --   採用序列化編碼，常見有如下格式   xml: 如 webservie soap；json: 如 JSON-RPC ；binary: 如 thrift; hession; kryo 等。格式肯定後編解碼就簡單了，因爲頭長度必定因此咱們比較關心的就是消息體的序列化方式。序列化咱們關心三個方面：（1）序列化和反序列化的效率，越快越好。（2）序列化後的字節長度，越小越好。（3） 序列化和反序列化的兼容性，接口參數對象若增長了字段，是否兼容。

9. 傳輸服務：

　　協議編碼以後，天然就是須要將編碼後的 RPC 請求消息傳輸到服務方，服務方執行後返回結果消息或確認消息給客戶方。RPC 的應用場景實質是一種可靠的請求應答消息流，和 HTTP 相似。所以選擇長鏈接方式的 TCP 協議會更高效，與 HTTP 不一樣的是在協議層面咱們定義了每一個消息的惟一 id，所以能夠更容易的複用鏈接。  既然使用長鏈接，那麼第一個問題是到底 client 和 server 之間須要多少根鏈接？實際上單鏈接和多鏈接在使用上沒有區別，對於數據傳輸量較小的應用類型，單鏈接基本足夠。單鏈接和多鏈接最大的區別在於，每根鏈接都有本身私有的發送和接收緩衝區，所以大數據量傳輸時分散在不一樣的鏈接緩衝區會獲得更好的吞吐效率。因此，若是你的數據傳輸量不足以讓單鏈接的緩衝區一直處於飽和狀態的話，那麼使用多鏈接並不會產生任何明顯的提高，反而會增長鏈接管理的開銷。  鏈接是由 client 端發起創建並維持。若是 client 和 server 之間是直連的，那麼鏈接通常不會中斷（固然物理鏈路故障除外）。若是 client 和 server 鏈接通過一些負載中轉設備，有可能鏈接一段時間不活躍時會被這些中間設備中斷。爲了保持鏈接有必要定時爲每一個鏈接發送心跳數據以維持鏈接不中斷。心跳消息是 RPC 框架庫使用的內部消息，在前文協議頭結構中也有一個專門的心跳位，就是用來標記心跳消息的，它對業務應用透明。  

10.執行調用：

　　client stub 所作的事情僅僅是編碼消息並傳輸給服務方，而真正調用過程發生在服務方。server stub 從前文的結構拆解中咱們細分了 RpcProcessor 和 RpcInvoker 兩個組件，一個負責控制調用過程，一個負責真正調用。這裏咱們仍是以 java 中實現這兩個組件爲例來分析下它們到底須要作什麼？  java 中實現代碼的動態接口調用目前通常經過反射調用。除了原生的 jdk 自帶的反射，一些第三方庫也提供了性能更優的反射調用，所以 RpcInvoker 就是封裝了反射調用的實現細節。

11.RPC 異常處理  

　　不管 RPC 怎樣努力把遠程調用假裝的像本地調用，但它們依然有很大的不一樣點，並且有一些異常狀況是在本地調用時絕對不會碰到的。在說異常處理以前，咱們先比較下本地調用和 RPC 調用的一些差別：（1）本地調用必定會執行，而遠程調用則不必定，調用消息可能由於網絡緣由並未發送到服務方。（2） 本地調用只會拋出接口聲明的異常，而遠程調用還會跑出 RPC 框架運行時的其餘異常。（3） 本地調用和遠程調用的性能可能差距很大，這取決於 RPC 固有消耗所佔的比重。  正是這些區別決定了使用 RPC 時須要更多考量。當調用遠程接口拋出異常時，異常多是一個業務異常，也多是 RPC 框架拋出的運行時異常（如：網絡中斷等）。業務異常代表服務方已經執行了調用，可能由於某些緣由致使未能正常執行，而 RPC 運行時異常則有可能服務方根本沒有執行，對調用方而言的異常處理策略天然須要區分。因爲 RPC 固有的消耗相對本地調用高出幾個數量級，本地調用的固有消耗是納秒級，而 RPC 的固有消耗是在毫秒級。那麼對於過於輕量的計算任務就並不合適導出遠程接口由獨立的進程提供服務，只有花在計算任務上時間遠遠高於 RPC 的固有消耗才值得導出爲遠程接口提供服務。