Dubbo Spring Cloud框架介紹、以及Dubbo與SpringCloud對比分析

最近在研究Dubbo和SpringCloud,網上查了查資料學習,這裏記錄一下

0、介紹

Dubbo

      https://github.com/apache/dubbo

      阿里巴巴在2011年開源了Dubbo框架,雖然在2013年停止更新,但在2017年9月又重啓維護併發布了新版本。目前已有很多的公  司將自己的業務建立在Dubbo之上,同時阿里雲也推出了企業級分佈式應用服務EDAS,爲Dubbo提供應用託管。

      Dubbo採用Zookeeper作爲註冊中心,RPC作爲服務調用方式,致力於提供高性能和透明化的RPC遠程服務調用方案。它與Spring無縫集成,基於服務提供方(服務端)與服務調用方(客戶端)角色構建簡單模型,其優點是使用方便、學習成本低。

Dubbo組件角色

 

Dubbo組件角色

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

調用關係說明:

  1. 服務容器Container負責啓動,加載,運行服務提供者。
  2. 服務提供者Provider在啓動時,向註冊中心註冊自己提供的服務。
  3. 服務消費者Consumer在啓動時,向註冊中心訂閱自己所需的服務。
  4. 註冊中心Registry返回服務提供者地址列表給消費者,如果有變更,註冊中心將基於長連接推送變更數據給消費者。
  5. 服務消費者Consumer,從提供者地址列表中,基於軟負載均衡算法,選一臺提供者進行調用,如果調用失敗,再選另一臺調用。
  6. 服務消費者Consumer和提供者Provider,在內存中累計調用次數和調用時間,定時每分鐘發送一次統計數據到監控中心Monitor。

一張帶有管理中心的組件關係圖

 

Dubbo總體架構

上面介紹給出的都是抽象層面的組件關係,可以說是縱向的以服務模型的組件分析,其實Dubbo最大的特點是按照分層的方式來架構,使用這種方式可以使各個層之間解耦合(或者最大限度地松耦合)。所以,我們橫向以分層的方式來看下Dubbo的架構,如圖所示:

Dubbo分層架構

 

Dubbo框架設計一共劃分了10個層,而最上面的Service層是留給實際想要使用Dubbo開發分佈式服務的開發者實現業務邏輯的接口層。圖中左邊淡藍背景的爲服務消費方使用的接口,右邊淡綠色背景的爲服務提供方使用的接口, 位於中軸線上的爲雙方都用到的接口。

下面,結合Dubbo官方文檔,我們分別理解一下框架分層架構中,各個層次的設計要點:

  1. 服務接口層(Service):與實際業務邏輯相關的,根據服務提供方和服務消費方的業務設計對應的接口和實現
  2. 配置層(Config):對外配置接口,以ServiceConfig和ReferenceConfig爲中心,可以直接new配置類,也可以通過Spring解析配置生成配置類。
  3. 服務代理層(Proxy):服務接口透明代理,生成服務的客戶端Stub和服務器端Skeleton,以ServiceProxy爲中心,擴展接口爲ProxyFactory。
  4. 服務註冊層(Registry):封裝服務地址的註冊與發現,以服務URL爲中心,擴展接口爲RegistryFactory、Registry和RegistryService。可能沒有服務註冊中心,此時服務提供方直接暴露服務。
  5. 集羣層(Cluster):封裝多個提供者的路由及負載均衡,並橋接註冊中心,以Invoker爲中心,擴展接口爲Cluster、Directory、Router和LoadBalance。將多個服務提供方組合爲一個服務提供方,實現對服務消費方來透明,只需要與一個服務提供方進行交互。
  6. 監控層(Monitor):RPC調用次數和調用時間監控,以Statistics爲中心,擴展接口爲MonitorFactory、Monitor和MonitorService。
  7. 遠程調用層(Protocol):封將RPC調用,以Invocation和Result爲中心,擴展接口爲Protocol、Invoker和Exporter。Protocol是服務域,它是Invoker暴露和引用的主功能入口,它負責Invoker的生命週期管理。Invoker是實體域,它是Dubbo的核心模型,其它模型都向它靠擾,或轉換成它,它代表一個可執行體,可向它發起invoke調用,它有可能是一個本地的實現,也可能是一個遠程的實現,也可能一個集羣實現。
  8. 信息交換層(Exchange):封裝請求響應模式,同步轉異步,以Request和Response爲中心,擴展接口爲Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
  9. 網絡傳輸層(Transport):抽象mina和netty爲統一接口,以Message爲中心,擴展接口爲Channel、Transporter、Client、Server和Codec。
  10. 數據序列化層(Serialize):可複用的一些工具,擴展接口爲Serialization、 ObjectInput、ObjectOutput和ThreadPool。

