CN110888663A - 应用更新方法、业务服务器、中转服务器、集群及存储介质 - Google Patents

Abstract

本申请公开应用更新方法、业务服务器、中转服务器、集群及存储介质。其中，一种应用更新方法，包括：为每个第一应用确定与每个第一应用匹配的第二应用；第一应用发送第一指令获取请求；响应于所述第一指令获取请求，判断所述第一应用是否有新版本的更新数据；在确定所述第一应用有新版本的更新数据时，判断第二应用是否已下载第一应用的更新数据；在确定与第一应用匹配的第二应用已下载第一应用的更新数据时，为第一应用生成第一指令；向所述第一应用发送第一指令；当第一应用接收到的第一指令包括从相匹配的第二应用获取第一应用的更新数据的指令时，第一应用发送对第一应用的更新数据的获取请求。

Description

应用更新方法、业务服务器、中转服务器、集群及存储介质

技术领域

本申请涉及大数据技术领域，尤其涉及应用更新方法、业务服务器、中转服务器、集群及存储介质。

背景技术

在智能运维(Artificial Intelligence for IT Operations，缩写为AIOPS)或者应用性能监测等场景中，服务器集群可以部署大量的分布式应用。这里，分布式应用例如可以是采集应用(例如为监测业务服务器的探针)、数据处理应用(例如对探针采集到数据进行分析的代理)等等。采集应用可以将采集的数据发送到数据处理应用。数据处理应用可以将分析结果上传到数据收集服务器。另外，数据收集服务器可以存储采集应用的升级包。

为了对采集应用进行升级，通常将采集应用与数据收集服务器进行直接连接。数据收集服务器可以根据运维人员的操作，将采集应用的升级包直接发送给采集应用。目前，管理人员需要人工判断各服务器中采集应用的版本，并控制数据收集服务器进行升级包的下发。由于需要管理人员判断采集应用的版本和控制升级包的下发，现有的升级方式需要耗费大量的人力。

因此，目前缺少对服务器集群中的应用的自动化更新方式。

发明内容

根据本申请一个方面，提供一种应用更新方法，在集群中执行，所述集群包括多个业务服务器、多个中转服务器和至少一个数据收集服务器，每个业务服务器包括用于采集监测数据的第一应用，每个中转服务器包括用于处理监测数据的第二应用；所述更新方法包括：

数据收集服务器为每个第一应用确定与每个第一应用匹配的第二应用；

每个业务服务器中第一应用向数据收集服务器发送第一指令获取请求；

所述数据收集服务器响应于所述第一指令获取请求，判断所述第一应用是否有新版本的更新数据；

所述数据收集服务器在确定所述第一应用有新版本的更新数据时，判断与所述第一应用匹配的第二应用是否已下载所述第一应用的更新数据；

所述数据收集服务器在确定与所述第一应用匹配的第二应用已下载所述第一应用的更新数据时，为发出所述第一指令获取请求的第一应用生成第一指令，所述第一指令包括下述中至少一个：从相匹配的第二应用获取第一应用的更新数据的指令、备份所述第一应用的指令、更新所述第一应用的指令和运行更新后的第一应用的指令；

向所述第一应用发送所述第一指令；

当第一应用接收到的第一指令包括从相匹配的第二应用获取第一应用的更新数据的指令时，第一应用向相匹配的第二应用发送对第一应用的更新数据的获取请求，以便所述相匹配的第二应用返回第一应用的更新数据。

在一些实施例中，应用更新方法进一步包括：

所述数据收集服务器在确定与所述第一应用匹配的第二应用未下载所述第一应用的更新数据时，向发出所述第一指令获取请求的第一应用返回空指令，并且确定是否存在与相匹配的第二应用对应的表示下载第一应用的更新数据的第二指令；

在确定不存在与相匹配的第二应用对应的表示下载第一应用的更新数据的第二指令时，为相匹配的第二应用生成第二指令，所述第二指令包括：下载第一应用的更新数据的指令；

每个中转服务器中第二应用向数据收集服务器发送第二指令获取请求；

所述数据收集服务器响应于所述第二指令获取请求，确定是否存在与发出第二指令获取请求的第二应用对应的表示下载第一应用的更新数据的第二指令；

所述数据收集服务器在确定存在与所述第二应用对应的表示下载第一应用的更新数据的第二指令时，向所述第二应用返回表示下载第一应用的更新数据的第二指令；

当第二应用接收到的第二指令表示下载第一应用的更新数据的指令时，第二应用向数据收集服务器发送对所述第一应用的更新数据的获取请求，以便所述数据收集服务器返回第一应用的更新数据。

在一些实施例中，应用更新方法进一步包括：

所述数据收集服务器在确定不存在与所述第二应用对应的表示下载第一应用的更新数据的第二指令时，确定第二应用是否有新版本的更新数据；

所述数据收集服务器在确定第二应用有新版本的更新数据时，确定所述第二应用是否有匹配的第一应用；

所述数据收集服务器在所述第二应用存在匹配的第一应用时，判断所述第二应用的新版本是否支持所述匹配的第一应用；

所述数据收集服务器在确定所述第二应用不存在匹配的第一应用或者确定所述第二应用的新版本支持所述匹配的第一应用时，为所述第二应用生成第二指令，所述生成的第二指令包括下述中至少一个：下载第二应用的更新数据的指令、更新第二应用的指令、备份第二应用的指令、运行更新后的第二应用的指令；

所述数据收集服务器向所述第二应用发送所述生成的第二指令；

当第二应用接收到的第二指令包括下载第二应用的更新数据的指令时，所述第二应用向所述数据收集服务器发送对所述第二应用的更新数据的获取请求，以便所述数据收集服务器返回所述第二应用的更新数据。

在一些实施例中，应用更新方法进一步包括：

所述数据收集服务器响应于所述第一指令获取请求，判断是否存在与发出所述第一指令获取请求的第一应用对应的第三指令，所述第三指令不同于第一指令；

在确定不存在所述第三指令时，执行所述判断所述第一应用是否有新版本的更新数据；

所述数据收集服务器响应于所述第二指令获取请求，确定是否存在与发出第二指令获取请求的第二应用对应的第四指令，所述第四指令不同于所述第二指令；

所述数据收集服务器在确定不存在所述第四指令时，执行所述确定是否存在与发出第二指令获取请求的第二应用对应的表示下载第一应用的更新数据的第二指令；

所述第一应用在执行所述第一指令后，向所述数据收集服务器发送第一通知消息，所述第一通知消息用于描述所述第一指令是否执行成功；

所述数据收集服务器响应于所述第一通知消息，在确定所述第一指令执行成功时，将与发出第一通知消息的第一应用对应的第一指令标记为已执行状态；在确定所述第一指令执行失败时，将与发出第一通知消息的第一应用对应的第一指令标记为待执行状态；

所述第二应用在执行所述第二指令后，向所述数据收集服务器发送第二通知消息，所述第二通知消息用于描述所述第二指令是否执行成功；

所述数据收集服务器响应于所述第二通知消息，在确定所述第二指令执行成功时，将与发出第二通知消息的第二应用对应的第二指令标记为已执行状态；在确定所述第二指令执行失败时，将与发出第二通知消息的第二应用对应的第二指令标记为待执行状态。

在一些实施例中，应用更新方法进一步包括：

每个第一应用向与其相匹配的第二应用发送监测数据，以便所述相匹配的所述第二应用对监测数据进行聚合处理，并将聚合结果上传到所述数据收集服务器。

