CN116225464A - 一种平台的快速部署方法 - Google Patents

Abstract

本发明公开了一种平台的快速部署方法，包括以下步骤：（a）将平台拆分成相对独立且有具体功能的多个组件，对每个所述组件进行封装，使封装后的所述组件通过统一的访问接口进行信息传输；（b）检测多个所述组件之间的依赖关系，建立依赖库并将其存储在中央仓库中，使用统一的标识符和版本号对所述依赖库进行管理；随后通过声明和引用所述依赖库以自动下载和安装所需的依赖项；（c）围绕所述组件的接口设计、组件参数化设计和组件的功能设计三方面对所述组件进行结构和内部参数的配置，以接口标准为纽带将多个所述组件组织起来即可。解决人工干预过程中可能引入的各种人为错误（比如错误配置）带来的系统无法使用问题，可以减少平台的部署时间。

Description

一种平台的快速部署方法

技术领域

本发明属于软件部署技术领域，涉及一种平台的部署方法，尤其是一种平台的快速部署方法。

背景技术

平台（主要包含云平台、大数据框架、智能框架、数据库等等）的开设实际上就是平台的部署，即将平台部署到物理机集群上去以作为业务系统的公用基础底层。

现有的平台部署方法主要是人工使用一系列部署工具（有部署云的，有部署大数据组件的）进行，比如Hue、Rancher、Sahara等等。Hue是一个可快速开发和调试Hadoop生态系统中各种应用的、基于浏览器的图形化用户接口，其本质上是一组WEB应用，用于和MRS大数据组件进行交互，能够帮助用户浏览HDFS，进行Hive查询，启动MapReduce编程模型等；它承载了与所有MRS大数据组件交互的应用。Hue当前部署过程仍十分繁琐，需要编写大量的配置文件，当出现组件部署故障的情况后，需要专业人员进行问题排查，当前无法支持大规模的组件快速部署。Sahara旨在为用户提供简单部署 Hadoop 集群的能力，主要包括集群和任务管理两大类功能。目前Sahara还不支持Hadoop集群配置更新和服务管理，没有Trove的配置概念，这意味着Hadoop的配置只能在创建的时候设置，创建完后就不能更新了，也不支持启动/停止/重启服务。Rancher是一套容器管理平台，它可以帮助组织在生产环境中轻松快捷的部署和管理容器；Rancher可以轻松地管理各种环境的容器，满足IT需求并为DevOps团队提供支持；但Rancher当前仍存在一系列问题：主要包括环境信息的残留、操作系统版本不适配、配置文件复杂、非工作节点仍然被部署等问题。

可见，当前的平台部署软件基本上只能较快地部署网络和存储等基础的应用，而对于云、大数据、智能框架、数据库等部署平台的配置则十分复杂，容易出错；同时平台的各类组件部署都互相独立，没有实现组件之间的协同，容易造成组件部署之间的冲突，难以根据实际需求进行灵活部署。

发明内容

基于上述缺陷，本发明提供一种平台的快速部署方法，以减少平台软件的部署时间，降低时间成本，并减少软件平台部署的复杂度。

为了达成上述目的，本发明提供一种平台的快速部署方法，包括以下步骤：

（a）将平台拆分成相对独立且有具体功能的多个组件，对每个所述组件进行封装，使封装后的所述组件通过统一的访问接口进行信息传输；

（b）检测多个所述组件之间的依赖关系，建立依赖库并将其存储在中央仓库中，使用统一的标识符和版本号对所述依赖库进行管理；随后通过声明和引用所述依赖库以自动下载和安装所需的依赖项；

（c）围绕所述组件的接口设计、组件参数化设计和组件的功能设计三方面对所述组件进行结构和内部参数的配置，以接口标准为纽带将多个所述组件组织起来即可。

优化地，步骤（a）中，所述平台至少包括云组件、数据库组件、智能框架组件和大数据组件。

优化地，步骤（b）中，通过依赖关系求解算法检测多个所述组件之间的依赖关系，所述依赖关系求解算法包括组件依赖树的第一子算法、对资源规格函数进行运算的第二子算法和生成组件依赖列表的第三子算法。

