思考一個問題：為什么需要 RPC 服務？

在傳統(tǒng)的開發(fā)模式中，我們通常將系統(tǒng)的各個服務部署在單臺機器，隨著服務的擴展，這種方式已經(jīng)完全無法滿足系統(tǒng)大規(guī)模的擴展需要，分布式系統(tǒng)由此誕生，在分布式系統(tǒng)中，最重要就是各個服務之間的 RPC 調(diào)用。

RPC 全稱 Remote Procedure Call——遠程過程調(diào)用，它是一種通過網(wǎng)絡從遠程計算機程序上請求服務，而不需要了解底層網(wǎng)絡技術的方式。簡單一點就是：通過一定協(xié)議和方法使得調(diào)用遠程計算機上的服務，就像調(diào)用本地服務一樣。

通常來說，RPC 的實現(xiàn)方式有很多，可以基于常見的 HTTP 協(xié)議，也可以在TCP上層封裝自定義協(xié)議，常見的 Web Service 就是基于 HTTP 協(xié)議的 RPC，HTTP 協(xié)議的優(yōu)點是具有良好的跨平臺性，特別適合異構系統(tǒng)較多的公司，但是由于 HTTP 報頭較為冗長，性能較差，基于 TCP 協(xié)議的 RPC 可以建立長連接，速度和效率明顯，但是難度和復雜程度很高。

RPC 的誕生讓構建分布式應用更容易，極大的擴大系統(tǒng)的可擴展性，容錯性。為復雜業(yè)務邏輯的系統(tǒng)進行服務化改造和高可用性升級提供了可能。

RPC 調(diào)用分類

RPC 調(diào)用的分類方式有很多種。

從通信協(xié)議層面可以分為：

基于 HTTP 協(xié)議的 RPC；

基于二進制協(xié)議的 RPC；

基于 TCP 協(xié)議的 RPC。

從是否跨平臺可分為：

單語言 RPC，如 RMI, Remoting；

跨平臺 RPC，如 google protobuffer, restful json，http XML。

從調(diào)用過程來看，可以分為同步通信RPC和異步通信RPC：

同步 RPC：指的是客戶端發(fā)起調(diào)用后，必須等待調(diào)用執(zhí)行完成并返回結果；

異步 RPC：指客戶方調(diào)用后不關心執(zhí)行結果返回，如果客戶端需要結果，可用通過提供異步 callback 回調(diào)獲取返回信息。大部分 RPC 框架都同時支持這兩種方式的調(diào)用。

RPC 框架結構

一個完整的 RPC 框架的架構主要模塊如圖所示。

RPC 服務方的主要職責是提供服務，供客戶端調(diào)用訪問，服務端會通過一個接收器接受客戶端的調(diào)用請求，根據(jù)相應的 RPC 協(xié)議進行解碼獲取調(diào)用方法以及相關參數(shù)，當調(diào)用完成后，服務器端通過后臺處理模塊處理完成并將結果返回給客戶端。

對于客戶端來說，服務調(diào)用完全透明，像調(diào)用本地服務一樣調(diào)用遠程方法，客戶端調(diào)用服務時候通過一個遠程連接和服務端建立通道，并通過相應的協(xié)議進行編碼，將調(diào)用的方法和相關參數(shù)發(fā)送給服務方。

上 手 篇

RPC 模塊詳解

下面我們根據(jù)上面的RPC的架構圖，對圖中的各個模塊進行拆解，并解釋每個模塊的作用。

服務端（Server)：RPC 服務的提供者，負責將 RPC 服務導出；

客戶端 （Client）：RPC 服務的消費者，負責調(diào)用 RPC 服務；

代理（Proxy）：通過動態(tài)代理，提供對遠程接口的代理實現(xiàn)；

執(zhí)行器（Invoker）：對于客戶端：主要負責服務調(diào)用的編碼，調(diào)用請求發(fā)送和等待結果返回；對于服務方：負責處理調(diào)用邏輯并返回調(diào)用結果；

協(xié)議管理（Protocol）：協(xié)議管理組件，負責整個 RPC 通信協(xié)議的編/解碼；

連接端口（Connector）：負責維持客戶方和服務方的長連接通道；

后臺處理（Processor）：負責整個調(diào)用服務中的管理調(diào)度，包括線程池，分發(fā)，異常處理等；

連接通道（Channel）：客戶端和服務器端的數(shù)據(jù)傳輸通道。

具體到 JAVA 平臺來說，其中的3,4通常使用動態(tài)代理實現(xiàn)，5,6,7,8使用 NIO 或者一些高性能 NIO 框架，如 mina,netty 實現(xiàn)。

最簡單的 RPC JAVA 實現(xiàn)

在進一步拆解了組件并劃分了職責之后，這里以一個最簡單 Java RPC 框架實現(xiàn)為例，對 RPC 具體邏輯進行分析。

RPC 框架服務發(fā)布代碼：

服務端發(fā)布服務的代碼如上，首先校驗傳入的端口和服務是否合法，然后開啟一個 socket 監(jiān)聽，這兒為了簡便，沒有采用 NIO 方式，同時直接采用 java 的序列化方式，將傳入的數(shù)據(jù)通過反射取出調(diào)用的方法和參數(shù)，本地執(zhí)行后將運行結果通過 socket 套接字返回給客戶端。

RPC 框架服務調(diào)用代碼：

框架中客戶端調(diào)用的代碼中，首先校驗對應的端口和主機是否合法，然后通過動態(tài)代理生成一個代理對象，在代理對象的方法中，攔截調(diào)用，通過建立 socket 連接，將方法和參數(shù)傳遞到遠端執(zhí)行并獲取遠程執(zhí)行返回結果。

