CN115567392A - 一种客户内部业务系统自动部署升级方法 - Google Patents

Abstract

本发明提供一种客户内部业务系统自动部署升级方法，首先获取业务系统已有的配置模板，具体方法为从业务系统的运行时配置中获得出配置模板，更新配置模板的格式，并将更新后的配置模板替换成现场运行时配置；基于更新后的模板化的运行时配置进行系统升级。和现有技术相比，本发明所记载的方法实现了配置模板的自动生成，减少了对现场操作的技术人员的业务水平的需求。无论是直接连接服务供应商提供的升级服务器进行升级，还是直接在客户现场进行升级，都比现有技术所采用的技术方案更快更节省资源。

Description

一种客户内部业务系统自动部署升级方法

技术领域

本发明属于计算机技术领域，尤其是一种客户内部业务系统自动部署升级方法。

背景技术

在现代化的大型金融企业内部，为执行内部业务沟通，需要部署专用的内部业务系统。伴随着企业的发展，业务的拓展，企业内各个业务系统的迭代开发，需要不停升级各个业务系统到目标版本，才能够让用户使用上最新的功能。需要注意的是，为了提高数据安全以及便于内部管控，大型金融企业内部的系统都是单独联网且与外网隔离设置。因此再在内部业务系统升级的过程中，需要由系统程序开发人员准备好升级所需要的各种文件：例如前端文件、后端程序包、配置文件、数据库sql脚本；然后准备上线文档用于说明操作步骤，企业的运维实施人员阅读此文档后根据文档内容进行配置并执行相应的程序。

但是在这个过程中，系统程序开发人员的写作水平决定了上线文档的质量。一旦上线文档文本质量过低会造成信息失真，运维实施人员无法读懂文本含义从而也无法实施升级工作。即便运维实施人员完全读懂了上线文档的内容，其自身的技能水平也可能造成升级失败。尤其是在各种中间件的安装问题及安装过程中出现的故障排查方面，运维实施人员可能会面对很多技术上的知识盲区。即便运维实施人员完成了系统的升级，由于整个过程为人工操作，整体速度非常慢，也容易出错，从而影响客户满意度。而且对于大型企业而言，需要升级的业务功能多，因此需要聘用大量的运维实施人员，增加公司运营成本。

现有技术中对于软件自动安装或自动升级的专利有不少。例如专利号为CN201010282302.4的专利《一种自动安装应用软件的方法和系统》中就公开了一种自动安装应用软件的方法和系统。该方法包括：S1、启动源操作系统；S2、所述源操作系统启动系统识别程序以自动识别目标操作系统的系统信息；S3、所述源操作系统基于所述目标操作系统的系统信息启动自动配置程序进行目标应用软件安装的系统适应自动配置，进而产生目标配置文件；S4、所述源操作系统基于所述目标配置文件，启动所述目标应用软件的安装程序进而自动安装所述目标应用软件到所述目标操作系统中。实施该发明的自动安装应用软件的方法和系统，用户无需了解复杂的计算机知识，就能够正确地自动安装应用软件。更进一步地，该发明的方法和系统还可以用于包括多种目标操作系统的目标设备，进行正确地自动安装应用软件。但是这样方案是在基于操作系统等环境信息下安装单一应用软件，并不是针对超大规模的业务系统进行涉及前端 、后端 、微服务 、中间件 、缓存 、数据库 、消息队列 、文件系统等各种功能的完整部署。因此这样的技术方案无法涉及到整体的系统配置中。

现有技术中还公开过类似于专利号CN201010572412.4的发明专利《计算机专用软件更新的自动配置》。该发明专利记载的软件更新系统自动对执行过程控制系统的计算机主机进行过程控制系统的提供商批准的软件更新的配置。软件更新系统包括客户端应用程序以及服务器应用程序，其中的客户端应用程序生成计算机主机可用的软件更新请求并且启动自动配置对主机的软件更新，服务器应用程序响应该请求向客户端应用程序提供软件更新数据。

但是这样的方案是基于客户端/服务器模式，需要在客户现场发出网络请求去访问远程的服务器，客户端再执行完成升级。这一点受制于很多用户，尤其是金融领域的用户的安全措施，有时候无法连接外网。即便连接外网，也需要依次下载多个版本升级软件，下载的软件包内容多，且有大量重复的数据下载，因此系统更新的效率低。