进一步地，步骤（b）中，所述第一子算法包括以下步骤：

S11、判断所述组件自身状态是否有效：当组件自身状态无效时，当前组件不可用；当组件自身状态有效时，执行步骤S12；

S12、判断所述组件是否依赖其他组件：当依赖其他组件时，则当前组件可用，执行步骤S15；当不依赖其他组件时，执行步骤S13；

S13、判断资源规格函数中各组件的可用性，并对资源规格函数进行运算；

S14、判断依赖组件的布尔运算结果：当依赖组件的布尔运算为假，则当前组件不可用；当依赖组件的布尔运算为真，则当前组件可用，执行步骤S15；

S15、将当前组件加入组件依赖树。

更进一步地，步骤（b）中，所述第二子算法包括以下步骤：

S21、将所述资源规格函数转为后缀表达式，将后缀表达式元素存入运算元素栈，后缀表达式的运算符存入运算符栈；

S22、判断运算元素栈的元素数量是否大于1：当运算元素栈的元素数量不大于1时，直接返回运算元素栈的唯一元素的可用性；当运算元素栈的元素数量大于1时，进入步骤S23；

S23、运算元素栈弹出栈顶的两个元素：元素A和元素B；

S24、判断元素A和元素B的可用性；

S25、运算符栈弹出运算符a；

S26、以元素A和元素B的可用性作为运算的前项和后项进行运算符a所表示的运算，产生元素C；

S27、将元素C压入运算元素栈，执行步骤S22。

更进一步地，步骤（b）中，所述第三子算法包括以下步骤：

S31、创建组件遍历栈；所述组件遍历栈是存放还未被遍历的组件的一种栈，初始条件下为空；

S32、将组件压入组件遍历栈；

S33、判断组件遍历栈是否为空：当组件遍历栈为空，组件遍历完毕，返回组件依赖列表；当组件遍历栈不为空，继续执行S34；

S34、从组件遍历栈中弹出一种组件，组件A；

S35、将组件A加入组件依赖列表；

S36、确定组件依赖树上是否存在子节点：当组件依赖树上不存在子节点，则当前组件为组件依赖树上的叶子节点，执行步骤S33；当组件依赖树上存在子节点，将组件的所有子节点压入组件遍历栈。

优化地，步骤（c）中，将各项组件配置关联起来，抽取元配置和衍生配置，做好配置的统一规划，所述配置包括地址、端口和节点数。

本发明平台的快速部署方法，将平台整体进行拆分和统一封装，每个组件都是相对独立的单元，都可以完成一个具体的功能。每个组件都可以独立部署，互不影响，而且可以自动检测依赖关系、升级库版本等，解决人工干预过程中可能引入的各种人为错误（比如错误配置）带来的系统无法使用问题，可以减少软件的部署时间，降低时间成本。

附图说明

图1为本发明平台的组件结构图；

图2为本发明依赖关系求解算法中第一子算法的流程图；

图3为本发明依赖关系求解算法中第二子算法的流程图；

图4为本发明依赖关系求解算法中第三子算法的流程图；

图5为本发明平台的部署策略图；

图6为本发明组件部署过程模型图。

具体实施方式

为了使本技术领域的人员更好地理解本发明，下面将结合实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所做的等效变化与修饰前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

本发明平台的快速部署方法，包括以下步骤：

（a）将平台拆分成相对独立且有具体功能的多个组件，对每个所述组件进行封装，使封装后的所述组件通过统一的访问接口进行信息传输。

快速开设平台将软件整体进行拆分和统一封装，每个组件都是相对独立的单元，都可以完成一个具体的功能。每个组件都可以独立部署，互不影响，以实现快速开设平台更好的可扩展性和强大的容灾能力。封装后的组件通过统一的访问接口进行信息传输，实现组件解耦。每个组件都可以实现内部异构，内部的实现不影响外部的组件部署和运行。快速开设平台部署的组件封装后可以实现灵活扩展，通过开放的访问接口进行整体软件的便捷升级，同时各项组件实现弹性伸缩的功能，各个组件封装好后，可以根据实际的需求对所需的组件进行灵活扩容，实现资源利用效率最大化。

