前言

昨天我們分享了dubbo的後臺管理控制檯，簡單介紹了它的基本用法，同時我也發現了自己在dubbo方面知識點的缺失，所以從今天開始，我們就開始學習dubbo的進階知識點，然後逐步掃清dubbo的知識盲區。

今天我們要分享的內容主要有兩個，一個是對之前配置內容的補充，一個就是dubbo負載均衡方面的基礎知識。好了，讓我們直接開始吧。

配置補充

首先，先看配置的補充。週五的時候，我們補充了一些關於dubbo配置的相關知識點，介紹了註解式配置dubbo，但是在今天進行dubbo負載均衡的時候，發現在註冊多個服務提供者的時候，一直報埠被佔用的錯誤：

搞了一早上都沒找到問題在哪，所以早上出門前，demo

# dubbo應用配置
# dubbo應用名稱
application.dubbo.application.name=dubbo-server
# dubbo註冊配置
# dubbo註冊中心地址
application.dubbo.registry.address=zookeeper://127.0.0.1:2181
# dubbo註冊中心型別
application.dubbo.registry.client=curator
#application.dubbo.registry.username=dubbo
#application.dubbo.registry.password=dubbo
application.dubbo.registry.port=20880
 

我一直以為這裡的application.dubbo.registry.port就是服務的註冊埠，所以改來改去，服務依然提示埠被佔用。直到在某個機緣巧合的時刻，我打開了DubboConfigConfiguration這個配置類，我才發現自己少配置了：

在之前分享的內容中，我們只配置了AppliationConfig和RegistryConfig，而沒有配置ProtocolConfig，這個配置類設定的是協議相關的資訊，其中就包括我們這裡需要指定的服務埠：

然後我們只需要加上相應的配置即可解決上面的問題。這裡配置的方式有多種，這裡我們介紹一種新的配置方式（你可以按照我們之前分享的那種方式將配置檔案直接注入）：

首先在我們的配置類上加上@EnableDubbo註解，這個註解的作用就是啟用dubbo的相關配置：

我們之前的配置就不需要了，直接註釋或者刪除就可以了。同時，這個註解經為我們集成了@DobbuComponentScan和@EnableDubboConfig註解，所以我們不需要再重複註解：

然後我們在application.properties加上對應的註解即可：

# dubbo應用配置
# dubbo應用名稱
dubbo.application.name=dubbo-server
# dubbo註冊配置
# dubbo註冊中心地址
dubbo.registry.address=zookeeper://127.0.0.1:2181
# dubbo註冊中心型別
dubbo.registry.client=curator
dubbo.registry.protocol.port=20881
dubbo.registry.port=20881
dubbo.protocol.name=dubbo
dubbo.metadata-report.address=zookeeper://127.0.0.1:2181

需要注意的是，這個裡的配置字首必須與DubboConfigConfiguration指定的配置保持一致，否則相關配置無法正常注入。

完成上面的配置，我們再次啟動服務，發現我們服務的埠已經發生變化，同時修改註冊埠，再啟動一個服務也是ok的：

好了，到這裡，配置相關的內容就完了，其他配置可以參考我們上面的方式進行修改，目前我們就先分析這麼多。

負載均衡

關於dubbo的負載均衡，我們今天只說一些簡單內容，因為負載均衡這塊的內容也不是很複雜，如果你只是簡單使用，只需要瞭解各種策略的大概原理效果即可。當然，如果你有自定義負載均衡擴充套件的需求，那你可能要深入去了解了，具體的可以參考官方文件：

https://dubbo.apache.org/zh/docs/advanced/loadbalance/

負載均衡策略

Dubbo官方為我們提供了四種負載均衡策略，分別是隨機策略、輪詢策略、最少活躍呼叫數策略和一致性 Hash策略。如果我們不指定負載均衡策略，預設情況下為隨機策略。

• 隨機，按權重設定隨機概率。在一個截面上碰撞的概率高，但呼叫量越大分佈越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。
• 輪詢，按公約後的權重設定輪詢比率。存在慢的提供者累積請求的問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。
• 最少活躍呼叫數，相同活躍數的隨機，活躍數指呼叫前後計數差。使慢的提供者收到更少請求，因為越慢的提供者的呼叫前後計數差會越大。
• 一致性 Hash，相同引數的請求總是發到同一提供者。當某一臺提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。

負載均衡原始碼位於org.apache.dubbo.rpc.cluster.loadbalance包下，後面我們有時間再來研究相關實現原理，今天就暫時提一下：

負載用法

負載均衡預設情況下也是啟用的，只是策略預設是隨機，為了演示方便，我們這裡指定為輪詢。

服務端負載我也指定的是輪詢策略，但是好像沒有啥效果，請求始終在同一個服務上。

服務端指定負載均衡策略後是有效果的，下面是客戶端的程式碼：

@RestController
@RequestMapping("/dubbo")
public class DemoController {
    @DubboReference(version = "1.0", interfaceName = "demoService", interfaceClass = DemoService.class, loadbalance = "roundrobin")
    private DemoService demoService;

    @RequestMapping("/test")
    public Object demo() {
        String hello = demoService.sayHello("world");
        System.out.println(hello);
        return hello;
    }
}

訪問兩次/dubbo/test介面後，我們看到，兩個服務分別被訪問一次：

說明負載均衡已經起作用了。

總結

今天我們分享了兩個知識點，一個是dubbo的另一種配置方式的補充，另一個是dubbo的負載均衡。

在配置補充的相關內容中，我們演示了dubbo官方提供的配置方式，這種方式可以提供更豐富、更全面的配置，當然，最主要的是你要搞清楚各種配置方式之間的區別，搞清楚dubbo配置的本質，這樣不論你用那種配置方式，都可以信手拈來。

另外一塊是關於dubbo負載均衡的，主要分為兩種，一種是針對客戶端的，一種是針對服務端的，客戶端的我們演示過了，服務端的負載均衡好像沒啥效果，可能是我的開啟方式不對，後面有機會的話，我們再來研究。

dubbo的負載均衡在使用方面還是比較簡單，沒有特別複雜的配置，也不需要引入第三方包，只需要在介面呼叫的時候指定負載均衡策略即可，當然底層實現也沒有特別複雜，這些策略本質上就是為了獲取服務呼叫地址，即確定具體呼叫哪個服務，如果目前的四種負載均衡策略無法滿足你的需求，你也可以自定義自己的負載策略。

最後，附上我們示例的專案地址，最近幾天都忘記了，感興趣的小夥伴就可以去看下：

https://github.com/Syske/learning-dome-code/tree/dev/spring-boot-dubbo-demo