CN108319656A

CN108319656A - 实现灰度发布的方法、装置及计算节点和系统

Info

Publication number: CN108319656A
Application number: CN201711499192.5A
Authority: CN
Inventors: 陆天炜; 付裕; 罗圣美; 钱煜明
Original assignee: ZTE Corp
Current assignee: Jinzhuan Xinke Co Ltd
Priority date: 2017-12-29
Filing date: 2017-12-29
Publication date: 2018-07-24
Also published as: JP2021513694A; WO2019128205A1; JP7083901B2

Abstract

本申请公开了一种实现灰度发布的方法、装置及计算节点和系统，包括：对接收到的应用请求进行处理，确定出接收到的应用请求为灰度请求；根据预先设置的分片配置信息对灰度请求进行解析，确定灰度请求是请求灰度数据的第一灰度请求，或者是请求灰度数据和正式数据的第二灰度请求；将第一灰度请求或第二灰度请求中请求灰度用户的数据的部分转发至灰度请求对应的灰度用户所在的灰度数据节点执行；将第二灰度请求中请求正式用户数据的部分转发至正式用户所在的正式数据节点执行。通过本申请提供的技术方案，在数据库层将灰度用户和正式用户区分开来，简单有效地达到了灰度发布的目的，同时减少了业务改造量。

Description

实现灰度发布的方法、装置及计算节点和系统

技术领域

本申请涉及但不限于分布式数据处理技术，尤指一种基于分布式数据库的实现灰度发布的方法、装置及计算节点和系统。

背景技术

为了减少甚至避免系统升级对用户使用造成的影响，越来越多的应用，在升级的过程中都会采用灰度发布的策略。其中，灰度发布(又名金丝雀发布)是指在黑与白之间，能够平滑过渡的一种发布方式。在灰度发布上可以进行A/B testing，即让一部分用户继续用产品特性A，另一部分用户开始用产品特性B，如果用户对产品特征B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到产品特征B。灰度发布可以保证整体系统的稳定性，在初始灰度时就可以发现问题、进而做出调整，从而保证其影响度。

相关技术中，常用的灰度发布策略包括，应用根据正式用户和灰度用户的名单，将对应的流量分别导入到原有业务系统和新业务系统上。这种方式在增加一个新的业务系统的同时，也会相应增加配置中心等一系列功能模块。这样，应用需要维护对应原有业务系统和新的业务系统的新旧两份业务代码，以及保留新旧两份数据结构及其数据内容。

目前，实现灰度发布的系统多以通过应用端、服务端实现为主，很少涉及到数据库，即使涉及到数据库，也是灰度用户和正式用户使用同一套数据库，通过增加冗余字段来适配业务修改，比如：在一张表中，正式用户需要用字段A、字段B和字段C三个字段，灰度用户需要使用字段A、字段D和字段E三个字段，当使用一套数据库承载正式用户和灰度用户时，这张表中就需要包括有字段A、字段B、字段C、字段D和字段E五个字段，显然，对正式用户的数据来说，字段D和字段E是冗余的，而对灰度用户的数据来说，字段B和字段C是冗余的。这样，在正式应用访问时，需要限制其仅能访问正式数据，并且需要屏蔽字段D和字段E；而在灰度应用访问时，需要限制其仅能访问灰度数据，并且需要屏蔽字段B和字段C，这样的处理给业务带来了限制；而且，灰度业务修改变得越来越复杂，不利于后期维护，也不利于版本回滚。

发明内容

为了解决上述技术问题，本申请提供一种实现灰度发布的方法、装置及计算节点和系统，能够简单有效地达到灰度发布的目的，同时减少业务改造量。

本申请提供了一种实现灰度发布的方法，包括：

对接收到的应用请求进行处理，确定出接收到的应用请求为灰度请求；

根据预先设置的分片配置信息对灰度请求进行解析，确定灰度请求是请求灰度数据的第一灰度请求，或者是请求灰度数据和正式数据的第二灰度请求；

将第一灰度请求或第二灰度请求中请求灰度用户的数据的部分转发至灰度请求对应的灰度用户所在的灰度数据节点执行；将第二灰度请求中请求正式用户数据的部分转发至正式用户所在的正式数据节点执行。

本身还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现本申请实施例中任意一种实现灰度发布的方法的步骤。

本申请又提供了一种实现灰度发布的设备，包括处理器和计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令被所述处理器执行时，实现本申请实施例中任意一种实现灰度发布的方法。

本申请再提供了一种实现灰度发布的装置，包括：过滤模块、解析模块，以及转发模块；其中，

过滤模块，用于对接收到的应用请求进行处理，确定出接收到的应用请求为灰度请求；

解析模块，用于根据加载的分片配置信息对灰度请求进行解析，确定灰度请求是请求灰度数据的第一灰度请求，或者是请求灰度数据和正式数据的第二灰度请求；

转发模块，用于将第一灰度请求或第二灰度请求中请求灰度用户的数据的部分转发至灰度请求对应的灰度用户所在的灰度数据节点执行；将第二灰度请求中请求正式用户数据的部分转发至正式用户所在的正式数据节点执行。

