CN117499478A - 一种Java服务器应用代理自动更新平台和装置 - Google Patents

Abstract

本发明公开了一种Java服务器应用代理的自动更新平台和装置，包括更新检测工具、更新服务器端以及分布式部署的多个机房区域机房服务器端。其中，更新检测工具用于获取发生真正变化的Java代理更新文件，并将获取到的Java代理更新文件包上传到更新服务器端，从而触发代理文件的自动批量更新；更新服务器端用于根据接收到的各Java代理更新文件包向需更新的代理对应的机房区域机房服务器端下发Java代理更新通知，并向各待更新的机房区域机房服务器端提供Java代理更新文件包；机房区域机房服务器端用于根据接收到的Java代理更新通知主动向更新服务器端获取Java代理更新文件包，从而主动地对本地Java服务器应用代理进行批量自动更新。

Description

一种Java服务器应用代理自动更新平台和装置

技术领域

本发明涉及信息技术领域，具体涉及一种Java服务器应用代理自动更新平台和装置。

背景技术

Java Instrument支持通过一个独立的代理(Agent)监测JVM上应用程序的运行，它能获取JVM的运行时状态，还可以通过替换和修改类定义等方式拦截应用系统的操作数据，以及拦截处理不当影响到业务系统、耗时大导致业务运行变慢等相关风险。

但是，在实际工作中，往往需要更新几千甚至更多上述Agent或需要处理Agent的Bug，由于手工更新效率低而且容易出错，怎样高效、可靠地在生产环境下变更大量Agent，同时避免影响到业务系统的正常运行，是实际工作中的重要挑战。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种Java服务器应用代理自动更新平台，针对部署在多个机房内大量的Java业务服务的Agent的自动更新，通过更新检测工具来自动检测并获取Java代理更新文件包，然后通过更新服务器端对所有Agent以及对应的文件包进行统一的管理，并及时向需要更新Agent的机房区域机房服务器端下发Java代理更新通知，以使机房区域机房服务器端可以及时自动更新本地的所有Agent。

本发明的技术方案为：

本发明提供一种Java服务器应用代理自动更新平台，包括更新检测工具、更新服务器端以及分布式部署的多个机房区域机房服务器端；其中，

更新检测工具用于获取发生真正变化的Java代理更新文件，并将获取到的Java代理更新文件包上传到更新服务器端，从而触发代理文件的自动批量更新；

更新服务器端用于根据接收到的各Java代理更新文件包向对应的机房区域机房服务器端下发Java代理更新通知，并向各待更新的机房区域机房服务器端提供Java代理更新文件包；

机房区域机房服务器端用于根据接收到的Java代理更新通知主动向更新服务器端获取Java代理更新文件包，从而对本地Java服务器应用代理进行更新。

根据本发明的Java服务器应用代理自动更新平台的一实施例，所述更新检测工具还包括Java代理源代码版本控制工具，通过Java代理源代码版本控制工具来管理Java代理各版本源代码；其中，所述更新检测工具利用Java代理源代码版本控制工具来检测Java服务器应用代理是是否发生更新，包括以下步骤：

调用Java代理源代码版本控制工具，分别获取Java代理当前版本和上一版本的源代码以及配置文件；

对比当前版本和上一版本的源代码以及配置文件，判断源代码和配置文件是否发生变动；若是，则找到发生变动的所有文件；若否，则继续对比检测Java服务器应用代理是否发生更新；

对找到的所有文件进行清洗，然后再对比清洗后的当前版本和上一版本的文件，找到真正发生变化的文件；

根据真正发生变化的文件生成对应的Java代理更新文件包，并将生成的Java代理更新文件包上传到更新服务器端进行存储。

根据本发明的Java服务器应用代理自动更新平台的一实施例，所述Java服务器应用代理信息包括各项目以及所有服务实例的位置信息、更新进度信息、错误数据信息，以及各版本Java代理的源代码位置信息和对应的待更新的Java代理更新文件包信息；其中，所述更新服务器端获取到待更新的Java代理更新文件包后，根据Java代理更新文件包对应的Java服务器应用代理信息向对应的机房区域机房服务器端下发Java代理更新通知。

根据本发明的Java服务器应用代理自动更新平台的一实施例，各机房区域机房服务器端根据本地Java服务需求分别部署多个更新控制端，通过更新控制端控制对应Java服务代理的更新。

根据本发明的Java服务器应用代理自动更新平台的一实施例，所述Java服务器应用代理自动更新平台采用代理自动发现机制来自动采集各个机房所有服务器信息，从而实现更新服务器端对所有代理的统一管理。

根据本发明的Java服务器应用代理自动更新平台的一实施例，所述Java服务器应用代理自动更新平台采用代理更新范围控制机制对待更新的代理进行风险评估，结合量化校验新版本Java服务器应用代理对Java服务器应用的影响，从机房、项目、服务器三个维度控制Java代理的更新范围。

