前言：剛完成的Spring基礎專題本想更新原始碼的，但是發現分布式非常火，而我喜歡玩這個，所以今年我希望把我的知識可以分享給正在奮斗中的互

聯網開發人員，以及未來想往架構師上走的道友們我們一起進步，從一個互聯網職場小白到一個滬漂濕人，一路讓我知道分享是一件多么重要的事

情，總之不對的地方，多多指出，我們一起徜徉代碼的海洋！

我這里做每個章節去說的前提，不是一定很標準的套用一些官方名詞，目的是為了讓大家可以理解更加清楚，如果形容的不恰當，可以留言出來，萬

分感激！

1、Dubbo整合SpringBoot

在上一節我們用傳統的Spring案例，結合官網，簡單介紹了Dubbo對應不同的服務怎么進行發布，以及注冊中心Zookeeper的使用，當然我這里是為了演示效果，根據官網的極力推薦，使用的注冊中心是Zookeeper，實際上Zookeeper的功能遠遠不止這些，而在

市面上的注冊中心有很多種，比如Zookeeper，Nacos，Simple，Multicast和Redis等等，你沒想過Redis可以做注冊中心吧，當然市面上用的比較少，還有Netflix系的SpringCloud Eureka等等，其實這些都是為了做服務治理的第一步，

那么本章開始，帶你走進SpringBoot微服務化的Dubbo案例，里面很多干貨，都是在實戰中會用到的，里面不會涉及到很多業務代碼，微服務的本質是運維！！說三遍，運維，所以應該更注重服務之間的關系，和遇到各種問題應該具備的解決方案！在實戰中

都值得一試！

準備環境：

我們設定兩個服務：

• user-service-provider
• order-service-consumer

一個api介面層

• api-service：這個用上一節的專案

新建一個Springboot專案，我就很簡單過兩個圖，不會的要百度下了，

然后

下一步后

好了，我把上個專案中的代碼都拷過來，創建兩個服務的最終效果是這樣的

兩個服務的pom檔案別忘記加上這個api-service，之前一定要install到本地！！

<dependency>
    <groupId>com.chenxin.dubbo</groupId>
    <artifactId>api-service</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

那么此時我們兩個服務就創建好了，那么我們要改造下，既然是Springboot專案，就需要有Controller請求層，模擬一個請求去請求user-service-provider的業務方法，

新建一個OrderController，負責呼叫用戶服務，回傳用戶id對應的地址，

是不是發現少了什么，對，pom檔案里的依賴沒進來，上節我們的依賴是純Dubbo，是這樣的

但是我們已經轉成了Springboot專案了，場景驅動器會幫我們做自動裝配的，所以我們只需要引入dubbo和springboot的starter就可以

注意下自己的Springboot版本，我的是2.x版本的，對照下圖看看

    <dependency>
            <groupId>com.alibaba.boot</groupId>
            <artifactId>dubbo-spring-boot-starter</artifactId>
            <version>0.2.0</version>
        </dependency>

其實你匯入這個依賴你會發現一個東西，這個starter已經把上節我們需要的zk依賴，監控等依賴都帶進來了，

這樣是不是就可以啟動了呢？當然不是，我們上一節的組態檔，怎么辦，怎么整合到Springboot專案中來呢？

當然有辦法，看官網：

取而代之的是用application.properties里面的key，value來替代xml的標簽，這個我在講Spring的時候經常提到

所以我們在user-service-provider中的properties檔案重要這么配置，我特地做了對比，可以看看其實和組態檔沒什么區別，

dubbo.application.name=user-service-provider
    <!-- 提供方應用資訊，用于計算依賴關系 -->
    <dubbo:application name="gmall-user"  />

dubbo.registry.address=127.0.0.1:2181
dubbo.registry.protocol=zookeeper
    <!-- 使用zookeeper注冊中心暴露服務地址 -->
    <dubbo:registry protocol="zookeeper" address="127.0.0.1:2181" />


dubbo.protocol.name=dubbo
dubbo.protocol.port=20880
    <!-- 用dubbo協議在20880埠暴露服務 -->
    <dubbo:protocol name="dubbo" port="20880" />

那么對于暴露的服務，我們xml中是這么寫的

    <!-- 宣告需要暴露的服務介面 -->
    <dubbo:service interface="com.chenxin.dubbo.service.UserService" ref="userService" />

如果很多介面需要暴露的話，這個量就上來了，所以dubbo為我們提供了注解，叫做@Service