本申请还提供一种计算节点，包括本申请实施例中任一项所述的实现灰度发布的装置。

本申请再提供了一种实现灰度发布的系统，包括：分布式数据库中的数据节点集群、分布式数据库中的计算节点集群；其中，

分布式数据库中的数据节点集群包括两个或两个以上数据节点，用于承载用户数据；数据通过分片配置信息分布到多个数据节点；

分布式数据库中的计算节点集群包括两个或两个以上计算节点，用于对外提供服务，所述计算节点包括本申请实施例中任一项所述的实现灰度发布的装置。

本申请技术方案包括：对接收到的应用请求进行处理，确定出接收到的应用请求为灰度请求；根据加载的分片配置信息对灰度请求进行解析，确定灰度请求是请求灰度数据的第一灰度请求，或者是请求灰度数据和正式数据的第二灰度请求；根据灰度修改配置信息对第一灰度请求或第二灰度请求中请求灰度用户数据的部分进行改写；将改写后的第一灰度请求或第二灰度请求中请求灰度用户的数据的部分转发至灰度请求对应的灰度用户所在的灰度数据节点执行；将第二灰度请求中请求正式用户数据的部分转发至正式用户所在的正式数据节点执行。通过本申请提供的技术方案，在数据库层将灰度用户和正式用户区分开来，简单有效地达到了灰度发布的目的，同时减少了业务改造量。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本申请技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请的技术方案，并不构成对本申请技术方案的限制。

图1为本申请实现灰度发布的方法的流程图；

图2为本申请实现数据分片及同名异构表实施例的示意图；

图3为本申请支持灰度发布的用户数据分片实施例的示意图；

图4为本申请分布式数据库数据重分布实施例的示意图；

图5为本申请灰度请求报表统计处理实施例的示意图；

图6为本申请对账处理实施例的流程图；

图7为本申请实现灰度发布的装置的组成结构示意图；

图8为本申请计算节点的组成实施例的示意图；

图9为本申请基于分布式数据库实现灰度发布的整体架构示意图；

图10为本申请实现灰度发布的设备的结构组成示意图；

图11为本申请实现灰度发布的第一实施例的示意图；

图12为本申请实现灰度发布的第二实施例的示意图；

图13为本申请实现灰度发布的第三实施例的示意图；

图14为本申请实现灰度发布的第四实施例的示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下文中将结合附图对本申请的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

图1为本申请实现灰度发布的方法的流程图，如图1所示，包括：

步骤100：计算节点对接收到的应用请求进行处理，确定出接收到的应用请求为灰度请求。

可选地，如果确定出接收到的应用请求是请求正式数据的正式请求，本申请方法还包括：

将正式请求转发至正式请求对应的正式用户所在的正式数据节点执行。

可选地，本步骤中，计算节点可以通过IP白名单对接收到的应用请求进行过滤，来区分接收到的应用请求是灰度请求，还是请求正式数据的正式请求。

可选地，IP白名单包括：正式请求IP白名单和灰度请求IP白名单；通过IP白名单对接收到的应用请求进行过滤包括：

来自正式请求IP白名单中的正式应用数据库客户端的应用请求为正式请求；

来自灰度请求IP白名单中的灰度应用数据库客户端的应用请求为灰度请求；

来自非白名单IP即既不属于正式请求IP白名单中的正式应用数据库客户端，也不属于灰度请求IP白名单中的灰度应用数据库客户端的应用请求会被丢弃。

本申请通过IP白名单过滤掉了非法的应用请求。

本步骤之前还包括：

与应用配合，通过流量指引如在请求中携带身份信息等来识别，将灰度用户和正式用户的请求分别引流到不同IP的数据库客户端(并非用户的客户端，通常部署在应用服务器)上，这样，保证了本步骤通过分布式数据库的IP白名单针对数据库客户端的请求进行IP过滤。具体实现方式很多，并不用于限定本申请的保护范围，这里不再赘述。

步骤101：根据预先设置的分片配置信息对灰度请求进行解析，确定灰度请求是请求灰度数据的第一灰度请求，或者是请求灰度数据和正式数据的第二灰度请求。

可选地，分片配置信息可以包括但不限于以下任意组合：List分片、ER分片、Hash分片、Range分片等，本申请中，通过多种分布方式组合区分灰度用户和正式用户。

可选地，本申请之前还包括：

根据预先设置的分片配置信息，利用分布式数据库的数据分片功能，在数据库层区分灰度用户的数据和正式用户的数据，也就是说，将灰度用户和正式用户区分开来。并且，本申请通过使用相同的分片配置信息来保障同一个用户的所有相关数据拥有相同的分布规则即针对同一个用户的数据分布采用同一个分片配置信息。同一个用户可能涉及很多表，但是这些相关的表都采用同样的分片配置信息。

可选地，步骤101中的根据预先设置的分片配置信息对灰度请求进行解析，具体包括：根据灰度请求确定需要查询的表；根据分片配置信息查询该表的分片规则，并按照分片规则确定该灰度请求对应的数据节点。

