歡迎光臨
每天分享高質量文章

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等,點擊下方圖片查看詳情。

赞(0)

分享創造快樂