一种复杂服务端应用系统的升级系统及方法与流程

本发明涉及运维技术领域，特别涉及一种复杂服务端应用系统的升级系统及方法。

背景技术：

随着云计算的推进，复杂服务端应用系统如何自动化的升级已经成为运维的难题。

参见图1示出的现有复杂服务端应用系统典型结构，现有复杂服务端应用系统一般可以包括界面层、服务层、数据访问层和数据库层，每一层都可能是一组集群部署模式，当任何一个应用发生升级改造将影响整个结构。

现有复杂服务端应用系统的升级方式一般是人工手动升级，而系统结构复杂，必然导致工作量大，且升级效率低，容易出现错误。例如，每当业务需求发生变化或修复系统问题，相关服务器上的应用都需要升级，这时需要系统管理员对相关的应用服务器以及数据库服务器一一作升级工作。另外，由于是分层部署，应用之间又存在依赖关系，升级过程中需要考虑升级的顺序。如果升级过程中没有做好协调工作，很可能因为各层应用的程序版本不一致而导致系统无法正常使用。因此，如何实现复杂服务端应用系统的自动化升级，提高升级效率且升级有序是本领域需要解决的问题。

技术实现要素：

本发明的目的是提供一种复杂服务端应用系统的升级方法及系统，以实现复杂服务端应用系统的自动化升级，提高升级效率且升级有序。

为实现上述目的，本发明提供如下技术方案：

一种复杂服务端应用系统的升级系统，包括升级服务管理端和设置于各待升级应用的升级服务；

所述升级服务管理端用于接收并解析升级数据包，得到应用任务配置信息，生成应用任务信息列表，并根据应用类型，将所述应用任务信息列表中的各个应用类型节点进行排序；根据所述应用任务信息列表，以及接收的应用服务器配置信息和升级参数配置信息，生成包含各个升级子任务的应用升级任务列表；根据预设任务调度策略，依序从所述应用升级任务列表获取所述升级子任务，并分发所述升级子任务至相应的所述升级服务；

所述升级服务用于接收并执行所述升级子任务。

可选地，所述升级服务管理端包括解析模块和配置交互模块；

所述解析模块用于解压所述升级数据包，获取升级配置文件，生成所述应用任务信息列表，并根据应用类型，将所述应用任务信息列表中的各个所述应用类型节点进行排序；循环处理所述应用任务信息列表，获取所述应用任务配置信息和升级文件；根据所述应用任务信息列表，将与版本信息对应的所述升级文件打包生成应用升级包；

所述配置交互模块用于接收用户配置的所述应用服务器配置信息和所述升级参数配置信息。

可选地，所述升级服务管理端包括任务生成模块，用于生成升级任务节点，并为所述升级任务节点分配唯一标识id；根据预设任务生成规则，循环处理所述应用任务信息列表，基于所述应用服务器配置信息和所述升级参数配置信息，生成包含各个所述升级子任务的所述应用升级任务列表；将同属于同一所述待升级应用的所述升级子任务划分至同一任务组，将同属于一个应用任务的任务组划分至同一应用任务；

其中，每组所述任务组均包括测试子任务。

可选地，所述升级服务管理端包括任务调度模块，用于根据应用任务优先级高低，依序执行各个所述应用任务；

其中，所述应用任务包括一个或多个所述任务组，每个所述任务组包括一个或多个所述升级子任务以及所述测试子任务；每个所述应用任务的任务调度过程为：

分发所述测试子任务分发至相应的所述升级服务；

当所述测试子任务执行成功后，根据预设任务调度规则，分发所述升级子任务至相应的所述升级服务；

所述预设任务调度规则具体包括第一调度规则、第二调度规则和第三调度规则；所述第一调度规则为依次分发执行同一任务组的所述升级子任务；所述第二调度规则为并行分发同一任务组的所有的所述升级子任务，当同一任务组的所有所述升级子任务分发完成后，分发下一任务组的任务；所述第三调度规则为并行分发同一应用任务的所有所述升级子任务。

可选地，所述升级服务包括接收模块和执行模块；

所述接收模块用于比较所述升级子任务携带的版本信息与所述升级服务所在的所述待升级应用的版本信息，判断是否一致；若不一致，则接收失败，返回接收失败结果；

所述执行模块用于当所述升级子任务携带的版本信息与所述升级服务所在的所述待升级应用的版本信息一致时，执行所述升级子任务，并返回执行结果。

可选地，所述执行模块包括下载子模块、备份子模块、升级子模块、结果返回子模块和重启子模块；

