携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第12天，点击查看活动详情
对于中型及以上的企业互联网公司拥有的用户级基本都是百万级以上的。而当我们的产品需求又总是源源不断，一旦上线新的迭代功能出现问题都会直接影响用户的。对于企业来说可能是一场灾难。
现在很多企业可能没有设计灰度发布，或者说有灰度环境但是只是作为发布之前的一个预发环境。所以，在大型系统中容错是很重要。毕竟经历再严格的测试，上线后出现 bug 也是很正常的。为了让上线的功能产生的错误对用户的影响最少，可以分批上线或者让部分用户体验。这种方式就是灰度发布，也称为金丝雀发布。
金丝雀发布
金丝雀发布是一个将新版本推出给非常精选的用户列表的过程。开发者选择满足特定条件的人发布他们的更新。更改/更新最终将发布给所有人，但一小部分用户可以先于其他用户体验它。
如果初始用户发现任何错误或问题，开发人员可以立即修复并启动新的更新。如果他们发现新版本没有任何错误，他们可以将其发布给整个用户群。
常用的灰度发布的实现方式有两种：
- 分批次部署发布
- 通过业务规则部署发布
通过分批次部署发布
分批次部署根据部署服务器的维度进行设计的。某服务可能部署了十几个实例甚至更多。
设计原理
将所有实例进行分组，分组规则：2的倍数扩展。即如15个实例划分四组：1 2 4 8。这样划分可控制划分组不会太多，这样部署次数也不会太多。如有1024台机器的话也只需部署十次就可以。
然后只需观察已部署的机器日志，发现错误则修复。完全没问题后再部署第二组，依次下去。
存在问题
- 每次都需要检查没问题才继续进行，实例很多的话工作量也会多，可能需要一整天时间都在跟进。效率极其低。
- 此方案测试可能需要内部人员自己测试，才能准确命中服务器，线上用户可能命中率很低
通过业务规则部署发布
根据某种业务策略，让部分用户优先体验功能，这样出问题只影响部分用户。
设计原理
用用户 id，手机号，设备信息等相关信息，生成哈希值，再进行求模。然后根据比例将部分用户的访问路由到新版功能，就灰度环境。部分用户还是保持访问旧版功能。这样当新版用户使用时出现问题则进行修复，当完全都没有错误时则可以全部上线到所有服务内。
通过取模策略是一种单策略。当有多个服务或者说微服务环境下，可能需要组合策略，比如多个服务同时灰度，或者仅其中几个灰度环境其他不需要灰度环境。这时可以增加一个 Tag 进行标识。
优势
- 降低测试成本，提高上线的效率
- 对于大部分用户来说服务是高可用的
参考资料：