Dubbo基礎知識——Dubbo的分層結構和執行流程，以及和Spring Cloud的區別。

時間 2021-08-12

標籤面試 redis 數據庫後端設計模式緩存網絡多線程架構併發欄目 Dubbo 简体版

原文原文鏈接

RPC

簡單實現一個RPC框架

咱們這是 Demo，目的是突出 RPC框架重點功能 - 實現遠程調用。因此啥七七八八的都沒，而且我用僞代碼來展現，其實也就是刪除了一些保護性和約束性的代碼，由於看起來太多了不太直觀，須要一堆 try-catch 啥的，所以我刪減了一些，直擊重點。面試

首先咱們定義一個接口和一個簡單實現。redis

public interface AobingService {  
    String hello(String name);  
} 
public class AobingServiceImpl implements AobingService {  
    public String hello(String name) {  
        return "Yo man Hello，I am" + name;  
    }  
}

而後咱們再來實現服務提供者暴露服務的功能。數據庫

public class AobingRpcFramework { 
     public static void export(Object service, int port) throws Exception { 
          ServerSocket server = new ServerSocket(port);
          while(true) {
              Socket socket = server.accept();
              new Thread(new Runnable() {
                  //反序列化
                  ObjectInputStream input = new ObjectInputStream(socket.getInputStream()); 
                  String methodName = input.read(); //讀取方法名
                  Class<?>[] parameterTypes = (Class<?>[]) input.readObject(); //參數類型
                  Object[] arguments = (Object[]) input.readObject(); //參數
                  Method method = service.getClass().getMethod(methodName, parameterTypes);  //找到方法
                  Object result = method.invoke(service, arguments); //調用方法
                  // 返回結果
                  ObjectOutputStream output = new ObjectOutputStream(socket.getOutputStream());
                  output.writeObject(result);
              }).start();
          }
     }
    public static <T> T refer (Class<T> interfaceClass, String host, int port) throws Exception {
       return  (T) Proxy.newProxyInstance(interfaceClass.getClassLoader(), new Class<?>[] {interfaceClass}, 
            new InvocationHandler() {  
                public Object invoke(Object proxy, Method method, Object[] arguments) throws Throwable {  
                    Socket socket = new Socket(host, port);  //指定 provider 的 ip 和端口
                    ObjectOutputStream output = new ObjectOutputStream(socket.getOutputStream()); 
                    output.write(method.getName());  //傳方法名
                    output.writeObject(method.getParameterTypes());  //傳參數類型
                    output.writeObject(arguments);  //傳參數值
                    ObjectInputStream input = new ObjectInputStream(socket.getInputStream());  
                    Object result = input.readObject();  //讀取結果
                    return result;  
               }
        });  
    }  
}

好了，這個 RPC 框架就這樣好了，是否是很簡單？就是調用者傳遞了方法名、參數類型和參數值，提供者接收到這樣參數以後調用對於的方法返回結果就行了！這就是遠程過程調用，咱們來看看如何使用：後端

//服務提供者只須要暴露出接口
       AobingService service = new AobingServiceImpl ();  
       AobingRpcFramework.export(service, 2333);  

       //服務調用者只須要設置依賴
       AobingService service = AobingRpcFramework.refer(AobingService.class, "127.0.0.1", 2333);  
       service.hello();

這個示例，簡單明瞭：設計模式

生產者：會一直去消費socket中的數據，若是沒有的話，就會一直阻塞住，當socket中有數據時，阻塞放開，獲取方法名和參數信息，而後執行類中的方法，並將結果寫入socket。

消費者：其實就是搞了一個代理，當調用service.hello()時，就會觸發該代理，這個代理其實就是初始化socket，而後類名和方法寫入socket，而後等待服務端返回數據，最後取出數據，而後直接返回。

說明：這裏只是一個RPC框架，真正的RPC其實還包括數據序列化和反序列化的過程，而後生產者和消費者的交互，可使HTTP，也能夠是其它方式，不必定須要咱們直接操做Socket。

Dubbo基礎

Dubbo 簡介

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

Dubbo 發展歷史

Dubbo 是阿里巴巴 2011年開源的一個基於 Java 的 RPC 框架，中間沉寂了一段時間，不過其餘一些企業還在用 Dubbo 並本身作了擴展，好比噹噹網的 Dubbox，還有網易考拉的 Dubbok。可是在 2017 年阿里巴巴又重啓了對 Dubbo 維護。在 2017 年榮獲了開源中國 2017 最受歡迎的中國開源軟件 Top 3。在 2018 年和 Dubbox 進行了合併，而且進入 Apache 孵化器，在 2019 年畢業正式成爲 Apache 頂級項目。網絡