在一些实施例中，应用更新方法进一步包括：

当第二应用接收到的第二指令包括下载第二应用的更新数据的指令时，第二应用从所述数据收集服务器获取所述第二应用的更新数据；

当第二应用接收到的第二指令包括备份所述第二应用的指令时，第二应用进行程序备份操作；

当第二应用接收到的第二指令包括更新所述第二应用的指令时，第二应用利用所述第二应用的更新数据进行更新操作；

当第二应用接收到的第二指令包括运行所述更新后的第二应用时，第二应用进行重启操作，并在完成重启操作后向所述数据收集服务器发送版本注册请求，以便所述数据收集服务器记录更新后的第二应用的版本号。

在一些实施例中，应用更新方法进一步包括：

当第一应用接收到的第一指令包括备份第一应用的指令时，第一应用进行程序备份操作；

当第一应用接收到的第一指令包括更新第一应用的指令时，第一应用基于已下载的第一应用的更新程序进行更新操作；

当第一应用接收到的第一指令包括运行更新后的第一应用的指令时，第一应用进行重启操作或者等待业务服务器的系统重启；

当所述第一应用完成重启后，向所述数据收集服务器发送包含更新后版本号的通知消息，以便所述数据收集服务器响应于所述通知消息为更新后的第一应用分配版本相匹配的第二应用。

在一些实施例中，应用更新方法进一步包括：

每个业务服务器中第一应用向所述数据收集服务器发送第一注册请求，所述第一注册请求包括：所述第一应用的版本号；

所述数据收集服务器响应于第一注册请求，为所述第一应用分配标识；

每个中转服务器中第二应用向所述数据收集服务器发送第二注册请求，所述第二注册请求包括：所述第二应用的版本号；

所述数据收集服务器响应于第二注册请求，为所述第二应用分配标识。

在一些实施例中，每个第一应用包括：用于采集监测数据的第一代理和管理第一代理的第一控制器，每个第二应用包括：用于聚合监测数据的第二代理和管理第二代理的第二控制器；

所述第二应用从所述数据收集服务器获取所述第一应用的更新数据，包括：所述第一控制器从所述数据收集服务器获取所述第一代理的更新数据；

所述第二应用从所述数据收集服务器获取所述第二应用的更新数据，包括：

所述第二控制器从所述数据收集服务器获取所述第二代理的更新数据。

在一些实施例中，应用更新方法进一步包括：

每个第一应用向所述数据收集服务器发送对第二应用的信息获取请求；

所述数据收集服务器响应于所述信息获取请求，返回与第一应用相匹配的第二应用的标识和第二应用的访问地址。

根据本申请一个方面，提供一种应用更新方法，应用于业务服务器的第一应用中，所述应用更新方法包括：

向数据收集服务器发送第一指令获取请求，以便所述数据收集服务器响应于所述第一指令获取请求而返回第一指令，所述第一指令包括下述中至少一个：从相匹配的第二应用获取所述第一应用的更新数据的指令、备份所述第一应用的指令、更新所述第一应用的指令和运行更新后的第一应用的指令；

当第一应用接收到的第一指令为从相匹配的第二应用获取第一应用的更新数据的指令时，第一应用向相匹配的第二应用发送对第一应用的更新数据的获取请求，以便所述相匹配的第二应用返回第一应用的更新数据。

在一些实施例中，应用更新方法进一步包括：

采集与业务服务器有关的监测数据；

所述第一应用向与其相匹配的第二应用发送监测数据，以便所述相匹配的所述第二应用对监测数据进行聚合处理，并将聚合结果上传到所述数据收集服务器。

在一些实施例中，应用更新方法进一步包括：

当第一应用接收到的第一指令包括备份第一应用的指令时，第一应用进行程序备份操作；

当第一应用接收到的第一指令包括更新第一应用的指令时，第一应用基于已下载的第一应用的更新程序进行更新操作；

当第一应用接收到的第一指令包括运行更新后的第一应用的指令时，第一应用进行重启操作或者等待业务服务器的系统重启；

当所述第一应用完成重启后，向所述数据收集服务器发送包含更新后版本号的通知消息，以便所述数据收集服务器响应于所述通知消息为更新后的第一应用分配版本相匹配的第二应用。

在一些实施例中，应用更新方法进一步包括：

向所述数据收集服务器发送第一注册请求，所述第一注册请求包括：所述第一应用的版本号，以便所述数据收集服务器为所述第一应用分配标识；

在执行所述第一指令后，向所述数据收集服务器发送第一通知消息，所述第一通知消息用于描述所述第一指令是否执行成功；

向所述数据收集服务器发送对第二应用的信息获取请求，以便所述数据收集服务器响应于所述信息获取请求，返回与所述第一应用相匹配的第二应用的标识和第二应用的访问地址。

根据本申请一个方面，提供一种应用更新方法，应用于中转服务器的第二应用中，所述应用更新方法包括：

向数据收集服务器发送第二指令获取请求，以便所述数据收集服务器响应于所述第二指令获取请求而返回第二指令，所述第二指令包括下述中至少一个：下载第二应用的更新数据的指令、更新第二应用的指令、备份第二应用的指令、运行更新后的第二应用的指令、下载第一应用的更新程序的指令；

当接收到的第二指令表示下载第一应用的更新数据的指令时，向数据收集服务器发送对所述第一应用的更新数据的获取请求，以便所述数据收集服务器返回第一应用的更新数据。

在一些实施例中，应用更新方法进一步包括：

接收来自第一应用的监测数据；

对监测数据进行聚合处理，并将聚合结果上传到所述数据收集服务器；

当接收到的第二指令包括下载第一应用的更新数据的指令时，从所述数据收集服务器获取所述第一应用的更新数据；

当接收到的第二指令包括下载第二应用的更新数据的指令时，所述第二应用向所述数据收集服务器发送对所述第二应用的更新数据的获取请求，以便所述数据收集服务器返回所述第二应用的更新数据；

当第二应用接收到的第二指令包括备份所述第二应用的指令时，第二应用进行程序备份操作；

当第二应用接收到的第二指令包括更新所述第二应用的指令时，第二应用利用所述第二应用的更新数据进行更新操作；

当第二应用接收到的第二指令包括运行所述更新后的第二应用时，第二应用进行重启操作，并在完成重启操作后向所述数据收集服务器发送版本注册请求，以便所述数据收集服务器记录更新后的第二应用的版本号；

在执行所述第二指令后，向所述数据收集服务器发送第二通知消息，所述第二通知消息用于描述所述第二指令是否执行成功。

根据本申请一个方面，提供一种应用更新方法，应用于数据收集服务器中，所述应用更新方法包括：

为每个第一应用确定与每个第一应用匹配的第二应用；

响应于第一指令获取请求，判断对应的第一应用是否有新版本的更新数据；

在确定所述第一应用有新版本的更新数据时，判断与所述第一应用匹配的第二应用是否已下载所述第一应用的更新数据；

在确定与所述第一应用匹配的第二应用已下载所述第一应用的更新数据时，为发出所述第一指令获取请求的第一应用生成第一指令，所述第一指令包括下述中至少一个：从相匹配的第二应用获取第一应用的更新数据的指令、备份所述第一应用的指令、更新所述第一应用的指令和运行更新后的第一应用的指令；

向所述第一应用发送所述第一指令，以便所述第一应用执行所述第一指令。

在一些实施例中，应用更新方法进一步包括：