RPC 調(diào)用測試：

如上圖所示，服務器端發(fā)布一個接口服務 HelloService，客戶端成功通過 RPC 調(diào)用。

思 考 篇

自定義 RPC 協(xié)議

協(xié)議頭

在上面的示例程序當中，我們僅僅是完成了一個基本的遠程調(diào)用，并沒有實現(xiàn) RPC 框架中的很多組件功能，從最簡單的代碼版本中我們可以發(fā)現(xiàn)，發(fā)起一個 RPC 調(diào)用，需要傳輸?shù)淖罨緮?shù)據(jù)如下：

接口方法：包括接口的名字和相應的方法名字；

方法參數(shù)：包括參數(shù)的類型和取值；

附件參數(shù)，包括調(diào)用接口版本，接口超時時間等等。

因此，如果要自定義協(xié)議實現(xiàn) RPC，我們必須再協(xié)議的消息體中包含這部分數(shù)據(jù)，另外，我們需要定義一些協(xié)議元數(shù)據(jù)，這些元數(shù)據(jù)通常放在協(xié)議頭中，和包含必要參數(shù)的協(xié)議體一期組成了自定義消息。

元數(shù)據(jù)通常會包含以下字段，大部分字段只需要1-2位：

magic: 魔數(shù)，方便協(xié)議解碼

header_size: 協(xié)議頭大小，便于解碼，同時可用用于處理TCP粘包問題

id :消息 id，用來標示這次調(diào)用

version: 接口版本

type:消息類型，可用包括普通調(diào)用消息，心跳，控制消息

status:消息狀態(tài),是否首次處理或者已經(jīng)處理

body_size: 消息體長度

serialize_type:消息體序列化類型

body：具體消息

具體消息

消息內(nèi)容在網(wǎng)絡上傳輸需要對其進行編碼，這個編碼的過程就是序列化過程，顯然，對于網(wǎng)絡傳輸?shù)臄?shù)據(jù)，在能夠保證信息足夠解碼的情況下，序列化的大小越小，傳輸?shù)拈_銷就越小，效率就越高，目前 JAVA 平臺常用的序列化方式有：xml，json ，binary(包括 thrift; hession; kryo 等)。

在 RPC 調(diào)用中我們推薦使用二進制方式進行序列化，在大部分的測試中，二進制方式序列化具有相當好的表現(xiàn)，另外一個比較有意思的地方是，每一次 JDK 版本的升級，JAVA 自帶的序列化方式的效率都有提升。

服務端調(diào)用優(yōu)化

從前面的示例代碼中，我們僅僅簡單的考慮了實現(xiàn)了組件中的服務端和客戶端，并沒有考慮效率問題，在一個完整的 RPC 框架中，我們需要考慮實現(xiàn)并優(yōu)化調(diào)用的每一個地方，同時，為了符合業(yè)務需求，需要有很高的可靠性和容錯機制。

具體來說，在動態(tài)代理模塊，我們不會采用 java 自帶的動態(tài)接口，而是會采用一些性能更高的三方庫，在連接通道和連接模塊，我們會采用更優(yōu)秀的三方NIO，如 netty 來實現(xiàn)，在后端處理模塊，我們也不會僅僅是執(zhí)行結果并返回，要考慮更多的東西：

并發(fā)控制：當多個請求并發(fā)處理的時候，如何管理和控制線程池和超時等待時間；

版本隔離：當服務有多個版本的時候，如何讓不同的調(diào)用者能夠調(diào)用正確的服務；

服務路由：當服務提供者有多臺機器的時候，如何提高系統(tǒng)負載均衡，路由到正確的服務端；

服務降級：當多個服務重要性有不同的時候，如果保證核心業(yè)務的穩(wěn)定性，適當?shù)慕档头呛诵臉I(yè)務優(yōu)先級；

服務監(jiān)控和報警：服務出現(xiàn)異常情況時候，運維和對應的系統(tǒng)負責人能夠第一時間得到告警和錯誤信息。

以上的思考大部分要結合運維層面一起考慮，但是 RPC 框架本身也要提供足夠的支持才能保證它足夠的健壯性。

需要注意的一些地方

雖然 RPC 有足夠多的優(yōu)點讓你去使用，但是當真正轉(zhuǎn)向服務化的時候，依然有很多需要考慮的地方：

網(wǎng)絡問題：本地調(diào)用無需考慮是否能夠執(zhí)行問題，網(wǎng)絡調(diào)用可能會因為各種外部網(wǎng)絡環(huán)境，端口攔截，IP 受限等可能情況導致無法成功執(zhí)行。所以 RPC 的服務端通常要考慮冪等性和容錯性，接口需要較強的魯棒性設計。

異常處理：RPC 和本地服務最大的不同就是 RPC 服務存在分布式一致性問題，當服務沒有調(diào)用成功情況下，本地和遠程的服務可能處于一個不一致的狀態(tài)，如何進行異常處理和事物的回滾機制也是一個需要考慮的問題，是需要保障強一致性和最終一致性通常取決于具體的業(yè)務需求。

由于網(wǎng)絡原因，RPC 服務通常會被本地服務處理慢一個數(shù)量級，在比較輕量級的業(yè)務和并發(fā)量很小的情況下，并不需要 RPC 服務，引入 RPC 服務后，無論是系統(tǒng)的調(diào)試，還是線上問題分析都會變得非常復雜，是否引入也需要權衡相關利弊。

文末小結

本文簡單的介紹了 RPC 的基本知識和相關分析以供拋磚引玉，進一步的學習可以參考當前最主流的一些 RPC 框架，如dubbo, protobuff ,thrift 通過對其源碼的深入學習，相信能獲益匪淺。