目前 Dubbo 社區主力維護的是 2.6.x 和 2.7.x 兩大版本，2.6.x 版本主要是 bug 修復和少許功能加強爲準，是穩定版本。而 2.7.x 是主要開發版本，更新和新增新的 feature 和優化，而且 2.7.5 版本的發佈被 Dubbo 認爲是里程碑式的版本發佈。它實現了面向接口的代理 RPC 調用，而且能夠配合 ZooKeeper 等組件實現服務註冊和發現功能，而且擁有負載均衡、容錯機制等。多線程

Dubbo 整體架構

這幅圖簡單解釋一下：架構

Consumer：須要調用遠程服務的服務消費方
Registry：註冊中心
Provider：服務提供方
Container：服務運行的容器
Monitor：監控中心

一些注意的點：併發

首先註冊中心和監控中心是可選的，你能夠不要監控，也不要註冊中心，直接在配置文件裏面寫而後提供方和消費方直連。

就算註冊中心和監控中心宕機了也不會影響到已經正常運行的提供者和消費者，由於消費者有本地緩存提供者的信息。

Dubbo 分層架構

總的而言 Dubbo 分爲三層，若是每一層再細分下去，一共有十層：

大的三層分別爲 Business（業務層）、RPC 層、Remoting，而且還分爲 API 層和 SPI 層。而分 API 層和 SPI 層這是 Dubbo 成功的一點，採用微內核設計+SPI擴展，使得有特殊需求的接入方能夠自定義擴展，作定製的二次開發。

SPI（Service Provider Interface），是 JDK 內置的一個服務發現機制，它使得接口和具體實現徹底解耦。咱們只聲明接口，具體的實現類在配置中選擇。

我們再來看看每一層都是幹嗎的：

Service，業務層，就是我們開發的業務邏輯層。
Config，配置層，主要圍繞 ServiceConfig 和 ReferenceConfig，初始化配置信息。
Proxy，代理層，服務提供者仍是消費者都會生成一個代理類，使得服務接口透明化，代理層作遠程調用和返回結果。
Register，註冊層，封裝了服務註冊和發現。
Cluster，路由和集羣容錯層，負責選取具體調用的節點，處理特殊的調用要求和負責遠程調用失敗的容錯措施。
Monitor，監控層，負責監控統計調用時間和次數。
Portocol，遠程調用層，主要是封裝 RPC 調用，主要負責管理 Invoker，Invoker表明一個抽象封裝了的執行體，以後再作詳解。
Exchange，信息交換層，用來封裝請求響應模型，同步轉異步。
Transport，網絡傳輸層，抽象了網絡傳輸的統一接口，這樣用戶想用 Netty 就用 Netty，想用 Mina 就用 Mina。
Serialize，序列化層，將數據序列化成二進制流，固然也作反序列化。

Dubbo 調用過程

生產者和消費者的調用過程以下：

生產者服務註冊

啓動privider，根據協議Protocol將須要暴露出去的接口封裝成Invoker；
經過 Exporter 包裝一下，將 Exporter 經過 Registry 註冊到註冊中心。

消費者調用流程

消費者啓動會向註冊中心拉取服務提供者的元信息；
Proxy 持有一個 Invoker 對象，調用 invoke 以後須要經過 Cluster 先從 Directory 獲取全部可調用的遠程服務的 Invoker 列表，若是配置了某些路由規則，好比某個接口只能調用某個節點的那就再過濾一遍 Invoker 列表；
剩下的 Invoker 經過 LoadBalance 作負載均衡選取一個；
通過 Filter 作一些統計相關的事情；
經過 Client 作數據傳輸，好比用 Netty 來傳輸；
傳輸須要通過 Codec 接口作協議構造，再序列化
將請求發送給服務提供者

提煉一下：初始化服務拿到服務信息 -> 構造數據請求 -> 經過負載均衡選取機器節點 -> 處理統計信息 -> 序列化數據 -> 請求發送給下游

生產者處理請求

接受請求，反序列化數據；
將數據扔到線程池；
跟進請求數據，找到對應的Exporter；
經過Filter進行簡單過濾；
經過Exporter找到對應的Invoker，執行具體的方法，返回數據；
將數據序列化以後，直接返回。

提煉一下：接受請求 -> 反序列化數據 -> 扔入線程池 -> 找到Exporter -> 過濾請求 -> 經過Invoker執行 -> 反序列化結果 -> 返回請求

Dubbo特色

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

下面簡單講述一下Dubbo和Spring Cloud的區別，不過在講述二者區別以前，咱們先簡單瞭解一下Spring Cloud。

Spring Cloud簡述

Spring Cloud簡介

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

Spring Boot 是 Spring 的一套快速配置腳手架，使用默認大於配置的理念，用於快速開發單個微服務。

Spring Cloud 完整技術

核心功能：

分佈式/版本化配置
服務註冊和發現
路由
服務和服務之間的調用
負載均衡
斷路器
分佈式消息傳遞

