0 前言

提前先祝大家春節快樂！好了，先簡單聊聊。

我從事的是大數據開發相關的工作，主要負責的是大數據計算這塊的內容。最近Hive集群跑任務總是會出現Thrift連接HS2相關問題，研究瞭解了下內部原理，突然來了興趣，就想著自己也實現一個RPC框架，這樣可以讓自己在設計與實現RPC框架過程中，也能從中瞭解和解決一些問題，進而讓自己能夠更好的發展（哈哈，會不會說我有些劍走偏鋒？不去解決問題，居然研究RPC。別急，這類問題已經解決了，後續我也會發文章詳述的）。

1 RPC流水線工程？

原理圖上我已經標出來流程式號，我們來走一遍：

• ① Client以本地調用的方式調用服務
• ② Client Stub接收到調用後，把服務調用相關信息組裝成需要網路傳輸的消息體，並找到服務地址（host:port），對消息進行編碼後交給Connector進行發送
• ③ Connector通過網路通道發送消息給Acceptor
• ④ Acceptor接收到消息後交給Server Stub
• ⑤ Server Stub對消息進行解碼，並根據解碼的結果通過反射調用本地服務
• ⑥ Server執行本地服務並返回結果給Server Stub
• ⑦ Server Stub對返回結果組裝打包並編碼後交給Acceptor進行發送
• ⑧ Acceptor通過網路通道發送消息給Connector
• ⑨ Connector接收到消息後交給Client Stub，Client Stub接收到消息併進行解碼後轉交給Client
• ⑩ Client獲取到服務調用的最終結果

由此可見，主要需要RPC負責的是2~9這些步驟，也就是說，RPC主要職責就是把這些步驟封裝起來，對用戶透明，讓用戶像調用本地服務一樣去使用。

2 為RPC做個技術選型

• 序列化/反序列化

  首先排除Java的ObjectInputStream和ObjectOutputStream，因為不僅需要保證需要序列化或反序列化的類實現Serializable介面，還要保證JDK版本一致，公司應用So Many，使用的語言也眾多，這顯然是不可行的，考慮再三，決定採用Objesess。

• 通信技術

  同樣我們首先排除Java的原生IO，因為進行消息讀取的時候需要進行大量控制，如此晦澀難用，正好近段時間也一直在接觸Netty相關技術，就不再糾結，直接命中Netty。

• 高併發技術

  遠程調用技術一定會是多線程的，只有這樣才能滿足多個併發的處理請求。這個可以採用JDK提供的Executor。

• 服務註冊與發現

  Zookeeper。當Server啟動後，自動註冊服務信息（包括host,port,還有nettyPort）到ZK中；當Client啟動後，自動訂閱獲取需要遠程調用的服務信息列表到本地緩存中。

• 負載均衡

  分散式系統都離不開負載均衡演算法，好的負載均衡演算法可以充分利用好不同伺服器的計算資源，提高系統的併發量和運算能力。

• 非侵入式

  藉助於Spring框架

RPC架構圖如下：

3 讓RPC夢想成真

由架構圖，我們知道RPC是C/S結構的。

3.1 先來一個單機版

單機版的話比較簡單，不需要考慮負載均衡（也就沒有zookeeper)，會簡單很多，但是只能用於本地測試使用。而RPC整體的思想是：為客戶端創建服務代理類，然後構建客戶端和服務端的通信通道以便於傳輸數據，服務端的話，就需要在接收到數據後，通過反射機制調用本地服務獲取結果，繼續通過通信通道返回給客戶端，直到客戶端獲取到數據，這就是一次完整的RPC調用。

3.1.1 創建服務代理

可以採用JDK原生的Proxy.newProxyInstance和InvocationHandler創建一個代理類。詳細細節網上博客眾多，就不展開介紹了。當然，也可以採用CGLIB位元組碼技術實現。

3.1.2 構建通信通道 & 消息的發送與接收

客戶端通過Socket和服務端建立通信通道，保持連接。可以通過構建好的Socket獲取ObjectInputStream和ObjectOutputStream。但是有一點需要註意，如果Client端先獲取ObjectOutputStream，那麼服務端只能先獲取ObjectInputStream，不然就會出現死鎖一直無法通信的。

3.1.3 反射調用本地服務

服務端根據請求各項信息，獲取Method，在Service實例上反向調用該方法。

3.2 再來一個分散式版本

我們先從頂層架構來進行設計實現，也就是技術選型後的RPC架構圖。主要涉及了藉助於，Zookeeper實現的服務註冊於發現。

3.2.1 服務註冊與發現

當Server端啟動後，自動將當前Server所提供的所有帶有@ZnsService註解的Service Impl註冊到Zookeeper中，在Zookeeper中存儲數據結構為 ip:httpPort:acceptorPort

當Client端啟動後，根據掃描到的帶有@ZnsClient註解的Service Interface從Zookeeper中拉去Service提供者信息並緩存到本地，同時在Zookeeper上添加這些服務的監聽事件，一旦有節點發生變動（上線/下線），就會立即更新本地緩存。

3.2.2 服務調用的負載均衡

Client拉取到服務信息列表後，每個Service服務都對應一個地址list，所以針對連哪個server去調用服務，就需要設計一個負載均衡路由演算法。當然，負載均衡演算法的好壞，會關係到伺服器計算資源、併發量和運算能力。不過，目前開發的RPC框架zns中只內置了Random演算法，後續會繼續補充完善。

3.2.3 網路通道

• Acceptor

當Server端啟動後，將同時啟動一個Acceptor長連接線程，用於接收外部服務調用請求。內部包含了編解碼以及反射調用本地服務機制。

• Connector

當Client端發起一個遠程服務調用時，ZnsRequestManager將會啟動一個Connector與Acceptor進行連接，同時會保存通道信息ChannelHolder到內部，直到請求完成，再進行通道信息銷毀。

3.2.4 請求池管理

為了保證一定的請求併發，所以對服務調用請求進行了池化管理，這樣可以等到消息返回再進行處理，不需要阻塞等待。

3.2.5 響應結果非同步回調

當Client端接收到遠程服務調用返回的結果時，直接通知請求池進行處理，No care anything!

4. 總結

本次純屬是在解決Thrift連接HS2問題時，突然來了興趣，就構思了幾天RPC大概架構設計情況，便開始每天晚上瘋狂敲代碼實現。我把這個RPC框架命名為zns，現在已經完成了1.0-SNAPSHOT版本，可以正常使用了。在開發過程中，也遇到了一些平時忽略的小問題，還有些是工作工程中沒有遇到或者遺漏的地方。因為是初期，所以會存在一些bug，如果你感興趣的話，歡迎提PR和ISSUE，當然也歡迎把代碼clone到本地研究學習。雖然就目前來看，想要做成一個真正穩定可投產使用的RPC框架還有短距離，但是我會堅持繼續下去，畢竟RPC真的涉及到了很多點，只有真正開始做了，才能切身體會和感受到。Ya hoh!終於成功實現了v1.0，嘿嘿……

源碼地址

• zns源碼地址

• zns源碼簡單介紹：

  zns由zns-api, zns-common, zns-client, zns-server四個核心模塊組成。zns-service-api, zns-service-consumer, zns-service-provider三個模塊是對zns進行測試使用的案例。