CN107612760A - 一种业务服务的中断监测方法及*** - Google Patents

Abstract

本发明公开了一种业务服务的中断监测方法及***，其中方法包括：设置一个时间周期p；在所述时间周期p内监控一业务的所有请求的业务连接状态，若有任一业务连接完成第一次握手，执行后续步骤，否则判断所述业务的服务处于中断状态；监控所述业务连接的第二次握手状态，若有任一业务连接完成第二次握手，执行后续步骤，否则判断所述业务的服务处于中断状态；监控所述业务连接的第三次握手状态，若有任一业务连接完成第三次握手，判断所述业务的服务处于正常服务状态，否则判断所述业务的服务处于中断状态。本发明通过监控时间周期内业务连接的握手状态，若所述业务所有连接未完成连续的三次握手，则判断所述业务的服务处于中断状态。

Description

一种业务服务的中断监测方法及***

技术领域

本发明涉及IT运维领域，具体涉及一种业务服务的中断监测方法及***。

背景技术

当前，各行业IT信息化程度越来越高，甚至一些行业和企业已经达到完全无纸化办公。在基础网络承载基础上，核心的业务***或交易***的运行保障成为IT运维的重中之重。业务***对应的软件***后台服务(简称“业务服务”)的状态监测是一项关键运维技术工作。当用户无法连接或访问业务***时，很可能该业务***不够稳定和可靠，导致该业务服务异常退出并中断，所有用户无法登录和访问该***，严重影响和干扰企业和单位的正常运营。业务服务的中断状态，是业务***的最严重状态。对业务服务的中断状态的监测和判断，至关重要。在业务服务运行的载体计算机中，相对容易监测和判断服务的异常状态，比如监测进程状态等。但对于网络***，如何高效、准确判断服务的运行状态，相对困难。

从用户访问业务***的实时体验监测出发，提出一种监测和判断业务服务的中断状态的方法和监测***是目前迫切需要解决的问题。

发明内容

本发明从用户访问业务***的实时体验监测出发，提出了一种监测和判断业务服务的中断状态的方法和监测***，即一种业务服务的中断监测方法及***，通过监控时间周期内业务连接的握手状态，若所述业务连接未完成连续的三次握手，则判断所述业务的服务处于中断状态，从而快速、便捷的判断业务服务的状态。

为解决上述问题，本发明的第一方面提供了一种业务服务的中断监测方法，包括:设置一个时间周期p；在所述时间周期p内监控一业务的所有请求的业务连接状态，若有任一业务连接完成第一次握手，执行后续步骤，否则判断所述业务的服务处于中断状态；监控所述业务连接的第二次握手状态，若有任一业务连接完成第二次握手，执行后续步骤，否则判断所述业务的服务处于中断状态；监控所述业务连接的第三次握手状态，若有任一业务连接完成第三次握手，判断所述业务的服务处于正常服务状态，否则判断所述业务的服务处于中断状态。

进一步地，所述业务连接采用TCP传输控制协议。

进一步地，在所述时间周期p内监控所述业务的所有请求的业务连接状态之前，还包括：在客户端到服务器之间的业务链路中，设置至少一个探针，所述探针用于获取所述业务连接的业务数据，进而判断所述业务连接握手是否成功。

进一步地，在所述时间周期p内监控所述业务的所有请求的业务连接状态时，若没有任何业务连接发生，则判断在所述时间周期p内无业务访问。

根据本发明的另一个方面，提供了一种业务服务的中断监测***，包括：

客户端、服务器和所述客户端和服务器之间的业务链路。

进一步地，该***还包括：至少一个探针，设置于所述业务链路中，所述探针用于获取所述业务链路中产生业务连接的业务数据，进而判断所述业务连接握手是否成功。

进一步地，该***还包括业务服务处理单元，与所述探针连接，所述业务服务处理单元包括：时间周期设置模块，用于设置一个时间周期p；第一监控模块，与所述时间周期设置模块连接，用于在所述时间周期p内监控一业务所有请求的业务连接的第一次握手状态；第二监控模块，与所述第一监控模块连接，用于监控所述业务连接的第二次握手状态；第三监控模块，与所述第二监控模块连接，用于监控所述业务连接的第三次握手状态；中断状态判断模块，与所述第一监控模块、第二监控模块和第三监控模块分别连接，用于判断所述业务的服务是否处于中断状态。

