Nepxion Discovery：Spring Cloud微服務版本灰度釋出新神器

專案地址：https://github.com/Nepxion/Discovery

強烈建議star、fork該專案，該專案可以作為學習改造Spring Cloud元件的案例專案。

Nepxion Discovery是一款對Spring Cloud的服務註冊發現的增強中介軟體，其功能包括多版本灰度釋出，黑/白名單的IP地址過濾，限制註冊等，支援Eureka、Consul和Zookeeper。現有的Spring Cloud微服務可以方便引入該外掛，程式碼零侵入，使用者只需要做如下簡單的事情：

• 引入相關Plugin Starter依賴到pom.xml

• 必須為微服務定義一個版本號（version），在application.properties或者yaml的metadata裡

• 必須為微服務自定義一個便於為微服務歸類的Key，例如組名（group）或者應用名（application），在application.properties或者yaml的metadata裡，便於遠端配置中心推送和灰度介面分析

• 使用者只需要關註相關規則推送。可以採用如下方式之一：

  透過遠端配置中心推送規則

  透過控制檯介面推送規則

  透過客戶端工具（例如Postman）推送推測

Quick Start

圖形化演示操作：

• 請訪問http://www.iqiyi.com/w_19rzwzovrl.html，影片清晰度改成720P，然後最大化播放。

• 請訪問https://pan.baidu.com/s/1eq_N56VbgSCaTXYQ5aKqiA，獲取更清晰的影片 Alt text Alt text。

  

更多教程和示例檢視最下麵的“示例演示”。

痛點

現有Spring Cloud的痛點：

• 如果你是運維負責人，是否會經常發現，你掌管的測試環境中的服務註冊中心，被一些不負責的開發人員把他本地開發環境註冊上來，造成測試人員測試失敗。你希望可以把本地開發環境註冊給遮蔽掉，不讓註冊。

• 如果你是運維負責人，生產環境的某個微服務叢集下的某個實體，暫時出了問題，但又不希望它下線。你希望可以把該實體給遮蔽掉，暫時不讓它被呼叫。

• 如果你是業務負責人，鑒於業務服務的快速迭代性，微服務叢集下的實體釋出不同的版本。你希望根據版本管理策略進行路由，提供給下游微服務區別呼叫，達到多版本灰度訪問控制。

• 如果你是測試負責人，希望對微服務做A/B測試，那麼透過動態改變版本達到該目的。

簡介

實現對基於Spring Cloud的微服務和Zuul閘道器的支援：

• 具有極大靈活性——支援在任何環節做過濾控制和版本灰度釋出。

• 具有極小限制性——只要開啟了服務註冊發現，程式入口加了@EnableDiscoveryClient。

實現服務註冊層面的控制：

• 基於黑/白名單的IP地址過濾機制禁止對相應的微服務進行註冊。

• 基於最大註冊數的限制微服務註冊。一旦微服務叢集下註冊的實體數目已經達到上限，將禁止後續的微服務進行註冊。

實現服務發現層面的控制：

• 基於黑/白名單的IP地址過濾機制禁止對相應的微服務被髮現。

• 基於版本配對，透過對消費端和提供端可訪問版本對應關係的配置，在服務發現和負載均衡層面，進行多版本訪問控制。

實現灰度釋出：

• 透過規則改變，實現灰度釋出。

• 透過版本切換，實現灰度釋出。

• 實現透過XML進行上述規則的定義。

實現透過事件匯流排機制（EventBus）的功能，實現釋出/訂閱功能：

• 對接遠端配置中心，預設整合阿裡巴巴的Nacos，非同步接受遠端配置中心主動推送規則資訊，動態改變微服務的規則。

• 結合Spring Boot Actuator，非同步接受Rest主動推送規則資訊，動態改變微服務的規則。

• 結合Spring Boot Actuator，動態改變微服務的版本。

• 在服務註冊層面的控制中，一旦禁止註冊的條件觸發，主動推送非同步事件，以便使用者訂閱。

實現透過Listener機制進行擴充套件：

• 使用者可以自定義更多的規則過濾條件。

• 使用者可以對服務註冊發現核心事件進行監聽。