所述下载子模块用于根据所述升级子任务，下载所述应用升级包；

所述备份子模块用于执行应用备份；

所述升级子模块用于解压所述应用升级包，获取升级文件，执行应用升级工作；调用数据库升级脚本文件，执行数据库升级工作；

所述结果返回子模块用于生成任务执行结果，并返回给所述升级服务管理端；

所述重启子模块用于根据所述升级子任务携带的重启配置信息，确定是否需要重启；如果需要重启，则调用重启脚本文件，重启应用，并返回重启信息给所述升级服务管理端。

可选地，所述升级服务还包括回滚模块，用于接收所述升级服务管理端发送的回滚请求；根据所述回滚请求，获取回滚信息；根据所述回滚信息，执行回滚操作。

可选地，所述升级服务管理端还包括任务状态监控服务，用于监控正在执行的升级任务和回滚任务；

所述任务状态监控服务包括第一监控模块和第二监控模块；

所述第一监控模块用于监控正在执行的所述升级任务，根据所述升级任务的执行时间与第一时间阈值的大小，更新所述升级任务的状态为第一预设状态；

所述第二监控模块用于监控所述回滚任务，根据所述回滚任务的执行时间和第二时间阈值的大小，更新所述回滚任务的状态为第二预设状态。

可选地，所述升级服务管理端还包括升级日志查看模块和升级任务查询模块；

所述升级任务查询模块用于根据查询指令，查找并显示相应任务信息；

所述升级日志管理模块用于根据日志查询或日志下载指令，显示相应升级日志信息或下载相应升级日志。

一种复杂服务端应用系统的升级方法，应用于任一项所述的复杂服务端应用系统的升级系统，该方法包括：

升级服务管理端接收并解析升级数据包，得到应用任务配置信息，生成应用任务信息列表，并根据应用类型，将所述应用任务信息列表中的各个应用类型节点进行排序；根据所述应用任务信息列表，以及接收的应用服务器配置信息和升级参数配置信息，生成包含各个升级子任务的应用升级任务列表；根据预设任务调度策略，依序从所述应用升级任务列表获取所述升级子任务，并分发所述升级子任务至相应的所述升级服务；

升级服务接收并执行所述升级子任务。

本发明所提供的一种复杂服务端应用系统的升级系统及方法，通过升级服务管理端接收并解析升级数据包，得到应用任务配置信息，生成应用任务信息列表，并根据应用类型，将应用任务信息列表中的各个应用类型节点进行排序；根据应用任务信息列表，以及接收的应用服务器配置信息和升级参数配置信息，生成包含各个升级子任务的应用升级任务列表；根据预设任务调度策略，依序从应用升级任务列表获取升级子任务，并分发升级子任务至相应的升级服务；升级服务接收并执行升级子任务。本申请根据应用类型确定升级子任务的优先级，再根据优先级的高低和任务调度策略进行分发任务，进而协调各个应用的有序升级，且升级任务可配置，实现了复杂服务端应用系统的自动化升级，相较于人工升级，其效率较高，准确性较好。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为现有复杂服务端应用系统典型结构示意图；

图2为本发明实施例提供的复杂服务端应用系统的升级系统的结构示意框图；

图3为本发明实施例提供的升级配置文件结构示意图；

图4为本发明实施例提供的服务器配置文件结构示意图；

图5为本发明实施例提供的应用类型配置文件结果示意图；

图6为本发明实施例提供的升级任务信息文件结构示意图；

图7为本发明实施例提供的一次升级任务的示意图；

图8为本发明实施例提供的任务状态转换说明示意图；

图9为本发明实施例提供的个税系统停机升级示意图；

图10为本发明实施例提供的复杂服务端应用系统的升级方法的流程示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参考图2，图2为本发明实施例提供的复杂服务端应用系统的升级系统的结构示意框图，该升级系统包括升级服务管理端21和设置于各待升级应用的升级服务22；

升级服务管理端21用于接收并解析升级数据包，得到应用任务配置信息，生成应用任务信息列表，并根据应用类型，将应用任务信息列表中的各个应用类型节点进行排序；根据应用任务信息列表，以及接收的应用服务器配置信息和升级参数配置信息，生成包含各个升级子任务的应用升级任务列表；根据预设任务调度策略，依序从应用升级任务列表获取升级子任务，并分发升级子任务至相应的升级服务；

升级服务22用于接收并执行升级子任务。