不再是Spring的注解@Service

import org.springframework.stereotype.Service;

而是

import com.alibaba.dubbo.config.annotation.Service;

這里要注意！

所以暴露的介面上需要加上@Service注解

然后我們要啟動前，在主啟動類上加上一個@EnableDubbo這個注解，表示開啟基于注解的Dubbo

記得要本地啟動zk和dubbo-admin，不然你看不到效果，本地訪問localhost:7001就可以了，此時，生產者我們已經成功注冊到zk上了，接下來消費者order-service也要注冊上去并且去訂閱生產者

消費者也是一樣，這么幾步：

1、依賴引進來

    <dependency>
            <groupId>com.alibaba.boot</groupId>
            <artifactId>dubbo-spring-boot-starter</artifactId>
            <version>0.2.0</version>
        </dependency>

2、配置properties檔案，用戶服務默認走8080，所以你這里要宣告下埠別沖突了

server.port=8081
dubbo.application.name=order-service-consumer
dubbo.registry.address=127.0.0.1:2181
dubbo.registry.protocol=zookeeper

dubbo.protocol.name=dubbo
dubbo.protocol.port=20880

3、參考的地方從@Autowired改成@Reference，@Service改成Dubbo的包

4、主啟動類上加上注解@EnableDubbo

來測驗下介面localhost:8081/initOrder/1，很明顯已經呼叫成功了，

到這里，其實整合Springboot已經完成，我這邊要詳細的介紹一些注意事項：

1、對于覆寫策略

dubbo官網給出了啟動時候的覆寫策略：

啟動時候的引數 覆寫 外部配置的引數，這個外部配置，你理解為目的是實作配置的集中式管理：比如目前有很多主流的配置中心，

這部分業界已經有很多成熟的專業配置系統如 Apollo, Nacos 等，Dubbo 所做的主要是保證能配合這些系統正常作業，

外部化配置和其他本地配置在內容和格式上并無區別，可以簡單理解為 dubbo.properties 的外部化存盤，配置中心更適合將一些公共配置如注冊中心、元資料中心配置等抽取以便做集中管理，

而外部配置引數 覆寫 代碼的api設定的引數

代碼的api設定引數 覆寫 本地的properties組態檔，這個是很重要的，優先級是從上到下

這個場景會經常使用到，尤其是上配置中心的時候，是非常有用的，

2、啟動時檢查

Dubbo 預設會在啟動時檢查依賴的服務是否可用，不可用時會拋出例外，阻止 Spring 初始化完成，以便上線時，能及早發現問題，默認 check="true"，

比如你生產者在啟動了很久一段時間，然后啟動消費者，這個時候偶發的會爆出消費者找不到服務，或者生產者沒有啟動，直接啟動消費者，也會報錯，我演示下只啟動order-service-consumer這個服務

為什么要說這個呢，因為目前我演示的是消費者呼叫生產者，是單向的，但是在實際專案中，雙向呼叫是很正常的事情，那就涉及到回圈依賴，比如我用戶服務要呼叫訂單服務的介面，而訂單服務也要呼叫用戶服務的介面

這樣就產生了雙向依賴關系，在任何一方啟動都會先檢查另一方有沒有正常啟動，所以都會拋出例外，這樣的場景，為了不想這些例外資訊不斷發生影響服務的判斷，我可以設定啟動的時候關閉檢查，設定check的值為false；

這樣啟動的時候就不會報錯，而在呼叫具體的服務的時候，才會去檢查是否有相關介面被暴露在注冊中心上，從而再拋出例外，

還有一點，如果你的 Spring 容器是懶加載的，或者通過 API 編程延遲參考服務，請關閉 check，也就是設定check=false，啟動的時候不檢查，因為Spring容器都已經懶加載了，不會在創建工廠的時候初始化bean，創建bean物件；

如果你設定為true，會導致本服務臨時不可用時，因為啟動的時候檢查，檢查啥呢，Spring容器都沒初始化物件出來，所以你的服務會拋出例外，拿到 null 參考；

如果 check="false"，總是會回傳參考，不為空，當服務恢復時，能自動連上，

所以對于某個介面來說的話，我們基于組態檔的方式，對于消費者方，在啟動的時候先不檢查userService是否可用，可以這么設定

<dubbo:reference id="userService" check="false" interface="com.chenxin.dubbo.service.UserService"/>

那么注解版的話，直接在@Reference注解里有個屬性叫做check，置位false即可！！