举例来看，假设灰度请求的语句为：select*from T where id＝3；并假设按照预先设置的分片配置信息得知：表T是按照id进行range分片的，且id1～id10分布在数据节点1上，id11～id20分布在数据节点2。那么，该灰度请求的数据分布在数据节点1上，也就是说，通过分析可得知：该灰度请求会被发送到数据节点1上执行。

步骤103：将第一灰度请求或第二灰度请求中请求灰度用户的数据的部分转发至灰度请求对应的灰度用户所在的灰度数据节点执行；将第二灰度请求中请求正式用户数据的部分发至正式用户所在的正式数据节点执行。

可选地，对于同时涉及灰度用户和正式用户的第二灰度请求，比如统计报表等，数据执行完毕后，还包括：通过汇总请求将发往灰度用户所在的灰度数据节点的部分的执行结果，以及发往正式用户所在的正式数据节点的部分的执行结果进行汇总。

可选地，在步骤101之后，步骤103之前，本申请实现灰度发布的方法还包括：

步骤102：根据预先设置的灰度修改配置信息对第一灰度请求或第二灰度请求中请求灰度用户数据的部分进行改写。

分布式数据库支持同名异构的表即名称相同但是数据结构不同的表，为了满足对灰度业务的数据结构和业务逻辑的要求，可选地，本申请之前还包括：

根据灰度修改配置信息对灰度用户数据库的表结构进行改写，使得灰度用户和正式用户使用的数据表结构不一样。虽然灰度用户的表与正式用户的表的表结构不同，但是二者仍然使用相同名称的表。

举例来看：假设请求中有两条语句：第一条语句为：select A，B，C from T whereid＝3；第二条语句为：select A，B，C from T where id＝13；并假设按照预先设置的分片配置信息得知：表T是按照id进行range分片的，且id1～id10分布在数据节点1上，id11～id20分布在数据节点2；那么，

对于第一条语句，假设没有添加灰度修改配置信息，因此，不需要进行SQL改写，直接将第一条语句直接发往分片数据节点1；而对于第二条语句，假设添加的灰度修改配置信息为：D＝A+B，E＝10*C，那么，会将原语句中的B替换为D-A，将原语句中的C替换为E/10，最终发往分片数据节点2上的语句被改写为：select A，D-A，E/10 from T where id＝13。

也就是说，根据灰度修改配置信息涉及到哪些表，哪些字段来确定是否需要改写，不涉及到修改的字段，则不需要改写SQL。

这样，实现了业务使用相同的语句对异构数据库的访问支持，而不会出现维度不一致的情况。比如说，原来表中的字段是字段A、字段B和字段C，灰度用户的字段是字段A、字段D和字段E。如果D＝A+B，E＝10*C，按照本申请中的改写方式，那么灰度用户的表实际是字段A、字段(A+B)，以及字段(10*C)，这个维度和原来是一致的，能够保证方便的进行回滚，且不会丢失信息。

图2为本申请实现数据分片及同名异构表实施例的示意图，当不使用分布式数据库时，同一张表的所有数据会被放在一个数据节点上，表中会存放所有数据行，如图2左侧所示，单节点上的表T存放9行数据。当使用分布式数据库时，假设数据被分布到三个数据节点上，并假设数据节点1上存放1行～4行，数据节点2上存放5行～8行，数据节点3上存放第9行。实现图2中的数据分布方式可以有多种策略：

比如，如果采用List分片，可以通过枚举的方式如set1{1、2、3、4}，set2{5、6、7、8}，set3{9}将数据分布在不同的数据节点上；

再如，如果采用Range分片，可以通过框定范围如set1{1～4}，set2{5～8}，set3{9～∞}将数据分布在不同的数据节点上；

又如，如果采用其它分片方式如Hash分片、关系分片等等。

可选地，如果希望不同的数据节点上的表T结构不一样，可以对表结构进行修改。如图2中数据节点2和数据节点3上的表T，可以通过alter操作表结构如：alter table setC＝B-C，将数据节点2上的表结构修改为T(A、B、B-C)，通过如：alter table set C＝B+C，将数据节点3上的表结构修改为T(A、B、B+C)。

需要说明的是，修改表结构在计算结点创建表之后，整个数据节点对计算结点展示的仍然是原始的表结构T(A、B、C)。也就是说，对分布式数据库来讲，通过计算节点对外展示表结构，正式数据库和灰度数据库中的表T是一个整体，不论做了什么样的灰度修改，对外表结构仍然是T(A、B、C)。

图3为本申请支持灰度发布的用户数据分片实施例的示意图，如图3所示：需要配置灰度用户的选择策略即预先设置分布式数据库的分片策略，比如：可以按照范围设置ID的1-100的用户为灰度用户，这属于Range分布，将数据分为正式数据和灰度数据。对相关的表设置相同的分布规则，以确保同一用户的所有数据都会分布在同一个库中，正式用户相关的表T1、表T2、表T3和表T4都在正式数据节点上，灰度用户相关的表T1、表T2、表T3和表T4都在灰度数据节点上。