可以理解，上述升级数据包为用户上传至升级服务管理端的，用户具体通过升级服务管理端提供的导入界面将相应的升级数据包导入至升级服务管理端。其中，升级数据包可以以压缩文件形式存在，例如为zip文件。

升级数据包可以包括一次升级的所有文件，至少可以包括升级脚本文件app_update.xml、数据库升级脚本文件、升级说明文件readme.txt、升级文件以及升级配置文件updateconfig.xml。升级说明文件包括应用的升级说明，升级配置文件包括所需升级应用的基本信息。

为更好地介绍升级配置文件updateconfig.xml，请参见图3示出的本发明实施例提供的升级配置文件结构示意图。升级配置文件中可包括预先配置好的应用任务节点、任务名称、应用类型、应用根目录、旧版本信息、新版本信息、更新说明以及更新方式(是否停机升级)等相关信息。

上述应用任务配置信息可以包括应用类型信息、表征升级后是否重启的信息、是否需要升级数据库。

应用服务器配置信息和升级参数配置信息均可以是人为配置。其中，具体可以通过服务器管理界面勾选、设置相应的服务器信息，然后系统会相应地更新应用服务器信息。

升级参数配置信息可以包括升级模式、最大升级时间、最大回退时间等信息。升级模式包括手动升级和自动升级，手动升级指的是升级任务手动触发，自动升级指的是升级任务完全由系统自动完成。最大升级时间指的是超出该时间则认为升级任务执行失败，且该时间当次任务有效。

应用服务器配置信息和升级参数配置信息都有相应的默认值，例如，最大升级时间的系统默认值为10min，用户可以根据需求确定是否修改应用各配置信息的默认值。

升级服务管理端在接收到用户配置的应用服务器配置信息后，会相应地更新服务器配置文件serverconfig.xml。参见图4示出的服务器配置文件结构示意图，该服务器配置文件包括服务器id、服务器名称、服务器ip、服务器端口、应用类型等相关信息。

本实施例中，升级服务管理端可以包括解析模块和配置交互模块；解析模块用于解压升级数据包，获取升级配置文件，生成应用任务信息列表，并根据应用类型，将应用任务信息列表中的各个应用类型节点进行排序；循环处理应用任务信息列表，获取应用任务配置信息和升级文件；根据应用任务信息列表，将与版本信息对应的升级文件打包生成应用升级包；配置交互模块用于接收用户配置的应用服务器配置信息和升级参数配置信息。

可以理解，根据应用类型，将应用任务信息类别中的各个应用类型节点进行排序，即根据应用类型，将后续生产的升级子任务进行排序，确定每个任务的优先级和升级的先后顺序。

根据各个待升级应用的应用类型，预先设定各个应用类型的优先级。然后，即可根据各升级子任务对应的待升级应用的优先级，确定该任务的优先级。

例如，可以预先设定a类应用优先级最高，b类应用次之，c类应用次次之。则a类应用的升级子任务的优先级最高，b类应用的升级子任务的优先级次之，c类应用的升级子任务的优先级次次之。

具体地，下面将结合图3和图4对解析和配置过程作进一步介绍。其中，解析过程具体为：

生成一个唯一标识guid，在应用的更新目录下以该guid为名称建立空文件夹；

解压升级数据包，并将解压后的内容存放至该空文件夹所在目录；

读取得如图3所示的升级配置文件updateconfig.xml，得到其中的应用任务<apptask>节点信息，生成apptask信息列表，并根据应用类型的优先级，将apptask信息列表中的<apptype>节点进行排序；其中，应用类型的优先级可以通过读取如图5示出的应用类型配置文件apptypecofig.xml获取，更具体地，各个应用类型的优先级以apptypecofig.xml中的<priority>节点为准；

循环处理apptask应用任务信息列表，更具体地，根据apptask信息中的应用根目录节点，检查对应的文件目录是否存在，如果不存在则返回错误信息，如果存在则继续解析；

检查应用根目录下是否存在readme.txt文件，如果不存在返回错误信息，如果存在则继续处理；

根据apptask信息中的<apptype>节点的内容从如图4所示的apptypeconfig.xml文件中找到对应的应用大类信息；

检查应用根目录下的升级文件，如果发现升级文件中有配置文件，表示升级完成后要重载配置文件；如果发现升级文件中包含类文件、jar包、更新后需重启服务的文件(如web.xml文件，这种文件可能存在多个，通过系统参数指定)，则表示该升级完成后要重启应用；其它情况则表示升级完成后无需其它操作；

