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

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

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

一、介紹

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

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

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

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

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

二、RPC框架基本組成

RPC框架需要的最基本的三個要素：

ServiceProvider: 服務提供方，提供相關服務接口。

ServiceConsumer: 服務消費方，消費服務提供方的接口。

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

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

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

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

2.1 注冊中心

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

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

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

2.2 服務提供方（RPC服務端）

其需要對外提供服務接口，一個服務方需要包括啟動連接注冊中心，注冊相關信息到注冊中心，提供服務下線和更新機制，維護服務名和服務的映射，序列化和反序列化，啟動通信等。

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

2.3 服務消費方（RPC消費端）

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

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

2.4 通訊框架

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

2.5 通訊協(xié)議

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

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

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

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

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

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

2.6 序列化

2.6.1 概念介紹

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

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

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

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

JSON

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

Protobuf

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

2.7 負載均衡

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

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

2）隨機，采用隨機請求的方式，隨機一個Random的數(shù)值，根據(jù)random進行取余。

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

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

三、實現(xiàn)

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

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

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

服務消費方：選擇Dubbo類似的基于代理Spring的BeanDefination來實現(xiàn)。

通訊框架：Netty。

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

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

負載均衡：實現(xiàn)輪訓和隨機。

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

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

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

3.1 注冊中心

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

因為我們是以可拓展和接口方式實現(xiàn)的，所以我們定義了一些接口，通過不同的實現(xiàn)來進行區(qū)分，后期可以通過不同的配置來選擇合適的注冊中心。

3.2 服務提供方

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

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

自動裝備邏輯：

使用和服務注冊邏輯：

3.3 服務消費方

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

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

啟動開始類代碼：

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

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

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

3.4 通訊框架

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

3.5 通訊協(xié)議

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

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

第二個字節(jié)代表協(xié)議版本號，以便對協(xié)議進行擴展，使用不同的協(xié)議解析器。

第三個字節(jié)是請求類型，如0代表請求1代表響應。

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

3.6 序列化協(xié)議

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

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

四、總結(jié)

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