一种dubbo应用级全链路灰度发布方法及系统

技术领域

本发明涉及计算机技术领域,更具体地说，涉及到一种dubbo应用级全链路灰度发布方法及系统。

背景技术

项目上线都是以应用级别粒度进行更新上线的，上线的新版本与旧版本需要通过隔离测试和新旧版本访问流量控制来实现灰度发布，dubbo2.6目前只能够实现服务级别的权重和路由控制，如果需要对整个应用权重和路由进行修改，目前只能采用循环所有服务的方式进行权重和路由添加修改，这样不仅低效而且存在循环出错的风险。dubbo2.6如果要实现新版本上线后暂时无流量进入，需要开发人员为每个服务权重设置默认值0来防止流量进入新版本，如果某个开发人员忘记了或者设置错误都将会导致流量进入新版本。而通过路由配置来实现隔离测试，如果服务发布到k8s等容器云中，需要等到服务启动后才能获取服务所在的服务器IP进行路由配置，而此时流量可能已经进入新版本。如上两种都会导致灰度发布生效时间过晚，导致流量随机进入新旧版本的不可控，无法起到新旧版本隔离，并且需要开发人员介入灰度发布流程中来，增加的开发人员的负担。服务链路调用在微服务架构中是普遍存在的，dubbo2.6目前还无法方便快速的做到在整个链路中实现应用新旧版本隔离测试。

本发明内容

为了克服现有技术的不足，本发明提供一种dubbo应用级全链路灰度发布方法高效控制用户流量进入新版本进行新旧版本隔离测试的问题。

本发明解决其技术问题所采用的技术方案是：一种dubbo应用级全链路灰度发布方法，包括以下步骤：步骤一：用户通过消费端向生产端发送访问请求；步骤二：基于所述用户访问请求，所述消费端获取目标信息，所述目标信息包括tag和weight；步骤三：基于所述消费端获取的所述目标消息，将所述符合目标消息的用户通过所述消费端切入至目标版本，所述版本包括新版本和旧版本。

优选地，所述用户通过消费端向生产端发送访问请求之前，所述步骤还包括：

部署平台将tag与weight写入注册中心，以使所述注册中心对所述tag与所述weight进行注册登记。

优选地，所述部署平台将tag与weight写入注册中心之后，所述步骤还包括：

所述注册中心将所述tag与所述weight缓存至所述消费端；

或者所述部署平台通过qos接口将所述tag与所述weight缓存至所述消费端。

优选地，在所述消费端获取目标消息之后，将所述符合目标消息的用户通过所述消费端切入至目标版本之前，所述步骤还包括：

根据所述生产端中缓存的所述tag与所述weight，基于loadbalance封装的算法对invoker 进行版本分类。

优选地，将所述符合目标消息的用户通过所述消费端切入至目标版本，所述步骤包括：

带有tag的用户根据所述weight值通过所述消费端访问所述生产端的新版本；

未带有tag的用户根据所述weight值通过所述消费端访问所述生产端的旧版本。

一种dubbo应用级全链路灰度发布系统，所述系统还包括：

发送单元，用于用户通过消费端向生产端发送访问请求；

获取单元，用于基于所述用户访问新版本请求，所述消费端获取目标信息，所述目标信息包括tag和weight；

切入单元，用于基于所述消费端获取的所述目标消息，将所述符合目标消息的用户通过所述消费端切入至目标版本，所述版本包括新版本和旧版本。

优选地，所述系统还包括：

写入单元，用于部署平台将tag与weight写入注册中心，以使所述注册中心对所述tag与所述weight进行注册登记。

优选地，所述系统还包括：

第一缓存单元，哟所述注册中心将所述tag与所述weight缓存至所述消费端；

或者

第二缓存单元，用于所述部署平台通过qos接口将所述tag与所述weight缓存至所述消费端。

优选地，所述系统还包括：

分类单元，用于根据所述生产端中缓存的所述tag与所述weight，基于loadbalance封装的算法对invoker进行版本分类。

优选地，所述访问单元包括：

第一访问子单元，用于带有tag的用户根据所述weight值通过所述消费端访问所述生产端的新版本；

第二访问子单元，用于未带有tag的用户根据所述weight值通过所述消费端访问所述生产端的旧版本。

本发明的有益效果是：通过分别控制tag和权重值两个值来控制用户流量进入新版本进行新旧版本隔离测试，从而达到自动快速测试新版本，进而提高dubbo灰度发布的效率。