從上圖可以看出,Dubbo對於服務提供方和服務消費方,從框架的10層中分別提供了各自需要關心和擴展的接口,構建整個服務生態系統(服務提供方和服務消費方本身就是一個以服務爲中心的)

根據官方提供的,對於上述各層之間關係的描述,如下所示:

  1. 在RPC中,Protocol是核心層,也就是隻要有Protocol + Invoker + Exporter就可以完成非透明的RPC調用,然後在Invoker的主過程上Filter攔截點。
  2. 圖中的Consumer和Provider是抽象概念,只是想讓看圖者更直觀的瞭解哪些類分屬於客戶端與服務器端,不用Client和Server的原因是Dubbo在很多場景下都使用Provider、Consumer、Registry、Monitor劃分邏輯拓普節點,保持統一概念。
  3. 而Cluster是外圍概念,所以Cluster的目的是將多個Invoker僞裝成一個Invoker,這樣其它人只要關注Protocol層Invoker即可,加上Cluster或者去掉Cluster對其它層都不會造成影響,因爲只有一個提供者時,是不需要Cluster的。
  4. Proxy層封裝了所有接口的透明化代理,而在其它層都以Invoker爲中心,只有到了暴露給用戶使用時,才用Proxy將Invoker轉成接口,或將接口實現轉成Invoker,也就是去掉Proxy層RPC是可以Run的,只是不那麼透明,不那麼看起來像調本地服務一樣調遠程服務。
  5. 而Remoting實現是Dubbo協議的實現,如果你選擇RMI協議,整個Remoting都不會用上,Remoting內部再劃爲Transport傳輸層和Exchange信息交換層,Transport層只負責單向消息傳輸,是對Mina、Netty、Grizzly的抽象,它也可以擴展UDP傳輸,而Exchange層是在傳輸層之上封裝了Request-Response語義。
  6. Registry和Monitor實際上不算一層,而是一個獨立的節點,只是爲了全局概覽,用層的方式畫在一起。

4 服務調用流程

服務調用流程

 

Spring Cloud

Spring Cloud基於Spring Boot實現,使用HTTP的RESTful風格API作爲調用方式。它所包含的多個子項目共同構建了微服務架構體系。

 

1、SpringBoot對比SpringCloud

SpringBoot專注於快速開發單個微服務。

SpringCloud是關注全局的微服務協調框架,它將SpringBoot開發的單個微服務整合管理,併爲微服務之間提供,配置管理、服務發現、斷路器、路由網關等集成服務,SpringCloud依賴SpringBoot。

2、Dubbo對比SpringCloud

2.1、調用方式對比

服務調用方式是 Dubbo 和 Spring Cloud 重要不同點,熟悉RPC/HTTP/REST概念,有助對比 Dubbo 和SpringCloud。

RPC 是遠端過程調用,其調用協議通常包含傳輸協議和編碼協議。RPC調用是面向服務的封裝,針對服務的可用性和效率等都做了優化。

http是超文本傳輸協議,RPC 也可以用http作爲傳輸協議,但一般是用 tcp作爲傳輸協議。

2.2、執行性能對比

Dubbo 採用單一長連接和NIO異步通訊(保持連接/輪詢處理),使用自定義報文的TCP協議,並且序列化使用定製Hessian2框架,適合於小數據量大併發的服務調用,以及服務消費者機器數遠大於服務提供者機器數的情況,但不適用於傳輸大數據的服務調用。

Spring Cloud 直接使用 HTTP 協議,在性能上弱於Dubbo。

2.3、註冊中心對比

這裏通常指ZooKeeper(Dubbo註冊中心)和Eureka(Cloud註冊中心)的對比。

分佈式領域著名的CAP理論(C:數據一致性,A:服務可用性,P:分區故障的容錯性),Zookeeper保證的是CP,但對於服務發現而言,可用性比數據一致性更加重要,AP勝過CP,而 Eureka 設計則遵循 AP 原則。