检查应用的updatescripts目录，如果目录下有database目录，那么要确保该目录下要同时存在database_update.sql、database_rollback.sql文件，如果缺少任一个则返回错误信息，否则在updatecontent中加入database标志表示该任务需要升级数据库；然后在updatecontent节点中加入app标志表示该任务需要升级应用文件；其次检查应用的updatescripts目录，如果该目录下存在app_update.xml脚本，则在updatecontent节点中增加appshell标志表示该任务需要执行应用升级脚本；

根据apptask信息中的应用根目录信息与版本信息，将对应的升级文件进行打包生成应用升级包，文件名格式为应用根目录_版本信息.zip，并将应用升级包的包名记入apptask信息中。

升级数据包解析后，用户则可进行相应的应用服务器配置和升级参数配置。其中，应用服务器的配置需要相应的更新应用服务器配置文件，其更新的过程具体如下：

读取serverconfig.xml中的所有流量控制器信息；

循环处理流量控制器信息；

取得主流量控制器信息，根据流量控制器的ip地址与端口设置，从流量控制器中获取该控制器管理的应用服务器信息列表；

如果从主流量控制器中获取信息失败，则取得备份流量控制器信息，从备份流量控制器信息中取得应用服务器信息列表；

如果从备份流量控制器获取应用服务器信息也失败，则返回错误信息，此时，可以提示用户“从xxx流量控制器获取应用服务信息失败，不能继续执行升级工作”等相关信息；

如果取得应用服务器列表，则根据所属省份与ip地址逐个检查列表中的服务器信息在serverconfig.xml中是否存在，如果不存在则把加该服务器信息加入到serverconfig.xml中，同时为该服务器设置应用类型。应用类型设置规则可以为：根据流量控制器所属税务机关的机构类型，从apptypeconfig.xml中取得有效的应用类型信息。如果应用类型信息只有一个，则直接把该应用服务器归到该应用类型；如果应用类型信息有多个，则查找应用类型信息中是否存“notype”的类型，如果有则设该应用服务器的应用类型为“notype”，否则新增一个“notype”应用类型，并设置该应用服务器的应用类型为新增的应用类型；最后保存serverconfig.xml，完成serverconfig.xml更新完毕。

当然，所有流量控制器中的应用服务器信息获取完后，如果有应用服务器的应用类型为“notype”,则要显示服务器管理界面，让管理员配置应用服务器的应用类型。

解析完升级数据包以及配置完相关信息后，即可以进行生成相应的升级任务。故在本实施例中，上述升级服务管理可以包括任务生成模块，用于生成升级任务节点，并为升级任务节点分配唯一标识id；根据预设任务生成规则，循环处理应用任务信息列表，基于应用服务器配置信息和升级参数配置信息，生成包含各个升级子任务的应用升级任务列表；将同属于同一待升级应用的升级子任务划分至同一任务组，将同属于一个应用任务的任务组划分至同一应用任务；其中，每组任务组均包括测试子任务。

需要说明，上述唯一标识id可以具体为guid。上述预设任务生成规则可以具体为：每一台应用服务器生成一个升级任务；大类相同，小类相同的应用任务分至同一任务组；每个任务组均生成一个测试节点，且测试节点在升级过程中第一个执行；数据升级脚本分配至测试组中的测试节点执行。

更具体地，结合图6示出的升级任务信息文件结构作进一步介绍。其中，升级任务信息文件updatetask.xml用于存放升级任务信息，包括正在执行的升级任务以及升级任务历史信息。其可以包括升级状态信息、任务开始/结束时间、应用任务信息、升级顺序、新/旧版本信息、升级内容等相关信息。

其任务生成过程可以具体为：

生成一个升级任务<updatetask>节点，并为其生成一个id，该id可以具体为guid；

循环处理应用任务信息列表，生成应用任务的id，例如，可以用％updatetask.id％-％apptask.priority％作为apptask的id。如果所生成的id的<apptask>节点在<updatetask>中不存在，则生成一个<apptask>节点并设置id，否则取得该<apptask>节点；

读取应用根目录下的readme.txt文件，把其中的内容加入任务描述信息；循环处理指定到当前apptask的应用服务器所在省；

将省名称加入任务描述信息，将apptask的<description>节点内容加入任务描述信息；用％apptask.id％-％provinceid％-％subtype％作为id生成一个<group>节点；设置该<group>节点的index属性为当前应用服务器的索引值；

循环处理当前省的应用服务器信息，并将应用服务器名称、地址加入任务描述信息；

