CN108062231A - 一种基于相关分析的云应用自动化配置方法 - Google Patents

Abstract

发明涉及一种基于相关分析的云应用自动化配置方法。提出了一个基于服务的应用拓扑描述模型，采用声明式的方法刻画云应用的部署拓扑结构，涵盖运维部署、扩展、运行时服务状态检测等信息，并基于服务和配置模板的方式描述组件参数关联关系，构建出配置更改事件级联传播的有向图，通过服务注册发现机制实现组件间强依赖关系的解耦，维持应用关联参数间的一致性，提出基于分布式事务的系统可用性保障机制，通过事务确保系统在更新配置后整个应用的可用性，提高系统运行时更新配置的可靠性。

Description

一种基于相关分析的云应用自动化配置方法

技术领域

本发明涉及一种基于相关分析的云应用自动化配置方法，属于软件技术领域。

背景技术

云计算以虚拟化技术为基础，以网络为载体提供基础设施、平台、软件等服务。云计算采取即付即用的模式管理，具有按需供给和弹性伸缩等特性，使其成为广泛使用的计算模式。同时，减少产品发布时间与减少应用发布错误已成为公司项目成功与否的两大指标。在企业级应用向云端迁移背景与企业应用自动化管理趋势下，云计算平台应用自动化的维护管理自然成为了公司的需求，而运维自动化技术和工具的引入也促使IT企业在应用从产品到服务的发布周期越来越短，次数越来越多。另一方面，配置错误已成为导致系统故障的第二大因素。因此，云计算平台下迫切地需要一套自动化的方法来有效地管理云应用，应对频繁的部署与运行时再配置需求，减少产品上线时间，降低运行时再配置过程中的出错率。

在基础设施和运行环境方面，随着以Docker为首的容器虚拟化技术的发展，云计算平台虚拟化技术更加多样化。目前主流的云平台如Amazon、Google等纷纷引入Docker虚拟化技术。容器虚拟化与传统基于Hypervisor的系统虚拟化相比，拥有更高的资源利用率、更快捷的部署效率，加快应用在开发环境与测试环境中的部署效率，极大地减少开发与测试间信息沟通缺乏引起的人工配置错误。但是容器虚拟化技术有其局限性，如采用容器虚拟化的公有云平台无法支持系统内核的修改，可是传统的DB2数据库、MySQL数据库或Oracle数据库等均需要调整操作系统内核以达到最优化的性能。为更高的资源利用率与系统性能，企业将选择混合虚拟化的公有云作为企业应用的运行支撑平台。同时由于安全和控制原因，企业应用并不能完全部署于公有云平台。越来越多公司的IT基础设施开始引入混合云模式。因此如何有效快速地在多样化的部署环境下转换部署策略，实现快速部署也是云计算平台下应用自动化管理的一大需求。

综上所述，对于企业应用的云化管理，提出一套有效地减少配置错误的自动化方法以及开发一个支持云计算平台异构环境下应用自动化部署与运行时配置管理的服务具有十分重要的研究价值与现实意义。随着云计算的不断发展，大量的企业应用将部署于云平台。发明将这种以云计算平台作为运行支撑平台的应用称为云应用。云应用系统结构复杂、系统参数众多等特性以及运行时的再配置需求，给云计算平台的自动化运维管理带来了一系列挑战，具体如下：云应用系统参数众多，版本迭代使其复杂度和规模不断扩大，使得人工部署和管理方式无法满足需求，迫切需要高效、自动化的部署服务。应用通常由异构组件组成，系统配置参数间存在相关性，使得配置错误成为导致系统故障的主要原因之一。云应用的运行时动态配置和服务失效往往导致系统不一致问题，引起系统异常。部署操作顺序和服务状态等因素对应用是否能够正确部署配置产生重要了影响。

配置管理工具已成为实现自动化部署运维的主要手段，CMT采用领域描述语言编写脚本程序，用于简化应用的管理与部署，自动化管理应用的配置，在目标机器上安装新的软件或服务。但是仍存在学习成本高与无法描述应用系统整体部署方案和高层抽象视图等不足。CMT只关注应用单个组件的部署配置，缺乏机制维护同一应用多组件间参数的关联。同时单一应用的脚本分散，管理困难，难以维护。单个配置参数的更改可能涉及多个脚本，人工更改容易出错，并且它们只能维护单个主机的状态，无法满足频繁的部署与运行时更新的需求，难以实现组件的弹性伸缩和解决服务失效问题。

发明内容

本发明的目的：通过配置模板描述组件配置的依赖关系，减少配置参数关系导致的不一致。同时隔离应用的高层抽象与底层的实现细节，可在混合云环境下转换部署策略，提高部署的效率。

