本文轉載自微信公眾號「樓仔」，作者夢樓。轉載本文請聯系樓仔公眾號。

RPC系列的文章是我去年寫的，當時寫的比較散，現在重新進行整理。對于想學習RPC框架的同學，通過這篇文章，讓你知其然并知其所以然，便于以后技術選型，下面是文章內容目錄：

RPC

什么是RPC

RPC(Remote Procedure Call Protocol)遠程過程調用協議。一個通俗的描述是：客戶端在不知道調用細節的情況下，調用存在于遠程計算機上的某個對象，就像調用本地應用程序中的對象一樣。

比較正式的描述是：一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。

那么我們至少從這樣的描述中挖掘出幾個要點：

• RPC是協議：既然是協議就只是一套規范，那么就需要有人遵循這套規范來進行實現。目前典型的RPC實現包括：Dubbo、Thrift、GRPC、Hetty等。
• 網絡協議和網絡IO模型對其透明：既然RPC的客戶端認為自己是在調用本地對象。那么傳輸層使用的是TCP/UDP還是HTTP協議，又或者是一些其他的網絡協議它就不需要關心了。
• 信息格式對其透明：我們知道在本地應用程序中，對于某個對象的調用需要傳遞一些參數，并且會返回一個調用結果。至于被調用的對象內部是如何使用這些參數，并計算出處理結果的，調用方是不需要關心的。那么對于遠程調用來說，這些參數會以某種信息格式傳遞給網絡上的另外一臺計算機，這個信息格式是怎樣構成的，調用方是不需要關心的。
• 應該有跨語言能力：為什么這樣說呢?因為調用方實際上也不清楚遠程服務器的應用程序是使用什么語言運行的。那么對于調用方來說，無論服務器方使用的是什么語言，本次調用都應該成功，并且返回值也應該按照調用方程序語言所能理解的形式進行描述。

為什么要用RPC

其實這是應用開發到一定的階段的強烈需求驅動的。如果我們開發簡單的單一應用，邏輯簡單、用戶不多、流量不大，那我們用不著。當我們的系統訪問量增大、業務增多時，我們會發現一臺單機運行此系統已經無法承受。此時，我們可以將業務拆分成幾個互不關聯的應用，分別部署在各自機器上，以劃清邏輯并減小壓力。此時，我們也可以不需要RPC，因為應用之間是互不關聯的。

當我們的業務越來越多、應用也越來越多時，自然的，我們會發現有些功能已經不能簡單劃分開來或者劃分不出來。此時，可以將公共業務邏輯抽離出來，將之組成獨立的服務Service應用 。而原有的、新增的應用都可以與那些獨立的Service應用 交互，以此來完成完整的業務功能。

所以此時，我們急需一種高效的應用程序之間的通訊手段來完成這種需求，所以你看，RPC大顯身手的時候來了!

其實描述的場景也是服務化 、微服務和分布式系統架構的基礎場景。即RPC框架就是實現以上結構的有力方式。

常用的RPC框架

• Thrift：thrift是一個軟件框架，用來進行可擴展且跨語言的服務的開發。它結合了功能強大的軟件堆棧和代碼生成引擎，以構建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 這些編程語言間無縫結合的、高效的服務。
• gRPC：一開始由 google 開發，是一款語言中立、平臺中立、開源的遠程過程調用(RPC)系統。
• Dubbo：Dubbo是一個分布式服務框架，以及SOA治理方案。其功能主要包括：高性能NIO通訊及多協議集成，服務動態尋址與路由，軟負載均衡與容錯，依賴分析與降級等。Dubbo是阿里巴巴內部的SOA服務化治理方案的核心框架，Dubbo自2011年開源后，已被許多非阿里系公司使用。
• Spring Cloud：Spring Cloud由眾多子項目組成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系統及微服務常用的工具，如配置管理、服務發現、斷路器、智能路由、微代理、控制總線、一次性token、全局鎖、選主、分布式會話和集群狀態等，滿足了構建微服務所需的所有解決方案。Spring Cloud基于Spring Boot, 使得開發部署極其簡單。

RPC原理

RPC調用流程

要讓網絡通信細節對使用者透明，我們需要對通信細節進行封裝，我們先看下一個RPC調用的流程涉及到哪些通信細節：

