[发明专利]业务系统的状态检测方法、系统、装置及计算机可读介质

说明书

本发明涉及运维管理领域，尤其涉及业务系统的状态检测方法、系统、装置及计算机可读介质，所述状态检测方法包括：服务状态检测系统发送探测请求至业务系统；业务系统根据探测标识识别出探测请求；业务系统根据处理队列个数复制探测请求；业务系统将复制的探测请求送入处理队列，每个处理队列至少送入一个探测请求；业务系统通过处理队列处理探测请求，并得到每个处理队列的探测应答，实现了最大限度覆盖业务逻辑处理流程的同时得到业务处理的真实状态。

技术领域

本发明涉及运维管理领域，尤其涉及业务系统的状态检测方法、系统、装置及计算机可读介质。

技术背景

目前运维监控系统对于业务系统的状态监测主要的方法有以下几种：

1.心跳包模式

最基本的就是心跳包模式，即客户端定时向服务端发送一个事先约定好的大多数情况下无实际意义的报文请求，当服务端收到该请求后，返回一个应答，若客户端在一定时间内没有收到任何心跳应答，即可认为服务已出现问题，处于不可用状态，需要查明服务不可用原因并采集措施。本方法主要的不足之处在于对于被探测的服务而言，对心跳包的处理都是简单的直接返回应答，所以这样的探测结果正常时，只能证明该服务对心跳请求依旧正常，但服务的内部真实运行状态无从得知。

2.健康数据采集模式

这种模式需要服务本身支持或者在服务所在机器上安装其他与程序无关的独立服务/脚本不断收集宿主机状态数据例如CPU、Memory利用率以及服务本身运行数据例如QPS(Query per second每秒查询率)，队列个数等健康指标，再将这些健康数据存入数据库或者提供相关服务接口供采集程序采集汇总并经过简单对比得到当前系统的运行情况。目前大多数监控技术都采用这种方式，本质上都是靠在服务程序所在机器上安装采集程序采集健康数据然后统一处理的方式。这种方式已经可以比较全面的了解服务的当前健康情况，不足之处在于采集到的数据都是总体健康数据，是一种相对业务而言黑盒的方式来获取的数据，对于业务层面的可用性难以有一个很好的反馈，例如当某个业务已经异常时，如果这个业务对总体指标的贡献度较小，那么采集的总体数据将比较难反映出情况。此外，当系统内部有多个队列时，每个队列的情况也比较难反映。

3.数据包探测模式

探测数据包队列，跟踪该队列在每一段链路上的内部数据包传输间隔捕获探测数据包队列在每一个链路上的平均传输间隔，确认拥塞链路。这种方式可以一定程度获取系统节点的拥塞情况，但是同样只能得知系统的总体运行状态，无法得知具体业务的可用情况，当节点存在处理队列时，也同样难以得知每个队列内部的真正状态，例如当某个业务请求处理超时时，其它队列有可能还是正常，此时如果探测数据包队列从正常的通道过去，探测监控端便会认为该节点处于正常状态，只有当该业务请求请求量足够大将所有队列都堵死后，才会被探测监控端发现，然而这时候已经处于比较严重的地步了。

综上，目前主要的几种业务系统的状态检测方案都无法真实、全面的反映业务系统内部真实的运行状态。

发明内容

针对现有技术存在的技术问题，根据本发明实施例提出了业务系统的状态检测方法，包括：服务状态检测系统发送探测请求至业务系统；业务系统根据探测标识识别出探测请求；业务系统根据处理队列个数复制探测请求；业务系统将复制的探测请求送入处理队列，每个处理队列至少送入一个探测请求；业务系统通过处理队列处理探测请求，并得到每个处理队列的探测应答。

可选的，所述探测请求包括实际业务请求字段和探测标识，所述探测请求对应设置唯一的探测标识。

可选的，所述状态检测方法还包括：当探测请求处理需要访问数据库或者缓存时，调用代理数据库或者代理缓存。

可选的，代理数据库存储模拟账户数据，模拟账户数据的字段包括服务状态检测系统编号、模拟账户编号、账号及随机数。