在确定与所述第一应用匹配的第二应用未下载所述第一应用的更新数据时，向发出所述第一指令获取请求的第一应用返回空指令，并且确定是否存在与相匹配的第二应用对应的表示下载第一应用的更新数据的第二指令；

在确定不存在与相匹配的第二应用对应的表示下载第一应用的更新数据的第二指令时，为相匹配的第二应用生成第二指令，所述第二指令包括：下载第一应用的更新数据的指令；

响应于第二指令获取请求，确定是否存在与发出第二指令获取请求的第二应用对应的表示下载第一应用的更新数据的第二指令；

在确定存在与所述第二应用对应的表示下载第一应用的更新数据的第二指令时，向所述第二应用返回表示下载第一应用的更新数据的第二指令。

在一些实施例中，应用更新方法进一步包括：

在确定不存在与所述第二应用对应的表示下载第一应用的更新数据的第二指令时，确定第二应用是否有新版本的更新数据；

在确定第二应用有新版本的更新数据时，确定所述第二应用是否有匹配的第一应用；

在所述第二应用存在匹配的第一应用时，判断所述第二应用的新版本是否支持所述匹配的第一应用；

在确定所述第二应用不存在匹配的第一应用或者确定所述第二应用的新版本支持所述匹配的第一应用时，为所述第二应用生成第二指令，所述生成的第二指令包括下述中至少一个：下载第二应用的更新数据的指令、更新第二应用的指令、备份第二应用的指令、运行更新后的第二应用的指令；

所述数据收集服务器向所述第二应用发送所述生成的第二指令。

在一些实施例中，应用更新方法进一步包括：

响应于所述第一指令获取请求，判断是否存在与发出所述第一指令获取请求的第一应用对应的第三指令，所述第三指令不同于第一指令；

在确定不存在所述第三指令时，执行所述判断所述第一应用是否有新版本的更新数据；

响应于所述第二指令获取请求，确定是否存在与发出第二指令获取请求的第二应用对应的第四指令，所述第四指令不同于所述第二指令；

在确定不存在所述第四指令时，执行所述确定是否存在与发出第二指令获取请求的第二应用对应的表示下载第一应用的更新数据的第二指令；

接收第一通知消息，所述第一通知消息用于描述所述第一指令是否执行成功；

在确定所述第一指令执行成功时，将与发出第一通知消息的第一应用对应的第一指令标记为已执行状态；

在确定所述第一指令执行失败时，将与发出第一通知消息的第一应用对应的第一指令标记为待执行状态；

接收第二通知消息，所述第二通知消息用于描述所述第二指令是否执行成功；

在确定所述第二指令执行成功时，将与发出第二通知消息的第二应用对应的第二指令标记为已执行状态；

在确定所述第二指令执行失败时，将与发出第二通知消息的第二应用对应的第二指令标记为待执行状态。根据本申请一个方面，提供一种存储介质，存储有一个或多个程序，所述一个或多个程序包括指令，所述指令当由服务器执行时，使得所述服务器执行根据本申请的应用更新方法。

根据本申请一个方面，提供一种集群，用于执行根据本申请的应用更新方法。

根据本申请一个方面，提供一种业务服务器，用于执行根据本申请的应用更新方法。

根据本申请一个方面，提供一种中转服务器，用于执行根据本申请的应用更新方法。

根据本申请一个方面，提供一种数据收集服务器，用于执行根据本申请的应用更新方法。

综上，根据本申请的集群可以通过数据收集服务器控制第一应用和第二应用的匹配关系，从而能够保证第一应用和第二应用的匹配度(即，使得第一应用能够将监测数据发送到支持第一应用的第二应用中)。

特别说明是，在集群中，多个第一应用的升级时间不同，多个第二应用的升级时间不同，因此集群存在多个第一应用的运行版本不一致，并且多个第二应用的运行版本不一致的情况。本申请的集群通过控制匹配关系，可以使得不同版本的第一应用均可以将采集的数据传输到相匹配的第二应用，而可以避免现有技术的人工升级方式中出现第一应用和第二应用版本不匹配的情况，从而保证集群的运行稳定性。

另外，根据本申请的集群可以由第一应用从数据收集服务器获取第一指令，从而能够自动控制业务服务器从中转服务器下载更新数据。相比于现有技术中人工控制应用升级的方式，根据本申请的集群可以能够避免人工更新应用的麻烦，自动地对业务服务器中第一应用进行更新，并且通过中转服务器向第一应用提供更新数据，能够提高业务服务器获取更新数据的部署效率和提高集群的运行稳定性。

另外，在多个第一应用和第二应用的升级过程中，本申请的集群通过在第一应用升级后重新确定升级后第一应用与第二应用的匹配关系，能够实现第一应用和第二应用的自动匹配，从而提高集群的业务稳定性。

附图说明

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

图1示出了根据本申请一些实施例的应用场景的示意图；

图2示出了根据本申请一些实施例的应用更新方法200的流程图；

图3示出了根据本申请一个实施例的应用更新方法300的流程图；

图4示出了根据本申请一个实施例的双层加密方法400的流程图；

图5示出了根据本申请一个实施例的双层解密方法500的流程图；

图6示出了一个服务器的组成结构图。

具体实施方式

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

图1示出了根据本申请一些实施例的应用场景的示意图。如图1所示，集群100可以包括多个业务服务器(例如图1示出的业务服务器110、120、130和N)、多个中转服务器(例如图1示出的140、150和M)和至少一个数据收集服务器(例如图1示出的160和190)。其中，N和M为正整数。

在集群100中存在多个数据收集服务器时，多个数据收集服务器可以执行分布式应用。业务服务器和中转服务器通常部署在业务处理现场。换言之，业务服务器和中转服务器部署在第一局域网210中。多个数据收集服务器可以部署在第二局域网220中。第一局域网210中服务器可以通过网络200与第二局域网220中服务器进行远程通讯。这里，网络200例如可以是广域网(WAN)。

业务服务器可以执行各种业务程序，本申请对此不做限制。业务服务器可以包括一个或多个第一应用170。这里，第一应用170例如可以对业务服务器进行监控，并采集监控数据。这里，监测数据例如可以包括业务服务器对http请求的响应时间、监测到的异常告警信息等等，本申请对此不做限制。

中转服务器可以包括第二应用180。第二应用180可以对监测数据进行处理，并将处理结果上传到数据收集服务器。这里，第二应用180的例如可以对监测数据进行聚合处理。例如，第二应用180可以对业务服务器一段时间(例如1分钟或者10分钟等)内http请求的响应时间进行均值计算，并将响应时间的均值作为一个聚合结果。又例如，第二应用180可以将一段时间中内容相同的告警消息聚合成一条告警消息，并将聚合成的告警消息作为一条聚合结果。

在一些实施例中，集群100可以包括大量的业务服务器。中转服务器的数量少于业务服务器。每个中转服务器中第二应用180可以接收多个业务服务器中的监测数据。例如，集群100具有2000个业务服务器、60个中转服务器。一个中转服务器可以接收并处理40个业务服务器的监测数据。

综上，根据本申请一些实施例的集群100，通过在业务服务器和数据收集服务器之间部署用于数据预处理的中转服务器，可以使得业务服务器仅进行监测而不需要对监测数据进行聚合等数据预处理，从而节省业务服务器的资源和提高业务处理效率。

另外，本申请的集群100实现了对第一应用170和第二应用180的自动更新，从而提高了对应用更新的效率和准确度。下面结合图2对应用的更新方案进行说明。

