系统灰度随笔记
这段时间系统重构,负责重构的其中一个模块需要与四个上游系统对接进行切换,虽然自己在这个过程中也设计了一套灰度方案来承接,将灰度的主动权控制在下游,但是很难同时应对四个上游系统,因为每个上游系统灰度的key是不同的,在技术实现难度上比较大。同时跨部门对接沟通成本非常大,每个部门的排期也都非常紧张,是需要硬技能和软技能的同时结合才能完成的。因此来谈谈怎样设计一个可靠的灰度方案。
如果设计可靠的灰度方案
1.灰度的基本概念
1.1基本灰度方案
一个较大的业务或系统改动,往往会影响整个产品的用户体验或操作流程。为了控制影响面,可以选取一批特定用户、流程、单据等,只允许这一部分用户或数据按照变更后的新逻辑在系统中流转,而另一部分用户仍然执行变更前的老逻辑。这一步是线上系统灰度方案的起点。按这个逻辑进行数据切分之后,我们主要关注灰度的数据,是否按照新逻辑,产生了预期的结果,因此灰度线上验证工作非常重要
1.2 灰度解决什么问题
比如说系统在重构之后,新旧系统数据的一致性怎么保证,如何不影响旧系统的运转逻辑,毕竟全量切换之后,如果新系统出了问题,那将是灾难性的问题。安全生产规则中所谓的“无灰度,不发布”就是这个思想,通过灰度尽可能的减少问题的影响面。如果通过灰度过程发现一个线上问题,那么去掉灰度的保护,可能就会产生一个严重的故障。
2.灰度设计要解决的基本问题
2.1 灰度维度的选取
生产系统中常见的灰度的规则,有用户id尾号、业务单据id尾号、白名单、黑名单、时间戳等。
采用用户id尾号或业务单据id尾号作为灰度key,是更常见的灰度区分方式。但如何选取这类灰度key,需要注意几个要点。
1.灰度key的数据最好是均匀的,比如与客服系统对接,现在各大电商公司,下单之后还需应对非常多的客服问题,当某个系统与客服系统对接时,在灰度切换时,可以选择用某个客服工号来进行灰度,只灰度这个客服对应的单据。每个客服对应的单量一般来说是比较均匀的,数据量相差不大。在与杉杉系统对接切换,杉杉奥莱有很多家门店,我们可以按门店的维度来进行灰度切换,在与海淘对接切换,我们按照供应商ID来实现灰度方案,每个系统都可以按照自己业务的维度来实现灰度。
2.系统中使用灰度key的选取逻辑要简化,灰度key作为判别是走新逻辑还是旧逻辑,这个条件判断一般会在系统中反复出现、多次执行。除此之外,简化key的计算逻辑也会带来业务语义上的简化,便于整个业务链上的技术同学与非技术同学快速理解,也便于遇到问题时快速定位与排查,更有利于系统的长期维护。
2.2 简化灰度逻辑
灰度逻辑仅仅是将一个用户或单据非此即彼的区分开,因此灰度逻辑不仅没有必要做的太过复杂,而且还应当尽量简化,如果业务上有条件,最好能用一个字段或一个变量搞定。
首先,比如说电商公司,很多家集团公司,有很多业务是根据公司维度去做灰度的,我们就可以通过一个字段来配置。比如通过一个字段来配置灰度开关,有利于完成灰度进度的调整,例如灰度快进,灰度暂停等,如果设置了多个灰度变量,在调整灰度变量时,可能会导致灰度覆盖不全,灰度数据不一致等复杂问题。我之前在设计灰度方案的时候,想同时兼容上游灰度情况,通过3个变量来进行灰度,同时需要配置上游来源系统,每个来源系统又会有一些重叠的情况,比如杉杉是按公司ID来灰度,账单是按供应商ID来灰度,如果每个系统都想按照自己的业务维度来灰度,那么我在下游做灰度兼容时就会异常的复杂,比如同时调整公司维度和供应商维度,那么可能会导致一部分用户数据被跳过,或者导致调整后的灰度范围远远超过预期,这些问题在实际生产中是发生较为频繁的,因此我们需要简化灰度逻辑。
2.3 灰度过程保持数据一致性
灰度数据一致性的问题是系统设计的核心问题。比如最近重构的费控系统,对接客服切换,老系统的业务还在继续发生,新的系统已经上线,外部系统在切换过程中将一小部分数据命中新系统,其他的业务数据继续流向老系统,当用户在某个时刻命中了新系统,如果在另外一个时刻新系统逻辑问题或者灰度回退等情况,导致了没有命中灰度,这时就造成了数据不一致问题。
因此我们必须制定灰度的规则
1.以灰度命中数据作为标准,上游系统下发了数据给新系统,新系统做完逻辑操作之后,更新表,上游应从新系统拿回结果,而不应该从旧系统去拿回结果。
2.加速推进灰度速度,保持新旧系统数据的一致,比如一个上游下发数据到新旧系统做付款,但是由于业务原因,这笔付款一直在旧系统没有付款,比如说要等到1年后才会去做付款,那正常情况我们是应该等到这笔在旧系统付款完,但是这会将整体灰度的时间拉的很长,在面对这种情况,我们可以加速灰度的进程。比如我们可以这部分旧数据进行打标,统计这部分的数据量,在新系统较为稳定的情况下,我们后续全量切到新系统之后,可以将这部分未付款数据初始化到新系统中,在新系统中继续进行付款。因此需要通过另一个维度来标识。