微服务架构—服务增强组件Nepxion Discovery - 好文

Nepxion Discovery是一款对Spring
Cloud的服务注册发现的增强中间件，其功能包括多版本灰度发布，黑/白名单的IP地址过滤，限制注册等，支持Eureka、Consul和Zookeeper，Spring
Cloud微服务可以方便引入该插件，并且代码零侵入，引入注意事项如下：

* 引入相关Plugin Starter依赖到pom.xml
* 必须为微服务定义一个版本号（version），在application.properties或者yaml里
*
必须为微服务自定义一个便于为微服务归类的Key，例如组名（group）或者应用名（application），在application.properties或者yaml的metadata里，便于远程配置中心推送和灰度界面分析
*
使用者只需要关注相关规则推送。可以采用如下方式之一

* 通过远程配置中心推送规则
* 通过控制台界面推送规则
Nepxion Discovery优势

* 基于Spring Cloud的微服务和Zuul网关的支持
* 具有极大灵活性 - 支持在任何环节做过滤控制和版本灰度发布
* 具有极小限制性 - 只要开启了服务注册发现，程序入口加了@EnableDiscoveryClient
实现服务注册层面的控制
* 基于黑/白名单的IP地址过滤机制禁止对相应的微服务进行注册
* 基于最大注册数的限制微服务注册。一旦微服务集群下注册的实例数目已经达到上限，将禁止后续的微服务进行注册
* 基于黑/白名单的IP地址过滤机制禁止对相应的微服务被发现
* 基于版本配对，通过对消费端和提供端可访问版本对应关系的配置，在服务发现和负载均衡层面，进行多版本访问控制
* 实现灰度发布
* 实现通过事件总线机制（EventBus）的功能，实现发布/订阅功能
* 对接远程配置中心，默认集成阿里巴巴的Nacos，异步接受远程配置中心主动推送规则信息，动态改变微服务的规则
* 结合Spring Boot Actuator，异步接受Rest主动推送规则信息，动态改变微服务的规则
* 使用者可以自定义更多的规则过滤条件
* 实现图形化的灰度发布功能
pom依赖

微服务选择相应的插件引入，最后一个如需对接Nacos远程配置中心，则引入
<dependency> <groupId>com.nepxion</groupId> <artifactId>
discovery-plugin-starter-eureka</artifactId> <version>
${discovery.plugin.version}</version> </dependency> <dependency> <groupId>
com.nepxion</groupId> <artifactId>discovery-plugin-starter-consul</artifactId> <
version>${discovery.plugin.version}</version> </dependency> <dependency> <
groupId>com.nepxion</groupId> <artifactId>discovery-plugin-starter-zookeeper</
artifactId> <version>${discovery.plugin.version}</version> </dependency> <
dependency> <groupId>com.nepxion</groupId> <artifactId>
discovery-plugin-config-center-extension-nacos</artifactId> <version>
${discovery.plugin.version}</version> </dependency>
独立控制台引入，最后一个如需对接Nacos远程配置中心，则引入
<dependency> <groupId>com.nepxion</groupId> <artifactId>
discovery-console-starter</artifactId> <version>${discovery.plugin.version}</
version> </dependency> <dependency> <groupId>com.nepxion</groupId> <artifactId>
discovery-console-extension-nacos</artifactId> <version>
${discovery.plugin.version}</version> </dependency>
工程

规则和策略
<?xml version="1.0" encoding="UTF-8"?> <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" providerservice-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. 标准配置，举例如下 <service consumer-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版本 2. 版本值不配置，举例如下 <service consumer-service-name="a" provider
-service-name="b" provider-version-value="1.0,1.1"/> 表示消费端任何版本，允许访问提供端1.0和1.1版本
<service consumer-service-name="a" provider-service-name="b" consumer-version
-value="1.0"/> 表示消费端1.0版本，允许访问提供端任何版本 <service consumer-service-name="a"
provider-service-name="b"/> 表示消费端任何版本，允许访问提供端任何版本 3. 版本值空字符串，举例如下 <service
consumer-service-name="a" provider-service-name="b" consumer-version-value=""
provider-version-value="1.0,1.1"/> 表示消费端任何版本，允许访问提供端1.0和1.1版本 <service consumer
-service-name="a" provider-service-name="b" consumer-version-value="1.0"
provider-version-value=""/> 表示消费端1.0版本，允许访问提供端任何版本 <service consumer-service
-name="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地址注册的过滤”一致

版本属性字段定义策略

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

功能开关策略
#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
项目地址：https://github.com/Nepxion/Discovery
<https://github.com/Nepxion/Discovery>

热门工具换一换