CN111104260A - 服务升级的监测方法、装置、服务器及存储介质 - Google Patents
服务升级的监测方法、装置、服务器及存储介质 Download PDFInfo
- Publication number
- CN111104260A CN111104260A CN201911404099.0A CN201911404099A CN111104260A CN 111104260 A CN111104260 A CN 111104260A CN 201911404099 A CN201911404099 A CN 201911404099A CN 111104260 A CN111104260 A CN 111104260A
- Authority
- CN
- China
- Prior art keywords
- server group
- target
- server
- index
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Hardware Redundancy (AREA)
- Debugging And Monitoring (AREA)
Abstract
本公开提供了一种服务升级的监测方法、装置、服务器及存储介质，属于互联网技术领域。方法包括：分别获取目标集群中第一服务器组和第二服务器组的多个目标指标的数据；确定第一服务器组与第二服务器组之间在每个目标指标上的数据差异；若多个目标指标中包括第一指标，则根据预设指标的数据和第一指标的重要程度，确定第二阈值；若第一指标对应的数据差异超过第二阈值，则对第一服务器组中的服务器进行回滚。本公开通过自动根据每个目标指标的数据差异和其对应的阈值来确定升级是否出现异常，若升级出现异常，则自动对服务器进行回滚，实现了自动化监测服务升级及异常恢复，不用人工监测升级过程，极大地降低了人力成本。
Description
技术领域
本公开涉及互联网技术领域，特别涉及一种服务升级的监测方法、装置、服务器及存储介质。
背景技术
为了给用户提供更好的服务体验，需要不断升级来改善服务器的性能或者实现新的功能。
相关技术中，在对目标集群中的服务器进行升级时，需要升级人员持续的监测服务器的各项指标数据来判断升级是否出现异常，如果升级异常，则人工控制将正在升级的服务器回滚到升级前，从而消除故障。
这种做法存在的问题是，由于服务器的升级较为频繁且每次升级持续的时间较长，而每次升级过程都需要升级人员全程监测，因此，整个升级过程的人力成本过高。
发明内容
本公开实施例提供了一种服务升级的监测方法、装置、服务器及存储介质,能够解决相关技术中，服务器升级的人力成本过高的问题。所述技术方案如下：
一方面，提供了一种服务升级的监测方法，所述方法包括：
在对目标集群中的服务器的升级过程中，分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据，所述第一服务器组包括部署有新版本服务的服务器，所述第二服务器组包括部署有旧版本服务的服务器；
确定所述第一服务器组与所述第二服务器组之间在每个所述目标指标上的数据差异；
若所述多个目标指标中包括第一指标，则根据所述多个目标指标中包括的预设指标的数据和所述第一指标的重要程度，确定第二阈值，所述第一指标为数据差异超过其对应的第一阈值的指标；
若所述第一指标对应的数据差异超过第二阈值，则对所述第一服务器组中的服务器进行回滚。
在一种可能的实现方式中，所述分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据之前，所述方法还包括：
获取所述目标集群中的多个服务器的服务版本，根据所述服务版本将所述多个服务器分为所述第一服务器组和所述第二服务器组，然后执行分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据的步骤。
在另一种可能的实现方式中，所述若所述第一指标对应的数据差异超过第二阈值，则对所述第一服务器组中的服务器进行回滚，包括：
若所述第一指标对应的数据差异超过第二阈值，则将所述数据差异通知目标用户；
若接收到所述目标用户反馈的差异异常通知，执行所述对所述第一服务器组中的服务器进行回滚的步骤。
在另一种可能的实现方式中，所述方法还包括：
若接收到所述目标用户反馈的差异正常通知，则将所述第一阈值更新为所述数据差异。
在另一种可能的实现方式中，所述对所述第一服务器组中的服务器进行回滚之前，所述方法还包括：
将所述第一服务器组的服务流量转移到备用的服务器组上，所述备用的服务器组包括部署有旧版本服务的服务器。
在另一种可能的实现方式中，所述对所述第一服务器组中的服务器进行回滚之后，所述方法还包括：
将所述服务流量转移到所述第一服务器组上，重新执行所述分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据的步骤。
在另一种可能的实现方式中，所述多个目标指标的数据为服务器组内多个服务器的平均值。
在另一种可能的实现方式中，所述目标指标包括系统性能指标、应用程序指标、业务数据指标中的至少一种；所述预设指标包括每秒查询率QPS。
在另一种可能的实现方式中，所述方法还包括：
获取所述第一服务器组升级前的所述多个目标指标的数据；
确定所述第一服务器组与所述第一服务器升级前在每个所述目标指标上的数据波动；
若所述多个目标指标中包括第二指标，则根据所述多个目标指标中包括的预设指标的数据和所述第二指标的重要程度，确定第四阈值，所述第二指标为数据波动超过其对应的第三阈值的指标；
若所述第二指标对应的数据波动超过第四阈值，则对所述第一服务器组中的服务器进行回滚。
另一方面，提供了一种服务升级的监测装置，所述装置包括：
数据获取模块，被配置为在对目标集群中的服务器的升级过程中，分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据，所述第一服务器组包括部署有新版本服务的服务器，所述第二服务器组包括部署有旧版本服务的服务器；
数据差异确定模块，被配置为确定所述第一服务器组与所述第二服务器组之间在每个所述目标指标上的数据差异；
阈值确定模块，被配置为若所述多个目标指标中包括第一指标，则根据所述多个目标指标中包括的预设指标的数据和所述第一指标的重要程度，确定第二阈值，所述第一指标为数据差异超过其对应的第一阈值的指标；
服务回滚模块，被配置为若所述第一指标对应的数据差异超过第二阈值，则对所述第一服务器组中的服务器进行回滚。
在一种可能的实现方式中，所述装置还包括：
服务版本获取模块，被配置为获取所述目标集群中的多个服务器的服务版本，根据所述服务版本将所述多个服务器分为所述第一服务器组和所述第二服务器组。
在另一种可能的实现方式中，所述服务回滚模块，被配置为若所述第一指标对应的数据差异超过第二阈值，则将所述数据差异通知目标用户；若接收到所述目标用户反馈的差异异常通知，则对所述第一服务器组中的服务器进行回滚。
在另一种可能的实现方式中，所述装置还包括：
数据更新模块，被配置为若接收到所述目标用户反馈的差异正常通知，则将所述第一阈值更新为所述数据差异。
在另一种可能的实现方式中，所述装置还包括：
流量转移模块，被配置为将所述第一服务器组的服务流量转移到备用的服务器组上，所述备用的服务器组包括部署有旧版本服务的服务器。
在另一种可能的实现方式中，所述流量转移模块，还被配置为将所述服务流量转移到所述第一服务器组上；
所述数据获取模块，配置为若所述服务流量转移到所述第一服务器组上，则重新分别获取所述目标集群中所述第一服务器组和所述第二服务器组的所述多个目标指标的数据。
在另一种可能的实现方式中，所述多个目标指标的数据为服务器组内多个服务器的平均值。
在另一种可能的实现方式中，所述目标指标包括系统性能指标、应用程序指标、业务数据指标中的至少一种；所述预设指标包括每秒查询率QPS。
在另一种可能的实现方式中，所述数据获取模块，还被配置为获取所述第一服务器组升级前的所述多个目标指标的数据；
所述数据差异确定模块，被配置为确定所述第一服务器组与所述第一服务器升级前在每个所述目标指标上的数据波动；
所述阈值确定模块，还被配置为若所述多个目标指标中包括第二指标，则根据所述多个目标指标中包括的预设指标的数据和所述第二指标的重要程度，确定第四阈值，所述第二指标为数据波动超过其对应的第三阈值的指标；
所述服务回滚模块，还被配置为若所述第二指标对应的数据波动超过第四阈值，则对所述第一服务器组中的服务器进行回滚。
另一方面，提供了一种服务器，所述服务器包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现上述任一种可能的实现方式中所述的服务升级的监测方法所执行的操作。
另一方面，提供了一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现上述任一种可能的实现方式中所述的服务升级的监测方法所执行的操作。
本公开实施例提供的技术方案带来的有益效果是：
在本公开实施例中，在对目标集群中的服务器进行升级时，分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据，所述第一服务器组包括部署有新版本服务的服务器，所述第二服务器组包括部署有旧版本服务的服务器；确定所述第一服务器组与所述第二服务器组之间在每个所述目标指标上的数据差异；若所述多个目标指标中包括第一指标，所述第一指标为数据差异超过其对应的第一阈值的指标，则根据所述多个目标指标中包括的预设指标的数据和所述第一指标的重要程度，确定第二阈值；若所述第一指标对应的数据差异超过第二阈值，则对所述第一服务器组中的服务器进行回滚。通过获取第一服务器组和第二服务器组的多个目标指标的数据，根据每个目标指标的数据的数据差异是否超过阈值自动确定升级是否出现异常，若数据差异超过阈值，则自动对第一服务器组中的服务器进行回滚，也即是，能够自动判断升级中出现的异常，并自动进行异常恢复，从而实现自动化监测服务器升级，无需人工监测，释放了大量人力，极大地降低了人力成本。
附图说明
为了更清楚地说明本公开实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本公开实施例提供的一种实施环境的示意图；
图2是本公开实施例提供的一种服务升级的监测方法流程图；
图3是本公开实施例提供的一种服务升级的监测方法流程图；
图4是本公开实施例提供的一种服务升级的监测流程示意图；
图5是本公开实施例提供的一种服务升级的监测流程示意图；
图6是本公开实施例提供的一种服务升级的监测流程示意图；
图7是本公开实施例提供的一种服务升级的监测流程示意图；
图8是本公开实施例提供的一种服务升级的监测装置的框图；
图9是本公开实施例提供的服务器结构示意图。
具体实施方式
为使本公开的目的、技术方案和优点更加清楚，下面将结合附图对本公开实施方式作进一步地详细描述。
为了便于理解本公开的技术过程，首先对一些名词进行解释：
发布分组：当前发布完成的分布式系统内的计算机组。
待发布分组：分布式系统内，还未被新代码部署的计算机组。
Zookeeper(分布式系统的可靠协调系统)：一个开源分布式协调服务，一般用来做集群注册中心，可以自动感知并反馈集群中节点的变化。
部署：指计算机代码在计算机上的发布和运行，分布式系统下部署通过zookeeper进行计算机管理。
发布中检查：是指灰度发布过程中，发布分组与待发布分组的指标区别检查，用于判定已发布机器是否满足预期。
发布后检查：是指部署集群完成后，对比集群发布前后异常指标，用于判定系统部署完成后集群状态是否满足预期。
图1是本公开实施例提供的一种实施环境的示意图。参见图1，该实施环境包括监测服务器101和目标集群中的多台服务器102，监测服务器101和服务器102之间通过无线或者有线网络连接。监测服务器101与服务器102之间可以实现数据传输、消息交互等功能。
在对目标集群中的服务器的升级过程中，监测服务器101首先根据多台服务器102中的服务版本，将目标集群中的多台服务器102分为第一服务器组和第二服务器组，其中第一服务器组中的服务器已经部署有新的服务版本，第二服务器组中的服务器还未部署新的服务器版本，即第二服务器组中服务器的服务版本为旧的服务版本。
将目标集群中的多台服务器进行分组后，监测服务器101分别获取第一服务器组和第二服务器组的多个目标指标的数据，通过第一服务器组和第二服务器组在多个目标指标上的数据差异来确定第一服务器组的升级是否异常，若确定升级出现异常，则自动对第一服务器组中的服务器进行回滚，使第一服务器组中的服务器回退到部署旧版本服务的状态。若升级未出现异常，监测服务器101则认为第一服务器组中的服务器完成升级，且目标集群中的服务器会按照预先的设置从第二服务器组继续选择若干台机器来部署新的服务版本。此时，监测服务器101会根据服务器的服务版本以及部署该服务版本的时间将第二服务器组中的服务器重新分组，此后的监测方法则和第一次分组的监测方法同理，直至目标集群中的服务器均完成升级。
图2是本公开实施例提供的一种服务升级的监测方法的流程图。参见图2，该实施例包括：
步骤201：在对目标集群中的服务器的升级过程中，分别获取目标集群中第一服务器组和第二服务器组的多个目标指标的数据，第一服务器组包括部署有新版本服务的服务器，第二服务器组包括部署有旧版本服务的服务器。
步骤202：确定第一服务器组与第二服务器组之间在每个目标指标上的数据差异。
步骤203：若多个目标指标中包括第一指标，则根据多个目标指标中包括的预设指标的数据和第一指标的重要程度，确定第二阈值，第一指标为数据差异超过其对应的第一阈值的指标。
步骤204：若第一指标对应的数据差异超过第二阈值，则对第一服务器组中的服务器进行回滚。
在一种可能的实现方式中，分别获取目标集群中第一服务器组和第二服务器组的多个目标指标的数据之前，方法还包括：
获取目标集群中的多个服务器的服务版本，根据服务版本将多个服务器分为第一服务器组和第二服务器组，然后执行分别获取目标集群中第一服务器组和第二服务器组的多个目标指标的数据的步骤。
在另一种可能的实现方式中，若第一指标对应的数据差异超过第二阈值，则对第一服务器组中的服务器进行回滚，包括：
若第一指标对应的数据差异超过第二阈值，则将数据差异通知目标用户；
若接收到目标用户反馈的差异异常通知，执行对第一服务器组中的服务器进行回滚的步骤。
在另一种可能的实现方式中，方法还包括：
若接收到目标用户反馈的差异正常通知，则将第一阈值更新为数据差异。
在另一种可能的实现方式中，对第一服务器组中的服务器进行回滚之前，方法还包括：
将第一服务器组的服务流量转移到备用的服务器组上，备用的服务器组包括部署有旧版本服务的服务器。
在另一种可能的实现方式中，对第一服务器组中的服务器进行回滚之后，方法还包括：
将服务流量转移到第一服务器组上，重新执行分别获取目标集群中第一服务器组和第二服务器组的多个目标指标的数据的步骤。
在另一种可能的实现方式中，多个目标指标的数据为服务器组内多个服务器的平均值。
在另一种可能的实现方式中，目标指标包括系统性能指标、应用程序指标、业务数据指标中的至少一种；预设指标包括每秒查询率QPS。
在另一种可能的实现方式中，方法还包括：
获取第一服务器组升级前的多个目标指标的数据；
确定第一服务器组与第一服务器升级前在每个目标指标上的数据波动；
若多个目标指标中包括第二指标，则根据多个目标指标中包括的预设指标的数据和第二指标的重要程度，确定第四阈值，第二指标为数据波动超过其对应的第三阈值的指标；
若第二指标对应的数据波动超过第四阈值，则对第一服务器组中的服务器进行回滚。
在本公开实施例中，在对目标集群中的服务器进行升级时，分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据，所述第一服务器组包括部署有新版本服务的服务器，所述第二服务器组包括部署有旧版本服务的服务器；确定所述第一服务器组与所述第二服务器组之间在每个所述目标指标上的数据差异；若所述多个目标指标中包括第一指标，所述第一指标为数据差异超过其对应的第一阈值的指标，则根据所述多个目标指标中包括的预设指标的数据和所述第一指标的重要程度，确定第二阈值；若所述第一指标对应的数据差异超过第二阈值，则对所述第一服务器组中的服务器进行回滚。通过获取第一服务器组和第二服务器组的多个目标指标的数据，根据每个目标指标的数据的数据差异是否超过阈值自动确定升级是否出现异常，若数据差异超过阈值，则自动对第一服务器组中的服务器进行回滚，也即是，能够自动判断升级中出现的异常，并自动进行异常恢复，从而实现自动化监测服务器升级，无需人工监测，释放了大量人力，极大地降低了人力成本。
图3是本公开实施例提供的一种服务升级的监测方法的流程图。参见图3，该实施例包括：
步骤301：监测服务器获取目标集群中的多个服务器的服务版本，根据服务版本将多个服务器分为第一服务器组和第二服务器组。
其中，第一服务器组包括部署有新版本服务的服务器，第二服务器组包括部署有旧版本服务的服务器。
需要说明的一点是，在对目标集群中的多台服务器进行升级的过程中，可以采用分批升级的方式，即先对目标集群中的第一批服务器部署新的服务器版本，当确认该第一批服务器的升级完成时，再从剩余部分的服务器中选择第二批服务器来部署新的服务版本，直至目标集群中的服务器全都升级完成。
在分批升级的过程中，可以将监测服务器的分组的时机分为下述两种情况：
第一种情况是对集群中的第一批服务器部署新的服务版本后。此时，监测服务器可以获取目标集群中的多个服务器的服务版本，根据服务版本将多个服务器分为第一服务器组和第二服务器组。其中，第一服务器组中的服务器即为第一批部署新的服务版本的服务器。
其中，监测服务器根据服务版本将多个服务器分为第一服务器组和第二服务器组的方式为：监测服务器将服务版本为新的服务版本的服务器分到第一服务器组，将服务版本为旧的服务版本的服务器分到第二服务器组。
例如，参考图4，目标集群中有n台服务器，其中，第一台服务器和第二台服务器中的服务版本为V2，其余的服务器中服务版本为V1，则监测服务器将第一台服务器和第二台服务器分到第一服务器组中，将其余的服务器分到第二服务器组中。
另一种情况是对目标集群中未部署新的服务版本的服务器重新分批部署新的服务版本后。此时，监测服务器可以获取目标集群中的多个服务器的服务版本和部署该服务版本的时间，根据服务版本和部署该服务版本的时间将多个服务器分为第一服务器组和第二服务器组。
其中，监测服务器根据服务版本和部署该服务版本的时间将多个服务器分为第一服务器组和第二服务器组的方式为：监测服务器将部署旧的服务版本的服务器分到第二服务器组，将部署新的服务版本的服务器中部署时间为最新时间的服务器分到第一服务器组。
例如，当上述例子中第一台服务器和第二台服务器完成升级，且第三台服务器和第四台服务器中部署了新的服务版本后，监测服务器根据服务版本可将其余的服务器分到第二服务器组中。对于这四台服务器，监测服务器可以获取这四台服务器中服务版本的部署时间，假设监测服务器获取到第一台服务器和第二台服务器中新服务版本的部署时间为00:00，第三台服务器和第四台服务器中新服务版本的部署时间为00:10，则监测服务器将第三台服务器和第四台服务器分到第一服务器组，不再对第一台服务器和第二台服务器进行分组。
在本公开实施例中，监测服务器通过监测目标集群中服务器的服务版本实现自动将目标集群中的多台服务器分为第一服务器组和第二服务器组，第一服务器组包括部署有新版本服务的服务器，第二服务器组包括部署有旧版本服务的服务器，从而后续可根据两个服务器组的数据差异来判断升级是否出现异常。另外，监测服务器通过在分组时结合服务器中部署服务版本的时间，从而可以避免将已经完成升级的服务器重新分到第一服务器组中导致重复检查的问题，从而提高了监测效率。另一方面，假设监测服务器没有结合部署服务版本的时间而导致已经完成升级的服务器重新分到第一服务器组，当判断第一服务器组中的服务器升级异常时，监测服务器则可能将已经完成升级的服务器连同升级异常的服务器一起回滚到旧的服务版本，从而极大地降低目标集群的服务升级效率。所以，监测服务器通过结合部署服务版本的时间来进行分组，在提高监测效率的同时，也提高了目标集群服务升级的效率。
需要说明的另一点是，监测服务器获取目标集群中的多个服务器的服务版本和部署该服务版本的时间的方式可以为：监测服务器在升级服务开始前，通过zookeeper来获取多个服务器的服务版本和部署该服务版本的时间，之后，通过zookeeper来监控目标集群中多个服务器的状态，若发现某个服务器的服务版本改变，则通过zookeeper获取该服务器的服务版本和部署该服务版本的时间。
步骤302：监测服务器分别获取目标集群中第一服务器组和第二服务器组的多个目标指标的数据。
其中，目标指标包括系统性能指标、应用程序指标、业务数据指标中的至少一种。系统性能指标包括CPU(Central Processing Unit，中央处理器)的使用率、内存的使用率、磁盘的使用率等。应用程序指标包括应用程序抛出的异常数量、HTTP(Hyper TextTransport Protocol，超文本传输协议)错误率等。数据业务指标包括调用次数、平均响应时间、平均执行时间等，当然，数据业务指标还包括一些更加具象化的指标，例如，订单数、GMV(Gross Merchandise Volume，网站成交金额)数量，点击次数等。
监测服务器分别获取目标集群中第一服务器组和第二服务器组的多个目标指标的数据的方式为：监测服务器在预设时长内周期性获取目标集群中第一服务器组和第二服务器组的多个目标指标的数据。
预设时长可以根据需要设置，例如，可以设置为5分钟、10分钟等，在预设时长内获取数据的周期也可以根据需要设置，例如，可以设置为1分钟、2分钟等。本公开对预设时长和获取数据的周期不做限制。
需要说明的一点是，预设时长实际上可理解为监测服务器对每批升级的服务器的监测时长，且在预设时长内获取数据的周期是监测服务器对每批升级的服务器的判断周期。监测服务器根据在预设时长内获取的目标指标的数据来判断升级是否出现异常，只有在整个预设时长内的每个判断周期中，每个目标指标的数据都没有出现异常，监测服务才认为第一服务器组中的服务器完成升级。由于第一服务器组中的服务器在部署了新的服务版本后，目标指标的数据通常不会立马显示出异常，因此，通过设置预设时长，且监测服务器在整个预设时长内周期性获取目标指标的数据，基于该数据来进行升级异常判断，从而可以做到有效监测。并且，监测服务器获取目标指标的数据的周期设定的较小，例如，1分钟，以便于监测服务器可以尽早地发现升级异常。
参考图5，监测服务器通过分组采集第一服务器组和第二服务器组的多个目标指标的数据，方便后续根据两组服务器的数据差异来判断升级是否出现异常。并且，通过分钟级步进采集实现尽早地发现升级异常。
需要说明的另一点是，多个目标指标的数据为服务器组内多个服务器的平均值。也即是，将第一服务器组的每个目标指标的数据除以第一服务器组中服务器的台数得到的平均值作为第一服务器组的每个目标指标的数据；将第二服务器组的每个目标指标的数据除以第二服务器组中服务器的台数得到的平均值作为第二服务器组的每个目标指标的数据。并且，第一服务器组和第二服务器组的每个目标指标的数据在求平均值之前已经进行了归一化处理。
通过对多个目标指标的数据进行归一化处理和对服务器的台数求平均，实现了数据均匀化，可以避免因流量，服务器数量等因素影响指标数据的差异，导致后续基于数据差异来判断升级是否异常时判断不准确的问题。
步骤303：监测服务器确定第一服务器组与第二服务器组之间在每个目标指标上的数据差异。
监测服务器确定第一服务器组与第二服务器组之间在每个目标指标上的数据差异的方式可以有以下两种：
在第一种方式中，对于任一个目标指标，监测服务器将第一服务器组的该目标指标的数据与第二服务器组的该目标指标的数据的差的绝对值作为该目标指标的数据差异。
例如，对于CPU的使用率这个指标，若第一服务器组的CPU的使用率为80％，第二服务器组的CPU的使用率为60％，则数据差异为20％。
在第二种方式中，对于任一个目标指标，监测服务器先取第一服务器组的该目标指标的数据与第二服务器组的该目标指标的数据的差的绝对值，将差的绝对值再除以第二服务器组的该目标指标的数据，得到该目标指标的数据差异。
例如，还是采用上述例子，通过第二种方式得到的数据差异则为33.3％。
在本公开中，以通过第二种方式计算数据差异为例进行说明。
需要说明的一点是，数据差异可以采用任一种数值表示形式，上述数据差异只是通过百分比的形式做实例说明，当然，还可以用能够表示差异程度的其他数值形式来表示，本公开对此不做限制。
在一种可能的实现方式中，监测服务器在执行步骤303之前，还要先比较每个目标指标的数据在第一服务器组和第二服务器组上的大小，根据比较结果确定是否执行步骤303。实施方式为：对于任一个目标指标，监测服务器比较第一服务器组的该目标指标的数据是否大于第二服务器组的该目标指标的数据，若比较结果为大于，监测服务器则确定该目标指标是否越大越好，若该目标指标越大越好，监测服务器则认为该目标指标正常，不再确定第一服务器组与第二服务器组之间在该目标指标上的数据差异；若比较结果为小于，监测服务器则确定该目标指标是否越小越好，若该目标指标越小越好，监测服务器则认为该目标指标正常，不再确定第一服务器组与第二服务器组之间在该目标指标上的数据差异。
在一种可能的实现方式中，监测服务器中可以存储两个目标指标列表，第一个目标指标列表用于存储指标数据越大越好的目标指标，例如，数据吞吐量、调用次数等。第二个目标指标列表用于存储指标数据越小越好的目标指标，例如，平均响应时间，平均执行时间等。相应的，对于任一个目标指标，若该目标指标的比较结果为大于，监测服务器则从第一个目标指标列表中查找该目标指标，若查找到，则确定该目标指标越大越好；若该目标指标的比较结果为小于，监测服务器则从第二个目标指标列表中查找该目标指标，若查找到，则确定该目标指标越小越好。
在本公开实施例中，对于任一个目标指标，监测服务器通过先判断第一服务器组在该目标指标的数据相对于第二服务器组在该目标指标的数据是否往好的方向偏移，若该目标指标是往好的方向偏移，则不再确定该目标指标的数据差异。由于数据差异是用来判断服务升级异常的，而通常情况下，若一个目标指标的数据是往好的方向偏移的时候，该目标指标是正常的，所以通过在确定出一个目标指标是往好的方向偏移时，不再确定该目标指标的数据差异可以节省监测服务器的资源。
步骤304：若多个目标指标中包括第一指标，监测服务器则根据多个目标指标中包括的预设指标的数据和第一指标的重要程度，确定第二阈值，第一指标为数据差异超过其对应的第一阈值的指标。
其中，预设指标包括QPS(Queries Per Second，每秒查询率)。
在该步骤之前，监测服务器首先要获取每个目标指标对应的第一阈值。
在一种可能的实现方式中，指标数据库中存储有目标指标以及目标指标对应的第一阈值，相应的，监测服务器可以从指标数据库中获取每个目标指标对应的第一阈值。其中，指标数据库中的每个目标指标的第一阈值可以是用户预先设置的，也可以是监测服务器根据每个目标指标的历史数据差异更新在指标数据库中的。
需要说明的一点是，在每个判断周期，对于多个目标指标中的任一个指标，若该目标指标对应的数据差异未超过其对应的第一阈值，监测服务器则认为升级正常；若监测服务器没有获取到该目标指标对应的第一阈值，监测服务器也认为升级正常，并且将该目标指标对应的数据差异作为该目标指标的第一阈值存储在指标数据库中，从而在下个判断周期可以基于该第一阈值对该目标指标进行判断。
若多个目标指标中包括第一指标，第一指标为数据差异超过其对应的第一阈值的指标，监测服务器则认为升级可能出现异常，且根据多个目标指标中包括的预设指标的数据和第一指标的重要程度，确定第二阈值。
其中，监测服务器根据多个目标指标中包括的预设指标的数据和第一指标的重要程度，确定第二阈值的方式为：监测服务器获取基准阈值，若预设指标的数据超过其对应的第五阈值，则将该预设指标对应的第一系数确定为基准阈值的第一系数；根据第一指标的重要程度确定基准阈值的第二系数；将基准阈值与第一系数以及第二系数的乘积作为第二阈值。
其中，基准阈值可以为用户预先设置的，也可以为第一指标对应的第一阈值。第五阈值和第一系数为用户预先设置的。预设指标可以为一个也可以为多个，每个预设指标均有其对应的第五阈值和第一系数。若预设指标为多个，监测服务器则判断每个预设指标的数据是否超过其对应的第五阈值，若有多个预设指标的数据超过其对应的第五阈值时，监测服务器则根据该多个预设指标确定出多个第一系数。相应的，第二阈值则是基准阈值与第二系数以及多个第一系数的乘积。
在确定第二阈值之前，监测服务器还需要先确定第一指标的重要程度，从而根据第一指标的重要程度确定基准阈值的第二系数。在一种可能的实现方式中，第一指标的重要程度是根据当前提供流量服务的接口的重要等级来确定的。相应的，监测服务器确定第一指标的重要程度的方式为：监测服务器获取当前提供流量服务的接口；根据该接口和接口与重要等级的对应关系，确定该接口对应的重要等级；将该重要等级作为第一指标的重要程度。其中，接口与重要等级的对应关系可以配置在监测服务器中，也可以存储在指标数据库中。
监测服务器确定出第一指标的重要程度后，根据第一指标的重要程度确定基准阈值的第二系数的方式为：监测服务器根据第一指标的重要程度以及重要等级与第二系数的对应关系，确定第一指标的重要程度对应的第二系数，将该第二系数作为基准阈值的第二系数。
下面举例说明第二阈值的确定方法。假设基准阈值为30％，第一指标为CPU的使用率，预设指标为QPS，预设指标当前的值为25，预设指标对应的第五阈值为20，即预设指标当前的值大于第二阈值，预设指标对应的第一系数为0.8，当前提供流量服务的接口的重要等级为“非核心”，重要等级“非核心”对应的第二系数为1.5，则监测服务器确定第一指标的第二阈值的步骤为：监测服务器获取基准阈值30％；将QPS对应的第一系数0.8作为基准阈值的第一系数；将当前提供流量服务的接口的重要等级“非核心”对应的第二系数1.5作为基准阈值的第二系数；将30％*0.8*1.5得到的值36％作为第二阈值。
在本公开实施例中，通过根据第一指标的重要程度和预设指标当前的值来确定第二阈值，且第一指标的重要程度是根据当前提供流量服务的接口的重要程度确定的，即第二阈值不是一个固定的值，而是根据当前提供流量服务的接口的重要程度和预设指标当前的值来动态确定的，后续基于第二阈值来判断升级是否异常，从而实现根据流量的变化动态判定升级中的异常，提高了异常判断的准确率。
需要说明的一点是，若在整个预设时长内，每个目标指标的数据差异均未超过其对应的第一阈值，监测服务器则认为第一服务器组中的服务器完成升级。然后执行步骤301。另外，继续参考图5，监测服务器还会给目标用户发送升级完成通知，用于提示目标用户本批第一服务器组中的服务器已经完成升级。
步骤305：若第一指标对应的数据差异超过第二阈值，监测服务器则将数据差异通知目标用户。
其中，目标用户为预先设置的，例如，目标用户可以为负责目标集群的服务升级的监测人员。该步骤包括：若第一指标对应的数据差异超过第二阈值，监测服务器则确定升级出现异常，并且将该第一指标的数据差异和第二阈值以及监测服务器做出的异常判断结果通知目标用户。
在本公开实施例中，监测服务器通过在确定升级出现异常时，将与升级异常相关的信息及时通知目标用户，从而用户可以根据这些信息对监测服务器确定的升级异常，做进一步的异常判断，从而提高了服务升级中的异常判断的准确率。
在一种可能的实现方式中，若第一指标对应的数据差异超过第二阈值，监测服务器则确定升级出现异常，并对目标集群中的升级服务进行拦截。拦截的时间和通知目标用户的时间没有先后顺序的要求。
在本公开实施例中，监测服务器通过在确定升级出现异常时，对目标集群中的升级服务进行拦截，可以避免在出现升级异常后目标集群中的服务器仍继续进行升级，从而造成更大的升级故障。
步骤306：若接收到目标用户反馈的差异正常通知，监测服务器则将第一阈值更新为数据差异。
在本公开实施例中，若接收到目标用户反馈的差异正常通知，监测服务器则认为第一指标对应的第一阈值的设值不合理，然后将第一指标对应的第一阈值更新为该数据差异。从而，在下一判断周期，根据更新后的第一阈值来对该第一指标进行异常判断。
监测服务器通过根据目标用户的反馈来不断修正目标指标对应的第一阈值，即通过机器学习的方式不断地调整判断标准，从而后续在基于第一阈值对第一指标进行异常判断时，可以做出更准确的异常判断，提高了服务升级的异常监测的准确率。
监测服务器在判断出现异常时，将升级异常通知目标用户，在接收到目标用户反馈的差异正常通知时，认为此次升级检查结果报出不准确，通过提供反馈入口的方式，记录不准确时的指标详情，后续的检测就会避免同样的不准确的出现。
需要说明的一点是，监测服务器在接收到用户反馈的差异正常通知时，需要放开对目标集群服务升级的拦截，从而目标集群可以继续进行服务升级。
步骤307：若接收到目标用户反馈的差异异常通知，监测服务器则对第一服务器组中的服务器进行回滚。
在一种可能的实现方式中，监测服务器对第一服务器组中的服务器进行回滚之前，先将第一服务器组的服务流量转移到备用的服务器组上。
其中，备用的服务器组包括部署有旧版本服务的服务器。备用的服务器组是在目标集群升级前就准备好的，即在对目标集群进行升级服务前，先对集群进行容量扩充，增加一定数量的备用服务器，组成备用服务器组，且备用的服务器组中服务器的数量可以大于目标集群中服务器的数量，也可以与目标集群中服务器的数量相同，当然，还可以小于目标集群中服务器的数量，例如，备用服务器的数量可以与目标集群中升级的每批服务器的数量相同。本公开对备用服务器组中服务器的数量不做限制，备用的服务器组只要能够承受目标集群的所有服务流量即可。
在本公开实施例中，监测服务器通过在接收到目标用户反馈的差异异常通知时，先将第一服务器组的服务流量转移到备用的服务器组上，从而可以保证在升级异常时流量服务的正常进行。
监测服务器对第一服务器组中的服务器进行回滚之后，再将服务流量转移到第一服务器组上，然后重新执行步骤302。
例如，参考图6，目标集群中有n台待升级的服务器，备用的服务器组中服务器的数量为m台。在对目标集群中的一批服务器升级的过程中，对目标集群进行发布中检查，若该批服务器的升级检查失败，则将该批服务器中的服务流量转移到备用的服务器组上，然后对该批服务器进行回滚。回滚之后，再将备用的服务器组上的服务流量转移到该批服务器上，释放备用的服务器组，然后重新对目标集群进行服务升级。并且，在目标集群中的所有服务器均已部署新的服务版本后，对目标集群的整体进行发布后检查，若升级检查失败，则将目标集群整体的服务流量转移到备用的服务器组上，然后对目标集群中所有服务器进行回滚。回滚之后，再将备用的服务器组上的服务流量转移到目标集群的所有服务器上，释放备用的服务器组，然后重新对目标集群进行服务升级。
在一种可能的实现方式中，监测服务器通过zookeeper将第一服务器组的服务流量转移到备用的服务器组上。参考图7，实施步骤包括：监测服务器通过zookeeper向服务的调用方广播消息，消息中携带升级异常的服务器的标识以及备用的服务器的标识，服务调用方在接收到广播消息后，根据升级异常的服务器的标识以及备用的服务器的标识，禁用升级异常的服务器，同时启用备用的服务器。
监测服务器将备用的服务器组上的服务流量转移到第一服务器组上的方法同理，此处不再赘述。
在本公开实施例中，在确定出现升级异常时，监测服务器通过zookeeper将第一服务器组的服务流量转移到备用的服务器组上，利用zookeeper的快速协调能力，实现异常服务器组与备用服务器组之间的无缝切换，即在毫秒级的时间内自动摘除异常服务器和容量平衡，保障服务容量足以承载所有请求压力的同时达到了毫秒级恢复故障的效果。
需要说明的一点是，上述方案是基于升级服务器组和待升级服务器组的多个目标指标的数据差异来判断升级服务器组是否出现升级异常的，在另一种可能的实现方式中，还可以基于升级服务器组和升级服务器组升级前在多个目标指标上数据波动来判断升级服务器组是否出现升级异常，该方法的实现步骤包括：监测服务器获取第一服务器组升级前的多个目标指标的数据；监测服务器确定第一服务器组与第一服务器升级前在每个目标指标上的数据波动；若多个目标指标中包括第二指标，监测服务器则根据多个目标指标中包括的预设指标的数据和第二指标的重要程度，确定第四阈值，第二指标为数据波动超过其对应的第三阈值的指标；若第二指标对应的数据波动超过第四阈值，监测服务器则对第一服务器组中的服务器进行回滚。
需要说明的另一点是，基于升级服务器组和升级服务器组升级前在多个目标指标上数据波动，判断升级服务器组是否出现升级异常的方案中各个步骤的实现方式与基于升级服务器组和待升级服务器组的多个目标指标的数据差异来判断升级服务器组是否出现升级异常中，对应步骤的实现方式同理，此处不再赘述。
需要说明的再一点是，还可以将这两种方案结合起来判断升级服务器组是否出现升级异常，即同时基于升级服务器组和升级服务器组升级前在多个目标指标上数据波动，与升级服务器组和待升级服务器组的多个目标指标的数据差异，来判断第一服务器组的升级是否出现异常。判断的方式为：当基于两种判断方法中的任意一种确定升级出现异常，则确定升级出现异常，只有基于两种判断方法都确定升级无异常时，升级才是成功的。
在本公开实施例中，在对目标集群中的服务器进行升级时，分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据，所述第一服务器组包括部署有新版本服务的服务器，所述第二服务器组包括部署有旧版本服务的服务器；确定所述第一服务器组与所述第二服务器组之间在每个所述目标指标上的数据差异；若所述多个目标指标中包括第一指标，所述第一指标为数据差异超过其对应的第一阈值的指标，则根据所述多个目标指标中包括的预设指标的数据和所述第一指标的重要程度，确定第二阈值；若所述第一指标对应的数据差异超过第二阈值，则对所述第一服务器组中的服务器进行回滚。通过获取第一服务器组和第二服务器组的多个目标指标的数据，根据每个目标指标的数据的数据差异是否超过阈值自动确定升级是否出现异常，若数据差异超过阈值，则自动对第一服务器组中的服务器进行回滚，也即是，能够自动判断升级中出现的异常，并自动进行异常恢复，从而实现自动化监测服务器升级，无需人工监测，释放了大量人力，极大地降低了人力成本。
图8是本公开实施例提供的一种服务升级的监测装置的框图。参见图8，该实施例包括：
数据获取模块801，被配置为在对目标集群中的服务器的升级过程中，分别获取目标集群中第一服务器组和第二服务器组的多个目标指标的数据，第一服务器组包括部署有新版本服务的服务器，第二服务器组包括部署有旧版本服务的服务器。
数据差异确定模块802，被配置为确定第一服务器组与第二服务器组之间在每个目标指标上的数据差异。
阈值确定模块803，被配置为若多个目标指标中包括第一指标，则根据多个目标指标中包括的预设指标的数据和第一指标的重要程度，确定第二阈值，第一指标为数据差异超过其对应的第一阈值的指标。
服务回滚模块804，被配置为若第一指标对应的数据差异超过第二阈值，则对第一服务器组中的服务器进行回滚。
在一种可能的实现方式中，装置还包括：
服务版本获取模块，被配置为获取目标集群中的多个服务器的服务版本，根据服务版本将多个服务器分为第一服务器组和第二服务器组。
在另一种可能的实现方式中，服务回滚模块804，被配置为若第一指标对应的数据差异超过第二阈值，则将数据差异通知目标用户；若接收到目标用户反馈的差异异常通知，则对第一服务器组中的服务器进行回滚。
在另一种可能的实现方式中，装置还包括：
数据更新模块，被配置为若接收到目标用户反馈的差异正常通知，则将第一阈值更新为数据差异。
在另一种可能的实现方式中，装置还包括：
流量转移模块，被配置为将第一服务器组的服务流量转移到备用的服务器组上，备用的服务器组包括部署有旧版本服务的服务器。
在另一种可能的实现方式中，流量转移模块，还被配置为将服务流量转移到第一服务器组上；
数据获取模块801，配置为若服务流量转移到第一服务器组上，则重新分别获取目标集群中第一服务器组和第二服务器组的多个目标指标的数据。
在另一种可能的实现方式中，多个目标指标的数据为服务器组内多个服务器的平均值。
在另一种可能的实现方式中，目标指标包括系统性能指标、应用程序指标、业务数据指标中的至少一种；预设指标包括每秒查询率QPS。
在另一种可能的实现方式中，数据获取模块801，还被配置为获取第一服务器组升级前的多个目标指标的数据；
数据差异确定模块802，被配置为确定第一服务器组与第一服务器升级前在每个目标指标上的数据波动；
阈值确定模块803，还被配置为若多个目标指标中包括第二指标，则根据多个目标指标中包括的预设指标的数据和第二指标的重要程度，确定第四阈值，第二指标为数据波动超过其对应的第三阈值的指标；
服务回滚模块804，还被配置为若第二指标对应的数据波动超过第四阈值，则对第一服务器组中的服务器进行回滚。
在本公开实施例中，在对目标集群中的服务器进行升级时，分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据，所述第一服务器组包括部署有新版本服务的服务器，所述第二服务器组包括部署有旧版本服务的服务器；确定所述第一服务器组与所述第二服务器组之间在每个所述目标指标上的数据差异；若所述多个目标指标中包括第一指标，所述第一指标为数据差异超过其对应的第一阈值的指标，则根据所述多个目标指标中包括的预设指标的数据和所述第一指标的重要程度，确定第二阈值；若所述第一指标对应的数据差异超过第二阈值，则对所述第一服务器组中的服务器进行回滚。通过获取第一服务器组和第二服务器组的多个目标指标的数据，根据每个目标指标的数据的数据差异是否超过阈值自动确定升级是否出现异常，若数据差异超过阈值，则自动对第一服务器组中的服务器进行回滚，也即是，能够自动判断升级中出现的异常，并自动进行异常恢复，从而实现自动化监测服务器升级，无需人工监测，释放了大量人力，极大地降低了人力成本。
上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。
需要说明的是：上述实施例提供的服务升级的监测装置在进行服务升级监测时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的服务升级的监测装置与服务升级的监测方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
图9是本公开实施例提供的一种服务器的结构示意图，该服务器900可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(central processingunits，CPU)901和一个或一个以上的存储器902，其中，所述存储器902中存储有至少一条指令，所述至少一条指令由所述处理器901加载并执行以实现上述各个方法实施例提供的方法。当然，该服务器还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该服务器还可以包括其他用于实现设备功能的部件，在此不做赘述。
在示例性实施例中，还提供了一种计算机可读存储介质，例如包括指令的存储器，上述指令可由终端中的处理器执行以完成下述实施例中服务升级的监测方法。例如，所述计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述仅为本公开的可选实施例，并不用以限制本公开，凡在本公开的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。
Claims (12)
1.一种服务升级的监测方法，其特征在于，所述方法包括：
在对目标集群中的服务器的升级过程中，分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据，所述第一服务器组包括部署有新版本服务的服务器，所述第二服务器组包括部署有旧版本服务的服务器；
确定所述第一服务器组与所述第二服务器组之间在每个所述目标指标上的数据差异；
若所述多个目标指标中包括第一指标，则根据所述多个目标指标中包括的预设指标的数据和所述第一指标的重要程度，确定第二阈值，所述第一指标为数据差异超过其对应的第一阈值的指标；
若所述第一指标对应的数据差异超过第二阈值，则对所述第一服务器组中的服务器进行回滚。
2.根据权利要求1所述的方法，其特征在于，所述分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据之前，所述方法还包括：
获取所述目标集群中的多个服务器的服务版本，根据所述服务版本将所述多个服务器分为所述第一服务器组和所述第二服务器组，然后执行分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据的步骤。
3.根据权利要求1所述的方法，其特征在于，所述若所述第一指标对应的数据差异超过第二阈值，则对所述第一服务器组中的服务器进行回滚，包括：
若所述第一指标对应的数据差异超过第二阈值，则将所述数据差异通知目标用户；
若接收到所述目标用户反馈的差异异常通知，执行所述对所述第一服务器组中的服务器进行回滚的步骤。
4.根据权利要求3所述的方法，其特征在于，所述方法还包括：
若接收到所述目标用户反馈的差异正常通知，则将所述第一阈值更新为所述数据差异。
5.根据权利要求1所述的方法，其特征在于，所述对所述第一服务器组中的服务器进行回滚之前，所述方法还包括：
将所述第一服务器组的服务流量转移到备用的服务器组上，所述备用的服务器组包括部署有旧版本服务的服务器。
6.根据权利要求5所述的方法，其特征在于，所述对所述第一服务器组中的服务器进行回滚之后，所述方法还包括：
将所述服务流量转移到所述第一服务器组上，重新执行所述分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据的步骤。
7.根据权利要求1所述的方法，其特征在于，所述多个目标指标的数据为服务器组内多个服务器的平均值。
8.根据权利要求1所述的方法，其特征在于，所述目标指标包括系统性能指标、应用程序指标、业务数据指标中的至少一种；所述预设指标包括每秒查询率QPS。
9.根据权利要求1-8任一项所述方法，其特征在于，所述方法还包括：
获取所述第一服务器组升级前的所述多个目标指标的数据；
确定所述第一服务器组与所述第一服务器升级前在每个所述目标指标上的数据波动；
若所述多个目标指标中包括第二指标，则根据所述多个目标指标中包括的预设指标的数据和所述第二指标的重要程度，确定第四阈值，所述第二指标为数据波动超过其对应的第三阈值的指标；
若所述第二指标对应的数据波动超过第四阈值，则对所述第一服务器组中的服务器进行回滚。
10.一种服务升级的监测装置，其特征在于，所述装置包括：
数据获取模块，被配置为在对目标集群中的服务器的升级过程中，分别获取所述目标集群中第一服务器组和第二服务器组的多个目标指标的数据，所述第一服务器组包括部署有新版本服务的服务器，所述第二服务器组包括部署有旧版本服务的服务器；
数据差异确定模块，被配置为确定所述第一服务器组与所述第二服务器组之间在每个所述目标指标上的数据差异；
阈值确定模块，被配置为若所述多个目标指标中包括第一指标，则根据所述多个目标指标中包括的预设指标的数据和所述第一指标的重要程度，确定第二阈值，所述第一指标为数据差异超过其对应的第一阈值的指标；
服务回滚模块，被配置为若所述第一指标对应的数据差异超过第二阈值，则对所述第一服务器组中的服务器进行回滚。
11.一种服务器，其特征在于，所述服务器包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如权利要求1至权利要求9任一项所述的服务升级的监测方法所执行的操作。
12.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现如权利要求1至权利要求9任一项所述的服务升级的监测方法所执行的操作。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911404099.0A CN111104260B (zh) | 2019-12-30 | 2019-12-30 | 服务升级的监测方法、装置、服务器及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911404099.0A CN111104260B (zh) | 2019-12-30 | 2019-12-30 | 服务升级的监测方法、装置、服务器及存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111104260A true CN111104260A (zh) | 2020-05-05 |
| CN111104260B CN111104260B (zh) | 2023-04-14 |
Family
ID=70423983
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911404099.0A Active CN111104260B (zh) | 2019-12-30 | 2019-12-30 | 服务升级的监测方法、装置、服务器及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111104260B (zh) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111930448A (zh) * | 2020-09-23 | 2020-11-13 | 南京梦饷网络科技有限公司 | 用于服务发布的方法、电子设备和存储介质 |
| CN111949277A (zh) * | 2020-08-17 | 2020-11-17 | 中国工商银行股份有限公司 | 智能化灰度发布投产方法、装置、计算机设备及存储介质 |
| CN112527368A (zh) * | 2020-12-02 | 2021-03-19 | 北京百度网讯科技有限公司 | 集群内核版本更新方法、装置、电子设备和存储介质 |
| CN112783729A (zh) * | 2021-01-29 | 2021-05-11 | 北京三快在线科技有限公司 | 一种针对灰度发布的异常处理方法及异常处理装置 |
| CN115460295A (zh) * | 2022-09-13 | 2022-12-09 | 中航信移动科技有限公司 | 一种离群服务器恢复询问时间的确定方法、介质及设备 |
| CN115914400A (zh) * | 2022-11-07 | 2023-04-04 | 中国工商银行股份有限公司 | 业务处理方法、装置、电子设备及介质 |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005114398A2 (en) * | 2004-05-18 | 2005-12-01 | Bea Systems, Inc. | Production redeployment through application versioning |
| US20170163742A1 (en) * | 2015-12-02 | 2017-06-08 | International Business Machines Corporation | Supporting high availability for orchestrated services |
| CN107301055A (zh) * | 2017-07-19 | 2017-10-27 | 北京小米移动软件有限公司 | 升级服务器的方法及装置 |
| US20180121322A1 (en) * | 2016-10-31 | 2018-05-03 | Facebook, Inc. | Methods and Systems for Testing Versions of Applications |
| US20180189046A1 (en) * | 2016-12-29 | 2018-07-05 | Arris Enterprises Llc | Method and System for Analytics-Based Updating of Networked Devices |
| CN109347652A (zh) * | 2018-08-31 | 2019-02-15 | 北京奇艺世纪科技有限公司 | 服务器集群的服务管理方法和装置 |
| US20190372832A1 (en) * | 2018-05-31 | 2019-12-05 | Beijing Baidu Netcom Science Technology Co., Ltd. | Method, apparatus and storage medium for diagnosing failure based on a service monitoring indicator |
-
2019
- 2019-12-30 CN CN201911404099.0A patent/CN111104260B/zh active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005114398A2 (en) * | 2004-05-18 | 2005-12-01 | Bea Systems, Inc. | Production redeployment through application versioning |
| US20170163742A1 (en) * | 2015-12-02 | 2017-06-08 | International Business Machines Corporation | Supporting high availability for orchestrated services |
| US20180121322A1 (en) * | 2016-10-31 | 2018-05-03 | Facebook, Inc. | Methods and Systems for Testing Versions of Applications |
| US20180189046A1 (en) * | 2016-12-29 | 2018-07-05 | Arris Enterprises Llc | Method and System for Analytics-Based Updating of Networked Devices |
| CN107301055A (zh) * | 2017-07-19 | 2017-10-27 | 北京小米移动软件有限公司 | 升级服务器的方法及装置 |
| US20190372832A1 (en) * | 2018-05-31 | 2019-12-05 | Beijing Baidu Netcom Science Technology Co., Ltd. | Method, apparatus and storage medium for diagnosing failure based on a service monitoring indicator |
| CN109347652A (zh) * | 2018-08-31 | 2019-02-15 | 北京奇艺世纪科技有限公司 | 服务器集群的服务管理方法和装置 |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111949277A (zh) * | 2020-08-17 | 2020-11-17 | 中国工商银行股份有限公司 | 智能化灰度发布投产方法、装置、计算机设备及存储介质 |
| CN111930448A (zh) * | 2020-09-23 | 2020-11-13 | 南京梦饷网络科技有限公司 | 用于服务发布的方法、电子设备和存储介质 |
| CN112527368A (zh) * | 2020-12-02 | 2021-03-19 | 北京百度网讯科技有限公司 | 集群内核版本更新方法、装置、电子设备和存储介质 |
| CN112527368B (zh) * | 2020-12-02 | 2024-03-22 | 北京百度网讯科技有限公司 | 集群内核版本更新方法、装置、电子设备和存储介质 |
| CN112783729A (zh) * | 2021-01-29 | 2021-05-11 | 北京三快在线科技有限公司 | 一种针对灰度发布的异常处理方法及异常处理装置 |
| CN115460295A (zh) * | 2022-09-13 | 2022-12-09 | 中航信移动科技有限公司 | 一种离群服务器恢复询问时间的确定方法、介质及设备 |
| CN115914400A (zh) * | 2022-11-07 | 2023-04-04 | 中国工商银行股份有限公司 | 业务处理方法、装置、电子设备及介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111104260B (zh) | 2023-04-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111104260B (zh) | 服务升级的监测方法、装置、服务器及存储介质 | |
| CN107844343B (zh) | 一种复杂服务端应用系统的升级系统及方法 | |
| US10554478B2 (en) | Method and apparatus for providing trouble isolation via a network | |
| CN103916481B (zh) | 一种处理数据的方法和装置 | |
| CN110149366B (zh) | 提高集群系统可用性的方法、装置和计算机设备 | |
| CN109787858B (zh) | 一种批量发布服务的方法及终端 | |
| CN109298960A (zh) | 应用崩溃处理方法、装置、计算机装置及存储介质 | |
| CN109739527B (zh) | 一种客户端灰度发布的方法、装置、服务器和存储介质 | |
| WO2014153311A1 (en) | Automatic version management | |
| CN112765161B (zh) | 报警规则匹配方法、装置、电子设备及存储介质 | |
| CN110618864A (zh) | 一种中断任务恢复方法及装置 | |
| CN114356557A (zh) | 一种集群扩容方法及装置 | |
| CN111949404A (zh) | 调整服务器负载的方法、装置和相关设备 | |
| CN109639490B (zh) | 一种宕机通知方法及装置 | |
| CN104967532A (zh) | Toc技术运维系统及应用方法 | |
| CN111601329B (zh) | 一种端口中断告警的处理方法及装置 | |
| CN115495309A (zh) | 共用存储服务器的数据库服务器io处理方法及装置 | |
| CN113742400B (zh) | 一种基于自适应约束条件的网络数据获取系统及方法 | |
| CN111935289B (zh) | 基于区块链的动态监控方法和装置 | |
| CN114398223A (zh) | 网络服务器集群可用性监测方法及系统 | |
| CN110086660B (zh) | 一种数据处理方法及装置 | |
| CN113778763A (zh) | 一种三方接口服务故障智能切换方法及系统 | |
| CN107909460B (zh) | 头寸同步方法、设备、数据中心及存储介质 | |
| CN112965902A (zh) | 一种应用系统的评估方法及装置 | |
| CN112765188A (zh) | 配置信息处理方法、配置管理系统、电子设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20230926 Address after: Room 507, Floor 5, Building 2, Yard 18, Haidian Suzhou Street, Haidian District, Beijing 100080 Patentee after: BEIJING KUXUN TECHNOLOGY Co.,Ltd. Patentee after: BEIJING SANKUAI ONLINE TECHNOLOGY Co.,Ltd. Address before: 100080 2106-030, 9 North Fourth Ring Road, Haidian District, Beijing. Patentee before: BEIJING SANKUAI ONLINE TECHNOLOGY Co.,Ltd. |