根据本发明的Java服务器应用代理自动更新平台的一实施例，所述Java服务器应用代理自动更新平台在进行风险评估时，根据Java服务器应用代理文件包的功能作用进行分类，并记录分类后的Java服务器应用代理文件包的更新信息，从而依据Java服务器应用代理文件包的更新信息自动推荐Java服务器应用代理执行更新前的质量校验；其中，Java服务器应用代理文件包分类包括核心、通信、拦截检测及数据处理。

根据本发明的Java服务器应用代理自动更新平台的一实施例，所述Java服务器应用代理自动更新平台采用代理更新追溯机制来记录各个代理的更新全过程，从而实现对代理更新过程的追溯和管理。

本发明还公开一种Java服务器应用代理自动更新装置，其特征在于，所述Java服务器应用代理自动更新装置内置如权利要求1-8任一项所述的Java服务器应用代理自动更新平台。

本发明对比现有技术有如下的有益效果：本发明针对Agent部署的多个机房内大量的Java业务服务的自动更新，通过更新检测工具来自动检测并获取Java代理更新文件包，然后通过更新服务器端对所有Agent以及对应的文件包进行统一的管理，并及时向需要更新Agent的机房区域机房服务器端下发Java代理更新通知，以使机房区域机房服务器端可以及时对本地的Agent进行自动更新。与现有技术相比，本发明可以在服务器端统一完成更新的管理和更新过程的监控，无须手动部署更新，开启专门的自动更新进程，即可实现对部署于不同机房的Java项目的不同业务实例的大批量Agent进行自动控制更新，大大减少了人工维护成本，同时还能减少更新错误的发生，实现稳定可控的更新大量项目的预期。此外，本发明还采用了代理更新范围控制机制Agent更新追溯机制，有效控制新版本Agent更新对业务系统的影响范围，使更新的Agent效果能够迅速应用到项目中，有利于项目的稳定运行，保障了生产环境下Agent自动更新的效率和可靠性，提高了更新成功率。。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1是示出本发明的Java服务器应用代理自动更新平台一实施例的架构图。

图2是示出本发明的自动检测Java服务器应用代理更新方法一实施例的流程图。

图3是示出本发明的真实环境下新版本Agent检验方法一实施例的流程图。

图4是示出本发明的更新控制端自动更新一个Agent实例一实施例的详细流程图。

图5是示出本发明的数据库实体一实施例的E-R图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

在此公开一种Java服务器应用代理自动更新平台一实施例，图1是示出本发明的Java服务器应用代理自动更新平台一实施例的架构图。如图1所示，本实施例中，Java服务器应用代理(以下有时简称Agent)自动更新平台包括更新检测工具、更新服务器端以及分布式部署的多个机房区域机房服务器端。其中，更新检测工具用于获取发生真正变化的Java代理更新文件，并将获取到的Java代理更新文件包上传到更新服务器端，从而触发代理文件的自动批量更新。更新服务器端用于根据接收到的各Java代理更新文件包向对应的机房区域机房服务器端下发Java代理更新通知，并向各待更新的机房区域机房服务器端提供Java代理更新文件包。机房区域机房服务器端用于根据接收到的Java代理更新通知主动向更新服务器端获取Java代理更新文件包，从而对本地Java服务器应用代理进行更新。

具体地，由于不同的互联网业务往往部署在多个机房中，不同机房之间可能在网络上无法互通，使用Agent的项目可能至少有数百个，需要更新的服务进程一般会达到数千甚至更多。为了在更新时找到真正发生了变化的jar文件，因此，本实施例中，更新检测工具还包括Java代理源代码版本控制工具，通过Java代理源代码版本控制工具来管理Java代理各版本源代码。图2是示出本发明的自动检测Java服务器应用代理更新方法一实施例的流程图。请参照图2，以下是对更新检测工具利用Java代理源代码版本控制工具来检测Java服务器应用Agent是是否发生更新的详细说明。

步骤A1：调用Java代理源代码版本控制工具，分别获取Java代理当前版本和上一版本的源代码以及配置文件。

具体地，本实施例中，为了实时监测到jar发生变化的Agent，使用Git、SVN等Java代理源代码版本控制工具来管理Agent各版本的源代码以及配置文件。实时监测时，更新检测工具通过调用Java代理源代码版本控制工具的API或者SDK，来读取各Agent的当前版本以及上一版本的源代码和配置文件，用以在下一步骤中对比两个版本的源代码和配置文件。

步骤A2：对比当前版本和上一版本的源代码以及配置文件，判断源代码和配置文件是否发生变动；若是，则找到发生变动的所有文件；若否，则继续对比检测Java服务器应用代理是否发生更新。

本实施例中，通过上一步骤S1获取到Agent的当前版本以及上一版本的源代码和配置文件后，对比两个版本的源代码和配置文件是否发生差异，如果是的话，则找到发生变动的所有文件。如果两个版本的文件并没有差异，则判断确定该Agent并没有发生更新，更新检测工具则继续检测Java服务器应用Agent是否发生更新。

此外，本实施例中，为了提高检测效率，还设置了差异忽略策略。用户通过差异忽略策略可以指定一些即使发生了变动，也无需进行更新的文件。在对获取到有差异的文件以后，根据差异忽略策略排除掉在对比时须忽略的文件和对比差异项。

