SpringBoot+Zookeeper集群+Nginx反向代理+Dubbo分布式托管（提供者、消費者）

• 一、軟件架構和微服務需求
• • 1.1、微服務需求
  • 1.2、框架選擇
  • 1.3、集群分布(下面為此圖實戰演示)
• 二、搭建Zookeeper注冊中心集群服務
• • 2.1、配置三臺zookeeper注冊中心服務器（數量可選）
  • 2.2、修改三臺zookeeper配置信息
  • 2.3、配置zookeeper集群區分id
  • 2.4、啟動zookeeper集群服務
• 三、啟動Dubbo管理控制臺可視化界面
• • 3.1、修改dubbo-admin的配置文件
  • 3.2、打包dubbo-admin項目
  • 3.3、運行`dubbo-admin-0.0.1-SNAPSHOT.jar`包
• 四、創建服務提供者集群服務（三個）
• • 4.1、新建SpringBoot_dubbo_provider項目
  • 4.2、引入pom.xml坐標依賴文件
  • 4.3、新建包com.ebuy.service，在此包下新建HelloService接口
  • 4.4、新建包com.ebuy.service.impl，在此包下新建接口HelloServiceImpl實現類
  • 4.5、核心配置文件（使用application.yml樹狀結構）
  • 4.6、啟動第一臺provider-8081提供者服務
  • 4.7、啟動第二臺provider-8082提供者服務
  • 4.8、啟動第三臺provider-8083提供者服務
• 五、創建服務消費者集群服務（四個）
• • 5.1、新建SpringBoot_dubbo_consumer項目
  • 5.2、引入pom.xml坐標依賴文件
  • 5.3、新建包com.ebuy.service,在此包下新建HelloService接口，與提供者接口保持一致
  • 5.4、新建包com.ebuy.controller,在此包下新建HelloController類
  • 5.5、核心配置文件（使用application.yml樹狀結構）
  • 5.6、啟動第一臺consumer-2011服務消費者
  • 5.7、啟動第一臺consumer-2012服務消費者
  • 5.8、啟動第一臺consumer-2013服務消費者
  • 5.9、啟動第一臺consumer-2014服務消費者
• 六、使用SwitchHosts工具模擬綁定域名
• • 6.1、修改主機配置文件hosts的只讀屬性
  • 6.2、以管理員身份運行SwitchHosts工具，新建域名（自定義）
• 七、使用Nginx反向代理（消費者）
• • 7.1、nginx反向代理作用
  • 7.2、修改nginx配置文件
  • 7.3、啟動nginx
• 八、通過nginx反向代理，請求消費者，通過消費者訪問提供者
• • 8.1、第一次請求
  • 8.2、第二次請求
  • 8.3、第三次請求
  • 8.4、第四次請求
• 九、解決Dubbo內置負載均衡策略問題
• • 9.1、Dubbo 的內置負載均衡策略（四種）
  • 9.2、什么是輪詢策略？
  • 9.3、如何解決不完全輪詢策略（忽略性能差異）？
  • 9.4、配置負載均衡策略
  • • 9.4.1、第一種在消費者注解方式配置
    • 9.4.2、第二種在消費者配置文件yml或者properties中配置
    • 9.4.3、第三種在提供者業務層注解方式配置
    • 9.4.4、第四種在提供者配置文件方式配置

一、軟件架構和微服務需求

1.1、微服務需求

我們知道軟件架構的演化過程，從單體架構，到垂直架構，再到SOA架構，最后到現在較流行的微服務架構。每個架構都有各自的優缺點，隨著架構體系的演化和現如今軟件整體架構的需求在不斷的提高，微服務之所以比較流行就是因為它將系統服務層完全獨立出來，抽取為一個一個的服務；微服務架構采用去中心化思想，服務之間采用restful等輕量協議通信，相比ESB更輕量。因為創建一個系統要考慮到全面服務，總體來說要能做到軟件架構的三要素：高可用、高性能、高并發。如果一個系統做不到這三個要素，那就不能稱為一個好的軟件系。