根据应用服务器地址获取服务器中应用的状态信息，如果获取状态失败，则标记当前任务的状态为“服务不在线”；设置<task>节点的index属性当前应用服务器的索引值；

生成<task>节点，用％group.id％-％服务器索引％作为该节点的id，并为<task>节点设置应用服器地址与端口；

为<task>节点设置脚本信息，如果当前apptask需要执行数据库升级且当前服务器的索引为0，则在脚本节点中增加数据库脚本信息；

将<task>节点加入<group>节点，将<group>节点加入<apptask>节点，将<apptask>节点加入<updatetask>节点，将<updatetask>节点的内容加入updatetask.xml文件。

根据用户配置的应用服务器信息、升级参数信息以及升级数据包，一次向生成一次升级任务的所有的升级子任务，且根据应用类型，将各个升级子任务划分至相应的任务组，并将相应的任务组划分至相应的应用任务。

生成任务之后，根据相应的任务优先级以及任务调度策略，将各个升级子任务分发至升级服务，有序地协调各个应用的升级。

本实施例中，上述升级服务管理端可以包括任务调度模块，用于根据应用任务优先级高低，依序执行各个应用任务；其中，应用任务包括一个或多个任务组，每个任务组包括一个或多个升级子任务以及测试子任务；每个应用任务的任务调度过程为：分发测试子任务分发至相应的升级服务；当测试子任务执行成功后，根据预设任务调度规则，分发升级子任务至相应的升级服务；预设任务调度规则具体包括第一调度规则、第二调度规则和第三调度规则；第一调度规则为依次分发执行同一任务组的升级子任务；第二调度规则为并行分发同一任务组的所有的升级子任务，当同一任务组的所有升级子任务分发完成后，分发下一任务组的任务；第三调度规则为并行分发同一应用任务的所有升级子任务。

为更好地介绍任务的调度过程，结合图7示出的一次升级任务的示意图。其中，升级任务包括应用任务0、应用任务1及应用任务2，应用任务0优先级最高，应用任务1次之，应用任务2次次之；应用任务0包括任务组0-0，任务组0-0包括升级子任务0-0-0、升级子任务0-0-1及升级子任务0-0-2；应用任务1包括任务组1-0和任务组1-1，任务组1-0包括升级子任务1-0-0、升级子任务1-0-1及升级子任务1-0-2，任务组1-1包括升级子任务1-1-0、升级子任务1-1-1及升级子任务1-1-2；应用任务2包括任务组2-0和任务组2-1，任务组2-0包括升级子任务2-0-0、升级子任务2-0-1及升级子任务2-0-2，任务组2-1包括升级子任务2-1-0、升级子任务2-1-1及升级子任务2-1-2。其中，每个任务组的虚线标示的升级子任务为测试子任务。

测试子任务首先执行，当该测试子任务执行成功后，才会执行该任务组的剩余任务。如果该测试子任务执行失败，则可以停止该应用任务的执行，等待回滚操作或其它相应措施。

测试子任务执行成功后，可以根据第一调度规则、第二调度规则或第三调度规则来执行剩余任务。其中，第一调度规则为手动升级模式下的调度方式，第二调度规则和第三调度规则为自动升级模式下的调度方式。

当利用第一调度规则来执行后续任务时，具体过程可以为：依次分发该测试子任务所在任务组的剩余任务，当分发完一个任务组的升级子任务后，用户都需要手动选择下一个升级子任务；当利用第二调度规则来执行后续任务时，具体过程可以为：同一任务组的剩余升级子任务自动执行，当同组的所有升级子任务执行成后，发起下一任务组的执行，如果当前任务组为该应用任务的最后一组，则自动发起下一应用任务的测试任务的执行；当利用第三调度规则执行后续任务时，具体过程可以为：同一应用任务的剩余子任务分组并行执行，每组内按顺序执行，当前应用任务的所有子任务都执行成功后，自动发起下一应用任务的测试任务的执行。

例如，图7所述的升级任务的调度顺序可以具体为：

执行测试子任务0-0-0，如果该任务执行失败，则停止应用任务0的执行，等待回滚操作；如果该任务执行成功，则按序继续执行子任务0-0-1与子任务0-0-2；

等到应用任务0全部执行完毕，执行应用任务1的测试子任务1-0-0，如果该任务执行失败，则停止应用任务1的执行，等待回滚操作；如果该任务执行成功，则可以发起任务组1-0剩余的任务或者可以发起应用任务1剩余的任务(分组并行执行，组内按序进行)；

