1.2.2 灰度发布

灰度发布又称“金丝雀发布”，是一种在新旧版本间平滑过渡的发布方式。它起源于采矿工人的实践经验，金丝雀对瓦斯气体非常敏感，瓦斯浓度稍高就会中毒，采矿工人在探查矿井时，会随身携带一只金丝雀，如果金丝雀的生命体征出现异常，就意味着矿井中存在瓦斯浓度过高的风险。

灰度发布背后的理念很简单，用较小的代价（一只金丝雀）去试错，这样即便出现了风险（瓦斯浓度过高），主要的用户群体（采矿工人）也仍然是安全的。从软件工程的角度来讲，如图1-8所示，通过引流的方式让少部分线上用户先接触到新版本功能，同时技术人员在新版本功能上做一些验证工作，观察监控报警，确认功能无误后，逐步将流量切换至新版本上，直至所有流量都切换完毕。

图1-8 灰度发布的引流策略

如果在切换的过程中发现新版本功能有问题，则应该立即将所有流量切回旧版本上，将影响范围降至最小。

灰度发布的技术实现并不困难，方案也比较丰富，较为简单的做法是引入带权重的负载均衡策略，将用户请求按比例转发至新旧版本上。一些开源服务组件支持灰度发布功能的定制，例如，我们可以基于Apache Dubbo中的Router/LoadBalance实现灰度发布功能，也可以在Spring Cloud中基于Ribbon定制实现灰度发布功能，甚至可以直接使用Nginx Ingress在网关层实现灰度发布功能。

灰度发布有如下3种常见的策略。

● 按流量比例：这是最简单的灰度发布策略，也就是将流量按比例转发至新旧版本上，以达到灰度发布的效果。

● 按人群特点：根据人群的特点（如用户ID、用户所在地区、用户类型、用户活跃度等）进行导流，以便精准地管控灰度范围。

● 按渠道：根据不同渠道（如注册方式、手机运营商、App平台等）进行导流，这也是一种精确的灰度发布策略。

最后，我们有必要谈一下灰度发布策略的一些常见误区，以帮助读者举一反三。

● 以偏概全：选择的灰度范围不具备代表性，比如我们上线了一个针对会员的新功能，但选择的灰度发布策略所覆盖的大部分用户不是会员，这就大大影响了灰度发布发现问题的能力。

● 无效灰度：灰度的本质是提前试错，但前提是有能力试错。笔者曾经历过一次印象深刻的高级别线上事故，研发人员更改了用户下预约单的逻辑，引入了一个bug，这个bug本应在灰度发布阶段被发现，但遗憾的是，灰度发布时已是当天21点，而灰度发布策略所涵盖的门店恰恰在21点全部关店歇业了，导致没有任何灰度流量触及新功能，研发人员误认为一切正常，最终引发了事故。由此可见，灰度发布策略需要保证新功能一定被验证到，不存在无效灰度的情况。

● 监控缺失：我们不仅需要有效的灰度发布策略，还需要辅以完备的监控，以便及早发现风险，采取止损措施。