這篇文章我們來聊一聊RPC框架，為什么要聊RPC呢 ？

首先從個(gè)人成長角度，如果一個(gè)新時(shí)代碼農(nóng)能清楚的了解RPC框架所具備的要素，掌握RPC框架中涉及的服務(wù)注冊發(fā)現(xiàn)、負(fù)載均衡、序列化協(xié)議、RPC通信協(xié)議、Socket通信、異步調(diào)用、熔斷降級(jí)等技術(shù)，可以全方位的提升基本素質(zhì)。

其次，目前市面上也有非常多優(yōu)秀的框架，GitHub上也有相關(guān)源碼，但好記性不如爛筆頭，只有自己真正了解并且動(dòng)手去嘗試寫一個(gè)RPC框架，才是我們?nèi)フ莆者@門技術(shù)的最優(yōu)路徑。

一、介紹

研究一個(gè)概念或者框架，帶著三個(gè)W去考慮，可能會(huì)對(duì)他有更加深刻的了解：

1）What，什么是RPC框架，RPC是 Remote Procedure Call 的簡稱，遠(yuǎn)程過程調(diào)用，那么什么叫遠(yuǎn)程過程調(diào)用呢，你可以理解為我們調(diào)用外部（遠(yuǎn)程）服務(wù)就像調(diào)用自己本地方法一樣。

2）Where，RPC框架用在什么地方，在分布式系統(tǒng)和微服務(wù)盛行的今天，各業(yè)務(wù)系統(tǒng)會(huì)被獨(dú)立拆分出來成為一個(gè)個(gè)獨(dú)立的web應(yīng)用，應(yīng)用之間的交互和數(shù)據(jù)傳輸就成了必不可少的一環(huán)，RPC就是為了實(shí)現(xiàn)獨(dú)立服務(wù)之間遠(yuǎn)程交互的框架。

3）Why，為什么需要一個(gè)RPC框架，服務(wù)之間的調(diào)用需要各種場景和因素的考慮，內(nèi)部原理非常復(fù)雜和繁瑣，同時(shí)在集群情況下，服務(wù)的負(fù)載均衡，熔斷，限流等都是需要去考慮的，這時(shí)候就需要一個(gè)集服務(wù)注冊發(fā)現(xiàn)、負(fù)載均衡、序列化協(xié)議、RPC通信協(xié)議、Socket通信、異步調(diào)用、熔斷降級(jí)等技術(shù)為一體的技術(shù)去完成這些公共功能，RPC框架就是在這種情況下應(yīng)運(yùn)而生。

目前比較主流的RPC框架包括谷歌開源的GRPC、阿里巴巴的Dubbo、Netflix 的SpringCloud等。

二、RPC框架基本組成

RPC框架需要的最基本的三個(gè)要素：

ServiceProvider: 服務(wù)提供方，提供相關(guān)服務(wù)接口。

ServiceConsumer: 服務(wù)消費(fèi)方，消費(fèi)服務(wù)提供方的接口。

Registry: 注冊中心，用于進(jìn)行服務(wù)的注冊、發(fā)現(xiàn)、治理、高可用。

基于三個(gè)最基本要素，還會(huì)延伸出包括負(fù)載均衡器、熔斷降級(jí)器、通信協(xié)議組件、序列化協(xié)議等等組件。

一個(gè)最簡單的RPC調(diào)用模型圖如下所示：

下面做一些名詞的介紹和解釋：

2.1 注冊中心

注冊中心是RPC框架中的管理者和協(xié)調(diào)者角色，雖然在遠(yuǎn)程過程調(diào)用中服務(wù)消費(fèi)者會(huì)不經(jīng)過注冊中心，會(huì)直接向服務(wù)提供者發(fā)送請(qǐng)求，但是隨著我們的服務(wù)方越來越多，每個(gè)服務(wù)的實(shí)例也不斷變化的，且每個(gè)服務(wù)的地址，端口等信息是需要通知到消費(fèi)方的，所以我們需要一個(gè)類似“管家”的角色，來負(fù)責(zé)管理服務(wù)注冊和發(fā)現(xiàn)的工作，這個(gè)“管家”我們稱之為注冊中心。