本文我們著重講解，使用SpringBoot項目整合Zookeeper注冊中心，Nginx反向代理和Dubbo遠程代理分布式托管，最后實現系統的高可用、高并發和高性能，其核心就是使所有服務器面對海量訪問能夠實現負載均衡。

1.2、框架選擇

• SpringBoot是當前比較流行的框架，其底層集成了Spring、mybatis、hibernate等多種優秀框架，這個框架的好用程度就不多說了，用起來可以說是朗朗上手，帶勁。
• Nginx是一 個輕量級/高性能的反向代理Web服務器，而且Nginx支持跨平臺、配置簡單、高并發連接：處理2-3萬并發連接數，官方監測能支持5萬并發，內存消耗小：開啟10個nginx才占150M內存 ，nginx處理靜態文件好，耗費內存少，它能夠實現非常高效的反向代理和負載平衡。
• Dubbo是一款微服務開發框架，它提供了RPC通信與微服務治理兩大關鍵能力。這意味著，使用Dubbo開發的微服務，將具備相互之間的遠程發現與通信能力，同時利用Dubbo提供的豐富服務治理能力，可以實現諸如服務實現、負載均衡、流量調度等服務治理訴求。同時Dubbo是高度可擴展的，用戶幾乎可以在任意功能點去定制自己的實現，以改變框架的默認行為來滿足自己的業務需求。
• Zookeeper是Apache Hadoop的子項目，是一個樹型的目錄服務，支持變更推送，適合作為Dubbo服務的注冊中心，工業強度較高，可用于生產環境，并推薦使用。
• 我們最終要實現的效果如下圖（讓其Dubbo分布式中的服務器全部使用集群，實現負載均衡）：
  

1.3、集群分布(下面為此圖實戰演示)

簡單集成應用可以詳細觀看分布式與微服務系列（二）、分布式RPC框架Apache Dubbo服務。

二、搭建Zookeeper注冊中心集群服務

因為本次測試是在一臺電腦上做測試，所以暫不使用Linux虛擬機啟動Zookeeper集群服務了，怕到時候電腦啊承受不住，掛掉。我們就先在Windows下使用Zookeeper測試即可。

2.1、配置三臺zookeeper注冊中心服務器（數量可選）

2.2、修改三臺zookeeper配置信息

修改zoo.cfg配置文件信息：


這三行代碼（不要修改）依次粘到后兩臺zookeeper配置文件中，別忘了更改端口號依次為2082、2083：

server.1=127.0.0.1:2801:3801 server.2=127.0.0.1:2802:3802 server.3=127.0.0.1:2803:3803

2.3、配置zookeeper集群區分id

2.4、啟動zookeeper集群服務

在啟動過程中，發現第一臺有報錯，莫要慌，不要緊，因為在第一臺啟動的時候會自動尋找靈臺兩臺zokkeeper，找不到你說急不急，所以就報錯了，等三臺zookeeper都啟動成功了，就不會報錯了！

如果實在不放心，可以連接zookeeper自帶的客戶端，查看下當前節點是否已創建！


出現上述節點就說明zookeeper集群此時已經啟動成功了，最后一個客戶端窗口可以關閉，但是上述仨窗口放著，可千萬別關哈！！！

三、啟動Dubbo管理控制臺可視化界面

我們人如果想要知道服務提供者和消費者是是否成功注冊和訂閱到zookeeper注冊中心，Dubbo官方為我們提供了一個Dubbo管理控制臺可視化界面。

啟動Dubbo控制臺界面有兩種方式，詳情可以查看我的上篇文章分布式與微服務系列（二）、分布式RPC框架Apache Dubbo服務，第四點有詳細介紹如何使用，此處我們就簡單介紹下jar包形式啟動Dubbo可視化管理控制臺，另一個是war包形式。

3.1、修改dubbo-admin的配置文件

3.2、打包dubbo-admin項目