1. 服務消費方(client)調用以本地調用方式調用服務;
2. client stub接收到調用后負責將方法、參數等組裝成能夠進行網絡傳輸的消息體;
3. client stub找到服務地址，并將消息發送到服務端;
4. server stub收到消息后進行解碼;
5. server stub根據解碼結果調用本地的服務;
6. 本地服務執行并將結果返回給server stub;
7. server stub將返回結果打包成消息并發送至消費方;
8. client stub接收到消息，并進行解碼;
9. 服務消費方得到最終結果。

RPC的目標就是要2~8這些步驟都封裝起來，讓用戶對這些細節透明。

下面是網上的另外一幅圖，感覺一目了然：

如何做到透明化遠程服務調用

怎么封裝通信細節才能讓用戶像以本地調用方式調用遠程服務呢?對java來說就是使用代理!java代理有兩種方式：1) jdk 動態代理;2)字節碼生成。盡管字節碼生成方式實現的代理更為強大和高效，但代碼維護不易，大部分公司實現RPC框架時還是選擇動態代理方式。

下面簡單介紹下動態代理怎么實現我們的需求。我們需要實現RPCProxyClient代理類，代理類的invoke方法中封裝了與遠端服務通信的細節，消費方首先從RPCProxyClient獲得服務提供方的接口，當執行helloWorldService.sayHello("test")方法時就會調用invoke方法。

public class RPCProxyClient implements java.lang.reflect.InvocationHandler{
    private Object obj;
    public RPCProxyClient(Object obj){
        this.obj=obj;
    }
    /**
     * 得到被代理對象;
     */
    public static Object getProxy(Object obj){
        return java.lang.reflect.Proxy.newProxyInstance(obj.getClass().getClassLoader(),
                obj.getClass().getInterfaces(), new RPCProxyClient(obj));
    }
    /**
     * 調用此方法執行
     */
    public Object invoke(Object proxy, Method method, Object[] args)
            throws Throwable {
        //結果參數;
        Object result = new Object();
        // ...執行通信相關邏輯
        // ...
        return result;
    }
}

public class Test {
     public static void main(String[] args) {         
     HelloWorldService helloWorldService = (HelloWorldService)RPCProxyClient.getProxy(HelloWorldService.class);
     helloWorldService.sayHello("test");
    }
}

其實就是通過動態代理模式，在執行該方法的前后對數據進行封裝和解碼等，讓用于感覺就像是直接調用該方法一樣，殊不知，我們對方法前后都經過了復雜的處理。

如何對消息進行編碼和解碼

確定消息數據結構

客戶端的請求消息結構一般需要包括以下內容：

• 接口名稱：在我們的例子里接口名是“HelloWorldService”，如果不傳，服務端就不知道調用哪個接口了;
• 方法名：一個接口內可能有很多方法，如果不傳方法名服務端也就不知道調用哪個方法;
• 參數類型&參數值：參數類型有很多，比如有bool、int、long、double、string、map、list，甚至如struct等，以及相應的參數值;
• 超時時間 + requestID(標識唯一請求id)

服務端返回的消息結構一般包括以下內容：

• 狀態code + 返回值
• requestID

序列化

一旦確定了消息的數據結構后，下一步就是要考慮序列化與反序列化了。

什么是序列化?序列化就是將數據結構或對象轉換成二進制串的過程，也就是編碼的過程。

什么是反序列化?將在序列化過程中所生成的二進制串轉換成數據結構或者對象的過程。

為什么需要序列化?轉換為二進制串后才好進行網絡傳輸嘛!

為什么需要反序列化?將二進制轉換為對象才好進行后續處理!

現如今序列化的方案越來越多，每種序列化方案都有優點和缺點，它們在設計之初有自己獨特的應用場景，那到底選擇哪種呢?從RPC的角度上看，主要看三點：

• 通用性：比如是否能支持Map等復雜的數據結構;
• 性能：包括時間復雜度和空間復雜度，由于RPC框架將會被公司幾乎所有服務使用，如果序列化上能節約一點時間，對整個公司的收益都將非常可觀，同理如果序列化上能節約一點內存，網絡帶寬也能省下不少;
• 可擴展性：對互聯網公司而言，業務變化飛快，如果序列化協議具有良好的可擴展性，支持自動增加新的業務字段，而不影響老的服務，這將大大提供系統的靈活度。