步骤A3：对找到的所有文件进行清洗，然后再对比清洗后的当前版本和上一版本的文件，找到真正发生变化的文件。

本实施例中，在通过步骤S2获取到发生差异的源代码、配置文件以后，为了进一步提高更新检测准确性，需要对找到的所有文件逐个对比和清洗，去除文本中的空格和注释并合并压缩为一行，然后再对比每个文件在两个版本下的差异，对于发生变化的源码文件，再通过反编译并比较编译后的对应文件确认差异的确存在，从而找到真正有变化的agent代码文件、变化了的方法和变更的代码量、配置量等具体的变更范围。

步骤A4：根据真正发生变化的文件生成对应的Java代理更新文件包，并将生成的Java代理更新文件包上传到更新服务器端进行存储。

本实施例中，通过上述步骤S3找到真正发生变化的源代码和配置文件后，解析对应项目的编译文件pom.xml或build.gradle，并根据发生变化的源码、配置文件来确定需要更新的jar，然后在编译成功后把需要更新的jar上传到更新服务器端进行分布式存储服务。此外，本实施例还可以在更新服务器端保存jar和源码文件直接的对应关系，用以支持发现不同版本的Agent新增的源代码文件，同时通过对应关系也可以支持根据内容真正变动的源代码文件来确定需要更新的jar。

进一步地，本实施例中，通过更新检测工具获取到Java代理更新文件包后，将获取到Java代理更新文件包上传到更新服务器端进行分布式存储，并通过更新服务器端向对应的机房区域机房服务器端下发Java代理更新通知，以对对应的Agent进行更新。其中，更新服务器端用于统一管理Java服务器应用代理自动更新平台，包括产品项目模块、服务实例模块、机房管理模块、jar和源码模块、更新分析模块、区域服务模块、更新文件模块、更新历史模块、更新问题模块、对外接口模块、用户警告模块以及更新触发模块。其中，产品项目模块用于统一管理所有产品和项目的项目信息(包括但不限于所在机房、服务器配置和IP、JRE版本等项目信息)。服务实例模块用于统一管理所有服务实例的实例信息(包括但不限于所在机房、服务器配置和IP、JRE版本等服务实例信息)。机房管理模块用于统一管理位于不同区域的各机房的机房信息(包括但不限于机房位置、服务器配置、JRE版本等机房信息)。jar和源码模块用于存储各Agent不同版本的jar和源代码。更新分析模块用于对待更新的Agent进行分析，以确定更新风险以及范围。区域服务模块则根据待更新的Java代理更新文件包向对应的机房区域机房服务器端下发Java代理更新通知，并通过更新文件模块向各待更新的机房区域机房服务器端提供Java代理更新文件包。更新历史模块用以存储各Agent每次更新时的更新信息，用以支持更新追溯查询。更新问题模块则用于对用于记录Agent更新进展时发现的更新问题，用户警告模块则用于当Agent更新出现问题时向用户提供警告。对外接口模块则用于提供对外进行信息和数据传递的接口。

具体地，本实施例中，为了实现更新服务器端对所有Agent的统一管理，采用代理自动发现机制来自动采集各个机房所有服务器信息，包括服务器上运行的是服务器进程类型(常见的Java服务器是一个有限集，包括Tomcat、Resin、Undertow等)、Java服务器分配的内存配置、服务器的CPU配置、服务器所在的机房位置以及IP地址。同时，本实施例中的更新服务器端还可以根据Java服务器的类型分别读取对应的配置文件提取器主要配置及其引用的Agent，由此获取更多的Java服务器对应的Agent信息。

由于JDK规范规定了Java应用必须通过“-JavaAgent:Agent的jar的路径”的方式引用一个Agent，因此，实施例中，利用上述的代理自动发现机制和获取到的服务器信息还可以定位到有哪些项目的哪些服务实例使用了Agent，以及哪些服务实例还没有启用。这些定位信息有助于进一步推动Agent的覆盖管理，包括对于未应用Agent的项目或服务实例未启动原因的记录、以及可能的后续计划、措施等等。同时，由于使用相同反向代理服务或者业务系统jar相同的不同服务器进程属于同一个项目，因此本实例中还可以进一步确定一个项目有多少服务实例，并将这些信息上报到更新服务器端进行保存，然后允许用户对这些信息进行管理，包括设置项目名及项目所属的产品、所部署的机房、是否允许自动更新某个项目/服务器的Agent等等。