2.4、框架生態對比

      可能說起來Dubbo,很多人都不陌生,這畢竟是一款從2012年就開始開源的Java RPC框架,中間由於各種各樣的原因停止更新4年半的時間,中間只發過一個小版本修了一個小bug,甚至大家都以爲這個項目已經死掉了,竟然又在2017年9月份恢復了更新,不可謂不神奇。

      網絡上很多人都拿Dubbo和Spring Cloud做對比,可能在大家的心目中,這兩個框架是可以畫上等號的吧,後來在網絡上有一個非常流行的表格,比較詳細的對比了 Spring Cloud 和 Dubbo ,表格如下:

  Dubbo SpringCloud
服務註冊中心 Zookeeper  Spring Cloud Netfix Eureka
服務調用方式 RPC  REST API
服務監控 Dubbo-monitor Spring Boot Admin
熔斷器 不完善 Spring Cloud Netflix Hystrix
服務網關 Spring Cloud Netflix Zuul
分佈式配置 Spring Cloud Config
服務跟蹤 Spring Cloud Sleuth
數據流 Spring Cloud Stream
批量任務 Spring Cloud Task
信息總線 Spring Cloud Bus

Dubbo 專注 RPC 和服務治理,Spring Cloud 則是一個微服務架構生態。

 

      以上列舉了一些核心部件,當然這裏需要申明一點,Dubbo對於上表中總結爲“無”的組件不代表不能實現,而只是Dubbo框架自身不提供,需要另外整合以實現對應的功能,這樣看起來確實Dubbo更像是Spring Cloud的一個子集。

      Dubbo 在國內擁有着巨大的用戶羣,大家希望在使用 Dubbo 的同時享受 Spring Cloud 的生態,出現各種各樣的整合方案,但是因爲服務中心的不同,各種整合方案並不是那麼自然,直到 Spring Cloud Alibaba 這個項目出現,由官方提供了 Nacos 服務註冊  中心後,纔將這個問題完美的解決。並且提供了 Dubbo 和 Spring Cloud 整合的方案,命名爲: Dubbo Spring Cloud 。

      ​Spring Cloud擁有很多的項目模塊,包含了微服務系統的方方面面。Dubbo是一個非常優秀的服務治理和服務調用框架,但缺少很多功能模塊,例如網關、鏈路追蹤等。在項目模塊上,Spring Cloud佔據着更大的優勢。

      Spring Cloud的更新速度非常塊,Camden.SR5版本發佈於2017年2月6日,Camden.SR6版本發佈於2017年3月10日,Dalston版本發佈於2017年4月12日,基本每個月會發一次版本的迭代。從GitHub的代碼倉庫來看,Spring Cloud幾乎每天都有更新。阿里巴巴於2011年10月開源了Dubbo,開源後的Dubbo發展迅速,大概每2~3個月有一次版本更新。然而,從在2013年3月開始,Dubbo暫停了版本更新,並只在2014年10月發佈了一個小版本,修復了一個bug,之後長期處於版本停止更新的狀態。直到2017年9月,阿里巴巴中間件部門重新組建了Dubbo團隊,把Dubbo列爲重點開源項目,並在2017年9~11月期間,一直保持每月一次版本更新的頻率。

      從學習成本上考慮,Dubbo的版本趨於穩定,文檔完善,可以即學即用,沒有太大難度。Spring Cloud 基於Spring Boot開發,需要開發者先學會Spring Boot。另外,Spring Cloud版本迭代快,需要快速跟進學習。Spring Cloud文檔大多是英文的,要求學習者有一定的英文閱讀能力。此外,Spring Cloud文檔很多,不容易快速找到相應的文檔。

      從開發風格上來講,Dubbo 更傾向於Spring Xml的配置方式,Dubbo官方也推薦這種方式。Spring Cloud基於Spring Boot,Spring Boot採用的是基於註解和JavaBean配置方式的敏捷開發。從開發速度上講,Spring Cloud具有更高的開發和部署速度

       最後,Spring Cloud 的通信方式大多數是基於HTTP Restful風格的,服務與服務之間完全無關、無耦合。由於採用的是HTTP Rest,因此服務無關乎語言和平臺,只需要提供相應API接口,就可以相互調用。Dubbo 的通信方式基於遠程調用,對接口、平臺和語言有強依賴性。如果需要實現跨平臺調用服務,需要寫額外的中間件,這也是Dubbo存在的原因。

       Dubbo和Spring Cloud擁有各自的優缺點。Dubbo更易上手,並且廣泛使用於阿里巴巴的各大站點,經歷了“雙11”期間高併發、大流量的檢驗,Dubbo框架非常成熟和穩定。Spring Cloud服務框架嚴格遵守Martin Fowler 提出的微服務規範,社區異常活躍,它很可能成爲微服務架構的標準。

