我從事的是大數據開發相關的工作，主要負責的是大數據計算這塊的內容。最近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，當然也歡迎把代碼Fork一份研究學習。雖然就目前來看，想要做成一個真正穩定可投產使用的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進行測試使用的案例。
轉載自併發編程網 – ifeve.com本文鏈接地址: 設計一個分佈式RPC框架