在打開的DOS命令窗口中執行命令mvn clean package，先清除一下，然后打包項目，第一次執行可能會有點慢，大概一分鐘左右，稍安勿躁：

打包完成出現target目錄：

進入target目錄：

3.3、運行dubbo-admin-0.0.1-SNAPSHOT.jar包

首先你要確保你的此jar包所在的路徑沒有中文，你就可以直接在打開DOS命令窗口，切換到此路徑下，執行命令java -jar dubbo-admin-0.0.1-SNAPSHOT.jar即可運行；如果有中文，將此jar包直接拷貝到另外一個沒有中文的目錄下，再執行命令：

如果覺得每次啟動打開DOS窗口比較麻煩，那就jar包所在目錄下創建一個批處理：


如果你得jar包運行出現錯誤，那就是你上述的配置或路徑寫錯了，仔細檢查一遍按照我上述的步驟重新打包很快的。

啟動成功，然后我們就可以在瀏覽器地址欄輸入localhost:7001直接訪問了

四、創建服務提供者集群服務（三個）

4.1、新建SpringBoot_dubbo_provider項目

4.2、引入pom.xml坐標依賴文件

<!--springboot啟動器--><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter</artifactId></dependency><!--springboot web啟動器--><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><!--springboot 測試啟動器--><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope></dependency><!--dubbo與springboot集成啟動器--><dependency><groupId>org.apache.dubbo</groupId><artifactId>dubbo-spring-boot-starter</artifactId><version>2.7.6</version></dependency><!--dubbo與注冊中心zookeeper整合包--><dependency><groupId>org.apache.dubbo</groupId><artifactId>dubbo-registry-zookeeper</artifactId><version>2.7.6</version><exclusions><exclusion><groupId>org.apache.curator</groupId><artifactId>curator-recipes</artifactId></exclusion></exclusions></dependency><!--實現自動化創建節點路徑的父節點--><dependency><groupId>org.apache.curator</groupId><artifactId>curator-recipes</artifactId><version>4.2.0</version></dependency>

4.3、新建包com.ebuy.service，在此包下新建HelloService接口

package com.ebuy.service;public interface HelloService {public String sayHello(String name); }

4.4、新建包com.ebuy.service.impl，在此包下新建接口HelloServiceImpl實現類

package com.ebuy.service.impl;import com.ebuy.service.HelloService; import org.apache.dubbo.config.annotation.Service;@Service(loadbalance = "roundrobin",interfaceClass = HelloService.class) public class HelloServiceImpl implements HelloService {@Overridepublic String sayHello(String name){return "hello---"+name;} }

上述loadbalance=“roundrobin”指的是用戶通過消費者服務，訪問提供者時，按照輪詢的負載均衡策略訪問每一臺服務提供者；

• random：默認就是隨機策略的；（推薦）
• roundrobin：依次輪詢；（推薦）
• leastactive：最少活躍調用數（權重）活躍數指調用前后計數差，優先調用高的，相同活躍數的隨機。使慢的提供者收到更少請求，因為越慢的提供者的調用前后計數差會越大；
• consistenthash ：一致性策略，同參數的請求一定分發到同一個 Provider 如果需要某一類請求都到一個節點，那么可以使用一致性 Hash 策略。

注意：@Service注解是org.apache.dubbo.config.annotation.Service包下的，不是spring包下的。

4.5、核心配置文件（使用application.yml樹狀結構）

server:port: 8081 #服務器端口號 dubbo:application:name: springboot_provider #提供者應用名registry:address: 127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183 #連接注冊中心集群protocol: zookeeper #dubbo采用的注冊中心協議protocol: #連接注冊中心協議port: 20881 #dubbo端口號為20880，此處我們一會為了做集群區分，先改成20881name: dubbo config-center: #配置中心timeout: 25000 #最大超時時間scan:base-packages: com.ebuy.service.impl #掃描哪個包下提供的服務

4.6、啟動第一臺provider-8081提供者服務

