Java Dubbo框架知識點梳理

Posted on by

1、Dubbo是什麼

Dubbo 是一個分佈式、高性能、透明化的 RPC 服務框架，提供服務自動註冊、自動發現等高效服務治理方案， 可以和 Spring 框架無縫集成。

RPC 指的是遠程調用協議，也就是說兩個服務器交互數據。

2、Dubbo的由來

互聯網的快速發展，Web應用程序的規模不斷擴大，一般會經歷如下四個發展階段。

單一應用架構：當網站流量很小時，隻需一個應用，將所有功能都部署在一起即可。

垂直應用架構：當訪問量逐漸增大，單一應用按照有業務線拆成多個應用，以提升效率。此時，用於加速前端頁面開發的 Web框架（MVC） 是關鍵。

分佈式服務架構：當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。此時，用於提高業務復用及整合的 分佈式服務框架（RPC） 是關鍵。

流動計算架構：當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集群容量，提高集群利用率。此時，用於提高機器利用率的 資源調度和治理中心（SOA） 是關鍵。

3、Dubbo的主要應用場景

透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，隻需簡單配置，沒有任何API侵入。

軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，降低成本，減少單點。

服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，並且能夠平滑添加或刪除服務提供者。

4、Dubbo的核心功能

有3個核心功能：

  • Remoting：網絡通信框架，提供對多種NIO框架抽象封裝，包括“同步轉異步”和“請求-響應”模式的信息交換方式。
  • Cluster：服務框架，提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。
  • Registry：服務註冊，基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

5、Dubbo的核心組件

組件角色 說明
Provider 暴露服務的服務提供方
Consumer 調用遠程服務的服務消費方
Registry 服務註冊與發現的註冊中心
Monitor 統計服務的調用次數和調用時間的監控中心
Container 服務運行容器

6、Dubbo服務註冊與發現的流程

流程說明：

  • Provider（提供者）綁定指定端口並啟動服務
  • 提供者連接註冊中心，並發本機IP、端口、應用信息和提供服務信息發送至註冊中心存儲
  • Consumer（消費者），連接註冊中心，並發送應用信息、所求服務信息至註冊中心
  • 註冊中心根據消費者所求服務信息匹配對應的提供者列表發送至Consumer應用緩存
  • Consumer在發起遠程調用時基於緩存的消費者列表擇其一發起調用

設計的原因：

  • Consumer與Provider解耦，雙方都可以橫向增減節點數
  • 註冊中心本身可做對等集群，可動態增減節點，並且任意一臺宕掉後，將自動切換到另一臺
  • 去中心化，雙方不直接依懶註冊中心，即使註冊中心全部宕機短時間內也不會影響服務的調用

7、Dubbo的架構設計

Dubbo的框架設計一共劃分瞭10個層：

  • 服務接口層（Service）：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的接口和實現。
  • 配置層（Config）：對外配置接口，以ServiceConfig和ReferenceConfig為中心。
  • 服務代理層（Proxy）：服務接口透明代理，生成服務的客戶端Stub和服務器端Skeleton。
  • 服務註冊層（Registry）：封裝服務地址的註冊與發現，以服務URL為中心。
  • 集群層（Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker為中心。
  • 監控層（Monitor）：RPC調用次數和調用時間監控。
  • 遠程調用層（Protocol）：封裝RPC調用，以Invocation和Result為中心，擴展接口為Protocol、Invoker和Exporter。
  • 信息交換層（Exchange）：封裝請求響應模式，同步轉異步，以Request和Response為中心。
  • 網絡傳輸層（Transport）：抽象mina和netty為統一接口，以Message為中心。

8、Dubbo的服務調用流程