Spring Cloud 組件架構

流程：

請求統一經過 API 網關（Zuul）來訪問內部服務。
網關接收到請求後，從註冊中心（Eureka）獲取可用服務。
由 Ribbon 進行均衡負載後，分發到後端具體實例。
微服務之間經過 Feign 進行通訊處理業務。
Hystrix 負責處理服務超時熔斷。
Turbine 監控服務間的調用和熔斷相關指標。

Dubbo vs Spring Cloud

Dubbo優缺點

優勢：

Dubbo 支持 RPC 調用，服務之間的調用性能會很好。
支持多種序列化協議，如 Hessian、HTTP、WebService。
Dobbo Admin後臺管理功能強大，提供了路由規則、動態配置、訪問控制、權重調節、均衡負載等功能。
在國內影響力比較大，中文社區文檔較爲全面。
阿里重啓維護。

缺點：

Registry 嚴重依賴第三方組件（zookeeper 或者 redis），當這些組件出現問題時，服務調用很快就會中斷。
Dubbo 只支持 RPC 調用。使得服務提供方（抽象接口）與調用方在代碼上產生了強依賴，服務提供者須要不斷將包含抽象接口的 jar 包打包出來供消費者使用。一旦打包出現問題，就會致使服務調用出錯，而且之後發佈部署會成很大問題（太強的依賴關係）。
另外，之後要兼容 .NET Core 服務，Dubbo RPC 自己不支持跨語言（能夠用跨語言 RPC 框架解決，好比 Thrift、gRPC（重複封裝了），或者本身再包一層 REST 服務，提供跨平臺的服務調用實現，但相對麻煩不少）
Dubbo 只是實現了服務治理，其餘微服務框架並未包含，若是須要使用，須要結合第三方框架實現（好比分佈式配置用淘寶的 Diamond、服務跟蹤用京東的 Hydra，但使用相對麻煩些），開發成本較高，且風險較大。
社區更新不及時（雖然最近在瘋狂更新），但也不免阿里之後又不更新了，就尷尬了。
主要是國內公司使用，但阿里內部使用 HSF，相對於 Spring Cloud，企業應用會差一些。

Spring Cloud優缺點

優勢：

有強大的 Spring 社區、Netflix 等公司支持，而且開源社區貢獻很是活躍。
標準化的將微服務的成熟產品和框架結合一塊兒，Spring Cloud 提供整套的微服務解決方案，開發成本較低，且風險較小。
基於 Spring Boot，具備簡單配置、快速開發、輕鬆部署、方便測試的特色。
支持 REST 服務調用，相比於 RPC，更加輕量化和靈活（服務之間只依賴一紙契約，不存在代碼級別的強依賴），有利於跨語言服務的實現，以及服務的發佈部署。另外，結合 Swagger，也使得服務的文檔一體化。
提供了 Docker 及 Kubernetes 微服務編排支持。
國內外企業應用很是多，經受了大公司的應用考驗（好比 Netfilx 公司），以及強大的開源社區支持。

缺點：

支持 REST 服務調用，可能由於接口定義太輕，致使定義文檔與實際實現不一致致使服務集成時的問題（可使用統一文檔和版本管理解決，好比 Swagger）。
REST 服務調用性能會比 RPC 低一些（但也不是強綁定）
Spring Cloud 整合了大量組件，相關文檔比較複雜，須要針對性的進行閱讀。

總體對比

Dubbo 專一 RPC 和服務治理，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 的主要不一樣體如今兩個方面：服務調用方式不一樣和專一點不一樣（生態不一樣）。

後記

這篇文章，其實主要是對Dubbo有一個總體的認識，而後初步瞭解Dubbo和Spring Cloud二者的區別，由於網上常常會把它們兩拿來比較。

整篇文章都是概念性的東西，可是對於咱們理解Dubbo又很是重要，能夠只能做爲入門篇，我目前也是先對Java技術棧的技術，先總體初步瞭解，後續會選擇幾個方向再深刻學習。

一直想整理出一份完美的面試寶典，可是時間上一直騰不開，這套一千多道面試題寶典，結合今年金三銀四各類大廠面試題，以及 GitHub 上 star 數超 30K+ 的文檔整理出來的，我上傳之後，毫無心外的短短半個小時點贊量就達到了 13k，說實話仍是有點難以想象的。

一千道互聯網 Java 工程師面試題

內容涵蓋：Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Spring、SpringBoot、SpringCloud、RabbitMQ、Kafka、Linux等技術棧（485頁）

《Java核心知識點合集（283頁）》

內容涵蓋：Java基礎、JVM、高併發、多線程、分佈式、設計模式、Spring全家桶、Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、MongoDB、Redis、MySQL、RabbitMQ、Kafka、Linux、Netty、Tomcat、數據庫、雲計算等