本发明还可以建立软件资源的三维数据模型。按照软件资源的复用粒度与抽象层次，将软件资源划分为大、中、小三种不同的粒度。依据软件资源的粒度，从软件资源的分类信息（分类模型）、资源对象信息（对象模型）和属性信息（属性信息模型）三个方面，建立软件资源的三维数据模型，对软件资源进行统一的分类。依据三维数据模型，将软件资源组件化封装划分为大、中、小三种不同分类。本发明的软件组件封装结构如图1所示（该平台软件至少包括云组件、数据库组件、智能框架组件、大数据组件和其它组件等）。分类模型将软件资源按本身特性分类，明确各种软件资源的所属范围；对象模型描述软件资源按照复用粒度和抽象层次所得到的资源粒度，不同的粒度级别构成不一样的资源对象信息；属性信息模型按属性特征分类描述各类资源的自有属性信息。三个部分共同构成软件资源的三维数据模型，完成对软件资源的分类、对象化和定义，同时为以后软件资源的模板分类、建立和封装打下基础。

（b）检测多个所述组件之间的依赖关系，建立依赖库并将其存储在中央仓库中，使用统一的标识符和版本号对所述依赖库进行管理；随后通过声明和引用所述依赖库以自动下载和安装所需的依赖项。

不同的组件进行组装整合成完整的软件整体，某个组件顺利运行依赖其它组件从而产生了组件依赖。组件依赖是指和组件相关的各种依赖关系，表现为对象之间的约束，若约束无法满足，组件部署将会受到影响。组件依赖具有传播性，能够引起链漪效应，一个结点将直接或间接地依赖多个结点。根据软件依赖冲突的性质，可以将其分为三大类：强依赖、弱依赖以及负依赖。强依赖是软件部署的必要条件，如果没有满足强依赖的条件，则部署无法进行下去。弱依赖是指软件部分组件指定的条件，如果当前依赖不存在，软件可以正常使用，但是相关组件服务无法使用。负依赖是指禁止部署的冲突，当前目标机器中已经存在的软件同部署软件冲突，二者即为不可兼容，互为负依赖。

通过依赖关系求解算法检测多个所述组件之间的依赖关系，所述依赖关系求解算法包括组件依赖树的第一子算法、对资源规格函数进行运算的第二子算法和生成组件依赖列表的第三子算法。即本发明提出依赖管理算法，依赖关系求解算法是根据通过组件的资源规格函数运算求出所有满足规格资源规格函数的组件的列表。依赖关系求解算法分为三个子算法：第一子算法用于搜索 给定组件的子依赖，将满足资源规格函数的子依赖构建为组件依赖树；第二子算法是对资源规格函数进行运算；第三子算法用于生成组件依赖树后，遍历组件依赖树，生成组件依赖列表。

第一子算法是查找组件的所有子依赖，并根据组件自身状态以及资源规格函数是否被满足以判断组件的可用性。当组件可用时，此算法构造组件依赖树，组件依赖树由组件所有满足资源规格函数的子依赖组成。第一子算法，如图2所示，包括以下步骤：

S11、判断所述组件自身状态是否有效：当组件自身状态无效时，当前组件不可用；当组件自身状态有效时，执行步骤S12；

S12、判断所述组件是否依赖其他组件：当依赖其他组件时，则当前组件可用，执行步骤S15；当不依赖其他组件时，执行步骤S13；

S13、判断资源规格函数中各组件的可用性，并对资源规格函数进行运算；

S14、判断依赖组件的布尔运算结果：当依赖组件的布尔运算为假，则当前组件不可用；当依赖组件的布尔运算为真，则当前组件可用，执行步骤S15；

S15、将当前组件加入组件依赖树。

第二子算法对资源规格函数进行运算，如图3所示，包括以下步骤：

S21、将所述资源规格函数转为后缀表达式，将后缀表达式元素存入运算元素栈，后缀表达式的运算符存入运算符栈；