目前互聯網公司廣泛使用Protobuf、Thrift、Avro等成熟的序列化解決方案來搭建RPC框架，這些都是久經考驗的解決方案。

消息里為什么要有requestID?這個問題很簡單，就不說明了，你能回答出來么?

如何發布自己的服務

這個我前面的很多文章都提到過，Java常用zookeeper，Go常用ETCD，服務端進行注冊和心跳，客戶端獲取機器列表，沒啥高深的，比如zookeeper：

gRPC & Thrift

gRPC

gRPC 簡介

gRPC是一個高性能、通用的開源RPC框架，其由Google 2015年主要面向移動應用開發并基于HTTP/2協議標準而設計，基于ProtoBuf序列化協議開發，且支持眾多開發語言。

由于是開源框架，通信的雙方可以進行二次開發，所以客戶端和服務器端之間的通信會更加專注于業務層面的內容，減少了對由gRPC框架實現的底層通信的關注。

如下圖，DATA部分即業務層面內容，下面所有的信息都由gRPC進行封裝。

gRPC 特點

• 語言中立，支持多種語言;
• 基于 IDL 文件定義服務，通過 proto3 工具生成指定語言的數據結構、服務端接口以及客戶端 Stub;
• 通信協議基于標準的 HTTP/2 設計，支持雙向流、消息頭壓縮、單 TCP 的多路復用、服務端推送等特性，這些特性使得 gRPC 在移動端設備上更加省電和節省網絡流量;
• 序列化支持 PB(Protocol Buffer)和 JSON，PB 是一種語言無關的高性能序列化框架，基于 HTTP/2 + PB, 保障了 RPC 調用的高性能。

gRPC 交互過程

• 交換機在開啟gRPC功能后充當gRPC客戶端的角色，采集服務器充當gRPC服務器角色;
• 交換機會根據訂閱的事件構建對應數據的格式(GPB/JSON)，通過Protocol Buffers進行編寫proto文件，交換機與服務器建立gRPC通道，通過gRPC協議向服務器發送請求消息;
• 服務器收到請求消息后，服務器會通過Protocol Buffers解譯proto文件，還原出最先定義好格式的數據結構，進行業務處理;
• 數據處理完后，服務器需要使用Protocol Buffers重編譯應答數據，通過gRPC協議向交換機發送應答消息;
• 交換機收到應答消息后，結束本次的gRPC交互。

簡單地說，gRPC就是在客戶端和服務器端開啟gRPC功能后建立連接，將設備上配置的訂閱數據推送給服務器端。我們可以看到整個過程是需要用到Protocol Buffers將所需要處理數據的結構化數據在proto文件中進行定義。

什么是Protocol Buffers?

你可以理解ProtoBuf是一種更加靈活、高效的數據格式，與XML、JSON類似，在一些高性能且對響應速度有要求的數據傳輸場景非常適用。ProtoBuf在gRPC的框架中主要有三個作用：

• 定義數據結構
• 定義服務接口
• 通過序列化和反序列化，提升傳輸效率

為什么ProtoBuf會提高傳輸效率呢?

我們知道使用XML、JSON進行數據編譯時，數據文本格式更容易閱讀，但進行數據交換時，設備就需要耗費大量的CPU在I/O動作上，自然會影響整個傳輸速率。Protocol Buffers不像前者，它會將字符串進行序列化后再進行傳輸，即二進制數據。

可以看到其實兩者內容相差不大，并且內容非常直觀，但是Protocol Buffers編碼的內容只是提供給操作者閱讀的，實際上傳輸的并不會以這種文本形式，而是序列化后的二進制數據。字節數會比JSON、XML的字節數少很多，速率更快。

如何支撐跨平臺，多語言呢?

Protocol Buffers自帶一個編譯器也是一個優勢點。前面提到的proto文件就是通過編譯器進行編譯的，proto文件需要編譯生成一個類似庫文件，基于庫文件才能真正開發數據應用。具體用什么編程語言編譯生成這個庫文件呢?由于現網中負責網絡設備和服務器設備的運維人員往往不是同一組人，運維人員可能會習慣使用不同的編程語言進行運維開發，那么Protocol Buffers其中一個優勢就能發揮出來——跨語言。

從上面的介紹，我們得出在編碼方面Protocol Buffers對比JSON、XML的優點：