一個(gè)合格的注冊中心需要具備包括緩存和持久化服務(wù)提供方數(shù)據(jù)，動(dòng)態(tài)更新服務(wù)提供者信息，動(dòng)態(tài)監(jiān)聽服務(wù)提供方節(jié)點(diǎn)變化，推送節(jié)點(diǎn)變化到消費(fèi)方，查詢服務(wù)提供方數(shù)據(jù)等功能。

目前市面上比較流行的注冊中心有：Zookper、 Nacos、Consul、Eurake等，針對(duì)于上面功能的實(shí)現(xiàn)方式也有所不同，以下是注冊中心的對(duì)比：

2.2 服務(wù)提供方（RPC服務(wù)端）

其需要對(duì)外提供服務(wù)接口，一個(gè)服務(wù)方需要包括啟動(dòng)連接注冊中心，注冊相關(guān)信息到注冊中心，提供服務(wù)下線和更新機(jī)制，維護(hù)服務(wù)名和服務(wù)的映射，序列化和反序列化，啟動(dòng)通信等。

目前服務(wù)提供方有兩種服務(wù)提供維度，基于接口的服務(wù)提供和基于服務(wù)的服務(wù)提供，Dubbo3.0 之前是基于接口維度做的服務(wù)注冊，Dubbo3.0之后漸漸向服務(wù)維度的服務(wù)注冊發(fā)現(xiàn)靠攏，SpringCloud是基于服務(wù)來進(jìn)行注冊發(fā)現(xiàn)的，在云原生和容器化越來越火的今天，基于服務(wù)可以更好的適配容器化和云原生。

2.3 服務(wù)消費(fèi)方（RPC消費(fèi)端）

服務(wù)消費(fèi)方需要具備可以從注冊中心拉取服務(wù)列表，緩存服務(wù)列表，動(dòng)態(tài)監(jiān)聽和更新服務(wù)列表的功能，還需要具備針對(duì)于服務(wù)的負(fù)載均衡策略，序列化和反序列化，根據(jù)約定的通信協(xié)議進(jìn)行調(diào)用等。

目前Dubbo是基于代理和Spring的BeanDefination來實(shí)現(xiàn)的，在消費(fèi)啟動(dòng)的時(shí)候會(huì)去掃描基于自定義注解或配置的信息，然后生成一個(gè)相應(yīng)的代理對(duì)象，注冊到Spring容器中，在調(diào)用的時(shí)候直接通過代理類進(jìn)行相關(guān)一系列調(diào)用。SpringCloud是基于HTTP協(xié)議和增強(qiáng)版的RestTemplate來實(shí)現(xiàn)的，內(nèi)部實(shí)現(xiàn)了Ribbon的負(fù)載均衡，消費(fèi)方可以通過Feign或者RestTemplate實(shí)現(xiàn)遠(yuǎn)程調(diào)用。

2.4 通訊框架

通訊框架是服務(wù)之間進(jìn)行IO交互和傳輸?shù)谋ＷC，消費(fèi)端需要通過通訊框架和提供方進(jìn)行交互，獲取數(shù)據(jù)，目前市面上主流的基于Java的NIO通訊框架就是Netty。

2.5 通訊協(xié)議

通訊協(xié)議是消費(fèi)端和服務(wù)端約定好一種交互協(xié)議，當(dāng)消費(fèi)端拿到服務(wù)端提供的IO流之后，需要根據(jù)通訊協(xié)議獲取具體的數(shù)據(jù)內(nèi)容，目前TCP通訊協(xié)議比較通用的是HTTP、FTP、SMTP協(xié)議等，SpringCloud是基于HTTP的通訊協(xié)議實(shí)現(xiàn)的，Dubbo內(nèi)部自己集成了一套通訊協(xié)議。

業(yè)界的主流協(xié)議的解決方案可以歸納如下：

消息定長，例如每個(gè)報(bào)文的大小為固定長度100字節(jié)，如果不夠用空格補(bǔ)足。

在包尾特殊結(jié)束符進(jìn)行分割。

將消息分為消息頭和消息體，消息頭中包含表示消息總長度（或者消息體長度）的字段。

通過對(duì)比，我們發(fā)現(xiàn)第三點(diǎn)是最為靈活和可拓展的，一般推薦都會(huì)使用第三種。

