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