发明内容

为克服现有技术的不足及存在的问题，本发明提供一种客户内部业务系统自动部署升级方法。无论客户的系统是否连接外网，也无论客户内部维护人员的技术水平高低，均能实现高度自动化的复杂业务系统更新。

对此，本发明一种客户内部业务系统自动部署升级方法，首先获取业务系统已有的配置模板，具体方法为从业务系统的运行时配置中获得出配置模板，更新配置模板的格式，并将更新后的配置模板替换成现场运行时配置；基于更新后的模板化的运行时配置进行系统升级。

所述升级包括：对业务系统所在的部署环境进行检测和分析；基于配置模板更新运行时配置；获取发版文件，中间件升级时，将部署环境中业务系统现有的运行时配置和中间件相关的配置和发版文件的目录中配置文件的中间件部分进行比对，对比的结果包括新增、修改或删除三种状态，根据不同状况更新配置模板的值。之前已经存在的内容检测是否相同，相同的内容不用重复升级。不同的内容则需要删除原有的内容，复制新版本的内容。原先没有的文件则需要新建。原先有最后没有的内容直接删除。将这些信息全部放到配置模板中，执行发版文件中自带的数据库脚本。

回写配置，将配置信息发送到配置中心，使其生效并根据升级前后两个版本的静态目录比对识别具体升级所需的前端程序文件和后端程序文件；根据配置准确下载所述升级所用文件后进行升级；升级完毕后对于部署环境再次进行健康检测，检测结果符合要求后将本次升级的配置模板进行保存。

简单的说，本发明核心包括三个动作：

1、从业务系统的运行时配置中获得出配置模板并将配置模板格式统一并更新；具体方法为：

获取部署环境中已有的配置模板；

解析已有的配置模板，检阅其中的配置格式；

当配置格式中的配置项为：“配置业务类别-配置数据库类型-配置数据库编号-配置值属性”结构时，判定其已经为更新后的配置模板；

否则将配置格式中的配置项修改为“配置业务类别-配置数据库类型-配置数据库编号-配置值属性”结构的配置模板。

这一步骤非常重要，因为客户升级的是大型的业务系统软件，功能复杂繁多。其中很多不同的功能都是由多个工作小组分别开发的。而不同的开发者在开发过程中，通常只考虑自己部分代码的一致性和逻辑性，无法和其它工作小组进行协调更不会考虑具体部署的问题。因此现有技术中常规的配置方式都是传统的key=value模式，在配置文件中根据关键字取值。key是关键字，value是值。因此现有的模式下没有本发明所述的自动部署考虑。不同小组里使用的KEY不统一，各有各的风格，杂乱无章无法。而本发明通过统一的配置项设置，确保了后期的自动配置工作可以实现。对于之前并非统一的键值也可以通过工具将其统一。

2、在前一步骤基础上，利用配置模板直接实现中间件的自动调整。这一点在具体实施方式中再进一步说明。

3、还能实现快速跨版本升级，具体包括：

数据库端通过脚本SQL根据版本号依次进行模拟升级，直到目标版本；此时直接使用目标版本的脚本和执行该脚本的前置必要脚本，忽略重复冗余或无效脚本；在这个过程中，只需记录中间件发生的变化，并进行标记，无需真正根据配置模板执行。在这个过程中有些曾经加入后又被删除的内容也只是打上标记后取消。真正有效缩短了升级的流程。

前端程序和后端程序在升级过程中仅模拟部署，即在升级前记下当前版本，然后根据版本号依次记录每次升级时更新的文件，直到目标版本，根据记录对比获取实际发生变化的静态文件列表，从而下载这些静态文件物理部署最终版本。

优选的，所述模拟升级过程中将每次升级的配置模板以及静态文件部署状态通过快照的形式保存下来，且每次升级依靠上一次的升级的快照来作为参照，最终达到目标版本；在升级过程中保留所有的快照，升级完毕和健康状态检测完毕后，删除快照。

优选的，对业务系统所在的部署环境进行检测和分析具体包括：部署环境验证，确认是已认证的客户的业务系统所在的部署环境；版本探测：获取该部署环境中已有的业务系统的版本信息；业务系统升级前健康探测：确认已有的业务系统应用正常。环境判定具有两层作用，一是站在服务供应商立场，确保进行升级工作的是指定的设备，避免超范围升级给服务供应商造成损失。同时也验证当前的部署环境是否符合系统升级的要求，确保升级顺利。

