CN109739726A - 一种健康检查方法、装置及电子设备 - Google Patents
一种健康检查方法、装置及电子设备 Download PDFInfo
- Publication number
- CN109739726A CN109739726A CN201811653471.7A CN201811653471A CN109739726A CN 109739726 A CN109739726 A CN 109739726A CN 201811653471 A CN201811653471 A CN 201811653471A CN 109739726 A CN109739726 A CN 109739726A
- Authority
- CN
- China
- Prior art keywords
- interface
- service interface
- request
- service
- health status
- 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.)
- Pending
Links
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本说明书实施例提供一种健康检查方法、装置及电子设备。所述方法包括：获取业务系统向服务接口发起接口请求后，所述服务接口返回的请求执行情况，所述请求执行情况包括请求响应耗时和请求响应结果；再根据请求执行情况，确定所述服务接口在单位时间内的平均响应耗时和响应成功率；将所述平均响应耗时和响应成功率与该服务接口的最低可用标准进行比较，从而判断得出所述服务接口的健康状态，实现对服务接口的健康状态的识别。
Description
技术领域
本说明书涉及计算机技术领域，尤其涉及一种健康检查方法、装置及电子设备。
背景技术
在互联网的大潮中，越来越多的互联网公司与政府机构或行业机构合作，搭建一站式政务、生活综合服务平台，为用户提供统一入口办理社保、税务、公积金、水电煤、医疗等各种事务。平台系统底层需要依赖大量外部的政府机构和行业机构的各项服务接口。在平台系统的业务过程中，平台系统很难感知到这些外部机构的系统中，各项服务接口的运用状态。当一些高频服务接口发生故障时，会引发平台系统的整体性能劣化，甚至影响到其它无关的业务链路，而且故障发生后需要人力介入，才能确认外部系统的恢复情况。
现有技术中，对平台系统是否发生故障等运行状态的一般健康检查方法，主要针对的是系统或应用级别的健康检查，以判断系统或应用是否正常运行，这种方法只能感知检查粒度较粗的系统性能问题以及网络问题，如网络不通、服务器宕机等造成的故障。基于现有技术，需要提供一种检查粒度小，精度更高的健康检查方案。
发明内容
本说明书实施例提供一种健康检查方法、装置及电子设备，以解决现有技术存在的故障识别的粒度较粗，精度低的问题。
为解决上述技术问题，本说明书实施例是这样实现的：
本说明书实施例提供的一种健康检查方法，包括：
获取业务系统向服务接口发起接口请求后，对所述服务接口进行调用产生的请求执行情况，所述请求执行情况包括请求响应耗时和请求响应结果；
根据所述请求执行情况，确定所述服务接口在单位时间内的平均响应耗时和响应成功率；
将所述平均响应耗时和响应成功率与该服务接口的最低可用标准进行比较，判断所述服务接口的健康状态。
另外，在所述方法中，还包括：创建健康状态表，所述健康状态表用于记录所述服务接口的健康状态，所有所述服务接口的初始健康状态均为非故障状态。
另外，在所述方法中，所述判断所述服务接口的健康状态之后，还包括：根据判断得出的健康状态，对所述健康状态表中所述服务接口的健康状态进行更新。
另外，在所述方法中，所述业务系统向服务接口发起接口请求后，还包括：通过查询所述健康状态表，判断所述服务接口的当下健康状态；
当所述服务接口的当下健康状态为故障状态时，对所述服务接口在故障之后，所接收到的接口请求进行过滤，判断是否通过所述接口请求；
对通过的接口请求，接收服务接口返回的请求执行情况；对不通过的接口请求，返回该接口请求的模拟响应；
当所述服务接口的当下健康状态为非故障状态时，接收服务接口返回的请求执行情况。
另外，在所述方法中，所述对所述服务接口在故障之后，所接收到的接口请求进行过滤，判断是否通过所述接口请求，包括：设置所述服务接口的接口请求阈值，对所述服务接口在故障之后，所接收到的接口请求进行累加，当接口请求的累加值达到所述阈值，将达到所述阈值后的接口请求作为通过的接口请求，并清空所述累加值。
另外，在所述方法中，所述阈值为动态阈值，所述设置所述服务接口的接口请求阈值，包括：根据以下方式调整动态阈值，
当Q＝0时，N’＝N*(1-s％)；
并重新统计接下来t分钟内的Q，直至Q＞0，或N＜Nmin；
当Q≥Qmax时，N’＝N*(1+s％)；
并重新统计接下来t分钟内的Q，直至Q＜Qmax，或N＜Nmax；
其中，t表示调整动态阈值的时间间隔；Q表示t分钟内接口请求的累加值；N’表示动态阈值；N表示初始阈值；s表示最小调整幅度；Nmin表示服务接口正常运行时的日常最小接口请求量；Nmax表示服务接口正常运行时的日常最大接口请求量；Qmax表示服务接口在最长请求响应耗时最大可承受的接口请求量。
另外，在所述方法中，所述根据所述请求执行情况，确定所述服务接口在单位时间内的平均响应耗时和响应成功率，包括：将单位时间内所有接口请求对所述服务接口的调用，所产生的请求响应耗时和请求响应结果，计算其平均值，得到平均响应耗时和响应成功率。
另外，在所述方法中，所述服务接口的最低可用标准，包括：根据所述服务接口所提供的服务内容，确定所述服务接口的可用平均耗时和可用成功率。
另外，在所述方法中，所述将所述平均响应耗时和响应成功率与该服务接口的最低可用标准进行比较，判断所述服务接口的健康状态，包括：
当所述平均响应耗时高于可用平均耗时，或响应成功率低于可用成功率时，所述服务接口标记为不可用，连续多次标记为不可用，且达到限制次数时，判断该服务接口的健康状态为故障状态；连续多次标记为不可用，且未达到限制次数时，判断该服务接口的健康状态仍为非故障状态；
当所述平均响应耗时低于可用平均耗时，且响应成功率高于可用成功率时，所述服务接口标记为可用，连续多次标记为可用时，判断该服务接口的健康状态为非故障状态。
本说明书实施例提供的一种健康检查装置，包括：
获取模块，用于获取业务系统向服务接口发起接口请求后，对所述服务接口进行调用产生的请求执行情况，所述请求执行情况包括请求响应耗时和请求响应结果；
确定模块，用于根据所述请求执行情况，确定所述服务接口在单位时间内的平均响应耗时和响应成功率；
判断模块，将所述平均响应耗时和响应成功率与该服务接口的最低可用标准进行比较，判断所述服务接口的健康状态。
另外，在所述装置中，还包括：创建模块，用于创建健康状态表，所述健康状态表用于记录所述服务接口的健康状态，所有所述服务接口的初始健康状态均为非故障状态。
另外，在所述装置中，还包括：更新模块，用于根据所述判断模块判断得出的健康状态，对所述健康状态表中所述服务接口的健康状态进行更新。
另外，在所述装置中，还包括：查询过滤模块，用于通过查询所述健康状态表，判断所述服务接口的当下健康状态；
当所述服务接口的当下健康状态为故障状态时，对所述服务接口在故障之后，所接收到的接口请求进行过滤，判断是否通过所述接口请求；
对通过的接口请求，接收服务接口返回的请求执行情况；对不通过的接口请求，返回该接口请求的模拟响应；
当所述服务接口的当下健康状态为非故障状态时，接收服务接口返回的请求执行情况。
另外，在所述装置中，所述查询过滤模块进一步用于：设置所述服务接口的接口请求阈值，对所述服务接口在故障之后，所接收到的接口请求进行累加，当接口请求的累加值达到所述阈值，将达到所述阈值后的接口请求作为通过的接口请求，并清空所述累加值。
另外，在所述装置中，所述阈值为动态阈值，所述查询过滤模块进一步用于：根据以下方式调整动态阈值，
当Q＝0时，N’＝N*(1-s％)；
并重新统计接下来t分钟内的Q，直至Q＞0，或N＜Nmin；
当Q≥Qmax时，N’＝N*(1+s％)；
并重新统计接下来t分钟内的Q，直至Q＜Qmax，或N＜Nmax；
其中，t表示调整动态阈值的时间间隔；Q表示t分钟内接口请求的累加值；N’表示动态阈值；N表示初始阈值；s表示最小调整幅度；Nmin表示服务接口正常运行时的日常最小接口请求量；Nmax表示服务接口正常运行时的日常最大接口请求量；Qmax表示服务接口在最长请求响应耗时最大可承受的接口请求量。
另外，在所述装置中，所述确定模块具体用于：将单位时间内所有接口请求对所述服务接口的调用，所产生的请求响应耗时和请求响应结果，计算其平均值，得到平均响应耗时和响应成功率。
另外，在所述装置中，所述服务接口的最低可用标准，包括：根据所述服务接口所提供的服务内容，确定所述服务接口的可用平均耗时和可用成功率。
另外，在所述装置中，所述判断模块具体用于：
当所述平均响应耗时高于可用平均耗时，或响应成功率低于可用成功率时，所述服务接口标记为不可用，连续多次标记为不可用，且达到限制次数时，判断该服务接口的健康状态为故障状态；连续多次标记为不可用，且未达到限制次数时，判断该服务接口的健康状态仍为非故障状态；
当所述平均响应耗时低于可用平均耗时，且响应成功率高于可用成功率时，所述服务接口标记为可用，连续多次标记为可用时，判断该服务接口的健康状态为非故障状态。
本说明书实施例提供的一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述一种健康检查方法。
本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：
通过获取业务系统向服务接口发起接口请求后，服务接口返回的请求执行情况，请求执行情况包括请求响应耗时和请求响应结果；再根据请求执行情况，确定服务接口在单位时间内的平均响应耗时和响应成功率；将平均响应耗时和响应成功率与该服务接口的最低可用标准进行比较，从而判断得出服务接口的健康状态。基于本方案，能够感知服务接口的健康状态，实现接口级别的健康状态的检查，从而降低故障识别的粒度，提升故障识别的精度。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本说明书的方案在实际应用场景下涉及的系统整体架构的示意图；
图2为本说明书实施例提供的一种健康检查方法的流程示意图；
图3为本说明书实施例提供的服务接口运维操作的流程示意图；
图4为本说明书实施例提供的一种健康检查装置的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
图1为本说明书的方案在一种实际应用场景下涉及的系统整体架构的示意图。系统整体架构包括域内系统和域外系统，域内系统和域外系统分别是一个独立的有安全边界的系统集合，也是数据隔离的基本单元，域内系统和域外系统之间至少具有逻辑机房及以上级别的隔离，相互访问需要建立信任关系。域内系统可以是一个或多个平台系统，例如政务服务平台系统、生活服务平台系统等，域内系统也可以称为域内平台系统，域内平台系统中包含平台业务系统；域外系统由大量的外部系统所组成，例如政府机构的应用系统和行业机构的应用系统等；每个外部系统都有对应的服务接口，一个外部系统可以提供多个接口服务，外部系统的服务以服务接口的方式提供，平台系统的业务需要依赖这些外部系统所提供的服务来实现。本说明书实施例中，健康检查装置位于域内系统与域外系统的边界，可以统一管理平台系统对外部渠道的访问，通过健康检查装置的辅助可以实现平台系统对外部系统服务的调用。
基于上述场景，下面对本说明书的方案进行详细说明。
图2为本说明书实施例提供的一种健康检查方法的流程示意图，该方法具体可以包括以下步骤：
在步骤S210中，获取业务系统向服务接口发起接口请求后，对所述服务接口进行调用产生的请求执行情况，所述请求执行情况包括请求响应耗时和请求响应结果。
在本说明书一个或多个实施例中，用户发起对平台系统的访问，平台系统接收用户发送的业务访问请求，平台系统将业务访问请求转换成对外部系统的服务接口调用的接口请求。接口请求包含服务调用的地址、调用的方法以及调用的参数，这些可以唯一标识出一个具有确定功能的服务接口，因此接口请求与服务接口之间具有较为确定的对应关系。
需要说明的是，一个服务接口可以表示一个独立执行的最小原子服务，通过对接口请求的解析，将服务调用的地址、调用的方法、以及调用的参数(可自定义为部分参数)，作为接口请求的要素，要素一致的接口请求可以看作是对一个原子服务接口的请求。服务接口的健康状态识别、更新等操作，都基于这样的一个原子服务接口进行。
在一个具体实施例中，政务服务平台系统提供了包括公积金查询/办理、社保查询/办理、违章缴费等业务，例如：用户通过网站访问平台系统，发起查询公积金的业务访问请求，平台系统需要依赖外部的公积金管理中心的系统所提供的服务来实现，平台系统将该业务访问请求转换为接口请求，通过健康检查装置发起对外部系统的服务进行调用的接口请求，实现平台系统对外部系统服务的调用。
在本说明书一个或多个实施例中，业务系统向外部系统的服务接口发送接口请求后，外部系统执行该接口请求，并返回请求执行情况，请求执行情况包括请求响应耗时和请求响应结果，请求响应耗时可以是指从发出接口请求到接收请求响应结果的时间或者按照预定的规则确定的其他时间起止范围，请求响应结果包含接口请求对服务接口的调用是否成功等结果。在健康检查装置接收到请求执行情况后，将请求执行情况中的请求响应结果返回给上层业务。
在步骤S220中，根据所述请求执行情况，确定所述服务接口在单位时间内的平均响应耗时和响应成功率。
具体的，将单位时间内所有接口请求对服务接口的调用，所产生的请求响应耗时和请求响应结果，计算其平均值，得到平均响应耗时和响应成功率。
在一个具体实施例中，例如：在单位时间1分钟内，对同一服务接口共发起了5次接口请求，其中这5次调用的请求响应耗时分别为：1s、0.8s、1.5s、2s、0.7s，请求响应结果分别为：成功、成功、成功、失败、失败，那么通过叠加计算得出该服务接口在单位时间内的平均响应耗时为1.2s，响应成功率为60％。
在步骤S230中，将所述平均响应耗时和响应成功率与该服务接口的最低可用标准进行比较，判断所述服务接口的健康状态。
在本说明书一个或多个实施例中，服务接口的最低可用标准表明了该服务接口可以被正常调用的最低条件，当达到该条件时，则可以进行对该服务接口的调用。现实应用中，可以采用多项“指标”来刻画服务接口的最低可用标准，这些“指标”可以同时作为最低标准，也可以仅以其中一项作为最低标准，或者在某些条件下以其中一项作为最低标准，而在另一些情况下则以另一项或几项作为最低标准。比如，服务接口的最低可用标准可以包括服务接口的可用平均耗时和可用成功率两个“指标”，服务接口的最低可用标准采用以下方式获得：根据服务接口所提供的服务内容，来确定服务接口的可用平均耗时和可用成功率。上述服务内容包括使用人次以及资金安全性等，当使用人次越多，资金安全性越高，那么要求服务接口的可用平均耗时就越短，可用成功率就越高。
在本说明书一个实施例中，服务接口健康状态的判断方法，可以包括：
当平均响应耗时高于可用平均耗时，或响应成功率低于可用成功率时，服务接口标记为不可用，连续多次标记为不可用，且达到限制次数时，判断该服务接口的健康状态为故障状态；连续多次标记为不可用，且未达到限制次数时，判断该服务接口的健康状态仍为非故障状态；
当平均响应耗时低于可用平均耗时，且响应成功率高于可用成功率时，服务接口标记为可用，连续多次标记为可用时，判断该服务接口的健康状态为非故障状态。
在一个具体实施例中，例如：某一个服务接口的可用平均耗时为1s，可用成功率为80％，该服务接口在本次单位时间内的平均响应耗时为1.2s，响应成功率为60％，那么在本次单位时间内该服务接口标记为不可用；继续以1分钟为单位时间连续评估该服务接口是否可用，比如设置限制次数为5次，如果该服务接口连续2次被标记为不可用，判断该服务接口的健康状态仍为非故障状态(此时为告警状态)；如果该服务接口连续5次被标记为不可用时，那么判断该服务接口的健康状态为故障状态。
又例如该服务接口在下一次单位时间内的平均响应耗时为0.8s，响应成功率为90％，那么在下一次单位时间内该服务接口标记为可用，且如果该服务接口连续多次(连续2次或以上)标记为可用时，则判断该服务接口的健康状态为非故障状态。
在本说明书实施例中，非故障状态又分为正常状态和告警状态，如上述内容：当平均响应耗时高于可用平均耗时，或响应成功率低于可用成功率时，服务接口标记为不可用，连续多次标记为不可用，且未达到限制次数时，判断该服务接口的健康状态仍为非故障状态；但是，此时的非故障状态为告警状态，而非正常状态。当服务接口连续多次标记为可用时，该服务接口的健康状态为非故障状态，此时的非故障状态为正常状态。
另外，若单位时间内的该服务接口的接口请求量为0时，将该服务接口标记为null，表示不具备统计意义；当服务接口标记为null时，中断连续统计，待下一次非null标记出现后重新统计。
基于上述连续动态的健康状态判断机制，可根据不同时刻服务接口的健康状态，定义健康状态变化时的自动告警(例如，从可用→不可用)，以及自动通知(例如，从不可用→可用)。其他，如响应耗时统计值增长，服务接口调用量增加的情况也可以定义相应的通知。
根据前述实施例可知，由步骤S210至步骤S230中，通过业务系统向服务接口发起接口请求后对服务接口进行调用，并接收服务接口返回的真实请求的执行情况；通过对请求执行情况进行统计分析，以单位时间作为评估服务接口可用与否的判断间隔，采用连续统计的方式，确定服务接口的健康状态，实现自动化的接口级别的故障识别，且故障识别的粒度更小，精度更高；本方案可以适用于存在大量无法获取操作权限的域外应用系统的场景，分钟级别的接口健康状态定义和连续统计后的健康状态判断逻辑，可以有效排除瞬时因素(例如，网络抖动)的影响，评估出域外服务接口阶段性的可用程度。
上述内容主要介绍了本说明书实施例中服务接口的健康状态检查方法，本说明书实施例还在服务接口的故障识别基础上，进一步实现对服务接口的运维操作。参见图3，该图示出了本说明书实施例提供的服务接口运维操作的流程示意图，主要包括以下内容：
创建健康状态表，健康状态表用于记录服务接口的健康状态，所有服务接口的初始健康状态均为非故障状态。在步骤S230之后，根据判断得出的服务接口的健康状态，对健康状态表中该服务接口的健康状态进行更新。
在本说明书一个或多个实施例中，在业务系统发起对服务接口的接口请求后，首先会查询健康状态表并判断该服务接口的当下健康状态，而不是将该服务接口的所有接口请求全部通过，通过查询的方式直接判断出流经的接口请求是否可真实执行，即服务接口是否为故障状态，将故障接口的服务挂起，实现故障接口和非故障接口之间的服务隔离。通过挂起故障接口的服务，在域外系统的服务接口发生故障时，能限定故障服务的传播范围和影响范围，即发生故障后平台系统不会出现滚雪球效应，保障平台上的服务间相互不影响。
进一步地，基于上述对服务接口当下健康状态的查询和判断，根据服务接口不同的健康状态，采用以下运维操作：
当服务接口的当下健康状态为故障状态时，对服务接口在故障之后，所接收到的接口请求进行过滤，判断是否通过接口请求。
在本说明书一个或多个实施例中，当服务接口的当下健康状态为故障状态时，不能将接下来持续流经该故障接口的所有接口请求全部通过，这样将会有大量无效的超时请求，影响平台系统的稳定性；也不能拦截掉所有流经该故障接口的接口请求，无法达到持续检测的目的；通过过滤筛选的方式，将流经故障接口的接口请求，按照预定的频率筛选通过，即对流经故障接口的接口请求进行过滤，判断是否通过接口请求，包括：
设置服务接口的接口请求阈值，对服务接口在故障之后，所接收到的接口请求进行累加，当接口请求的累加值达到阈值，将达到阈值后的接口请求作为通过的接口请求，并清空累加值。
在一个具体实施例中，例如：初始设置某个服务接口的接口请求阈值为100，当判断该服务接口的健康状态为故障状态后，对接下来流经该故障接口的接口请求进行累加，直到接口请求的累加值达到100后，将第100个或第101个接口请求通过该服务接口，同时，将累加的统计结果清空，并重新统计，从而有效控制故障接口通过的请求数量，保证放过的接口请求即使是无效的超时请求，也不会影响到系统的整体性能。
进一步地，根据上述频率筛选规则，对于通过的接口请求，接收服务接口返回的请求执行情况；通过接口请求是指，对该接口请求进行真实的执行并返回真实执行的执行情况结果。在本说明书实施例中，通过的接口请求还可以作为继续检测服务接口是否可用的心跳信息，以这种间断性尝试调用的方式，持续监听更新服务接口的健康状态，并自动感知隔离后的故障接口的服务恢复情况，一旦外部服务接口从故障状态更新为非故障状态后，可及时取消对服务接口的隔离，并重新提供服务，整个过程无需人工介入，实现自动化的故障隔离及恢复，节约人力运维成本。
对于不通过的接口请求，不真实执行接口请求对服务接口的调用，而是返回该接口请求的模拟响应，用根据服务接口的业务特性提前录制或者定义好的结构体，作为接口请求调用的模拟响应返回。通过对接口请求作模拟响应，实现对流经故障接口的服务请求做进一步的隔离，保证大部分的接口请求都不被真实执行，避免大量无效请求通过故障接口。
当通过查询健康状态表后，判断服务接口的当下健康状态为非故障状态时，将非故障接口的接口请求全部通过，对通过的接口请求进行真实执行并返回真实执行的执行情况结果。
在本说明书一个或多个实施例中，可通过并真实执行的接口请求，包括服务接口在非故障状态下的接口请求，以及服务接口在故障状态下，经筛选过滤通过的接口请求。
在本说明书一个或多个实施例中，当配置者不知道如何设置接口请求的阈值，才能达到既能足够隔离故障接口的服务，又能合理的监控故障接口的恢复情况，根据不同服务接口的调用量的累加值，自适应地增大和缩小这个阈值；因此对于故障接口的接口请求阈值，应该以动态调整的方式设置为动态阈值，具体的，可以采用以下方式动态调整服务接口的阈值大小：
当Q＝0时，N’＝N*(1-s％)；
并重新统计接下来t分钟内的Q，直至Q＞0，或N＜Nmin；
当Q≥Qmax时，N’＝N*(1+s％)；
并重新统计接下来t分钟内的Q，直至Q＜Qmax，或N＜Nmax；
其中，t表示调整动态阈值的时间间隔；Q表示t分钟内接口请求的累加值；N’表示动态阈值；N表示初始阈值；s表示最小调整幅度；Nmin表示服务接口正常运行时的日常最小接口请求量；Nmax表示服务接口正常运行时的日常最大接口请求量；Qmax表示服务接口在最长请求响应耗时最大可承受的接口请求量。
通过设置动态阈值，阈值可随请求量的增大而增大，请求量的减少而减少，
持续放过少量的请求达到监听的目的，但是叉能控制通过的接口请求数量，避免过多的失败请求；还可以区分高频访问的接口和低频访问的接口的过滤标准，避免高频访问的接口由于放过的请求过多影响到系统性能，也避免低频访问的接口由于请求太少而长时间没有请求通过来感知接口的恢复情况，动态阈值可以充分达到隔离和即时恢复的平衡状态。
基于同样的思路，本说明书实施例还提供了一种健康检查装置，如图4为本说明书实施例提供的一种健康检查装置，该装置400主要包括：
获取模块401，用于获取业务系统向服务接口发起接口请求后，对所述服务接口进行调用产生的请求执行情况，所述请求执行情况包括请求响应耗时和请求响应结果；
确定模块402，用于根据所述请求执行情况，确定所述服务接口在单位时间内的平均响应耗时和响应成功率；
判断模块403，将所述平均响应耗时和响应成功率与该服务接口的最低可用标准进行比较，判断所述服务接口的健康状态。
根据本申请的实施例，在所述装置中，还包括：创建模块404，用于创建健康状态表，所述健康状态表用于记录所述服务接口的健康状态，所有所述服务接口的初始健康状态均为非故障状态。
根据本申请的实施例，在所述装置中，还包括：更新模块405，用于根据所述判断模块判断得出的健康状态，对所述健康状态表中所述服务接口的健康状态进行更新。
根据本申请的实施例，在所述装置中，还包括：查询过滤模块406，用于通过查询所述健康状态表，判断所述服务接口的当下健康状态；
当所述服务接口的当下健康状态为故障状态时，对所述服务接口在故障之后，所接收到的接口请求进行过滤，判断是否通过所述接口请求；
对通过的接口请求，接收服务接口返回的请求执行情况；对不通过的接口请求，返回该接口请求的模拟响应；
当所述服务接口的当下健康状态为非故障状态时，接收服务接口返回的请求执行情况。
根据本申请的实施例，所述查询过滤模块406进一步用于：设置所述服务接口的接口请求阈值，对所述服务接口在故障之后，所接收到的接口请求进行累加，当接口请求的累加值达到所述阈值，将达到所述阈值后的接口请求作为通过的接口请求，并清空所述累加值。
根据本申请的实施例，所述阈值为动态阈值，所述查询过滤模块进一步用于：根据以下方式调整动态阈值，
当Q＝0时，N’＝N*(1-s％)；
并重新统计接下来t分钟内的Q，直至Q＞0，或N＜Nmin；
当Q≥Qmax时，N’＝N*(1+s％)；
并重新统计接下来t分钟内的Q，直至Q＜Qmax，或N＜Nmax；
其中，t表示调整动态阈值的时间间隔；Q表示t分钟内接口请求的累加值；N’表示动态阈值；N表示初始阈值；s表示最小调整幅度；Nmin表示服务接口正常运行时的日常最小接口请求量；Nmax表示服务接口正常运行时的日常最大接口请求量；Qmax表示服务接口在最长请求响应耗时最大可承受的接口请求量。
根据本申请的实施例，所述确定模块402具体用于：将单位时间内所有接口请求对所述服务接口的调用，所产生的请求响应耗时和请求响应结果，计算其平均值，得到平均响应耗时和响应成功率。
根据本申请的实施例，所述服务接口的最低可用标准，包括：根据所述服务接口所提供的服务内容，确定所述服务接口的可用平均耗时和可用成功率。
根据本申请的实施例，所述判断模块403具体用于：
当所述平均响应耗时高于可用平均耗时，或响应成功率低于可用成功率时，所述服务接口标记为不可用，连续多次标记为不可用，且达到限制次数时，判断该服务接口的健康状态为故障状态；连续多次标记为不可用，且未达到限制次数时，判断该服务接口的健康状态仍为非故障状态；
当所述平均响应耗时低于可用平均耗时，且响应成功率高于可用成功率时，所述服务接口标记为可用，连续多次标记为可用时，判断该服务接口的健康状态为非故障状态。
本说明书实施例还提供一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述一种健康检查方法。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、电子设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本说明书实施例提供的装置、电子设备、非易失性计算机存储介质与方法是对应的，因此，装置、电子设备、非易失性计算机存储介质也具有与对应方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述对应装置、电子设备、非易失性计算机存储介质的有益技术效果。
本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本说明书实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。
Claims (19)
1.一种健康检查方法，其特征在于，包括：
获取业务系统向服务接口发起接口请求后，对所述服务接口进行调用产生的请求执行情况，所述请求执行情况包括请求响应耗时和请求响应结果；
根据所述请求执行情况，确定所述服务接口在单位时间内的平均响应耗时和响应成功率；
将所述平均响应耗时和响应成功率与该服务接口的最低可用标准进行比较，判断所述服务接口的健康状态。
2.如权利要求1所述的方法，其特征在于，还包括：
创建健康状态表，所述健康状态表用于记录所述服务接口的健康状态，所有所述服务接口的初始健康状态均为非故障状态。
3.如权利要求2所述的方法，其特征在于，所述判断所述服务接口的健康状态之后，还包括：
根据判断得出的健康状态，对所述健康状态表中所述服务接口的健康状态进行更新。
4.如权利要求3所述的方法，其特征在于，所述业务系统向服务接口发起接口请求后，还包括：通过查询所述健康状态表，判断所述服务接口的当下健康状态；
当所述服务接口的当下健康状态为故障状态时，对所述服务接口在故障之后，所接收到的接口请求进行过滤，判断是否通过所述接口请求；
对通过的接口请求，接收服务接口返回的请求执行情况；对不通过的接口请求，返回该接口请求的模拟响应；
当所述服务接口的当下健康状态为非故障状态时，接收服务接口返回的请求执行情况。
5.如权利要求4所述的方法，其特征在于，所述对所述服务接口在故障之后，所接收到的接口请求进行过滤，判断是否通过所述接口请求，包括：
设置所述服务接口的接口请求阈值，对所述服务接口在故障之后，所接收到的接口请求进行累加，当接口请求的累加值达到所述阈值，将达到所述阈值后的接口请求作为通过的接口请求，并清空所述累加值。
6.如权利要求5所述的方法，其特征在于，所述阈值为动态阈值，所述设置所述服务接口的接口请求阈值，包括：根据以下方式调整动态阈值，
当Q＝0时，N’＝N*(1-s％)；
并重新统计接下来t分钟内的Q，直至Q＞0，或N＜Nmin；
当Q≥Qmax时，N’＝N*(1+s％)；
并重新统计接下来t分钟内的Q，直至Q＜Qmax，或N＜Nmax；
其中，t表示调整动态阈值的时间间隔；Q表示t分钟内接口请求的累加值；N’表示动态阈值；N表示初始阈值；s表示最小调整幅度；Nmin表示服务接口正常运行时的日常最小接口请求量；Nmax表示服务接口正常运行时的日常最大接口请求量；Qmax表示服务接口在最长请求响应耗时最大可承受的接口请求量。
7.如权利要求1所述的方法，其特征在于，所述根据所述请求执行情况，确定所述服务接口在单位时间内的平均响应耗时和响应成功率，包括：
将单位时间内所有接口请求对所述服务接口的调用，所产生的请求响应耗时和请求响应结果，计算其平均值，得到平均响应耗时和响应成功率。
8.如权利要求1所述的方法，其特征在于，所述服务接口的最低可用标准，包括：根据所述服务接口所提供的服务内容，确定所述服务接口的可用平均耗时和可用成功率。
9.如权利要求8所述的方法，其特征在于，所述将所述平均响应耗时和响应成功率与该服务接口的最低可用标准进行比较，判断所述服务接口的健康状态，包括：
当所述平均响应耗时高于可用平均耗时，或响应成功率低于可用成功率时，所述服务接口标记为不可用，连续多次标记为不可用，且达到限制次数时，判断该服务接口的健康状态为故障状态；连续多次标记为不可用，且未达到限制次数时，判断该服务接口的健康状态仍为非故障状态；
当所述平均响应耗时低于可用平均耗时，且响应成功率高于可用成功率时，所述服务接口标记为可用，连续多次标记为可用时，判断该服务接口的健康状态为非故障状态。
10.一种健康检查装置，其特征在于，包括：
获取模块，用于获取业务系统向服务接口发起接口请求后，对所述服务接口进行调用产生的请求执行情况，所述请求执行情况包括请求响应耗时和请求响应结果；
确定模块，用于根据所述请求执行情况，确定所述服务接口在单位时间内的平均响应耗时和响应成功率；
判断模块，将所述平均响应耗时和响应成功率与该服务接口的最低可用标准进行比较，判断所述服务接口的健康状态。
11.如权利要求10所述的装置，其特征在于，还包括：
创建模块，用于创建健康状态表，所述健康状态表用于记录所述服务接口的健康状态，所有所述服务接口的初始健康状态均为非故障状态。
12.如权利要求11所述的装置，其特征在于，还包括：
更新模块，用于根据所述判断模块判断得出的健康状态，对所述健康状态表中所述服务接口的健康状态进行更新。
13.如权利要求12所述的装置，其特征在于，还包括：
查询过滤模块，用于通过查询所述健康状态表，判断所述服务接口的当下健康状态；
当所述服务接口的当下健康状态为故障状态时，对所述服务接口在故障之后，所接收到的接口请求进行过滤，判断是否通过所述接口请求；
对通过的接口请求，接收服务接口返回的请求执行情况；对不通过的接口请求，返回该接口请求的模拟响应；
当所述服务接口的当下健康状态为非故障状态时，接收服务接口返回的请求执行情况。
14.如权利要求13所述的装置，其特征在于，所述查询过滤模块进一步用于：
设置所述服务接口的接口请求阈值，对所述服务接口在故障之后，所接收到的接口请求进行累加，当接口请求的累加值达到所述阈值，将达到所述阈值后的接口请求作为通过的接口请求，并清空所述累加值。
15.如权利要求14所述的装置，其特征在于，所述阈值为动态阈值，所述查询过滤模块进一步用于：根据以下方式调整动态阈值，
当Q＝0时，N’＝N*(1-s％)；
并重新统计接下来t分钟内的Q，直至Q＞0，或N＜Nmin；
当Q≥Qmax时，N’＝N*(1+s％)；
并重新统计接下来t分钟内的Q，直至Q＜Qmax，或N＜Nmax；
其中，t表示调整动态阈值的时间间隔；Q表示t分钟内接口请求的累加值；N’表示动态阈值；N表示初始阈值；s表示最小调整幅度；Nmin表示服务接口正常运行时的日常最小接口请求量；Nmax表示服务接口正常运行时的日常最大接口请求量；Qmax表示服务接口在最长请求响应耗时最大可承受的接口请求量。
16.如权利要求10所述的装置，其特征在于，所述确定模块具体用于：
将单位时间内所有接口请求对所述服务接口的调用，所产生的请求响应耗时和请求响应结果，计算其平均值，得到平均响应耗时和响应成功率。
17.如权利要求10所述的装置，其特征在于，所述服务接口的最低可用标准，包括：根据所述服务接口所提供的服务内容，确定所述服务接口的可用平均耗时和可用成功率。
18.如权利要求17所述的装置，其特征在于，所述判断模块具体用于：
当所述平均响应耗时高于可用平均耗时，或响应成功率低于可用成功率时，所述服务接口标记为不可用，连续多次标记为不可用，且达到限制次数时，判断该服务接口的健康状态为故障状态；连续多次标记为不可用，且未达到限制次数时，判断该服务接口的健康状态仍为非故障状态；
当所述平均响应耗时低于可用平均耗时，且响应成功率高于可用成功率时，所述服务接口标记为可用，连续多次标记为可用时，判断该服务接口的健康状态为非故障状态。
19.一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至9中任一项所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811653471.7A CN109739726A (zh) | 2018-12-29 | 2018-12-29 | 一种健康检查方法、装置及电子设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811653471.7A CN109739726A (zh) | 2018-12-29 | 2018-12-29 | 一种健康检查方法、装置及电子设备 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN109739726A true CN109739726A (zh) | 2019-05-10 |
Family
ID=66362978
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811653471.7A Pending CN109739726A (zh) | 2018-12-29 | 2018-12-29 | 一种健康检查方法、装置及电子设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109739726A (zh) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110162424A (zh) * | 2019-05-23 | 2019-08-23 | 腾讯科技（深圳）有限公司 | 故障处理方法、系统、装置及存储介质 |
| CN110247823A (zh) * | 2019-06-13 | 2019-09-17 | 北京奇艺世纪科技有限公司 | 一种故障检测方法、装置及相关设备 |
| CN110430070A (zh) * | 2019-07-19 | 2019-11-08 | 北京奇艺世纪科技有限公司 | 一种服务状态分析方法、装置、服务器、数据分析设备及介质 |
| CN111404759A (zh) * | 2020-04-17 | 2020-07-10 | 腾讯科技（深圳）有限公司 | 服务检测方法、规则配置方法、相关设备及介质 |
| CN112765002A (zh) * | 2020-12-28 | 2021-05-07 | 中国人寿保险股份有限公司上海数据中心 | 一种应用系统健康情况评价方法、设备及存储介质 |
| CN115550218A (zh) * | 2022-10-11 | 2022-12-30 | 平安银行股份有限公司 | 基于接口自动化的应用监控方法、装置和可读存储介质 |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104239156A (zh) * | 2013-06-21 | 2014-12-24 | 阿里巴巴集团控股有限公司 | 一种外部服务的调用方法及系统 |
| US20150222504A1 (en) * | 2014-02-03 | 2015-08-06 | Apigee Corporation | System and method for monitoring and reporting data in api processing systems |
| CN105847057A (zh) * | 2016-03-29 | 2016-08-10 | 乐视控股（北京）有限公司 | 故障处理方法及装置 |
| CN106802864A (zh) * | 2016-12-30 | 2017-06-06 | 中国银联股份有限公司 | 一种基于金融系统的测试方法及装置 |
| CN107329877A (zh) * | 2017-06-29 | 2017-11-07 | 南京途牛科技有限公司 | 机票业务监控执行系统及方法 |
| CN107707384A (zh) * | 2017-09-06 | 2018-02-16 | 北京五八到家信息技术有限公司 | 一种基于调用外部服务的服务状态监测方法及监测系统 |
| CN108683605A (zh) * | 2018-06-12 | 2018-10-19 | 阿里巴巴集团控股有限公司 | 一种服务调用的限流方法和装置 |
-
2018
- 2018-12-29 CN CN201811653471.7A patent/CN109739726A/zh active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104239156A (zh) * | 2013-06-21 | 2014-12-24 | 阿里巴巴集团控股有限公司 | 一种外部服务的调用方法及系统 |
| US20150222504A1 (en) * | 2014-02-03 | 2015-08-06 | Apigee Corporation | System and method for monitoring and reporting data in api processing systems |
| CN105847057A (zh) * | 2016-03-29 | 2016-08-10 | 乐视控股（北京）有限公司 | 故障处理方法及装置 |
| CN106802864A (zh) * | 2016-12-30 | 2017-06-06 | 中国银联股份有限公司 | 一种基于金融系统的测试方法及装置 |
| CN107329877A (zh) * | 2017-06-29 | 2017-11-07 | 南京途牛科技有限公司 | 机票业务监控执行系统及方法 |
| CN107707384A (zh) * | 2017-09-06 | 2018-02-16 | 北京五八到家信息技术有限公司 | 一种基于调用外部服务的服务状态监测方法及监测系统 |
| CN108683605A (zh) * | 2018-06-12 | 2018-10-19 | 阿里巴巴集团控股有限公司 | 一种服务调用的限流方法和装置 |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110162424A (zh) * | 2019-05-23 | 2019-08-23 | 腾讯科技（深圳）有限公司 | 故障处理方法、系统、装置及存储介质 |
| CN110162424B (zh) * | 2019-05-23 | 2022-03-22 | 腾讯科技（深圳）有限公司 | 故障处理方法、系统、装置及存储介质 |
| CN110247823A (zh) * | 2019-06-13 | 2019-09-17 | 北京奇艺世纪科技有限公司 | 一种故障检测方法、装置及相关设备 |
| CN110430070A (zh) * | 2019-07-19 | 2019-11-08 | 北京奇艺世纪科技有限公司 | 一种服务状态分析方法、装置、服务器、数据分析设备及介质 |
| CN110430070B (zh) * | 2019-07-19 | 2022-07-22 | 北京奇艺世纪科技有限公司 | 一种服务状态分析方法、装置、服务器、数据分析设备及介质 |
| CN111404759A (zh) * | 2020-04-17 | 2020-07-10 | 腾讯科技（深圳）有限公司 | 服务检测方法、规则配置方法、相关设备及介质 |
| CN112765002A (zh) * | 2020-12-28 | 2021-05-07 | 中国人寿保险股份有限公司上海数据中心 | 一种应用系统健康情况评价方法、设备及存储介质 |
| CN112765002B (zh) * | 2020-12-28 | 2023-11-14 | 中国人寿保险股份有限公司上海数据中心 | 一种应用系统健康情况评价方法、设备及存储介质 |
| CN115550218A (zh) * | 2022-10-11 | 2022-12-30 | 平安银行股份有限公司 | 基于接口自动化的应用监控方法、装置和可读存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109739726A (zh) | 一种健康检查方法、装置及电子设备 | |
| US10637737B2 (en) | Managing alarms from distributed applications | |
| CN109491850A (zh) | 一种磁盘故障预测方法及装置 | |
| US20180239658A1 (en) | Programatically classifying alarms from distributed applications | |
| CN110535902A (zh) | 基于微服务实现监控智能化的处理方法及电子装置 | |
| US11838387B2 (en) | Fog node scheduling method and apparatus, computer device, and storage medium | |
| CN103607424B (zh) | 一种服务器连接方法及服务器系统 | |
| CN108958882A (zh) | 一种容器调整方法、装置和系统 | |
| CN108804119A (zh) | 配置更新方法、装置、系统、配置中心、应用节点及介质 | |
| CN108989075A (zh) | 一种网络故障定位方法及系统 | |
| WO2017030796A1 (en) | Diagnostic framework in computing systems | |
| CN104735088A (zh) | 一种cdn网络中服务器节点调整方法及装置 | |
| CN104579765A (zh) | 一种集群系统的容灾方法和装置 | |
| CN108845912A (zh) | 服务接口调用故障的报警方法及计算设备 | |
| CN113242297B (zh) | 服务系统及服务状态的调整方法 | |
| CN108173672A (zh) | 检测故障的方法和装置 | |
| Mendonça et al. | Modelling and analysing contextual failures for dependability requirements | |
| CN110417586A (zh) | 服务监控方法、服务节点、服务器及计算机可读存储介质 | |
| CN104683155A (zh) | 网络管理系统中的告警屏蔽机制 | |
| CN116225609A (zh) | Kubernetes集群的Pod调度方法、装置、设备及计算机可读介质 | |
| US10664525B2 (en) | Data partioning based on end user behavior | |
| CN115883407A (zh) | 一种数据采集方法、系统、设备及存储介质 | |
| CN110445650A (zh) | 检测报警方法、设备及服务器 | |
| CN116823251B (zh) | 一种基于聚合支付的服务商可信支付方法、设备及介质 | |
| CN109510730A (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 | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20200925 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20200925 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Applicant before: Alibaba Group Holding Ltd. |
|
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20190510 |