其中，灰度用户的相关表，根据灰度业务需要执行相应的表结构修改，如图4中灰度库所示，表名和正式数据节点中的一致，但是表结构有所不同。针对表结构的修改，如由正式库的表T(A、B、C)变为灰度库的表T(A、B、B-C)，增加对应表的SQL改写配置(如C＝B-C)即可。

其中，正式用户的查询只会涉及正式库(左侧虚线框内数据)，灰度用户的查询会涉及到灰度库和正式库(右侧虚线框内数据)。

灰度用户对于不涉及灰名单人群的SQL请求，通过静态路由灰名单筛选后，会直接将SQL语句发往正式库，如图4中的基本信息表二；灰度用户对于涉及到灰名单人群的SQL请求，会将对应的SQL经过改写后，再发往灰度节点上执行，比如：原有的select C from T，根据改写配置，将被改写为select B+C from T再发往灰度节点。

对分布式数据库来说，由于使用了数据分片技术，数据被切分成细小的切分(sharding)，分布在数据节点集群中，在运行过程中，难免出现业务的热点数据，业务负载可能集中在某个分片上。造成单数据节点压力过大，为了保证更好地利用设备，可选地，本申请还包括：

对数据进行重新分布以均衡负载，包括：将部分热点数据移动到新增分片中，或者从负担较大的数据节点迁移到负担较小的数据节点。

用户的分片可以通过分布式数据库的数据重分布功能来实现重新分片。使用数据重分布功能，实现了在不停业务的情况下按照既定的分片配置信息迁移数据。如图4所示，假设原来的数据分布在4个数据节点上，但是，由于数据节点4的压力较大，可以对数据节点4的数据进行重新分布，如迁移一部分数据到新增的数据节点5上。

可选地，本申请方法还包括：根据灰度用户的应用特性，修改对应灰度表的表结构。比如：原来数据库中某一字段M按照“元”为单位，业务逻辑展示给用户的是“万元”为单位。那么，通过灰度修改，会将数据库中该字段改为M/10000。

举例来看，以表T为例，假设对应正式数据库中的字段包括字段A、字段B和字段C，对应灰度数据库中的字段包括字段A、字段B和字段D，其中，假设配置规则为：D＝C+B，那么，对于应用请求如通用SQL请求中含有字段C的语句来说，改写规则即灰度修改配置信息为：C＝D-B。具体示例如表1所示：

表1

这样，当计算节点接收到通用的SQL请求时，首先根据预先设置的分片配置信息，判断出涉及到的数据分片，如果同时涉及到正式数据库和灰度数据库的用户，则根据SQL改写规则判断是否需要进行改写，最后将改写后的语句发往对应数据库(DB)即数据节点执行。

可选地，本申请方法还包括：

当用户判断灰度应用可以正式发布时，将所有原正式数据库的数据结构修改为灰度数据库的数据结构，即对原正式数据库中的数据结构进行升级处理；

当用户判断灰度应用不适用时，将灰度数据库的数据结构回退为正式数据库的数据结构，即对灰度数据库中的数据结构进行回退处理。

针对在上述升级或回退场景，可以通过针对SQL配置规则生成自动化脚本来执行升级；也可以通过数据导入的方式迁移用户来实现。

以表T为例，假设对应正式数据库中的字段包括字段A、字段B和字段C，对应灰度数据库中的字段包括字段A、字段B和字段D，其中，假设配置规则为：D＝C+B，那么，升级、回退脚本如表2所示：

表2

以表T1为例，假设对应正式数据库中的字段包括字段A、字段B和字段C，对应灰度数据库中的字段包括字段A、字段B和字段D，假设表T2对应正式数据库中的字段和对应灰度数据库中的字段均包括字段E、字段F和字段G，其中，假设配置规则为：T1.D＝T1.A+T1.B+T2.G，那么，升级、回退脚本如表3所示：

表3

同时涉及灰度用户和正式用户的请求一般都是统计报表处理，图5为本申请灰度请求报表统计处理实施例的示意图，如图5所示，包括：同时涉及灰度用户和正式用户的请求一般都是统计报表：正式数据库和灰度数据库共用一套报表生成程序，如同一套存储过程，生成报表的结构相同如分库报表；计算节点负责调用正式数据库和灰度数据库的报表生成程序，通过加载SQL改写规则，向报表生成程序传入不同的参数，匹配各数据库中同名异构的表的表结构；计算节点负责汇总各数据库生成的报表即分库报表。

如图5所示，以存储过程为例，正式数据库和灰度数据库中都有上述的同一套存储过程，当计算节点下发生成报表命令时，根据报表相关的表，触发不同的改写规则，传入不同的参数，如对表T，在正式数据库的存储过程中对字段C进行批处理；在灰度数据库的存储过程中对字段E/10的结果做处理。

如图5所示，以一个统计存储过程为例，该存储过程统计表中某一字段大于100的个数。在正式数据库中，直接传入字段C，而在灰度数据库中，想要正确实现统计，需要传入E/10。