图2示出了根据本申请一些实施例的应用的更新方法200的流程图。方法200例如可以在集群100中执行。

如图2所示，在步骤S201中，数据收集服务器160确定与每个第一应用170匹配的第二应用180。这里，不同的业务服务器可以运行不同版本的第一应用170。不同的中转服务器可以运行不同版本的第二应用180。在第一应用170和第二应用180版本匹配时，第二应用180可以正常处理相匹配的第一应用170中的监测数据。数据收集服务器160可以根据各业务服务器中第一应用170的版本号以及中转服务器中第二应用180的版本号，确定第一应用170和第二应用180的匹配关系。例如，数据收集服务器160可以确定业务服务器110中第一应用170与中转服务器140中第二应用180相匹配，以及确定业务服务器120中第一应用170与中转服务器150中第二应用180相匹配。另外，业务服务器可以从数据收集服务器160获取相匹配的第二应用180的信息。这里，第二应用180的信息例如可以包括第二应用180的标识和访问地址，但不限于此。

每个业务服务器中第一应用170可以执行步骤S202，向数据收集服务器160发送第一指令获取请求，即发送对第一指令的获取请求。

在步骤S203中，数据收集服务器160响应于第一指令获取请求，判断第一应用170(即执行步骤S202的第一应用)是否有新版本的更新数据。

在步骤S203确定第一应用有新版本的更新数据时，数据收集服务器160可以执行步骤S204，判断与第一应用170匹配的第二应用是否已下载第一应用的更新数据。

在步骤S204确定与第一应用匹配的第二应用已下载第一应用的更新数据时，数据收集服务器160可以执行步骤S205，为发出第一指令获取请求的第一应用生成第一指令。第一指令例如可以包括下述中至少一个：从相匹配的第二应用获取第一应用的更新数据的指令、备份第一应用的指令、更新第一应用的指令和运行更新后的第一应用的指令。

在步骤S206中，数据收集服务器160向第一应用发送第一指令。

当第一应用170接收到的第一指令包括从相匹配的第二应用获取第一应用的更新数据的指令时，第一应用170可以执行步骤S207，向相匹配的第二应用发送对第一应用的更新数据的获取请求，以便相匹配的第二应用执行步骤S208，返回第一应用的更新数据。

综上，根据本申请的集群100可以通过数据收集服务器160控制第一应用和第二应用的匹配关系，从而能够保证第一应用和第二应用的匹配度(即，使得第一应用能够将监测数据发送到支持第一应用的第二应用中)。

特别说明是，在集群中，多个第一应用的升级时间不同，多个第二应用的升级时间不同，因此集群存在多个第一应用的运行版本不一致，并且多个第二应用的运行版本不一致的情况。本申请的集群100通过控制匹配关系，可以使得不同版本的第一应用均可以将采集的数据传输到相匹配的第二应用，而可以避免现有技术的人工升级方式中出现第一应用和第二应用版本不匹配的情况，从而保证集群的运行稳定性。

另外，根据本申请的集群100可以由第一应用从数据收集服务器160获取第一指令，从而能够自动控制业务服务器从中转服务器下载更新数据。相比于现有技术中人工控制应用升级的方式，根据本申请的集群100可以能够避免人工更新应用的麻烦，自动地对业务服务器中第一应用进行更新，并且通过中转服务器向第一应用提供更新数据，能够提高业务服务器获取更新数据的部署效率和提高集群的运行稳定性。

图3示出了根据本申请一些实施例的应用更新方法300的流程图。方法300例如可以由集群100执行。

在一些实施例中，每个第一应用170可以包括用于采集监测数据的第一代理171和管理第一代理171的第一控制器172。第一代理171可以被认为是部署在业务服务器中的探针(agent)。每个第二应用180包括用于聚合监测数据的第二代理181和管理第二代理181的第二控制器182。

每个业务服务器中第一应用170可以执行步骤S301，向数据收集服务器160发送第一注册请求。第一注册请求例如可以包括第一应用的版本号。这里，第一应用的版本号例如为第一代理171的版本号。另外，第一注册请求还可以包括运行第一应用170的业务服务器的状态信息。状态信息例如包括业务服务器的访问地址、业务服务器的标识、处理器标识、硬盘容量和内存容量等信息。数据收集服务器160可以执行步骤S302，响应于第一注册请求，记录第一应用170的版本号和为第一应用分配标识。这里，通过分配标识，数据收集服务器160可以通过分配的标识区分不同业务服务器中的第一应用170。另外，数据收集服务器160还可以执行步骤S303，向第一应用170发送分配的标识。

每个中转服务器中第二应用180可以执行步骤S304，向数据收集服务器160发送第二注册请求。第二注册请求例如可以包括第二应用180的版本号。这里，第二应用180的版本号例如为第二代理181的版本号。另外，第二注册请求还可以包括运行第二应用180的中转服务器的状态信息。中转服务器的状态信息例如可以包括中转服务器的访问地址、业务服务器的标识、处理器标识、硬盘容量和内存容量等信息。

数据收集服务器160可以执行步骤S305，响应于第二注册请求，记录第二应用的版本号，并且为第二应用180分配标识。这样，数据收集服务器160可以根据分配的标识来区分集群100中各中转服务器。另外，数据收集服务器160可以执行步骤S306，向第二应用180发送分配的标识。

另外，数据收集服务器160可以执行步骤S307，为每个第一应用170确定与每个第一应用170匹配的第二应用180。在一些实施例中，步骤S307可以根据第一应用170的版本号和第二应用180的版本号，确定第一应用170和第二应用180之间的匹配关系，即确定与每个第一应用170匹配的第二应用180。这样，数据收集服务器160通过确定匹配关系，可以合理分配第一应用170的监测数据的发送目标(发送目标为相匹配的第二应用180)。

第一应用170还可以执行步骤S308，向数据收集服务器160发送对第二应用180的信息获取请求。

数据收集服务器160可以执行步骤S309，响应于对第二应用180的信息获取请求，返回与第一应用170相匹配的第二应用180的标识和第二应用180的访问地址。这里，第二应用180的访问地址例如可以包括第二应用180所处中转服务器的IP地址和第二应用180的端口号。

第一应用170可以执行步骤S310，向相匹配的第二应用180发送监测数据。

相匹配的第二应用180可以执行步骤S311，对监测数据进行聚合处理。例如，第二应用180可以通过第二代理181进行聚合处理。另外，第二应用180还可以执行步骤S312，将聚合结果上传到数据收集服务器160。

综上，根据本申请实施例的集群100，通过数据收集服务器160确定第一应用170和第二应用180的匹配关系，可以使得第一应用170能够将监测数据发送相匹配的第二应用180。在一些场景中，集群100中存在多个版本的第一应用170和多个版本的第二应用180。如果第一应用170将监测数据发送到不匹配的第二应用180，第二应用180无法对来自不匹配的第一应用170的监测数据进行聚合处理。因此，根据本申请实施例的集群100可以通过自动控制第一应用170和第二应用180的匹配关系，能够避免第一应用170将监测数据发送到不匹配的第二应用180，进而提高对监测数据的预处理能力。

