增量部署还是全量部署，你应该如何选择？ 嘉宾介绍 许桂林目前在FIT2CLOUD负责公司的技术布道和生态合作。在此之前，他曾就职于意法半导体、欧特克和阿里云。许桂林热衷于云计算（尤其是公有云IaaS平台）。拥有多年AWS生产环境工作经验。是较早在国内分享AWS实战经验的作者之一。 1。Preface 应用部署是工程人员（包括开发、测试、运维）每天面临的重要问题之一。尤其是现在应用交付的频率越来越高，工程师往往需要花费巨大的成本和精力来完成频繁的应用部署工作。在过去的六个月里，我们接触了大量来自不同行业、不同规模的企业客户，但我们发现他们在应用部署上都有一个类似的困惑，那就是应该选择增量部署还是全量部署。在这里，我们希望扩展我们的观点。在开始讨论这个问题之前，让我们先重新定义两个问题。 部署还是释放？ 部署一般是指将应用程序或服务“安装”到目标环境（开发、测试或生产）中，而发布是指将应用程序或服务交付给最终用户使用。尽管这两个动作（尤其是在生产环境中）经常同时发生，但它们应该是两个完全不同的阶段。事实上，一个好的持续交付流程应该将“部署”和“发布”解耦为两个独立可控的阶段。 部署包括什么？ 不管是增量部署还是全量部署，都需要注意部署的内容是什么，尤其是在微服务被广泛讨论的今天。从部署的角度来看，我们将任何可独立部署的内容称为“部署单元”。一个部署单元可以是一个模块，也可以是几个模块的组合，也可以是一个完整的应用，如何划分取决于具体的场景。总的来说，划分部署单元的最佳实践是一个可以独立演进、部署、与应用程序其他部分松散耦合的集合。 弄清了以上两个问题后，我们可以更准确地将这里要讨论的话题表达为“一个部署单元应该增量部署还是全量部署？” 二、增量部署 增量部署一般是指在每次部署过程中，先提取当前版本与待部署版本之间的增量（包括代码、可执行文件或配置等），只更新部署过程中的增量部分。这种部署方式的常见部署流程如下： 1.使用代码管理工具（SVN、GIT等）提取两个版本之间的增量，并结合其他方面的增量变化。 2。根据增量部分制定具体的部署方式，编写部署脚本，准备增量部署包（包括混淆代码等）。 3。将增量部署包分发部署到已运行上一版本的目标环境，完成系统的版本升级。 目前很多企业都在使用这种部署方式，尤其是主要使用动态语言（如PHP、Python、JavaScript等）的团队。团队选择这种部署方式的主要原因可以归纳为： 1。部署速度快。增量部署每次只更新增量部分，文件分发和配置更新的内容会少一些，部署需要的时间也比较短。 2。减少变异量。增量部署可以减少整个系统的改动幅度，很多已经完成的配置任务不需要每次都重复。这样可以避免误操作，降低部署失败率。 3。提高安全性。增量部署每次只涉及增量代码部分，不会直接暴露系统的整个代码部分更新，避免了系统代码泄露的风险。 3。增量部署和全量部署 在仔细比较这两种部署方式之前，我们需要思考一下对于一个部署操作来说，哪些考虑是最重要和最核心的，我们应该优先保证的。在我们看来，部署操作最重要的考虑因素应该是部署操作的“可重复、可预测、不可撤销”，其次才是部署的效率和安全性。之所以这样定义优先级，主要是因为目前的系统部署普遍面临以下“三多”挑战： 1。部署操作的数量太多。持续交付已经成为企业共同的追求，也是企业IT服务能力的核心指标。当部署数量增加时，每次部署的可预测性和回滚性是最基本的保证，否则很难做到频繁部署。 2。部署环境变化很大。随着企业IT基础架构的云化和动态化，部署环境不仅面临传统开发、测试、预发布和生产（DTAP）环境迁移的挑战，而且各个环境的内部基础架构也频繁变化。许多（增量和全量部署场景会出现并频繁切换）。这对部署的可重复性提出了非常高的要求。 3。有许多部署操作员。随着自动化部署和持续交付的普及，越来越多的人需要能够进行部署操作。这不仅包括传统的开发、测试和运维人员，还包括公司管理人员，甚至需要快速部署一套系统（用于演示或其他目的）的营销和销售人员。这也需要非常可预测和可重复的部署操作。 如果我们对比以上需求，我们会发现“增量部署”在满足这些需求上有很多挑战，可以分析如下： 1.增量部署对部署之外的任何更新都非常敏感，降低了部署过程的可预测性。 在日常工作中，经常会出现临时修改运行环境来修复问题的部署外更新。一旦在增量计算中没有及时考虑到这些部署外的更新，就非常容易导致后续的增量部署失败。全部署流程会完整的执行整个环境的配置、初始化、部署，对这些非部署的更新有更好的容错能力。 2。增量部署使得回滚操作非常困难。 每次回滚都需要逆向计算增量部分，然后进行回滚操作。及时的备份策略有机会降低这个难度，但如果需要回滚多个版本，仍然是一个巨大的挑战。 3。增量部署不能直接满足日常从零开始部署***系统的需求。 云环境中资源的动态变化（尤其是虚拟机的增减）将逐渐成为一种常态，用户可能时刻面临两种场景的部署需求：从旧版本升级到最新version，或者从头开始重新部署最新版本的应用程序。显然，这两个部署需要增量更新，另一个需要完整更新。 如果团队将“增量部署”作为日常的部署方式，必然需要维护两种部署模式，增量部署和全量部署。但是，如果统一使用“全部署”，就可以避免这个问题。一个部署过程统一了两种不同的部署需求，增强了部署的可重复性。 以上挑战使得增量部署模式越来越难以满足高频部署的工程需求。越来越多的自动化部署系统和工具选择了全量部署模式。当然，在选择全卷部署方式时，也需要慎重考虑前述全卷部署方式的弊端。简单来说，我们可以通过以下策略来解决或缓解这些弊端： 1。在开始部署操作之前，提前在本地准备好全量部署所需的所有资料（部署包、配置文件等）。这样就可以将部署操作变成本地操作，大大提高了部署的效率和速度。 2。通过灰度发布或负载均衡等方式降低全量部署对应用可用性的影响。同时可以有效解耦部署和发布两个阶段，提高应用发布的灵活性。 4。如何选择部署模式？ 上文提到，越来越多的部署系统或工具选择全量部署方式，但这并不意味着增量部署就没用了。相反，很多状态相关的部署单元（比如数据库）基本上不能采用全部署模式，最典型的就是“数据库模式”的更新操作。对于这里的部署需求，工程师基本上只能采用增量部署，需要仔细设计部署流程、脚本和回滚策略。 综上所述，对于现代系统中大多数状态无关的部署单元（应用、模块、微服务等）来说，全量部署一般应该是最好的选择。状态相关的部署单元（数据库等）仍然适用于增量部署逻辑。
