文章插图
案例分析：发生的原因在于打款事项的幂等被破坏 。两个渠道无法感知对方的打款行为 。
案例解决：在申请退款时，即打上标，将灰度行为完全依赖于标识，后续所有的处理依标进行，避免不同调用引起的灰度不一致的行为 。后续退款相关的灰度行为，都前移至了申请退款阶段，此时命中灰度规则后，即会给它打上一个灰度标，后续的行为完全按标行走 。
上述案例，是一个非常经典的问题，即灰度过程中数据一致性未能做好保证，导致出现两种打款策略组，破坏了幂等 。那么怎么样保证灰度一致性原则呢？我认为有以下三个原则需要遵循：
原则一：灰度命中处理只能被一次消费如上述案例，如果将灰度的判定放在“同意退款”，那就非常容易出现前后两次调用时，走到不同处理流程的尴尬情况，反之，我们可以巧妙的将灰度判定前移至“申请退款”，并打上相应的标，后续“同意退款”则按标进行即可，保证灰度命中处理只被一次消息 。“同意退款”是想灰度的功能，但“申请退款”才是真正的灰度对象 。所以想灰度的功能跟实现灰度的对象，并不一定要一致 。
原则二：确保不同环境的灰度一致性许多带安全生产环境的应用，从预发到线上前，需要在安全生产环境观察1小时以上，包括应用代码发布或配置发布 。这中间的时差，极其容易引发灰度的混乱，比如开头说的那一个case，由于notify无差别的往安全生产和线上生产环境发消息，应用在两个环境中的配置不一致，导致消息被过滤的问题 。
这种问题，就像使用原则一的方法进行预先打标处理，也是无法规避的，比较好的处理方法是，制造一个时延周期，确保线上生产和安全生产的一致性 。比如推送一个未来的生效时间，且确保生效时间晚于全量发布完成后的时间，这样即可确保两个环境的一致性 。
原则三：确保不同应用的灰度一致性如果灰度流程涉及多个应用，那么灰度逻辑需要确保一致 。简而言之，一个形如“A-->B-->C”的链路中，要么保证B系统无视A系统的灰度条件，要么确保灰度逻辑仅在A系统中进行判断 。
3.4 前端灰度策略
前文提到的灰度策略，我均是从一个服务端的视角考虑，其实在前端或web端也有一些常用的灰度技巧，这里简单聊一下 。
1.CDN资源分流
前端资源放在CDN上，每次发布新版本，资源即增量的传到CDN并指定唯一版本号 。在处理请求时，依据前端策略来分流不同用户使用不同版本的CDN，展示不同的样式 。此时，相应的后端接口，需要依据参数来控制灰度策略，区分前端不同的请求 。一般在类似于账单业务升级时，会用到这种策略 。因为前后端都需要灰度，所以需要由前端控制灰度策略，后端进行参数兼容，保证账单的多样性 。
2.客户端分流
客户端分流的策略与CDN资源一样，由客户端来控制灰度分流，根据客户端传来的参数和版本号，结合当前的放量策略来决定服务情况 。客户端分流的策略也会更多，如用户设备系统、App版本号、app安装渠道、用户ID、设备ID 。
四、写在最后
灰度很重要，灰度的策略也需要结合实际情况进行灵活的调整 。本文中提到的策略、观点均是本人一得之见 。引玉之砖，欢迎大家讨论 。
作者:崔剑飞(木祎)
来源:微信公众号:阿里开发者
出处
:https://mp.weixin.qq.com/s/QPYprfHeHBnh38HQBh_K-w
【分享一例有意思的灰度设计缺陷，浅谈灰度方案的设计】
推荐阅读
- 程晓玥|程晓玥分享月子生活，被多人照顾生活惬意，哺乳画面曝光温馨有爱
- 人力资源|线上兼职有哪些可以赚钱的，靠谱的网上赚钱平台分享，建议先收藏
- 黄骨鱼|到钓黄鸭叫的时候啦！鲜嫩美味，野钓攻略分享
- 分享糖醋鱼的家常做法窍门
- 大厨分享干锅土豆片的做法
- 模型越大，AI编程个性化就越难？
- 金素妍|遭老公精神控制？金素妍分享甜蜜日常掀争议，急澄清他都是为我好
- 酒店管理|理诺士校友分享-酒店管理专业的广阔职业前景
- 手机上怎么拍照花草识别？分享个小妙招
- 鲫鱼|鲫鱼好钓又难钓，分享几个我的经验