本文轉(zhuǎn)載自微信公眾號「樓仔」，作者夢樓。轉(zhuǎn)載本文請聯(lián)系樓仔公眾號。

RPC系列的文章是我去年寫的，當(dāng)時寫的比較散，現(xiàn)在重新進行整理。對于想學(xué)習(xí)RPC框架的同學(xué)，通過這篇文章，讓你知其然并知其所以然，便于以后技術(shù)選型，下面是文章內(nèi)容目錄：

RPC

什么是RPC

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

比較正式的描述是：一種通過網(wǎng)絡(luò)從遠程計算機程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。

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

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

為什么要用RPC

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

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

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

其實描述的場景也是服務(wù)化 、微服務(wù)和分布式系統(tǒng)架構(gòu)的基礎(chǔ)場景。即RPC框架就是實現(xiàn)以上結(jié)構(gòu)的有力方式。

常用的RPC框架

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

RPC原理

RPC調(diào)用流程

要讓網(wǎng)絡(luò)通信細節(jié)對使用者透明，我們需要對通信細節(jié)進行封裝，我們先看下一個RPC調(diào)用的流程涉及到哪些通信細節(jié)：

1. 服務(wù)消費方(client)調(diào)用以本地調(diào)用方式調(diào)用服務(wù);
2. client stub接收到調(diào)用后負責(zé)將方法、參數(shù)等組裝成能夠進行網(wǎng)絡(luò)傳輸?shù)南Ⅲw;
3. client stub找到服務(wù)地址，并將消息發(fā)送到服務(wù)端;
4. server stub收到消息后進行解碼;
5. server stub根據(jù)解碼結(jié)果調(diào)用本地的服務(wù);
6. 本地服務(wù)執(zhí)行并將結(jié)果返回給server stub;
7. server stub將返回結(jié)果打包成消息并發(fā)送至消費方;
8. client stub接收到消息，并進行解碼;
9. 服務(wù)消費方得到最終結(jié)果。

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

下面是網(wǎng)上的另外一幅圖，感覺一目了然：

如何做到透明化遠程服務(wù)調(diào)用

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

下面簡單介紹下動態(tài)代理怎么實現(xiàn)我們的需求。我們需要實現(xiàn)RPCProxyClient代理類，代理類的invoke方法中封裝了與遠端服務(wù)通信的細節(jié)，消費方首先從RPCProxyClient獲得服務(wù)提供方的接口，當(dāng)執(zhí)行helloWorldService.sayHello("test")方法時就會調(diào)用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));
    }
    /**
     * 調(diào)用此方法執(zhí)行
     */
    public Object invoke(Object proxy, Method method, Object[] args)
            throws Throwable {
        //結(jié)果參數(shù);
        Object result = new Object();
        // ...執(zhí)行通信相關(guān)邏輯
        // ...
        return result;
    }
}

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

其實就是通過動態(tài)代理模式，在執(zhí)行該方法的前后對數(shù)據(jù)進行封裝和解碼等，讓用于感覺就像是直接調(diào)用該方法一樣，殊不知，我們對方法前后都經(jīng)過了復(fù)雜的處理。

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

確定消息數(shù)據(jù)結(jié)構(gòu)

客戶端的請求消息結(jié)構(gòu)一般需要包括以下內(nèi)容：

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

服務(wù)端返回的消息結(jié)構(gòu)一般包括以下內(nèi)容：

• 狀態(tài)code + 返回值
• requestID

序列化

一旦確定了消息的數(shù)據(jù)結(jié)構(gòu)后，下一步就是要考慮序列化與反序列化了。

什么是序列化?序列化就是將數(shù)據(jù)結(jié)構(gòu)或?qū)ο筠D(zhuǎn)換成二進制串的過程，也就是編碼的過程。

什么是反序列化?將在序列化過程中所生成的二進制串轉(zhuǎn)換成數(shù)據(jù)結(jié)構(gòu)或者對象的過程。

為什么需要序列化?轉(zhuǎn)換為二進制串后才好進行網(wǎng)絡(luò)傳輸嘛!

為什么需要反序列化?將二進制轉(zhuǎn)換為對象才好進行后續(xù)處理!

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

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

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

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

如何發(fā)布自己的服務(wù)

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

gRPC & Thrift

gRPC

gRPC 簡介

