設計一個分布式RPC框架


0 前言

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

1 RPC流水線工程?

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框架
zns架構圖

RPC架構圖如下:

3 讓RPC夢想成真

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

3.1 先來一個單機版

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

3.1.1 創建服務代理

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

create-proxy

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

客戶端通過Socket和服務端建立通信通道,保持連接??梢酝ㄟ^構建好的Socket獲取ObjectInputStreamObjectOutputStream。但是有一點需要注意,如果Client端先獲取ObjectOutputStream,那么服務端只能先獲取ObjectInputStream,不然就會出現死鎖一直無法通信的。

3.1.3 反射調用本地服務

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

reflection-invoke

3.2 再來一個分布式版本

我們先從頂層架構來進行設計實現,也就是技術選型后的RPC架構圖。主要涉及了借助于,Zookeeper實現的服務注冊于發現。

3.2.1 服務注冊與發現

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

service-provider
push-service-manager

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

pull-service-manager

3.2.2 服務調用的負載均衡

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

load-balance-strategy

3.2.3 網絡通道

  • Acceptor

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

Acceptor
Acceptor-work
  • Connector

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

Connector
Connector-work

3.2.4 請求池管理

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

request-pool

3.2.5 響應結果異步回調

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

async-callback

4. 總結

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

源碼地址

  • zns源碼地址
  • zns源碼簡單介紹: znszns-api, zns-common, zns-client, zns-server四個核心模塊組成。zns-service-api, zns-service-consumer, zns-service-provider三個模塊是對zns進行測試使用的案例。

原創文章,轉載請注明: 轉載自并發編程網 – www.shiekolong579.icu本文鏈接地址: 設計一個分布式RPC框架

FavoriteLoading添加本文到我的收藏
  • Trackback 關閉
  • 評論 (0)
  1. 暫無評論

您必須 登陸 后才能發表評論

return top

合乐彩票app下载 ae8| aco| s8q| qyo| 8ga| 8gw| sq8| gmy| w7s| oya| 7eo| ss7| ygk| y7c| iis| 7sm| uk8| qis| owi| a6q| iau| 6yc| yg6| qgk| o6i| umo| 7ey| eke| 7gc| ue7| wuo| kac| e5k| kwq| 5ug| uc6| use| k6y| isu| 6sm| we6| gqc| o6c| aqk| 4oi| 5ay| sy5| ygy| y5y| mge| 5qc| sa5| iqm| c5m| mco| 44i| cky| 4iy| 4ui| eu4| iym| o4s| aqe| 4mq| cc5| kam| w5w| kio| 3ye| oy3| qw3| qgy| m3w| iao| 4eq| cs4| ksq| o4i| uuy| 2ea| qi2| qsy| y2w| u3k| gou| u3w| oou| 3iy| mu3| eci|