此外，本实施例中，更新服务器端在向对应的机房区域机房服务器端下发Java代理更新通知之前，还需要代理更新范围控制机制来对待更新的Agent进行进一步评估，结合量化校验新版本Java服务器应用代理对Java服务器应用的影响，从机房、项目、服务器三个维度控制Java代理的更新范围。在评估Agent的更新内容后认为有一定风险时，可以选择某个现网或灰度环境下的部分项目的部分服务实例，甚至只选择某个项目的一个服务实例来作为进行对比评估的当前版本，然后在选定的范围和环境下，对比搜集到的新版本和当前版本的Agent的请求拦截和处理过程中的数据，包括但不限于拦截的耗时、拦截和处理过程中是否出现异常或错误等等。经过一段时间的验证对比，确定两个版本的拦截耗时数据接近，并且应用新版本后未出现新的错误或异常后，则表示验证通过，可以在全部服务实例上应用新版本Agent。同时，本实施例也可以根据两个版本的拦截耗时数据的差的绝对值和潜在错误、异常的内容，把二者之间的差异分为不同的等级，然后根据各Agent归属的等级来确定将其应用到对应等级的项目中。

本实施例中，鉴于Agent的更新有可能还会影响到整个项目的所有应用，为了进一步降低Agent更新的风险，还可以把Agent的jar根据功能或作用进行分类，根据Agent的构成把相关的jar分为核心、通信、拦截检测及数据处理这些类别。然后根据这些类别将核心jar的范围压缩至最小并且包含自动更新功能，并在数据库存储每个版本的更新信息，例如具体更新了哪些jar文件、更新验证和应用更新后发现的错误和异常在源码中的位置、变更位于哪些类别范围、变更的大小以及具体范围等等。通过这些更新信息，可以确定各类别jar的更新频率或分布，然后结合更新验证和应用更新后发现的错误和异常在源码中的位置，并确定哪些jar类型的更新有问题以及具体的错误和异常。同时，本实施例还可以根据检测到的变更位于的类别范围、从上面得到的变更的大小和具体范围，从而自动推荐执行更新前的质量校验，为更新风险的评估提供可靠依据，以提高整个过程的工作效率和自动化程度。如此，不仅可以让管理人员及时主动缓存需更新的jar，同时还有助于管理人员发现Agent的规划和设计上的部分不足、避免类似问题重复发生，降低Agent更新带来的风险和影响。

此外，在实际更新操作过程中，在对多个机房的大量服务实例进行自动更新时，由于不同服务器及其配置和运行状况的不同，很有可能会出现部分服务实例无法成功自动更新的情况，这类情况不能及时处理可能会降低部分用户的体验，甚至引发应用故障。为了解决上述问题，本实施例中，更新服务器端还配置了Agent更新追溯机制，在Agent更新时，记录每个Agent控制端更新的各个步骤及其完成状态、完成时间、所在的位置(机房、所属项目和IP地址等等)，并不断汇总这些数据到更新服务器端并允许用户随时查看，并把无法自动更新的服务实例的相关信息实时通知到用户，帮助用户结合更新范围准确把握各个服务实例更新的进度以及有哪些服务实例更新失败、哪些没有更新响应，以便用户能及时干预，避免因无从得知更新失败而不能及时响应等情况，提高了Agent更新成功率和效率。

进一步地，本实施例中，更新服务器端获取到各Java代理更新文件包，并完成对Agent更新的风险评估以后，开始根据待更新的Java代理更新文件包向对应的机房区域机房服务器端下发Java代理更新通知，各待更新的机房区域机房服务器端通过所辖的更新控制端来实现对Agent的更新。

具体地，本实施例中，各机房区域机房服务器端根据本地Java服务需求分别部署多个更新控制端，通过更新控制端来控制对应Java服务代理的更新。其中，更新控制端在对Agent进行更新之前，首先需要量化校验新版本的Agent对应用的影响，以此进一步降低Agent对机房项目的影响。图3是示出本发明的真实环境下新版本Agent检验方法一实施例的流程图，下面结合图3，详细说明真实环境下新版本Agent的检验过程。

步骤B1：Agent更新控制端接收校验请求，并根据校验请求建立新业务部署实例。

步骤B2:修改端口，使新业务部署实例引用新的Agent。

本实施例中，Agent更新控制端收到区域机房服务器端发送的更新校验请求后，记录要验证的Agent的版本号、相关文件的下载地址、总校验时长等信息。然后在服务器本地复制一份已部署的业务系统目录到一个新文件夹，并修改复制后的业务系统使用新的端口，从而使复制后的业务系统基于旧版本Agent的配置文件来应用新版本的Agent。与此同时，将Agent拦截数据的上报目的地修改为自身的HTTP服务地址，并设置总校验时长。

步骤B3:启动新业务部署，结合启动过程的输出和日志判断是否启动成功；若成功，则复制原业务实例的网络流量并转发给新业务部署实例，开始运行新业务部署实例。若否，Agent更新控制端则从新业务部署实例日志中解析错误、异常，并将解析错误、异常进行上报后退出。

本实施例中，通过上述步骤完成复制业务系统以及新版本Agent的配置以后，启动复制后的业务系统并指定其应用新版本的Agent，开始准备拦截业务系统的操作。其中，如果启动失败，Agent端解析新业务服务实例的日志得到启动失败相关的错误、异常并上报，然后退出终结更新。如果启动成功后，则复制原业务系统进程端口的网络流量到新启动的业务系统对应的端口，开始运行新业务部署实例并校验。

