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

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 {
    @Override
    public 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，此處我們一會為了做集群區分，先改成20881
    name: 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 {

    @Reference
    HelloService helloService;

    int port=2011;

    @RequestMapping("/hello")
    @ResponseBody
    public 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 {
    @Override
    public String sayHello(String name)
    {
        return "hello---8081----"+name;
    }
}

9.4.4、第四種在提供者組態檔方式配置

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

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