在一些实施例中，第一应用170可以周期性向数据收集服务器160发送第一指令获取请求，以便从数据收集服务器160获取待执行的第一指令。第二应用180可以周期性向数据收集服务器160发送第二指令获取请求，以便从数据收集服务器160获取待执行的第二指令。简言之，第一应用170和第二应用180均可以周期性从数据收集服务器160获取待执行命令。数据收集服务器160可以确定由第一应用170执行的第一指令，和确定由第二应用180执行的第二指令。例如，数据收集服务器160可以为每个第一应用170维护一个第一指令序列，为每个第二应用180维护一个第二指令序列。数据收集服务器160可以将生成的第一指令缓存在第一指令序列中，将第二指令缓存在第二指令序列中。第一指令的范围例如包括：从相匹配的第二应用180获取第一应用的更新数据的指令、备份第一应用170的指令(即备份未更新的第一应用的指令)、更新第一应用170的指令和运行更新后的第一应用170的指令。第二指令的范围例如包括：下载第二应用180的更新数据的指令、更新第二应用180的指令、备份第二应用180的指令(即备份未更新的第二应用的指令)、运行更新后的第二应用180的指令、下载第一应用170的更新数据的指令。

每个业务服务器中第一应用170可以执行步骤S313，向数据收集服务器160发送第一指令获取请求，即发送对第一指令的获取请求。

在步骤S314中，数据收集服务器160响应于第一指令获取请求，判断是否存在与发出第一指令获取请求的第一应用170对应的第三指令。第三指令不同于第一指令。第三指令可以是升级指令(即第一指令)之外的任意指令。第三指令通常与业务相关，优先级高于第一指令。换言之，在存在第三指令时，数据收集服务器160可以优先返回第三指令。

在步骤S314确定不存在第三指令时，数据收集服务器160可以执行步骤S315，判断第一应用是否有新版本的更新数据。

在步骤S315确定第一应用有新版本的更新数据时，数据收集服务器160可以执行步骤S316，判断与第一应用170匹配的第二应用180是否已下载第一应用的更新数据。

在步骤S316确定与第一应用匹配的第二应用已下载第一应用的更新数据时，数据收集服务器160可以执行步骤S317，为发出第一指令获取请求的第一应用生成第一指令。第一指令例如可以包括下述中至少一个：从相匹配的第二应用获取第一应用的更新数据的指令、备份第一应用的指令、更新第一应用的指令和运行更新后的第一应用的指令。

在步骤S318中，数据收集服务器160可以向第一应用170发送第一指令。

当第一应用170接收到的第一指令包括从相匹配的第二应用获取第一应用的更新数据的指令时，第一应用170可以执行步骤S319，向相匹配的第二应用发送对第一应用的更新数据的获取请求，以便相匹配的第二应用返回第一应用的更新数据。在一些实施例中，第一应用170可以执行一个或多次步骤S319。每个获取请求可以包括第一应用170的更新数据的索引号。每个索引号对应第一应用的更新数据中一个数据块。相匹配的第二应用180可以执行一次或多次步骤S320，返回第一应用170的更新数据。每次执行步骤S320时，第二应用180可以返回一个索引号对应的数据块。

第一应用170还可以对接收到的第一应用170的更新数据进行校验。在校验成功后，第一应用170还可以向数据收集服务器160发送表示下载更新数据成功的通知消息。

当第一应用170接收到的第一指令包括备份第一应用的指令时，第一应用170可以执行步骤S321，进行程序备份操作。第一应用170例如可以由第一控制器172对当前运行的第一代理171进行程序备份。

当第一应用170接收到的第一指令包括更新第一应用的指令时，第一应用170可以执行步骤S322，基于已下载的第一应用的更新数据进行更新操作。例如，在步骤S322中，由第一控制器172利用第一代理171的更新程序替换旧版本的第一代理171。第一应用170还可以向数据收集服务器160发送表示更新成功的通知消息。

当第一应用接收到的第一指令包括运行更新后的第一应用170的指令时，第一应用170可以执行步骤S323，进行重启操作或者等待业务服务器的系统重启。在一些应用场景中，第一应用170不允许自动进行重启，步骤S323可以等待业务服务器的系统重启而实现重启第一应用170。另外，在允许第一应用170进行自动重启的场景中，在步骤S323中，由第一控制器172重启更新后的第一代理171。

另外，在完成重启后，第一应用170可以执行步骤S324，向数据收集服务器160发送包含更新后版本号的通知消息。例如，第一应用170更新前的版本号为V1.0，更新后的版本号为V2.0。

数据收集服务器160可以执行步骤S325，响应于通知消息为更新后的第一应用170分配版本相匹配的第二应用180。例如，业务服务器110中第一应用170在重启之前与中转服务器140中第二应用180相匹配。在完成重启之后，业务服务器110运行版本为V2.0。中转服务器140中第二应用180的版本号为V1.0。数据收集服务器160例如可以确定中转服务器150中第二应用180(版本号为V2.0)与业务服务器110中V2.0版本的第一应用170相匹配。

数据收集服务器160还执行步骤S326，向第一应用170发送重新分配的第二应用180的访问地址和标识。例如，步骤S326可以向业务服务器110中第一应用170发送中转服务器150中第二应用180的标识和访问地址。在此基础上，业务服务器110中第一应用170不再向中转服务器140发送监测数据，而是向中转服务器150发送监测数据，并由中转服务器150中第二应用180对来自业务服务器110中的监测数据进行聚合等预处理操作。这里，预处理操作是指在数据收集服务器160进行数据处理之前进行的处理操作。

综上，根据本申请的集群100可以在第一应用170更新后，自动为更新后第一应用170重新确定相匹配的第二应用180，能够避免第一应用和第二应用版本不匹配的问题，从而能够自动控制第一应用170和第二应用180的版本匹配，进而极大提高集群运行的稳定性。

另外说明的是，在步骤S316确定与第一应用匹配的第二应用未下载第一应用的更新数据时，数据收集服务器160可以向发出第一指令获取请求的第一应用返回空指令(即返回的响应消息中不包括第一指令)。并且，数据收集服务器160可以执行步骤S327，确定是否存在与相匹配的第二应用对应的表示下载第一应用的更新数据的第二指令。换言之，步骤S327可以确定数据收集服务器160是否已经为相匹配的第二应用生成一个表示下载第一应用的更新数据的第二指令。

在步骤S327确定不存在与相匹配的第二应用对应的表示下载第一应用的更新数据的第二指令时，数据收集服务器160可以执行步骤S328，为相匹配的第二应用生成一条第二指令。这条第二指令包括下载第一应用的更新数据的指令。这里，数据收集服务器160可以将生成的第二指令加入到相匹配的第二应用对应的第二指令序列中。

在一些实施例中，第二应用180可以执行步骤S329，向数据收集服务器160发送第二指令获取请求。

数据收集服务器160可以执行步骤S330，确定是否存在与发出第二指令获取请求的第二应用对应的第四指令。第四指令不同于第二指令。第四指令是指优先权高于第二指令的各种由第二应用执行的业务指令。在确定存在第四指令时，数据收集服务器160可以优先返回第四指令。

在步骤S330确定不存在所述第四指令时，数据收集服务器160可以执行步骤S331确定是否存在与发出第二指令获取请求的第二应用对应的、表示下载第一应用的更新数据的第二指令。换言之，步骤S331第二应用对应的第二指令序列中确定是否存在表示下载第一应用的更新数据的第二指令。

在步骤S331确定存在表示下载第一应用的更新数据的第二指令时，数据收集服务器160可以执行步骤S332，向第二应用180返回表示下载第一应用的更新数据的第二指令。

当第二应用180接收到的第二指令表示下载第一应用的更新数据的指令时，第二应用180可以执行步骤S333，向数据收集服务器160发送对第一应用的更新数据的获取请求。数据收集服务器160可以执行步骤S334，返回第一应用的更新数据。