步骤B4：Agent更新控制端通过日志输出新的Agent运行时的拦截耗时，并定时计算耗时。

步骤B5：Agent更新控制端将计算到的耗时、错误和异常数据上报本地区域机房服务器端，通过本地区域机房服务器端判断校验是否正常，并将校验结果返回给Agent更新控制端，同时上报给更新服务器端。

本实施例中，新Agent实例在其内置的HTTP服务受到拦截上报的数据后，仅通过日志来输出拦截耗时，不作其它处理。同时，为了及时获取校验数据，本实施例中，还设置了定时解析机制，新Agent实例根据设定的定时解析机制定时解析其日志，然后每隔一定时长把这些数据上报到区域机房服务器端。其中，在解析日志时，新Agent实例主要搜集以下两类信息来进行解析：一是检查新版本Agent日志中是否有输出的错误和异常，如果发现异常，则根据异常信息是否属于一个问题集合(包括空指针、索引越界、内存溢出、参数错误、被0除等)来确认相关异常是否是程序bug，问题集合的内容可以在服务端管理、更新。然后检查相同时间段内旧版本Agent日志的错误和异常，对比两个版本的输出，搜集仅在新版本出现的错误和异常的信息。二是计算每分钟新版本所有拦截耗时数据的平均值、最大值和标准差并缓存。如此，通过对上述两类信息的搜集以及解析，获取到对应的校验数据，并将其上报到区域机房服务器端进行校验分析，判断校验是否正常，并将校验结果返回给Agent更新控制端，同时上报给更新服务器端。

步骤B6：达到校验时长后，Agent更新控制端上报校验数据到本地区域机房服务器端并要求返回校验结果。

步骤B7：本地区域机房服务器端处理上报的校验数据，并将校验结果返回给新Agent更新控制端。

步骤B8：Agent更新控制端接收校验结果，并停止校验新业务部署实例。

本实施例中，新Agent实例对应的Agent更新控制端在达到要求的校验时长后，控制停止搜集校验数据，并将最近的校验数据到本地区域机房服务器端，并向本地区域机房服务器端注明返回校验结果。本地区域机房服务器端接收到校验数据后，检查对比新旧两个版本所有拦截数据的平均、最大性能和性能标准差，如果发现新版本的数值更大，而且两个版本之间的差异值超过一定数值或有错误、异常，则返回校验不通过。否则返回校验通过的校验结果给新Agent更新控制端，同时上报相关数据到更新服务器端。新Agent实例收到校验结果后保存校验开始时间、结束时间和相关结果数据到本地数据库，并停止校验用的新业务实例。

本实施例中，本地区域机房服务器端通过上述步骤完成新版本Agent的检验后，开始对Agent进行更新。其中，一般更新过程包括通知更新、下载待更新文件、备份和删除待更新文件、执行更新(采用新文件替换原文件/替换应用引用Agent的路径)、应用更新这5个主要步骤，每个步骤都会在本地数据库记录完成状态。如果中途因为用户重启业务服务导致更新终止，更新过程会根据本地数据库记录的上一个步骤的完成状态继续后续工作。另外，本实施例的更新机制支持用任意一个版本的Agent替换另外任意一个版本，不受版本号限制。图4是示出本发明的更新控制端自动更新一个Agent实例一实施例的详细流程图，下面结合图4，详细说明本实施中更新控制端自动更新一个Agent实例的具体步骤。

步骤C1:获取更新通知，校验参数。

本实施例中，Agent更新控制端收到区域机房服务器端的更新通知后，保存待更新版本的信息到本地数据库，包括要更新的版本号、待下载文件的地址、更新后是否立即重启应用服务、更新类型(全量更新还是部分更新)、下载文件的MD5/SHA1码并校验参数是否合法等等。

步骤C2：确定通知状态，并向本地区域机房服务器端发送下载待更新文件请求。

步骤C3：本地区域机房服务器端检查下载是否超限，若是，则在建议时刻后一个随机时间重新调度下载，生成随机时间的时间长度可以根据文件下载所需时长乘以待下载更新文件的服务器数/允许的并发下载量确定，能满足所有服务器的下载需要即可，可以进一步增加一定的冗余时长。若否，则Agent更新控制端从本地区域机房服务器端下载并保存待更新文件。

本实施例中，检查确认更新状态为“已通知”后，Agent端取一个按上述方式计算确定的时间或用户自定义时间段内(例如24小时内)向本地区域机房服务器端发起文件下载操作。区域机房服务器收到文件下载请求后，先检查下载中的总请求数是否超限，不超限则Agent更新控制端立即通过其分布式存储服务开启下载指定版本的文件。若超限，则结合下载耗时向更新控制端返回建议等待多久后重试下载的下载响应。Agent收到该下载响应，则在建议的等待时间到达时调度再重新发起下载。