2.6 序列化

2.6.1 概念介紹

序列化（serialization）就是將對(duì)象序列化為二進(jìn)制形式（字節(jié)數(shù)組），一般也將序列化稱為編碼（Encode），主要用于網(wǎng)絡(luò)傳輸、數(shù)據(jù)持久化等。

反序列化（deserialization）則是將從網(wǎng)絡(luò)、磁盤等讀取的字節(jié)數(shù)組還原成原始對(duì)象，以便后續(xù)業(yè)務(wù)的進(jìn)行，一般也將反序列化稱為解碼（Decode），用于網(wǎng)絡(luò)傳輸對(duì)象的解碼，以便完成遠(yuǎn)程調(diào)用。

2.6.2 序列化協(xié)議XML & SOAP

XML是一種常用的序列化和反序列化協(xié)議，具有跨機(jī)器，跨語言等優(yōu)點(diǎn)。XML歷史悠久，其1.0版本早在1998年就形成標(biāo)準(zhǔn)，并被廣泛使用至今，目前金融和銀行行業(yè)使用較多。

JSON

JSON 全程（Javascript Object Notation）起源于弱類型語言Javascript， 它的產(chǎn)生來自于一種稱之為”Associative array”的概念，其本質(zhì)是就是采用”Attribute－value”的方式來描述對(duì)象。實(shí)際上在Javascript和PHP等弱類型語言中，類的描述方式就是Associative array。JSON的具有數(shù)據(jù)簡單，可接受程度高，結(jié)構(gòu)簡潔，序列化包體小等特點(diǎn)，目前大部分的公司都是使用這種序列化協(xié)議來實(shí)現(xiàn)的。

Protobuf

由谷歌開發(fā)的一款高性能序列化框架，是一個(gè)純粹的展示層協(xié)議，可以和各種傳輸層協(xié)議一起使用，目前支持Java、C++、Python 等多種語言，他具有更小的數(shù)據(jù)量，更快的解析速度，簡單的調(diào)用等特點(diǎn)，目前得物使用的Dubbo2.7.7版本 默認(rèn)使用這種序列化協(xié)議。

2.7 負(fù)載均衡

負(fù)載均衡是保證服務(wù)提供方在多實(shí)例的情況下保證負(fù)載的均衡的一種策略，目前大體有如下幾種負(fù)載均衡策略：

1）輪訓(xùn)，采用計(jì)數(shù)器的方式，根據(jù)計(jì)數(shù)器的值和實(shí)例數(shù)量進(jìn)行取余。

2）隨機(jī)，采用隨機(jī)請(qǐng)求的方式，隨機(jī)一個(gè)Random的數(shù)值，根據(jù)random進(jìn)行取余。

3）加權(quán)輪訓(xùn)，采用權(quán)重的方式，給每一個(gè)實(shí)例配置不同的權(quán)重比例，通過比例選擇合適的實(shí)例。

4） 一致性Hash，采用Hash環(huán)的方式，大體的實(shí)現(xiàn)思路是通過尋址的方式找到就近的一個(gè)節(jié)點(diǎn)，具體可以自行網(wǎng)上搜索一下相關(guān)文檔理解。

三、實(shí)現(xiàn)

既然是當(dāng)作練手實(shí)現(xiàn)一個(gè)RPC框架，所以會(huì)盡量借鑒當(dāng)前主流的框架，技術(shù)選型方面：

 注冊中心：選擇Zookeeper來實(shí)現(xiàn)。

服務(wù)提供方：選擇基于服務(wù)維度來實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)，目前主流框架都是基于這個(gè)來做的。

服務(wù)消費(fèi)方：選擇Dubbo類似的基于代理Spring的BeanDefination來實(shí)現(xiàn)。

通訊框架：Netty。

通訊協(xié)議：采用上述的第三種方式。

序列化協(xié)議：支持JSON 和 Protobuf。

負(fù)載均衡：實(shí)現(xiàn)輪訓(xùn)和隨機(jī)。

當(dāng)然，上述的組件都是使用SpringBoot的SPI方式來進(jìn)行選擇的，后續(xù)如果需要進(jìn)行拓展和按不同配置加載，可以通過配置的方式來實(shí)現(xiàn)插件的可插拔。