S22、判断运算元素栈的元素数量是否大于1：当运算元素栈的元素数量不大于1时，直接返回运算元素栈的唯一元素的可用性；当运算元素栈的元素数量大于1时，进入步骤S23；

S23、运算元素栈弹出栈顶的两个元素：元素A和元素B；

S24、判断元素A和元素B的可用性；

S25、运算符栈弹出运算符a；

S26、以元素A和元素B的可用性作为运算的前项和后项进行运算符a所表示的运算，产生元素C；

S27、将元素C压入运算元素栈，执行步骤S22。

在搜索满足资源规格函数的组件的算法构建组件依赖树后，依赖关系求解算法需要求解满足资源规格函数的所有组件的列表，以便于软件组装。因此需要对组件依赖树进行遍历，求解组件依赖树中所有以来的节点，存入组件依赖列表中。第三子算法组件依赖树遍历的算法如图4所示，即第三子算法包括以下步骤：

S31、创建组件遍历栈；所述组件遍历栈是存放还未被遍历的组件的一种栈，初始条件下为空；

S32、将组件压入组件遍历栈；

S33、判断组件遍历栈是否为空：当组件遍历栈为空，组件遍历完毕，返回组件依赖列表；当组件遍历栈不为空，继续执行S34；

S34、从组件遍历栈中弹出一种组件，组件A；

S35、将组件A加入组件依赖列表；

S36、确定组件依赖树上是否存在子节点：当组件依赖树上不存在子节点，则当前组件为组件依赖树上的叶子节点，执行步骤S33；当组件依赖树上存在子节点，将组件的所有子节点压入组件遍历栈。

另外，快速开设平台提出规范化语义版本号（规范化语义版本号是一种定义清晰的标准，用于描述开源库的版本）。它可以避免版本号混乱或不一致导致的依赖冲突。语义版本号标准定义了如何分配版本号，并指定了版本号之间的比较规则。这可以确保开发人员、用户和工具能够正确地理解和处理库的版本，每个服务器中保证，可以安装一个组件的多个版本，但是一个组件只有一个版本对外可用（进入运行状态）。语义版本号标准通常由三个数字构成：MAJOR.MINOR.PATCH。其中MAJOR版本号变化表示不兼容的API更改；MINOR版本号变化表示向后兼容的功能添加；PATCH版本号变化表示向后兼容的错误修复。例如，如果一个库的版本从1.0.0升级到2.0.0，则说明该库进行了重大变化，可能需要更改应用程序代码以适应新版本的API。使用语义版本号时，开发人员需要遵循一定的规则，例如不应跨越MAJOR版本号更改，因为这可能会导致应用程序无法兼容旧的API。此外，开发人员还应该考虑显式地记录每个库依赖的版本和范围，以避免与其他库的依赖冲突。

（c）围绕所述组件的接口设计、组件参数化设计和组件的功能设计三方面对所述组件进行结构和内部参数的配置，以接口标准为纽带将多个所述组件组织起来即可。

本申请提出了组件和参数可配置的控制软件架构，围绕组件的接口设计、组件参数化设计和组件的功能设计三方面来定义软件的组件，确定软件组件的开发方法。软件平台的可配置能力可以分为两种类型：第一种是结构上的可配置，即所谓的组件配置，软件组织上是浮动的，可以根据实际情况对软件组成进行更改；第二种是组件内部参数可配置，即组件实现中需要的数据并非在组件开发时直接写入到源代码中，而是可以根据需要由外部进行输入，再反映到组件中。

