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。
1.jpg
2.jpg
更多教程和示例查看最下面的“示例演示”。 #痛点 现有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)可以不用下线,留作下次版本上线再次灰度发布。 架构图:
3.jpg
#兼容 ##版本兼容情况 * 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远程配置中心,则引入:

    com.nepxion
    discovery-plugin-starter-eureka
    ${discovery.plugin.version}



    com.nepxion
    discovery-plugin-starter-consul
    ${discovery.plugin.version}



    com.nepxion
    discovery-plugin-starter-zookeeper
    ${discovery.plugin.version}



    com.nepxion
    discovery-plugin-config-center-extension-nacos
    ${discovery.plugin.version}
独立控制台引入,最后一个如需对接Nacos远程配置中心,则引入

    com.nepxion
    discovery-console-starter
    ${discovery.plugin.version}



    com.nepxion
    discovery-console-extension-nacos
    ${discovery.plugin.version}
#工程
b1.png
#规则和策略 ##规则示例 请不要被吓到,我只是把注释写的很详细而已,里面配置没几行:


    
    
        
        
        
        
        
        
            
            
        

        

        
        
        
        
        
            
            
        
    

    
        
        
        
            
            
        

        
        
        
        
            
            
            
            
            
            
        
    
##多版本灰度规则策略 版本策略介绍: 1、标准配置,举例如下:
表示消费端1.0版本,允许访问提供端1.0和1.1版本。 2、版本值不配置,举例如下:
表示消费端任何版本,允许访问提供端1.0和1.1版本。
表示消费端1.0版本,允许访问提供端任何版本。
表示消费端任何版本,允许访问提供端任何版本。 3、版本值空字符串,举例如下:
表示消费端任何版本,允许访问提供端1.0和1.1版本。
表示消费端1.0版本,允许访问提供端任何版本。
表示消费端任何版本,允许访问提供端任何版本。 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界面,如下图:
4.jpg
#独立控制台 为UI提供相关接口,包括: * 一系列批量功能。 * 跟Nacos集成,实现配置推送和清除。 PORT端口号为server.port或者management.port都可以(management.port开放只支持3.x.x版本)。 ##控制台接口 参考Swagger界面,如下图:
5.jpg
#扩展和自定义更多规则或者监听 使用者可以继承如下类: * AbstractRegisterListener,实现服务注册的扩展和监听,用法参考discovery-springcloud-example下MyRegisterListener。 * AbstractDiscoveryListener,实现服务发现的扩展和监听,用法参考discovery-springcloud-example下MyDiscoveryListener。注意,在Consul下,同时会触发service和management两个实例的事件,需要区别判断,如下图。 * AbstractLoadBalanceListener,实现负载均衡的扩展和监听,用法参考discovery-springcloud-example下MyLoadBalanceListener。 集成了健康检查的Consul控制台。
6.jpg
#示例演示 ##场景描述 本例将模拟一个较为复杂的场景,如下图:
7.jpg
系统部署情况: * 网关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版本。 用规则来表述上述关系:


    
        
            
            
            
            
            
            
            
            
            
            
            
            
        
    
上述微服务分别见discovery-springcloud-example字样的8个DiscoveryApplication,分别对应各自的application.properties。这8个应用,对应的版本和端口号如下表:
b2.png
独立控制台见discovery-springcloud-example-console,对应的版本和端口号如下表:
b3.png
##开始演示 启动服务注册发现中心,默认是Eureka。可供选择的有Eureka,Zuul,Zookeeper。Eureka,请启动discovery-springcloud-example-eureka下的应用,后两者自行安装服务器。 根据上面选择的服务注册发现中心,对示例下的discovery-springcloud-example/pom.xml进行组件切换。

    com.nepxion
    discovery-plugin-starter-eureka
    
    
    ${discovery.plugin.version}
根据上面选择的服务注册发现中心,对控制台下的discovery-springcloud-example-console/pom.xml进行组件切换切换。

    org.springframework.cloud
    spring-cloud-starter-netflix-eureka-client
    
    
##服务注册过滤的操作演示 黑/白名单的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:
8.jpg
图 2:
9.jpg
图 3:
10.jpg
图 4:
11.jpg
图 5:
12.jpg
基于网关的操作过程和效果: * 在上面基础上,启动discovery-springcloud-example下DiscoveryApplicationZuul。 * 因为Zuul是一种特殊的微服务,所有操作过程跟上面完全一致。 图 6:
13.jpg
图7
14.jpg

0 个评论

要回复文章请先登录注册