等到应用任务1全部执行完毕，执行应用任务2的测试子任务2-0-0，如果该任务执行失败，则停止应用任务2的执行，等待回滚操作；如果该任务执行成功，则可以发任务组2-0剩余的任务或者可以发起应用任务2剩余的任务(分组并行执行，组内按序进行)；

等到应用任务2的所有升级子任务都执行成功，则升级任务完成。

可以看出，当优先级高的应用任务执行完成后，才会进入下一优先级应用的升级，直至升级任务列表中的所有升级子任务都完成，这样可以实现升级流程的控制，有效地协调各个应用间的升级顺序。且设置测试子任务，当测试子任务执行成功后，才进行后续升级工作，这样可以减少问题的影响面。例如，如果测试子任务执行失败，则表示当前节点出现问题，此时只需回退测试节点，结束升级任务，有效地把升级失败带来的影响控制在小范围内。

将各个升级子任务分发至相应的升级服务后，升级服务会执行相应的接收和执行操作。其中，任务接收是升级服务对外提供的soa服务，负责对任务的预处理。接收失败时，返回给升级服务管理端相应的处理报告，接收成功时，执行升级子任务。

本实施例中，上述升级服务可以包括接收模块和执行模块，接收模块用于比较升级子任务携带的版本信息与升级服务所在的待升级应用的版本信息，判断是否一致；若不一致，则接收失败，返回接收失败结果；执行模块用于当升级子任务携带的版本信息与升级服务所在的待升级应用的版本信息一致时，执行升级子任务，并返回执行结果。

可以理解，升级服务管理端所发送的升级子任务会携带有相关的升级任务信息。其中，升级任务信息可以包括应用旧版本信息、升级包地址信息以及其它相关信息。

升级服务获取到升级子任务的相应升级任务信息后，会从当前的应用的版本文件中读取应用版本信息，然后将所读取到的应用版本信息与任务所携带的应用旧版本信息相比较，判断是否一致，如果一致，则执行升级子任务，如果不一致，则生成相应的报告返回给升级管理端。

进一步地，上述执行模块可以包括下载子模块、备份子模块、升级子模块、结果返回子模块和重启子模块；下载子模块用于根据升级子任务，下载应用升级包；备份子模块用于执行应用备份；升级子模块用于解压应用升级包，获取升级文件，执行应用升级工作；调用数据库升级脚本文件，执行数据库升级工作；结果返回子模块用于生成任务执行结果，并返回给升级服务管理端；重启子模块用于根据升级子任务携带的重启配置信息，确定是否需要重启；如果需要重启，则调用重启脚本文件，重启应用，并返回重启信息给升级服务管理端。

具体地，升级服务从升级任务信息中获取升级包文件地址，访问该地址，下载得到相应的升级包。升级包下载失败时，返回给升级服务管理端相应的失败信息，升级包下载成功后，解压升级包至相应的目录下。然后执行应用备份操作，具体可以以升级任务id为名称创建文件夹，将应用信息存储至该文件夹中。接着，如果该升级子任务需要升级数据库，则取得数据库链接信息，调用数据库更新脚本文件，执行数据库升级工作，并将开始/结束时间、执行结果等相关信息写入升级日志；执行完数据库升级工作后，可以接着将升级文件拷贝至应用的相应的目录下，如果升级文件前辍是“del-”则将该文件从应用目录中删除；如果对应的文件在当前应用中不存在，则直接拷贝文件，并记录文件名；如果对应的文件在当前应用中存在，则覆盖该文件。

拷贝完成后，可以将拷贝过程中的相关信息写入升级日志，例如开始时间、结束时间、文件源目录、文件目标目录、文件名、复制结果或异常信息等。

任务执行成功后，升级服务可以将任务执行结果生成为报告形式返回给升级服务管理端。此外，还可以判断是否需要重启，如果需要，则调用重启脚本，重启应用，并且同时返回相应的重启信息给升级服务管理端。

升级服务执行升级子任务时，可能成功，也可能失败。当升级子任务执行失败时，可以将应用回滚至升级之前的版本。

故本实施例中，上述升级服务还可以包括回滚模块，用于接收升级服务管理端发送的回滚请求；根据回滚请求，获取回滚信息；根据回滚信息，执行回滚操作。

升级服务的回滚过程可以具体为：接收升级服务管理端的回滚请求，根据该回滚请求携带的版本信息以及升级任务id等相关回滚信息。如果有数据回退脚本，则获取数据库配置信息，执行数据库回退脚本，并将数据库回退的开始/结束时间、回退结果等相关信息写入回退日志。从备份目录中相应文件，执行应用回退，并记录相关信息至回退日志。回退失败时，通知升级服务管理端，回退成功时，重启应用，并发送回退重启信息至升级服务管理端。

