一种基于容器的多机房批量自动化部署应用的方法及系统与流程

1.本发明属于自动化运维技术领域，具体涉及一种基于容器的多机房批量自动化部署应用的方法及系统。


背景技术：

2.过去，为了提升发布效率，应用大多采用单体架构，可以做到快速发布。但随着业务越来越复杂，需要将单体架构进行拆分，庞大的整体应用分解成一组服务。每个服务可以由单独的团队独立开发和维护,这些团队可以专注于某个服务，并且每一个微服务都能被独立部署。这样微服务架构开始流行了起来，它的出现为企业提供了许多关键性的优势，帮助一些企业快速发展，比如服务界限清晰，职责明确，避免了同一功能的重复开发等。但又会带来另外一个问题，就是大规模的微服务应用需要部署,所述大规模的微服务应用指的是不少于100个微服务应用的微服务集群，大大增加了部署的成本。
3.在单体架构中，由于运维只需保证少量应用的正常运行，通常采用手动部署的方式。而基于微服务架构开发的程序，由于涉及到大规模的微服务应用部署，则需高度自动化的部署流程和基础设施。特别是当服务器可能存在于跨地域的不同机房中，如何既保证部署系统安全性和应用部署之间的隔离，又能节省部署成本，实现自动化部署发布和无缝发布，并在部署发布期间仍然能够正常提供服务，就成为一个至关重要的问题。
4.针对大规模的微服务应用部署，现阶段比较主流的解决方案是基于docker容器的大规模应用部署。通过应用构建生成docker镜像，由于docker镜像里对应用的环境依赖进行了完整封装，可以做到一次构建处处运行。虽然使用docker对于单一容器、单一主机诸如构建和部署操作十分便捷，但是docker对于生产环境下大规模应用部署的支持十分有限。当单体架构拆分为微服务架构后，由于微服务之间存在依赖关系，如何编排微服务应用部署顺序成为一个关键的问题。
5.针对大规模微服务应用部署的痛点，也有人提出了基于docker容器虚拟化技术的自动化部署方案。docker是管理和部署微服务的绝佳工具，每个微服务可进一步被细分为在单独的docker容器中运行的进程，利用docker能简化应用的构建、部署和运行过程。虽然docker对于单一主机的构建部署十分便捷，但对于生产环境下多机房的大规模应用部署的支持几乎为空白。
6.与此同时,自动化部署系统在给人们带来便捷的同时，也给企业的信息安全带来了挑战，传统系统的权限控制的都是依靠人工来分配，这样当员工权限需要发生变更时，很难做到及时响应。为了加快应用的部署过程，大部分系统会通过监测代码的变化提前进行应用构建。这就造成了系统的频繁构建，给系统带来了很大的压力，需要高性能的硬件来支持。


技术实现要素：