优选的，在业务系统升级前的健康探测过程中，通过日志文件获取系统中已知故障，将已知故障数字化后，对比本次升级部署的文件中的自动修复程序性能，从而准确判断部署环境的健康程度，当健康程度未达到要求时，修复已知故障后再进行升级。这一点非常关键，现有技术中也有对网络状况的检测，同时对于网络状况不良的部署环境，往往是先要确保部署环境没有存在故障才能进行系统的升级。但是由于客户需要升级的业务系统所在部署环境往往是已经使用了很长一段时间的，各个机器的性能和运行状态确实无法保障一直处于健康状态。这样的情况下，最优的解决方式就是更换硬件系统。但是那样又会带来非常高昂的成本，还需要一定的配置时间，影响业务系统升级的工作。相应的，现有技术中针对故障的自动处理软件也有长足的进步，因此在本发明中，在业务系统升级前健康探测过程中，对于发现已经存在的故障进行一个预估，如果服务供应商提供的工具中有能有效缓解这些问题，即便无法完全修复，只要判定不影响系统升级工作，即可认为该部署环境是健康的。尤其在一些使用年限较长的设备上，这样的设置能保障升级的顺利完成。

优选的，当部署环境中存在多个设备同时每台设备上还具有多个业务系统时，如果只需要升级其中部分业务系统，在完成配置模板更新的步骤以后，运行升级工具，填入需要升级的设备信息，然后选择该设备上需要升级的具体业务系统，工具会自动探测当前运行的各个业务系统的版本，技术人员选择其中需要升级的业务系统，并选择这些业务系统需要升级到的版本号，在顺利通过健康检测后，升级工具开始逐个升级每个业务系统。这个过程由服务供应商提供的相应升级工具完成，便于技术人员在相对复杂的升级环境中管控整个升级过程。

优选的，在获取发版文件后，还包括对业务系统的部署环境进行负载均衡；在部署开始前中断业务系统中中间件和后端程序的流量；在升级过程中进行监测，确保中间件和后端程序没有任何流量产生；升级完毕且在部署环境健康探测结束后，开放这些应用流量。因为在系统升级过程中，尽可能的希望系统资源能分配给配置中心。但是由于本发明涉及的客户所采用的业务系统通常都不能停止工作，因此需要进行负载均衡。负载均衡通过连接在配置中心的网关实现，具体操作是面向动态流量进行切割，拦截。通过缓存对数据库返回避免在升级过程中其它业务占用过多流量进来。同时在请求前端的，暂时无视流量动态请求，但是也不是简单无视这些请求，而是通过前端程序内设的缓存将前端请求暂时记录并挂起，最终在系统升级完毕后重新放开流量后，根据请求的顺序第一时间处理相应的请求。这样对业务系统的用户而言，应用体验更好，而且能相对顺利过渡系统刚升级完毕后较为混乱的时间段。

优选的，当部署环境无法连接外网时，通过移动存储介质更新配置模板，再根据配置模板从服务供应商处复制对应静态文件。通过这样的方式，在部署环境无法连接外网的情况下，升级通过两步实现。第一步是通过操作配置中心获取本次升级的配置模板，再利用配置模板到服务供应商处获取对应静态文件。虽然分为两步，但是总的升级时间和需要传输的数据均少于现有技术中的直接部署。这样的方式还可以减少外部程序进入无网络连接内部系统的总量。

优选的，还包括故障处理步骤，在升级过程中，作业日志实时展现在配置中心的用户界面上，在相应的各个检测阶段一旦发现问题，则停止作业，且将升级工具暂停在当前阶段，并触发报警；

技术人员通过日志判定出现故障的步骤，根据日志记录和部署环境的实际情况，选择以下几种措施：

1）对于已知的问题，人工修复完毕后继续进行部署工作；

2）对于未知问题或存在高危度的问题，回滚升级步骤，回滚步骤为恢复到前一个快照记录的状态并停止升级。

这样即便出现了故障也不会导致整个业务系统崩溃，起到了尽可能的维护效果。尤其是快照中记载的前一个状态也是可实现的状态，如果真的最终出现了无法快速处理的故障，也可以先采用低于目标版本的程序暂时先使用，等到故障排除后继续升级。