图6为本申请对账处理实施例的流程图，如图6所示，灰度发布中的对账程序主要处理两个问题：对账文件只有一份，账单记录表分布在正式数据库和灰度数据库中；正式数据库和灰度数据库中的对账记录表结构可能不同。包括：

在正式数据库和灰度数据库中创建对账的临时表，临时表的表结构和对账系统导出的对账数据文件保持一致；

计算节点将对账数据文件中的条目按照正式用户(如图6中的条目1、条目2和条目3)、灰度用户(如图6中的条目4和条目5)的分片配置规则导入到对应的临时表中；

计算节点调用各数据库中的对账程序(如存储过程)，通过加载SQL改写规则，向其不同分片节点中的对账程序传入不同的参数，匹配(即通过通过改写，将请求中的语句调整为与数据库中表的结构相同)数据库中同名异构的对账表；

各分数据库对账结束后，计算节点汇总对账结果。

图7为本申请实现灰度发布的装置的组成结构示意图，如图7所示，所述装置至少包括：过滤模块、解析模块，以及转发模块；其中，

解析模块，用于根据预先设置的分片配置信息对灰度请求进行解析，确定灰度请求是请求灰度数据的第一灰度请求，或者是请求灰度数据和正式数据的第二灰度请求；

可选地，本申请装置还包括：

处理模块，用于根据预先设置的灰度修改配置信息对第一灰度请求或第二灰度请求中请求灰度用户数据的部分进行改写，再将改写后的第一灰度请求或第二灰度请求输出给转发模块。

可选地，过滤模块还用于：如果确定出接收到的应用请求是请求正式数据的正式请求，将正式请求转发至正式请求对应的正式用户所在的正式数据节点执行。

可选地，过滤模块具体用于：通过IP白名单对接收到的应用请求进行过滤，来区分接收到的应用请求是请求灰度数据的灰度请求，还是请求正式数据的正式请求。更具体地：

IP白名单分为两部分：正式请求IP白名单和灰度请求IP白名单；来自正式请求IP白名单中的正式应用数据库客户端的应用请求为正式请求；来自灰度请求IP白名单中的灰度应用数据库客户端的应用请求为灰度请求；来自非白名单IP的应用请求会被丢弃。

可选地，解析模块具体用于：根据灰度请求确定需要查询的表；根据分片配置信息查询该表的分片规则，并按照分片规则确定该灰度请求对应的数据节点。

可选地，解析模块还用于：根据预先设置的分片配置信息，利用分布式数据库的数据分片功能，在数据库层区分灰度用户的数据和正式用户的数据，也就是说，将灰度用户和正式用户区分开来。并且，本申请通过使用相同的分片配置信息来保障同一个用户的所有相关数据拥有相同的分布规则。

可选地，处理模块还用于：根据灰度修改配置信息对灰度用户数据库的表结构进行改写，使得灰度用户和正式用户使用的数据表结构不一样。

可选地，处理模块还用于：根据灰度用户的应用特性，修改对应灰度表的表结构。

可选地，处理模块还用于：对于同时涉及灰度用户和正式用户的第二灰度请求，比如统计报表等，在数据执行完毕后，将发往灰度用户所在的灰度数据节点的部分与发往正式用户所在的正式数据节点的部分的执行结果数据进行汇总。

可选地，处理模块还用于：对数据进行重新分布以均衡负载，包括：将部分热点数据移动到新增分片中，或者从负担较大的数据节点迁移到负担较小的数据节点。

可选地，处理模块还用于：

当用户判断灰度应用可以正式发布时，将所有原正式数据库的数据结构修改为灰度数据库的数据结构，即对原正式数据库中的数据结构进行升级处理；当用户判断灰度应用不适用时，将灰度数据库的数据结构回退为正式数据库的数据结构，即对灰度数据库中的数据结构进行回退处理。

图8为本申请计算节点的组成实施例的示意图，如图8所示，包括IP白名单模块、静态路由模块，以及数据改写模块，其中，IP白名单模块的具体实现如图7中的任一项过滤模块，静态路由模块的具体实现如图7中的任一项解析模块，数据改写模块的具体实现如图7中的任一项处理模块。

数据节点启动时，计算节点通过IP白名单模块加载IP白名单配置信息；通过静态路由模块，会加载数据分片配置信息；通过SQL数据改写模块会加载SQL改写规则配置信息。本申请计算节点的工作原理包括：

数据计算节点的IP白名单模块对接收到的所有外部应用请求进行白名单过滤，白名单分为包括两部分，正式请求IP白名单和灰度请求IP白名单。非白名单IP发来的SQL请求会被丢弃；正式客户端(如来自图中IP1)发来的请求，会直接发往正式数据库；灰度客户端(如图中来自IP2)发来的请求，会发往静态路由模块处理；

计算节点的静态路由模块根据数据分片配置信息对SQL请求进行路由和解析。通过解析SQL请求，将SQL请求分为单独请求正式数据、单独请求灰度数据和同时请求多部分用户数据三种。请求正式数据的SQL请求发往正式数据库；请求灰度数据的SQL请求，以及同时请求多部分用户数据的SQL请求经数据改写模块改写后发往灰度数据库。

