SpringCloud系列：Spring Cloud微服务版本灰度发布新神器秒杀架构实践

Spring Cloud微服务版本灰度发布新神器

任浩军 方志朋  2018-07-22

项目地址：https://github.com/Nepxion/Discovery 

强烈建议stra、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，获取更清晰的视频

§ 更多教程和示例查看最下面的“示例演示”，

痛点

现有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格式的配置中心，可以包括不限于Apollo，DisConf，Spring Cloud Config

场景

§ 黑/白名单的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远程配置中心，则引入

1.   <dependency>

2.       <groupId>com.nepxion</groupId>

3.       <artifactId>discovery-plugin-starter-eureka</artifactId>

4.       <version>${discovery.plugin.version}</version>

5.   </dependency>

6.

7.   <dependency>

8.       <groupId>com.nepxion</groupId>

9.       <artifactId>discovery-plugin-starter-consul</artifactId>

10.      <version>${discovery.plugin.version}</version>

11.  </dependency>

12.

13.  <dependency>

14.      <groupId>com.nepxion</groupId>

15.      <artifactId>discovery-plugin-starter-zookeeper</artifactId>

16.      <version>${discovery.plugin.version}</version>

17.  </dependency>

18.

19.  <dependency>

20.      <groupId>com.nepxion</groupId>

21.      <artifactId>discovery-plugin-config-center-extension-nacos</artifactId>

22.      <version>${discovery.plugin.version}</version>

23.  </dependency>

独立控制台引入，最后一个如需对接Nacos远程配置中心，则引入

1.   <dependency>

2.       <groupId>com.nepxion</groupId>

3.       <artifactId>discovery-console-starter</artifactId>

4.       <version>${discovery.plugin.version}</version>

5.   </dependency>

6.

7.   <dependency>

8.       <groupId>com.nepxion</groupId>

9.       <artifactId>discovery-console-extension-nacos</artifactId>

10.      <version>${discovery.plugin.version}</version>

11.  </dependency>

工程

规则和策略

规则示例

请不要被吓到，我只是把注释写的很详细而已，里面配置没几行

1.   <?xml version="1.0"encoding="UTF-8"?>

2.   <rule>

3.       <!-- 如果不想开启相关功能，只需要把相关节点删除即可，例如不想要黑名单功能，把blacklist节点删除-->

4.       <register>

5.           <!-- 服务注册的黑/白名单注册过滤，只在服务启动的时候生效。白名单表示只允许指定IP地址前缀注册，黑名单表示不允许指定IP地址前缀注册。每个服务只能同时开启要么白名单，要么黑名单-->

6.           <!-- filter-type，可选值blacklist/whitelist，表示白名单或者黑名单-->

7.           <!-- service-name，表示服务名-->

8.           <!-- filter-value，表示黑/白名单的IP地址列表。IP地址一般用前缀来表示，如果多个用“;”分隔，不允许出现空格-->

9.           <!-- 表示下面所有服务，不允许10.10和11.11为前缀的IP地址注册（全局过滤）-->

10.          <blacklistfilter-value="10.10;11.11">

11.              <!-- 表示下面服务，不允许172.16和10.10和11.11为前缀的IP地址注册-->

12.              <serviceservice-name="discovery-springcloud-example-a"filter-value="172.16"/>

13.          </blacklist>

14.

15.          <!-- <whitelist filter-value="">

16.              <service service-name="" filter-value=""/>

17.          </whitelist>  -->

18.

19.          <!-- 服务注册的数目限制注册过滤，只在服务启动的时候生效。当某个服务的实例注册达到指定数目时候，更多的实例将无法注册-->

20.          <!-- service-name，表示服务名-->

21.          <!-- filter-value，表示最大实例注册数-->

22.          <!-- 表示下面所有服务，最大实例注册数为10000（全局配置）-->

23.          <countfilter-value="10000">

24.              <!-- 表示下面服务，最大实例注册数为5000，全局配置值10000将不起作用，以局部配置值为准-->

