分享一例有意思的灰度设计缺陷，浅谈灰度方案的设计 _灰度设计

导读
灰度很重要，灰度的策略也需要结合实际情况进行灵活的调整，本文跟大家分享了一个前些时间发现的灰度设计bug 。
一、案例分享

跟大家分享一个前些时间发现的灰度设计bug，这个bug蛮有意思，看似完美方案，但因为未考虑到一些技术特性，导致存在缺陷。为更通顺的说明，先进行一些名词介绍。
灰度发布：灰度发布是指在黑与白之间，能够平滑过渡的一种方式。AB-test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。（引用Wiki百科）
安全生产环境：（简称SPE）为保障线上稳定性提供灰度流量生产环境。发布从预发到生产环境前，需要经过SPE进行流量验证。

1.1 案例简述

同一个应用，需要消费同一个topic消息两次，因不同环境的配置不一致，导致消息存在消费遗漏。

1.2 案例背景

需求的主要修改的点是将历史各异的结算模型改成统一结算模型，新老模型相差较大。在notify消息的处理上，原本是想在同一个consumer处理类中改写，但成本较大，且考虑到老模型后续是需要下线的，从代码整洁的角度出现，新写了一个消息处理类，使用另一个group组订阅，最终的结果就是同一个topic消息会被两个group组订阅，并由两个consumer类去消费。

1.3 方案描述

原灰度方案如下：设定一个时间作为灰度生效时间，再通过消息中买家的尾号作为切流条件。当一个消息被接收时，会先判断当前时间是否大于灰度时间，若满足大于灰度时间的条件，则判断买家尾号是否在灰度切流范围中，均满足时，走新的结算流程。若两个条件有一个条件不满足，则走老结算流程。

文章插图

1.4 方案缺陷分析

上述方案，一般而言，是一个很不错也很完备的方案，但结合本次结算模型迁移的背景，则存在一个缺陷。缺陷的由来即是“双消息” 。那么双消息处理是怎么引发问题的呢？原因在于灰度配置文件在安全生产和线上生产间阶梯推进时，需要等待1小时，这一小时会导致部分消息被遗漏。假设当前SPE和线上生产已同步推进至10%，此时SPE的配置推进至20%，线上生产依旧保留10%，那么双消息一条走到SPE，另一条走到安全生产时，即会出现问题，因为SPE的老group实现类只关心80%-100%的流量，而线上生产环境只关心0-10%的流量，中间存在消息遗漏。逻辑如下?图：

文章插图

1.5 案例的特殊之处

1.结算模型的升级，结合业务考虑，引入了双消息消费的方式。
2.新老consumer无差别监听消息进行消费，造成消费遗漏。
3.SPE安全生产停留1小时的机制。

1.6 改进策略

1.灰度时间总开关不变
2.买家尾号的灰度策略改为“尾号为K，区间生产时间为V”的KV对，其中V是一个未来时间，且“V值>系统时间+安全生产停留时间” 。如下，从50%流量推至100%，100%的流量配置生效时间是一个未来时间。

[{"rate":5000,"whiteList":[],"activeTime":1682928000000},{"rate":10000,"whiteList":[],"activeTime":1683795376000//未来时间}]

在跟进完上述问题后，我查阅了过去一年部门故障复盘文档，基本所有的故障和资金事件复盘，均有提及灰度手段。而像本案例中，于“不确定行为”进行灰度的控制，是新人们常见的误区。因此，结合自己在交易线的一些经验，谈下我认知中的灰度，并将阐述我理解的MVP版灰度方案，至少需要些什么，灰度设计中需要注意什么。
二、设计一个MVP版的灰度方案

2.1灰度方案是什么？

在聊how的问题前，有必要先讲一下WHAT和WHY 。先聊一下WHY，假设没有任何管控流程，代码发布后立即全量上线，又恰巧不幸地出现系统、数据或逻辑等方面的问题，那一场灾难也就随之而来，而且业务体量越大，风险&舆情&资损的敞口也就越大，损失越不可挽回。因此，发布流程需要必要的管控和监督，将风险控制在有限范围内，这样的发布流程即是灰度。平滑过渡是灰度重要特征，这个特征也决定了灰度发布的作用至少有两点：