图9为本申请基于分布式数据库实现灰度发布的整体架构示意图，如图9所示，分布式数据库前端对接多个应用如图1中的应用1、应用2...应用X，多个应用分别用于处理来自正式用户的应用请求和来自灰度用户的应用请求。

分布式数据库中的数据节点集群包括多个数据结点如图1中的数据节点1、数据节点2...数据节点M，用于承载所有的用户数据。数据通过分片策略分布到多个数据节点，每个数据节点承载部分用户数据。

分布式数据库中的计算节点集群包括多个计算节点如图1中的计算节点1、计算节点2...计算节点N，用于对外提供服务，具体包括图8中的任一项计算节点。计算节点采用无共享架构，对应用提供统一的标准结构化查询语言(SQL)接口，多个计算节点进行负载均衡。计算节点根据数据分片信息，找到对应的数据存放位置，便可将对应的SQL语句发往对应的数据节点执行。

本申请还提出了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一种实现灰度发布的方法的步骤。

图10为本申请实现灰度发布的设备的结构组成示意图，如图10所示，包括处理器和计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令被所述处理器执行时，实现上述任意一种实现灰度发布的方法。

其中，计算机可读存储介质包括以下任意一种或任意多种：闪存、硬盘、多媒体卡、卡型存储器(例如，安全数码卡(SD卡，Secure Digital Memory Card)或数据寄存器(DX，Data Register)存储器等)、随机访问存储器(RAM，Random Access Memory)、静态随机访问存储器(SRAM，Static Random Access Memory)、只读存储器(ROM，Read Only Memory)、电可擦除可编程只读存储器(EEPROM，Electrically Erasable Programmable Read-OnlyMemory)、可编程只读存储器(PROM，Programmable Read-Only Memory)、磁性存储器、磁盘、光盘等。

处理器可以是中央处理器(CPU，Central Processing Unit)、控制器、微控制器、微处理器、或其他数据处理芯片等。

下面结合具体应用场景对本申请实现灰度发布的方法进行详细描述。

第一实施例为分布式数据库支撑业务进行多级灰度发布的实施例，图11为本申请实现灰度发布的第一实施例的示意图，如图11所示，第一实施例中的分布式数据库存在多个数据节点，正常情况下所有数据都存放在正式库上。当用户希望同时进行多种灰度修改的比较时，将灰度用户的数据分配到其它的多个数据节点如灰度1库、灰度2库...灰度n库上进行。具体包括：

使用分布式数据库的重分布功能，按照灰度测试的用户分布配置信息规则设置表的分片信息，采用预先设置的能满足业务合适的分片规则，将数据进行重分布操作：将应用于一类灰度修改的测试用户的数据配置到灰度1库上、将应用于二类灰度修改的测试用户的数据配置到灰度2库上、...、将应用于n类灰度修改的测试用户数据配置到灰度库n上；

分别对分片1到分片n进行表结构的灰度修改操作，分别对新分片上的表执行alter操作，如alter T set C＝C+1、alter T set C＝C+2、...alter T set C＝C+n；在不同分片上，针对表结构的灰度修改操作，添加对应的SQL改写配置，比如在数据节点n上添加C＝C-n。

这样，当系统运行时，计算节点的静态路由模块对原始SQL语句进行解析和路由拆分，所有拆分后的SQL经过数据改写模块，找到该SQL对应执行节点的SQL改写规则并改写后发往对应的灰度库执行。以语句select C from T为例，对应分片2上的语句改写为selectC-1from T，对应分片3上的语句改为select c-2from T，...对应分片n上的语句改写为select c-n from T。

所有联机的单节点交易(即只涉及一个用户数据的在线业务)会直接返回，如计算节点判断该语句只发往节点n，selcet c from T where id in set n，则语句会被改写成selcet c-n from T where id in set n；批量的跨节点交易(即涉及多个分片上多个用户的业务)由中计算节点汇总后返回，如计算节点判断语句发往节点(n-1)和节点n，selcet cfrom T where id in set{n-1，n}，则语句会被拆分成两条如：一条语句selcet c-(n-1)from T where id in set n-1发往节点(n-1)，另一条语句selcet c-n from T where idin set n发往节点n。

在各灰度节点测试完成后，如果某一灰度修改类型满足用户需要，可以直接通过该灰度节点的修改类型对应的SQL改写配置信息直接生成升级脚本，并利用该升级脚本对整个数据库进行灰度升级。

第二实施例为分布式数据库支撑全局业务统一建设，图12为本申请实现灰度发布的第二实施例的示意图，如图12所示，第二实施例中，假设业务设计部门负责建设统一的应用平台，对数据结构有统一的要求，以方便进行数据报表统计；而下属业务建设部门则各自有一些特殊的需求，对同一个业务的处理方式各有不同。在这种情况下，可以使用本申请的分布式数据库系统满足对全局业务的统一建设的需求。具体包括：

