关于部署策略的遐思

随着技术和工具的不断发展、不断完善，终端用户对于互联网产品的预期日渐提升，在这样的背景下，不同的部署策略应时而生。本文对不同的部署策略展开了详细的介绍，并通过不同部署策略之间的对比，试图帮助读者决策适合他/她的部署策略应当是什么样子的。

随着 DevOps 的兴起，人们越来越意识到部署策略的重要性。再美好的代码架构，再完美无缺的代码质量，没有了部署策略的加持，都无法产生最终价值。上线——产品研发的最后一公里，很短又很艰难。当谈及产品上线时，最重要的便是部署策略。

何为一个部署策略

当我们想要部署应用程序的时候，我们需要谨慎的规划每一个步骤。因为每一个步骤都有可能被终端用户感知，影响终端用户的使用效果。部署的目标便是在不停机且不影响用户体验的情况下实现应用程序的安装或者升级。而部署策略则是对这样的升级过程的指导，部署策略不因软件架构以及所使用的工具、技术本身产生差异。下面，我们就一起来看看不同的部署策略。

纷繁复杂的部署策略

就地部署

就地部署，又称之为 BigBang/ReCreate。如下图所示，整个部署分为三个阶段：

• 阶段一，通知应用系统终端使用用户，应用系统即将进入升级维护阶段，通常通知里要告知终端用户系统升级维护时间的时长；

• 阶段二，应用系统挂起维护页面，此时终端用户再访问原有应有系统时只能看到维护页面的信息；与此同时，应用团队开始部署；

• 阶段三，应用团队部署完成，挂在内部测试域名，测试成功后，应用系统撤销维护页面，终端用户恢复对于应用系统的访问。

滚动部署

滚动部署，又称之为 Rolling Upgrade。如下图所示，整个部署无明显阶段分割:

• 步骤一：新的应用系统开始部署。新的应用系统实例会被创建出来；

• 步骤二：路由切换，终端用户的流量会指向新的部署好的应用系统实例；

• 步骤三：老应用系统被删除。

需要注意的是，从应用系统的角度来讲，上述不同步骤无明显阶段分割。在部署进行的过程中，应用系统的不同组成部分（如微服务架构中，不同组成部分即每一个微服务的实例）都尝试在当前环境中创建新的实例并切换路由到新实例，整体部署时长为第一个实例路由切换到最后一个应用系统实例路由切换之间的时长。

基于不同策略的滚动部署

对于下述部署策略可以简略得认为他们都是某种滚动部署，但也正因为如此，不同部署策略之间的分别到底是什么才更加令人疑惑。在接下来的部分里，让我们一起看看。

蓝绿部署

蓝绿部署，其滚动的方式为新建一整套应用系统，等待新的应用系统就绪即可切换，整个部署阶段大致分为三个：

• 阶段一，部署准备，在这个阶段里终端用户使用的是蓝系统，即下图所示 v2；绿系统会进入部署状态；

• 阶段二，开始部署，绿系统升级，直至绿系统变为当前应用系统的最新版本；

• 阶段三，路由切换，终端用户的请求被指向绿系统，应用系统部署完成。对于应用系统研发团队而言，在产品环境中总是存在蓝、绿两个版本的应用系统，同一时间终端用户只可感知到其中一个版本的应用系统的存在；蓝、绿两个系统的版本交替升级，同一时间不存在相同版本的蓝系统和绿系统。在这样的部署策略里，滚动是取决于应用系统研发团队的。

金丝雀部署

金丝雀部署又称为灰度发布或红黑部署。金丝雀部署的名称来源于矿场工作的场景，由于金丝雀对矿场中的毒气比较敏感，在矿场开工前工人们会放一个金丝雀进去，来验证矿场是否存在毒气，这就是金丝雀发布的由来——通过金丝雀来验证新的应用系统版本是否可用。下图展示了金丝雀部署的整个阶段：

• 阶段一，部署准备，此时可以看到全部终端用户都只能访问到老版本的应用系统；

• 阶段二，新版本应用部署，在这个阶段中产品环境会运行起两个版本的应用系统，但是对于终端用户来说他们能访问到的依然是老版本的应用系统；

• 阶段三，新版本应用系统测试运行，在这个阶段中大约 10%的终端用户会变成金丝雀用户，他们会访问到新版本的应用系统。金丝雀用户的选择，可能与其使用的设备相关、或者是一些地域性因素等等。这个阶段的关键在于金丝雀用户的使用体验，如果一切正常，则会进入阶段四。

• 阶段四，完全全部终端用户到新版本应用系统的切换。在这样的部署策略里，滚动或者切换的发生主要取决于终端用户的反馈。灰度发布策略则是在金丝雀部署策略上的演变，区别主要在于阶段四，在金丝雀部署中，阶段四是全部切换的，90%的终端用户同时感知到新版本的应用系统。而在灰度发布中，阶段四的切换是梯度的，终端用户对于新系统的感知从最初的 10%到 20%再到 30%等等，逐渐扩散直至 100%的用户全部看到新系统。

A/B Testing