步骤C4：判断下载的待更新文件是否完整；若是，则记录“已下载”，并解压下载的待更新文件；若否，则记录“文件损坏”，并搜集更新结果上报到本地区域机房服务器端。对于下载失败的服务器，区域机房服务器端可以通知这些服务器从同机房的其它备用下载服务或者从已经预先下载成功的备用服务器远程复制得到待更新的文件，相关服务器之间的通信安全性以采用专门的SSL证书和秘钥预先配置好的SSL连接为基础。

本实施例中，Agent更新控制端下载更新文件成功后，需要验证已下载文件的MD5/SHA1码是否与更新前传递的相同，相同的话则记录更新状态为“已下载”，然后解压缩需要更新的文件，否则的话记录“文件损坏”，并搜集更新结果上报到本地区域机房服务器端。

步骤C5：基于解压后的待更新文件选择更新类型；

步骤C6：根据更新类型进行Agent更新。

本实施例中，Agent更新控制端需要根据解压后的待更新文件选择对应的更新类型来进行更新。其中，更新类型分为全量更新和部分更新。若Agent更新控制端选择部分更新，则需要先通过计算、对比MD5/SHA1码来确认每个要更新的文件与原版同名文件是否不同，如有任意一个文件的两个对比结果相同则记录“更新文件设置错误”以及未更新的文件名。如果检查通过则把待更新文件全部复制到Agent对应的文件目录下。同时在复制时还需要检查所有更新文件具有读权限，如果没有则需要进行设置，设置失败的话则需要记录程序异常消息。此外，本实施例中，在进行部分更新时，需要先备份再删除要替换的文件。在备份路径下，按Agent当前版本号建立文件夹用于保存待更新文件，再执行备份，如果失败，例如硬盘空间已满、无写权限、写失败等，则记录备份失败及其错误消息，否则记录“已备份”。完成备份后，则删除Agent目录下待更新文件，删除出现错误时记录“删除失败”及错误信息，否则记录“已删除”。

步骤C7：更新应用，搜集更新记录结果并上报到本地区域机房服务器端。

本实施例中，通过上述步骤完成Agent更新后，开始更新应用，并搜集更新记录结果上报到本地区域机房服务器端。其中，在进行应用更新时，可以选择立即重启业务服务或者稍后重启业务服务两种方式进行操作。

具体地，如果区域机房服务器端指定更新后立即重启业务服务来进行应用更新，则需要先关闭业务服务进程然后重新启动。启动后读取日志检查没有Agent相关异常或错误输出，如果没有则记录“已应用”；如果有则搜集错误和异常消息及其在Agent代码中的位置。同时在应用更新时还需要记录应用时出错及搜集到的数据，再根据更新类型回滚，以恢复所有变更的Agent文件到更新前的状态并记录更新状态为“已回滚”。

如果区域机房服务器端选择的是稍后重启业务服务方式，则记录更新状态为“待重启”，后续由运维人员实施重启并根据重启后应用是否正常、日志文件中是否有Agent相关的错误和异常适当处理。如果这期间Agent能启动成功，则自动收集是否发生错误或异常并上报到区域机房服务器端。

步骤C8:本地区域机房服务器端定时将更新结果批量压缩上传到更新服务器端进行存储。

本实施例中，在进行更新应用时，还需搜集组装当前Agent的编号、IP、所属项目和最后一次更新步骤的状态及可能存在的错误和异常信息，再上报更新结果到区域机房服务器端，通过本地区域机房服务器端定时将更新结果批量压缩上传到更新服务器端进行存储。

此外，本实施例中，Java服务器应用代理自动更新平台除了可以通过各机房区域机房服务器端来进行Agent的自动更新以外，还可以支持用户从服务端选定用某个版本的Agent来替换当前使用中的版本，包括把使用中的版本文件替换另一个版本的Agent文件，从而方便地帮助用户减免大量手工更新工作。同时本发明支持用户随时从更新服务器端集中查看各项目的更新结果，全面了解更新进度和需要人工干预的不能自动更新的实例并及时响应。

其中，当用户发起更新多机房中一系列项目实例的Agent时，首选需要选定要更新的Agent版本及其文件，并设置是否需要校验该版本。若需要，则指定采用哪个机房内哪个具体IP地址的项目实例检验，以及此次更新的范围是哪些区域机房服务器端和项目。如果不指定的话则默认应用于所有机房的全部项目实例的Agent，此时服务端自动建立相应的更新事件记录。此外，本实施例中用户还可以根据各机房的位置把区域机房服务器端分组，并指定每一组的序号。接下来每一组的区域机房服务器端可以根据总序号把一定时长分为相等的时间段，每一组在每个时间段开始时刻发起下载待更新的jar和配置文件并保存在本地分布式存储服务。

本实施例中，在校验Agent时，更新服务器端先把待校验的Agent信息、相关文件推送到指定校验环境对应的区域机房服务器端，然后由该区域机房服务器端再把校验信息发送给指定的项目实例对应的Agent更新控制端。

本实施例中，接收到校验信息后，开始进入如图3所示的新版本Agent检验方法的流程，此处不再赘述。当服务器端检查校验结果是否通过，通过则记录当前更新事件记录的状态为“校验通过”并继续，否则的话则记录该状态为“校验未通过”，并退出本次更新过程。

