用于分布式应用的部署交付方法

技术领域

本发明涉及分布式应用部署的相关技术领域，具体地说是用于分布式应用的部署交付方法。

背景技术

公司开发的软件平台产品采用模块化开发的思想，分布式的技术架构，将各个相对独立的功能模块单独一个应用，产品交付时也会根据客户的需求不同，部署项目客户需要的若干应用模块，同时各个模块需要依赖的组件也不尽相同。因项目多，各个项目的需求各异，导致每个项目部署交付时都会因不同的需求，因此各个项目需要部署的应用模块、组件、配置项等需求也变得复杂多样，故如何能够简化部署流程，提高产品交付效率是目前亟待解决的技术问题。

发明内容

本发明的技术任务是提供一种用于分布式应用的部署交付方法，来解决因项目需求多样化带来的交付时工序复杂，缺少标准流程，效率较低的问题。

本发明的技术任务是按以下方式实现的，一种用于分布式应用的部署交付方法，该方法是通过web界面来协助整个平台系统的部署，采用引导性的方式引导平台部署人员完成部署工作；部署系统使用时，将部署系统的安装包及整个平台的包上传到需要部署的服务器集群中的一台服务器上，该服务器称为管理节点；再启动部署系统，访问部署页面进行平台部署流程的操作，具体如下：

S1、确定环境及环境服务器维护；

S2、选择需要部署的平台应用模块；

S3、部署并启动组件；

S4、配置平台应用的配置项；

S5、平台各个配置项的校验；

S6、检测平台应用模块。

作为优选，所述部署系统为java语言编写，依赖jdk环境，并支持管理多套环境的部署。

作为优选，所述步骤S1中确定环境及环境服务器维护具体如下：

创建一套部署环境的基本信息或者选择之前添加过的部署环境，通过完善部署之前添加过的部署环境，添加新应用模块或者组件；其中，部署环境的基本信息包括环境的项目名称、环境名称以及该环境需要用的服务器并配置好各个服务器连接。

作为优选，所述步骤S2中选择需要部署的平台应用模块具体如下：

S201、根据步骤S1中创建或者确定的环境信息，选择部署环境需要部署的应用模块；

S202、平台包括数十个应用模块，各个应用模块之间存在依赖关系，部署系统记录平台各个应用模块之间的依赖关系。

作为优选，所述步骤S3中部署并启动组件具体如下：

部署应用依赖的组件，组件的部署工作依赖ansible实现，提前编写好平台全部组件的安装脚本，具体部署组件的服务器信息以变量的方式实现可配置；

当步骤S2中确定好全部需要部署的应用后，部署系统会根据自身记录的每个应用模块需要依赖的组件，整理出此次环境需要部署的全部组件列表，并展示出来，用于触发组件部署任务。

作为优选，所述步骤S4中配置项的值包括自动生成和手动填写；

其中，自动生成：部署系统会预存一套平台应用的配置信息，平台应用的配置信息包括所有需要根据项目环境个性化修改的配置项的key值和默认value值；对于与组件信息有关的配置项，当各个组件部署完成后，通过触发部署系统中的配置生成功能，通过配置生成器模块根据规则自动生成配置项的value值，规则的逻辑是根据之前预存的配置项和本次部署的组件的信息，自动生成相应配置项的value值；其中，与组件信息有关的配置项包括数据库服务连接地址及缓存服务地址；

手动填写：对于和平台组件无关的配置项，需在部署平台提供的页面中做相应修改；其中，与平台组件无关的配置项包括项目使用默认区划及项目默认密码。

作为优选，所述步骤S5中平台各个配置项的校验具体如下：

部署人员触发校验操作，会对这套环境的全部必填配置项进行校验，全部必填配置项包括是否全部必填配置项已填写各个配置项是否存在格式错误及配置项中配置的各个服务是否正常。

更优地，所述步骤S6中检测平台应用模块具体如下：

S601、触发平台该套环境的所有应用启动，并提供基于springboot-actua tor的应用状态监控；

S602、通过调用各个应用模块的监控接口，整理后进行展示，用于部署人员观察每个应用实例的运行状态，做到及时发现异常应用并进行相应处理。

本发明的用于分布式应用的部署交付方法具有以下优点：

(一)本发明解决了因项目需求多样化带来的交付时工序复杂，缺少标准流程，效率较低的问题，能够简化部署流程，提高产品交付效率；

(二)本发明提高了部署工作的工作效率，简化了部署流程，通过增加各模块依赖关系维护、组件部署自动化、应用状态监控等功能，减少了部署过程中这些环节问题发生的概率。

