[发明专利]一种基于混合框架的微服务灰度发布方法

说明书

本发明涉及一种基于混合框架的微服务灰度发布方法，其特征在于，设置灰度配置模块，在服务网关中集成灰度识别模块和灰度路由组件，在非服务网关的每个服务中集成灰度路由组件；所述灰度配置模块用于配置灰度用户列表，确定哪些用户使用灰度版本，哪些用户使用正式版本；所述灰度识别模块用于对外来请求进行识别，确定是否是灰度请求，并进行灰度标记；所述灰度路由组件用于进行灰度路由，根据灰度标记，将请求路由到对应的服务；所述灰度路由组件主要由基于不同微服务框架的至少两个请求拦截器、至少两个调用拦截器和至少两个路由器组成。该方法有利于支持多个微服务框架的混合，适应更广泛的灰度发布场景。

技术领域

本发明属于计算机技术领域，具体涉及一种基于混合框架的微服务灰度发布方法。

背景技术

微服务系统在升级时，总体上有三种方式。第一种，即暴力升级，是把旧的服务停止掉，然后上新的服务。这种方式的影响是服务会有一个中断窗口，对于用户来说服务不可用，这是最大的影响，而且新的服务上线之后不免出现问题而不得不回滚至旧版本。第二种，即蓝绿发布，新旧服务同时存在，在新的服务充分验证之后，把流量全部切换到新服务，再把旧的服务下掉。这种方案的问题在于需要同时部署两套服务，资源成本较高，维护也比较麻烦。第三种，即灰度发布，服务只有一套，部分服务实例会同时存在正式版本（即旧版本）与灰度版本（即新版本），大部分用户使用正式版本，一部分用户体验灰度版本，当充分验证之后，把所有流量切换至灰度版本，再把旧版本下线掉。

目前，主流的微服务框架有Spring Cloud与Dubbo，各自框架下的灰度发布方案也比较多，但两个框架混合情况下的灰度发布方案则比较少。但有些项目为了充分利用两个框架各自的优点，或者由于技术栈迁移，会存在两个框架同时使用的情况，此时各自的灰度发布方案由于无法统一在一起，导致无法实现总体上的灰度发布。

发明内容

本发明的目的在于提供一种基于混合框架的微服务灰度发布方法，该方法有利于支持多个微服务框架的混合，适应更广泛的灰度发布场景。

为实现上述目的，本发明采用的技术方案是：一种基于混合框架的微服务灰度发布方法，其特征在于，设置灰度配置模块，在服务网关中集成灰度识别模块和灰度路由组件，在非服务网关的每个服务中集成灰度路由组件；

所述灰度配置模块用于配置灰度用户列表，确定哪些用户使用灰度版本，哪些用户使用正式版本；

所述灰度识别模块用于对外来请求进行识别，确定是否是灰度请求，并进行灰度标记；

所述灰度路由组件用于进行灰度路由，根据灰度标记，将请求路由到对应的服务；所述灰度路由组件主要由基于不同微服务框架的至少两个请求拦截器、至少两个调用拦截器和至少两个路由器组成；所述请求拦截器拦截服务网关或上游服务发来的请求并构建请求上下文，从请求中获取灰度路由信息并保存在当前请求的上下文中；所述调用拦截器在灰度路由之前，对本服务业务处理后的请求进行拦截，并将当前请求的上下文信息添加至请求中，以在调用下游服务时，将当前请求是否为灰度请求的信息传递给下游服务的请求拦截器，确保下游服务的正确路由；所述路由器判断当前请求是否为灰度请求，下游服务是否有灰度实例，然后在调用下游服务时，将当前请求路由到对应服务的对应实例。

进一步地，所述服务网关拦截进来的请求，并从灰度配置模块读取配置，将请求用户与灰度用户清单中的灰度用户进行匹配，如果匹配则将当前请求标记为灰度请求，否则标记为正式请求，从而实现灰度识别和标记。

进一步地，所述路由器判断当前请求是否为灰度请求，下游服务是否有灰度实例，然后按如下方法进行灰度路由：1）如果当前请求为灰度请求且下游服务有灰度实例，将当前请求发给灰度实例；2）如果当前请求为灰度请求且下游服务没有灰度实例，将当前请求发给正式实例；3）如果当前请求为正式请求，无论下游服务是否有灰度实例，都将当前请求发给正式实例。