設計一個分佈式RPC框架

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進行測試使用的案例。