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

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

1.结算模型的升级，结合业务考虑，引入了双消息消费的方式。

2.新老consumer无差别监听消息进行消费，造成消费遗漏。

3.SPE安全生产停留1小时的机制。

1.灰度时间总开关不变

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

[    {        "rate":5000,        "whiteList":[        ],        "activeTime":1682928000000    },    {        "rate":10000,        "whiteList":[

        ],        "activeTime":1683795376000  //未来时间    }]

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

1.降低发布带来的风险，让少部分用户先使用新功能新版本，提前小范围内发现bug或性能问题，及时做好修复，降低新功能新版本的影响。

2.通过新老版本对比，观察新功能带来的效果，更好起过渡效果。

2.2.1 明确灰度维度

常见的灰度规则有用户尾号（买家或卖家），业务单据id（如商品、订单、结算单、运单）、黑白名单、人群圈选（如定向投放）。黑白名单和人群圈选有点类似A/B-test，能比较精准的用于线上功能测试。一般用于两种场景：

1.风险极大，而功能测试又无法完全覆盖的场景，可以使用白名单和人群圈选做第一步的灰度策略。

2.功能存在争议，beta版功能测试，可以使用此法去收集反馈。

而采用用户id或业务id作为灰度条件，是更为通用的方式，这两种方案的流转模式如下：

尾号id灰度策略一般会与白名单策略组合使用，更稳妥的达到管控效果，结合我目前的项目实践，有一种较为万能的灰度公式分享给大家。

“1.白名单（个别用户）--> 2.买家尾号灰度1% -->3. 尾号3% -->4. 尾号10% -->5. 尾号30% --> 6. 尾号灰度50%-->7. 尾号灰度70%-->8. 尾号灰度100%”。

多数场景下，这一套公式流程是比较适用的。也许有同学会有疑问，是否可以采用“卖家id”灰度维度，多数情况下是可以的，但以卖家id为灰度规则，更容易命中到超大商家，可能带来的影响有两个，1.集中的单据被影响，2.相较买家购买，卖家维度更容易命中爆品热度的商品，引发数据库热点。因此，灰度维度的选择，是一件需要深思的事，我认为有几个原则需要遵守。

1.样本避免以偏概全，尽量保证样本的随机性，近似均匀分布。

这一点很好理解，比如你想统计有多少人坐过杭州地铁，然后你跑到杭州地铁站去做问卷调查，除了得到100%的结果，你一定会得到更多的白眼。同样，在灰度维度选择上，也需要保持样本的随机性。如用户id、商品id，一般就可以较好的满足日常灰度的需要。而像业务的人群id，在筛选时就得严格关注一下样本的随机性。

2.筛选条件需要由严至宽，逐步放开。

举一个例子，是去年进行某支付退款业务的中台升级时，在完成所有验证后，灰度策略里包含了一条，即逐步放开退款单的金额 ，从“控制退款单1元-->退款单10元-->30元-->100元-->300元-->全量放开”。这就是一种典型的风控层面的灰度策略，由严至宽。

2.2.2 做好过程观察和推进

灰度是一个逐渐由白至黑的过程，在这个过程中，“灰度可观察”和“灰度流程管理”，都需要做好。

灰度可观察

灰度过程必须可观察，这样才能及时发现问题，真正发挥灰度的价值。我总结了四个点，是灰度可观察的最小条件集，包括完备的流量日志、核对告警、反馈渠道及时触达和性能关注。以下逐一阐述。

策略一：完备的流量日志

完备的日志对于灰度过程中的问题发现是非常有必要的，将详细的处理逻辑，尤其是报错和异常的日志，是灰度可监控的必要条件。一方面，技术同学可以通过观察日志的错误日志，进行流量健康度的观察，另一方面，也可以结合 sunfire的统计监控能力，对灰度过程的报错做阈值告警。

策略二：核对告警

灰度项目中，核对也是常用的观测策略，无论是新业务的逐步上新或是新老业务的逐渐切换。如一个重资金相关的新业务上线，在逐步的灰度过程中，使用核对是验证非法单据的出现。这也是我日常业务跟进中经常使用的策略，比如RP3迁移灰度时，对打上新逻辑标的订单做校验。完备的日志是从系统处理的角度进行观察，而监控核对是从数据的角度进行另一个维度的观察，相辅相成不可缺少。

策略三：内部反馈渠道&舆情关注

这种策略一般用于白名单灰度的情况，且选中的白名单是与集团服务同学平时沟通较多且友好的商家，在百分比切流前，进行白名单个别商家的试点，关注异常情况。白名单内测后，切流阶段，如果有不可规避的风险，需要技术同学时刻关注客服反馈，必要时需要给客服统一的话术。

策略四：关注灰度过程中的性能问题

灰度不仅应用于功能，也可用于性能观察。灰度过程的流量是逐步增大的，新老功能的差异带来的性能影响，也是逐步放大的。比如一次改动中，新老流量模型中，对于某个信息字段的获取走的不同信息渠道，那么新老模型的性能差异就需要关注。此时不仅是业务的日志监控，应用系统的监控也需要安排上，尤其是灰度范围扩大的一段时间里，尤其需要关注接口性能，包括依赖rt变高，自身rt变高，数据库热点等问题。

灰度流程管理

好的灰度流程，需要具备优雅、可靠的特征。我认为“有序的推进”和“可及时回退”是灰度流程中必要的考虑。

有序的推进

从0到1的灰度过程，是一个边观察边推进的过程，通过日志、核对、自动化等手段做到有效观察后，在积累一定量级的单据后，再进行逐步的放开。需要关注的是如果配置非法状态下，是否保证老逻辑是否仍能正常消费。举例说明，下方伪代码是根据用户的尾号进行判断，在灰度配置平台里进行尾号的数字配置，那么，这一段代码看似正常，但实际隐藏着较大的风险：

//预期从灰度配置文件中读取一个int型的值，但配置中grayRange设置了一个字符串型“50%”,int grayRange = GrayHanlder.getConfig("灰度配置id").getInteger("grayRange");3if(userId mod 100 < grayRange){    //走新逻辑}else{    //走老逻辑}

灰度流程推进的前提，一定有效的流量观察之后，而不是形而上的依据灰度时长，请确保这一点。分享一个真实的故障案例：

灰度回退

当上线功能的表现不符合预期时，需要考虑控制灰度回退。一般在灰度的配置文件中，需要引入逻辑开关，值为true或false，命中true后，才会进入更细粒度的灰度命中。所以当结果观察不符合预期后，可以快速推进配置为false，必要时，走紧急审批。确保没有新流量走到灰度流程中。

灰度回退仅能阻止问题的扩大，但已出现问题的单据需要做好妥善处理，一般而言，有两种方案。

1.修订数据：新写修正接口或批量更改Db数据，但需要注意合规问题。

2.快速修复并发布新版本，利用升级来“回退”，覆盖上次灰度发布的修改。

这里仅讲一下服务端常用的灰度工具，一般都是轻量配置的平台，将配置内容脱离于代码之外，可以清晰快捷的推进，在灰度推进时，仅需做配置更新即可，不用发布代码。配置可以简单成一个String，也可以是一个json，举例如下。

      {        "flag": true,           //总开关，true为开启，false为关闭恢复        "buyerAccessFlow": 10,  //用户尾号控制，当前为尾号 0-9用户进入恢复        "amountLimit": 30000    //控制金额，金额小于300元，才进入恢复      }

许多同学对于灰度的认知还不多，认为分批发布也是一种灰度策略。其实严格意义上讲，应用的分批发布更多的是出于对系统稳定性的考虑，而不是灰度验证的考虑。从“可回退”的角度看，分批发布过程中，即使发现了问题，发现了脏数据，那数据也都是随机的，数据无法通过特征来找出数据，也就无法对脏数据进行订正或回滚，所以不是严格意义上的灰度策略。

灰度意味着线上存在两套处理规则或流程，一条业务单据在两套流程中处理的结果一般也是不一样的，因此确保单据在灰度过程中的一致性非常有必要，否则很可能引发线上问题，这里先举一个真实发生的例子

上述案例，是一个非常经典的问题，即灰度过程中数据一致性未能做好保证，导致出现两种打款策略组，破坏了幂等。那么怎么样保证灰度一致性原则呢？我认为有以下三个原则需要遵循：

原则一：灰度命中处理只能被一次消费

如上述案例，如果将灰度的判定放在“同意退款”，那就非常容易出现前后两次调用时，走到不同处理流程的尴尬情况，反之，我们可以巧妙的将灰度判定前移至“申请退款”，并打上相应的标，后续“同意退款”则按标进行即可，保证灰度命中处理只被一次消息。“同意退款”是想灰度的功能，但“申请退款”才是真正的灰度对象。所以想灰度的功能跟实现灰度的对象，并不一定要一致。

原则二：确保不同环境的灰度一致性

许多带安全生产环境的应用，从预发到线上前，需要在安全生产环境观察1小时以上，包括应用代码发布或配置发布。这中间的时差，极其容易引发灰度的混乱，比如开头说的那一个case，由于notify无差别的往安全生产和线上生产环境发消息，应用在两个环境中的配置不一致，导致消息被过滤的问题。

这种问题，就像使用原则一的方法进行预先打标处理，也是无法规避的，比较好的处理方法是，制造一个时延周期，确保线上生产和安全生产的一致性。比如推送一个未来的生效时间，且确保生效时间晚于全量发布完成后的时间，这样即可确保两个环境的一致性。

原则三：确保不同应用的灰度一致性

如果灰度流程涉及多个应用，那么灰度逻辑需要确保一致。简而言之，一个形如“A-->B-->C”的链路中，要么保证B系统无视A系统的灰度条件，要么确保灰度逻辑仅在A系统中进行判断。

前文提到的灰度策略，我均是从一个服务端的视角考虑，其实在前端或web端也有一些常用的灰度技巧，这里简单聊一下。

1.CDN资源分流

前端资源放在CDN上，每次发布新版本，资源即增量的传到CDN并指定唯一版本号。在处理请求时，依据前端策略来分流不同用户使用不同版本的CDN，展示不同的样式。此时，相应的后端接口，需要依据参数来控制灰度策略，区分前端不同的请求。一般在类似于账单业务升级时，会用到这种策略。因为前后端都需要灰度，所以需要由前端控制灰度策略，后端进行参数兼容，保证账单的多样性。

2.客户端分流

客户端分流的策略与CDN资源一样，由客户端来控制灰度分流，根据客户端传来的参数和版本号，结合当前的放量策略来决定服务情况。客户端分流的策略也会更多，如用户设备系统、app版本号、app安装渠道、用户ID、设备ID。

灰度很重要，灰度的策略也需要结合实际情况进行灵活的调整。本文中提到的策略、观点均是本人一得之见。引玉之砖，欢迎大家讨论。