在maven webapps項目下，可以直接使用tomcat7插件，只需修改端口號，就可以啟動多臺服務，在SpringBoot項目下，當然也可以啟動多臺服務，如下所示：

進入配置中心：

啟動之前，確認服務器端口號和dubbo端口號，以及提供服務方法的返回值：

4.7、啟動第二臺provider-8082提供者服務

修改application.yml配置文件中的端口號，兩處port：

4.8、啟動第三臺provider-8083提供者服務

修改application.yml配置文件中的端口號，兩處port：

此時三臺服務提供者已經全部啟動，但是是否成功注冊到zookeeper中心了，我們可以通過上述dubbo-admin管理控制臺，查看：


到這，我們就可以很安心的往下接著走下去了，三個服務者已經注冊到registory服務中心了。

五、創建服務消費者集群服務（四個）

5.1、新建SpringBoot_dubbo_consumer項目

5.2、引入pom.xml坐標依賴文件

<!--springboot啟動器--><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter</artifactId></dependency><!--springboot web啟動器--><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><!--springboot 測試啟動器--><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope></dependency><!--dubbo與springboot集成啟動器--><dependency><groupId>org.apache.dubbo</groupId><artifactId>dubbo-spring-boot-starter</artifactId><version>2.7.6</version></dependency><!--dubbo與注冊中心zookeeper整合包--><dependency><groupId>org.apache.dubbo</groupId><artifactId>dubbo-registry-zookeeper</artifactId><version>2.7.6</version><exclusions><exclusion><groupId>org.apache.curator</groupId><artifactId>curator-recipes</artifactId></exclusion></exclusions></dependency><!--實現自動化創建節點路徑的父節點--><dependency><groupId>org.apache.curator</groupId><artifactId>curator-recipes</artifactId><version>4.2.0</version></dependency><!-- 實現對 Spring Session 使用 Redis 作為數據源的自動化配置 --><dependency><groupId>org.springframework.session</groupId><artifactId>spring-session-data-redis</artifactId></dependency><!-- 實現對 Spring Data Redis 的自動化配置 --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId><exclusions><!-- 去掉對 Lettuce 的依賴，因為 Spring Boot 優先使用 Lettuce 作為 Redis 客戶端 --><exclusion><groupId>io.lettuce</groupId><artifactId>lettuce-core</artifactId></exclusion></exclusions></dependency><!-- 引入 Jedis 的依賴，這樣 Spring Boot 實現對 Jedis 的自動化配置 --><dependency><groupId>redis.clients</groupId><artifactId>jedis</artifactId></dependency>

5.3、新建包com.ebuy.service,在此包下新建HelloService接口，與提供者接口保持一致

package com.ebuy.service;public interface HelloService {public String sayHello(String name); }

5.4、新建包com.ebuy.controller,在此包下新建HelloController類

package com.ebuy.controller;import com.ebuy.service.HelloService; import org.apache.dubbo.config.annotation.Reference; import org.springframework.stereotype.Controller; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.ResponseBody; import javax.servlet.http.HttpServletRequest;@Controller @RequestMapping("/demo") public class HelloController {@ReferenceHelloService helloService;int port=2011;@RequestMapping("/hello")@ResponseBodypublic String getName(String name){//遠程調用,獲取響應結果String result = helloService.sayHello(name);System.out.println("consumer-" + port + "\t" + result);return result;} }

注意：

@Reference HelloService helloService;

此處的HelloService訪問的是遠程的Provider所提供的服務，所有使用@Autowire注解是加載不到的，要使用@Reference注解調用遠程提供者發布的@Service注解標注的服務注冊接口。

5.5、核心配置文件（使用application.yml樹狀結構）

server:port: 2011 #服務器端口號 dubbo:application:name: springboot_consumer #消費者服務名稱registry: #注冊中心address: 127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183 #zookeeper集群protocol: zookeeper #dubbo采用zookeeper注冊中心協議consumer: #消費者節點check: false #啟動時不用檢測提供者是否已經注冊config-center:timeout: 25000 #超時時間 單位秒

在啟動消費者前，要注意一點，因為SpringBoot內部機制會自動加載DataSource數據源和Redis相關配置，即使你沒有配任何置數據庫相關配置信息，它內部也會默認加載，這個時候我們啟動消費者服務就會出現如下錯誤：

Error creating bean with name ‘enableRedisKeyspaceNotificationsInitializer‘

這個時候如果你配置了數據庫和redis相關配置，暫時先全部注釋掉，然后在消費者主入口類的@SpringBootApplication排除運行期間不包括的服務，如下：

package com.ebuy;import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration; import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration;@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class, RedisAutoConfiguration.class}) public class SpringbootDubboConsumerApplication {public static void main(String[] args) {SpringApplication.run(SpringbootDubboConsumerApplication.class, args);} }