實現支援Spring Boot Actuator和Swagger整合。

實現獨立控制檯，支援對規則和版本集中管理，未來考慮介面實現。

實現支援未來擴充套件更多的服務註冊中心。

實現圖形化的灰度釋出功能。

名詞解釋

IP地址，即根據微服務上報的它所在機器的IP地址。本系統內部強制以IP地址上報，禁止HostName上報，杜絕Spring Cloud應用在Docker或者Kubernetes部署時候出現問題。

本地版本，即初始化讀取本地配置檔案獲取的版本，也可以是第一次讀取遠端配置中心獲取的版本。本地版本和初始版本是同一個概念。

動態版本，即灰度釋出時的版本。動態版本和灰度版本是同一個概念。

本地規則，即初始化讀取本地配置檔案獲取的規則，也可以是第一次讀取遠端配置中心獲取的規則。本地規則和初始規則是同一個概念。

動態規則，即灰度釋出時的規則。動態規則和灰度規則是同一個概念。

事件匯流排，即基於Google Guava的EventBus構建的元件。在使用上，透過事件匯流排推送動態版本和動態規則的時候，前者只支援非同步，後者支援非同步和同步。

遠端配置中心，即可以儲存規則配置XML格式的配置中心，可以包括不限於Nacos，Apollo，DisConf，Spring Cloud Config。

配置（Config）和規則（Rule），在本系統中屬於同一個概念，例如更新配置，即更新規則，例如遠端配置中心儲存的配置，即規則XML。

場景

黑/白名單的IP地址註冊的過濾：

• 開發環境的本地微服務（例如IP地址為172.16.0.8）不希望被註冊到測試環境的服務註冊發現中心，那麼可以在配置中心維護一個黑/白名單的IP地址過濾（支援全域性和區域性的過濾）的規則。

• 我們可以透過提供一份黑/白名單達到該效果。

最大註冊數的限制的過濾：

• 當某個微服務註冊數目已經達到上限（例如10個），那麼後面起來的微服務，將再也不能註冊上去。

黑/白名單的IP地址發現的過濾：

• 開發環境的本地微服務（例如IP地址為172.16.0.8）已經註冊到測試環境的服務註冊發現中心，那麼可以在配置中心維護一個黑/白名單的IP地址過濾（支援全域性和區域性的過濾）的規則，該本地微服務不會被其他測試環境的微服務所呼叫。

• 我們可以透過推送一份黑/白名單達到該效果。

多版本灰度訪問控制：

• A服務呼叫B服務，而B服務有兩個實體（B1、B2），雖然三者相同的服務名，但功能上有差異，需求是在某個時刻，A服務只能呼叫B1，禁止呼叫B2。在此場景下，我們在application.properties裡為B1維護一個版本為1.0，為B2維護一個版本為1.1。

• 我們可以透過推送A服務呼叫某個版本的B服務對應關係的配置，達到某種意義上的灰度控制，切換版本的時候，我們只需要再次推送即可。

動態改變微服務版本：

• 在A/B測試中，透過動態改變版本，不重啟微服務，達到訪問版本的路徑改變。

架構

簡單描述一下，本系統的核心模組“基於版本控制的灰度釋出”，從閘道器（Zuul）開始的灰度釋出操作過程。

灰度釋出前

• 假設當前生產環境，呼叫路徑為閘道器(V1.0)->服務A(V1.0)->服務B(V1.0)。

• 運維將釋出新的生產環境，部署新服務叢集，服務A(V1.1)，服務B(V1.1)。

• 由於閘道器(1.0)並未指向服務A(V1.1)，服務B(V1.1)，所以它們是不能被呼叫的。

灰度釋出中

• 新增用作灰度釋出的閘道器(V1.1)，指向服務A(V1.1)->服務B(V1.1)。

• 灰度閘道器(V1.1)釋出到服務註冊發現中心，但禁止被服務發現，閘道器外的呼叫進來無法負載均衡到閘道器(V1.1)上。

• 在灰度閘道器(V1.1)->服務A(V1.1)->服務B(V1.1)這條呼叫路徑做灰度測試。

• 灰度測試成功後，把閘道器(V1.0)指向服務A(V1.1)->服務B(V1.1)。

