一种基于Spring Cloud的微服务灰度发布方法
技术领域
本申请涉及计算机技术领域,特别涉及一种基于Spring Cloud的微服务灰度发布方法、装置、设备及系统。
背景技术
互联网企业产品形态包括两种,一种是2C的互联网产品,另一种是2B的内部业务支撑系统。2C的互联网产品的特点是面向广大用户,需要一天24小时提供服务,系统可用率要求高,经常以版本的方式进行升级。2B的业务支撑系统面向企业内部的运营人员,业务复杂多变,用户少并且是面向内部用户,经常以更新的方式来进行升级。
基于业务需求,系统升级时不能影响正在运行的线上服务,为了减少发布风险,一般引入灰度发布机制,即,让新版本在灰度环境下验证运行,验证通过后再正式对外提供服务。前述两种系统都是需要发布系统进行升级的,因此,需要一种企业级灰度发布方案来既满足互联网产品的高可用要求,同时满足业务支撑系统高发布频率的要求。
除此之外,微服务是近年来非常热门的一种架构,相对于单体架构,微服务架构将一个系统会拆分成多个独立的服务,不同服务之间通过RPC调用进行通信,从而帮助企业把复杂的系统拆解,降低复杂度。
传统的灰度发布过程包括以下两种方式:
1、搭建一套全量灰度环境
2、利用nginx或者微服务网关进行灰度路由
搭建全量灰度环境在单体架构下是可行的,因为一个系统就一种服务可以部署,但是在微服务架构下,一个系统可能依赖上十个服务,同时微服务架构有注册中心、网关、配置中心等基础设施,每个服务和基础设施都搭建一个灰度环境成本很高。利用nginx或者微服务网关进行灰度路由,虽然能有效解决从外面访问系统的灰度控制,但微服务架构有大量的服务间内部调用,服务间内部调用是不走网关的。
综上,如何提供一种灰度发布方案,同时满足互联网产品和业务支撑系统的需求,实现网关到服务以及服务与服务之间的灰度发布过程,避免成本较高,是亟待本领域技术人员解决的问题。
发明内容
本申请的目的是提供一种基于Spring Cloud的微服务灰度发布方法、装置、设备及系统,用以解决传统灰度发布方案或无法同时满足互联网产品和业务支撑系统的需求,或无法同时实现网关到服务以及服务与服务之间的灰度发布,或成本较高的问题。其具体方案如下:
第一方面,本申请提供了一种基于Spring Cloud的微服务灰度发布方法,包括:
确定目标服务以及所述目标服务的目标实例;
若所述目标服务为前台服务,则将新版本服务发布至所述目标服务的所述目标实例,并确定所述新版本服务的目标版本号;
若所述目标服务为后台服务,则将新版本服务发布至所述目标服务的所述目标实例,并将所述目标实例的区域参数设置为灰度标志位,以表征所述目标实例位于灰度区域中;
利用网关获取前端应用请求,若所述前端应用请求包括所述目标版本号,则根据所述目标版本号进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;若所述前端应用请求包括所述灰度标志位,则在所述灰度区域进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;
若验证通过,则将所述新版本服务发布至所述目标服务的全部实例,否则将所述目标实例切换回旧版本服务,以结束灰度发布。
优选的,在所述将所述目标实例的区域参数设置为灰度标志位之后,还包括:
将中继服务的中继实例的区域参数设置为灰度标志位,以作为从所述网关到所述目标实例的路由中继。
优选的,在所述将所述目标实例的区域参数设置为灰度标志位之后,包括:
在所述灰度环境验证结束之后,将所述目标实例和所述中继实例的区域参数修改为默认值。
优选的,所述根据所述目标版本号进行路由以将所述前端应用请求转发至所述目标实例,包括:
利用所述网关将所述前端应用请求发送至中继服务,所述中继服务调用所述目标服务,以将所述前端应用请求转发至所述目标服务;利用所述目标服务根据所述目标版本号将所述前端应用请求转发至自身的目标实例。
优选的,在所述利用网关获取前端应用请求之前,还包括:
根据配置中心的灰度路由规则,利用前端应用组装以所述目标版本号或所述灰度标志位为请求头的前端应用请求。
优选的,所述配置中心为Apollo,所述网关为zuul。
第二方面,本申请提供了一种基于Spring Cloud的微服务灰度发布装置,包括:
目标确定模块:用于确定目标服务以及所述目标服务的目标实例;
第一发布模块:用于若所述目标服务为前台服务,则将新版本服务发布至所述目标服务的所述目标实例,并确定所述新版本服务的目标版本号;
第二发布模块:用于若所述目标服务为后台服务,则将新版本服务发布至所述目标服务的所述目标实例,并将所述目标实例的区域参数设置为灰度标志位,以表征所述目标实例位于灰度区域中;
验证模块:用于利用网关获取前端应用请求,若所述前端应用请求包括所述目标版本号,则根据所述目标版本号进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;若所述前端应用请求包括所述灰度标志位,则在所述灰度区域进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;
发布结果模块:用于若验证通过,则将所述新版本服务发布至所述目标服务的全部实例,否则将所述目标实例切换回旧版本服务,以结束灰度发布。
第三方面,本申请提供了一种基于Spring Cloud的微服务灰度发布设备,包括:
存储器:用于存储计算机程序;
处理器:用于执行所述计算机程序,以实现如上所述的基于Spring Cloud的微服务灰度发布方法的步骤。
第四方面,本申请提供了一种基于Spring Cloud的微服务灰度发布系统,包括:服务发布模块、前端应用模块、网关;
其中,所述服务发布模块用于确定目标服务以及所述目标服务的目标实例;若所述目标服务为前台服务,则将新版本服务发布至所述目标服务的所述目标实例,并确定所述新版本服务的目标版本号;若所述目标服务为后台服务,则将新版本服务发布至所述目标服务的所述目标实例,并将所述目标实例的区域参数设置为灰度标志位,以表征所述目标实例位于灰度区域中;
所述前端应用模块用于生成前端应用请求,并将所述前端应用请求发送至所述网关;
所述网关用于在所述前端应用请求包括所述目标版本号时,根据所述目标版本号进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;在所述前端应用请求包括所述灰度标志位时,在所述灰度区域进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;
所述发布系统还用于在验证通过时,将所述新版本服务发布至所述目标服务的全部实例,在验证不通过时,将所述目标实例切换回旧版本服务,以结束灰度发布。
优选的,还包括配置中心,所述配置中心用于将灰度路由规则推送至所述前端应用模块,以便所述前端应用模块根据所述灰度路由规则生成前端应用请求。
本申请所提供的一种基于Spring Cloud的微服务灰度发布方法、装置、设备及系统,方案包括:确定目标服务以及目标实例;若目标服务为前台服务,则将新版本服务发布至目标实例,并确定新版本服务的目标版本号;若目标服务为后台服务,则将新版本服务发布至目标实例,并将目标实例的区域参数设置为灰度标志位,以表征目标实例位于灰度区域中;利用网关获取前端应用请求,若前端应用请求包括目标版本号,则根据目标版本号进行路由以将前端应用请求转发至目标实例,以进行灰度环境验证;若前端应用请求包括灰度标志位,则在灰度区域进行路由以将前端应用请求转发至目标实例,以进行灰度环境验证;若验证通过,则将新版本服务发布至目标服务的全部实例,否则将目标实例切换回旧版本服务,以结束灰度发布。
可见,该方案针对互联网产品的前台服务和业务支撑系统的后台服务,设置了两种灰度发布策略,其中,针对前台服务根据版本进行升级的特点,设置了基于版本的灰度发布策略;针对后台服务不根据版本进行升级的特点,设置了基于区域的灰度发布策略。因此,实现了灵活适应两种系统形态下的灰度发布过程。此外,在这两种灰度发布策略中,该方案根据版本号或灰度标志位进行灰度路由,不仅实现了网关到服务之间的灰度发布过程,还实现了服务与服务之间的灰度发布过程,提升了方案的场景适应力。最后,在微服务架构中,该方案无需针对每个服务分别设置灰度发布系统,节省了灰度发布过程的成本。
附图说明
为了更清楚的说明本申请实施例或现有技术的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请所提供的一种基于Spring Cloud的微服务灰度发布方法实施例一的实现流程图;
图2为本申请所提供的一种基于Spring Cloud的微服务灰度发布方法实施例二的实现流程图;
图3为本申请所提供的基于版本发布的特定场景下的灰度发布过程示意图;
图4为本申请所提供的基于区域发布的特定场景下的灰度发布过程示意图;
图5为本申请所提供的一种基于Spring Cloud的微服务灰度发布装置实施例的功能框图;
图6为本申请所提供的一种基于Spring Cloud的微服务灰度发布设备实施例的结构示意图;
图7为本申请所提供的一种基于Spring Cloud的微服务灰度发布系统实施例的系统架构示意图。
具体实施方式
本申请的核心是提供一种基于Spring Cloud的微服务灰度发布方法、装置、设备及系统,通过分别设置适用于前台服务的基于版本的灰度发布策略,以及适用于后台服务的基于区域的灰度发布策略,且根据版本号或灰度标志位进行灰度路由,实现了灵活适应两种系统形态下的灰度发布过程,且提升场景适应力的目的。
为了使本技术领域的人员更好地理解本申请方案,下面结合附图和具体实施方式对本申请作进一步的详细说明。显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
下面对本申请提供的一种基于Spring Cloud的微服务灰度发布方法实施例一进行介绍,参见图1,实施例一包括:
S101、确定目标服务以及所述目标服务的目标实例;
S102、若所述目标服务为前台服务,则将新版本服务发布至所述目标服务的所述目标实例,并确定所述新版本服务的目标版本号;
S103、若所述目标服务为后台服务,则将新版本服务发布至所述目标服务的所述目标实例,并将所述目标实例的区域参数设置为灰度标志位,以表征所述目标实例位于灰度区域中;
S104、利用网关获取前端应用请求,若所述前端应用请求包括所述目标版本号,则根据所述目标版本号进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;若所述前端应用请求包括所述灰度标志位,则在所述灰度区域进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;
S105、若验证通过,则将所述新版本服务发布至所述目标服务的全部实例,否则将所述目标实例切换回旧版本服务,以结束灰度发布。
本实施例主要用于实现灰度发布,灰度发布是在系统升级领域中的一种可以平滑切换升级方式,其基本原理为当有些服务器的需要升级时,可以先升级其中的部分服务器,并进行测试,如若评估测试结果正常,再升级其他的服务器。
如前文所述,互联网企业产品形态包括两种,一种是2C(to consumer,面向用户)的互联网产品,另一种是2B(to business,面向企业)的内部业务支撑系统。其中,2C的互联网产品是按版本进行发布的,而2B的内部业务支撑系统一般不按照版本来发布,因为内部系统发布频繁,使用人员时企业内部人员,不需要进行统一的版本管理。在Spring Cloud框架下,互联网产品和内部业务支撑系统分别包括多项服务,此处的服务可以理解为执行特定功能的软件及其硬件设备。本实施例中,前台服务是指互联网产品的服务,后台服务是指内部业务支撑系统的服务。
针对上述前台服务和后台服务的升级特点,本实施例扩展了负载均衡模块的负载均衡策略,以实现同时支持基于版本的灰度发布过程和基于区域的灰度发布过程。其中,版本(version),是指每个系统发布时会有的一个版本号,前端发出请求时会默认带上这个版本号;区域(region),是为了区分服务的灰度实例和正常实例所设置的一种属性。作为一种具体的实施方式,可以通过对Ribbon进行扩展以实现对上述两种灰度发布过程的支持,其中,Ribbon为Spring Cloud框架下的一个负载均衡模块,用于网关到微服务、微服务与微服务之间,对RPC调用进行负载均衡。
一般来说,一个服务会具备一个或多个实例,本实施例中的目标服务是指待进行系统升级的服务,目标服务的目标实例是指目标服务中预期部署新版本服务的实例。基于以上,下面分别对基于版本的灰度发布过程和基于区域的灰度发布过程进行介绍:
首先,基于版本的灰度发布过程,适用于前台服务。在灰度发布过程中,首先判断目标服务是否为前台服务,若是,则将新版本服务发布至目标实例,并确定新版本服务的目标版本号。发布完成后,等待目标实例启动,在目标实例启动之后,即可进行灰度环境验证。具体的,告知前端应用当前的灰度路由策略,即利用前端应用组装包括目标版本号的请求,以作为前端应用请求,这里的前端应用可以为PC端页面、小程序等,请求组装过程具体可以将目标版本号作为请求的请求头。然后,将前端应用请求发送至网关,网关及中继实例就会根据前述扩展得到的负载均衡策略将前端应用请求转发至目标实例中,从而实现灰度环境验证。其中,中继实例是指根据业务流程确定的请求从网关到目标实例之间经过的实例,可以理解的是,在灰度发布过程中,中继实例是否存在是不一定的,其存在与否主要根据业务流程确定。
再者,基于区域的灰度发布过程,适用于后台服务。在灰度发布过程中,首先判断目标服务是否为后台服务,若是,则将新版本服务发布至目标实例,并将目标实例的区域参数设置为灰度标志位,以表征目标实例位于灰度区域中。值得一提的是,如果从前端应用请求到目标实例的路由中存在中继实例,则需要将中继实例的区域参数也设置为灰度标志位。新版本服务发布完成后,等待目标实例启动,在目标实例启动之后,即可进行灰度环境验证。具体的,告知前端应用当前的灰度路由策略,即利用前端应用组装包括灰度标志位的请求,以作为前端应用请求,同样的,请求组装过程具体可以将灰度标志位作为请求的请求头。然后,将前端应用请求发送至网关,网关及中继实例就会根据前述扩展得到的负载均衡策略将前端应用请求转发至目标实例中,从而实现灰度环境验证。需要说明的是,在基于区域的灰度发布过程中,在灰度环境验证完成之后,需要将目标实例及中继实例的区域参数恢复到默认值。
上述网关是指微服务网关,具体可以选用zuul,zuul是spring cloud框架下一个常用的微服务网关,用于外部访问系统的入口。另外,上述灰度环境验证是否通过的评价标准可以根据实际需求来确定,本实施例不做限定。
本实施例所提供一种基于Spring Cloud的微服务灰度发布方法,分别针对互联网产品的前台服务和业务支撑系统的后台服务,设置了基于版本的灰度发布策略和基于区域的灰度发布策略,实现了灵活适应两种系统形态下的灰度发布过程。此外,在这两种灰度发布策略中,该方案分别根据版本号和灰度标志位进行灰度路由,不仅实现了网关到服务之间的灰度发布过程,还实现了服务与服务之间的灰度发布过程,提升了方案的场景适应力。
下面开始详细介绍本申请提供的一种基于Spring Cloud的微服务灰度发布方法实施例二,实施例二基于前述实施例一实现,且在实施例一的基础上进行了一定程度上的拓展。
参见图2,实施例二具体包括:
S201、确定目标服务以及所述目标服务的目标实例;
S202、若所述目标服务为前台服务,则将新版本服务发布至所述目标实例,并确定所述新版本服务的目标版本号;
S203、若所述目标服务为后台服务,则将新版本服务发布至所述目标实例,并将所述目标实例的区域参数设置为灰度标志位,以表征所述目标实例位于灰度区域中;将中继服务的中继实例的区域参数设置为灰度标志位,以作为从所述网关到所述目标实例的路由中继;
S204、根据配置中心的灰度路由规则,利用前端应用组装以所述目标版本号或所述灰度标志位为请求头的前端应用请求,并发送至网关;
S205、若所述前端应用请求包括所述目标版本号,则根据所述目标版本号进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;
具体的,利用所述网关将所述前端应用请求发送至中继服务,所述中继服务调用所述目标服务,以将所述前端应用请求转发至所述目标服务;利用所述目标服务根据所述目标版本号将所述前端应用请求转发至自身的目标实例。
S206、若所述前端应用请求包括所述灰度标志位,则在所述灰度区域进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;在所述灰度环境验证结束之后,将所述目标实例和所述中继实例的区域参数修改为默认值;
S207、若验证通过,则将所述新版本服务发布至所述目标服务的全部实例,否则将所述目标实例切换回旧版本服务,以结束灰度发布。
可见,本实施例提供的一种基于Spring Cloud的微服务灰度发布方法,基于Spring Cloud微服务框架实现,能够进行网关与微服务、微服务与微服务之间的灰度路由,还提供了两种灵活的灰度发布策略,满足企业级系统的需要。最后,耗费资源少,只对需要进行灰度发布的服务进行,其他不需要的服务或者微服务基础设施进行复用。
基于上述一种基于Spring Cloud的微服务灰度发布方法实施例的介绍,下面以具体应用场景为例,介绍具体的实现过程。整个方案实施过程涉及灰度依赖库、配置中心、微服务管理平台、灰度路由流程四个部分,下面分别对以上四项进行介绍:
一、灰度依赖库
灰度依赖库是一个jar,如果要做灰度发布,服务需要依赖这个库。如果服务要做灰度发布,可以通过如下方式就可以引入灰度依赖库:
<dependency>
<groupId>com.yjh</groupId>
<artifactId>mushroom-gray-starter</artifactId>
</dependency>
灰度依赖库的核心是对Ribbon进行了扩展,Ribbon需要提供两种灰度策略,一种是基于版本(version)的灰度策略,适合2C的互联网产品,直接应用于生产环境,另外一种是基于区域(region)的灰度策略,适合2B的业务支撑系统。这个apply方法是选择实例的一个过滤方法,该方法是灰度路由的核心:
参数包括:server当前实例的信息、ip、端口以及一些eureka(微服务注册中心)元数据;
返回值包括:如果server可以用于备选,则返回true,否则返回false。
下面分别给出基于版本的伪代码和基于区域的伪代码:
基于版本的伪代码如下:
基于区域的伪代码如下:
二、配置中心
配置中心是微服务体系中常用的组件,用于将配置实时下发到微服务,比较有名的开源配置中心有Spring Cloud Config和Apollo,作为一种具体的实施方式,这里可以选择Apollo作为配置中心。
三、微服务管理平台
微服务管理平台,是对微服务和实例进行管理的一个平台。
四、灰度流程
为了详尽说明流程,定义场景如下:
小程序:前端应用;
发布系统:进行自动发布的系统;
网关,网关调用服务A;
服务A,有实例A1、实例A2、实例A3,A调用B;
服务B,有实例B1、实例B2;
基于上述场景,下面分别就基于版本的灰度流程和基于区域的灰度流程进行介绍,其中每种流程分别从两个场景的灰度发布过程进行描述:
1)基于版本的灰度流程
灰度发布时基于version来进行路由,前端请求都带上请求头gray-version,配置中心通过配置属性gray.services推送灰度路由规则到网关和所有前端应用,ribbon过滤器根据灰度路由规则来选择实例。Gray Service配置需要灰度的服务,格式为“服务名:灰度实例ip:灰度请求版本”,注意灰度请求版本要带上产品前缀。
举例如下:
gray.services=demoA-service:192.168.0.0:demo-5.0,demoB-service:192.168.1.1:demo-5.0
凡是demo-5.0的请求访问demoA-service,demoB-service都会走灰度实例,其他请求走正常实例。
场景1:A服务灰度发布
如图3所示,该过程如下:
步骤11、选一个实例作为灰度实例,配置中心配置好灰度路由规则mushroom.gray.services=A:A3:demo-5.0;
步骤12、发布系统发布A3;
步骤13、A3启动后,请求网关,灰度请求头带上gray-version:demo-5.0,这样灰度请求都会走到灰度实例,而生产环境其他版本的请求都会路由到A1或者A2实例;
步骤14、利用灰度环境验证完功能后,配置中心关闭灰度路由规则;
步骤15、发布系统继续发布A1和A2,发布完成。
场景2:B服务灰度发布
步骤21、选取B2实例为灰度实例,配置中心配置好灰度路由规则mushroom.gray.services=B:B2:demo-5.0;
步骤22、发布系统发布B2
步骤23、B2启动后,请求网关,灰度请求头带上gray-version:demo-5.0,这样灰度请求可能到达A,A再调用B服务,由于B配置了灰度规则,只会路由到B2,而生产环境其他版本的请求都会路由到B1实例;
步骤24、利用灰度环境验证完功能后,配置中心关闭灰度路由规则;
步骤25、发布系统继续发布B1,发布完成。
2)基于region的灰度流程
区域的灰度发布适合2B的业务支撑系统,因为这类系统不需要版本,只需要按区域把灰度区隔离出来,去除不必要的配置中心。灰度发布时,利用注册中心属性region=gray的灰度实例组成一个隔离的灰度区域,灰度请求只会在灰度区域内路由,正常请求无法路由到灰度区域里面。
场景1:A服务要进行灰度发布
如图4所示,该过程如下:
步骤31、发布系统选取A3实例为灰度实例,发布系统发布版本到生产环境,启动时设置eureka.instance.metadata-map.region=gray,其中区域值gray自己定义,也可以设置成其他;
步骤32、A3启动后,eureka的实例metadata信息中region=gray,可以在微服务管理平台查询到;
步骤33、A3启动后,请求网关,灰度请求头带上region:gray,这样灰度请求都会走到灰度实例,生产环境其他请求因为请求头region为空或者region:prod,都会路由到A1或者A2实例;
步骤34、利用灰度环境验证完功能后,通过微服务管理平台把A3的元数据region改回prod,变成正常实例;
步骤35、发布系统继续发布A1和A2,发布完成。
场景2:B服务要进行灰度发布
步骤41、发布系统选取B2实例为灰度实例,发布系统发布版本到生产环境,启动时设置eureka.instance.metadata-map.region=gray;
步骤42、B2启动后,eureka的实例metadata信息中region=gray,可以在微服务管理平台查询到;选取其中某个A服务机器,假设为A3,微服务管理平台改成灰度实例,那么A3,B2组成了一个region为gray的灰度区域,跟region为prod的区域隔离开来;
步骤43、B2启动后,请求网关,灰度请求头带上region:gray,这样灰度请求都会走到灰度实例A3,A3再调用B服务,路由到B2;而生产环境其他请求因为请求头region为空或者region:prod,都会路由到A1或者A2实例;
步骤44、利用灰度环境验证完功能后,通过微服务管理平台把A3和B2修改成正常实例;
步骤45、发布系统继续发布B1,发布完成。
下面对本申请实施例提供的一种基于Spring Cloud的微服务灰度发布装置进行介绍,下文描述的一种基于Spring Cloud的微服务灰度发布装置与上文描述的一种基于Spring Cloud的微服务灰度发布方法可相互对应参照。
如图5所示,该装置包括:
目标确定模块501:用于确定目标服务以及所述目标服务的目标实例;
第一发布模块502:用于若所述目标服务为前台服务,则将新版本服务发布至所述目标服务的所述目标实例,并确定所述新版本服务的目标版本号;
第二发布模块503:用于若所述目标服务为后台服务,则将新版本服务发布至所述目标服务的所述目标实例,并将所述目标实例的区域参数设置为灰度标志位,以表征所述目标实例位于灰度区域中;
验证模块504:用于利用网关获取前端应用请求,若所述前端应用请求包括所述目标版本号,则根据所述目标版本号进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;若所述前端应用请求包括所述灰度标志位,则在所述灰度区域进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;
发布结果模块505:用于若验证通过,则将所述新版本服务发布至所述目标服务的全部实例,否则将所述目标实例切换回旧版本服务,以结束灰度发布。
本实施例的基于Spring Cloud的微服务灰度发布装置用于实现前述的基于Spring Cloud的微服务灰度发布方法,因此该装置中的具体实施方式可见前文中的基于Spring Cloud的微服务灰度发布方法的实施例部分,例如,目标确定模块501、第一发布模块502、第二发布模块503、验证模块504、发布结果模块505,分别用于实现上述基于SpringCloud的微服务灰度发布方法中步骤S101,S102,S103,S104,S105。所以,其具体实施方式可以参照相应的各个部分实施例的描述,在此不再展开介绍。
另外,由于本实施例的基于Spring Cloud的微服务灰度发布装置用于实现前述的基于Spring Cloud的微服务灰度发布方法,因此其作用与上述方法的作用相对应,这里不再赘述。
此外,本申请还提供了一种基于Spring Cloud的微服务灰度发布设备,如图6所示,包括:
存储器601:用于存储计算机程序;
处理器602:用于执行所述计算机程序,以实现如上文所述的基于Spring Cloud的微服务灰度发布方法的步骤。
最后,本申请提供了一种基于Spring Cloud的微服务灰度发布系统,如图7所示,包括:服务发布模块701、前端应用模块702、网关703;
其中,所述服务发布模块用于确定目标服务以及所述目标服务的目标实例;若所述目标服务为前台服务,则将新版本服务发布至所述目标服务的所述目标实例,并确定所述新版本服务的目标版本号;若所述目标服务为后台服务,则将新版本服务发布至所述目标服务的所述目标实例,并将所述目标实例的区域参数设置为灰度标志位,以表征所述目标实例位于灰度区域中;
所述前端应用模块用于生成前端应用请求,并将所述前端应用请求发送至所述网关;
所述网关用于在所述前端应用请求包括所述目标版本号时,根据所述目标版本号进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;在所述前端应用请求包括所述灰度标志位时,在所述灰度区域进行路由以将所述前端应用请求转发至所述目标实例,以进行灰度环境验证;
所述发布系统还用于在验证通过时,将所述新版本服务发布至所述目标服务的全部实例,在验证不通过时,将所述目标实例切换回旧版本服务,以结束灰度发布。
作为一种具体的实施方式,还包括配置中心,所述配置中心用于将灰度路由规则推送至所述前端应用模块,以便所述前端应用模块根据所述灰度路由规则生成前端应用请求。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其它实施例的不同之处,各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
以上对本申请所提供的方案进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。