实现控制软件结构的可配置性，首先需要基于模块化思想将软件功能进行分块，其次对需要进行配置的功能块做插件化的处理。前者的作用是明确功能，降低实现结构可配置的成本，同时规定了软件的组织形式和功能块间的接口标准；后者是实现结构可配置的关键，需要确保所有的组件都采用指定的接口标准进行组件设计。功能组件与客户程序的装配过程可以类比为键与槽的装配，只有采用标准接口的功能组件才能与客户程序对接。一般意义上的插件就是遵循其客户程序指定接口标准设计的所有功能组件的统称，但是通常一个完整的软件并非只是由一段主程序加数个的功能组件就能组织起来，而是一个功能组件又可以作为其它组件的客户程序，如此嵌套就可以组织起一个结构复杂的，功能明确，但功能组件可配置的应用软件。另外，要实现软件内部参数的可配置，可以采用将参数保存到外部文件、由软件读取文件并加载数据的方式。用于保存组件参数的文件可称为参数配置文件，软件对这些文件读取和写入的过程可称为对配置文件的解析。根据以上的对于组件、接口和配置文件的描述，可配置控制软件架构可以利用模块化的思想，先将软件结构划分成多个独立的功能模块，这些模块的地位可能是客户程序，也可能是功能组件，当然也可能兼而有之，然后以接口标准为纽带，通过“搭积木”式的系统构建思想，将所有的功能模块组织起来，这样软件的骨架就建立起来了。

后续的工作就是根据每个模块的功能定义或接口文件进行功能的实现，完善组件功能并用参数配置文件配置组件参数，整个控制软件就初步开发完成了。在遵循原有的接口标准或采用与原来并行的接口标准基础上，开发新的功能组件，然后通过系统配置加载到主程序中。如此，凭借开放式的软件架构，开发人员仅仅需要复用部分组件或开发拥有新功能的组件，再经过系统配置，就可以快速完成控制软件开发。

本申请将各项组件配置关联起来，抽取元配置和衍生配置，做好配置的统一规划（包括地址、端口、节点数等信息），如表1所示。

表1组件参数配置表

而且，软件部署模型的内容可以分为资源、机制、策略和属性这4大块，如图5所示。其中，资源模型是指在部署期间的所有实体，包括已部署的软件和目标的系统。机制模型定义了在部署期间对资源产生影响的操作（安装、配置、复制、删除等）。策略模型是指对机制选择的执行方式描述，例如为了提高系统安全级别，当前安全策略涉及禁止安装程序。属性模型描述了资源、机制、策略模型的属性，用于参数化部署目标，属性可以用来实例化当前的资源，例如部署软件的大小、依赖文件、相关约束等。部署模型是以递归的形式存在的，每一个实例都由其他各部署模型组成。每个模型都提供实体的结构化以及分层描述。资源，指定为目标系统或者部署的软件，它可以表示为资源组件的树结构的抽象形式。机制，是一种可以在部署期间执行的操作，对目标系统产生影响。它可以表示基本操作( 例如传输、复制等) 或更繁复的操作，例如安装、配置、卸载等。策略，策略的选择来源于资源以及机制的选择，这里可选择基本策略，如维护系统的某个属性，或者复合策略，如在相关的仅在进行资源优化策略后进行更好的服务质量策略。属性，属性描述了资源的各详细属性，例如软件的具体属性有软件大小、软件运行硬件要求、软件依赖应用程序等。

这样有助于提高可伸缩性、弹性和可靠性，同时也支持快速部署和测试。采用代码流水线将代码从开发环境自动推送到生产环境，包括自动化测试、构建和部署。这种方式可以在保证质量的前提下，实现快速迭代和部署。采用持续部署技术可以将软件更新自动发布到生产环境中，而不需要人工干预。这种方式可以大大减少手动错误，同时提高生产效率采用自动化配置管理技术可以管理应用程序的配置，包括环境变量、数据库连接等。这种方式可以减少手动配置出错的风险，同时提高配置的可重复性和一致性。

本发明通过并行化可以将任务拆分成多个子任务，并分配给多个处理器或计算机来同时执行。这样可以提高部署过程的效率和吞吐量，将循环依赖拆分成多个阶段进行处理，每个阶段使用独立的中间件或消息队列来传递数据和状态信息，从而实现解耦和避免循环依赖。开设平台运行时，根据图6所指示的流程，按需选取平台组件，选取完成后开设平台自动进行部署规划，对选取的组件进行依赖冲突分析，对发现的冲突进行自动处置。部署分析完成后自动生成组件的部署配置文件，对选取的组件进行聚合和并行化部署。