灰度釋出後

• 下線服務A(V1.0)，服務B(V1.0)，灰度成功。

• 灰度閘道器(V1.1)可以不用下線，留作下次版本上線再次灰度釋出。

架構圖：

相容

版本相容情況

• Spring Cloud F版，請採用4.x.x版本，具體程式碼參考master分支。

• Spring Cloud C版、D版和E版，請採用3.x.x版本，具體程式碼參考Edgware分支。

• 4.x.x版本由於Swagger和Spring Boot 2.x.x版本的Actuator用法有衝突，故暫時不支援Endpoint功能，其他功能和3.x.x版本一致。

中介軟體相容情況

Consul：

• Spring Cloud F版，最好採用Consul的1.2.1伺服器版本（或者更高），從https://releases.hashicorp.com/consul/1.2.1/獲取。

• Spring Cloud C版、D版和E版，必須採用Consul的0.9.3伺服器版本（或者更低），從https://releases.hashicorp.com/consul/0.9.3/獲取。

Zookeeper：

• Spring Cloud F版，必須採用Zookeeper的3.5.x伺服器版本（或者更高）。

• Spring Cloud C版、D版和E版，最好採用Zookeeper的3.5.0以下伺服器版本（或者更低）。

Eureka：

• 跟Spring Cloud版本保持一致。

依賴

微服務選擇相應的外掛引入，最後一個如需對接Nacos遠端配置中心，則引入：

<dependency>
    <groupId>com.nepxiongroupId>

    <artifactId>discovery-plugin-starter-eurekaartifactId>
    <version>${discovery.plugin.version}version>
dependency>

<dependency>
    <groupId>com.nepxiongroupId>
    <artifactId>discovery-plugin-starter-consulartifactId>
    <version>${discovery.plugin.version}version>
dependency>

<dependency>
    <groupId>com.nepxiongroupId>
    <artifactId>discovery-plugin-starter-zookeeperartifactId>
    <version>${discovery.plugin.version}version>
dependency>

<dependency>
    <groupId>com.nepxiongroupId>
    <artifactId>discovery-plugin-config-center-extension-nacosartifactId>
    <version>${discovery.plugin.version}version>
dependency>

獨立控制檯引入，最後一個如需對接Nacos遠端配置中心，則引入：

<dependency>
    <groupId>com.nepxiongroupId>

    <artifactId>discovery-console-starterartifactId>
    <version>${discovery.plugin.version}version>
dependency>

<dependency>
    <groupId>com.nepxiongroupId>
    <artifactId>discovery-console-extension-nacosartifactId>
    <version>${discovery.plugin.version}version>
dependency>

工程

工程名	描述
discovery-plugin-framework	核心框架
discovery-plugin-framework-eureka	核心框架的Eureka實現
discovery-plugin-framework-consul	核心框架的Consul實現
discovery-plugin-framework-zookeeper	核心框架的Zookeeper實現
discovery-plugin-config-center	配置中心實現
discovery-plugin-config-center-extension-nacos	配置中心的Nacos擴充套件
discovery-plugin-admin-center	管理中心實現
discovery-plugin-starter-eureka	Eureka Starter
discovery-plugin-starter-consul	Consul Starter
discovery-plugin-starter-zookeeper	Zookeeper Starter
discovery-console	獨立控制檯，提供給UI
discovery-console-extension-nacos	獨立控制檯的Nacos擴充套件
discovery-console-starter	Console Starter
discovery-console-desktop	圖形化灰度釋出等桌面程式
discovery-springcloud-example-console	獨立控制檯示例
discovery-springcloud-example-eureka	Eureka伺服器
discovery-springcloud-example	灰度釋出等示例

規則和策略

規則示例

請不要被嚇到，我只是把註釋寫的很詳細而已，裡面配置沒幾行：

