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

灰度流程管理好的灰度流程，需要具备优雅、可靠的特征。我认为“有序的推进”和“可及时回退”是灰度流程中必要的考虑。
有序的推进从0到1的灰度过程，是一个边观察边推进的过程，通过日志、核对、自动化等手段做到有效观察后，在积累一定量级的单据后，再进行逐步的放开。需要关注的是如果配置非法状态下，是否保证老逻辑是否仍能正常消费。举例说明，下方伪代码是根据用户的尾号进行判断，在灰度配置平台里进行尾号的数字配置，那么，这一段代码看似正常，但实际隐藏着较大的风险：
//预期从灰度配置文件中读取一个int型的值，但配置中grayRange设置了一个字符串型“50%”,int grayRange = GrayHanlder.getConfig("灰度配置id").getInteger("grayRange");3if(userId mod 100 < grayRange){//走新逻辑}else{//走老逻辑} 上述代码在执行时，会报错，导致新老逻辑都不会走到。当然，在实际业务需求中，很少发生这么低级的错误，但我的意思是，依赖于配置的灰度推进，需要确保灰度逻辑进行必要的验证，灰度的推进也需要极其的谨慎。一般而言灰度代码只是一个if+else，但其背后影响却极大。

文章插图

灰度流程推进的前提，一定有效的流量观察之后，而不是形而上的依据灰度时长，请确保这一点。分享一个真实的故障案例：
案例名：某B系业务的会员子账号id写入错误导致无法处理退款。
故障原因：因修复一个会员登录bug，更新了一个冷门字段的获取逻辑，某B系业务使用此字段做权限控制，导致业务受到影响。
灰度过程：此案例中的发布应用，在发布过程中进行了灰度停留，但灰度时间是晚上，而被影响的B系业务特性决定了晚间时分是流量低谷期，导致灰度过程中的问题未被及时关注，灰度流程未发挥应有的效用。
灰度改进：涉及会员和商家操作的系统，灰度发布时间包含商家操作高峰期（上午8点--10点）。?
灰度回退当上线功能的表现不符合预期时，需要考虑控制灰度回退。一般在灰度的配置文件中，需要引入逻辑开关，值为true或false，命中true后，才会进入更细粒度的灰度命中。所以当结果观察不符合预期后，可以快速推进配置为false，必要时，走紧急审批。确保没有新流量走到灰度流程中。
灰度回退仅能阻止问题的扩大，但已出现问题的单据需要做好妥善处理，一般而言，有两种方案。
1.修订数据：新写修正接口或批量更改Db数据，但需要注意合规问题。
2.快速修复并发布新版本，利用升级来“回退”，覆盖上次灰度发布的修改。

2.3 灰度工具

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

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

三、关于灰度其它常见的问题

3.1 机器分批发布不是严格意义上的灰度策略

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

3.2 灰度设计的一致性原则

灰度意味着线上存在两套处理规则或流程，一条业务单据在两套流程中处理的结果一般也是不一样的，因此确保单据在灰度过程中的一致性非常有必要，否则很可能引发线上问题，这里先举一个真实发生的例子
案例名：某电商业务增加一种退款打款渠道，灰度策略不合理导致双渠道出账的情况。
案例描述：RPC调用退款同意时，第一次命中尾号灰度，走进组合渠道中，但组合渠道里出现调用异常，但此时渠道会进行自身的重试。在重试期间，用户二次点击，此时灰度策略有变化，导致走到了另一个组合渠道，进行了打款并成功。?