灰度(金丝雀)发布、蓝绿部署、滚动发布

概念 

一、灰度(金丝雀)发布

定义

灰度发布又叫金丝雀发布，只升级部分服务，即让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本没什么意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来。 (金丝雀发布由来。以前，旷工开矿，在下矿洞前需要检查下方是否有毒气，矿工们先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来。)

实现

原理流量切换与灰度策略.实现方式参考以下 - 基于openresty+nginx实现前端灰度 - 基于apollo+ribbon实现后台灰度(关联知识点eureka元数据metadata-map)

二、蓝绿部署

定义

把环境分为AB组，首先把A组从负载均衡中摘除，把B组加入负载均衡中提供服务。类型A/B Test出发点不一样。

优缺点

• 发布简单
• 硬件数量翻倍

三、滚动发布

定义

滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。在金丝雀发布基础上的进一步优化改进，是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式。

总结

• 蓝绿发布：操作简单，硬件数量翻倍，以硬件换取操作。SLB进行切换几乎不停机，需考虑新旧环境切换对业务的影响。
• 灰度发布：硬件数量在原数量+1，此方式实现不停机发布，并且通过分流实现新旧并行，出问题后也可区分出新旧环境。
• 滚动发布：硬件数量在原数量+1，此方式实现不停机发布，并没有灰度发布明确的分流，出问题后不能快速区分出新旧环境，滚动发布主要体现出自动的发布策略依赖自动发布工具。如k8s就是现成的支持。滚动发布对于达到一定业务体量的公司，考虑到用户体验对业务的关键性，则需要投入研发资源开发支持滚动式发布的工具和配套的智能 LB，实现自动化和零停机的发布。
• 滚动与灰度：*滚动式发布一般和金丝雀发布配合，先发一台金丝雀去验证流量，再按批次增量发布。两者主要区别在于灰度强调是部分节点给指定用户体验没问题后再扩大发布，而滚动强调的是自动节点的更换，相对有一定风险两都结合即减少人工工作量风险也降低。*

实际实现

Kubernetes 项目中一个重要的设计思想：控制器模式Deployment，即Pod的“水平扩展 / 收缩”（horizontal scaling out/in）。这个功能，是从 PaaS 时代开始，一个平台级项目就必须具备的编排能力。

举个例子，如果你更新了 Deployment 的 Pod 模板（比如，修改了容器的镜像），那Deployment 就需要遵循一种叫作“滚动更新”（rolling update）的方式，来升级现有的容器。而这个能力的实现，依赖的是 Kubernetes 项目中的一个非常重要的概念（API 对象)：ReplicaSet。

ReplicaSet 的结构

更重要的是，Deployment 控制器实际操纵的，正是这样的 ReplicaSet 对象，而不是 Pod 对象

Deployment，与 ReplicaSet，以及 Pod 的关系

通过这张图，我们就很清楚的看到，一个定义了 replicas=3 的 Deployment，与它的ReplicaSet，以及 Pod 的关系，实际上是一种“层层控制”的关系。

其中，ReplicaSet 负责通过“控制器模式”，保证系统中 Pod 的个数永远等于指定的个数（比
如，3 个）。这也正是 Deployment 只允许容器的 restartPolicy=Always 的主要原因：只有在容器能保证自己始终是 Running 状态的前提下，ReplicaSet 调整 Pod 的个数才有意义。

而在此基础上，Deployment 同样通过“控制器模式”，来操作 ReplicaSet 的个数和属性，进
而实现“水平扩展 / 收缩”和“滚动更新”这两个编排动作。

有了 Deployment 的能力之后，你可以非常轻松地用它来实现金丝雀发布、蓝绿发布，以及 A/B 测试等很多应用发布模式