近年来，互联网公司的业务迅速扩大，用户需求经常发生变化，基于单个体系结构的传统软件系统很难适应互联网技术的快速开发。
因此，微观服务体系结构出现了，单个应用程序被分为许多较小且独特的服务。在他们的情况下，每项服务都是为特定业务逻辑封装和构建的，在生产环境中独立运营，并为服务环境提供了服务，并为此提供了服务。通过服务模块之间的合作，外部世界。
由于模块的强大自主权，Micro -Service架构可以满足快速的Internet应用程序和模块的独立更新的需求。操作和维护成本。如何响应微服务的快速和频繁更新和部署已成为需要在微服务应用中解决的主要问题之一。
为了实现注意点或任务的分离，微服务的开发测试，操作和维护过程严格区分，因此不同的项目团队具有不同的目标和流程。
开发人员的目的是快速改变生产环境，操作和维护人员的目标是保持生产环境的稳定性，这已成为快速发布软件的障碍。开发与运营之间的协作维护人员通常是通过手动进行的。这个过程效率低下且易于犯错。因此，它将改变应用程序，增加特征并修复生产环境的错误。
为了快速响应用户需求和微服务应用程序的持续变化，软件公司需要响应快速和频繁的微服务应用程序的发布，以填补开发和操作之间的差距。Devops是一种应对开发和开发和开发的新兴技术微服务的操作和维护，可以在两个开发，运营和维护的两个部门之间实现有效的合作。
Micro -Service应用程序示例不仅需要部署到开发环境以运行测试用例或检查更新代码，而且还需要连续部署并重新部署到生产环境中以提供服务。
由于应用程序经常会部署不同的环境，因此必须实现高效且自动化的应用程序部署。在同一时间，该应用程序需要从简单的开发环境无缝连接到复杂的分布式生产环境，并且需要便携式逻辑。。
DevOps社区提供了开源工具（例如Chef，Puppetsible），以支持部署过程自动化以实现连续的软件交付；在中间部分和应用层中，您可以获得重复使用组件（例如脚本，模板）以实现自动化；基础架构中的基础架构促进了云计算平台，为按需按需需求进行了基础物理资源的自动化部署提供了API。
因此，本文结合了各种级别的技术，服务和组件，以应对各种微服务应用程序的部署，以实现有效的微服务组件组合和自动化的微服务应用程序组件部署。
本文提出了高效率和动态应用程序部署引擎OPSFLOFE到DEVOPS。技术框架的设计和实现自动生成OPSFlow。最后，通过实验评估OPSFLOF的开销，并使用微服务应用程序来验证有效方法的有效方法的有效方法的有效方法的有效性方法的有效性方法的有效性方法。
应用程序部署引擎OPSFlow目标是将多种自动部署技术组合起来，以应对异质应用程序和部署环境，从而实现高效率和自动化微服务应用程序的部署。
OPSFlow作为一种自定义部署逻辑软件包，为用户或外部系统提供了API，以促进应用程序实例的部署。同时，它还提供了管理逻辑来扩展一些已部署的应用程序组件。它具有以下功能：
1）为特定的应用程序实例指定一种编程语言，以生成可移植的软件包，以便在不同环境中运行的应用程序实例，例如本地主机开发环境，本地服务器测试环境和远程云计算生产环境；
2）生成可执行组件（例如脚本，汇编程序）以实现“原子”部署操作。实现形式是软件包安装和配置的部署脚本，或通过调用云服务接口使用虚拟资源的代码。
3）安排多个部署可执行过程以形成云应用程序部署模板。部署执行过程负责执行部署计划，协调部署操作并创建特定的应用程序拓扑；
4）提供开放的API，以触发部署计划的应用程序拓扑的执行或创建。如图1所示，可以通过用户或外部系统调用API。
OPSFLOW系统体系结构根据应用程序拓扑动力学具有以下优点，以生成自定义的OPSFLOFENEM：
1）只有用于实施部署操作的可执行过程的部署具有较少的软件量表，资源消耗和配置操作以及高性能。
2）包装所需的可执行过程的部署是以自我持有的方式部署的，彼此彼此独立。由于它不依赖集中式中间件并避免单个故障点，因此具有更高的可靠性。
3）使用开源生态系统提供的可重复使用的组件（例如厨师和JUJU）自动生成部署计划，以实现部署执行计划的安排和执行。开发人员只需要调用所需的API，而不是手动开发粘合剂代码。
OPSFLOFE的动态生成方法如图2所示。它分为三个阶段：设计，构造和操作，并遵循使用不同技术实施通用规范的使用。
1）设计阶段：创建和维护应用拓扑模型；根据基础架构，中间件和应用程序组件选择可执行过程的部署。可以定制这些可执行过程或现有组件（例如厨师，Juju，Fog，Jclouds）；将所需的部署执行程序关联到应用程序拓扑。），因为每个开源社区都可以独立维护以维护存储库并提供有限的搜索功能，因此它缺乏全面的知识，并且很难选择合适的组件。本文通过集成知识来整合知识。库的元模型解决了问题。部署要求来自应用程序拓扑。您可以通过要求参考文件来表达部署可执行过程的要求以及与其他可执行过程部署相关联。
2）施工阶段：创建部署计划，即部署可执行过程，安排所有必要的部署执行程序以创建特定应用程序拓扑模型的示例。可以手动完成部署计划，也可以使用计划自动生成，该计划可以自动生成例如使用BPEL引擎自动生成应用程序部署的工作流程；创建部署计划时，所有必要的部署可执行过程都可以生成OPS?生成OPS?
流部署引擎。
3）操作阶段：生成自定义的OPSFlow引擎；提供API，根据建模的应用程序拓扑制定部署计划，并部署和管理应用程序实例；如果不需要部署和管理更多的应用程序示例，则OPSFLOF引擎将终止。
OPSFLOW部署引擎生成框架如图3所示，包括三个阶段：设计，构造和操作，特别包括以下组件。
应用程序拓扑模型的建模环境：建立和维护应用程序拓扑模型，并将所需的部署执行程序与这些拓扑模型中的组件和依赖关系相关联。
部署计划生成器：动态自动生成部署计划，该计划可以处理应用程序拓扑模型的创建。为了将建模环境与计划者分开，本文使用标准建模方法（例如Tosca [10]）。为了实现自定义目标，需要部署计划，需要相应的部署计划开发环境。在本文中，Eclipse BPEL设计师被用作BPEL工作流环境。
API生成器：生成部署可执行过程的技术细节，隐藏和抽象的实现，在API上创建部署计划，并实现包装部署执行程序而无需修改源代码。例如，如何调用可执行文件，如何通过输入参数以及如何收集输出数据。如果部署可执行过程涉及多个特定应用程序，请手动执行可执行文件以实现一个应用程序以实现API时间，那么有必要自动化API。需要修改自动化技术，以部署异质应用程序，手动修改和完善部署计划。特别是，当使用工作流模型（例如BPEL）时，集成的各种技术非常复杂且易于犯错。因此，技术特征及其调用机制是在API中包装的，标准化的通信协议（例如HTTP）可用于呼叫到Callessencethe部署计划生成器，不需要了解各种技术的呼叫机制的详细信息，但只需要需要了解如何致电API支持自动生成部署计划。
部署引擎包装：生成自固定的OPSFlow引擎，作为可移植的可执行软件包，运行时内部署应用程序实例。可以根据基于API的框架来实现API生成器和OPSFLOWEN引擎，例如Any2API [11]。根据OPSFLOW引擎的包装格式，API用于部署和管理应用程序示例。在同一时间，通过使用移植虚拟化方法，它可用于在不同环境中包装和执行OPSFLOW引擎。
本文实现了基于TOSCA的原型系统，该系统用于应对可移植性和可伸缩性，涵盖了三个阶段：设计，构造和操作。在设计阶段，建模工具提供了基于TOSCA的模型的可扩展建模环境，以改善改进的模型。另外，请使用酿酒厂[12]实现应用程序拓扑建模来管理不同类型的组件和依赖项。
在施工阶段，本文使用Opentosca作为部署计划生成器来生成具有动态应用程序拓扑模型的部署计划，以满足应用程序拓扑的特定部署需求。部署计划生成器可以自动生成部署计划，而无需手动完善。
在操作阶段，工作流建模语言生成的部署计划（例如BPMN或BPEL）需要在构造过程中生成相应的API，以公开部署执行程序的功能。ITEM.ITEM.ITEM.ITEM.ITEM.ITEM.本文章使用Any2API框架生成这些API。例如，部署可执行程序将基于SOAP/WSDL生成Web服务API，以支持BPEL中实施的部署计划，从而调用和处理基础可执行程序。
此外，当使用脚本语言（例如Python或Ruby）与相关库（REST-CLIENT）连接以实现部署计划时，生成了RESTFUL WEB API。由于生成的部署计划也通过调用API执行，基于API的递归聚合可以支持许多不同的拓扑模型。
最后，Docker容器使用Dockerfile包装OPSFLOFE引擎作为移植虚拟化技术，并使用Any2API同时执行包装操作。
本文以典型的在线商店应用程序为示例来分析应用程序部署所面临的问题。图4描述了在线商店的应用程序体系结构。它采用了混合云部署方法。它被部署在左侧，以形成AMA?ZON EC2的应用程序，并在右侧的右侧数据库组成，以避免将敏感数据暴露于公共云服务提供商.php应用程序。PHP应用程序已在Apache Server中部署，以显示用户界面和用户界面和执行业务逻辑。该数据库使用MySQL Master/从模式使用，以改善应用程序的应用和高可用性。
该应用程序由不同的组件组成，并采用了不同的部署技术。在它们之后，Web应用程序使用Unix Shell脚本部署，PHP模块和Apache Server使用厨师部署，MySQL数据库使用JUJU部署。部署用于基础架构层（包括虚拟机和网络配置），以通过API与云计算平台（Amazon，OpenStack）进行交互。
应用程序部署涉及各种类型的部署脚本和组件，需要考虑许多技术细节和差异。除了特定应用程序的外壳脚本外，厨师和JUJU都需要特定的部署引擎支持。
此外，应用程序拓扑以多种方式部署，即亚马逊被用作公共云服务提供商，OpenStack是一个私人云管理平台。一般自动化部署框架（例如Opentosca，Terraform，Brooklyn，Brooklyn，Brooklyn，）通过引入统一的元模型以进行抽象以实现不同部署程序的布置，以便使用不同的方法使用相应的元模型。但是，开发无法自动实现。
同时，由于通用部署引擎需要支持各种部署方法，因此通常是一个重量级模块，并且维护复杂性很高。
该实验使用三个公共厨师食谱来部署Apache服务器，PHP运行时环境和MySQL数据库，以在Amazon EC2 Cloud Infrastructure上实现两个Ruby脚本，并使用Amazon Relative数据库服务（RDS）来部署MySQL数据库实例。
实验系统部署在虚拟机（4 2.8 GHz的主要频率为64 -bit虚拟CPU，4 GB内存）中，并使用虚拟盒HyperViso完成Debian Linux容器中可执行程序的处理和调用的处理和调用。
监视本文中容器层的所有测量，请注意部署执行程序和API实现相关的测量，并对每个部署执行20个可执行程序（包括10次，10次无API实施）。在每个组中，都是初始执行（在干净的部署环境中运行，而无需任何操作），而其他5则遵循-up。
生成API实现的平均时间是施工阶段的开销，即8s?33s，其中包括检索到的特定部署可执行过程的依赖项。要简化生成的API，在生成的API的简化中，执行时间和较小的内存开销较小运行。
此外，当直接使用简单的部署可执行程序时，安排组件将降低生成API实现的复杂性。因此，资源的总体消耗取决于所选的分布方法。同时，可以将API重复使用以在不同的远程环境中运行可执行程序，以减少大型操作环境的开销。
本文从设计，构造和操作的三个阶段进行评估。实验结果如下：
1）设计阶段：生成API所需的时间，实验结果如图5所示；
2）施工阶段：部署可执行程序所需的时间，实验结果如图6所示；
3）操作阶段：执行程序所需的内存。实验结果如图7所示。
与传统的通用部署引擎不同，OPSFlow不依赖于运行时的集中中间件。，有几个缺点：
1）通用部署引擎提供的API不适合所有部署方案。它需要实现各种部署技术并具有很高的复杂性，因此很难维护和扩展。
2）通用部署引擎通常使用集中式中间件，并且存在一个单点丢失的问题，因此需要保持其可靠性。
3）使用部门总部门总部通常需要现场知识，并通过二级开发将现有的API打包，以实现多应用组件部署的安排。
4）通用部署引擎并非专门用于给定的应用程序拓扑，因此运营费用很高。
Bootware首先创建了部署引擎，然后使用其部署应用程序实例。该方法使用通用部署引擎，OPSFlow是针对特定应用程序的部署引擎。纸张将不同类型的部署可执行过程转换为基于TOSCA的组件，这对于重复使用由现有多元化多元化开源开源生态系统提供的内容而言很方便。尽管此方法可以有效地实现设计阶段和施工阶段的部署，但在操作阶段，需要将通用部署引擎部署和管理应用程序拓扑。
云提供商提供建模和布置工具，同时提供PAAS（平台为服务）服务。调用服务可以部署和管理应用程序实例，而无需显式建模应用程序拓扑。该文献提出了基于XEN平台的自动部署框架。文献提出了PM，VM和应用程序的云应用程序部署的描述语言。
但是，上述方法很难实现多云或混合云部署，并且很难自动化应用程序或部分应用程序到不同的提供商。在同一时间，API由提供商预定，必须由提供者手动打包，并且必须由开发自定义的键合代码，因此不适合特定的部署方案。
当前的Internet应用程序用户需要迅速变化，并且高效，自动部署技术是缩短软件发布周期的关键。Devops技术有助于实现快速自动化部署的过程，并通过不断迭代Microservices的交付来缩短发布周期。DevOps，本文提出了高效率和动态应用程序部署引擎OPSFlow及其生成方法，设计和实施了技术框架以支持所提出的方法。最后，实验结果表明，生产部署引擎的费用较少。
OPSFlow：DevOps.pdf的一种自动部署引擎