<rule>
    
    <register>
        
        
        
        
        
        <blacklist filter-value="10.10;11.11">
            
            <service service-name="discovery-springcloud-example-a" filter-value="172.16"/>
        blacklist>

        

        
        
        
        
        <count filter-value=“10000”>
            
            <service service-name=“discovery-springcloud-example-a” filter-value=“5000”/>
        count>
    register>

    <discovery>
        
        
        <blacklist filter-value=“10.10;11.11”>
            
            <service service-name=“discovery-springcloud-example-b” filter-value=“172.16”/>
        blacklist>

        
        
        
        <version>
            
            <service consumer-service-name=“discovery-springcloud-example-a” provider-service-name=“discovery-springcloud-example-b” consumer-version-value=“1.0” provider-version-value=“1.0;1.1”/>
            
            <service consumer-service-name=“discovery-springcloud-example-b” provider-service-name=“discovery-springcloud-example-c” consumer-version-value=“1.0” provider-version-value=“1.0;1.1”/>
            
            <service consumer-service-name=“discovery-springcloud-example-b” provider-service-name=“discovery-springcloud-example-c” consumer-version-value=“1.1” provider-version-value=“1.2”/>
        version>
    discovery>
rule>

多版本灰度規則策略

版本策略介紹:

1、標準配置，舉例如下：

"a" provider-service-name="b" consumer-version-value="1.0" provider-version-value="1.0,1.1"/> 

表示消費端1.0版本，允許訪問提供端1.0和1.1版本。

2、版本值不配置，舉例如下：

"a" provider-service-name="b" provider-version-value="1.0,1.1"/>

表示消費端任何版本，允許訪問提供端1.0和1.1版本。

"a" provider-service-name="b" consumer-version-value="1.0"/>

表示消費端1.0版本，允許訪問提供端任何版本。

<service consumer-service-name="a" provider-service-name="b"/>

表示消費端任何版本，允許訪問提供端任何版本。

3、版本值空字串，舉例如下：

"a" provider-service-name="b" consumer-version-value="" provider-version-value="1.0,1.1"/>

表示消費端任何版本，允許訪問提供端1.0和1.1版本。

"a" provider-service-name="b" consumer-version-value="1.0" provider-version-value=""/>

表示消費端1.0版本，允許訪問提供端任何版本。

"a" provider-service-name="b" consumer-version-value="" provider-version-value=""/>

表示消費端任何版本，允許訪問提供端任何版本。

4、版本對應關係未定義，預設消費端任何版本，允許訪問提供端任何版本。

特殊情況處理，在使用上需要極力避免該情況發生：

1. 消費端的application.properties未定義版本號，則該消費端可以訪問提供端任何版本。

2. 提供端的application.properties未定義版本號，當消費端在xml裡不做任何版本配置，才可以訪問該提供端。

動態改變規則策略

微服務啟動的時候，由於規則（例如：rule.xml）已經配置在本地，使用者希望改變一下規則，而不重啟微服務，達到規則的改變。

• 規則分為本地規則和動態規則。

• 本地規則是透過在本地規則（例如：rule.xml）檔案定義的，也可以從遠端配置中心獲取，在微服務啟動的時候讀取。

• 動態規則是透過POST方式動態設定，或者由遠端配置中心推送設定。

• 規則初始化的時候，如果接入了遠端配置中心，先讀取遠端規則，如果不存在，再讀取本地規則檔案。

• 多規則灰度獲取規則的時候，先獲取動態規則，如果不存在，再獲取本地規則。

動態改變版本策略

微服務啟動的時候，由於版本已經寫死在application.properties裡，使用者希望改變一下版本，而不重啟微服務，達到訪問版本的路徑改變。

• 版本分為本地版本和動態版本。

• 本地版本是透過在application.properties裡配置的，在微服務啟動的時候讀取。

• 動態版本是透過POST方式動態設定。

  多版本灰度獲取版本值的時候，先獲取動態版本，如果不存在，再獲取本地版本。

黑/白名單的IP地址註冊的過濾策略

微服務啟動的時候，禁止指定的IP地址註冊到服務註冊發現中心。支援黑/白名單，白名單表示只允許指定IP地址字首註冊，黑名單表示不允許指定IP地址字首註冊。

• 全域性過濾，指註冊到服務註冊發現中心的所有微服務，只有IP地址包含在全域性過濾欄位的字首中，都允許註冊（對於白名單而言），或者不允許註冊（對於黑名單而言）。