3、Dubbo Spring Cloud介紹

3.1 Dubbo Spring Cloud 概述

      Dubbo Spring Cloud 構建在原生的 Spring Cloud 之上,其服務治理方面的能力可認爲是 Spring Cloud Plus, 不僅完全覆蓋 Spring Cloud 原生特性,而且提供更爲穩定和成熟的實現,特性比對如下表所示:

功能組件 Spring Cloud Dubbo Spring Cloud
分佈式配置(Distributed configuration) Git、Zookeeper、Consul、JDBC Spring Cloud 分佈式配置 + Dubbo 配置中心
服務註冊與發現(Service registration and discovery) Eureka、Zookeeper、Consul Spring Cloud 原生註冊中心 + Dubbo 原生註冊中心
負載均衡(Load balancing) Ribbon(隨機、輪詢等算法) Dubbo 內建實現(隨機、輪詢等算法 + 權重等特性)
服務熔斷(Circuit Breakers) Spring Cloud Hystrix Spring Cloud Hystrix + Alibaba Sentinel 等
服務調用(Service-to-service calls) Open Feign、RestTemplate Spring Cloud 服務調用 + Dubbo @Reference
鏈路跟蹤(Tracing) Spring Cloud Sleuth + Zipkin Zipkin、opentracing 等

      以上對比表格摘自Dubbo Spring Cloud官方文檔。

      而且Dubbo Spring Cloud 基於 Dubbo Spring Boot 2.7.1 和 Spring Cloud 2.x 開發,無論開發人員是 Dubbo 用戶還是 Spring Cloud 用戶, 都能輕鬆地駕馭,並以接近“零”成本的代價使應用向上遷移。Dubbo Spring Cloud 致力於簡化雲原生開發成本,以達成提高研發效能以及提升應用性能等目的。

3.2 Dubbo Spring Cloud 主要特性

  • 面向接口代理的高性能RPC調用:提供高性能的基於代理的遠程調用能力,服務以接口爲粒度,屏蔽了遠程調用底層細節。
  • 智能負載均衡:內置多種負載均衡策略,智能感知下游節點健康狀況,顯著減少調用延遲,提高系統吞吐量。
  • 服務自動註冊與發現:支持多種註冊中心服務,服務實例上下線實時感知。
  • 高度可擴展能力:遵循微內核+插件的設計原則,所有核心能力如Protocol、Transport、Serialization被設計爲擴展點,平等對待內置實現和第三方實現。
  • 運行期流量調度:內置條件、腳本等路由策略,通過配置不同的路由規則,輕鬆實現灰度發佈,同機房優先等功能。
  • 可視化的服務治理與運維:提供豐富服務治理、運維工具:隨時查詢服務元數據、服務健康狀態及調用統計,實時下發路由策略、調整配置參數。

3.3 Spring Cloud 爲什麼需要RPC

      在Spring Cloud構建的微服務系統中,大多數的開發者使用都是官方提供的Feign組件來進行內部服務通信,這種聲明式的HTTP客戶端使用起來非常的簡潔、方便、優雅,但是有一點,在使用Feign消費服務的時候,相比較Dubbo這種RPC框架而言,性能堪憂。

      雖說在微服務架構中,會講按照業務劃分的微服務獨立部署,並且運行在各自的進程中。微服務之間的通信更加傾向於使用HTTP這種簡答的通信機制,大多數情況都會使用REST API。這種通信方式非常的簡潔高效,並且和開發平臺、語言無關,但是通常情況下,HTTP並不會開啓KeepAlive功能,即當前連接爲短連接,短連接的缺點是每次請求都需要建立TCP連接,這使得其效率變的相當低下。

      對外部提供REST API服務是一件非常好的事情,但是如果內部調用也是使用HTTP調用方式,就會顯得顯得性能低下,Spring Cloud默認使用的Feign組件進行內部服務調用就是使用的HTTP協議進行調用,這時,我們如果內部服務使用RPC調用,對外使用REST API,將會是一個非常不錯的選擇,恰巧,Dubbo Spring Cloud給了我們這種選擇的實現方式。