本发明的原理：提出了一个基于服务的应用拓扑描述模型，采用声明式的方法刻画云应用的部署拓扑结构，涵盖运维部署、扩展、运行时服务状态检测等信息，并基于服务和配置模板的方式描述组件参数关联关系，构建出配置更改事件级联传播的有向图，通过服务注册发现机制实现组件间强依赖关系的解耦，维持应用关联参数间的一致性，提出基于分布式事务的系统可用性保障机制，通过事务确保系统在更新配置后整个应用的可用性，提高系统运行时更新配置的可靠性。

本发明技术解决方案：一种基于相关分析的云应用自动化配置方法，其特点在于实现步骤如下：

（1）建立基于服务的应用拓扑描述模型

为解决云环境下应用部署与配置存在的问题：1）异构性，混合云场景下多样的部署环境与方法；2）高学习成本；3）配置正确性，确保应用在部署和配置过程中配置的正确性。发明提出一个应用拓扑描述模型，即STM（Service-based Topology Model），该模型：1）定义应用的拓扑结构，实现应用部署的高层抽象视图，从而屏蔽底层细节以应对异构性问题；2）提倡角色划分，高级运维人员负责底层脚本具体实现，普通运维人员负责上层模型的构建，提供脚本封装，降低学习成本；3）将组件参数中被其他组件依赖的部分抽离，定义为服务信息。使用配置模板与服务信息描述组件间的关联关系，分离组件的安装与配置，便于自动化维护应用的配置参数，确保应用配置的正确性。同时提供服务状态的定义，用于检测服务的可用性，当组件发生故障时，可将服务状态标记为不可用，以应对应用状态变化引起的配置不一致问题。

1)描述组件的拓扑结构。使用应用的高层抽象，隔离具体平台实现细节，实现与配置管理工具（Configuration Management Tool，CMT）的集成，支持声明式模型与系统初始部署与维护管理协作脚本间的自动转换，解耦组件间部署行为的依赖。

2)描述组件的服务信息、服务状态的检测命令。用于验证部署的正确性，分离应用部署的启动命令的成功执行与组件服务可用间的逻辑关联，启动命令执行成功并不代表该服务是可用的，解决因二者之间存在的时间差导致的应用部署失败问题。同时可用于实时检测应用层面的服务失效，应对应用的状态变化。

3)描述组件间的参数依赖关系。通过配置模板中的配置参数与组件的服务信息构建整个应用的关系依赖图。从而可通过组件服务信息的注册与注销检测应用组件增减，组件的服务状态检测组件的服务失效，配置参数的注册与注销检测应用组件配置参数的更改，从而应对应用的三种变化引起的配置不一致问题。

（2）定义基于发布订阅的关联配置角色

基于STM模型，本节提出了支持云应用初始部署和运行时动态配置的关联一致性保障机制。该机制主要包含三部分：1）事件的传播：该机制基于模型中定义的配置模板，订阅其他组件的服务以及属性参数的更改事件，构建应用变化事件传播的有向图，从而传播应用系统中的变化信息；2）事件的处理：通过应用变化事件的监听，实现应用组件间参数取值的自动调整。基于事件动态更新配置，从而维护配置参数的一致性；3）事件的产生：被依赖的应用组件接收到应用三类变化请求后，将自身的变化事件转发给其他组件。该机制解耦了部署与配置流程，应用组件基于自治和协调的方式，完成自身的初始配置，解决应用部署和运行时的参数配置或运行时故障服务失效引起的不一致问题。

（3）基于结构变化事件的交互流程

运维人员改变应用结构（如组件增减）时，参数一致性维护机制如何自动协调完成参数的自配置的过程。各个角色间的交互流程如下：

1)运维人员发起更改应用结构请求，Manager向Register Center发布对应NodeEvent事件。

2)Executor中的Event Executor接收Register Center中的NodeEvent事件，拉取NodeEvent事件描述的数据，将数据提交给Service Manager。

3)Executor中的Service Manager基于Event中的数据安装或卸载应用服务，然后发送服务增减请求至Register，同时将该服务的配置模板信息与check信息分别提交至Configurator与Health Checker。

4)Register向Register Center发送服务注册/注销请求，注册/注销特定的服务。

5)Health Checker基于check信息定时检测应用服务状态，不断将应用状态转发给Register Center，修改已有Service的状态。

6)Configurator向Register Center订阅应用服务的依赖的配置，当RegisterCenter接收到被依赖的配置信息时，通知Configurator，由Configurator从RegisterCenter中获取应用服务依赖的其他组件的Service和Attribtues信息，基于配置模板生成新的配置文件，更新服务的配置，触发应用重新载入配置。

（4）基于参数变化事件的交互流程