不同业务建设部门对统一的业务使用相同的表名T，同时满足平台对数据统一的要求。使用分布式数据库的重分布功能，按照各部门的用户分布配置规则设置表的分片信息，对数据重新进行分片：如将部门1的数据配置到分业务1库上、将部门2的数据配置到分业务2库上、...将部门n的数据配置到分业务n库上；各个建设部门按照各自的业务逻辑，修改各自的表结构，执行各自的alter语句。在不同分片上，各部门针对表结构的修改操作，添加对应的SQL改写配置规则。

这样，在系统运行时，计算节点的静态路由模块会对SQL语句进行解析和拆分，所有拆分后的SQL请求都有对应的分业务库，经过对应分业务库的数据改写模块，找到对应的SQL改写规则并改写后发往对应的分业务库执行。

仅涉及到各个业务建设部们各自业务库的数据会直接返回，而平台部门的统一的批量交易，如全局统计这样的跨业务库查询由计算节点汇总后返回。

不同的业务库始终保持不同的表结构和数据改写规则。这样，当各自的业务和平台统一的要求有冲突时，通过修改各自的表结构和改写配置规则来调整。

第三实施例为使用分布式数据库快速地进行业务的升级和回退，图13为本申请实现灰度发布的第三实施例的示意图，如图13所示，第三实施例中，使用本申请对应的升级和回退方法，快速地实现业务版本的升级和回退，而且基本不占用业务时间，且不会导致业务中断。具体包括：

业务需要进行升级时，不需要修改业务代码，只需要如通过对表结构进行修改，执行alter set C＝B+C语句，将原有表T(A、B、C)升级为表T(A、B、B+C)即可。针对从表T到表T、的表结构修改，新增对应的SQL改写配置信息即C＝B+C；新增配置后，所有与表T、相关的SQL语句都会被按照该SQL改写配置信息进行改写，即原有SQL代码中的C会被替换成C-B，替换完成后再发往对应的数据节点执行。

当业务需要进行回退时，不需要修改业务代码，直接在表T上执行alter set C＝C-B语句操作，将表T还原为之前的表T的数据结构，同时将SQL改写配置信息C＝B+C删除即可。这样，简单地实现了业务回退到之前的版本。

第四实施例4为使用SQL自动改写功能和路由屏蔽功能对业务进行热修复，图14为本申请实现灰度发布的第四实施例的示意图，如图14所示，第四实施例中，对分布式数据库的数据节点个数没有要求。正常情况下，业务运行正常。当遇到和SQL相关的业务逻辑错误(bug)时，可以通过本申请提供的SQL改写功能或者SQL屏蔽功能修改业务逻辑，以减少bug对用户的影响。具体包括：

生产环境正常运行中，如果出现逻辑bug，尤其是移动APP场景，应用已经分发到用户中断，不需要直接修复用户的客户端APP，针对这种问题，采用本申请有两种处理方式：

对于逻辑简单的bug，按照修复bug的逻辑，增加或者修改相关表的SQL改写配置信息，将原来有bug的SQL逻辑修改成正常的SQL逻辑，从而达到修复bug的目的。比如：原有SQL语句：select A from table T，假设业务中计算错了单位，需要返回的是1000*A，那么可以通过增加SQL改写配置信息即A＝1000*A，来修复这段逻辑即可；

如果逻辑比较复杂，比如通过SQL修改仍然不能修复该业务逻辑时，可以在计算节点的静态路由模块将相应的SQL语句屏蔽掉，比如：业务执行该SQL语句时，直接返回错误，这样也限制了bug影响的范围。

本申请提供的实现灰度发布的方法和装置，在不修改业务代码的前提下，解决了应用灰度发布需要不断对数据结构和业务逻辑修改的问题，将所有修改操作都归并到数据库上执行，并通过分布式数据重分布的功能方便了业务部门更加快捷地构造灰度业务数据，达到了节省系统资源投入、提升了业务灰度迭代效率。

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

Claims

1.一种实现灰度发布的方法，包括：

2.根据权利要求1所述的方法，所述方法之前还包括：

根据预先设置的所述分片配置信息，利用分布式数据库的数据分片功能，在数据库层区分所述灰度用户的数据和所述正式用户的数据；

其中，同一用户使用相同的分片配置信息。

3.根据权利要求1所述的方法，所述根据预先设置的分片配置信息对灰度请求进行解析之后，所述执行之前，还包括：

根据预先设置的灰度修改配置信息对所述第一灰度请求或所述第二灰度请求中请求灰度用户数据的部分进行改写。

4.根据权利要求3所述的方法，所述方法之前还包括：

根据所述灰度修改配置信息对灰度用户数据库的表结构进行改写，使得所述灰度用户和所述正式用户使用的数据表结构不一样，但使用相同名称。

5.根据权利要求1～4任一项所述的方法，如果所述确定出接收到的应用请求是请求正式数据的正式请求，还包括：

6.根据权利要求1所述的方法，其中，通过预先设置的IP白名单对所述接收到的应用请求进行过滤，来区分所述接收到的应用请求是请求灰度数据的灰度请求，还是请求正式数据的正式请求。