此外，升级服务还可以实现应用版本信息更新、打包日志、健康检查、暂停服务接口等功能。

可以理解，可以同时进行多个应用任务的回滚，也可以执行单个应用任务的回滚，且应用任务回滚可以自动回滚，也可以手动回滚。

本实施例中，上述升级服务管理端还可以包括任务状态监控服务，用于监控正在执行的升级任务和回滚任务；任务状态监控服务包括第一监控模块和第二监控模块；第一监控模块用于监控正在执行的升级任务，根据升级任务的执行时间与第一时间阈值的大小，更新升级任务的状态为第一预设状态；第二监控模块用于监控回滚任务，根据回滚任务的执行时间和第二时间阈值的大小，更新回滚任务的状态为第二预设状态。

可以理解，任务状态监控服务可以是定时监控，也可以非定时监控，在此不作限定。其可以包括升级任务监控即第一监控模块和回退任务监控即第二监控模块。

对于升级任务监控，如果升级任务执行的时间超过人工干预预警时间，则将该升级任务的状态更新为“任务异常状态”；如果该升级任务执行时间超过最大升级时间，则将该升级任务的状态更新为“升级失败”，并结束当前任务。其中，上述第一时间阈值包括人工干预预警时间和最大升级时间，第一预设状态包括异常和失败状态两种。

对于回退任务监控，如果回退任务的执行时间超过最大回退时间，则将该回退任务的状态更新为“回退失败“，结束当前回退任务。第二时间阈值指的是最大回退时间，第二预设状态指的是回退失败。

为更好地介绍整个升级过程所涉及的任务状态转换，可参见图8示出的任务状态转换说明示意图，其中，图中包括从升级任务生成后至回滚任务执行期间的任务状态转换，详细请参见图中相应介绍，在此不再赘述。

可以看出，利用任务状态监控，可以使任务升级过程的任务可监控，这样，可确保任务升级的准确性，且在任务异常或失败时能及时得知，以便及时做出应对措施。

本实施例中，升级服务管理端还可以包括升级日志查看模块和升级任务查询模块；升级任务查询模块用于根据查询指令，查找并显示相应任务信息；升级日志管理模块用于根据日志查询或日志下载指令，显示相应升级日志信息或下载相应升级日志。

也就是说，用户可以通过查询界面，输入所需查询任务的信息，系统可以查询到相应符合条件的升级任务信息并进行相应显示。升级服务在接收到日志下载指令，会相应打包升级日志，返回给升级服务管理端。

此外，升级服务管理端还可以设置用户登录权限管理、应用服务器管理等功能，且升级服务管理端可接收升级任务处理报告和回退任务处理报告，并根据报告，相应更新任务状态。例如，如果升级任务处理报告显示升级结果为失败，则将该任务的升级状态更新为“升级失败”，并相应的更新该任务对应的日志信息。

本发明实施例所提供的复杂服务端应用系统的升级系统，通过升级服务管理端接收并解析升级数据包，得到应用任务配置信息，生成应用任务信息列表，并根据应用类型，将应用任务信息列表中的各个应用类型节点进行排序；根据应用任务信息列表，以及接收的应用服务器配置信息和升级参数配置信息，生成包含各个升级子任务的应用升级任务列表；根据预设任务调度策略，依序从应用升级任务列表获取升级子任务，并分发升级子任务至相应的升级服务；升级服务接收并执行升级子任务。该系统根据应用类型确定升级子任务的优先级，再根据优先级的高低和任务调度策略进行分发任务，进而协调各个应用的有序升级，且升级任务可配置，实现了复杂服务端应用系统的自动化升级，相较于人工升级，其效率较高，准确性较好。

为更好地介绍本发明提供的复杂服务端应用系统的升级系统，下面将以个人税收系统为应用场景介绍升级流程。

个人税收系统包括总局部署核心应用、总局前置应用和核心web应用，以及省局前置应用、大厅应用和核心web应用，且各自均有相应的数据库集群，具备复杂服务应用系统的相应特点。

具体应用中，应用升级还可以分为停机升级和不停机升级，其中，不停机升级主要发生在业务逻辑变更、配置变更、页面变更等引起的升级，此类升级不需要重启服务器；停机升级主要发生在类文件或jar包发生变化的时候，此类升级需要重启应用。