参数变化主要指组件间关联配置参数的取值变化，该机制通过参数更改事件的发布与订阅应对参数变化，维持关联参数的一致性的过程。其中各角色的交互流程如下：

1)Agent2向RegisterCenter订阅Agent1中某组件的Attribute更改事件。

2)运维人员运行时发起配置更改请求，Manager向RegisterCenter发布ConfigEvent

3)RegisterCenter通知Agent1处理该ConfigEvent，同时Agent1分析ConfigEvent中的数据。

4)Agent1更改组件配置，触发应用重新载入配置，载入成功后，将ConfigEvent转发给Register。

5)Register将新的配置参数提交至RegisterCenter，Register Center基于订阅信息，通知Agent2。

6)Agent2的EventExecutor接收其依赖的配置被修改的事件，转发至Configurator

7)Configurator载入配置模板，从RegisterCenter获取最新参数值，重新构建配置文件，触发应用载入配置。

（5）基于服务状态变化事件的交互流程

服务的启动、停止以及服务的失效均会引起服务状态的变化，服务的状态变化后，与服务对应的Attribute参数将生效或失效。如何自动地应对参数的生效或失效，从而避免参数的不一致，也是该机制需要解决的。

故障检测：应用组件初始化时，Executor会将组件Service的check信息提交给HealthChecker，HealthChecker以一定的频率将组件的状态信息发送至RegisterCenter，当时间延迟超过一定阈值时或者HealthChecker检测出服务不可用，RegisterCenter将该组件服务的状态更改为不可用，服务处于失效状态，其他依赖该组件的Agent均会感知这一信息，启动Configurator，更新并修复配置。

故障修复：以服务失效为例描述了服务状态变化时各个角色将的交互流程：

1)Agent2向RegisterCenter订阅Agent1上某一组件的状态变化事件。

2)Agent1的HealthChecker向RegisterCenter报告组件服务不可用，Register Center将系统中该服务的状态更改为不可用，同时产生一个StateEvent事件。

3)Register Center通知Manager与Agent2，Agent2获取该StateEvent事件的数据并转发给Configurator。

4)Configurator从RegisterCenter中拉取所有处于生效状态的Service与Attribute，重新载入配置。

应用运行过程中的结构变化、参数变化、服务状态变化并不是相互独立的，一个运维操作中可能同时包含多种变化，如停止服务操作即包含一个结构变化事件也包含一个服务状态变化事件，同时有可能因为组件间级联的关联关系而触发产生一系列的参数变化事件。针对这三类事件，基于发布订阅的关联配置参数一致性维护机制均能自动化的维持系统关联参数的一致性。

本发明与现有技术相比具有如下优点：

（1）描述应用组件拓扑结构，实现应用部署视图的高层抽象，隔离底层的实现细节，支持多样化部署环境下运维脚本的自动转换，支持脚本的重用，提高部署的效率。

（2）描述组件配置依赖关系，减少配置参数关联导致的配置不一致错误。

（3）划分角色，区分开发人员与运维人员，分工合作，消除运维人员与开发人员间沟通不足引起的配置参数设置错误。

附图说明

图1为云应用自动化配置系统架构。

具体实施方式

以下结合具体实施例和附图对本发明进行详细说明，如图1所示， 本发明实施例方法流程：

系统架构中的各个节点功能，分别如下：

（1）控制节点

控制节点提供用户与系统交互的接口，管理用户的应用。控制节点提供三大管理功能：模型管理、配置管理、服务管理。模型管理负责应用STM模型编排、已有STM模型的管理以及通过STM模型与底层CMT工具或Docker间的执行代码转换进行目标应用的生命周期管理。配置管理负责管理已部署应用的参数以及关联参数，给用户提供运行时更改已部署应用配置的接口；同时还负责管理应用的配置模板，支持用户配置模板的上传与更新。服务管理负责实时的展示已部署应用组件的服务状态以及服务地址，访问地址信息等。

n 模型管理：模型管理可以分为三个模块：可视化建模、应用编排模块、模型转换模块。其中可视化建模模块基于JsPlumb提供网页上模型编排图的构建功能，应用编排模块基于可视化建模模块生成的编排图生成STM模型，而模型转换模块则基于STM模型，自动为应用生成运维任务以及各个组件的安装包，同时将运维任务转交给消息管理。

n 配置管理：配置管理给提供一个配置管理的交互接口，管理已部署应用的参数以及参数关联信息，并将用户的配置更改操作转交给控制消息模块。

n 消息管理：消息管理主要包含控制消息模块，负责控制节点与消息节点间的交互，将控制节点产生的所有控制消息转发至消息节点，同时也负责从消息节点中获取与控制节点相关的消息，比如代理节点发回的反馈信息。

