滚动更新，蓝绿部署，灰度发布

这3种 现代化的 发布模式相信很多人都听过， 但是并不是都能正确理解他们的作用和区别

滚动更新 Rolling Update

所谓滚动更新是for 那些多实例的service的。

假如1个 service 有n 个instance, 更新时并不是n 个 instance 同时更新， 而是有先后顺序。

rolling update 是k8s 提供的一个招牌特性

解决的问题：
这样的话在整个更新区间， 都保证至少1个instance 是在线的， 这样对用户来讲更新是无感知的， 实现所谓的高可用和0 downtime

未解决的问题：
假如新版本是有问题的， 有严重的bug, 在滚动更新区间是没有验证的， 所以当整个更新完成后还是有很大由于bug导致风险

原理如图：

蓝绿部署 Blue-Green Deployment

蓝绿部署 通常发生在传统的on-prem的service上
但它不一定是for 多instance 的 service的

定义
它是一种在生产环境中同时部署并运行两个完全独立的应用程序版本的策略。在蓝绿部署中，蓝色环境代表当前的稳定版本，而绿色环境代表新版本。新版本的应用程序在绿色环境中进行测试和验证，然后通过切换路由或负载均衡器将流量从蓝色环境切换到绿色环境。一旦验证通过，可以将流量完全切换到绿色环境，并最终关闭蓝色环境。

也就是讲， 蓝绿部署的前提是 一套与当前正在运行的生产环境 同样规格的备用servers

当要部署时

首先把新版本的service部署到 备用服务器上。(绿色)
然后在备用服务器上做一些必要的验证

一旦验证通过
就把正在运行的 gateway/lb 切换到备用服务器， 备用变成正式生产(绿色)
然后关闭旧生产的实例(蓝色)

解决的问题：
添加了验证步骤，规避了一些操作风险。 对大部分用户来讲也是无感知的。

未解决的问题:
在有限时间情况下， it人员的验证范围有限
额外一套 infra, 成本昂贵

原理如图：

灰度发布 - Gray Release - Canary Release

灰度发布也叫 金丝雀发布 Canary Release

定义
灰度发布是一种逐步将新版本应用程序引入生产环境的策略。在灰度发布中，新版本的应用程序会逐渐在一小部分用户或流量中进行测试和验证，然后逐步扩大范围，直到完全替换旧版本。它允许在生产环境中逐步验证新版本，并及时回滚以避免大规模影响。

简单来讲
假如我某个service 生产上运行着4个instance

在第一阶段我先发布新版本到某1个instance 上， 这时其他3个instance 还是旧版本

而且我会在这个阶段停留一段时间， 这时在生产上有3/4 用户还是用着旧版本， 没有受影响， 只有1/4用户用了新版本， 他们参与了验证

如果验证通过
在逐步发布到其他instance上

其实原理和滚动更新有点类似， 只不过大大减缓了整个发布的时间， 让部分用户参与验证，避免了大规模的生产事故

解决了的问题：
让部分用户参与验证， 让生产事故的影响减到最少

未解决的问题:
整个发布周期更长