3.4 實戰

本小結將會以一個簡單的入門案例,介紹一下在使用Nacos作爲服務中心,使用Dubbo來實現服務提供方和服務消費方的案例。

Nacos的安裝、部署配置和使用已經在前面的章節介紹過了,這裏不再贅述,如果還有不清楚的讀者,請參考前面的Nacos系列文章:

《Spring Cloud Alibaba | Nacos服務中心初探》

《Spring Cloud Alibaba | Nacos服務註冊與發現》

《Spring Cloud Alibaba | Nacos集羣部署》

《Spring Cloud Alibaba | Nacos配置管理》

3.4.1 創建父工程 dubbo-spring-cloud-demo

父工程依賴pom.xml如下:

代碼清單:Alibaba/dubbo-spring-cloud-demo/pom.xml


<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>${spring-cloud-alibaba.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <!-- Dubbo Spring Cloud Starter -->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-dubbo</artifactId>
    </dependency>
    <!-- Spring Cloud Nacos Service Discovery -->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>

    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

注意:

  1. 必須包含spring-boot-starter-actuator包,不然啓動會報錯。

  2. spring-cloud-starter-dubbo包需要注意groupId,根據具體使用的spring cloud alibaba版本依賴來確定。

    • 如果使用孵化版本,使用的groupId爲:org.springframework.cloud
    • 如果使用畢業版本,使用的groupId爲:com.alibaba.cloud
  3. 以上引用未指定版本,需顯示的聲明<dependencyManagement>

3.4.2 創建子工程 dubbo_api

      API模塊,存放Dubbo服務接口和模型定義,非必要,這裏創建僅爲更好的代碼重用以及接口、模型規格控制管理。

定義抽象接口HelloService.java:

代碼清單:Alibaba/dubbo-spring-cloud-demo/dubbo_api/src/main/java/com/springcloud/dubbo_api/service/HelloService.java


public interface HelloService {
    String hello(String name);
}

3.4.3 創建子工程 dubbo_provider ,Dubbo服務提供方

工程依賴pom.xml如下:

代碼清單:Alibaba/dubbo-spring-cloud-demo/dubbo_provider/pom.xml


<!-- API -->
<dependency>
    <groupId>com.springcloud.book</groupId>
    <artifactId>ch13_1_dubbo_api</artifactId>
    <version>${project.version}</version>
</dependency>

此處引入公共API模塊。

實現Dubbo接口,HelloServiceI.java如下:

代碼清單:Alibaba/dubbo-spring-cloud-demo/dubbo_provider/src/main/java/com/springcloud/dubbo_provider/service/HelloServiceI.java


@Service
public class HelloServiceI implements HelloService {
    @Override
    public String hello(String name) {
        return "Hello " + name;
    }
}

注意:這裏的@Service註解並不是來自Spring的org.springframework.stereotype.Service,而是Dubbo的org.apache.dubbo.config.annotation.Service,千萬不要引用錯誤。這裏的@Service註解僅聲明該Java服務(本地)實現爲Dubbo服務。

配置文件 application.yml 需要將Java服務(本地)配置爲 Dubbo 服務(遠程)如下:

代碼清單:Alibaba/dubbo-spring-cloud-demo/dubbo_provider/src/main/resources/application.yml


server:
port: 8000
dubbo:
    scan:
        base-packages: com.springcloud.book.ch13_1_dubbo_provider.service
protocol:
    name: dubbo
    port: -1
registry:
    address: spring-cloud://192.168.44.129
spring:
application:
    name: dubbo-spring-cloud-provider
cloud:
    nacos:
    discovery:
        server-addr: 192.168.44.129:8848
main:
    allow-bean-definition-overriding: true

注意:在暴露Dubbo服務方面,推薦使用外部化配置的方式,即指定Java服務實現類的掃描基準包。

Dubbo Spring Cloud 繼承了 Dubbo Spring Boot 的外部化配置特性,也可以通過標註 @DubboComponentScan 來實現基準包掃描。

  • dubbo.scan.base-packages:指定 Dubbo 服務實現類的掃描基準包
  • dubbo.protocol:Dubbo服務暴露的協議配置,其中子屬性name爲協議名稱,port爲協議端口(-1 表示自增端口,從 20880 開始)
  • dubbo.registry:Dubbo 服務註冊中心配置,其中子屬性address 的值 "spring-cloud://192.168.44.129",說明掛載到 Spring Cloud 註冊中心
  • spring.application.name:Spring 應用名稱,用於 Spring Cloud 服務註冊和發現。該值在 Dubbo Spring Cloud 加持下被視作dubbo.application.name,因此,無需再顯示地配置dubbo.application.name
  • spring.main.allow-bean-definition-overriding:在 Spring Boot 2.1 以及更高的版本增加該設定,因爲 Spring Boot 默認調整了 Bean 定義覆蓋行爲。
  • spring.cloud.nacos.discovery:Nacos 服務發現與註冊配置,其中子屬性 server-addr 指定 Nacos 服務器主機和端口。

創建應用主類Ch131DubboProviderApplication.java:

代碼清單:Alibaba/dubbo-spring-cloud-demo/dubbo_provider/src/main/java/com/springcloud/dubbo_provider/DubboProviderApplication.java


@SpringBootApplication
@EnableDiscoveryClient
public class DubboProviderApplication {

    public static void main(String[] args) {
        SpringApplication.run(DubboProviderApplication.class, args);
    }

}

3.4.4 創建子工程 dubbo_consumer ,服務調用方:

工程依賴pom.xml如下:

代碼清單:Alibaba/dubbo-spring-cloud-demo/dubbo_consumer/pom.xml


<!-- API -->
<dependency>
    <groupId>com.springcloud.book</groupId>
    <artifactId>ch13_1_dubbo_api</artifactId>
    <version>${project.version}</version>
</dependency>

工程配置application.yml如下:

代碼清單:Alibaba/dubbo-spring-cloud-demo/dubbo_consumer/src/main/resources/application.yml


server:
port: 8080
dubbo:
protocol:
    name: dubbo
    port: -1
registry:
    address: spring-cloud://192.168.44.129
cloud:
    subscribed-services: dubbo-spring-cloud-provider
spring:
application:
    name: dubbo-spring-cloud-consumer
cloud:
    nacos:
    discovery:
        server-addr: 192.168.44.129:8848
main:
    allow-bean-definition-overriding: true
  • dubbo.cloud.subscribed-services:表示要訂閱服務的服務名,可以配置'*',代表訂閱所有服務,不推薦使用。若需訂閱多應用,使用 "," 分割。

測試接口HelloController.java如下:

代碼清單:Alibaba/dubbo-spring-cloud-demo/dubbo_consumer/src/main/java/com/springcloud/dubbo_consumer/controller/HelloController.java


@RestController
public class HelloController {
    @Reference
    private HelloService helloService;

    @GetMapping("/hello")
    public String hello() {
        return helloService.hello("Dubbo!");
    }
}

注意:這裏的@Reference註解是org.apache.dubbo.config.annotation.Reference

啓動主類Ch131DubboConsumerApplication.java如下:

代碼清單:Alibaba/dubbo-spring-cloud-demo/dubbo_consumer/src/main/java/com/springcloud/dubbo_consumer/DubboConsumerApplication.java


@SpringBootApplication
@EnableDiscoveryClient
public class DubboConsumerApplication {

    public static void main(String[] args) {
        SpringApplication.run(DubboConsumerApplication.class, args);
    }

}

3.4.5 測試

啓動子工程 dubbo_provider 和子工程 dubbo_consumer ,啓動完成後,我們可以訪問Nacos控制檯的服務列表上看到兩個服務,如圖:

 

我們打開瀏覽器訪問:http://localhost:8080/hello ,可以看到頁面正常顯示Hello Dubbo!,測試成功,如圖:

 

4、示例代碼

https://github.com/apache/dubbo-spring-boot-project

https://github.com/cicadasmile/spring-cloud-base

https://github.com/meteor1993/SpringCloudLearning/tree/master/Alibaba/dubbo-spring-cloud-demo

https://github.com/cicadasmile/spring-cloud-base
 

5、參考:

https://juejin.im/post/5d82cf94e51d45620821cf92

https://mp.weixin.qq.com/s/RC8F_D1J75XEv7oR7xdK5Q

https://zhuanlan.zhihu.com/p/36182136

https://juejin.im/post/5ab09943f265da238f125ee8

http://shiyanjun.cn/archives/325.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章