附图说明

图1是dubbo应用级全链路灰度发布方法的流程示意图。

图2是dubbo应用级全链路灰度发布系统的功能模块图。

图3是dubbo应用级全链路灰度整体架构图。

图4是dubbo应用级全链路灰度发布系统部分示意图。

图5是dubbo应用级全链路灰度发布系统另一部分示意图。

图6是dubbo应用级全链路灰度发布系统另一部分示意图。

图7是dubbo应用级全链路灰度发布系统另一部分示意图。

图8是dubbo应用级全链路灰度发布系统另一部分示意图。

图9是dubbo灰度发布流程图。

图10是全链路标签路由实现图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

以下结合具体实施例对本发明的具体实现进行详细描述：

图1示出了本发明实施例一提供的dubbo应用级全链路灰度发布方法的实现流程，为了便于说明，仅示出了与本发明实施例相关的部分，详述如下：

在步骤S101中：用户通过消费端向生产端发送访问请求；

在本申请实施例中，消费端是面向dubbo服务的消费者，loadbalance的核心算法来获取具体的生产者进行消费，通过生产端是面向dubbo服务的生产者，通过环境变量来标注自己的版本排序信息，来实现启动后新旧版本流量隔离，这个是由部署平台来自动写入的，无需开发人员介入，用户通过消费端向生产端发送访问新版本的请求，以使得生产端响应消费端的请求，从而便于用户进入新版本进行测试。

优选地，部署平台将tag与weight写入注册中心，以使所述注册中心对所述tag与所述 weight进行注册登记，从而提高数据的安全性，所述部署平台将tag与weight写入注册中心之后，所述注册中心将所述tag与所述weight缓存至所述消费端，或者所述部署平台通过qos接口将所述tag与所述weight缓存至所述消费端，从而便于从部署平台或者注册中心获取tag信息与weight数据。

在步骤S102中：基于所述用户访问请求，所述消费端获取目标信息，所述目标信息包括 tag和weight；

在本申请实施例中，根据用户发来的访问新版本的请求，消费端获取到相应的目标信息，该目标信息为标签(tag)信息和权重(weight)数据，标签用于给用户进行标签，让带有标签的用户进入新版本，让未带有标签的用户进入旧版本，从而控制部分用户实现了自动隔离测试，进而达到了高效测试的目的。然后根据权重的具体数据进一步控制部分用户进入新版本进行测试，为了防止新版本出现故障，进入新版本测试的流量过大。

优选地，根据所述生产端中缓存的所述tag与所述weight，基于loadbalance封装的算法对invoker进行版本分类。首先判断是否存在标签(tag)信息和权重(weight)数据，当不存在标签(tag)信息和权重(weight)数据走正式版本筛选，当同时存在标签(tag)信息和权重 (weight)数据时，通过loadbalance封装的算法对invoker进行版本分类。

在步骤S103中：基于所述消费端获取的所述目标消息，将所述符合目标消息的用户通过所述消费端切入至目标版本，所述版本包括新版本和旧版本。

在本申请实施例中，消费端从部署平台或者注册中心获取到标签(tag)信息和权重 (weight)数据,将带有标签(tag)信息的用户流量再根据获取到具体权重数据允许那部分用户流量进入新版本进行测试，提高了新版本测试的效率。

具体地，带有tag的用户根据所述weight值通过所述消费端访问所述生产端的新版本；未带有tag的用户根据所述weight值通过所述消费端访问所述生产端的旧版本。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于一计算机可读取存储介质中，所述的存储介质，如ROM/RAM、磁盘、光盘等。

实施例二：

图2示出了本发明实施例二提供的dubbo应用级全链路灰度发布系统的结构，为了便于说明，仅示出了与本发明实施例相关的部分，详述如下：

发送单元201，用于用户通过消费端向生产端发送访问请求；

获取单元202，用于基于所述用户访问新版本请求，所述消费端获取目标信息，所述目标信息包括tag和weight；

切入单元203，用于基于所述消费端获取的所述目标消息，将所述符合目标消息的用户通过所述消费端切入至目标版本，所述目标版本包括新版本和旧版本。

本发明实施例中，用户通过消费端向生产端发送访问请求；基于所述用户访问请求，所述消费端获取目标信息，所述目标信息包括tag和weight；基于所述消费端获取的所述目标消息，将所述符合目标消息的用户通过所述消费端切入至目标版本，所述目标版本包括新版本和旧版本，通过tag和权重值来控制用户流量进入新版本进行新旧版本隔离测试，从而达到自动快速测试新版本，进而提高dubbo灰度发布的效率。各单元的具体实施方式可参考实施例一的描述，在此不再赘述。