接着，更新服务器端根据用户指定的更新范围通知相应的所有区域机房服务器端待应用的Agent信息，包括版本号、待下载的文件、服务端推荐的下载时间段(可选)、下载路径及文件完整性校验信息，并为每个区域机房服务器端建立一个更新汇总记录。若通知成功则记录“已通知”，否则记录“通知失败”及错误或异常信息。同时，本实施例中，还可以记录后续相应区域内已完成自动更新的Agent实例数、更新中和无法自动更新(已失败)的实例数等信息、无更新响应的Agent实例数，并允许用户查看各部分具体实例的详细信息。若出现失败的情况，本实施例还可以配置重试通知次数，例如配置为支持重试通知最多3次。

本实施例中，通过上述步骤完成区域机房服务器端的更新范围通知以后，各区域机房服务器端在指定的时间段从服务器端下载待更新的文件并保存到本地分布式存储。若下载成功，则向服务端上报对应的区域服务的更新记录的状态为“已下载”。如果下载失败，本实施例还可以配置重试下载次数，例如支持重试下载最多3次，并记录每次失败时程序的异常消息。如果最后仍失败则记录“重试3次后仍下载失败”，否则记录“重试1或2次后下载成功”。

本实施例中，各区域机房服务器端从服务器端下载到待更新的文件后，通知本地的各个服务实例开始准备应用新版本。如果通知成功，则记录相关实例的更新状态为“已通知成功”。如果通知失败，本实施例还可以配置重试通知次数，例如支持重试通知最多3次，并记录每次失败时程序的异常消息。如果最后还是失败，记录“重试3次后仍通知失败”和相关错误消息，否则记录“重试1或2次后通知成功”。

本实施例中，各区域机房服务器端本地的各个服务实例获取到更新通知以后，开始进入如图4所示的更新控制端自动更新一个Agent实例的详细流程。此处不再赘述。此外，本实施例中，更新控制端自动更新一个Agent实例时，还可以并行地更新各个机房中所有项目实例的Agent。对于Agent更新的每一步，都需要记录相应的完成状况以及出错时的错误信息或出现程序异常时的异常信息及相关代码的调用堆栈，并上报包括Agent的编号、服务器IP、步骤名、完成结果、完成时间、完成状态和可能的错误和异常信息，从而使用户在服务器端可知有哪些服务实例在应用更新及其实际进展。

本实施中，更新服务器端还根据用户设置的更新范围来计算待更新的项目实例数和相关机房的agent实例数N。同时服务器端还会定时扫描累计已成功、失败更新的实例数S和F，并分以下几种情况来记录agent更新状态：

第一种情况，N＝S+F并且F＝0，则记录agent更新事件的状态为“已更新完成”。

第二种情况，N＝S+F并且F>0，记录状态为“更新完成，但有F实例无法自动更新”。此时需要通过邮件等方式主动通知用户更新结果的汇总情况和分析，包括已成功更新的项目及实例的数目和完成时间等明细、更新过程中哪些项目的哪些实例发生了具体什么错误、哪些实例无更新响应，及其对应上述包括通知失败在内的具体哪个更新步骤(最后执行的步骤)、最后更新时间和最后执行更新的对象、发生在哪些机房、相关运维负责人等信息，还可以根据错误类型主动提示用户发起干预具体哪些实例的更新。

第三种情况，N<S+F，记录状态为“更新中”，此时仿照第二种情况每天通知用户更新进展以及发现的更新问题和分析结论。

此外，本实施例中，用户在更新过程中可以随时通过专门的服务器端中的UI来集中查看各机房所有项目实例的更新进展，包括有哪些/多少仍在更新中、有哪些/多少更新出错以及错误原因、自动更新过程各个步骤的出错比例、各个错误异常和消息发生次数的排行榜等信息，并对出错的实例安排适当的后续措施，包括人工排查修复后重试自动更新、根据这些上报信息补充或更新自动发现的Agent实例等等。

综上，本实施例中，作为Agent一部分的更新控制端，可以支持本地嵌入式数据库和HTTS服务，从而实现从机房区域机房服务器远程复制待更新的jar和配置文件。且本实施例中，在用户配置需校验时，更新控制端支持建立本地验证新版本的环境，验证对比新旧两个Agent版本，然后更新应用并上报结果。此外，本实施例中，更新控制端还支持每次启动本地业务服务后都自动注册。如果本地未保存区域服务地址，则先根据服务器IP、所在机房从配置的服务端地址查询机房区域服务地址并保存，然后以服务器IP、所属项目向区域服务注册。如果注册时发生错误，则上报服务端，在经过人工检查机房、项目配置后，可以手工发起重新注册。最后，本实施例中，更新控制端还用以接收本地Agent上报的拦截数据的请求，并解析每个数据记录的拦截时间。其中，拦截时间可以是当前系统事件时间减去这个时间所得到拦截耗时，例如每个一分钟。