gRPC是一個高性能、通用的開源RPC框架，其由Google 2015年主要面向移動應(yīng)用開發(fā)并基于HTTP/2協(xié)議標(biāo)準(zhǔn)而設(shè)計，基于ProtoBuf序列化協(xié)議開發(fā)，且支持眾多開發(fā)語言。

由于是開源框架，通信的雙方可以進行二次開發(fā)，所以客戶端和服務(wù)器端之間的通信會更加專注于業(yè)務(wù)層面的內(nèi)容，減少了對由gRPC框架實現(xiàn)的底層通信的關(guān)注。

如下圖，DATA部分即業(yè)務(wù)層面內(nèi)容，下面所有的信息都由gRPC進行封裝。

gRPC 特點

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

gRPC 交互過程

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

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

什么是Protocol Buffers?

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

• 定義數(shù)據(jù)結(jié)構(gòu)
• 定義服務(wù)接口
• 通過序列化和反序列化，提升傳輸效率

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

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

可以看到其實兩者內(nèi)容相差不大，并且內(nèi)容非常直觀，但是Protocol Buffers編碼的內(nèi)容只是提供給操作者閱讀的，實際上傳輸?shù)牟⒉粫赃@種文本形式，而是序列化后的二進制數(shù)據(jù)。字節(jié)數(shù)會比JSON、XML的字節(jié)數(shù)少很多，速率更快。

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

Protocol Buffers自帶一個編譯器也是一個優(yōu)勢點。前面提到的proto文件就是通過編譯器進行編譯的，proto文件需要編譯生成一個類似庫文件，基于庫文件才能真正開發(fā)數(shù)據(jù)應(yīng)用。具體用什么編程語言編譯生成這個庫文件呢?由于現(xiàn)網(wǎng)中負責(zé)網(wǎng)絡(luò)設(shè)備和服務(wù)器設(shè)備的運維人員往往不是同一組人，運維人員可能會習(xí)慣使用不同的編程語言進行運維開發(fā)，那么Protocol Buffers其中一個優(yōu)勢就能發(fā)揮出來——跨語言。

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

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

基于HTTP 2.0標(biāo)準(zhǔn)設(shè)計

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

由于gRPC基于HTTP 2.0標(biāo)準(zhǔn)設(shè)計，帶來了更多強大功能，如多路復(fù)用、二進制幀、頭部壓縮、推送機制。這些功能給設(shè)備帶來重大益處，如節(jié)省帶寬、降低TCP連接次數(shù)、節(jié)省CPU使用等。gRPC既能夠在客戶端應(yīng)用，也能夠在服務(wù)器端應(yīng)用，從而以透明的方式實現(xiàn)兩端的通信和簡化通信系統(tǒng)的構(gòu)建。

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

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

Thrift

Thrift 簡介

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

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

Thrift框架結(jié)構(gòu)

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

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

Thrift網(wǎng)絡(luò)棧結(jié)構(gòu)

thirft使用socket進行數(shù)據(jù)傳輸，數(shù)據(jù)以特定的格式發(fā)送，接收方進行解析。我們定義好thrift的IDL文件后，就可以使用thrift的編譯器來生成雙方語言的接口、model，在生成的model以及接口代碼中會有解碼編碼的代碼。thrift網(wǎng)絡(luò)棧結(jié)構(gòu)如下：

Transport層

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

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

TProtocol層

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

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

Server模型

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

gRPC VS Thrift

功能比較

直接貼上網(wǎng)上的兩幅截圖：

性能比較

也是基于網(wǎng)上測試的結(jié)果，僅供參考：

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

如何選型

什么時候應(yīng)該選擇gRPC而不是Thrift：

• 需要良好的文檔、示例
• 喜歡、習(xí)慣HTTP/2、ProtoBuf
• 對網(wǎng)絡(luò)傳輸帶寬敏感

什么時候應(yīng)該選擇Thrift而不是gRPC：

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

小節(jié)

上面詳細介紹gRPC和Thrift的特點和區(qū)別，小節(jié)如下：

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

gRPC示例

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

Dubbo & Spring Cloud

Dubbo

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

Dubbo 總體架構(gòu)：

Dubbo特點：

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

Spring Cloud

Spring Cloud 基于 Spring Boot，為微服務(wù)體系開發(fā)中的架構(gòu)問題，提供了一整套的解決方案——服務(wù)注冊與發(fā)現(xiàn)，服務(wù)消費，服務(wù)保護與熔斷，網(wǎng)關(guān)，分布式調(diào)用追蹤，分布式配置管理等。

Dubbo vs Spring Cloud

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

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

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