25.              <serviceservice-name="discovery-springcloud-example-a"filter-value="5000"/>

26.          </count>

27.      </register>

28.

29.      <discovery>

30.          <!-- 服务发现的黑/白名单发现过滤，使用方式跟“服务注册的黑/白名单过滤”一致-->

31.          <!-- 表示下面所有服务，不允许10.10和11.11为前缀的IP地址被发现（全局过滤）-->

32.          <blacklistfilter-value="10.10;11.11">

33.              <!-- 表示下面服务，不允许172.16和10.10和11.11为前缀的IP地址被发现-->

34.              <serviceservice-name="discovery-springcloud-example-b"filter-value="172.16"/>

35.          </blacklist>

36.

37.          <!-- 服务发现的多版本灰度访问控制-->

38.          <!-- service-name，表示服务名-->

39.          <!-- version-value，表示可供访问的版本，如果多个用“;”分隔，不允许出现空格-->

40.          <version>

41.              <!-- 表示消费端服务a的1.0，允许访问提供端服务b的1.0和1.1版本-->

42.              <serviceconsumer-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"/>

43.              <!-- 表示消费端服务b的1.0，允许访问提供端服务c的1.0和1.1版本-->

44.              <serviceconsumer-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"/>

45.              <!-- 表示消费端服务b的1.1，允许访问提供端服务c的1.2版本-->

46.              <serviceconsumer-service-name="discovery-springcloud-example-b"provider-service-name="discovery-springcloud-example-c"consumer-version-value="1.1"provider-version-value="1.2"/>

47.          </version>

48.      </discovery>

49.  </rule>

多版本灰度规则策略

1.   版本策略介绍

2.   1. 标准配置，举例如下

3.      <serviceconsumer-service-name="a"provider-service-name="b"consumer-version-value="1.0"provider-version-value="1.0,1.1"/>表示消费端1.0版本，允许访问提供端1.0和1.1版本

4.   2. 版本值不配置，举例如下

5.      <serviceconsumer-service-name="a"provider-service-name="b"provider-version-value="1.0,1.1"/>表示消费端任何版本，允许访问提供端1.0和1.1版本

6.      <serviceconsumer-service-name="a"provider-service-name="b"consumer-version-value="1.0"/>表示消费端1.0版本，允许访问提供端任何版本

7.      <serviceconsumer-service-name="a"provider-service-name="b"/>表示消费端任何版本，允许访问提供端任何版本

8.   3. 版本值空字符串，举例如下

9.      <serviceconsumer-service-name="a"provider-service-name="b"consumer-version-value=""provider-version-value="1.0,1.1"/>表示消费端任何版本，允许访问提供端1.0和1.1版本

10.     <serviceconsumer-service-name="a"provider-service-name="b"consumer-version-value="1.0"provider-version-value=""/>表示消费端1.0版本，允许访问提供端任何版本

11.     <serviceconsumer-service-name="a"provider-service-name="b"consumer-version-value=""provider-version-value=""/>表示消费端任何版本，允许访问提供端任何版本

12.  4. 版本对应关系未定义，默认消费端任何版本，允许访问提供端任何版本

13.

14.  特殊情况处理，在使用上需要极力避免该情况发生

15.  1. 消费端的application.properties未定义版本号，则该消费端可以访问提供端任何版本

16.  2. 提供端的application.properties未定义版本号，当消费端在xml里不做任何版本配置，才可以访问该提供端

动态改变规则策略

微服务启动的时候，由于规则（例如：rule.xml）已经配置在本地，使用者希望改变一下规则，而不重启微服务，达到规则的改变

§ 规则分为本地规则和动态规则

§ 本地规则是通过在本地规则（例如：rule.xml）文件定义的，也可以从远程配置中心获取，在微服务启动的时候读取

§ 动态规则是通过POST方式动态设置，或者由远程配置中心推送设置

§ 规则初始化的时候，如果接入了远程配置中心，先读取远程规则，如果不存在，再读取本地规则文件

§ 多规则灰度获取规则的时候，先获取动态规则，如果不存在，再获取本地规则

