高併發架構系列：如何從0到1設計一個類Dubbo的RPC框架

在過去持續分享的幾十期阿里Java面試題中，幾乎每次都會問到Dubbo相關問題，好比：「如何從0到1設計一個Dubbo的RPC框架」，這個問題主要考察如下幾個方面：

你對RPC框架的底層原理掌握程度。

以及考驗你的總體RPC框架系統設計能力。

 

具體，mike來爲你們詳解。

 

RPC和RPC框架

 

1.RPC(Remote Procedure Call)

即遠程過程調用, 主要解決遠程通訊間的問題，不須要了解底層網絡的通訊機制。

 

2.RPC框架

RPC框架負責屏蔽底層的傳輸方式（TCP或者UDP）、序列化方式、以及通訊細節。

實際使用中，並不須要關心底層通訊細節和調用過程，讓業務端專一於業務代碼的實現。

國內你們熟知的PRC框架，阿里的HSF和Dubbo(開源)。

 

Dubbo的發展由來

 

1. 業務規模小

好比早期一個應用Java War包，將全部功能都打包，部署在一個單機服務器，調用接口也比較方便，不涉及到任何分佈式場景。

2.業務規模變大

隨着業務的快速發展，業務愈來愈多、子系統也愈來愈多時。好比：淘寶的交易系統、商品系統、用戶系統、評價系統...上百個系統的出現。

系統變得愈來愈複雜，業務代碼依然耦合在一塊兒。好比最先期的淘寶denali工程，包含全部業務系統的代碼，就僅打包部署都須要很長的時間。

而且，隨着每一個業務線的快速發展，業務代碼耦合在一塊兒，上線後出現問題急須要回滾代碼，拉分支、大量的代碼merge工做，這個過程極其痛苦。

這個時候，你會發現技術已經成了業務的瓶頸，急需把業務單獨抽離出來，各自單獨部署。

 

3.Dubbo和HSF的出現

應用系統一旦涉及到拆分部署，問題就來了，急需一種高效的應用程序間的通信手段來完成這種需求，這就會涉及到分佈式遠程調用。

因而，淘寶就把denali按照業務爲單位拆分紅了相似這樣的系統：UM(UserManger)、SM(ShopManager)..等等幾十個工程代碼。

再按照業務爲單位，把全部調用相關的接口以業務爲單元進行拆分：UIC(用戶中心服務)、SIC(店鋪中心服務)...等等以業務爲單位集羣部署，按照業務提供服務。

因此，RPC的框架來了，阿里內部使用HSF，以及開源的RPC 框架：Dubbo。

 

RPC框架的核心設計

 

前面提到了RPC的核心目標：主要是解決分佈式系統中服務之間的調用問題。

其實，走到這一步涉及的知識體系很是的多：要求對通訊、遠程調用、消息機制等有深刻的理解和掌握，要求的都是從理論、硬件級、操做系統級以及所採用的語言的實現都有清楚的理解。

1.RPC框架三個核心角色

1)服務提供者（Server）

對外提供後臺服務，將本身的服務信息，註冊到註冊中心。

 

2)註冊中心（Registry）

用於服務端註冊遠程服務以及客戶端發現服務。

目前主要的註冊中心能夠藉由 zookeeper，eureka，consul，etcd 等開源框架實現。

好比：阿里的Dubbo就是採用zookeeper實現註冊中心。

 

3)服務消費者（Client）

從註冊中心獲取遠程服務的註冊信息，而後進行遠程過程調用。

 

2.RPC遠程調用過程

1）服務調用方（client）調用以本地調用方式調用服務；

2）client stub接收到調用後負責將方法、參數等組裝成可以進行網絡傳輸的消息體；在Java裏就是序列化的過程

3）client stub找到服務地址，並將消息經過網絡發送到服務端；

4）server stub收到消息後進行解碼,在Java裏就是反序列化的過程；

5）server stub根據解碼結果調用本地的服務；

6）本地服務執行處理邏輯；

7）本地服務將結果返回給server stub；

8）server stub將返回結果打包成消息，Java裏的序列化；

9）server stub將打包後的消息經過網絡併發送至消費方

10）client stub接收到消息，並進行解碼, Java裏的反序列化；

11）服務調用方（client）獲得最終結果。

 

RPC框架的目標就是要2~10這些步驟都封裝起來。

 

RPC框架涉及技術

 

1.創建通訊

首先，要解決通信的問題，主要是經過在客戶端和服務器之間創建TCP鏈接，遠程過程調用的全部交換的數據都在這個鏈接裏傳輸。

 

2.服務尋址

1）服務註冊

首先須要把服務註冊到服務中心。其實就是在註冊中心進行一個登記，註冊中心存儲了該服務的IP、端口、調用方式(協議、序列化方式)等。在zookeeper中，進行服務註冊，實際上就是在zookeeper中建立了一個znode節點，該節點存儲了上面所說的服務信息。

 

2）服務發現

服務消費者在第一次調用服務時，會經過註冊中心找到相應的服務的IP地址列表，並緩存到本地，以供後續使用。當消費者調用服務時，不會再去請求註冊中心，而是直接經過負載均衡算法從IP列表中取一個服務提供者的服務器調用服務。

 

3）註冊服務

可靠的尋址方式（主要是提供服務的發現）是RPC的實現基石，好比能夠zookeeper來實現註冊服務等等。

服務提供者啓動後主動向服務（註冊）中心註冊機器ip、端口以及提供的服務列表。

服務消費者啓動時向服務（註冊）中心獲取服務提供方地址列表，可實現軟負載均衡和Failover。

提供者須要定時向註冊中心發送心跳，一段時間未收到來自提供者的心跳後，認爲提供者已經中止服務，從註冊中心上摘取掉對應的服務等等。

 

3.網絡傳輸

數據傳輸採用什麼協議，數據該如何序列化和反序列化。

 

4.NIO通訊

當前不少RPC框架都直接基於netty這一IO通訊框架，好比阿里巴巴的HSF、dubbo，Hadoop Avro，推薦使用Netty 做爲底層通訊框架。

 

5.服務調用

好比：B機器進行本地調用（經過代理Proxy）以後獲得了返回值，此時還須要再把返回值發送回A機器，一樣也須要通過序列化操做，而後再通過網絡傳輸將二進制數據發送回A機器，而當A機器接收到這些返回值以後，則再次進行反序列化操做

總之，要實現一個RPC不算難，難的是實現一個高性能高可靠的RPC框架，後續將結合Dubbo的實現一塊兒再探討。

以上就是RPC的介紹，更多Redis、Spring Cloud、MySQL數據庫分庫分表等高併發架構設計，具體請參考高併發架構系列專題：

以爲有用請點贊支持

以爲不錯請點贊支持，歡迎留言或進個人我的羣855801563領取【架構資料專題目合集90期】、【BATJTMD大廠JAVA面試真題1000+】，本羣專用於學習交流技術、分享面試機會，拒絕廣告，我也會在羣內不按期答題、探討。