进一步地，所述业务连接采用TCP传输控制协议。

进一步地，在所述时间周期p内监控所述业务所有请求的业务连接时，若没有任何业务连接发生，则中断状态判断模块判断在所述时间周期p内无业务访问。

本发明的上述技术方案具有如下有益的技术效果：

1.保障关键业务***在网络环境下的可靠、高效、稳定运行；

2.针对业务***可能出现的异常中断退出，实时、有效地对在线业务***服务状态进行判断与监测。

附图说明

图1是本发明提供的一种业务服务的中断监测方法的方法流程示意图；

图2是本发明提供的一种业务服务的中断监测方法的原理示意图；

图3是本发明提供的一种业务服务的中断监测方***的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明了，下面结合具体实施方式并参照附图，对本发明进一步详细说明。应该理解，这些描述只是示例性的，而并非要限制本发明的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本发明的概念。

应当理解的是，本发明的上述具体实施方式仅仅用于示例性说明或解释本发明的原理，而不构成对本发明的限制。因此，在不偏离本发明的精神和范围的情况下所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。此外，本发明所附权利要求旨在涵盖落入所附权利要求范围和边界、或者这种范围和边界的等同形式内的全部变化和修改例。

请参阅图1，图1是本发明提供的一种业务服务的中断监测方法的方法流程示意图。

如图1所示，本发明提供了一种业务服务的中断监测方法，该方法包括：

S100，设置一个时间周期p。

作为一种优选的实施方式，时间周期p为1分钟。

S200，在所述时间周期p内监控一业务的所有请求的业务连接状态，若有任一业务连接完成第一次握手，执行步骤S300，否则跳转到步骤S500。

其中，所述业务连接采用TCP传输控制协议(Transmission Control Protocol)。本发明提供的第一次握手、第二次握手和第三次握手都是基于TCP传输控制协议建立的，为便于理解，后文中将第一次握手描述为第一次TCP握手，将二次握手描述为第二次TCP握手，第三次握手描述为第三次TCP握手，含义相同，不在赘述。

请参阅图2，图2是本发明提供的一种业务服务的中断监测方法的原理示意图。

如图2所示，在S200步骤中，第一次握手指第一次TCP握手，即建立连接时，客户端发送syn包(syn＝j)到服务器，并进入SYN_SENT状态，等待服务器确认。SYN为同步序列编号(Synchronize Sequence Numbers)。

若监控到时间周期p内有任一业务连接完成第一次TCP握手，执行后续步骤S300；若监控到时间周期p内没有任何业务连接完成第一次TCP握手，则跳转到步骤S500，判断所述业务的服务处于中断状态。

需要注意的是，这里的“没有任何业务连接完成第一次TCP握手”指的是，监控到有第一次TCP握手出现，但是没有完成该握手。

所述时间周期p内监控所述业务的所有请求的业务连接状态时，若没有任何业务连接发生，则判断在所述时间周期p内无业务访问。因为连第一次TCP握手都没有监控到，并不能认为所述业务的服务处于中断状态，而是认为无业务访问，由于根本没有业务访问，所以无法判断为中断状态。

S300，监控所述业务连接的第二次握手状态，若有任一业务连接完成第二次握手，执行步骤S300，否则跳转到步骤S500。

如图2所示，在S300步骤中，第二次握手指第二次TCP握手，指服务器收到syn包后，确认客户的SYN(ack＝j+1)，同时自己也发送一个SYN包(syn＝k)，即SYN+ACK包，此时服务器进入SYN_RECV状态。

若在时间周期p内监控到有任一业务连接完成第二次TCP握手，执行后续步骤S400。

若没有任何业务连接完成第二次TCP握手，执行步骤S500，判断所述业务的服务处于中断状态。由于第二次TCP握手是已经完成第一次TCP握手的基础上建立的，所以必须完成连续的两次TCP握手才可以执行后续的步骤。

具体地，认为业务连接完成了第一次TCP握手，但是没有完成第二次TCP握手，因此判断所述业务的服务处于中断状态。

S400，监控所述业务连接的第三次握手状态，若有任一业务连接完成第三次握手，执行步骤S300，否则跳转到步骤S500。

如图2所示，在S400步骤中，第三次握手指第三次TCP握手，指客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack＝k+1)，此包发送完毕，客户端和服务器同时进入ESTABLISHED(TCP连接成功)状态，完成三次握手。