动态改变版本策略

微服务启动的时候，由于版本已经写死在application.properties里，使用者希望改变一下版本，而不重启微服务，达到访问版本的路径改变

§ 版本分为本地版本和动态版本

§ 本地版本是通过在application.properties里配置的，在微服务启动的时候读取

§ 动态版本是通过POST方式动态设置

§ 多版本灰度获取版本值的时候，先获取动态版本，如果不存在，再获取本地版本

黑/白名单的IP地址注册的过滤策略

微服务启动的时候，禁止指定的IP地址注册到服务注册发现中心。支持黑/白名单，白名单表示只允许指定IP地址前缀注册，黑名单表示不允许指定IP地址前缀注册

§ 全局过滤，指注册到服务注册发现中心的所有微服务，只有IP地址包含在全局过滤字段的前缀中，都允许注册（对于白名单而言），或者不允许注册（对于黑名单而言）

§ 局部过滤，指专门针对某个微服务而言，那么真正的过滤条件是全局过滤+局部过滤结合在一起

最大注册数的限制的过滤策略

微服务启动的时候，一旦微服务集群下注册的实例数目已经达到上限（可配置），将禁止后续的微服务进行注册

§ 全局配置值，只下面配置所有的微服务集群，最多能注册多少个

§ 局部配置值，指专门针对某个微服务而言，那么该值如存在，全局配置值失效

黑/白名单的IP地址发现的过滤策略

微服务启动的时候，禁止指定的IP地址被服务发现。它使用的方式和“黑/白名单的IP地址注册的过滤”一致

版本属性字段定义策略

不同的服务注册发现组件对应的版本配置值

1.   # Eureka config

2.   eureka.instance.metadataMap.version=1.0

3.   eureka.instance.metadataMap.group=xxx-service-group

4.

5.   # 奇葩的Consul配置（参考https://springcloud.cc/spring-cloud-consul.html - 元数据和Consul标签）

6.   # Consul config（多个值用“,”分隔，例如version=1.0,value=abc）

7.   spring.cloud.consul.discovery.tags=version=1.0,group=xxx-service-group

8.

9.   # Zookeeper config

10.  spring.cloud.zookeeper.discovery.metadata.version=1.0

11.  spring.cloud.zookeeper.discovery.metadata.group=xxx-service-group

功能开关策略

1.   # Plugin config

2.   # 开启和关闭服务注册层面的控制。一旦关闭，服务注册的黑/白名单过滤功能将失效，最大注册数的限制过滤功能将失效。缺失则默认为true

3.   spring.application.register.control.enabled=true

4.   # 开启和关闭服务发现层面的控制。一旦关闭，服务多版本调用的控制功能将失效，动态屏蔽指定IP地址的服务实例被发现的功能将失效。缺失则默认为true

5.   spring.application.discovery.control.enabled=true

6.   # 开启和关闭通过Rest方式对规则配置的控制和推送。一旦关闭，只能通过远程配置中心来控制和推送。缺失则默认为true

7.   spring.application.config.rest.control.enabled=true

8.   # 本地规则文件的路径，支持两种方式：classpath:rule.xml - 规则文件放在resources目录下，便于打包进jar；file:rule.xml - 规则文件放在工程根目录下，放置在外部便于修改。缺失则默认为不装载本地规则

9.   spring.application.config.path=classpath:rule.xml

10.  # 为微服务归类的Key，一般通过group字段来归类，例如eureka.instance.metadataMap.group=xxx-group或者eureka.instance.metadataMap.application=xxx-application。缺失则默认为group

11.  # spring.application.group.key=group

12.  # 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，实现服务注册的扩展和监听

§ AbstractDiscoveryListener，实现服务发现的扩展和监听，注意，在Consul下，同时会触发service和management两个实例的事件，需要区别判断，如下图

集成了健康检查的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版本

用规则来表述上述关系

1.   <?xml version="1.0"encoding="UTF-8"?>

2.   <rule>

3.       <discovery>

4.           <version>