7.本发明所要解决的技术问题是克服现有技术的不足，提供一种基于容器的多机房
批量自动化部署应用的方法及系统。
8.为解决现有的技术问题，本发明提供一种基于容器的多机房批量自动化部署应用的方法，其特征在于，包括如下步骤：
9.步骤1：在应用部署系统中录入应用部署信息，所述应用部署信息包含组织架构信息、应用信息、版本信息、环境信息及连接配置信息；
10.所述组织架构信息包含部门名称及部门类别；所述部门类别包含研发、测试、运维、项目管理及其他；
11.所述应用信息包含微服务应用名称、部门名称、依赖应用列表及微服务应用的类别；所述依赖应用列表根据不同微服务应用之间的依赖关系，配置不同微服务应用名称之间的关联；所述依赖应用列表记录存在关联的微服务应用名称；所述微服务应用的类别包含前端应用和后端应用；所述前端应用用于返回用户请求的页面或数据报文；所述后端应用用于数据计算和数据存储且不直接与用户进行交互；
12.在所述版本信息中，针对业务需求形成编制版本，1个业务需求对应1个编制版本，1个编制版本关联至少1个微服务应用的编制；所述版本信息包含编制版本的版本号、部门名称、关联的微服务应用名称、版本上线时间；
13.所述环境信息用于定义机房及机器，所述机房及机器用于应用部署的应用环境配置，所述应用环境至少配置在1个机房内的1个机器上；所述环境信息包含应用环境类型、机房名称、机器编号；所述应用环境类型包含开发环境、测试环境及生产环境；
14.所述连接配置信息是指应用部署所需的连接信息，包含机房名称、应用环境类型、连接地址；所述连接地址包含ip地址和端口号；
15.步骤2：分配基于组织架构的用户权限，具体为：
16.步骤2
‑
1：定义用户的身份类别：获取组织架构信息，以用户的隶属部门定义身份类别，所述身份类别包含研发类别、测试类别、运维类别、项目管理类别及其他类别；
17.步骤2
‑
2：根据用户的身份类别，分配相应应用环境中的应用部署权限；若用户的身份类别为研发类别，开启开发环境中的应用部署权限，关闭测试环境及生产环境中的应用部署权限；若用户的身份类别为测试类别，开启测试环境中的应用部署权限，关闭开发环境及生产环境中的应用部署权限；若用户的身份类别为运维类别，开启生产环境中的应用部署权限，关闭开发环境及测试环境中的应用部署权限；若用户的身份类别为项目管理类别，开启开发环境及测试环境中的应用部署权限，关闭生产环境中的应用部署权限；若用户的身份类别为其他类别，关闭所有应用环境中的应用部署权限；
18.步骤3：建立基于生命周期的应用构建，所述生命周期包括应用的开发阶段、测试阶段和发布阶段；首先，在应用编制时，以每个编制版本的版本号为单位，为版本号关联的应用标识转测时间和发布时间；其次，以转测时间和发布时间区分该应用所处的生命周期的阶段；所述发布时间取版本信息中的版本上线时间的值；动态监测应用所处的生命周期的阶段，若当前时间在转测时间之前，应用的生命周期阶段为开发阶段；若当前时间在转测时间和发布时间之间，应用的生命周期阶段为测试阶段；若当前时间在发布时间之后，应用的生命周期阶段为生产阶段；
19.在任一个生命周期的阶段，监听从应用部署系统发送的应用构建指令后触发应用构建；所述应用构建指令中包含版本号和应用名称；待系统接收到应用构建指令后，根据应
用名称获取应用程序源码，应用程序源码经应用构建生成应用镜像文件存入镜像仓库，所述应用镜像文件包含应用程序源码和应用部署所依赖的软件；所述应用镜像文件生成时以应用构建指令中包含的版本号和应用名称命名；
20.步骤4：编排应用部署的优先级:根据依赖应用列表编排应用部署的顺序，当多个微服务应用同时部署时，依照微服务应用的类别区分前端应用和后端应用，先执行后端应用的部署，再执行前端应用的部署；调用当前待部署后端应用的依赖应用列表，先执行依赖应用列表中的后端应用部署，再执行当前待端署后端应用的部署；调用当前待部署前端应用的依赖应用列表，先执行依赖应用列表中的前端应用部署，再执行当前待端署前端应用的部署；
21.步骤5：以版本号为单位，执行部署与版本号关联的多个微服务应用，具体为：
22.步骤5
‑
1：下载应用镜像至部署机房：待系统接收到包含版本号的应用部署指令，根据版本信息，匹配关联版本号的微服务应用名称；获取应用的生命周期的阶段，以应用的生命周期的阶段作为部署环境的应用环境类型；待确认指令发出用户在部署环境中具有应用部署权限后，根据环境信息，匹配与部署环境的环境类型一致的机房名称及机器编号；下载文件名包含版本号和应用名称的应用镜像文件至部署机房的机器内；
23.步骤5
‑
2：以容器的形式启动微服务应用在不同环境和机房内的部署：以容器封装应用镜像文件的微服务应用名称、应用程序源码及应用部署所依赖的软件；按照步骤4的优先级编排规则，编排待部署应用的部署顺序，容器内的应用镜像文件按照部署顺序启动运行。
24.在所述步骤1中，所述连接地址是数据库连接地址、服务注册地址和缓存数据库地址的集合；所述数据库连接地址包含数据库名称；所述缓存数据库地址包含缓存数据库名称；
25.在所述步骤1中，版本信息录入时，由用户向系统提交版本号，应用部署系统获取到版本号后，将与版本号关联的微服务应用名称、版本上线时间、用户隶属部门的部门名称录入所述版本号的版本信息；所述版本号中包含业务名称、编制年份及编号；所述版本号中的编号由系统自动生成。在所述步骤2中，对于首次进入应用部署系统的用户，应用部署系统根据用户的隶属部门获取该部门的微服务应用名称；将微服务应用名称相应的应用信息反馈给用户；当用户所在部门发生变化后，获取变化后的部门名称，以新的部门名称对应的部门类别作为用户的新身份类别，并依据新身份类别分配新的环境中的应用部署权限。在所述步骤3中，应用镜像文件的命名中还包含文件生成编号，所述文件生成编号根据应用镜像文件生成时间自动生成，具体为：按照应用镜像文件的生成时间的先后顺序，新的文件生成编号在前一个文件生成编号基础上加1。
26.在所述步骤3中，生产阶段的应用构建指令由用户发出至应用部署系统；测试阶段和生产阶段后的应用构建指令根据应用程序源码的变化触发发出至应用部署系统，具体为：每小时检测应用程序源码的变化，如若源码内容发生了变更，自动获取源码变化的应用名称及关联应用的版本号，以应用名称和版本号形成应用构建指令；
27.所述步骤3中的应用镜像为docker应用镜像；
28.所述步骤3的应用构建之前，利用jenkins对应用程序源码执行代码语法检测及单元测试，待代码语法检测及单元测试全部通过后，将本次预构建的应用加入应用构建队列；
应用构建队列按照先入先出顺序地执行应用构建；
29.所述步骤3中，对镜像仓库中存储的应用镜像文件定期清理；在应用的开发阶段和测试阶段，均只保留最后一次应用构建生成的应用镜像文件；在发布阶段则保留每一次应用构建生成的应用镜像文件。
30.在所述步骤3中，应用编制时，用户新编制的应用程序源码提交至代码管理服务器中，动态监测代码管理服务器中的应用程序源码变化；所述代码管理服务器为svn。
31.在所述步骤4的优先级编排过程中，不存在依赖关系的后端应用同时部署；不存在依赖关系的前端应用同时部署。在所述步骤5
‑
1中，获取应用部署指令发出用户的应用部署权限；匹配用户的应用部署权限下的应用环境类型是否与部署环境的应用环境类型一致；若不一致，用户在部署环境中不具有应用部署权限，系统拒绝部署；若一致，用户在部署环境中具有应用部署权限，系统执行部署；
32.在所述步骤5
‑
1的以应用的生命周期的阶段作为部署环境的应用环境类型的步骤中，应用的生命周期阶段为开发阶段，部署环境的应用环境类型为开发环境；若应用的生命周期阶段为测试阶段，部署环境的应用环境类型为测试环境；若应用的生命周期阶段为生产阶段，部署环境的应用环境类型为生产环境；
33.在所述步骤5
‑
1的应用镜像文件下载中，若根据版本号和微服务应用名称，在应用镜像仓库中找到多个应用镜像文件，取应用镜像文件生成的时间，按照从前至后进行排序，下载生成时间排在最后的应用镜像文件；
34.在所述步骤5
‑
2中，应用镜像文件运行时，从连接配置信息中获取到数据库连接地址、缓存数据库地址及服务注册地址；按照数据库连接地址的ip和端口号，执行应用与后台数据库的连接；按照缓存数据库连接地址的ip和端口号，执行应用与后台缓存数据库的连接；按照注册中心地址的ip和端口号，执行应用在注册中心的注册；
35.待所述步骤5的应用在指定机房和指定环境中部署成功后，将应用对外提供服务的地址信息更新入nginx反向代理服务器的配置文件中。
36.一种基于容器的多机房批量自动化部署应用的系统，其特征在于，包括基础信息管理模块、用户管理模块、配置中心、应用构建模块、应用部署模块及应用镜像库；所述基础信息管理模块，用于管理包含组织架构信息、连接配置信息、应用信息、版本信息及环境信息的基础信息；所述用户管理模块，用于用户管理及控制应用部署权限的自动分配；所述配置中心，用于配置应用在指定机房和环境中部署所需的必要配置信息；所述应用构建模块，用于根据应用所处的生命周期阶段执行应用构建；所述应用部署模块，用于控制应用在不同机房和不同环境下的正常部署；
37.用户管理模块从基础信息模块中获取组织架构信息，根据组织架构信息为用户分配在不同环境中的应用部署权限；在权限允许的条件下，应用构建模块从基础信息模块中获取应用信息，按照应用名称跟踪应用程序源码的变化，待检测到代码变化时，判断应用所处生命周期的阶段，并依据生命周期的阶段触发应用构建，形成应用镜像存入应用镜像库；待应用构建完成后，应用部署模块获取待部署的应用，按照动态编排的应用部署优先级，顺序地针对不同应用的配置环境和配置机房，从配置中心获取配置信息，并连同从应用镜像库中下载的应用镜像实例打包发送至机房，完成应用在指定机房和环境下的部署。
38.本发明所达到的有益效果:
39.(1)本发明通过根据应用所处在生命周期的阶段选择性执行应用构建,实现对对应用自动化构建过程的更细粒度的控制，在满足用户自动化构建需求的前提下，减少了应用构建的次数。同时通过定期清除构建生成的镜像以释放镜像的存储空间,极大地降低了构建的成本；
40.(2)在用户权限的管理上，本发明不再通过传统的人工手动进行权限控制，而是能结合公司现有的组织架构，根据用户归属都责任部门以及职位动态的进行权限分配，当员工的职位变化导致责任部门变化后，同步调整员工的权限，增强了部署系统的信息安全；
41.(3)本发明针对跨地域多机房的复杂场景,隔离不同环境不同机房内应用部署配置信息,应用部署时以容器封装应用程序源码,并根据应用部署的机房和环境拉取部署配置信息,减少依赖应用配置文件泄露带来的安全风险,实现了同一个应用容器在不同环境不同机房启动时读取不同应用配置的问题。
42.(4)本发明基于应用类型和应用间依赖关系，在应用部署的过程中动态编制应用部署顺序，并通过分离应用镜像下载和容器启动的应用镜像运行过程，保障应用部署时按照编制顺序运行，不仅遵循应用间的优先级关系，使应用在发布期间仍能正常提供服务，也进一步提高了部署效率。
附图说明
43.图1为本发明实施例中一种基于容器的多机房批量自动化部署应用方法流程图；
44.图2为本发明实施例中一种多机房环境下自动部署应用的方法流程图；
45.图3为本发明实施例中一种多机房批量自动化部署应用的系统结构简图。
具体实施方式
46.下面结合附图和示例性实施例对本发明作进一步的说明：
47.图1为本发明实施例中基于容器的多机房批量自动化部署应用的方法流程图，如图1所示，具体步骤包括：
48.步骤101：在应用部署系统中录入应用部署信息，所述应用部署信息包含组织架构信息、应用信息、版本信息、环境信息及连接配置信息；
49.所述组织架构信息是指相关责任部门划分的信息，用于用户身份的归类；所述组织架构信息包含部门名称及部门类别名称；所述部门类别包含研发、测试、运维、项目管理及其他；
50.所述应用信息是用于描述微服务应用的属性信息，包含微服务应用名称、部门名称、依赖应用列表及微服务应用的类别；所述依赖应用列表按照应用对其他应用的依赖关系，配置应用名称与其他应用名称之间的关联；所述依赖应用列表记录着存在关联的其他应用的应用名称；所述应用类别是指微服务应用的类别，所述微服务应用的类别包含前端应用和后端应用；所述前端应用是指用于返回用户请求的页面或者数据报文的应用；所述后端应用是指用于数据计算和数据存储且不直接与用户进行交互的应用；
51.所述版本信息是针对业务需求形成的编制版本，1个业务需求对应1个编制版本，1个编制版本关联至少1个微服务应用的编制；比如业务需求“黑五大促销”对应的编制版本1，与编制版本1关联应用有订单微服务应用、会员微服务应用及商品微服务应用的编制；业
务需求“添加会员类型”对应的编制版本2，此时编制版本2关联会员微服务应用的编制；所述版本信息包含编制版本的版本号、部门名称、关联应用名称、版本上线时间；在本发明实施例中的版本信息录入时，由用户向系统提交版本号，比如版本号为mic
‑
2021
‑
001，其中mic为业务名称、2021年编制年份、001是系统自动生成的编号；系统获取到版本号后，将与版本号相关的关联应用名称、版本上线时间、用户归属部门的部门名称录入所述版本号的版本信息；
52.所述环境信息用于定义应用部署的应用环境所配置在的机房及机器，所述应用环境至少配置在1个机房内的1个机器上；所述环境信息包含应用环境类型、机房名称、机器编号；所述应用环境类型包含开发环境、测试环境及生产环境；
53.所述连接配置信息是指应用部署在指定机房和指定环境中所需的连接信息，所述连接配置信息包含机房名称、应用环境类型、连接地址；所述连接地址包含ip地址和端口号；本发明实施例中的连接地址是指数据库连接地址、服务注册地址、缓存数据库地址的地址集合；比如数据库连接地址配为192.168.1.49:1520；缓存数据库地址配为192.168.1.128:8998；服务注册地址配为192.168.1.132:2181
54.步骤102：基于组织架构信息，为归属各部门的用户分配应用部署权限；
55.步骤102
‑
1：定义用户的身份类别：从配置中心获取组织架构信息，按照部门类别为隶属该部门的用户分配身份类别，以获取的部门类别作为该部门下用户的身份类别，所述身份类别包含研发类别、测试类别、运维类别、项目管理类别及其他类别；
56.步骤102：根据用户的身份类别，分配不同的应用部署权限，所述应用部署权限是指应用环境中的应用部署权限；用户的身份类别为研发类别，开启开发环境中的应用部署权限，关闭测试环境及生产环境中的应用部署权限；用户的身份类别为测试类别，开启测试环境中的应用部署权限，关闭开发环境及生产环境中的应用部署权限；用户的身份类别为运维类别，开启生产环境中的应用部署权限，关闭开发环境及测试环境中的应用部署权限；用户的身份类别为项目管理类别，开启开发环境及测试环境中的应用部署权限，关闭生产环境中的应用部署权限；用户的身份类别为其他类别，关闭所有应用环境中的应用部署权限；
57.首次进入应用部署系统的用户，根据用户所在部门的部门名称获取该由部门负责编制的应用的应用名称；根据应用名称获取应用信息反馈给用户；所以新用户只需要登录便能知道自己部门负责的应用名称、应用依赖列表、应用类别；同时根据新用户的身份类别，系统知道用户在哪些环境下具有应用部署的权限；当用户所在部门发生变化后，获取变化后的部门名称，以新的部门名称对应的部门类别作为用户的新身份类别，并依据新身份类别分配新的环境中的应用部署权限；
58.步骤103：基于生命周期的应用构建，所述生命周期是应用的开发阶段、测试阶段和发布阶段的合集；首先，在应用编制时，以每个编制版本的版本号为单位，为版本号关联的每一个应用标识转测时间和发布时间；其次，以转测时间和发布时间区分该应用所处的生命周期的阶段；所述发布时间取版本信息中的版本上线时间的值；所述生命周期的阶段包含开发阶段、测试阶段及发布阶段；动态监测应用所处的生命周期的阶段，若当前时间在转测时间之前，应用的生命周期阶段为开发阶段；若当前时间在转测时间和发布时间之间，应用的生命周期阶段为测试阶段；若当前时间在发布时间之后，应用的生命周期阶段为生
产阶段；
59.在任一个生命周期的阶段，监听获取应用构建指令后触发应用构建；所述应用构建指令中包含版本号和应用名称；在本发明实施例中，生产阶段的应用构建指令由用户发出；测试阶段和生产阶段后的应用构建指令根据应用程序变化触发发出，具体为：每小时检测应用程序源码的变化，如若源码内容发生了变更，自动获取源码变化的应用名称及关联应用的版本号，以应用名称和版本号形成应用构建指令；
60.待系统接收到应用构建指令后，根据应用名称获取应用程序源码，应用程序源码经应用构建生成应用镜像文件存入镜像仓库，所述应用镜像文件包含应用程序源码和应用部署所依赖的基础软件，比如系统软件；所述应用镜像文件生成时以应用构建指令中包含的版本号和应用名称命名；
61.在应用构建形成应用镜像文件之前，利用jenkins对变更后的应用程序源码执行代码检测及单元测试，待应用程序源码无语法和执行逻辑错误后，将本次预构建的应用加入应用构建队列；应用构建队列按照先入先出顺序地执行应用的构建。通过上述结合生命周期的阶段对应用构建实施更细粒度的控制，在满足自动化构建要求的同时降低了构建的频率，缩减了构建的成本。
62.在本发明实施例中，应用镜像仓库中的应用镜像文件定时清理。在开发阶段和测试阶段均只保留最后一次应用构建生成的应用镜像文件；发布阶段则会保留每一个应用构建生成的应用镜像文件以支持版本回退功能，通过结合镜像文件的定时清理策略，提高了镜像文件空间的利用率；
63.步骤104：应用部署的优先级编排:由于微服务之间存在依赖关系，为了保证在部署过程中能正常对外提供服务，要对应用部署顺序进行动态编排。根据应用类型和应用间依赖关系编排应用部署的顺序。所述应用间依赖关系用于限定待部署应用依赖在其他应用部署完成之后才能执行部署；所述应用间依赖关系预先配置在应用信息的依赖应用列表中；
64.当多个微服务应用同时部署时，依照应用类型区分前端应用和后端应用，先执行后端应用的部署，再执行前端应用的部署；针对后端应用间存在的依赖关系，调用当前待部署后端应用的依赖应用列表，先执行依赖应用列表中的后端应用部署，再执行当前待端署后端应用的部署；针对前端应用间存在的依赖关系，调用当前待部署前端应用的依赖应用列表，先执行依赖应用列表中的前端应用部署，再执行当前待端署前端应用的部署；不存在依赖关系的后端应用同时部署；不存在依赖关系的前端应用同时部署；
65.步骤105：以版本号为单位，将与版本号关联的多个应用，以容器的形式启动应用在不同环境和机房内的部署；包含应用镜像下载至部署机房和应用镜像文件在容器内运行，具体为：
66.步骤105
‑
1：应用镜像下载至部署机房；
67.105
‑1‑
1：获取部署环境的应用环境类型：所述部署环境根据应用的生命周期的阶段决定；若应用的生命周期阶段为开发阶段，部署环境的应用环境类型为开发环境；若应用的生命周期阶段为测试阶段，部署环境的应用环境类型为测试环境；若应用的生命周期阶段为生产阶段，部署环境的应用环境类型为生产环境；
68.105
‑1‑
2：应用部署权限判断：获取发出应用部署指令的用户名，获得所述用户的
应用部署权限；匹配用户的应用部署权限下的应用环境是否与部署环境一致；若不一致，拒绝部署；若一致，继续执行；
69.105
‑1‑
3：获取部署机房的地址：根据部署环境的环境名称，从所述环境信息中匹配应用环境类型与部署环境类型一致的机房名称及机器编号；以机房名称和机器编号作为部署机房的地址；
70.105
‑1‑
4：应用镜像文件下载至指定机房的指定机器内：根据部署指令中的版本号找到关联应用的应用名称，按照版本号和应用名称，从应用镜像库中找到文件名与版本号及应用名称一致的应用镜像文件；按照部署机房的地址，下载应用镜像文件至指定机房的指定机器内；若应用镜像库中找到多个版本号及应用名称均一致的应用镜像文件，取应用镜像文件生成的时间按照从前之后排序，下载生成时间排在最后的应用镜像文件；
71.步骤105
‑
2：应用镜像文件在容器内运行；当待部署应用的应用镜像文件下载至指定机房的指定机器内后，以容器封装应用镜像文件的应用名称、应用程序源码及应用部署所依赖的软件；按照步骤4的优先级编排规则，编排待部署应用的部署顺序，容器内的应用镜像文件按照部署顺序启动运行；待每个容器自动启动时，获取容器内应用镜像文件的应用名称，根据应用名称及部署机房的地址，从连接配置信息中获取连接地址；在执行应用程序源码的过程，按照连接地址中的数据库连接ip及端口号、缓存数据库ip及端口号、服务注册ip及端口号，执行应用与后台数据库的连接、后台缓存数据库的连接和应用在注册中心的注册；待应用在指定机房和指定环境中部署成功后，将应用对外提供服务的地址信息更新入nginx反向代理服务器的配置文件中。
72.为解决日复一日频繁构建及发布应用，避免花费大量的时间进行重复劳动。本发明实施例中选用docker镜像作为经应用构建后生成的应用镜像，如图2所示的本发明实施例中的一种多机房环境下自动部署应用的方法流程图，解决持续化集成场景中多服务应用在多机房自动化部署和无缝对接发布的问题，保障在部署发布期之间仍能正常提供服务，具体流程包含：
73.步骤201：新编制的应用程序源码提交至代码管理服务器。在本发明实施例的持续化集成管理中,选用svn(subversion的缩写)代码管理服务器。svn是一个开放源代码的版本控制系统，用于多个人共同开发同一个项目，实现共享资源，实现最终集中式的管理。
74.步骤202：根据应用的生命周期启动应用构建；应用构建系统定时扫描代码管理服务器，待检测到代码管理服务器中应用程序源码发生变化时，获取当前时间点，将当前时间点与转测时间点和发布时间点进行比较，判断应用所处的生命周期阶段；若当前时间点在转测时间点之前，应用当前处于开发阶段；若当前时间点在转测时间点和发布时间点之间，应用当前处于测试阶段；若当前时间点在发布时间点之后，应用当前处于发布阶段；当应用处于测试阶段和发布阶段时，应用程序源码的变化自动触发应用构建。通过引入生命周期，解决了频繁应用构建导致的系统高负载繁忙，同时也减少了应用构建文件存储的压力。
75.步骤203：应用经构建后生成应用docker镜像文件，存入私有docker镜像库：针对步骤202触发启动应用构建的应用，先利用jenkins对应用程序源码进行单元测试和静态代码检查，待全部通过后生成与应用程序源码对应的docker应用镜像，并保存在docker镜像仓库，同时生成应用待部署任务加入待部署队列中；
76.未通过jenkins检测的应用程序源码，生成失败原因通过邮件的方式发送给代码
提交人；代码提交人通过邮件查看到构建失败具体原因，修改代码并手动触发构建或者等待下一次自动构建，直至应用构建成功。
77.步骤204：动态编排应用部署的优先级顺序：获取当前需要部署的应用，区分前端应用和后端应用，先执行后端应用的部署，再执行前端应用的部署；获取各个后端应用的应用依赖列表中记录的应用间依赖关系，先部署应用依赖列表记录的后端应用，再部署当前待部署的后端应用；获取各个前端应用的应用依赖列表中记录的应用间依赖关系，先部署应用依赖列表记录的前端应用，再部署当前待部署的前端应用；
78.若当前需要部署的后端应用之间不存在依赖关系，同时执行部署；若当前需要部署的前端应用之间不存在依赖关系，同时执行部署；
79.步骤205：按照编排的优先级顺序执行应用部署：获取待部署应用的应用名及预部署的机房和环境；所述预部署的环境根据应用所处的生命周期判断，若当前应用所处的生命周期的阶段是测试阶段，预部署的环境为测试环境；若当前应用所处的生命周期的阶段是发布阶段，预部署的环境为生产环境；
80.从私有docker镜像仓库中拉取待部署应用的docker镜像；同时在应用容器启动的过程中，处于不同机房的容器会根据其部署的环境以及机房信息自动从配置中心获取应用的配置信息，进行启动。
81.步骤206：应用提供服务的地址更新：由于系统中采用nginx作为反向代理服务器，所以在应用部署成功后，需要将应用容器的ip同步更新到nginx配置文件中。配置文件更新完毕后，nginx会重新加载修改后的nginx配置，继续对外提供服务。待部署的应用在各个机房都全部启动完毕，nginx反向代理服务器也完成最新nginx配置的加载后，整个多机房的微服务集群的部署也就完成了。
82.在本发明实施例中的部署环境包含开发环境、测试环境及生产环境，所述开发环境、所述测试环境和所述生产环境均能配置在多个机房的多个计算机内，比如部署机房包含美国机房、联通机房及本地机房，在上述三个机房内配有多台计算机；在任一机房内配置开发环境、测试环境及生产环境，不同的环境配在不同的计算机内；相关应用部署的环境信息提前录入系统，供应用部署时根据部署环境调用获取部署的机房名称和机器编号；
83.在本发明实施例中，所述开发环境用于开发人员验证应用代码的可行性；所述测试环境用于应用发布的测试；所述生产环境是应用正式提供服务的环境；在应用部署时，会根据实际需要动态地执行在指定环境及指定机房的部署。
84.如图3所示的本发明实施例中的一种多机房批量自动化部署应用的系统结构简图，具体包含应用自动化部署系统、nginx反向代理服务器、机房；所述nginx反向代理服务器与服务访问方相连，所述机房包含美国机房、联通机房及本地机房；所述应用自动化部署系统包含基础信息管理模块、用户管理模块、配置中心、应用构建模块、应用部署模块及docker应用镜像库；其中，所述基础信息管理模块，用于管理组织架构信息、应用信息、应用版本信息等基础信息；所述用户管理模块，用于用户信息管理及控制应用部署权限的自动分配；所述配置中心，用于配置应用在指定机房和环境中部署所需的必要配置信息；所述应用构建模块，用于根据应用所处的生命周期阶段执行应用构建；所述应用部署模块，用于控制应用在不同机房和不同环境下的正常部署；
85.用户管理模块从基础信息模块中获取组织架构信息，根据组织架构信息为用户分
配在不同环境中的应用部署权限；在权限允许的条件下，应用构建模块从基础信息模块中获取应用信息，按照应用名称跟踪应用程序源码的变化，待检测到代码变化时，判断应用所处生命周期的阶段，并依据生命周期的阶段触发应用构建，形成应用镜像存入应用镜像库；待应用构建完成后，应用部署模块获取待部署的应用，按照动态编排的应用部署优先级，顺序地针对不同应用的配置环境和配置机房，从配置中心获取配置信息，并连同从应用镜像库中下载的应用镜像实例打包发送至机房，完成应用在指定机房和环境下的部署。
86.本发明所达到的有益效果:
87.(1)本发明通过根据应用所处在生命周期的阶段选择性执行应用构建,实现对对应用自动化构建过程的更细粒度的控制，在满足用户自动化构建需求的前提下，减少了应用构建的次数。同时通过定期清除构建生成的镜像以释放镜像的存储空间,极大地降低了构建的成本。
88.(2)在用户权限的管理上，本发明不再通过传统的人工手动进行权限控制，而是能结合公司现有的组织架构，根据用户归属都责任部门以及职位动态的进行权限分配，当员工的职位变化导致责任部门变化后，同步调整员工的权限，增强了部署系统的信息安全。
89.(3)本发明针对跨地域多机房的复杂场景,隔离不同环境不同机房内应用部署配置信息,应用部署时以容器封装应用程序源码,并根据应用部署的机房和环境拉取部署配置信息,减少依赖应用配置文件泄露带来的安全风险,实现了同一个应用容器在不同环境不同机房启动时读取不同应用配置的问题。
90.(4)本发明基于应用类型和应用间依赖关系，在应用部署的过程中动态编制应用部署顺序，并通过分离应用镜像下载和容器启动的应用镜像运行过程，保障应用部署时按照编制顺序运行，不仅遵循应用间的优先级关系，使应用在发布期间仍能正常提供服务，也进一步提高了部署效率。
91.以上实施例不以任何方式限定本发明，凡事对以上实施例以等效变换方式作出的其他改进与应用，都属于本发明的保护范围。