在步骤S331确定不存在表示下载第一应用的更新数据的第二指令时，数据收集服务器160可以执行步骤S335，确定第二应用是否有新版本的更新数据。

在步骤S335确定第二应用有新版本的更新数据时，数据收集服务器160可以执行步骤S336，确定第二应用是否有匹配的第一应用。换言之，步骤S336可以确定是否存在第一应用向第二指令获取请求对应的第二应用发送监测数据。

步骤S336确定第二应用存在匹配的第一应用时，数据收集服务器160可以执行步骤S337，判断第二应用的新版本是否支持匹配的第一应用。

在步骤S336确定第二应用不存在匹配的第一应用，或者在步骤S337确定所述第二应用的新版本支持匹配的第一应用时，数据收集服务器160可以执行步骤S338，为第二应用生成与第二应用的更新有关的第二指令。这里，生成的第二指令包括下述中至少一个：下载第二应用的更新数据的指令、更新第二应用的指令、备份第二应用的指令、运行更新后的第二应用的指令。

数据收集服务器160还可以执行步骤S339，向第二应用发送生成的第二指令。这里，第二指令可以包括第二应用的标识(Command ID)和第二应用180的更新数据的标识，但不限于此。

当第二应用接收到的第二指令包括下载第二应用的更新数据的指令时，第二应用可以执行步骤S340。

第二应用180可以执行一次或多次步骤S340，向数据收集服务器160发送对第二应用180的更新数据的获取请求。获取请求例如可以包括第二指令的标识和第二应用180的更新数据的标识。这里，更新数据的标识例如为更新数据中数据块的索引号。相应地，数据收集服务器160可以执行一次或多次步骤S341，返回第二应用的更新数据。例如，在每次执行步骤S341时，返回与索引号对应的数据块。

第二应用180在获取到第二应用180的完整更新数据后，可以对接收到的更新数据进行校验操作。这里，校验操作例如为MD5等校验方式。在通过校验后，第二应用180可以向数据收集服务器160发送表示下载成功的消息。下载成功的消息可以包括：当前运行的第二应用180的版本号和已下载的更新数据的版本号。第二应用180的更新数据例如为第二代理181的升级包。数据收集服务器160可以响应于接收到下载成功的消息，向第二应用180发送响应消息。响应消息表示数据收集服务器160已接收到下载成功的消息。另外，如果第二应用180未接收到响应消息，会重复执行发送表示下载成功的消息，直到接收到响应消息。

另外，当第二应用接收到的第二指令包括备份第二应用180的指令时，第二应用180可以执行步骤S342，进行程序备份操作。例如，第二应用180可以由第二控制器182将当前运行的第二代理181的程序(即更新前的程序)进行备份操作。

另外，当第二应用接收到的第二指令包括更新第二应用180的指令时，第二应用180可以执行步骤S343，由第二控制器182利用第二代理181的更新数据进行更新操作。例如，第二控制器182可以利用第二代理181的更新数据进行替换操作，从而更新第二代理181。

另外，当第二应用接收到的第二指令包括运行更新后的第二应用180时第二应用180可以执行步骤S344，进行重启操作。例如，在步骤S344中，第二控制器182可以重启更新后的第二代理181。这样，第二应用180可以运行新版本的第二代理181。在完成重启操作后，第二应用180可以执行步骤S345，向数据收集服务器160发送版本注册请求。这里，版本注册请求可以包括第二应用180的更新后的版本号。例如，中转服务器140的第二应用180升级之前版本号为V1.0，更新好的版本号为V3.0。响应于接收到版本注册请求，数据收集服务器160可以记录第二应用180更新后的版本号。例如，数据收集服务器160可以将第二应用180的版本号更新成V3.0。数据收集服务器160在确定业务服务器150中第一应用170的版本号为V3.0时，可以将业务服务器150中第一应用170与中转服务器140中的第二应用180进行匹配，并且向业务服务器150中第一应用170发送中转服务器140发送中转服务器140的第二应用180的标识和访问地址。

在一些实施例中，第一应用在执行所述第一指令后，可以向数据收集服务器160发送第一通知消息，所述第一通知消息用于描述所述第一指令是否执行成功。数据收集服务器响应于第一通知消息，在确定第一指令执行成功时，将与发出第一通知消息的第一应用对应的第一指令标记为已执行状态。在确定第一指令执行失败时，数据收集服务器160将与发出第一通知消息的第一应用对应的第一指令标记为待执行状态。这样，数据收集服务器160又一次接收到第一指令获取请求时，可以向第一应用返回待执行状态的第一指令。

在一些实施例中，第二应用在执行第二指令后，向数据收集服务器160发送第二通知消息。第二通知消息用于描述第二指令是否执行成功。

数据收集服务器160响应于第二通知消息，在确定第二指令执行成功时，将与发出第二通知消息的第二应用对应的第二指令标记为已执行状态。在确定所述第二指令执行失败时，将与发出第二通知消息的第二应用对应的第二指令标记为待执行状态。这样，数据收集服务器160在又一次接收到第二指令获取请求时，可以向第二应用返回待执行状态的第二指令。

综上，根据本申请的集群100，可以通过数据收集服务器160自动控制第一指令和第二指令的生成，从而能够控制多个第一应用和第二应用进行自动升级。另外，在多个第一应用和第二应用的升级过程中，本申请的集群100通过在第一应用升级后重新确定升级后第一应用与第二应用的匹配关系，能够实现第一应用和第二应用的自动匹配，从而提高集群的业务稳定性。

在一些实施例中，上文中涉及发送更新数据的步骤、发送第一指令和第二指令的步骤、以及发送对更新数据的获取请求的步骤，均可以由发送数据方进行双层加密处理和由接收数据方进行双层解密处理。

在一些实施例中，图1中每个中转服务器和每个数据收集服务器均存储有相同的加密包集合。加密包集合包括多个加密包和每个加密包的索引标识，不同加密包对应不同的加解密方式。每个加密包可以包括加密函数和解密函数。这里，加密包集合例如可以对称加密方式的加密包、非对称加密方式的加密包和哈希方式的加密包等等。其中，对称加密方式的加密包例如可以包括：DES包、DESX包、IDEA包、RC4包和AES包等等。非对称加密方式的加密包例如可以包括：RSA包和DSA包等等。

双层加密方式可以实施为方法400。

如图4所示，在步骤S401中，从加密包集合中选定加密包，并基于选定的加密包对未加密数据进行加密，得到未加密数据对应的第一加密数据。这里，步骤S401可以采用随机方式选定加密包，或者采用其他的选择方式选定加密包。又例如，步骤S401可以随机选定索引标识(也可以称为索引号)，并将选定的索引标识对应的加密包作为选定的加密包。例如，步骤S401随机选定的加密包为IDEA包，可以对未加密数据进行IDEA方式的加密。这里，步骤S401加密方式可以认为是双层加密中的第一层加密操作。步骤S401通过随机选定加密包(即随机选定加密算法)，可以提高第一层加密方式的灵活性，和提高第一层加密方式的防破解能力。

在步骤S402中，生成第一随机数和第二随机数。这里，第一随机数例如为13位。第一随机数每一位为十进制数字。例如，第一随机数为“1234567890324”。第二随机数的取值范围在第一随机数的位数的范围内，例如1～13。第二随机数例如为“3”。