以上所述仅为本发明较佳的实施方式，并非用以限定本发明的保护范围；同时以上的描述，对于相关技术领域中具有通常知识者应可明了并据以实施，因此其他未脱离本发明所揭露概念下所完成之等效改变或修饰，都应涵盖在本发明的保护范围之内。

Claims (7)

1.一种平台的快速部署方法，其特征在于，包括以下步骤：

（a）将平台拆分成相对独立且有具体功能的多个组件，对每个所述组件进行封装，使封装后的所述组件通过统一的访问接口进行信息传输；

（b）检测多个所述组件之间的依赖关系，建立依赖库并将其存储在中央仓库中，使用统一的标识符和版本号对所述依赖库进行管理；随后通过声明和引用所述依赖库以自动下载和安装所需的依赖项；

（c）围绕所述组件的接口设计、组件参数化设计和组件的功能设计三方面对所述组件进行结构和内部参数的配置，以接口标准为纽带将多个所述组件组织起来即可。

2.根据权利要求1所述平台的快速部署方法，其特征在于：步骤（a）中，所述平台至少包括云组件、数据库组件、智能框架组件和大数据组件。

3.根据权利要求1所述平台的快速部署方法，其特征在于：步骤（b）中，通过依赖关系求解算法检测多个所述组件之间的依赖关系，所述依赖关系求解算法包括组件依赖树的第一子算法、对资源规格函数进行运算的第二子算法和生成组件依赖列表的第三子算法。

4.根据权利要求3所述平台的快速部署方法，其特征在于，步骤（b）中，所述第一子算法包括以下步骤：

S11、判断所述组件自身状态是否有效：当组件自身状态无效时，当前组件不可用；当组件自身状态有效时，执行步骤S12；

S12、判断所述组件是否依赖其他组件：当依赖其他组件时，则当前组件可用，执行步骤S15；当不依赖其他组件时，执行步骤S13；

S13、判断资源规格函数中各组件的可用性，并对资源规格函数进行运算；

S14、判断依赖组件的布尔运算结果：当依赖组件的布尔运算为假，则当前组件不可用；当依赖组件的布尔运算为真，则当前组件可用，执行步骤S15；

S15、将当前组件加入组件依赖树。

5.根据权利要求4所述平台的快速部署方法，其特征在于，步骤（b）中，所述第二子算法包括以下步骤：

S21、将所述资源规格函数转为后缀表达式，将后缀表达式元素存入运算元素栈，后缀表达式的运算符存入运算符栈；

S22、判断运算元素栈的元素数量是否大于1：当运算元素栈的元素数量不大于1时，直接返回运算元素栈的唯一元素的可用性；当运算元素栈的元素数量大于1时，进入步骤S23；

S23、运算元素栈弹出栈顶的两个元素：元素A和元素B；

S24、判断元素A和元素B的可用性；

S25、运算符栈弹出运算符a；

S26、以元素A和元素B的可用性作为运算的前项和后项进行运算符a所表示的运算，产生元素C；

S27、将元素C压入运算元素栈，执行步骤S22。

6.根据权利要求4所述平台的快速部署方法，其特征在于，步骤（b）中，所述第三子算法包括以下步骤：

S31、创建组件遍历栈；所述组件遍历栈是存放还未被遍历的组件的一种栈，初始条件下为空；

S32、将组件压入组件遍历栈；

S33、判断组件遍历栈是否为空：当组件遍历栈为空，组件遍历完毕，返回组件依赖列表；当组件遍历栈不为空，继续执行S34；

S34、从组件遍历栈中弹出一种组件，组件A；

S35、将组件A加入组件依赖列表；

S36、确定组件依赖树上是否存在子节点：当组件依赖树上不存在子节点，则当前组件为组件依赖树上的叶子节点，执行步骤S33；当组件依赖树上存在子节点，将组件的所有子节点压入组件遍历栈。

7.根据权利要求1所述平台的快速部署方法，其特征在于，步骤（c）中，将各项组件配置关联起来，抽取元配置和衍生配置，做好配置的统一规划，所述配置包括地址、端口和节点数。

Images