若在时间周期p内监控到有任一业务连接完成第三次TCP握手，执行步骤600，判断所述业务的服务处于正常服务状态。此时业务连接已经完成连续的三次TCP握手。

如果没有任何业务连接完成第三次TCP握手，执行步骤S500，判断所述业务的服务处于中断状态。具体地，认为业务连接完成了两次连续的TCP握手，但是没有完成第三次TCP握手，因此判断所述业务的服务处于中断状态。

S500，判断所述业务的服务处于中断状态。

当业务的服务状态处于中断时，用户访问该***时出现页面无法打开、数据无法获取到等现象。

S600，判断所述业务的服务处于正常服务状态。

在所述时间周期p内监控所述业务的所有请求的业务连接状态之前，还包括：S150，在客户端到服务器之间的业务链路中，设置至少一个探针，所述探针用于获取所述业务连接的业务数据，进而判断所述业务连接握手是否成功。

具体地，该探针设置于业务链路之中，获取客户端到服务器之间所有的TCP握手数据，根据探针获取到的TCP握手数据进行中断状态判断。

图3是本发明提供的一种业务服务的中断监测***的结构示意图。

如图3所示，本发明还提供了一种业务服务的中断监测***，该***包括：客户端50、服务器60和所述客户端50和服务器60之间的业务链路70。

其中，所述***还包括：至少一个探针80，设置于所述业务链路70中，所述探针80用于获取所述业务链路70中产生业务连接的业务数据，进而判断所述业务连接握手是否成功。

具体地，该探针80设置于业务链路70之中，获取客户端50到服务器60之间所有的握手数据，根据探针80获取到的握手数据进行中断状态判断。

其中，所述***还包括：业务服务处理单元90，与所述探针80连接，所述业务服务处理单元90包括：

时间周期设置模块901，用于设置一个时间周期p。

作为一种优选的实施方式，时间周期p为1分钟。

第一监控模块902，与所述时间周期设置模块901连接，用于在所述时间周期p内监控一业务所有请求的业务连接的第一次握手状态。

其中，所述业务连接采用TCP传输控制协议(Transmission ControlProtocol)。本发明提供的第一次握手、第二次握手和第三次握手都是基于TCP传输控制协议建立的，为便于理解，后文中将第一次握手描述为第一次TCP握手，将二次握手描述为第二次TCP握手，第三次握手描述为第三次TCP握手，含义相同，不在赘述。

具体地，第一次握手指第一次TCP握手，即建立连接时，客户端50发送syn包(syn＝j)到服务器，并进入SYN_SENT状态，等待服务器确认。SYN为同步序列编号(SynchronizeSequence Numbers)。

若第一监控模块902监控到时间周期p内有任一业务连接完成第一次TCP握手，则转到第二监控模块903继续监控。

若第一监控模块902监控到时间周期p内没有任何业务连接完成第一次TCP握手，则判断所述业务的服务处于中断状态。

需要注意的是，这里的“没有任何业务连接完成第一次TCP握手”指的是，监控到有第一次TCP握手出现，但是没有完成该握手。

当第一监控模块902在时间周期p内监控所述业务的所有请求的业务连接状态时，若没有任何业务连接发生，则判断在时间周期p内无业务访问。因为连第一次TCP握手都没有监控到，并不能认为所述业务的服务处于中断状态，而是认为无业务访问，由于根本没有业务访问，所以无法判断为中断状态。

第二监控模块903，与所述第一监控模块902连接，用于监控所述业务连接的第二次握手状态。

具体地，第二次握手指第二次TCP握手，指服务器收到syn包后，确认客户的SYN(ack＝j+1)，同时自己也发送一个SYN包(syn＝k)，即SYN+ACK包，此时服务器进入SYN_RECV状态。

若第二监控模块903在时间周期p内监控到有任一业务连接完成第二次TCP握手，则转到第三监控模块904继续监控。

若第二监控模块903没有任何业务连接完成第二次TCP握手，判断所述业务的服务处于中断状态。由于第二次TCP握手是已经完成第一次TCP握手的基础上建立的，所以必须完成连续的两次TCP握手才可以转到第三监控模块904继续监控。

第三监控模块904，与所述第二监控模块903连接，用于监控所述业务连接的第三次握手状态。

