代码更新方法：
蓝绿部署：
蓝绿部署，英文名：Blue Green Deployment，是一种可以保证系统在不间断提供服务的情况下上线代码的部署方式。
如何保证系统不间断提供服务呢？
蓝绿部署的模型中包含两套集群。
在正常情况下（没有上线操作），集群A和集群B的代码版本是一致的，并且同时对外提供服务。
在有项目代码上线的时候，我们首先把一个集群（比如集群A）从负载列表中摘除，进行新版本的部署。集群B仍然继续提供服务。
当集群A升级完毕，我们把负载均衡重新指向集群A，再把集群B从负载列表中摘除，进行新版本的部署。集群A重新提供服务。
最后，当集群B也升级完成，我们把集群B也恢复到负载列表当中。这个时候，两个集群的版本都已经升级，并且对外的服务几乎没有间断过。
负载均衡是：挂一端，另外一端也要顶得住。
在用户比较少的情况下可以干这个事情。
先对一个Web服务器升级更新，再对另外一台服务器进行升级更新。
蓝绿部署是费钱，需要两套集群。
滚动更新：
滚动更新，**英文Rolling update，**同样是一种可以保证系统在不间断提供服务的情况下上线代码的部署方式。
和蓝绿部署不同的是，滚动部署对外提供服务的版本并不是非此即彼，而是在更细的粒度下平滑完成版本的升级。
如何做到细粒度平滑升级版本呢？
1台1台地进行升级、或者2台2台地进行升级、或者4台4台进行升级......或者某几台分批进行升级。
最终所有的节点都升级了版本。
容器升级很快。
第2个容器（新的版本）很快替换第1个容器。容器是轻量级的虚拟机。
蓝绿部署和滚动部署两者对比：
蓝绿部署：2套进行切换，最终实现升级的方式。切换是两者都要启动，然后负载均衡进行切换。
数据冲突的情况下，后台数据库也要进行升级。
整套升级，还是要容器方便。
滚动部署：快速地分批次升级，最终达到全部升级的目的。
在容器平台比较容易实现。
灰度发布（A/B测试，金丝雀部署）
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。
AB test就是一种灰度发布方式，**让一部分用户继续用A，一部分用户开始用B，**如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
游戏公司的内测体验。
政府政策试点。
灰度发布可以保证整体系统的稳定，**在初始灰度的时候就可以发现、调整问题，以保证其影响度，**而我们平常所说的金丝雀部署也就是灰度发布的一种方式。
比较平滑，保证整体的稳定。及时发现和调整问题。
金丝雀：试点。
灰度发布/金丝雀部署步骤：
-
准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
-
从负载均衡列表中移除掉"金丝雀"服务器。（把权重调为0，新的请求就不找你，老的流量会断。）
-
升级"金丝雀"应用（排掉原有流量并进行部署）。
-
对应用进行自动化测试。
-
将"金丝雀"服务器重新添加到负载均衡列表中（连通性和健康检查）。（把权重改为原来的值。）
-
如果"金丝雀"在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
除此之外灰度发布还可以设置路由权重，动态调整不同的权重来进行新老版本的验证。
滚动更新：在容器中比较容易实现。