• 簡單，體積小，數據描述文件大小只有1/10至1/3;
• 傳輸和解析的速率快，相比XML等，解析速度提升20倍甚至更高;
• 可編譯性強。

基于HTTP 2.0標準設計

除了Protocol Buffers之外，從交互圖中和分層框架可以看到， gRPC還有另外一個優勢——它是基于HTTP 2.0協議的。

由于gRPC基于HTTP 2.0標準設計，帶來了更多強大功能，如多路復用、二進制幀、頭部壓縮、推送機制。這些功能給設備帶來重大益處，如節省帶寬、降低TCP連接次數、節省CPU使用等。gRPC既能夠在客戶端應用，也能夠在服務器端應用，從而以透明的方式實現兩端的通信和簡化通信系統的構建。

HTTP 版本分為HTTP 1.X、 HTTP 2.0，其中HTTP 1.X是當前使用最廣泛的HTTP協議，HTTP 2.0稱為超文本傳輸協議第二代。HTTP 1.X定義了四種與服務器交互的方式，分別為：GET、POST、PUT、DELETE，這些在HTTP 2.0中均保留。HTTP 2.0的新特性：

• 雙向流、多路復用
• 二進制幀
• 頭部壓縮

Thrift

Thrift 簡介

thrift是一種可伸縮的跨語言服務的RPC軟件框架。它結合了功能強大的軟件堆棧的代碼生成引擎，以建設服務，高效、無縫地在多種語言間結合使用。2007年由facebook貢獻到apache基金，是apache下的頂級項目，具備如下特點：

• 支持多語言：C、C++ 、C# 、D 、Delphi 、Erlang 、Go 、Haxe 、Haskell 、Java 、JavaScript、node.js 、OCaml 、Perl 、PHP 、Python 、Ruby 、SmallTalk
• 消息定義文件支持注釋，數據結構與傳輸表現的分離，支持多種消息格式
• 包含完整的客戶端/服務端堆棧，可快速實現RPC，支持同步和異步通信

Thrift框架結構

Thrift是一套包含序列化功能和支持服務通信的RPC(遠程服務調用)框架，也是一種微服務框架。其主要特點是可以跨語言使用，這也是這個框架最吸引人的地方。

圖中code是用戶實現的業務邏輯，接下來的 Service.Client和 write()/read()是thrift根據IDL生成的客戶端和服務端的代碼，對應于RPC中Client stub和Server stub。TProtocol 用來對數據進行序列化與反序列化，具體方法包括二進制，JSON 或者 Apache Thrift 定義的格式。TTransport 提供數據傳輸功能，使用 Apache Thrift 可以方便地定義一個服務并選擇不同的傳輸協議。

Thrift網絡棧結構

thirft使用socket進行數據傳輸，數據以特定的格式發送，接收方進行解析。我們定義好thrift的IDL文件后，就可以使用thrift的編譯器來生成雙方語言的接口、model，在生成的model以及接口代碼中會有解碼編碼的代碼。thrift網絡棧結構如下：

Transport層

代表Thrift的數據傳輸方式，Thrift定義了如下幾種常用數據傳輸方式：

• TSocket: 阻塞式socket;
• TFramedTransport: 以frame為單位進行傳輸，非阻塞式服務中使用;
• TFileTransport: 以文件形式進行傳輸。

TProtocol層

代表thrift客戶端和服務端之間傳輸數據的協議，通俗來講就是客戶端和服務端之間傳輸數據的格式(例如json等)，thrift定義了如下幾種常見的格式：

• TBinaryProtocol: 二進制格式;
• TCompactProtocol: 壓縮格式;
• TJSONProtocol: JSON格式;
• TSimpleJSONProtocol: 提供只寫的JSON協議。

Server模型

• TSimpleServer: 簡單的單線程服務模型，常用于測試;
• TThreadPoolServer: 多線程服務模型，使用標準的阻塞式IO;
• TNonBlockingServer: 多線程服務模型，使用非阻塞式IO(需要使用TFramedTransport數據傳輸方式);
• THsHaServer: THsHa引入了線程池去處理，其模型讀寫任務放到線程池去處理，Half-sync/Half-async處理模式，Half-async是在處理IO事件上(accept/read/write io)，Half-sync用于handler對rpc的同步處理;

gRPC VS Thrift

功能比較