在步骤S403中，基于第一随机数，对包含选定的索引标识和第一加密数据的目标数据进行混淆处理(也可以称为第二次加密操作)，得到第二加密数据。目标数据例如可以用A表示，第一随机数例如可以用B表示。目标数据时对选定的索引标识和第一加密数据的拼接结果。索引标识例如为“3”，第一加密数据例如为“xxxxx”。目标数据的数据格式可以表示为“3|xxxxx”。这里，混淆处理的方式例如为异或操作。第二加密数据可以表示为C。C＝A^B

在步骤S404中，基于第二随机数，对第一随机数进行第一循环移位操作，得到第三随机数。这里，第一循环移位操作的移动方向例如为将末尾的数字向首位移动。例如，第二随机数为3，对第一随机数“1234567890324”进行循环移位操作后，得到的第三随机数为“3241234567890”。另外，第一循环移位操作的移动方向也可以被设置为将前端的数字向末尾移动。

在步骤S405中，生成未加密数据对应的加密结果，加密结果(也可以称为加密封装数据包)包括：第三随机数、第二随机数和第二加密数据。例如，加密结果拼接成的字符序列为：“3241234567890”，“3”，C。

另外说明的是，本申请的实施例在每次需要进行加密时，都会重新生成第一随机数、第二随机数和重新选定加密包。这样，即使两次执行方法400的原始数据相同，两次得到的加密结果也不同。换言之，本申请实施例的双层加密方式，可以在第一层加密中随机选定加密算法进行第一次加密，并且在第二层加密中通过随机数(第一随机数)对第一次的加密结果进行第二次加密，以及通过随机数载体(即第二随机数和第三随机数的组合)携带加解密信息(即加解密方法索引)。本申请的实施例由于每次传输数据时执行一次双层加密方式，使得每次数据传输的随机数载体不同，第一次加密的加密算法也不同，从而极大提高了防破解能力。即时两次传输的原始数据相同，每次实际传输的数据包也不同。相应地，每次截获的数据都不同，从而极大提高防破解能力。

综上，根据本申请的双层加密方式能够极大提高传输指令的防篡改能力。在此基础上，本申请的集群可以安全的更新应用，避免被恶意的代码植入导致数据被窃取或者破坏掉应用程序导致业务故障的问题，从而极大提高集群内各服务器的安全性。另外说明的是，相比于单次会话期间加密方式不变的情况，本申请实施例通过在每一次数据传输时执行一次双层加密方式，可以极大提高防破解能力。

在一些实施例中，双层解密方式可以实施为方法500。

如图5所示，在步骤S501中，从加密结果中提取第三随机数、第二随机数和第二加密数据。

在步骤S502中，基于第二随机数，对第三随机数进行第二循环移位操作，得到第一随机数。这里，第二循环移位操作是针对上文中第一循环移位操作的逆向操作。

在步骤S503中，基于第一随机数，对第二加密数据进行解密处理，得到目标数据。目标数据包括选定的加密包的索引标识和第一加密数据。在一些实施例中，目标数据例如可以用A表示，第一随机数例如可以用B表示。第二加密数据可以表示为C。其中，C＝A^B。步骤S503可以利用第一随机数对第二加密数据进行异或操作，从而得到第一加密数据和选定的索引标识。即，A＝C^B。

在步骤S504中，根据选定的加密包的索引标识，从本地存储的加密包集合中取得选定的加密包。

在步骤S505中，基于选定的加密包，对第一加密数据进行解密，得到未加密数据。综上，方法500可以对方法400的加密结果进行解密。

图6示出了一个服务器的组成结构图。图6中服务器可以是业务服务器、中转服务器或者数据收集服务器。如图6所示，该服务器包括一个或者多个处理器(CPU)602、通信模块604、存储器606、用于互联这些组件的通信总线608以及用于接口610。用户接口可以包括输出设备612和输入设备614。输出设备612例如为显示器等设备。输入设备614例如为鼠标、键盘等设备。

处理器602可通过通信模块604接收和发送数据以实现网络通信和/或本地通信。

存储器606可以是高速随机存取存储器，诸如DRAM、SRAM、DDR RAM、或其他随机存取固态存储设备；或者非易失性存储器，诸如一个或多个磁盘存储设备、光盘存储设备、闪存设备，或其他非易失性固态存储设备。

存储器606存储处理器602可执行的指令集，包括：

操作系统616，包括用于处理各种基本系统服务和用于执行硬件相关任务的程序；

应用618，包括用于实现上述应用更新方法的各种程序，这种程序能够实现上述各实施例中的应用更新的流程，比如可以包括图1所示第一应用170或者第二应用180。

另外，本申请的每一个实施例可以通过由服务器执行的数据处理程序来实现。显然，数据处理程序构成了本申请。

此外，通常存储在一个存储介质中的数据处理程序通过直接将程序读取出存储介质或者通过将程序安装或复制到数据处理设备的存储设备(如硬盘和或内存)中执行。因此，这样的存储介质也构成了本发明。存储介质可以使用任何类型的记录方式，例如纸张存储介质(如纸带等)、磁存储介质(如软盘、硬盘、闪存等)、光存储介质(如CD-ROM等)、磁光存储介质(如MO等)等。

因此本申请还公开了一种非易失性存储介质，其中存储有数据处理程序，该数据处理程序用于执行本申请的应用更新方法的任意一种实施例。

另外，本申请所述的方法步骤除了可以用数据处理程序来实现，还可以由硬件来实现，例如，可以由逻辑门、开关、专用集成电路(ASIC)、可编程逻辑控制器和嵌微控制器等来实现。因此这种可以实现本申请所述方法的硬件也可以构成本申请。

以上所述仅为本申请的可选实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种应用更新方法，其特征在于，在集群中执行，所述集群包括多个业务服务器、多个中转服务器和至少一个数据收集服务器，每个业务服务器包括用于采集监测数据的第一应用，每个中转服务器包括用于处理监测数据的第二应用；所述更新方法包括：

数据收集服务器为每个第一应用确定与每个第一应用匹配的第二应用；

每个业务服务器中第一应用向数据收集服务器发送第一指令获取请求；

所述数据收集服务器响应于所述第一指令获取请求，判断所述第一应用是否有新版本的更新数据；

所述数据收集服务器在确定所述第一应用有新版本的更新数据时，判断与所述第一应用匹配的第二应用是否已下载所述第一应用的更新数据；

所述数据收集服务器在确定与所述第一应用匹配的第二应用已下载所述第一应用的更新数据时，为发出所述第一指令获取请求的第一应用生成第一指令，所述第一指令包括下述中至少一个：从相匹配的第二应用获取第一应用的更新数据的指令、备份所述第一应用的指令、更新所述第一应用的指令和运行更新后的第一应用的指令；

向所述第一应用发送所述第一指令；

当第一应用接收到的第一指令包括从相匹配的第二应用获取第一应用的更新数据的指令时，第一应用向相匹配的第二应用发送对第一应用的更新数据的获取请求，以便所述相匹配的第二应用返回第一应用的更新数据。

2.如权利要求1所述的应用更新方法，其特征在于，进一步包括：

所述数据收集服务器在确定与所述第一应用匹配的第二应用未下载所述第一应用的更新数据时，向发出所述第一指令获取请求的第一应用返回空指令，并且确定是否存在与相匹配的第二应用对应的表示下载第一应用的更新数据的第二指令；

在确定不存在与相匹配的第二应用对应的表示下载第一应用的更新数据的第二指令时，所述数据收集服务器为相匹配的第二应用生成第二指令，所述第二指令包括：下载第一应用的更新数据的指令；