参见图9示出的个税系统停机升级示意图，包括升级服务管理端和设置于各个应用的升级服务，其中，应用包括核心应用、前置应用和大厅应用。核心应用的优先级最高，前置应用次之，大厅应用次次之。

停机升级的具体过程可以具体为：s1、系统管理员上传系统管理员上传升级文件包；s2、解析升级包；s3、系统管理员配置升级服务器信息；s4、根据升级包以及升级服务器信息生成升级子任务；s5、向相关的大厅应用发送停止服务指令，相应的大厅应用停止接收用户请求。如果核心web不分开部署，且需要升级核web，则要向相关的核心应发送停止服务指令。如果核心web分开部署,且需要升级核心web，则要向相关的核心web应用发送停止服务指令；s6、向总局前置的流量控制器发送隔离请求，隔离指定核心应用；s7、向指定核心应用的升级服务发送升级任务；s8、升级服务接收升级任务，并从管理端下载升级包；s9、如果需要升级数据库，则由升级服务发起核心数据库升级；s10、执行应用升级工作，重启应用；s11、核心应用的升级服务向升级管理端发送升级报告；s12、向流量控制器发送撤消隔离请求，撤消隔离核心应用；s13、向流量控制器发送隔离请求，隔离指定的前置应用；s14、向指定前置应用的升级服务发送升级任务；s15、升级服务接收升级任务，并从管理端下载升级包；s16、如果需要升级数据库，则由升级服务发起前置数据库升级；s17、执行应用升级工作，重启前置应用；s18、前置应用向升级管理端发送升级报告；s19、向流量控制器发送撤消隔离请求，撤消指定核心应用的隔离；s20、向大厅应用发送升级任务；s21、升级服务接收升级任务，并从管理端下载升级包；s22、如果需要升级数据库，则由升级服务执行大厅数据库升级；s23、执行应用升级工作，重启大厅应用；s24、大厅应用向升级管理端发送升级报告；s25、显示升级结果。其中，步骤序号与图中标号一一对应。

停机升级和不停机升级的过程类似，两者的最主要区别步骤在于停机升级需要上述步骤s5即向相关应用发送停止服务指令，不停机升级不需要此步骤，其它步骤类似或相同，在此不再赘述。

可以说明，各个步骤的详细过程可相应参见上述实施例的相关内容，在此不再赘述。例如，升级服务管理端解析升级数据包的过程可参见上文介绍数据包解析的相应内容。

本实施例中，由升级服务管理端同一发起升级任务，并根据应用类型和任务调度协调各应用的有序升级，且升级任务可配置，实现了复杂服务端应用系统的自动化升级，提高了升级效率和准确率。

下面对本发明实施例提供的复杂服务端应用系统的升级方法进行介绍，下文描述的复杂服务端应用系统的升级方法与上文描述的复杂服务端应用系统的升级方法可相互对应参照。

请参考图10，图10为本发明实施例提供的复杂服务端应用系统的升级方法的流程示意图，该方法应用于上述实施例的任一项复杂服务端应用系统的升级系统，该方法包括以下步骤：

步骤1001、升级服务管理端接收并解析升级数据包，得到应用任务配置信息，生成应用任务信息列表，并根据应用类型，将所述应用任务信息列表中的各个应用类型节点进行排序；根据所述应用任务信息列表，以及接收的应用服务器配置信息和升级参数配置信息，生成包含各个升级子任务的应用升级任务列表；根据预设任务调度策略，依序从所述应用升级任务列表获取所述升级子任务，并分发所述升级子任务至相应的所述升级服务；

步骤1002、升级服务接收并执行所述升级子任务。

本发明实施例所提供的复杂服务端应用系统的升级方法，通过升级服务管理端接收并解析升级数据包，得到应用任务配置信息，生成应用任务信息列表，并根据应用类型，将应用任务信息列表中的各个应用类型节点进行排序；根据应用任务信息列表，以及接收的应用服务器配置信息和升级参数配置信息，生成包含各个升级子任务的应用升级任务列表；根据预设任务调度策略，依序从应用升级任务列表获取升级子任务，并分发升级子任务至相应的升级服务；升级服务接收并执行升级子任务。该方法根据应用类型确定升级子任务的优先级，再根据优先级的高低和任务调度策略进行分发任务，进而协调各个应用的有序升级，且升级任务可配置，实现了复杂服务端应用系统的自动化升级，相较于人工升级，其效率较高，准确性较好。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

以上对本发明所提供的复杂服务端应用系统的升级系统及方法进行了详细介绍。本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。