• 區域性過濾，指專門針對某個微服務而言，那麼真正的過濾條件是全域性過濾+區域性過濾結合在一起。

最大註冊數的限制的過濾策略

微服務啟動的時候，一旦微服務叢集下註冊的實體數目已經達到上限（可配置），將禁止後續的微服務進行註冊。

• 全域性配置值，只下麵配置所有的微服務叢集，最多能註冊多少個。

• 區域性配置值，指專門針對某個微服務而言，那麼該值如存在，全域性配置值失效。

黑/白名單的IP地址發現的過濾策略

微服務啟動的時候，禁止指定的IP地址被服務發現。它使用的方式和“黑/白名單的IP地址註冊的過濾”一致。

版本屬性欄位定義策略

不同的服務註冊發現元件對應的版本配置值。

# Eureka config
eureka.instance.metadataMap.version=1.0
eureka.instance.metadataMap.group=xxx-service-group

# 奇葩的Consul配置（參考https://springcloud.cc/spring-cloud-consul.html - 元資料和Consul標簽）
# Consul config（多個值用“,”分隔，例如version=1.0,value=abc）
spring.cloud.consul.discovery.tags=version=1.0,group=xxx-service-group

# Zookeeper config
spring.cloud.zookeeper.discovery.metadata.version=1.0
spring.cloud.zookeeper.discovery.metadata.group=xxx-service-group

功能開關策略

# Plugin config
# 開啟和關閉服務註冊層面的控制。一旦關閉，服務註冊的黑/白名單過濾功能將失效，最大註冊數的限制過濾功能將失效。缺失則預設為true
spring.application.register.control.enabled=true
# 開啟和關閉服務發現層面的控制。一旦關閉，服務多版本呼叫的控制功能將失效，動態遮蔽指定IP地址的服務實體被髮現的功能將失效。缺失則預設為true
spring.application.discovery.control.enabled=true
# 開啟和關閉透過Rest方式對規則配置的控制和推送。一旦關閉，只能透過遠端配置中心來控制和推送。缺失則預設為true
spring.application.config.rest.control.enabled=true
# 本地規則檔案的路徑，支援兩種方式：classpath:rule.xml - 規則檔案放在resources目錄下，便於打包進jar；file:rule.xml - 規則檔案放在工程根目錄下，放置在外部便於修改。缺失則預設為不裝載本地規則
spring.application.config.path=classpath:rule.xml
# 為微服務歸類的Key，一般透過group欄位來歸類，例如eureka.instance.metadataMap.group=xxx-group或者eureka.instance.metadataMap.application=xxx-application。缺失則預設為group
# spring.application.group.key=group
# spring.application.group.key=application

配置中心

跟遠端配置中心整合。

本系統預設跟Nacos整合，如何安裝使用，請參考https://github.com/alibaba/nacos。使用者也可以跟攜程Apollo，百度DisConf等遠端配置中心整合，實現規則讀取和訂閱。

• 拉取配置，參考discovery-plugin-config-center-extension-nacos工程。

• 推送配置，參考discovery-console-extension-nacos工程。

管理中心

PORT埠號為server.port或者management.port都可以（management.port開放只支援3.x.x版本）。

配置介面、版本介面、路由介面參考Swagger介面，如下圖：

獨立控制檯

為UI提供相關介面，包括：

• 一系列批次功能。

• 跟Nacos整合，實現配置推送和清除。

PORT埠號為server.port或者management.port都可以（management.port開放只支援3.x.x版本）。

控制檯介面

參考Swagger介面，如下圖：

擴充套件和自定義更多規則或者監聽

使用者可以繼承如下類：

• AbstractRegisterListener，實現服務註冊的擴充套件和監聽，用法參考discovery-springcloud-example下MyRegisterListener。

• AbstractDiscoveryListener，實現服務發現的擴充套件和監聽，用法參考discovery-springcloud-example下MyDiscoveryListener。註意，在Consul下，同時會觸發service和management兩個實體的事件，需要區別判斷，如下圖。

• AbstractLoadBalanceListener，實現負載均衡的擴充套件和監聽，用法參考discovery-springcloud-example下MyLoadBalanceListener。

集成了健康檢查的Consul控制檯。