和现有技术相比，本发明所记载的方法实现了配置模板的自动生成，减少了对现场操作的技术人员的业务水平的需求。因为现有技术中即便是软件能实现一键升级，但是该软件的相关环境还是需要手动设置。本类软件不像windows操作系统一样，在常规的设备上都能安装，而是要布设在不同类型的不同环境下的各种设备上。这样的自动配置方式是现有技术中均无法实现的。所以无论是直接连接服务供应商提供的升级服务器进行升级，还是直接在客户现场进行升级，都比现有技术所采用的技术方案更快更节省资源。此外本发明是基于配置驱动的方式来自动比对分析，优于现有的完全人工配置的系统升级方案。

附图说明

图1是本发明客户内部业务系统自动部署升级方法的整体系统框图；

图2是本发明客户内部业务系统自动部署升级方法的工作流程示意图；

图3是现有技术中配置模板中配置格式示意图；

图4是本发明客户内部业务系统自动部署升级方法所采用的配置格式的示意图；

图5是本发明客户内部业务系统自动部署升级方法的在可连接外网的配置环境下的配置示意图。

具体实施方式

为了便于本领域技术人员的理解，下面结合附图和具体实施例对本发明创造作进一步描述。

本发明的软件部署可以用于业务系统的初次安装或者升级。其优点主要体现在升级过程中可以根据配置文件有目标性的选择需要下载的静态文件，减少实际下载的文件数量。同时还能通过虚拟升级的方式进行快速跨版本升级。这里首先要强调的是，本发明涉及的业务系统的安装不仅仅是安装软件。其整体过程中包含了根据部署环境设置配置模板，然后据此进行中间件升级、后端升级、前端升级。本发明中的中间件指的就是数据库、缓存、消息队列。后端程序指的是后台运行的支持性程序例如java程序。而前端指的是例如静态页面这些用户交互界面。这三者的升级也是要基于中间件-后端程序-前端程序的顺序实现。现有技术中这些步骤完全需要人工配置，而且下载的安装包里包含了全部的内容，内容冗余，升级效率低下。

实际现有技术中人工点击按钮触发自动化安装缓存集群的工具是相当成熟的。例如Redis Manager 就是一款Redis 一站式管理平台工具。支持集群（cluster、master-replica、sentinel）的监控、安装（除sentinel）、管理、告警以及基本的数据操作功能主要能实现：

集群监控：支持监控 Memory、Clients 等 Redis 重要指标；可实时查看 RedisInfo、Redis Config 和 Slow Log；

集群创建：支持 Docker、Machine、Humpback方式；

集群管理：支持节点Forget、Replicate Of、Failover、Move Slot、Start、Stop、Restart、Delete、修改配置等功能；

集群告警：支持 Memory、Clients 等指标(同监控指标)，支持邮件、企业微信APP、企业微信Webhook、钉钉告警；

工具箱：支持 Query、Scan 以及基本的数据操作。

但是这样的工具还是人工点击按钮触发自动化安装缓存集群的工具，如果直接使用，依然会存在docker镜像下载后使用时闪退，run容器的脚本也需要手动设置，否则不加数据库配置的启动不了。如果数据库配置设置不当，也可能无法识别数据库url后面的参数，直接报错。

而本发明采用的基于更新后的模板化的运行时配置进行系统升级，是利用现有的工具实现按模板自动配置，免去了人工设置的步骤。

如图1所示，本发明通常应用于银行或券商的内部系统升级。在向系统供应商购买内部业务系统后，经过一段时间的使用后随着业务需求的增加，对系统进行升级。系统中每一台设备都需要先获取业务系统已有的配置模板，具体方法为从业务系统的运行时配置中获得配置模板，更新配置模板的格式，并将更新后的配置模板替换成现场运行时配置；然后基于更新后的模板化的运行时配置进行系统升级。

