引言
近年来,互联网公司业务迅速扩展，用户需求频繁变化，传统基于单体架构的软件系统难以适应互联网技术的快速发展。
因此,微服务架构应运而生，将单一应用划分成众多规模较小、功能专一的服务。其中，每个服务对具体业务逻辑进行封装构建，独立运行于生产环境中，通过服务模块之间的相互配合以对外提供服务。
微服务架构由于模块自治性强，可以满足互联网应用变化快、模块独立更新的需求。但是微服务模块数量众多、交互复杂,增加了运维的难度与成本，如何应对微服务快速频繁的更新与部署已成为微服务架构应用亟需解决的主要问题之一。
为了实现关注点或任务的分离，将微服务的开发测试和运行维护过程进行严格区分，使得不同项目组具有不同的目标与流程。
开发人员的目标是快速将变更实现到生产环境，而运维人员的目标是保持生产环境的稳定，这成为快速频繁发布软件的障碍。开发和运维人员之间的协作通常通过手工进行，该过程低效且易错，因此将更改应用、增加特性和修复错误实现到生产环境中需要投入大量的人力和时间。
为了快速响应用户需求以及微服务应用的不断变化，软件企业需要应对快速频繁的微服务应用发布，填补开发和运营之间的鸿沟。DevOps是应对微服务应用开发与运维的新兴技术,可以实现开发和运维两个部门间的有效协作。
微服务应用实例不仅需要部署到开发环境以运行测试用例或者检查更新代码，也需要不断部署和重新部署到生产环境以提供服务。
由于应用会频繁部署到不同环境，实现高效自动化的应用部署至关重要。同时，应用需要从简单的开发环境到复杂的分布式生产环境无缝对接，部署逻辑需要具有可移植性。
DevOps社区提供开源工具(如Chef,PuppetAnsible)来支持部署过程自动化以实现软件的持续交付；在中间件与应用层,可以获取可重用的构件(如脚本、模板)以实现部署自动化；在基础设施层，云计算平台为应用按需提供底层物理资源自动化部署API。
因此,本文结合各层次多种技术、服务和构件以应对各类微服务应用的部署问题，从而实现高效的微服务组件组合和自动化的微服务应用组件部署。
本文面向DevOps提出了一种高效动态的应用部署引擎OpsFlow，设计与实现了技术框架以自动生成OpsFlow，最后，通过实验评价了生成OpsFlow的开销，并且使用微服务应用的实例研究验证了方法的有效性。
微服务应用自动化部署
2.1应用自动化部署引擎OpsFlow
应用部署引擎OpsFlow目标是组合多种自动化部署技术以应对异构应用与部署环境，从而实现高效自动化的微服务应用部署。
OpsFlow作为可移植可定制的部署逻辑包，为用户或外部系统提供API以便于部署应用实例，同时也提供管理逻辑对已部署的某些应用组件进行扩展，具有以下功能:
1)为特定应用实例指定编程语言以生成可移植包，使得应用实例在本地主机开发环境、本地服务器测试环境、远程云计算生产环境等不同的环境中运行；
2)生成可执行构件(如脚本、编译程序)以实现“原子”部署操作,其实现形态是安装和配置软件包的部署脚本,或是通过调用云服务接口来使用虚拟资源的代码；
3)编排多个部署可执行程序以形成云应用部署模板。部署可执行程序负责执行部署计划，协调部署操作，并创建特定应用拓扑；
4)提供公开API以触发部署计划的执行或创建应用拓扑，如图1所示API可以被用户或外部系统调用。例如，高层调度器可以根据当前负载调用OpsFlow接口以创建更多应用实例。
OpsFlow系统架构根据应用拓扑动态生成定制的OpsFlow引擎具有以下优点:
1）只包含实现部署操作所必需的部署可执行程序,具有较少的软件规模、资源消耗和配置操作，以及较高的性能。
2）打包所需要的部署可执行程序，以自包含方式部署特定应用，彼此间相互独立。由于不依赖于集中的中间件，避免了单一故障点，从而具有更高的可靠性。
3）使用开源生态系统提供的可重用构件（如Chef、Juju）自动生成部署计划，实现部署可执行计划的编排和执行，开发人员只需调用所需的API而无需手动开发粘连代码。
2.2OpsFlow部署引擎生成方法
OpsFlow的动态生成方法如图2所示，分为设计、构建和运行等三个阶段，遵循通用规范使用不同技术实现。
1）设计阶段：创建和维护应用拓扑模型；根据基础设施、中间件和应用组件选择部署可执行程序，这些可执行程序可以定制开发，也可以使用现有构件（如Chef，Juju，fog，Jclouds）；将所需的部署可执行程序关联到应用拓扑。其中，部署可执行程序，既可以独立开发，也可以重用现有开源社区提供的构件。对于现有开源部署构件（如Chef Super⁃market，Docker Hub），由于每个开源社区独立维护存储库，并且提供有限的搜索能力，因此缺乏全面的知识，难以选择合适的构件，本文通过整合知识库的元模型来解决该问题。部署需求来自于应用拓扑，可以通过需求参考文件来表达部署可执行程序的需求以及与其他部署可执行程序的关联。
2）构建阶段：创建部署计划，即部署可执行程序，编排所有必需的部署可执行程序，以创建特定应用拓扑模型的实例。部署计划可以手工完成，也可以使用计划自动生成技术，如使用 BPEL引擎自动生成应用部署的工作流程；在创建部署计划时，所有必需的部署可执行程序都已就绪，生成 Ops⁃
Flow部署引擎。
3）运行阶段：生成可定制的 OpsFlow 引擎；根据建模的应用拓扑，提供 API 以创建部署计划，并部署与管理应用实例；如果不需要部署和管理更多的应用实例，则终止OpsFlow引擎。
2.3 OpsFlow部署引擎生成框架
OpsFlow 部署引擎生成框架如图 3 所示，包括设计、构建和运行等三个阶段，具体包括以下几个组件。
应用拓扑模型的建模环境：建立和维护应用拓扑模型，并将所需的部署可执行程序关联到这些拓扑模型中的组件和依赖项。
部署计划产生器：动态自动生成部署计划，能够处理创建的应用拓扑模型。为了将建模环境与计划生成器分离，本文使用基于标准的建模方法（如 TOSCA［10］）。为了达到自定义目标而改进部署计划，则需要提供相应的部署计划开发环境，本文将Eclipse BPEL Designer作为BPEL工作流环境。
API 生成器：生成部署可执行程序，隐藏和抽象实现的技术细节，创建通过 API 访问的部署计划，实现在不修改源码的情况下包装部署可执行程序。例如，如何调用可执行文件，如何传递输入参数，以及如何收集输出数据。如果涉及多个特定应用的部署可执行程序，手工为单个应用包装可执行文件以实现API耗时费力，那么就需要自动化创建API。由于使用多种自动化技术来部署异构应用，需要手工修改与细化部署计划。特别是，当使用工作流建模语言（如 BPEL），集成各种技术非常复杂且容易出错，因此，将这些技术特点及其调用机制封装在 API 中，就可以使用 HTTP 等标准化通信协议来调用。部署计划生成器不需要了解各种技术的调用机制细节，而只需了解如何调用API以支持自动生成部署计划。
部署引擎包装器：生成自包含的 OpsFlow 引 擎，作为可移植可执行包，在运行时部署应用实例。API生成器和OpsFlow引擎包装器都可以基于API化框架实现，比如Any2API［11］。OpsFlow 引擎运行时环境：根据 OpsFlow 引擎的打包格式，使用API来部署和管理应用实例。同 时，通过使用可移植的虚拟化方法，可用于在不同的环境中打包和执行OpsFlow引擎。
2.4 OpsFlow部署引擎生成框架实现
本文基于 TOSCA 实现了原型系统，其中的工 具链用以应对可移植性和可扩展性，涵盖了设计、 构建和运行等三个阶段。在设计阶段，建模工具提 供了可扩展的基于 TOSCA标准的建模环境以改善 可移植性。并且，使用 Winery［12］ 实现应用拓扑建模，以管理不同类型的组件和依赖关系。
在构建阶段，本文使用 OpenTOSCA 作为部署 计划生成器以动态为特定应用拓扑模型生成部署 计划，从而满足应用拓扑的特定部署需求。对于常见的通用组件类型（如 MySQL 数据库和 Apache 服 务器），部署计划生成器能够自动生成部署计划，而无需手工进行细化。
在运行阶段，基于工作流建模语言（如 BPMN 或 BPEL）生成的部署计划，需要在构建时生成相应的API以暴露部署可执行程序所需功能，这些功能关联到应用拓扑模型的组件和依赖项。本文使用 Any2API 框架生成这些 API，例如，为部署可执行程序生成基于 SOAP/WSDL 的 Web 服务 API，以支持在 BPEL中实现的部署计划，从而调用和处理底层的可执行程序。
另外，当使用脚本语言（如Python 或 Ruby）与相关库（rest-client）连接一起实现部署计划时，生成基于 RESTFul的 Web API。由于生成的部署计划也是通过调用 API 执行的，基于 API 的递归聚合可以支持众多不同的拓扑模型。
最后，Docker容器作为可移植的虚拟化技术在构建时使用 Dockerfile 包装OpsFlow引擎 ，同时使用 Any2API执行包装操作。
3.实例研究
3.1 实验环境
本文以典型的网上商店应用作为实例来分析 应用部署所面临的问题。图 4 描述了网上商店应用架构，采用混合云部署方式，由左边部署在Ama⁃ zon EC2 的应用和右边部署在OpenStack的数据库构成，以避免将敏感数据暴露给公有云服务提供 商。PHP应用部署在 Apache服务器以展示用户界面并执行业务逻辑，数据库采用 MySQL 主/从模式以提高应用的可伸缩性与高可用性。
应用由不同 组件构成，采用不同部署技术。其中，Web 应用使用 Unix Shell脚本部署，PHP 模块和 Apache 服务器使用Chef部署，Mysql数据库使用Juju部署。同时， 在基础设施层（包括虚拟机和网络配置）使用 Fog 部署，与云计算平台（Amazon、OpenStack）通过 API 进行交互。
实现该应用部署涉及到多种类型的部署脚本和构件，需要考虑众多技术细节和差异，除了特定 应用的 Shell 脚本外，Chef 和 Juju 都需要特定部署引擎支持。
此外，应用拓扑以多云方式部署，即 Amazon作为公有云服务提供者，而OpenStack作为私有云管理平台。 通用的自动化部署框架（如 OpenTOSCA， Terraform，Brooklyn）通过引入统一的元模型进 行抽象以实现不同部署可执行程序的编排，使得不 同方法使用相应的元模型，但需要手工对特定部署模块进行适配开发而不能自动实现。
同时，由于通用的部署引擎需要支持多种部署方法，通常是重量 级模块，维护复杂度高。
3.2 开销分析
实验使用三种公开的 Chef cookbooks 来部署Apache服务器、PHP运行时环境和 MySQL数据库， 实现两个 Ruby 脚本在 Amazon EC2 云基础设施上 部署虚拟服务器，使用 Amazon 关系数据库服务 （RDS）部署MySQL数据库实例。
该实验系统部署在一台虚拟机（4 个 2.8 GHz 主频 64 位的虚拟 CPU，4 GB 内存），使用 Virtual Box Hyperviso，在 Debian Linux 容器中完成部署可 执行程序的处理和调用。
本文监测容器层的所有 度量，关注部署可执行程序和 API 实现相关的度量，执行每个部署可执行程序 20 次（其中，10 次有 API 实现，10 次没有 API 实现）。每组 10 次执行中 的 5 次是初始执行（在干净的部署环境中运行，而 没有执行任何操作），另外 5 次是后续执行。
生成 API 实现的平均时间是构建阶段的开销，为 8s~ 33s，其中包括检索特定部署可执行程序的依赖项。由于对生成的API进行了简化，运行时具有较 少的执行时间和较小的内存开销。
此外，当直接使 用简单的部署可执行程序，编排组件会减少生成 API实现的复杂性。因此，资源的总体消耗取决于 所选的编配方式，同时可以复用API实现在不同的 远程环境中运行可执行程序，以减少大型运行环境 的开销。
本文从设计、构建和运行等三个阶段对应 用部署开销进行评估，实验结果如下：
1）设计阶段：生成 API 所需的时间，实验结果 如图5所示；
2）构建阶段：部署可执行程序所需时间，实验 结果如图 6所示；
3）运行阶段：可执行程序运行所需内存，实验 结果如图7所示。
4.相关工作
与传统的通用部署引擎不同，OpsFlow 在运行 时不依赖于集中的中间件。论文利用可扩展的通用部署引擎来部署和管理各种应用，通过减少生成定制引擎的步骤来减少构建时的开销。与 OpsFlow相比有以下几个缺点：
1）通用部署引擎提供的 API并不适合所有的部署场景，需要实现多种部署 技术，具有较高的复杂性，因而难以维护和扩展；
2）通用部署引擎通常采用集中式中间件，存在单点失 效的问题，因此需要维护其可靠性。
3）使用通用部 署引擎通常需要领域知识，通过二次开发来包装现有的 API，从而实现多应用组件部署的编排。
4）通用部署引擎不是专门针对给定的应用拓扑，因此运行开销较高。
Bootware首先创建部署引擎，然后用其部署应用实例，该方法使用通用部署引擎，而 OpsFlow是面向特定应用动态生成的部署引擎。论文将不同类型的部署可执行程序转换为基于 TOSCA 标准的构件，便于现有多样化开源生态系统所提供内容的复用。该方法虽然能够有效实现设计阶段和构建阶段的部署自动化，但是在运行阶段需要通用部署引擎来部署和管理应用拓扑。
云提供商提供了建模和编排工具，同时提供了PaaS （Platform-as-a-Service）服务，调用该服务可以 部署和管理应用实例，而不需要显式建模应用拓扑。文献提出了基于 Xen 的云平台自动部署 框架。文献提出了 PM、VM 和应用等三个 层次的云应用部署的描述语言。
但以上方法难以 实现多云或混合云部署，将应用或部分应用自动化 迁移到不同的提供者非常困难。同时，API是由提 供者预先定义的，并且必须通过开发自定义的粘合 代码来手动包装，因此不适用于特定部署场景。
5.结语
当前互联网应用的用户需求快速变化，高效自动部署技术是缩短软件发布周期的关键。DevOps 技术有助于实现快速自动化部署过程，通过不断迭代交付微服务来缩短发布周期。本文面向 DevOps，提出了一种高效动态的应用部署引擎 OpsFlow 及其生成方法，设计并实现了技术框架以支持所提出方法，最后，实验结果表明，生成部署引擎具有较小的开销。
附件下载
OpsFlow：一种面向DevOps的应用自动化部署引擎.pdf