Nepxion Discovery：Spring Cloud灰度发布神器

原文链接：http://dockone.io/article/8149

【编者的话】Nepxion Discovery是一款对Spring Cloud服务注册发现和负载均衡的增强中间件，其功能包括灰度发布（包括切换发布和平滑发布），黑/白名单的IP地址过滤，限制注册，限制发现等，支持Eureka、Consul和Zookeeper，支持Spring Cloud Api Gateway（Finchley版）、Zuul网关和微服务的灰度发布，支持用户自定义和编程灰度路由策略，支持多数据源的数据库灰度发布等客户特色化灰度发布，支持Nacos和Redis为远程配置中心，同时兼容Spring Cloud Edgware版和Finchley版。

现有Spring Cloud微服务痛点

1. 如果你是运维负责人，是否会经常发现，你掌管的测试环境中的服务注册中心，被一些不负责的开发人员把他本地开发环境注册上来，造成测试人员测试失败。你希望可以把本地开发环境注册给屏蔽掉，不让注册。
2. 如果你是运维负责人，生产环境的某个微服务集群下的某个实例，暂时出了问题，但又不希望它下线。你希望可以把该实例给屏蔽掉，暂时不让它被调用。
3. 如果你是业务负责人，鉴于业务服务的快速迭代性，微服务集群下的实例发布不同的版本。你希望根据版本管理策略进行路由，提供给下游微服务区别调用，例如访问控制快速基于版本的不同而切换，例如在不同的版本之间进行流量调拨。
4. 如果你是业务负责人，希望灰度发布功能可以基于业务场景特色定制，例如根据用户手机号进行不同服务器的路由。
5. 如果你是DBA负责人，希望灰度发布功能可以基于数据库切换上。
6. 如果你是测试负责人，希望对微服务做A/B测试，那么通过动态改变版本达到该目的。

 

Spring Cloud微服务痛点场景表现

黑/白名单的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的流量在B1和B2进行调拨。

多数据源的数据库灰度控制

我们事先为微服务配置多套数据源，通过灰度发布实时切换数据源。

动态改变微服务版本

在A/B测试中，通过动态改变版本，不重启微服务，达到访问版本的路径改变。

用户自定义和编程灰度路由策略，可以通过非常简单编程达到如下效果：

• 我们可以在网关上根据不同的Token查询到不同的用户，把请求路由到指定的服务器。
• 我们可以在服务上根据不同的业务参数，例如手机号或者身份证号，把请求路由到指定的服务器。

 

Nepxion Discovery概念和功能介绍

Nepxion Discovery是一款对Spring Cloud服务注册发现和负载均衡的增强中间件，其功能包括灰度发布（包括切换发布和平滑发布），黑/白名单的IP地址过滤，限制注册，限制发现等，支持Eureka、Consul和Zookeeper，支持Spring Cloud Api Gateway（Finchley版）、Zuul网关和微服务的灰度发布，支持用户自定义和编程灰度路由策略，支持Nacos和Redis为远程配置中心，同时兼容Spring Cloud Edgware版和Finchley版。

Nepxion Discovery包含功能：

实现对基于Spring Cloud的微服务和Spring Cloud Api Gateway（F版）和Zuul网关的支持：

1. 具有极大的灵活性——支持在任何环节做过滤控制和灰度发布。
2. 具有极小的限制性——只要开启了服务注册发现，程序入口加了@EnableDiscoveryClient。
3. 具有极强的可用性——当远程配置中心全部挂了，可以通过Rest方式进行灰度发布。

实现服务注册层面的控制：

1. 基于黑/白名单的IP地址过滤机制禁止对相应的微服务进行注册。
2. 基于最大注册数的限制微服务注册。一旦微服务集群下注册的实例数目已经达到上限，将禁止后续的微服务进行注册。

实现服务发现层面的控制：

1. 基于黑/白名单的IP地址过滤机制禁止对相应的微服务被发现。
2. 基于版本号配对，通过对消费端和提供端可访问版本对应关系的配置，在服务发现和负载均衡层面，进行多版本访问控制。
3. 基于版本权重配对，通过对消费端和提供端版本权重（流量）对应关系的配置，在服务发现和负载均衡层面，进行多版本流量调拨访问控制。

实现灰度发布：

1. 通过版本的动态改变，实现切换灰度发布。
2. 通过版本访问规则的改变，实现切换灰度发布。
3. 通过版本权重规则的改变，实现平滑灰度发布。

实现通过XML或者Json进行上述规则的定义。

实现通过事件总线机制（EventBus）的功能，实现发布/订阅功能：

1. 对接远程配置中心，集成Nacos和Redis，异步接受远程配置中心主动推送规则信息，动态改变微服务的规则。
2. 结合Spring Boot Actuator，异步接受Rest主动推送规