如图2所示，为本发明的基本流程，在内部系统中指定主机作为配置中心，进行内部网络的系统升级工作，配置中心和需要升级的设备可以是同一台设备。首先对业务系统所在的设备的部署环境进行检测和分析；获取业务系统所在的设备配置模板，校验所述配置模板，将配置模板格式统一并更新。需要注意的是将配置模板格式统一并更新并不是在配置模板阶段的更新配置模板的格式的作业的重复。由于在更新配置模板的格式过程中，只是从正在运行的业务系统的运行时配置中获得配置模板，并调整配置模板的格式，因此此时需要对运行时配置做一个备份。这样万一修改配置模板格式后，再将更新后的配置模板替换成现场运行时配置时一旦出现问题，可以及时修正。此后在升级过程中对业务系统所在的设备的部署环境进行检测和分析；获取业务系统所在的设备配置模板时，则不仅限于运行时配置的内容。但是此时更新已经有之前的操作作为保障，基本不会出现问题，可以确保更新的可靠性。

在模板配置完成后基于本次升级工作获取发版文件，并对发版文件进行校验；预备技术组件：调整中间件，根据更新后的配置模板对可能用到的脚本进行升级；通过脚本对配置中心进行配置回写；此处配置回写是为了将一台设置完毕的设备中的配置模板作为样板，供其余类似设备使用。这样能减少后期其它设备升级的时间。回写完毕后通过需要升级的设备本地的文目录件和发版文件中的文件目录进行对比，准确找到需要具体升级的后端程序文件和前端程序文件。依次下载并升级后端程序和前端程序；升级完毕后对于升级后的部署环境进行健康探测。符合健康要求则说明改设备升级成功。

现有技术中对此通常有两种方案，一种是将作为配置中心的内网的主机连接到系统供应商的服务器上，根据版本信息下载对应的升级包进行升级。另一种是针对无法连接外网的部署环境中，需要利用存储设备将升级需要用到的配置工具，静态文件等，完整的复制到企业的内部系统中进行安装工作。以下根据这两种不同情况分别以具体案例进行说明。

实施例1：可以连接外网的部署环境。通常这样的环境中也不是所有主机都连接外网，而是由一台带有防火墙的管理主机连接外网，在该管理主机上设置配置中心，从而服务网络内连接的所有设备的升级。如图5所示本实施例是对于某银行内部系统进行升级，该系统安装在该银行某支行的内网上，仅通过一台主机连接到外网。此时将所述可连接外网的主机作为配置中心。

在此环境下，安装配置中心的主机可以直接连接上系统供应商的升级服务器。升级服务器先发送配置工具，对业务系统所在的部署环境进行检测和分析。所述检测和分析过程包括部署环境验证，用于确认是已认证的客户的业务系统所在的部署环境。这样是为了避免将业务升级在未购买服务的设备上，给系统供应商带来损失。版本探测：获取该部署环境中已有的业务系统的版本信息；从而可以判断系统升级的工作量。以及业务系统升级前健康探测：确认已有的业务系统应用正常，确保接下来的升级工作将在一个健康的环境下实现，避免由于环境问题导致的升级失败。

现有技术中对于环境健康的标准各有不同，通常认为，为保险起见需要完全消除掉已有的故障，才能确保升级的顺利。但是在本实施例中，整个网络已经搭设了10余年，相应的设备较为陈旧。整个系统在负载较高的情况下，有时间隔20-30分钟就会发生断开网络连接的情况。如果对设备进行更新成本过高而且会延迟系统升级的期限。在业务系统升级前健康探测过程中，通过日志文件获取系统得知了此故障。由于网络连接是保障升级顺利的必要前提，因此在系统供应商的升级服务器上预备了网络维护工具。通过该网络维护工具可以在网络断开后10秒内自动进行再连接。经过测试验证经过这样的再连接后，这样的网络断开不会影响业务系统的升级工作。因此虽然无法解决网络断开的问题，但还是可以判定部署环境的健康程度达到要求。

本次升级过程中部署环境中有4台设备需要升级，每台设备均为将协同办公系统从1.5版本升级到3.0版本。如果只需要升级其中部分业务系统，技术人员在配置中心中填入需要配置的设备信息，然后选择该设备上对应的业务系统，配置中心自动探测该设备上当前运行的各个业务系统的版本，在用户界面上显示当前业务系统整体运行为健康的版本，技术人员手动选择目标升级版本。

接着针对每台设备获取业务系统所在的部署环境进行检测和分析；获取业务系统已有的配置模板，具体方法为从业务系统的运行时配置中获得出配置模板，更新配置模板的格式，并将更新后的配置模板替换成现场运行时配置；所述升级包括：对业务系统所在的部署环境进行检测和分析；基于配置模板更新运行时配置；获取发版文件，中间件升级时，将部署环境中业务系统现有的运行时配置和中间件相关的配置和发版文件的目录中配置文件的中间件部分进行比对，更新配置模板的值；执行发版文件中自带的数据库脚本；