7.根据权利要求6所述的方法，其中，所述IP白名单包括：正式请求IP白名单和灰度请求IP白名单；

所述通过IP白名单对接收到的应用请求进行过滤包括：

确定来自正式请求IP白名单中的正式应用数据库客户端的应用请求为正式请求；

确定来自灰度请求IP白名单中的灰度应用数据库客户端的应用请求为所述灰度请求；

丢弃来自非白名单IP的应用请求。

8.根据权利要求1～4任一项所述的方法，其中，所述根据加载的分片配置信息对灰度请求进行解析包括：

根据所述灰度请求确定需要查询的表；根据所述分片配置信息查询该表的分片规则，并按照分片规则确定该灰度请求对应的数据节点。

9.根据权利要求1～4任一项所述的方法，所述第二灰度请求的数据执行完后，还包括：

将发往所述灰度用户所在的灰度数据节点的部分的执行结果，以及发往所述正式用户所在的正式数据节点的部分的执行结果进行汇总。

10.根据权利要求1～4任一项所述的方法，所述方法还包括：

对数据进行重新分布，将部分热点数据移动到新增分片中，或者将部分热点数据从负担大的数据节点迁移到负担小的数据节点。

11.根据权利要求1～4任一项所述的方法，所述方法还包括：根据所述灰度用户的应用特性，修改对应灰度表的表结构。

12.根据权利要求1～4任一项所述的方法，所述方法还包括：

当判断出灰度应用正式发布时，将所有正式数据库的数据结构修改为所述灰度应用对应的灰度数据库的数据结构；

当判断出灰度应用不适用时，将所述灰度应用对应的灰度数据库的数据结构回退为正式数据库的数据结构。

13.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述权利要求1～权利要求12任意一种实现灰度发布的方法的步骤。

14.一种实现灰度发布的设备，包括处理器和计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令被所述处理器执行时，实现权利要求1～权利要求12任意一种实现灰度发布的方法。

15.一种实现灰度发布的装置，包括：过滤模块、解析模块，以及转发模块；其中，

16.根据权利要求15所述的装置，所述装置还包括：

处理模块，用于根据所述灰度修改配置信息对所述第一灰度请求或所述第二灰度请求中请求灰度用户数据的部分进行改写，再将改写后的第一灰度请求或第二灰度请求输出给所述转发模块。

17.根据权利要求15所述的装置，所述过滤模块还用于：如果确定出所述接收到的应用请求是请求正式数据的正式请求，将正式请求转发至正式请求对应的正式用户所在的正式数据节点执行。

18.根据权利要求15、16或17所述的装置，其中，所述过滤模块用于通过IP白名单对所述接收到的应用请求进行过滤，区分所述接收到的应用请求是请求灰度数据的灰度请求，还是请求正式数据的正式请求。

19.根据权利要求15、16或17所述的装置，其中，所述IP白名单包括：正式请求IP白名单和灰度请求IP白名单；

所述区分所述接收到的应用请求是请求灰度数据的灰度请求，还是请求正式数据的正式请求包括：

确定来自正式请求IP白名单中的正式应用数据库客户端的应用请求为正式请求；确定来自灰度请求IP白名单中的灰度应用数据库客户端的应用请求为灰度请求；丢弃来自非白名单IP的应用请求。

20.根据权利要求15所述的装置，其中，所述解析模块具体用于：根据所述灰度请求确定需要查询的表；根据所述分片配置信息查询该表的分片规则，并按照分片规则确定该灰度请求对应的数据节点。

21.根据权利要求20所述的装置，所述解析模块还用于：

根据预先设置的所述分片配置信息，利用分布式数据库的数据分片功能，在数据库层区分灰度用户的数据和正式用户的数据；其中，同一用户使用相同的分片配置信息。

22.根据权利要求15所述的装置，所述处理模块还用于：根据所述灰度修改配置信息对灰度用户数据库的表结构进行改写，使得所述灰度用户和所述正式用户使用的数据表结构不一样。

23.根据权利要求15所述的装置，所述处理模块还用于：根据所述灰度用户的应用特性，修改对应灰度表的表结构。

24.根据权利要求15所述的装置，所述处理模块还用于：所述第二灰度请求在数据执行完后，将发往所述灰度用户所在的灰度数据节点的部分的执行结果，以及发往正式用户所在的正式数据节点的部分的执行结果进行汇总。

25.根据权利要求15所述的装置，所述处理模块还用于：对数据进行重新分布，将部分热点数据移动到新增分片中，或者将部分热点数据从负担大的数据节点迁移到负担小的数据节点。

26.根据权利要求15所述的装置，所述处理模块还用于：

27.一种计算节点，包括权利要求15～26任一项所述的实现灰度发布的装置。

28.一种实现灰度发布的系统，包括：分布式数据库中的数据节点集群、分布式数据库中的计算节点集群；其中，

分布式数据库中的计算节点集群包括两个或两个以上计算节点，用于对外提供服务，所述计算节点包括权利要求15～26任一项所述的实现灰度发布的装置。