如果我想全域設定統一規則，只需要在你的properties設定這個

dubbo.consumer.check=false 表示消費者在啟動的時候，都不去檢查生產者是否可用，防止回圈依賴的影響，

此外，我們只是說了啟動的時候不檢查，那么如果消費者啟動的時候，檢查注冊中心是否存在呢？消費者一定也是要訂閱注冊中心的，先存在注冊中心，進而去檢查服務是否存在，所以對于注冊中心也是一樣

如果不希望在服務啟動時候，因為注冊中心沒啟動而報錯，我們可以設定這個屬性

dubbo.registry.check=false

說明啟動的時候不檢查注冊中心，等注冊中心服務啟動的時候，再去訂閱，

3、超時策略

超時策略指的是服務的消費方在參考服務的提供方時，可能因為網路的原因，或者服務的提供者執行一個方法要很長的時間，很長時間沒有回傳，會導致大量的執行緒被阻塞在呼叫服務方上，會出現一些性能例外，

為了防止這個問題的不斷發生，我可以指定呼叫這個方法的超時時間，還是以上面的為例子，訂單服務要呼叫用戶服務，假設UserService資料回傳的時間是3s，那么就需要在呼叫的時候，配置上這個屬性time=xxxxx，單位是毫秒

超時是有個默認值，這個預設值是1000ms，有人說你怎么知道，還是看官網：

默認使用的是dubbo consumer的timeout，再看看dubbo consumer這個標簽

很明顯，的確是1000ms

所以可以試驗下，我在提供方執行緒休眠個4s，而呼叫方給個3s后超時，看看會不會有例外，

很明顯我在生產者執行緒休眠了4s后，消費者3s超時，結果報錯超時，現象在生產中，會經常出現這個問題，合理選擇一個好的超時時間是有效的，

但是在實際生產中，我會發現有很多的老專案用dubbo的時候，更多會采用組態檔的方式，那么可能這里設定了一個超時，那邊又設定了一個方法級別的超時，或者全域超時，哪里的會被覆寫，或者是優先生效呢？

后面的例子我以組態檔的方式演示，不以Springboot的方式，原因很簡單，xml你懂了，注解的方式你自然就很明確！

比如說，我在消費端設定了UserService的呼叫超時時間，為5s，而在提供方我設定執行緒休眠4s，很明顯這個是呼叫成功的對吧，

但是dubbo是可以支持介面方法級別的超時時間：

<dubbo:reference id="userService" check="false" timeout="5000" interface="com.chenxin.dubbo.service.UserService">
    <dubbo:method name="getUserAddressList" timeout="1000"></dubbo:method>
</dubbo:reference>

此時我設定方法getUserAddressList的超時時間為1s，那么是外層5s生效呢，還是內層方法1s的生效呢？

很明顯報錯了，思考下也知道，肯定是方法級別優先，介面次之，因為都已經精確到方法了，你介面生效的話，方法設了還有啥用嗎，對吧，

看官網的解釋：

• 方法級別優先，介面次之，全域再次之
• 級別一樣的話，消費者優先，提供者次之

那級別一樣，消費者優先是什么意思呢？

舉個例子，提供者提供介面，設定超時時間是2s，而同級別的消費者消費這個介面，超時設定5s，是哪邊生效？

運行看下，很明顯是消費者優先生效！！！

那上面兩種情況我都已經做了解釋，下面我設定一種情況，你們看看是什么優先，

假設我提供者設定了方法級別的超時時間，而消費者設定了介面級別的超時時間

這是提供方暴露介面，方法級別的超時時間為2s

這是消費方，介面級別的超時，5s

運行看下，結果其實是提供者方法級別的超時時間優先，

因為此時級別不一樣，級別一樣的時候，消費者才優先，級別不一樣，那么還是生產者優先

所以我再總結下：

• 方法級別優先，介面次之，全域再次之
• 級別一樣的話，消費者優先，提供者次之
• 級別不一樣，提供者優先，消費者次之

感興趣下去可以驗證下！！

4、重試次數

當我們在開發中某個服務由于各種原因，比如網路不佳，或者運行緩慢，導致了超時，消費者遠程呼叫方法失敗，我們可以通過調整重試次數，讓消費者多試幾次

這個重試次數，不包含第一次，比如我基于上述的代碼，在消費者這邊寫了個重試次數retries=3，那么會額外重試3次，直到成功，所以最多會試4次！！！