回写配置，将配置信息发送到配置中心，使其生效并根据升级前后两个版本的静态目录比对识别具体升级所需的前端程序文件和后端程序文件；根据配置准确下载所述升级所用文件后进行升级；升级完毕后对于部署环境再次进行健康检测，检测结果符合要求后将本次升级的配置模板进行保存。此处的部署是在单独一台设备上实现的，因此对该设备上的配置模板进行保存，其中大部分设置可以沿用到其它同型号的设备上。

以上过程中将配置模板格式统一并更新的具体方法为：根据现场运行时配置获取部署环境中已有的配置模板。运行时配置是指包含本地文件的可重载配置。

解析已有的配置模板，检阅其中的配置格式；发现为图3所示的KEY-VALUE形式。因此需要对配置格式进行修改。将配置格式中的配置项修改为如图4所示的“配置业务类别-配置数据库类型-配置数据库编号-配置值属性”结构的配置模板。

图中形如{ middleware / business /...} . {mysql/redis/...} . {0/1/2...} . {ip/port}前缀格式的配置项，分别说明了配置业务类别为中间件或是业务项或是其它；配置数据库类型为mysql或是redis或是其它；配置数据库编号指的是同时存在多个同类数据库时，具体的数据库编号；配置值属性为ip地址或是端口号或是其它。通过这样的配置结构更新了配置模板。

由于本发明是基于配置驱动，以运行时以配置模板为中心完成整个方案升级，所以实施本发明的前提是现场运行时部署环境的配置已经按照所述的实施改造完毕才可以，如果未能完成改造，也无法使用本方案完成任意业务系统的升级。

在获取发版文件步骤后，还包括对业务系统的部署环境进行负载均衡；在部署开始前通过网关切断冗余应用流量；升级完毕且在部署环境健康探测结束后再次进行负载均衡，开放这些应用流量。

本实施例中从业务系统从版本1.5升级到3.0，中间间隔了多个中间版本。因此可以采用跨版本加速升级方法，具体包括：

数据库端通过脚本SQL根据版本号依次进行模拟升级；即每次只在配置文件中进行修改，记载需要采用的脚本，但是并不执行该脚本直到目标版本。此时直接使用目标版本的脚本和执行该脚本的前置必要脚本，忽略重复冗余或无效脚本。例如在2.0版本时增加了一个功能，但是在2.2版本时又将该功能取消了。因此在最终升级配置时，对应此功能的相关脚本无需执行。

同样的，前端程序和后端程序在升级过程中仅模拟部署，即在升级前记下当前版本，然后根据版本号依次记录每次升级时更新的文件，直到目标版本，根据记录对比获取实际发生变化的静态文件列表，从而下载这些静态文件物理部署最终版本。这样就能节省大量的资源和时间。

升级完毕后，需要对于升级后的部署环境进行健康探测。探测完毕后没有出现问题就说明系统升级完成。

在这个案例中，原先升级这样工作量的业务系统，需要下载一整套系统文件，共计3G多的升级包，下载、部署、检测花费的总体时间大于5小时。而通过本发明采用的技术方案，最终实际下载的程序大约在600-700M即可满足升级需求，同时升级的时间也控制在半小时左右。这个效果的提升是非常显著的。

实施例2：本实施例同样是对于某银行内部系统进行升级，该系统安装在该银行某支行的内网上，仅通过一台主机连接到外网。在本实施例中，整个网络已经搭设时间更久，相应的设备较为陈旧。整个系统在负载较高的情况下，有时间隔5分钟就会发生断开网络连接的情况。在业务系统升级前的健康探测过程中，通过日志文件获取系统得知了此故障。由于网络连接是保障升级顺利的必要前提，虽然在系统供应商的升级服务器上预备了网络维护工具。但是经过测试验证经过这样的再连接后，这样的网络断开频率还是过于频繁，会影响业务系统的升级工作。因此判定部署环境的健康程度无法达到升级的要求，但是可以满足日常应用的要求。因此在这样的场景下可以通过经过验证的可移动存储介质来进行业务系统的升级。