本实施例中，针对上述的Java服务器应用代理自动更新平台的大批量Agent自动更新方法，根据实际业务需求，设计了一如图5所示的数据库实体E-R图。其中，Java服务器应用代理自动更新平台的业务实体包括项目、产品、机房、机房区域房屋实例、Agent、Agent实例、Agent更新历史以及Agent更新事件，每个业务实体均包含一系列属性。例如针对产品这个业务实体，则包括产品名、访问玉米、所属部门这三个属性。通过设置各业务实体的多个属性字段，可以详细表达所对应的实体的业务属性。此外，本实施例中，在具体实施时，还可以结合实际需求调整部分实体的属性字段，以适应具体业务需求。同时，针对各业务实体之间的关联关系，利用带箭头的虚线来表示业务实体之间逻辑上的依赖关系，例如产品依赖项目、Agent实例依赖项目、Agent依赖Agent实例等等。通过这些设置的业务实例以及各实例之间的依赖关系，支持多个不同Agent在各机房不同项目的更新事件及相关业务实体数据的管理以及更新过程的自动发起、追溯和重试机制。

本说明书中还公开了一种Java服务器应用代理自动更新装置。其中，该Java服务器应用代理自动更新装置内置如上所述的Java服务器应用代理自动更新平台。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

Claims (9)

1.一种Java服务器应用代理自动更新平台，其特征在于，包括更新检测工具、更新服务器端以及分布式部署的多个机房区域机房服务器端；其中，

更新检测工具用于获取发生真正变化的Java代理更新文件，并将获取到的Java代理更新文件包上传到更新服务器端，从而触发代理文件的自动批量更新；

更新服务器端用于根据接收到的各Java代理更新文件包向对应的机房区域机房服务器端下发Java代理更新通知，并向各待更新的机房区域机房服务器端提供Java代理更新文件包；

机房区域机房服务器端用于根据接收到的Java代理更新通知主动向更新服务器端获取Java代理更新文件包，从而对本地Java服务器应用代理进行更新。

2.根据权利要求1所述的Java服务器应用代理自动更新平台，其特征在于，所述更新检测工具还包括Java代理源代码版本控制工具，通过Java代理源代码版本控制工具来管理Java代理各版本源代码；其中，所述更新检测工具利用Java代理源代码版本控制工具来检测Java服务器应用代理是是否发生更新，包括以下步骤：

调用Java代理源代码版本控制工具，分别获取Java代理当前版本和上一版本的源代码以及配置文件；

对比当前版本和上一版本的源代码以及配置文件，判断源代码和配置文件是否发生变动；若是，则找到发生变动的所有文件；若否，则继续对比检测Java服务器应用代理是否发生更新；

对找到的所有文件进行清洗，然后再对比清洗后的当前版本和上一版本的文件，找到真正发生变化的文件；

根据真正发生变化的文件生成对应的Java代理更新文件包，并将生成的Java代理更新文件包上传到更新服务器端进行存储。

3.根据权利要求1所述的Java服务器应用代理自动更新平台，其特征在于，所述Java服务器应用代理信息包括各项目以及所有服务实例的位置信息、更新进度信息、错误数据信息，以及各版本Java代理的源代码位置信息和对应的待更新的Java代理更新文件包信息；其中，所述更新服务器端获取到待更新的Java代理更新文件包后，根据Java代理更新文件包对应的Java服务器应用代理信息向对应的机房区域机房服务器端下发Java代理更新通知。

4.根据权利要求1所述的Java服务器应用代理自动更新平台，其特征在于，各机房区域机房服务器端根据本地Java服务需求分别部署多个更新控制端，通过更新控制端控制对应Java服务代理的更新。

5.根据权利要求1所述的Java服务器应用代理自动更新平台，其特征在于，所述Java服务器应用代理自动更新平台采用代理自动发现机制来自动采集各个机房所有服务器信息，从而实现更新服务器端对所有代理的统一管理。

6.根据权利要求1所述的Java服务器应用代理自动更新平台，其特征在于，所述Java服务器应用代理自动更新平台采用代理更新范围控制机制对待更新的代理进行风险评估，结合量化校验新版本Java服务器应用代理对Java服务器应用的影响，从机房、项目、服务器三个维度控制Java代理的更新范围。

7.根据权利要求6所述的Java服务器应用代理自动更新平台，其特征在于，所述Java服务器应用代理自动更新平台在进行风险评估时，根据Java服务器应用代理文件包的功能作用进行分类，并记录分类后的Java服务器应用代理文件包的更新信息，从而依据Java服务器应用代理文件包的更新信息自动推荐Java服务器应用代理执行更新前的质量校验；其中，Java服务器应用代理文件包分类包括核心、通信、拦截检测及数据处理。

8.根据权利要求1所述的Java服务器应用代理自动更新平台，其特征在于，所述Java服务器应用代理自动更新平台采用代理更新追溯机制来记录各个代理的更新全过程，从而实现对代理更新过程的追溯和管理。

9.一种Java服务器应用代理自动更新装置，其特征在于，所述Java服务器应用代理自动更新装置内置如权利要求1-8任一项所述的Java服务器应用代理自动更新平台。