提供方代碼是：因為提供方超時設定優先，所以這個一定會超時，我們看下重試的驗證

結果發現，日志里面重試了4次！！！

在實際的生產環境中，如果你的提供方有多臺服務在不同的機子上，那么會重試輪詢不同的機器，我模擬下：

1、改提供方的埠20881，并且添加實作類的日志，表明模擬呼叫不同的服務，然后啟動main函式

2、改提供方的埠20882，并且添加實作類的日志，表明模擬呼叫不同的服務，然后啟動main函式

然后idea啟動三個main函式，等于模擬了三個服務提供方，看看監控中心，已經啟動三個服務，

啟動消費端試試

所以一共是4次，多個服務會以輪詢的方式進行重試，

先是UserServiceImpl.....1....發現超時，然后開始輪巡UserServiceImpl....2....發現也是超時，于是輪巡UserServiceImpl...3....也超時，于是最后一次又回來從UserServiceImpl....1....開始，以此下去，所以解釋為什么UserServiceImpl...1....會執行2次了吧，

這里要注意下，我們設定重試次數一定要在介面冪等的情況下設定重試次數

什么是介面冪等性，意思就是方法無論執行多少次，結果都是一樣的，比如查詢，我帶個條件查，無論查多少次，結果都是一樣的，比如洗掉，我洗掉一次了，洗掉成功，洗掉第二次也是一樣回傳洗掉成功，因為第一次已經洗掉過了，

比如修改，修改一次，和修改多次，結果都是一樣的，因為你每次都是執行同一個方法，帶同樣的引數，

但是非冪等性的話，就不能設定重試次數了，比如插入資料，每次插入都會產生新的效果，如果第一次超時了 ，雖然是超時，但是資料庫已經拿到這個新增的請求了，那么就會去新增資料，而消費方等不及了，開始重試，又插入一條資料；

所以以后在設計分布式系統的時候，這介面的冪等性要注意，

所以對于新增，我們不想做重試，就應該設定retries=0！！！

5、多版本

當一個介面實作，出現不兼容升級時，可以用版本號過渡，版本號不同的服務相互間不參考，

什么意思呢，就是你某個介面實作修改了，也就是某些業務修改了，那么生怕上線的時候，萬一這程式員寫的bug太多，影響了整體的功能，這就很操蛋，于是我們可以讓用戶使用一部分先上線的版本功能，老的不變，具體來說

可以按照以下的步驟進行版本遷移：

1. 在低壓力時間段，先升級一半的提供者為新版本，讓一半的新版本先試用看看有沒有問題
2. 然后過段時間，再將所有消費者升級為新版本，開始全部呼叫新的實作類，新的功能
3. 最后將剩下的一半提供者升級為新版本

這樣就有效的預防級聯的問題，

現在我把所有的服務都停掉，我多寫一個UserServiceImpl2，其實和UserServiceImpl1一樣，只是輸出不一樣

提供方埠恢復成20880，并且暴露服務添加版本號

這時候消費者指定版本號為1.0.0

然后啟動提供者和消費者后，日志列印

說明此時消費者呼叫的是老版本，同樣你version設定新版本，那么就會呼叫新版本的介面，

其實這就是灰度發布！！！

6、本地存根

用官網的圖：因為介面的實作都在服務端，有時候不一定所有的代碼都一定要通過遠程呼叫去執行，有時候也希望本地可以先做點事情，再選擇去調不呼叫遠程的服務，比如我要引數驗證通過了，再去呼叫遠程服務，于是本地存根就有用武之地了，

我們要在UserService介面寫個消費端的實作類叫做UserServiceStub，實作了UserService，與此同時，Dubbo會在消費端會生產一個代理的實體物件，這個代理物件我們是看不到的（基于動態代理創建的），假設叫做UserServiceProxy，把這個代理物件，通

過UserServiceStub的構造方法傳入進來，進行你的引數校驗等等操作，驗證是否成功了后，你再選擇去不去呼叫遠程的服務UserServiceImpl，

‘

所以我們在消費端寫個類，比如我要先本地判斷下引數是否合法！

然后寫完后記得要配置消費端，先走下本地存根，

然后啟動消費者看看本地存根有沒有被呼叫成功！很明顯已經呼叫了，

那么本節就整理了通過xml的方式，進行Dubbo的很多基礎點的配置，下一節我們繼續分享Dubbo是如何暴露本地服務以及高可用的程序的！！！敬請期待，，