5.               <!-- 表示网关z的1.0，允许访问提供端服务a的1.0版本-->

6.               <serviceconsumer-service-name="discovery-springcloud-example-zuul"provider-service-name="discovery-springcloud-example-a"consumer-version-value="1.0"provider-version-value="1.0"/>

7.               <!-- 表示网关z的1.1，允许访问提供端服务a的1.1版本-->

8.               <serviceconsumer-service-name="discovery-springcloud-example-zuul"provider-service-name="discovery-springcloud-example-a"consumer-version-value="1.1"provider-version-value="1.1"/>

9.               <!-- 表示消费端服务a的1.0，允许访问提供端服务b的1.0版本-->

10.              <serviceconsumer-service-name="discovery-springcloud-example-a"provider-service-name="discovery-springcloud-example-b"consumer-version-value="1.0"provider-version-value="1.0"/>

11.              <!-- 表示消费端服务a的1.1，允许访问提供端服务b的1.1版本-->

12.              <serviceconsumer-service-name="discovery-springcloud-example-a"provider-service-name="discovery-springcloud-example-b"consumer-version-value="1.1"provider-version-value="1.1"/>

13.              <!-- 表示消费端服务b的1.0，允许访问提供端服务c的1.0和1.1版本-->

14.              <serviceconsumer-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"/>

15.              <!-- 表示消费端服务b的1.1，允许访问提供端服务c的1.2版本-->

16.              <serviceconsumer-service-name="discovery-springcloud-example-b"provider-service-name="discovery-springcloud-example-c"consumer-version-value="1.1"provider-version-value="1.2"/>

17.          </version>

18.      </discovery>

19.  </rule>

上述微服务分别见discovery-springcloud-example字样的8个DiscoveryApplication，分别对应各自的application.properties。这8个应用，对应的版本和端口号如下表

独立控制台见discovery-springcloud-example-console，对应的版本和端口号如下表

开始演示

§ 启动服务注册发现中心，默认是Eureka。可供选择的有Eureka，Zuul，Zookeeper。Eureka，请启动discovery-springcloud-example-eureka下的应用，后两者自行安装服务器

§ 根据上面选择的服务注册发现中心，对示例下的discovery-springcloud-example/pom.xml进行组件切换

1.   <dependency>

2.       <groupId>com.nepxion</groupId>

3.       <artifactId>discovery-plugin-starter-eureka</artifactId>

4.       <!-- <artifactId>discovery-plugin-starter-consul</artifactId> -->

5.       <!-- <artifactId>discovery-plugin-starter-zookeeper</artifactId> -->

6.       <version>${discovery.plugin.version}</version>

7.   </dependency>

§ 根据上面选择的服务注册发现中心，对控制台下的discovery-springcloud-example-console/pom.xml进行组件切换切换

1.   <dependency>

2.       <groupId>org.springframework.cloud</groupId>

3.       <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>

4.       <!-- <artifactId>spring-cloud-starter-consul-discovery</artifactId> -->

5.       <!-- <artifactId>spring-cloud-starter-zookeeper-discovery</artifactId> -->

6.   </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规则

1.   <?xml version="1.0"encoding="UTF-8"?>

2.   <rule>

3.       <discovery>

4.           <version>

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

6.           </version>

7.       </discovery>

8.   </rule>

基于网关的操作过程和效果

§ 在上面基础上，启动discovery-springcloud-example下DiscoveryApplicationZuul

§ 因为Zuul是一种特殊的微服务，所有操作过程跟上面完全一致

§  

项目地址：https://github.com/Nepxion/Discovery 

强烈建议stra、fork该项目，该项目可以作为学习改造Spring Cloud组件的案例项目。

原创作者：方志朋

方志朋简介：SpringCloud中国社区联合创始人，博客访问量突破一千万，爱好开源，热爱分享，活跃于各大社区，保持着非常强的学习驱动力，终身学习践行者，终身学习受益者。目前就职于国内某家知名互联网保险公司，担任DEVOPS工程师，对微服务领域和持续集成领域研究较深，精通微服务框架SpringCloud