示例演示

場景描述

本例將模擬一個較為複雜的場景，如下圖：

系統部署情況：

• 閘道器Zuul叢集部署了1個

• 微服務叢集部署了3個，分別是A服務叢集、B服務叢集、C服務叢集，分別對應的實體數為2、2、3

微服務叢集的呼叫關係為閘道器Zuul->服務A->服務B->服務C。

系統呼叫關係：

• 閘道器Zuul的1.0版本只能呼叫服務A的1.0版本，閘道器Zuul的1.1版本只能呼叫服務A的1.1版本。

• 服務A的1.0版本只能呼叫服務B的1.0版本，服務A的1.1版本只能呼叫服務B的1.1版本。

• 服務B的1.0版本只能呼叫服務C的1.0和1.1版本，服務B的1.1版本只能呼叫服務C的1.2版本。

用規則來表述上述關係：

<rule>
    <discovery>
        <version>
            
            <service consumer-service-name="discovery-springcloud-example-zuul" provider-service-name="discovery-springcloud-example-a" consumer-version-value="1.0" provider-version-value="1.0"/>
            
            <service consumer-service-name="discovery-springcloud-example-zuul" provider-service-name="discovery-springcloud-example-a" consumer-version-value="1.1" provider-version-value="1.1"/>
            
            <service consumer-service-name="discovery-springcloud-example-a" provider-service-name="discovery-springcloud-example-b" consumer-version-value="1.0" provider-version-value="1.0"/>
            
            <service consumer-service-name="discovery-springcloud-example-a" provider-service-name="discovery-springcloud-example-b" consumer-version-value="1.1" provider-version-value="1.1"/>
            
            <service consumer-service-name="discovery-springcloud-example-b" provider-service-name="discovery-springcloud-example-c" consumer-version-value="1.0" provider-version-value="1.0;1.1"/>
            
            <service consumer-service-name="discovery-springcloud-example-b" provider-service-name="discovery-springcloud-example-c" consumer-version-value="1.1" provider-version-value="1.2"/>
        version>

    discovery>
rule>

上述微服務分別見discovery-springcloud-example字樣的8個DiscoveryApplication，分別對應各自的application.properties。這8個應用，對應的版本和埠號如下表：

微服務	服務埠	管理埠	版本
A1	1100	5100	1.0
A2	1101	5101	1.1
B1	1200	5200	1.0
B2	1201	5201	1.1
C1	1300	5300	1.0
C2	1301	5301	1.1
C3	1302	5302	1.2
Zuul	1400	5400	1.0

獨立控制檯見discovery-springcloud-example-console，對應的版本和埠號如下表：

服務埠	管理埠
2222	3333

開始演示

啟動服務註冊發現中心，預設是Eureka。可供選擇的有Eureka，Zuul，Zookeeper。Eureka，請啟動discovery-springcloud-example-eureka下的應用，後兩者自行安裝伺服器。

根據上面選擇的服務註冊發現中心，對示例下的discovery-springcloud-example/pom.xml進行元件切換。

<dependency>
    <groupId>com.nepxiongroupId>

    <artifactId>discovery-plugin-starter-eurekaartifactId>
    
    
    <version>${discovery.plugin.version}version>
dependency>

根據上面選擇的服務註冊發現中心，對控制臺下的discovery-springcloud-example-console/pom.xml進行元件切換切換。

<dependency>
    <groupId>org.springframework.cloudgroupId>

    <artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
    
    
dependency>

服務註冊過濾的操作演示

黑/白名單的IP地址註冊的過濾：

• 在rule.xml把本地IP地址寫入到相應地方。

• 啟動DiscoveryApplicationA1.java。

• 丟擲禁止註冊的異常，即本地服務受限於黑名單的IP地址串列，不會註冊到服務註冊發現中心；白名單操作也是如此，不過邏輯剛好相反。

最大註冊數的限制的過濾：

• 在rule.xml修改最大註冊數為0。

• 啟動DiscoveryApplicationA1.java。

• 丟擲禁止註冊的異常，即本地服務受限於最大註冊數，不會註冊到服務註冊發現中心。

黑/白名單的IP地址發現的過濾：