具体地，第三次握手指第三次TCP握手，指客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack＝k+1)，此包发送完毕，客户端和服务器同时进入ESTABLISHED(TCP连接成功)状态，完成三次握手。

若第三监控模块904在时间周期p内监控到有任一业务连接完成第三次TCP握手，判断所述业务的服务处于正常服务状态。此时业务连接已经完成连续的三次TCP握手。

如果第三监控模块904监控时间周期p内没有任何业务连接完成第三次TCP握手，判断所述业务的服务处于中断状态。具体地，认为业务连接完成了两次连续的TCP握手，但是没有完成第三次TCP握手，因此判断所述业务的服务处于中断状态。

中断状态判断模块905，与所述第一监控模块902、第二监控模块903和第三监控模块904分别连接，用于判断所述业务的服务是否处于中断状态。

本发明旨在保护一种业务服务的中断监测方法及***，通过监控时间周期内业务连接的握手状态，若所述业务连接未完成连续的三次握手，则判断所述业务的服务处于中断状态，从而快速、便捷的判断业务服务的状态。本发明针对业务***可能出现的异常中断退出，实时、有效地对在线业务***服务状态进行判断与监测，从而保障关键业务***在网络环境下的可靠、高效、稳定运行。

应当理解的是，本发明的上述具体实施方式仅仅用于示例性说明或解释本发明的原理，而不构成对本发明的限制。因此，在不偏离本发明的精神和范围的情况下所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。此外，本发明所附权利要求旨在涵盖落入所附权利要求范围和边界、或者这种范围和边界的等同形式内的全部变化和修改例。

Claims (9)

1.一种业务服务的中断监测方法，其特征在于，包括：

S100，设置一个时间周期p；

S200，在所述时间周期p内监控一业务的所有请求的业务连接状态，若有任一业务连接完成第一次握手，执行步骤S300，否则执行步骤S500；

S300，监控所述业务连接的第二次握手状态，若有任一业务连接完成第二次握手，执行步骤S400，否则执行步骤S500；

S400，监控所述业务连接的第三次握手状态，若有任一业务连接完成第三次握手，执行步骤S600，否则执行步骤S500；

S500，判断所述业务的服务处于中断状态；

S600，判断所述业务的服务处于正常服务状态。

2.根据权利要求1所述的方法，其中，所述业务连接采用TCP传输控制协议。

3.根据权利要求2所述的方法，其中，在所述时间周期p内监控所述业务的所有请求的业务连接状态之前，还包括：

S150，在客户端到服务器之间的业务链路中，设置至少一个探针，所述探针用于获取所述业务连接的业务数据，进而判断所述业务连接握手是否成功。

4.根据权利要求1所述的方法，其中，在所述时间周期p内监控所述业务的所有请求的业务连接状态时，若没有任何业务连接发生，则判断在所述时间周期p内无业务访问。

5.一种业务服务的中断监测***，其特征在于，包括：客户端(50)、服务器(60)和所述客户端(50)和服务器(60)之间的业务链路(70)。

6.根据权利要求5所述的***，其中，还包括：至少一个探针(80)，设置于所述业务链路(70)中，所述探针(80)用于获取所述业务链路(70)中产生业务连接的业务数据，进而判断所述业务连接握手是否成功。

7.根据权利要求6所述的***，其中，还包括业务服务处理单元(90)，与所述探针(80)连接，所述业务服务处理单元(90)包括：

时间周期设置模块(901)，用于设置一个时间周期p；

第一监控模块(902)，与所述时间周期设置模块(901)连接，用于在所述时间周期p内监控一业务所有请求的业务连接的第一次握手状态；

第二监控模块(903)，与所述第一监控模块连接(902)，用于监控所述业务连接的第二次握手状态；

第三监控模块(904)，与所述第二监控模块(903)连接，用于监控所述业务连接的第三次握手状态；

中断状态判断模块(905)，与所述第一监控模块(902)、第二监控模块(903)和第三监控模块(904)分别连接，用于判断所述业务的服务是否处于中断状态。

8.根据权利要求7所述的***，其中，所述业务连接采用TCP传输控制协议。

9.根据权利要求7所述的***，其中，在所述时间周期p内监控所述业务所有请求的业务连接时，若没有任何业务连接发生，则中断状态判断模块(905)判断在所述时间周期p内无业务访问。