在项目迭代的过程中，不可避免需要“上线”。上线就需要部署，或者重新部署；部署就意味着有修改；有修改意味着有风险。

目前有很多部署的技术，有的简单，有的复杂，有的得停机，有的不需要停机即可完成部署。


常用的部署方案：

一、蓝绿部署

       蓝绿部署是不停老版本，部署新版本然后进行测试，确认ok，将流量切换到新版本，然后老版本也升级到新版本。

        1、特点

             蓝绿部署无需停机，并且风向较小

        2、部署过程

              第一步：部署版本1的应用，所有请求流量都打到这个版本上。

              


              第二步：部署版本2的应用，版本2的代码与版本1不同（有新功能、bug修复等）

              


              第三步：将流量从版本1切换到版本2

              第四步：如果版本2测试正常，就可以删除版本1的应用，从此正式使用版本2

        3、小结：从过程不难发现，在部署的过程中，我们的应用始终在线，并且新版本上线的过程中，并没有修改老板的任何内容，在部署期间，老版本状态不受影响。这样风险很小，并且，只要老版本的资源不被删除，理论上，我们可以在任何时候回滚到老版本。

        4、蓝绿发布的注意事项

              当切换到蓝色环境时（新的代码），需要妥善处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题

                · 可能会出现需要同事处理“微服务架构应用” 和 “传统架构应用”的情况

                · 需要提前考虑数据库与应用同步迁移或者回滚的问题

                · 蓝绿部署需要有基础设施的支持

                · 考虑是否需要基础架构的隔离（VM、Docker）


二、滚动发布

        1、滚动发布定义

              一般是取出一个或者多个服务器停止服务，执行更新操作，并重新启动投入使用，周而复始，知道集群中所有的实例都更新成最新版本。

          


        2、特点

              · 这种部署方式相对于蓝绿部署，更加节约资源（它不需要运行两个集群，2倍的实例数）。我们可以取出部分部署，例如每次只取出20%进行升级。

              · 修改了现有的环境

              · 因为是逐步更新，你们我们在上线代码的时候，就会出现新老版本不一致的情况，如果对上线要求较高的场景，那么就需要考虑如何做好兼容问题

              · 如果需要回滚，很困难。举个例子，在某一次发布中，我们需要更新100个实例，每次更新10个实例，每次部署需要5分钟，当滚动发布到90个实例时，发现了问题，需要回滚，这个回滚是一个漫长，痛苦的过程。

              · 无法确定OK的环境，不易回滚


三、灰度发布/ 金丝雀发布

       1、定义

             灰度发布是指在黑与白之间，能够平滑过度的一种发布发昂是。ABtest就是一种灰度发布发昂是，让一部分用户继续使用A，一部分用户开始使用B，如果用户对B没有什么反对意见，那么就可以逐步扩大范围，把所有的用户都迁移到B上面来。灰度发布可以保证系统整体的稳定，在初试灰度的时候就可以发下安问题，调整问题以保证影响尽量小，而我们平常所说的金丝雀发布也是灰度发布的一种方式。

             

 

灰度发布／金丝雀发布由以下几个步骤组成：

  • 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
  • 从负载均衡列表中移除掉“金丝雀”服务器。
  • 升级“金丝雀”应用（排掉原有流量并进行部署）。
  • 对应用进行自动化测试。
  • 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
  • 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚） 

除此之外灰度发布还可以设置路由权重，动态调整不同的权重来进行新老版本的验证



--- 总结 ---


  • 蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚。
  • 灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本。
  • 滚动发布：按批次停止老版本实例，启动新版本实例。

如果你们运维自动化能力储备不够，肯定是越简单越好，建议蓝绿发布，如果业务对用户依赖很强，建议灰度发布。如果是K8S平台，滚动更新是现成的方案，建议先直接使用