• 在rule.xml把本地IP地址寫入到相應地方。

• 啟動DiscoveryApplicationA1.java和DiscoveryApplicationB1.java、DiscoveryApplicationB2.java。

• 你會發現A服務無法獲取B服務的任何實體，即B服務受限於黑名單的IP地址串列，不會被A服務的發現；白名單操作也是如此，不過邏輯剛好相反。

服務發現和負載均衡控制的操作演示

基於圖形化方式的多版本灰度訪問控制：

• 請訪問http://www.iqiyi.com/w_19s07thtsh.html，影片清晰度改成720P，然後最大化播放。

• 請訪問https://pan.baidu.com/s/1eq_N56VbgSCaTXYQ5aKqiA，獲取更清晰的影片。

基於Rest方式的多版本灰度訪問控制

基於服務的操作過程和效果：

啟動discovery-springcloud-example下7個DiscoveryApplication（除去Zuul），無先後順序，等待全部啟動完畢。

下麵URL的埠號，可以是服務埠號，也可以是管理埠號。

透過版本切換，達到灰度訪問控制，針對A服務：

1.1 透過Postman或者瀏覽器，執行POST http://localhost:1100/routes，填入discovery-springcloud-example-b;discovery-springcloud-example-c，檢視路由路徑，如圖1，可以看到符合預期的呼叫路徑。

1.2 透過Postman或者瀏覽器，執行POST http://localhost:1100/version/update，填入1.1，動態把服務A的版本從1.0切換到1.1。

1.3 透過Postman或者瀏覽器，再執行第一步操作，如圖2，可以看到符合預期的呼叫路徑，透過版本切換，灰度訪問控製成功。

透過規則改變，達到灰度訪問控制，針對B服務：

2.1 透過Postman或者瀏覽器，執行POST http://localhost:1200/config/update-sync，傳送新的規則XML（內容見下麵）。

2.2 透過Postman或者瀏覽器，執行POST http://localhost:1201/config/update-sync，傳送新的規則XML（內容見下麵）。

2.3 上述操作也可以透過獨立控制檯，進行批次更新，見圖5。操作的邏輯：B服務的所有版本都只能訪問C服務3.0版本，而本例中C服務3.0版本是不存在的，意味著這麼做B服務不能訪問C服務。

2.4 重覆1.1步驟，發現呼叫路徑只有A服務->B服務，如圖3，透過規則改變，灰度訪問控製成功。

負載均衡的灰度測試：

3.1 透過Postman或者瀏覽器，執行POST http://localhost:1100/invoke，這是example內建的訪問路徑示例（透過Feign實現）。

3.2 重覆“透過版本切換，達到灰度訪問控制”或者“透過規則改變，達到灰度訪問控制”操作，檢視Ribbon負載均衡的灰度結果，如圖4。

上述操作，都是單次操作，如需要批次操作，可透過“獨立控制檯”介面，它整合批次操作和推送到遠端配置中心的功能，可以取代上面的某些呼叫方式。

其它更多操作，請參考“配置中心”、“管理中心”和“獨立控制檯”。

新XML規則：

<rule>
    <discovery>
        <version>
            <service consumer-service-name="discovery-springcloud-example-b" provider-service-name="discovery-springcloud-example-c" consumer-version-value="" provider-version-value="3.0"/>
        version>

    discovery>
rule>

圖 1：

圖 2：

圖 3：

圖 4：

圖 5：

基於閘道器的操作過程和效果：

• 在上面基礎上，啟動discovery-springcloud-example下DiscoveryApplicationZuul。

• 因為Zuul是一種特殊的微服務，所有操作過程跟上面完全一致。

圖 6：

圖 7：

Kubernetes專案實戰訓練營

Kubernetes專案實戰訓練將於2018年8月17日在深圳開課，3天時間帶你係統掌握Kubernetes。本次培訓包括：Docker介紹、Docker映象、網路、儲存、容器安全；Kubernetes架構、設計理念、常用物件、網路、儲存、網路隔離、服務發現與負載均衡；Kubernetes核心元件、Pod、外掛、微服務、雲原生、Kubernetes Operator、叢集災備、Helm等，點選下方圖片檢視詳情。