（2） 消息节点

消息节点负责控制节点与代理节点以及代理节点之间的消息通信，将控制节点的控制消息转发至特定的代理节点，控制代理节点上应用安装卸载等。同时消息节点还负责代理节点上组件关联参数更改消息的发布与订阅，将某一代理节点上的关联参数更改消息推送至所有消息订阅者，实现基于发布订阅的关联配置参数一致性维护机制中关联参数的发布订阅功能。

n 配置参数更改消息的发布与订阅机制

消息的发布与订阅机制主要依赖于Consul的K/V存储功能，消息的发布时自动为消息产生一个全局的MessageKey，将消息内容以Value的方式存入Consul中。消息的订阅机制则以MessageKey为前缀，加上listeners即/MessageKey/listeners作为订阅者注册的SubKey，当一个订阅者发起消息订阅时，即将自身的信息如IP，端口等增加至SubKey对应的Value中。由配置更改消息的发起者通知所有订阅者消息的到达。MessageKey不仅要确保全局的唯一性，还要保证计算过程的效率，其中NodeEvent与ConfigEvent的产生规则略有不同，NodeEvent的产生规则为：/用户ID/应用ID/实例ID，而ConfigEvent的产生规则为：/用户ID/应用ID/实例ID/属性ID/。

n 控制消息的转发

发明主要采取拉的方式实现，消息节点并不负责向订阅者推送消息，由订阅者定时轮询消息节点，查看是否有新的消息。为提高效率，消息节点加入阻塞机制，当订阅者发起消息查询而此时并无新消息到达时，消息节点阻塞该请求一段时间，若时间段内仍然无消息到达，消息节点则释放该请求，反之则返回新消息。

（3） 代理节点

代理节点负责管理目标主机上的应用，依靠基于发布订阅的关联参数一致性维护机制管理主机上应用的配置模板以及配置文件。并能通过消息节点的发布订阅机制与其他代理节点建立分布式事务，实现本地配置数据的事务性更改，确保关联参数的一致性，维护系统可用性。

n Event Manager：EventManager模块负责监听消息节点的消息，消息节点主要转发两种消息：Node Event与Configuration Event。因此EventManager模块可以细分为NodeEvent Watcher与 ConfigurationEvent Watcher，分别监听相应的事件，并将事件提交给Executor，Executor根据消息类型，调用App Manager或Dynamic Manager中的相应模块。

n App Manager：App Manager负责管理目标主机上的应用或容器，以及应用的安装包、服务信息、STM模型描述等。

（4） 服务节点

服务节点负责存储整个系统中所有已部署应用组件的服务以及Attributes信息。并定时接收代理节点上的应用状态报告，维护组件服务的状态。针对失效的节点或服务，将失效消息发送至消息节点，由消息节点通知所有依赖该服务的组件，触发代理节点自动更新配置。

（5） 数据节点

数据节点负责存储整个系统中的数据，包括文件、yum源、Docker镜像、STM模型转换生成的应用组件安装包等，在控制节点与代理节点间传输数据。

Claims (1)

1.一种基于相关分析的云应用自动化配置方法，方法特征在于实现步骤如下：

（1）建立基于服务的应用拓扑描述模型： 1）定义应用的拓扑结构，实现应用部署的高层抽象视图，从而屏蔽底层细节以应对异构性问题；2）提倡角色划分，高级运维人员负责底层脚本具体实现，普通运维人员负责上层模型的构建，提供脚本封装，降低学习成本；3）将组件参数中被其他组件依赖的部分抽离，定义为服务信息；

（2）定义基于发布订阅的关联配置角色： 1）事件传播机制基于模型中定义的配置模板，订阅其他组件的服务以及属性参数的更改事件，构建应用变化事件传播的有向图，从而传播应用系统中的变化信息；2）事件处理通过应用变化事件的监听，实现应用组件间参数取值的自动调整；3）事件产生，被依赖的应用组件接收到应用三类变化请求后，将自身的变化事件转发给其他组件；

（3）基于结构变化事件的交互流程：运维人员改变应用结构（如组件增减）时，参数一致性维护机制如何自动协调完成参数的自配置的过程，包括：1）基于参数变化事件的交互流程，组件间关联配置参数的取值变化，该机制通过参数更改事件的发布与订阅应对参数变化，维持关联参数的一致性的过程；2）基于服务状态变化事件的交互流程，服务的启动、停止以及服务的失效均会引起服务状态的变化，服务的状态变化后，与服务对应的Attribute参数将生效或失效；3）基于服务状态变化事件的交互流程，服务的启动、停止以及服务的失效均会引起服务状态的变化，服务的状态变化后，与服务对应的Attribute参数将生效或失效。