蓝绿部署
蓝绿部署，英文名为 Blue Green Deployment，是一种可以保证系统在不间断提供服务的情况下上线的部署方式。
如何保证系统不间断提供服务呢？那就是同时部署两个集群，但仅对外提供一个集群的服务，当需要升级时，切换集群进行升级。蓝绿部署无需停机，并且风险较小。其大致步骤为：
部署集群 1 的应用（初始状态），将所有外部请求的流量都打到这个集群上
部署集群 2 的应用，集群 2 的代码与集群 1 不同，如新功能或者 Bug 修复等
将流量从集群 1 切换到集群 2
如集群 2 测试正常，就删除集群 1 正在使用的资源（例如实例），使用集群 2 对外提供服务
因为在使用蓝绿部署的方式时，我们需要控制流量，所以我们需要借助路由服务，如 Nginx 等。
滚动部署
滚动部署，英文名为 Rolling Update，同样是一种可以保证系统在不间断提供服务的情况下上线的部署方式。和蓝绿部署不同的是，滚动部署对外提供服务的版本并不是非此即彼，而是在更细的粒度下平滑完成版本的升级。
如何做到细粒度平滑升级版本呢？滚动部署只需要一个集群，集群下的不同节点可以独立进行版本升级。比如在一个 12 节点的集群中，我们每次升级 4 个节点，并将升级后的节点重新投入使用，周而复始，直到集群中所有的节点都更新为新版本。
这种部署方式相对于蓝绿部署，更加节约资源，因为它不需要运行两个集群。但这种方式也有很多缺点，例如：
没有一个确定 OK 的环境。使用蓝绿部署，我们能够清晰地知道老版本是 OK 的，而使用滚动发布，我们无法确定。
修改了现有的环境。
如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新 100 个实例，每次更新 10 个实例，每次部署需要 5 分钟。当滚动发布到第 80 个实例时，发现了问题，需要回滚。这时，我们估计就要疯了。
有的时候，我们还可能对系统进行动态伸缩，如果部署期间，系统自动扩容/缩容了，我们还需判断到底哪个节点使用的是哪个代码。尽管有一些自动化的运维工具，但是依然令人心惊胆战。
并不是说滚动发布不好，滚动发布也有它非常合适的场景。
金丝雀部署
金丝雀部署又称灰度部署（或者，灰度发布），英文名为 Canary Deployment，是指在黑与白之间，能够平滑过渡的一种发布方式。
金丝雀的名称来源于「矿井中的金丝雀」，早在 17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感，空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。
我们来看一下金丝雀部署的步骤：
准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件
从负载均衡列表中移除掉“金丝雀”服务器
升级“金丝雀”应用（切断原有流量并进行部署）
对应用进行自动化测试
将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）
如果“金丝雀”在线使用测试成功，升级剩余的其他服务器（否则就回滚）
在金丝雀部署中，常常按照用户量设置路由权重，例如 90% 的用户维持使用老版本，10% 的用户尝鲜新版本。不同版本应用共存，经常与 A/B 测试一起使用，用于测试选择多种方案。
金丝雀部署比较典型的例子，就是我们在使用某个应用的时候，该应用邀请我们进行“内测”或者“新版本体验”，如果我们同意了，那么我们就成了金丝雀。