需要注意的是，如果判定部署环境的健康程度为无法达到升级的要求，也无法满足日常应用的要求时，需要记录不合格项待人工处理。这种情况下结束升级工作。

本次升级过程中部署环境中有2台设备需要升级，每台设备均为将身份管理系统从2.0版本升级到2.5版本。因为这样的升级不连接外网，因此设备本身就作为配置中心。此时需要手动对每台设备获取业务系统所在的配置模板进行配置。校验所述配置模板，并将配置模板格式统一并更新；获取发版文件，并对发版文件进行校验；预备技术组件：调整中间件，根据更新后的配置模板对可能用到的脚本进行升级；通过脚本对配置中心进行配置回写；回写完毕后依次升级后端程序和前端程序；升级完毕后对于升级后的部署环境进行健康探测。

其中将配置模板格式统一并更新的具体方法和实施例1一样。本实施例中从业务系统从版本2.0升级到2.5，中间间隔了多个中间版本。主机中最后获取根据配置模板，将配置模板存储在移动存储设备中。通过物理方式，例如人为携带的方式将该移动存储设备接入系统供应商的升级服务器。这里依照配置文件在系统供应商的升级服务器上通过脚本SQL根据版本号依次进行模拟升级；即每次只在配置文件中进行修改，记载需要采用的脚本，但是并不执行该脚本直到目标版本。此时直接使用目标版本的脚本和执行该脚本的前置必要脚本，忽略重复冗余或无效脚本。前端程序和后端程序在升级过程中仅模拟部署，即在升级前记下当前版本，然后根据版本号依次记录每次升级时更新的文件。模拟升级过程中将每次升级的配置模板以及静态文件部署状态通过快照的形式保存下来，且每次升级依靠上一次的升级的快照来作为参照，最终达到目标版本；在升级过程中保留所有的快照。

最后根据静态文件列表，从系统供应商的升级服务器下载这些静态文件到移动存储设备上。再次将移动存储设备连接到需要升级的主机上，将自动根据配置文件和静态文件完成最终的升级工作。

在复制过程中，根据文件目录对比发现，其中有一台设备中其所有者已经根据需求单独安装过某个功能组件，而这个功能组件在新版本的业务系统中也被添加了进来。这一情况在文件目录对比时即可发现，在最后该设备实际升级的过程中，对应这个功能组件的安装程序就不必重复下载，节省了升级的时间和空间。

在升级过程中，作业日志实时展现在设备的用户界面上，在相应的各个检测阶段一旦发现问题，则停止作业，且将升级工具暂停在当前阶段，并触发报警；

技术人员通过日志判定出现故障的步骤，根据日志记录和部署环境的实际情况，选择以下几种措施：

1）对于已知的问题，人工修复完毕后继续进行部署工作；

2）对于未知问题或存在高危度的问题，回滚升级步骤，恢复到上一个部署环境健康的阶段。

这样就能实现业务系统的自动升级。

虽然本发明以较佳实施例揭露如上，但并非用以限定本发明实施的范围。任何本领域的普通技术人员，在不脱离本发明的发明范围内，当可作些许的改进，即凡是依照本发明所做的同等改进，应为本发明的范围所涵盖。在本说明书的描述中，参考术语“一个实施例/方式”、“一些实施例/方式”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例/方式或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例/方式或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例/方式或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例/方式或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例/方式或示例以及不同实施例/方式或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

本领域的技术人员应当理解，上述实施方式仅仅是为了清楚地说明本公开，而并非是对本公开的范围进行限定。对于所属领域的技术人员而言，在上述公开的基础上还可以做出其它变化或变型，并且这些变化或变型仍处于本公开的范围内。

Claims (10)

1.一种客户内部业务系统自动部署升级方法，其特征在于，首先获取业务系统已有的配置模板，具体方法为从业务系统的运行时配置中获得配置模板，更新配置模板的格式，并将更新后的配置模板替换成现场运行时配置；基于更新后的模板化的运行时配置进行系统升级；

所述升级包括：对业务系统所在的部署环境进行检测和分析；基于配置模板更新运行时配置；获取发版文件，中间件升级时，将部署环境中业务系统现有的运行时配置和中间件相关的配置和发版文件的目录中配置文件的中间件部分进行比对，更新配置模板的值；执行发版文件中自带的数据库脚本；