附图说明

下面结合附图对本发明进一步说明。

附图1为用于分布式应用的部署交付方法的流程框图。

具体实施方式

参照说明书附图和具体实施例对本发明的用于分布式应用的部署交付方法作以下详细地说明。

实施例：

如附图1所示，本发明的用于分布式应用的部署交付方法，该方法是通过web界面来协助整个平台系统的部署，采用引导性的方式引导平台部署人员完成部署工作；部署系统使用时，将部署系统的安装包及整个平台的包上传到需要部署的服务器集群中的一台服务器上，该服务器称为管理节点；再启动部署系统，访问部署页面进行平台部署流程的操作，具体如下：

S1、确定环境及环境服务器维护；

S2、选择需要部署的平台应用模块；

S3、部署并启动组件；

S4、配置平台应用的配置项；

S5、平台各个配置项的校验；

S6、检测平台应用模块。

本实施例中的部署系统为java语言编写，依赖jdk环境，并支持管理多套环境的部署。

本实施例中的步骤S1中确定环境及环境服务器维护具体如下：

创建一套部署环境的基本信息或者选择之前添加过的部署环境，通过完善部署之前添加过的部署环境，添加新应用模块或者组件；其中，部署环境的基本信息包括环境的项目名称、环境名称以及该环境需要用的服务器并配置好各个服务器连接。

本实施例中的步骤S2中选择需要部署的平台应用模块具体如下：

S201、根据步骤S1中创建或者确定的环境信息，选择部署环境需要部署的应用模块；

S202、平台包括数十个应用模块，各个应用模块之间存在依赖关系，部署系统记录平台各个应用模块之间的依赖关系。

举例：当部署人员选择需要部署A系统时，那么A系统正常运行需要依赖的B、C两个系统都会自动绑定在后续的应用部署过程中与A一同部署，这样就解决了需要人工维护各个系统依赖关系的问题，减少部署过程中应用依赖问题的产生。

本实施例中的步骤S3中部署并启动组件具体如下：

S301、部署应用依赖的组件，组件的部署工作依赖ansible实现，提前编写好平台全部组件的安装脚本，具体部署组件的服务器信息以变量的方式实现可配置；

S302、当步骤S2中确定好全部需要部署的应用后，部署系统会根据自身记录的每个应用模块需要依赖的组件，整理出此次环境需要部署的全部组件列表，并展示出来，用于触发组件部署任务。

举例：如步骤S2中确定需部署A、B、C三个应用模块，A模块需要依赖redis、zookeeper、mysql三个组件，B模块需要依赖redis、zookeeper两个组件，C模块需要依赖redis、zookeeper、kafka，那么部署系统就会列出需要部署部署的全都组件清单，即redis、zookeeper、mysql、kafka。部署人员将全部需要部署的组件安排好各自要占用的服务器以后，触发组件部署操作，部署系统会通过触发ansible的接口，将部署人员分配的组件服务器地址以参数形式传递给各个组件的部署脚本，将各个组件的安装包分发到指定服务器并通过编写好的脚本以此进行组件的自动化的安装部署。

本实施例中的步骤S4中配置项的值包括自动生成和手动填写；

其中，自动生成：部署系统会预存一套平台应用的配置信息，平台应用的配置信息包括所有需要根据项目环境个性化修改的配置项的key值和默认value值；对于与组件信息有关的配置项，当各个组件部署完成后，通过触发部署系统中的配置生成功能，通过配置生成器模块根据规则自动生成配置项的value值，规则的逻辑是根据之前预存的配置项和本次部署的组件的信息，自动生成相应配置项的value值；其中，与组件信息有关的配置项包括数据库服务连接地址及缓存服务地址；

手动填写：对于和平台组件无关的配置项，需在部署平台提供的页面中做相应修改；其中，与平台组件无关的配置项包括项目使用默认区划及项目默认密码。

本实施例中的步骤S5中平台各个配置项的校验具体如下：

部署人员触发校验操作，会对这套环境的全部必填配置项进行校验，全部必填配置项包括是否全部必填配置项已填写各个配置项是否存在格式错误及配置项中配置的各个服务是否正常。

本实施例中的步骤S6中检测平台应用模块具体如下：

S601、触发平台该套环境的所有应用启动，并提供基于springboot-actua tor的应用状态监控；

S602、通过调用各个应用模块的监控接口，整理后进行展示，用于部署人员观察每个应用实例的运行状态，做到及时发现异常应用并进行相应处理。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。