@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class, RedisAutoConfiguration.class}),exclude就代表不包括，排除的意思，這個時候再去逐個啟動消費者服務就可以了。

5.6、啟動第一臺consumer-2011服務消費者

5.7、啟動第一臺consumer-2012服務消費者

5.8、啟動第一臺consumer-2013服務消費者

5.9、啟動第一臺consumer-2014服務消費者

此時再去Dubbo-admin管理控制臺可視化界面查看：

六、使用SwitchHosts工具模擬綁定域名

6.1、修改主機配置文件hosts的只讀屬性

6.2、以管理員身份運行SwitchHosts工具，新建域名（自定義）

七、使用Nginx反向代理（消費者）

7.1、nginx反向代理作用

上述我們開啟了四臺消費者服務，那么我們怎么知道每次訪問的是哪一臺服務消費者，既然我們配置了四臺就要實現集群的機制，那么怎么實現？

這個時候Nginx作用就來了，Nginx反向代理可以實現負載均衡，也即是我們只需在Nginx的配置文件中配置需要通過的消費者服務，nginx內部機制算法會自動幫我們實現負載均衡，配置如下：

7.2、修改nginx配置文件

7.3、啟動nginx

nginx啟動之后，此時我們就可以通過www.ebuy.com域名進行測試訪問了！直接訪問應該會進入nginx的內置默認頁面。

八、通過nginx反向代理，請求消費者，通過消費者訪問提供者

在地址欄輸入http://www.ebuy.com/demo/hello?name=jason

8.1、第一次請求

查看控制臺，請求到的是哪一臺消費者：

8.2、第二次請求

查看控制臺，請求到的是哪一臺消費者：

8.3、第三次請求

查看控制臺，請求到的是哪一臺消費者：

8.4、第四次請求

查看控制臺，請求到的是哪一臺消費者：

由上述測試可以看出，nginx反向代理在我們第一次請求會隨機幫我們選一臺消費者，然后后續請求就會輪詢訪問消費者，這樣我們就實現了服務器的負載均衡，避免了當訪問量巨大時導致某一臺服務器超負載的情況。

九、解決Dubbo內置負載均衡策略問題

• 細心的伙子應該可以看出上述的四次測試中，消費者使用Nginx的反向代理實現了第一次隨機訪問，后續是依次輪詢的負載均衡策略；

• 然而but提供者卻沒有真正實現我們所謂的loadbalance="roundrobin"輪詢負載均衡策略，第一次8083、第二次和第三次都是8081，第四次才是8082，這顯然不符合我們所期望的輪詢機制，為什么會出現這樣的情況呢？

9.1、Dubbo 的內置負載均衡策略（四種）

• Random（默認是隨機負載）
  • 隨機訪問集群中節點。訪問概率和權重有關。是 Dubbo 的默認負載均衡策略。
  • 權重（weight）：
    占有比例。集群中每個項目部署的服務器的性能可能是不同，性能好的服務器權重應該高一些。
• RoundRobin（下面著重講解）

  輪詢。訪問頻率和 權重（weight） 有關。