9、Dubbo支持的協議 dubbo：

  • dubbo：單一長連接和NIO異步通訊，適合大並發小數據量的服務調用，以及消費者遠大於提供者。傳輸協議TCP，異步，Hessian序列化
  • rmi：采用JDK標準的rmi協議實現，傳輸參數和返回參數對象需要實現Serializable接口，使用Java標準序列化機制，使用阻塞式短連接，傳輸數據包大小混合，消費者和提供者個數差不多，可傳文件，傳輸協議TCP。
  • Java序列化存在安全漏洞
  • webservice： 基於WebService的遠程調用協議，集成CXF實現，提供和原生WebService的互操作。多個短連接，基於HTTP傳輸，同步傳輸，適用系統集成和跨語言調用
  • http：基於Http表單提交的遠程調用協議，使用Spring的HttpInvoke實現。多個短連接，傳輸協議HTTP，傳入參數大小混合，提供者個數多於消費者，需要給應用程序和瀏覽器JS調用
  • hessian：集成Hessian服務，基於HTTP通訊，采用Servlet暴露服務，Dubbo內嵌Jetty作為服務器時默認實現，提供與Hession服務互操作。多個短連接，同步HTTP傳輸，Hessian序列化，傳入參數較大，提供者大於消費者，提供者壓力較大，可傳文件

10、dubbo推薦用什麼協議

默認使用dubbo協議。

11、Dubbo有哪些註冊中心

  • Multicast註冊中心：Multicast註冊中心不需要任何中心節點，隻要廣播地址，就能進行服務註冊和發現。基於網絡分組傳輸實現
  • Zookeeper註冊中心：基於分佈式協調系統Zookeeper實現，采用Zookeeper的watch機制實現數據變更
  • redis註冊中心：基於redis實現，采用key/Map存儲，key存儲服務名和類型，Map中key存儲服務URL，value存儲服務過期時間。基於redis的發佈/訂閱模式通知數據變更
  • Simple註冊中心

12、Dubbo的服務治理

  • 過多的服務URL，配置困難
  • 負載均衡分配節點壓力過大的情況下也需要部署集群
  • 服務依賴混亂，啟動順序不清晰
  • 過多服務導致性能指標分析難度較大，需要監控

13、Dubbo的註冊中心集群掛掉，發佈者和訂閱者之間還能通信麼

可以的，啟動Dubbo時，消費者會從Zookeeper拉取註冊的生產者的地址接口等數據，緩存在本地。

每次調用時，按照本地存儲的地址進行調用。

14、Dubbo與Spring的關系

Dubbo采用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，隻需用Spring加載Dubbo的配置即可，Dubbo基於Spring的Schema擴展進行加載。

15、Dubbo使用的是什麼通信框架

默認使用NIO Netty框架

16、Dubbo集群提供瞭哪些負載均衡策略

  • Random LoadBalance: 隨機選取提供者策略，有利於動態調整提供者權重。截面碰撞率高，調用次數越多，分佈越均勻
  • RoundRobin LoadBalance: 輪循選取提供者策略，平均分佈，但是存在請求累積的問題
  • LeastActive LoadBalance: 最少活躍調用策略，解決慢提供者接收更少的請求
  • ConstantHash LoadBalance: 一致性Hash策略，使相同參數請求總是發到同一提供者，一臺機器宕機，可以基於虛擬節點，分攤至其他提供者，避免引起提供者的劇烈變動

缺省值為Random隨機調用。

17、Dubbo的集群容錯方案

  • Failover Cluster：失敗自動切換，當出現失敗，重試其它服務器。通常用於讀操作，但重試會帶來更長延遲。
  • Failfast Cluster：快速失敗，隻發起一次調用，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。
  • Failsafe Cluster：失敗安全，出現異常時，直接忽略。通常用於寫入審計日志等操作。
  • Failback Cluster：失敗自動恢復，後臺記錄失敗請求，定時重發。通常用於消息通知操作。
  • Forking Cluster：並行調用多個服務器，隻要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks=”2″ 來設置最大並行數。
  • Broadcast Cluster：廣播調用所有提供者，逐個調用，任意一臺報錯則報錯 。通常用於通知所有提供者更新緩存或日志等本地資源信息。

18、Dubbo的默認集群容錯方案

Failover Cluster。

19、Dubbo支持哪些序列化方式

默認使用Hessian序列化，還有Duddo、FastJson、Java自帶序列化。

20、Dubbo超時時間怎樣設置

Dubbo超時時間設置有兩種方式：

  • 服務提供者端設置超時時間，在Dubbo的用戶文檔中，推薦如果能在服務端多配置就盡量多配置，因為服務提供者比消費者更清楚自己提供的服務特性。
  • 服務消費者端設置超時時間，如果在消費者端設置瞭超時時間，以消費者端為主，即優先級更高。因為服務調用方設置超時時間控制性更靈活。如果消費方超時，服務端線程不會定制，會產生警告。