回写配置，将配置信息发送到配置中心，使其生效并根据升级前后两个版本的静态目录比对识别具体升级所需的前端程序文件和后端程序文件；根据配置准确下载所述升级所用文件后进行升级；升级完毕后对于部署环境再次进行健康检测，检测结果符合要求后将本次升级的配置模板进行保存。

2.根据权利要求1所述的一种客户内部业务系统自动部署升级方法，其特征在于， 还能实现跨版本加速升级方法，具体包括：

数据库端通过脚本SQL根据版本号依次进行模拟升级，直到目标版本；此时直接使用目标版本的脚本和执行该脚本的前置必要脚本，忽略重复冗余或无效脚本；

前端程序和后端程序在升级过程中仅模拟部署，即在升级前记下当前版本，然后根据版本号依次记录每次升级时更新的文件，直到目标版本，根据记录对比获取实际发生变化的静态文件列表，从而下载这些静态文件物理部署最终版本。

3.根据权利要求2所述的一种客户内部业务系统自动部署升级方法，其特征在于，所述模拟升级过程中将每次升级的配置模板以及静态文件部署状态通过快照的形式保存下来，且每次升级依靠上一次的升级的快照来作为参照，最终达到目标版本；在升级过程中保留所有的快照，升级完毕和健康状态检测完毕后，删除快照。

4.根据权利要求1所述的一种客户内部业务系统自动部署升级方法，其特征在于，将配置模板格式统一并更新的具体方法为：

从业务系统的运行时配置中获取配置模板；

解析已有的配置模板，检查其中的配置格式；

当配置格式中的配置项为：“配置业务类别-配置数据库类型-配置数据库编号-配置值属性”结构时，判定其已经为更新后的配置模板；

否则将配置格式中的配置项修改为“配置业务类别-配置数据库类型-配置数据库编号-配置值属性”结构的配置模板。

5.根据权利要求1所述的一种客户内部业务系统自动部署升级方法，其特征在于，对业务系统所在的部署环境进行检测和分析具体包括：部署环境验证，确认是已认证的客户的业务系统所在的部署环境；版本探测：获取该部署环境中已有的业务系统的版本信息；业务系统升级前健康探测：确认已有的业务系统应用正常。

6.根据权利要求5所述的一种客户内部业务系统自动部署升级方法，其特征在于，在业务系统升级前的健康探测过程中，通过日志文件获取系统中已知故障，将已知故障数字化后，对比本次升级部署的文件中的自动修复程序性能，从而准确判断部署环境的健康程度，当健康程度未达到要求时，修复已知故障后再进行升级。

7.根据权利要求1所述的一种客户内部业务系统自动部署升级方法，其特征在于，当部署环境中存在多个设备同时每台设备上还具有多个业务系统时，如果只需要升级其中部分业务系统，在完成配置模板更新的步骤以后，运行升级工具，填入需要升级的设备信息，然后选择该设备上需要升级的具体业务系统，工具会自动探测当前运行的各个业务系统的版本，技术人员选择其中需要升级的业务系统，并选择这些业务系统需要升级到的版本号，在顺利通过健康检测后，升级工具开始逐个升级每个业务系统。

8.根据权利要求1所述的一种客户内部业务系统自动部署升级方法，其特征在于，在获取发版文件后，还包括对业务系统的部署环境进行负载均衡；在部署开始前，中断业务系统中中间件和后端程序的流量；在升级过程中进行监测，确保中间件和后端程序没有任何流量产生；升级完毕且在部署环境健康探测结束后，开放这些应用流量。

9.根据权利要求1所述的一种客户内部业务系统自动部署升级方法，其特征在于，当部署环境无法连接外网时，通过移动存储介质更新配置模板，再根据配置模板从服务供应商处复制对应静态文件。

10.根据权利要求1所述的一种客户内部业务系统自动部署升级方法，其特征在于，还包括故障处理步骤，在升级过程中，作业日志实时展现在配置中心的用户界面上，在相应的各个检测阶段一旦发现问题，则停止作业，且将升级工具暂停在当前阶段，并触发报警；

技术人员通过日志判定出现故障的步骤，根据日志记录和部署环境的实际情况，选择以下几种措施：

1）对于已知的问题，人工修复完毕后继续进行部署工作；

2）对于未知问题或存在高危度的问题，回滚升级步骤，回滚步骤为恢复到前一个快照记录的状态并停止升级。

Images