直接貼上網上的兩幅截圖：

性能比較

也是基于網上測試的結果，僅供參考：

• 整體上看，長連接性能優于短連接，性能差距在兩倍以上;
• 對比Go語言的兩個RPC框架，Thrift性能明顯優于gRPC，性能差距也在兩倍以上;
• 對比Thrift框架下的的兩種語言，長連接下Go 與C++的RPC性能基本在同一個量級，在短連接下，Go性能大概是C++的二倍;
• 對比Thrift&C++下的TSimpleServer與TNonblockingServer，在單進程客戶端長連接的場景下，TNonblockingServer因為存在線程管理開銷，性能較TSimpleServer差一些;但在短連接時，主要開銷在連接建立上，線程池管理開銷可忽略;
• 兩套RPC框架，以及兩大語言運行都非常穩定，5w次請求耗時約是1w次的5倍;

如何選型

什么時候應該選擇gRPC而不是Thrift：

• 需要良好的文檔、示例
• 喜歡、習慣HTTP/2、ProtoBuf
• 對網絡傳輸帶寬敏感

什么時候應該選擇Thrift而不是gRPC：

• 需要在非常多的語言間進行數據交換
• 對CPU敏感
• 協議層、傳輸層有多種控制要求
• 需要穩定的版本
• 不需要良好的文檔和示例

小節

上面詳細介紹gRPC和Thrift的特點和區別，小節如下：

• GRPC主要就是搞了個ProtoBuf，然后采用HTTP協議，所以協議部分沒有重復造輪子，重點就在ProtoBuf上。
• Thrift的數據格式是用的現成的，沒有單獨搞一套，但是它在傳輸層和服務端全部是自己造輪子，所以可以對協議層、傳輸層有多種控制要求。

gRPC示例

除了理論，我們還需注重實踐，gPRC的使用姿勢看這篇文章 ??【RPC基礎系列3】gRPC簡單示例??

Dubbo & Spring Cloud

Dubbo

Dubbo 是一個分布式服務框架，致力于提供高性能和透明化的 RPC 遠程服務調用方案，以及 SOA 服務治理方案。簡單的說，Dubbo 就是個服務框架，說白了就是個遠程服務調用的分布式框架。

Dubbo 總體架構：

Dubbo特點：

• 遠程通訊: 提供對多種基于長連接的 NIO 框架抽象封裝(非阻塞 I/O 的通信方式，Mina/Netty/Grizzly)，包括多種線程模型，序列化(Hessian2/ProtoBuf)，以及“請求-響應”模式的信息交換方式。
• 集群容錯: 提供基于接口方法的透明遠程過程調用(RPC)，包括多協議支持(自定義 RPC 協議)，以及軟負載均衡(Random/RoundRobin)，失敗容錯(Failover/Failback)，地址路由，動態配置等集群支持。
• 自動發現: 基于注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

Spring Cloud

Spring Cloud 基于 Spring Boot，為微服務體系開發中的架構問題，提供了一整套的解決方案——服務注冊與發現，服務消費，服務保護與熔斷，網關，分布式調用追蹤，分布式配置管理等。

Dubbo vs Spring Cloud

使用 Dubbo 構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條內存質量不行就點不亮了，總是讓人不怎么放心，但是如果你是一名高手，那這些都不是問題;而 Spring Cloud 就像品牌機，在 Spring Source 的整合下，做了大量的兼容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝組件外的東西，就需要對其基礎有足夠的了解。

關于 Dubbo 和 Spring Cloud 的相關概念和對比，我個人比較傾向于 Spring Cloud，原因就是真正的微服務框架、提供整套的組件支持、使用簡單方便、強大的社區支持等等，另外，因為考慮到 .NET/.NET Core 的兼容處理，RPC 并不能很好的實現跨語言(需要借助跨語言庫，比如 gRPC、Thrift，但因為 Dubbo 本身就是“gRPC”，在 Dubbo 之上再包一層 gRPC，有點重復封裝了)，而 HTTP REST 本身就是支持跨語言實現，所以，Spring Cloud 這一點還是非常好的(Dubbox 也支持，但性能相比要差一些)。

但凡事無絕對，每件事物有好的地方也有不好的地方，總的來說，Dubbo 和 Spring Cloud 的主要不同體現在兩個方面：服務調用方式不同和專注點不同(生態不同)。