每个中转服务器中第二应用向数据收集服务器发送第二指令获取请求；

所述数据收集服务器响应于所述第二指令获取请求，确定是否存在与发出第二指令获取请求的第二应用对应的表示下载第一应用的更新数据的第二指令；

所述数据收集服务器在确定存在与所述第二应用对应的表示下载第一应用的更新数据的第二指令时，向所述第二应用返回表示下载第一应用的更新数据的第二指令；

当第二应用接收到的第二指令表示下载第一应用的更新数据的指令时，第二应用向数据收集服务器发送对所述第一应用的更新数据的获取请求，以便所述数据收集服务器返回第一应用的更新数据。

3.如权利要求2所述的应用更新方法，其特征在于，进一步包括：

所述数据收集服务器在确定不存在与所述第二应用对应的表示下载第一应用的更新数据的第二指令时，确定第二应用是否有新版本的更新数据；

所述数据收集服务器在确定第二应用有新版本的更新数据时，确定所述第二应用是否有匹配的第一应用；

所述数据收集服务器在所述第二应用存在匹配的第一应用时，判断所述第二应用的新版本是否支持所述匹配的第一应用；

所述数据收集服务器在确定所述第二应用不存在匹配的第一应用或者确定所述第二应用的新版本支持所述匹配的第一应用时，为所述第二应用生成第二指令，所述生成的第二指令包括下述中至少一个：下载第二应用的更新数据的指令、更新第二应用的指令、备份第二应用的指令、运行更新后的第二应用的指令；

所述数据收集服务器向所述第二应用发送所述生成的第二指令；

当第二应用接收到的第二指令包括下载第二应用的更新数据的指令时，第二应用向所述数据收集服务器发送对所述第二应用的更新数据的获取请求，以便所述数据收集服务器返回所述第二应用的更新数据。

4.如权利要求3所述的应用更新方法，其特征在于，进一步包括：

所述数据收集服务器响应于所述第一指令获取请求，判断是否存在与发出所述第一指令获取请求的第一应用对应的第三指令，所述第三指令不同于第一指令；

在确定不存在所述第三指令时，执行所述判断所述第一应用是否有新版本的更新数据；

所述数据收集服务器响应于所述第二指令获取请求，确定是否存在与发出第二指令获取请求的第二应用对应的第四指令，所述第四指令不同于所述第二指令；

所述数据收集服务器在确定不存在所述第四指令时，执行所述确定是否存在与发出第二指令获取请求的第二应用对应的表示下载第一应用的更新数据的第二指令；

所述第一应用在执行所述第一指令后，向所述数据收集服务器发送第一通知消息，所述第一通知消息用于描述所述第一指令是否执行成功；

所述数据收集服务器响应于所述第一通知消息，在确定所述第一指令执行成功时，将与发出第一通知消息的第一应用对应的第一指令标记为已执行状态；在确定所述第一指令执行失败时，将与发出第一通知消息的第一应用对应的第一指令标记为待执行状态；

所述第二应用在执行所述第二指令后，向所述数据收集服务器发送第二通知消息，所述第二通知消息用于描述所述第二指令是否执行成功；

所述数据收集服务器响应于所述第二通知消息，在确定所述第二指令执行成功时，将与发出第二通知消息的第二应用对应的第二指令标记为已执行状态；在确定所述第二指令执行失败时，将与发出第二通知消息的第二应用对应的第二指令标记为待执行状态。

5.如权利要求2所述的应用更新方法，其特征在于，进一步包括：

当第二应用接收到的第二指令包括下载第二应用的更新数据的指令时，第二应用从所述数据收集服务器获取所述第二应用的更新数据；

当第二应用接收到的第二指令包括备份所述第二应用的指令时，第二应用进行程序备份操作；

当第二应用接收到的第二指令包括更新所述第二应用的指令时，第二应用利用所述第二应用的更新数据进行更新操作；

当第二应用接收到的第二指令包括运行所述更新后的第二应用时，第二应用进行重启操作，并在完成重启操作后向所述数据收集服务器发送版本注册请求，以便所述数据收集服务器记录更新后的第二应用的版本号。

6.如权利要求1所述的应用更新方法，其特征在于，进一步包括：

当第一应用接收到的第一指令包括备份第一应用的指令时，第一应用进行程序备份操作；

当第一应用接收到的第一指令包括更新第一应用的指令时，第一应用基于已下载的第一应用的更新程序进行更新操作；

当第一应用接收到的第一指令包括运行更新后的第一应用的指令时，第一应用进行重启操作或者等待业务服务器的系统重启；

当所述第一应用完成重启后，向所述数据收集服务器发送包含更新后版本号的通知消息，以便所述数据收集服务器响应于所述通知消息为更新后的第一应用分配版本相匹配的第二应用。

7.如权利要求1所述的应用更新方法，其特征在于，进一步包括：

每个业务服务器中第一应用向所述数据收集服务器发送第一注册请求，所述第一注册请求包括：所述第一应用的版本号；

所述数据收集服务器响应于第一注册请求，为所述第一应用分配标识；

每个中转服务器中第二应用向所述数据收集服务器发送第二注册请求，所述第二注册请求包括：所述第二应用的版本号；

所述数据收集服务器响应于第二注册请求，为所述第二应用分配标识。

8.一种应用更新方法，其特征在于，应用于业务服务器的第一应用中，所述应用更新方法包括：

向数据收集服务器发送第一指令获取请求，以便所述数据收集服务器响应于所述第一指令获取请求而返回第一指令，所述第一指令包括下述中至少一个：从相匹配的第二应用获取所述第一应用的更新数据的指令、备份所述第一应用的指令、更新所述第一应用的指令和运行更新后的第一应用的指令；

当第一应用接收到的第一指令为从相匹配的第二应用获取第一应用的更新数据的指令时，第一应用向相匹配的第二应用发送对第一应用的更新数据的获取请求，以便所述相匹配的第二应用返回第一应用的更新数据。

9.一种应用更新方法，其特征在于，应用于中转服务器的第二应用中，所述应用更新方法包括：

向数据收集服务器发送第二指令获取请求，以便所述数据收集服务器响应于所述第二指令获取请求而返回第二指令，所述第二指令包括下述中至少一个：下载第二应用的更新数据的指令、更新第二应用的指令、备份第二应用的指令、运行更新后的第二应用的指令、下载第一应用的更新程序的指令；

当接收到的第二指令表示下载第一应用的更新数据的指令时，向数据收集服务器发送对所述第一应用的更新数据的获取请求，以便所述数据收集服务器返回第一应用的更新数据。

10.一种应用更新方法，其特征在于，应用于数据收集服务器，所述应用更新方法包括：

为每个第一应用确定与每个第一应用匹配的第二应用；

响应于第一指令获取请求，判断对应的第一应用是否有新版本的更新数据；

在确定所述第一应用有新版本的更新数据时，判断与所述第一应用匹配的第二应用是否已下载所述第一应用的更新数据；

在确定与所述第一应用匹配的第二应用已下载所述第一应用的更新数据时，为发出所述第一指令获取请求的第一应用生成第一指令，所述第一指令包括下述中至少一个：从相匹配的第二应用获取第一应用的更新数据的指令、备份所述第一应用的指令、更新所述第一应用的指令和运行更新后的第一应用的指令；

向所述第一应用发送所述第一指令，以便所述第一应用执行所述第一指令。

Images