廢話不多說，先貼上項(xiàng)目整體結(jié)構(gòu)：

整體代碼結(jié)構(gòu)如上，下面針對(duì)模塊一一講解：

3.1 注冊中心

代碼實(shí)現(xiàn)如下：

因?yàn)槲覀兪且钥赏卣购徒涌诜绞綄?shí)現(xiàn)的，所以我們定義了一些接口，通過不同的實(shí)現(xiàn)來進(jìn)行區(qū)分，后期可以通過不同的配置來選擇合適的注冊中心。

3.2 服務(wù)提供方

服務(wù)提供方通過使用Spring的事件來進(jìn)行監(jiān)聽，同時(shí)根據(jù)聲明式的注解來進(jìn)行解析和注冊，同時(shí)通過組裝元數(shù)據(jù)，將自己的服務(wù)注冊到注冊中心，完成服務(wù)提供方的服務(wù)注冊，同時(shí)啟動(dòng)Netty的客戶端，來進(jìn)行客戶端的監(jiān)聽，從而進(jìn)行服務(wù)調(diào)用，具體流程圖如下：

部分實(shí)現(xiàn)代碼如下：

自動(dòng)裝備邏輯：

使用和服務(wù)注冊邏輯：

3.3 服務(wù)消費(fèi)方

服務(wù)消費(fèi)方的邏輯稍微復(fù)雜一些，需要通過自動(dòng)裝配來創(chuàng)建新的BeanDefination, 然后從所有的Bean中找到相關(guān)的帶有RPC注解的參數(shù)，重寫B(tài)eanDefination，重寫的Bean需要構(gòu)建新的元數(shù)據(jù)和存入客戶端緩存，然后通過動(dòng)態(tài)代理的方式，創(chuàng)建一個(gè)代理對(duì)象，對(duì)象使用負(fù)載均衡在服務(wù)發(fā)現(xiàn)的時(shí)候選擇一個(gè)地址，通過Netty的方式進(jìn)行通信和數(shù)據(jù)交互，最后返回相關(guān)數(shù)據(jù)對(duì)象，具體的流程如下圖：

部分實(shí)現(xiàn)代碼如下：

啟動(dòng)開始類代碼：

代理類實(shí)現(xiàn)代碼：

負(fù)載均衡實(shí)現(xiàn)代碼：（SPI可拓展模式）

目前采用輪訓(xùn)和隨機(jī)的方式實(shí)現(xiàn)的，后期可根據(jù)接口進(jìn)行拓展。

3.4 通訊框架

我們使用Netty4實(shí)現(xiàn)了通訊框架，采用了NettyClient和NettyServer來實(shí)現(xiàn)：

3.5 通訊協(xié)議

我們目前使用了自定義的通信協(xié)議來實(shí)現(xiàn)：

第一個(gè)字節(jié)是魔法數(shù)，比如我定義為0X35。

第二個(gè)字節(jié)代表協(xié)議版本號(hào)，以便對(duì)協(xié)議進(jìn)行擴(kuò)展，使用不同的協(xié)議解析器。

第三個(gè)字節(jié)是請(qǐng)求類型，如0代表請(qǐng)求1代表響應(yīng)。

第四個(gè)字節(jié)表示消息長度，即此四個(gè)字節(jié)后面此長度的內(nèi)容是消息content。

3.6 序列化協(xié)議

目前支持JSON和ProtoBuf，后期我們可以通過SPI進(jìn)行拓展和可配置。

整體核心調(diào)用流程：

四、總結(jié)

本文從整體名詞介紹、內(nèi)部組件組件介紹等兩個(gè)方面闡述了RPC的框架模型，從技術(shù)選型、具體代碼等實(shí)現(xiàn)了一個(gè)RPC框架并應(yīng)用到項(xiàng)目中。目前RPC框架整體搭建完成，可以正常通過注解接入業(yè)務(wù)方使用，但還有很多細(xì)節(jié)需要更仔細(xì)地去考慮和思索，比如系統(tǒng)的可拓展性和框架的整體性能等。希望通過閱讀本篇文章，可以讓讀者對(duì)RPC有更清晰的了解，讓自己的基礎(chǔ)技能有一個(gè)更高的提升。