系统灰度随笔记
这段时间系统重构，负责重构的其中一个模块需要与四个上游系统对接进行切换，虽然自己在这个过程中也设计了一套灰度方案来承接，将灰度的主动权控制在下游，但是很难同时应对四个上游系统，因为每个上游系统灰度的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年后才会去做付款，那正常情况我们是应该等到这笔在旧系统付款完，但是这会将整体灰度的时间拉的很长，在面对这种情况，我们可以加速灰度的进程。比如我们可以这部分旧数据进行打标，统计这部分的数据量，在新系统较为稳定的情况下，我们后续全量切到新系统之后，可以将这部分未付款数据初始化到新系统中，在新系统中继续进行付款。因此需要通过另一个维度来标识。