实施例三：

图3示出了本发明实施例三提供的dubbo应用级全链路灰度整体架构图，为了便于说明，再结合图4至图10，其中包括：

如图3所示，架构组成部分说明：

生产者：dubbo服务的生产端

消费者：dubbo服务的消费端

注册中心：服务注册和标签权重数据保存的地方

部署平台：项目发布(发布生产者和消费者项目)和标签权重控制的中心

dubbo应用级全链路灰度发布整体实现过程(可参照Dubbo灰度整体架构图理解)：

如图4所示，部署平台发布消费者和生产者(可发布多个副本)，第一次发布这里默认生产者为绿版，本版本号为1592973324(时间戳)，此时用户访问流量经由消费者到达绿版本的生产者，访问绿版本中的某一个副本(相同版本的多个副本版本类型和版本号都一样)。

如图5所示，如果生产者有了新的版本需要上线，由于旧版本为绿版本，所以新版本会发布为蓝版本(新版本也可以存在多个副本)，发布后的新版本(蓝版本)版本号为15929799968 (时间戳)，新版本(蓝版本)版本号会大于旧版本(绿版本)版本号。

新版本(蓝版本)发布后，新旧版本会同时在线，消费者根据蓝绿版本和版本号筛选出哪些副本为旧版本(绿版本)副本哪些为新版本(蓝版本)副本，在没有进行标签和权重路由设置的情况下，消费者默认访问生产者旧版本(绿版本)。

如图6所示，为生产者新版本(蓝版本)打上标签，假设标签为tag1，标签(tag1)数据会写入注册中心，并会推送给消费者本地缓存(这里可参考灰度发布整体架构图)，如果用户访问流量中带有tag1，消费者会从本地缓存中查询是否存在与此标签(tag1)相同的版本，这里生产者中的蓝版本标签为tag1，访问流量就会走蓝版本。

如图7所示没有带标签的访问流量或者标签不是tag1的访问流量默认走旧版本(绿版本)，这样通过标签就能实现带标签(tag1)测试流量进入新版本(蓝版本)，而正式流量依旧进入旧版本(绿版本)，实现了在线新旧版本流量隔离测试的目的。

如图8所示，新旧版本成功发布上线并且通过标签路由流量隔离测试后，接下来有两中操作方式。

第一种操作方式：如果新旧版本不兼容，将新版本(蓝版本)的标签(tag1)去掉，然后下线旧版本(绿版本)，之后所有的访问流量就会进入新版本，新版上线到此结束。

第二种操作方式：如果新旧版本不存在兼容问题，可以将新版本(蓝版本)的标签(tag1) 去掉，然后通过权重路由将一部分的正式访问流量切入到新版本(蓝版本)，如果新版本(蓝版本)不存在问题，可以逐渐的将所有流量切入到新版本(蓝版本)，等流量全部切入新版本(蓝版本)后，最后下线旧版本(绿版本)，新版本上线到此结束。

如图9所示，如果此项目再次发布新版本时，那么此时的旧版本就是蓝版本，新版本则为绿版本，发布流程不变，发布流程总结：

发布流程有三种方式可选：

第一种：开始新版本上线->标签路由->权重路由->结束新版本上线

先通过了标签路由进行了流量隔离测试，然后逐渐将正式访问流量切入新版本，完全能达到平滑无抖动上线新版本的效果。

第二种：开始新版本上线->标签路由->结束新版本上线

如果新旧版本不兼容，采用此方式发布上线，如果新版本存在问题，可以快速切换会旧版本，但此时可能已经有大量的正式流量进入了有问题的新版本。

第三种：开始新版本上线->权重路由->结束新版本上线

如果采用此发布方式，推荐先通过标签路由进行流量隔离测试(第一种发布方式)。

如果版本兼容推荐采用第一种，既能实现流量隔离测试也可以保证正式流量逐渐切入到新版本。如图10所示，全链路标签路由实现，

1、标签为tag1时的访问路线

A1–>B1->C1->D2

2、标签为tag2时的访问路线

A2–>B1->C1->D1

3、标签为tag3时的访问路线

A1–>B2->C2->D1

4、没有便签或者便签不为tag1,tag2,tag3其中一个，就走默认访问路线

A1–>B1->C1->D1

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。