与其他的策略不同，A/B Testing 更像是一个产品策略，它的指导意义不在于部署本身如何进行，而是在于业务层面。当业务层面，不确定特定场景的业务功能哪样对于终端用户更合理时，A/B Testing 确实能够帮助到决策。在 A/B Testing 中，终端用户会被分成两组甚至更多，处于不同组别的用户在相同场景下，他们感知到的功能是不同的，这里所说的功能可能是页面的样式、交互的体验，甚至是提供的业务功能本身，比如推荐的算法、具体的业务流程等等。

暗部署

在暗部署策略中，应用系统本身部署的频率可能很高，但是对于终端用户来说这种部署是感知不到的——用户并没有体验到新功能。如下图所示：

• 部署开始前，用户可以感知到系统中已经部署的三个模块；

• 部署完成后，应用系统当前多了一个红色模块；但是对于终端用户来说，红色模块还是未知或者不存在的；

• 待功能完备或者完整测试完成后，终端用户的流量就会进入新的红色模块；此种部署策略，通常伴随着 feature-toggle 的使用一起。

不可变部署

该部署策略主要是为解决部署中可能存在的 SnowflakeServer 现象而存在的。环境的管理对于应用研发团队来讲是十分困难的，虚拟机、操作系统、安装软件、应用配置等等，配置管理不当就会导致 Configuration Shift 的问题出现，进一步导致 SnowflakeServer（每一台服务器都或多或少存在着不同）的问题。不可变部署即认为每一次的配置更新对映射着一个全新的实例，并不存在对于已有实例的配置的修改，通过这种方法避免了对于实例配置手动修改所带来的问题和风险。事实上，上述任何一种部署策略都可以融入不可变部署的思想，增加应用团队对于环境配置本身的掌控权。

不同部署策略之间的优劣势

在不同的场景下，部署策略的建议如下：

• 从产品发展的角度来考虑：

• 如果一个产品尚在 beta 阶段，仅有相对少量的衷心用户，那么就地部署是最经济实惠的选择；如果产品已经面向市场，考虑到终端用户的影响，那推荐的是零当机时间的部署；

• 从用户基数的角度考虑，基数很大、覆盖地理区域广泛的时候，建议考虑金丝雀部署或者灰度发布；基数相对较小的时候，蓝绿部署是较为简单的选择；无论是蓝绿部署还是金丝雀部署，都可以考虑和暗部署进行结合，缩短部署周期，提升部署频率。

• 无论对于何种部署策略，如果想要支持回滚的操作，都需要考虑有状态的数据的存储问题。在都考虑了有状态数据的存储的情况下，回滚的影响的区别点在于对终端用户影响的范围（即广度和时间）。

• 从回滚的时间点上来说

• 发生在终端用户感知新系统之前：就地部署策略

• 发生在终端用户感知新系统之后：滚动部署、蓝绿部署、金丝雀部署、暗部署；

• 对于终端用户影响的范围（广度和时间）

• 影响时间不可控：滚动部署（依靠所使用的技术和工具来决定滚动时间长短）

• 影响用户范围大小：

• 少量用户：金丝雀部署仅影响金丝雀用户

• 全部用户：蓝绿部署和暗部署，影响时间较短，发生问题以后可以立刻回滚；

• 想要做到有状态数据的零当机部署，需要考虑数据的增量修改，每一次对于数据库或者有状态数据的修改都要考虑向后兼容，以数据库为例，如果想要删除某一列，则删除操作需要拆解为两个步骤：先在某次产品发布中从代码层面消除对待删除列的依赖；再在下一次部署中删除数据库中的这一列；

• 从开发成本上来说，

• 成本最小：

• 滚动部署在大多数容器管理的工具中都有支撑，对于业务代码本身的侵入性较小因此开发成本也最低；

• 中等：

• 就地部署需要考虑维护页面的搭建以及部署期间到部署完成时流量的切换（维护页面与产品系统之间）；

• 暗部署，主要是长期研发过程中对于 feature toggle 的管控；

• 高成本：

• 蓝绿部署与金丝雀部署，主要成本在于对终端用户的分割以及终端用户接触新系统后系统的监测（从监测结果才可以推导出是否可以开启新系统）

特别需要注意的误区：

• 使用蓝绿部署即可迅速回滚是错误的。产品发布失败后是否可以回滚主要取决于有状态数据的变更方式，如果有状态数据不能做到增量修改，那么即使绿版本部署失败想切回蓝版本也会因为有状态数据已经变更而失败（比如数据库的 schema 已经发生了向后不兼容的更改），相反，在没有处理好有状态数据变更而使用蓝绿部署时，反而会增加环境的维护成本以及基础设施运行的成本；

• 基于暗部署的持续发布，部署频率等同于特性发布频率的说法是错误的。使用暗部署的方式进行特征发布，确实可以缩短部署频率，从而降低每一次发布（由基础设施变更带来）的风险，但是暗部署成功以后，业务特性并没有真正发布。业务特性的发布可能需要几次暗部署才能支撑上。

最后，本文介绍了当前市面上几种常见的部署方式，并对每一种部署方式进行了不同维度的对比，也澄清了一些概念层面的误解，希望本文有助于你决策自己的部署策略。