• LeastActive

  最少活躍調用數，相同活躍數的隨機。如果某個機器性能越差，那么接收的請求越少，越不活躍，此時就會給不活躍的性能差的機器分配更少的請求

• ConsistentHash

  一致性 Hash 算法，相同參數的請求一定分發到同一個 Provider 如果需要某一類請求都到一個節點，那么可以使用一致性 Hash 策略。

9.2、什么是輪詢策略？

• 所謂輪詢是指將請求輪流分配為每臺提供者服務器，舉個栗子：假設我們有三臺服務器A、B、C。我們將第一個請求分配給服務器A，第二個請求分配給服務器B，第三個請求分配給服務器C，第四個請求分配給服務器A，也即是當所有服務器請求一遍后，再次請求將會從第一臺服務器輪流請求，這個過程就叫做輪詢。

• 輪詢負載均衡策略（并不完全是輪詢的），不可忽略的一點是，每臺服務器之間多少都會存在一些性能上的差異，如果我們將等量的請求分配給某一臺性能較差的服務器，由于這臺服務器性能較差，那么再次發出請求，請求還是會在這臺性能較差的服務器上出現，很明顯我們上述出現的情況就是因為如此。盡管我們上述所有的服務器是在同一臺電腦上啟動的（為了模擬），其實這也驗證了即使是同一臺電腦，自身的服務器也會對不同的tomcat進程分配不同的進程占用時長，所以就導致了上述第二次和第三次請求訪問的都是8081的情況！！！說到這應該可以理解了吧！

• 要知道一般情況下，每個服務都會部署到不同的電腦上，一般很少出現連續性能問題的這種情況。

9.3、如何解決不完全輪詢策略（忽略性能差異）？

• 想要解決上述問題，這個時候我們就需要對輪詢過程進行加權（weight），以調控每臺服務器的負載，經過加權后，每臺服務器能夠得到的請求數比例，接近或等于它們自身的權重比。

• 注解方式

  @Service(loadbalance = "roundrobin",weight = "權重數")

• 配置文件方式

  dubbo:provider:loadbalance: roundrobin #輪詢負載均衡策略weight: "權重數" #針對每一臺服務提供者所在服務器的性能進行權重數配置（一般情況下默認都是100）

9.4、配置負載均衡策略

配置負載均衡策略有很多種方式：

9.4.1、第一種在消費者注解方式配置

@Controller @RequestMapping("/demo") public class HelloController {//表示在當前業務層中所有方法都會輪詢訪問所有provider集群@Reference(loadbalance = "roundrobin") HelloService helloService;}

9.4.2、第二種在消費者配置文件yml或者properties中配置

dubbo:consumer: loadbalance: roundrobiin #此處代表針對當前服務的所有controller層都會輪詢的訪問provider集群

9.4.3、第三種在提供者業務層注解方式配置

//此處配置，只在provider集群中所有服務中的(當前業務層)對外提供輪詢服務 @Service(loadbalance = "roundrobin") public class HelloServiceImpl implements HelloService {@Overridepublic String sayHello(String name){return "hello---8081----"+name;} }

9.4.4、第四種在提供者配置文件方式配置

dubbo:provider:loadbalance: roundrobin #針對provider集群中所有服務的所有業務層對外提供輪詢負載均衡策略

其實上述四種配置中，不推薦在消費者一方使用負載均衡策略配置，因為提供者配置的是集群方式，該怎么提供對外服務，很顯然在提供者方配置最為合適，也比較高效。

---

一起學編程，讓生活更隨和！如果你覺得是個同道中人，歡迎關注博主公眾號：【隨和的皮蛋桑】。專注于Java基礎、進階、面試以及計算機基礎知識分享🐳。偶爾認知思考、日常水文🐌。

總結

以上是生活随笔為你收集整理的分布式与微服务系列（三）、SpringBoot+Zookeeper集群+Nginx反向代理+Dubbo分布式托管（提供者、消费者）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。