21、服務調用超時問題

Dubbo在調用服務不成功時，默認是會重試兩次的。

22、Dubbo在安全機制方面是如何解決

Dubbo通過Token令牌防止用戶繞過註冊中心直連，然後在註冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的調用方。

23、Dubbo和DubboX之間的區別

DubboX基於Dubbo上做瞭一些擴展，如增加瞭服務可 restful 調用，更新瞭開源組件等。

24、除瞭Dubbo還有哪些分佈式框架

大傢熟知的就是Spring Cloud，當然國外也有類似的多個框架。

25、Dubbo和Spring Cloud的關系

Dubbo是SOA時代的產物，它的關註點主要在於服務的調用，流量分發、流量監控和熔斷。而Spring Cloud誕生於微服務架構時代，考慮的是微服務治理的方方面面。另外，由於依托瞭Spring、Spring Boot，兩個框架在開始目標就不一致，Dubbo定位於服務治理，而Spirng Cloud是一個生態。

26、Dubbo和Spring Cloud的區別

最大的區別：Dubbo底層是使用Netty這樣的NIO框架，是基於TCP協議傳輸的，配合以Hession序列化完成RPC通信。

而Spring Cloud是基於Http協議+Rest接口調用遠程過程的通信，相對來說，Http請求會有更大的報文，占用的帶寬也會更多。但是REST相比RPC更為靈活，服務提供方和調用方的依賴隻依靠一紙契約，不存在代碼級別的強依賴，這在強調快速演化的微服務環境下顯得更為合適。至於註重通信速度還是方便靈活性方面，具體情況具體考慮。

史上最強Dubbo面試28題答案詳解：核心功能+服務治理+架構設計等

27、例子

服務端

定義一個Service Interface：（HelloService.java）

package com.x.hello.api;
 
public interface HelloService
{
  String sayHello(String name);
}

接口的實現類：（HelloServiceImpl.java）

package com.x.hello.impl;
 
import com.x.hello.api.HelloService;
 
public class HelloServiceImpl implements HelloService {
    public String sayHello(String name){
        return "Hello" + name;
    }
}

Spring配置：（provider.xml）

<?xmlversion="1.0"encoding="UTF-8"?>
<beans>
    <!--Application name-->
    <dubbo:applicationname="hello-world-app"/>
    <!--registry address, used for service to register itself-->
    <dubbo:registryaddress="multicast://224.5.6.7:1234"/>
    <!--expose this service through dubbo protocol, through port 20880-->
    <dubbo:protocolname="dubbo" port="20880"/>
    <!--which service interface do we expose?-->
    <dubbo:serviceinterface="com.x.hello.api.HelloService" ref="helloService"/>
    <!--designate implementation-->
    <beanid="helloService" class="com.x.hello.impl.HelloServiceImpl"/>
</beans>

測試代碼：（Provider.java）

import org.springframework.context.support.ClassPathXmlApplicationContext;
 
public class Provider {
    public static void main(String[] args){
        // 啟動成功，監聽端口為20880
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(newString[]{"provider.xml"});
        // 按任意鍵退出
        System.in.read();
    }
}

客戶端

Spring配置文件：(consumer.xml)

<?xmlversion="1.0"encoding="UTF-8"?>
<beans>
    <!--consumer application name-->
    <dubbo:applicationname="consumer-of-helloworld-app"/>
    <!--registry address, used for consumer to discover services-->
    <dubbo:registryaddress="multicast://224.5.6.7:1234"/>
    <!--whichservicetoconsume?-->
    <dubbo:referenceid="helloService" interface="com.x.hello.api.HelloService"/>
</beans>

客戶端測試代碼：（Consumer.java）

import org.springframework.context.support.ClassPathXmlApplicationContext;
import com.alibaba.hello.api.HelloService;
 
public class Consumer {
    public static void main(String[] args) {
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(newString[]{"consumer.xml"});
        // Get service invocation proxy
        HelloService helloService =(HelloService)context.getBean("helloService");
        // Do invoke!
        String hello = helloService.sayHello("world");
        System.out.println(hello);
    }
}

到此這篇關於Java Dubbo框架知識點梳理的文章就介紹到這瞭,更多相關Java Dubbo知識梳理內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：