灰度发布

什么是灰度发布？

灰度发布是指在 黑和白(0和1)之间，能够平滑过渡的一种发布方式。

AB test就是一种灰度发布方式，指为产品已发布A版本，在发布B版本时，在同一时间维度。

让一部分用户继续用A版本，一部分用户开始用B版本，如果用户对B版本没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B版本上面来。灰度发布可以保证整体系统的稳定，在初始灰度发布时就可以发现及调整问题，以保证其影响度。

灰度发布好处

降低发布影响面： 就算出问题，也只会影响部分用户，从而可以提前发现新版本中的 bug，然后在下一次发布前提前修复，避免影响更多用户；

提升用户体验： 除了能发现 bug，还能很好的收集新版本的用户使用反馈，从而提前调整系统，提升用户体验，也能给后续的产品演进带来参考价值。

可以做到不停机的热迁移，版本回滚便捷（速度快）

灰度发布分类

蓝绿发布(Blue-Green Deployment)

蓝绿发布提供了一种零宕机的部署方式。不停老版本，部署新版本进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。始终有两个版本同时在线，有问题可以快速切换。

蓝绿部署中，一共有两套系统：

• 一套是正在提供服务系统，标记为“绿色”；
• 另一套是准备发布的系统，标记为“蓝色”。

优缺点

• 优点：新版本升级和老版本回滚迅速。用户可以灵活控制流量走向
• 缺点：成本较高，需要部署两套环境（蓝/绿）

比如日常运行时，需要10台服务器支撑业务，那么使用蓝绿部署，你就需要购置二十台服务器。

金丝雀发布/灰度发布(Canary Release)

灰度发布 Gray Release（又名金丝雀发布 Canary Release）

不停机旧版本，部署新版本，高比例流量（例如：95%）走旧版本，低比例流量（例如：5%）切换到新版本，通过监控观察无问题，逐步扩大范围，最终把所有流量都迁移到新版本上。属无损发布

在软件开发中，灰度测试通常涉及将新功能或更新推送到一小部分用户，例如5％或10％的用户。

这些用户将能够使用新功能或更新，而其他用户则不会看到它们。

通过监视这些用户的反馈和行为，开发人员可以评估新功能或更新的效果，并识别任何问题或错误。

在Java中，可以使用一些工具来实现灰度测试，例如FeatureToggle和LaunchDarkly。

这些工具可以帮助开发人员轻松地控制新功能或更新的推出，并监视用户反馈和行为。

• 优点：灵活简单，不需要用户标记驱动。安全性高，新版本如果出现问题，只会发生在低比例的流量上
• 缺点：成本较高，需要部署稳定/灰度两套环境

滚动发布（Rolling Release）

每次只升级一个或多个服务，通过观察无问题，不断执行这个过程，直到集群中的全部旧版本升级到新版本。属有损发布

K8S 默认采用了滚动发布

• 优点：成本较低，只需要部署一套环境。出现问题影响范围，只限于发生在若干台正在滚动发布的服务上
• 缺点：停止旧版本的过程中，无法精确计算旧版本是否已经完成它正在执行的工作，需要靠业务自身去判断。旧版本不保留，一旦全部升级完毕后才发现问题，无法快速回滚，必须重新降级部署。发布和回滚需要较长的时间周期