CN106656557A - 业务状态处理方法和装置 - Google Patents

Abstract

本发明公开了一种业务状态处理方法及装置。其中，该方法包括：在预定周期内，获取业务中的每个子业务对应的服务进程的运行状态；对每个子业务对应的服务进程的运行状态进行汇总得到第一汇总结果；根据第一汇总结果确定业务的状态。通过本发明解决了现有技术中采用监控点进行监控的监控系统所存在的问题，改善了监控效果。

Description

业务状态处理方法和装置

技术领域

本发明涉及通讯技术领域，具体而言，涉及业务状态处理方法和装置。

背景技术

随着互联网浪潮的兴起和“互联网+”概念的普及，各类互联网业务蓬勃发展，互联网产品大量涌现。在这种趋势下，同一类型的产品往往同时面临几十、上百款竞品，行业竞争异常激烈。为了能够紧跟用户需求、不断试错、提升用户体验，业务的开发和迭代周期也被一再缩短。

现阶段行业内，针对业务系统运行状态的监控主要基于TPC、SPEC、HPCC等搭建而来。以上做法基本上都是搭建一个专属的业务监控系统，然后在各项业务子进程中添加监控点，将各个监控点的数据进行汇总分析，同时相伴的还有一个专属的分析系统并将分析结果集成在一个后台系统中用于展示。这些系统都能够提供详尽的业务系统运行状态数据，包括每个业务节点的访问量，丢包率，超时等。

目前，常见的业务监控系统的工作流程是用户通过客户端等终端向服务器发送请求之后，中心服务器就会将请求转发到对应的业务服务器上，然后对应业务服务器上的业务模块就会执行业务处理，并向其所位于的业务服务器上的监控采集模块发送业务监控数据，其中所述业务监控数据以预定格式指示业务模块名称和监控点名称；在达到预定的时间间隔时由所述监控采集模块基于至少一个所接收的业务监控数据生成监控信息；将所生成的监控信息发送到监控服务器；由所述监控服务器存储所接收的监控信息；以及由所述监控服务器按照统计时间间隔基于所存储的监控信息生成分级统计汇总数据。其中评判业务系统的健康程度时经常使用TPC、SPEC、Linpack、HPCC等，这些方法能够从处理器性能、服务器系统性能、商业应用性能等方面模拟或者量化线上业务请求，然后给出了一个量化的评价指标。

一般TPC类型服务器评测体系的做法是在一个服务器上安装一个数据库,然后在数据库模拟一些标准化操作,最后会得到数据库每分钟处理事务数或数据库每秒钟处理事务数这两种统计结果。TPC就是用这两种统计结果来评价服务器的性能；一般SPEC服务器评测体系的做法是一个全面衡量Web应用中java企业应用服务器性能的基础测试。在这个基准测试中，系统模拟一个现代化企业的电子化业务工作，如客户定购查询、产品生产制造管理、供应商等，给系统以巨大的负载，以全面测试运行典型java业务应用的服务器性能水平；一般Linpack服务器评测体系的做法是在目标集群中运行Linpack测试程序,测试结果以浮点运算每秒(Flops)给出。其中：MFlops＝每秒一百万次(10^6)浮点运算、GFlops＝每秒十亿次(10^9)浮点运算。

随着互联网产品需求的高速变更，业务开发时的敏捷及快速迭代要求，从现阶段监控系统的工作流程中可以看出，虽然上述这些传统的业务监控系统能够对业务系统提供详细的运行状态数据，但也暴露出很多弊端：

首先，传统监控系统需要在各个子项业务中添加监控点，当业务快速扩张时需要添加的监控点也急速增多，这无疑增大了开发的复杂度和任务量，需要大量人力资源；其次，快速增多的监控数据，也要求对监控点的汇总分析系统进行快速迭代，这会占用更多的人力资源；再次，监控数据的增多也需要投入大量的开发资源和服务器资源，占用资源降低速度；最后，在业务快速扩张的过程中，人力物力都会比较紧张，难以维护一个同样快速膨胀的监控系统，监控系统的有效性就会大打折扣。

综上，传统方式打造的监控系统很难适应高速扩张的业务系统，现在常用的业务监控系统不适用于业务高速发展的互联网业务，而且缺乏对业务报警扩展能力的支持，具有应用的局限性。

针对现有技术中采用监控点进行监控的监控系统所存在的问题，目前尚未提出有效的解决方案。

发明内容

本发明提供了一种业务状态处理方法和装置，以解决现有技术中采用监控点进行监控的监控系统所存在的问题。

根据本发明实施例的一个方面，提供了一种业务状态处理方法，包括：在预定周期内，获取业务中的每个子业务对应的服务进程的运行状态；对所述每个子业务对应的服务进程的运行状态进行汇总得到第一汇总结果；根据所述第一汇总结果确定所述业务的状态。

进一步地，在确定所述业务状态之后，所述方法还包括：在所述业务的状态符合第一预定条件和/或所述子业务对应的服务进程的运行状态符合第二预定条件的情况下，进行告警。

进一步地，获取业务中的每个子业务对应的服务进程的运行状态包括：统计所述每个子业务对应的服务进程每次对接受到请求的处理时间；在所述预定周期内对所述处理时间进行累积得到累计结果；根据所述累积结果获取所述预定周期内的运行状态。

进一步地，根据所述累积结果获取所述预定时间内的运行状态包括：计算所述预定周期内的所述每个子业务对应的服务进程处理接收到请求的理论处理时间的上限；将所述累积结果与所述理论处理时间的上限的比值作为健康值，其中，所述健康值用于标识所述运行状态。

进一步地，所述方法还包括：对预定时间段内的所述每个子业务对应的服务进程的每个所述预定周期的运行状态进行汇总得到的第二汇总结果，其中，所述预定时间段大于所述预定周期；根据所述第二汇总结果确定所述业务的状态。

进一步地，对所述每个子业务对应的服务进程的运行状态进行汇总还包括：获取所述预定时间段内所述每个子业务对应的服务进程的总运行状态；对所述每个子业务对应的服务进程的总运行状态进行排序。

进一步地，对所述每个子业务对应的服务进程的运行状态进行汇总还包括：对所述总运行状态的排序结果进行告警。

进一步地，所述预定周期为时间片。

根据本发明实施例的另一方面，提供了一种业务状态处理装置。根据本发明的业务状态处理装置包括：获取单元，用于在预定周期内，获取业务中的每个子业务对应的服务进程的运行状态；汇总单元，用于对所述每个子业务对应的服务进程的运行状态进行汇总得到第一汇总结果；确认单元，根据所述第一汇总结果确定所述业务的状态。进一步地，所述业务状态处理装置还包括：告警单元，用于在所述业务的状态符合第一预定条件和/或所述子业务对应的服务进程的运行状态符合第二预定条件的情况下，进行告警。

进一步地，所述获取单元包括：统计模块，用于统计所述每个子业务对应的服务进程每次对接受到请求的处理时间；累计模块，用于在所述预定周期内对所述处理时间进行累积得到累计结果；第一获取模块，用于根据所述累积结果获取所述预定周期内的运行状态。

进一步地，所述第一获取模块用于：计算所述预定周期内的所述每个子业务对应的服务进程处理接收到请求的理论处理时间的上限；并将所述累积结果与所述理论处理时间的上限的比值作为健康值，其中，所述健康值用于标识所述运行状态。

进一步地，所述汇总单元还用于对：预定时间段内的所述每个子业务对应的服务进程的每个所述预定周期的运行状态进行汇总得到的第二汇总结果，其中，所述预定时间段大于所述预定周期；所述确认单元还用于：根据所述第二汇总结果确定所述业务的状态。

进一步地，所述汇总单元还包括：第二获取模块，用于获取所述预定时间段内所述每个子业务对应的服务进程的总运行状态；排序模块，用于对所述每个子业务对应的服务进程的总运行状态进行排序。

进一步地：所述汇总单元还包括：告警模块，用于对所述总运行状态的排序结果进行警告。

根据发明实施例，采用了在预定周期内，获取业务中的每个子业务对应的服务进程的运行状态；对所述每个子业务对应的服务进程的运行状态进行汇总得到第一汇总结果；根据所述第一汇总结果确定所述业务的状态。通过本发明解决了现有技术中采用监控点进行监控的监控系统所存在的问题，改善了监控效果。

附图说明

构成本申请的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的一种业务状态处理方法的流程图；

图2是根据本发明实施例的一种业务状态处理方法的系统结构图；

图3是根据本发明实施例的一种业务状态处理方法的数据流程图；

图4是是根据本发明实施例的一种业务状态处理方法的每日汇总邮件示意图；

图5是根据本发明实施例的一种业务状态处理装置的具体硬件架构示意图；以及

图6是根据本发明实施例的一种业务状态处理装置的示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本发明实施例提供了一种业务状态处理方法。图1是根据本发明实施例的一种业务状态处理方法的流程图。如图1所示，该方法包括步骤如下：

步骤S102，在预定周期内，获取业务中的每个子业务对应的服务进程的运行状态；

步骤S104，对每个子业务对应的服务进程的运行状态进行汇总得到第一汇总结果；

步骤S106，根据第一汇总结果确定该业务的状态。

在上述步骤，采用了监控一个业务中的每个子业务服务进程的状态，通过这种状态的汇总就可以得知该业务的运行情况，这不同于现有技术中的设置不同监控点的处理方法，在业务的流程进行调整之后，由于上述步骤当中并没有针对业务本身的流程设置监控点，所以不需要对监控进行太大的调整。从而解决了现有技术中采用监控点进行监控的监控系统所存在的问题，改善了监控效果。

例如，如果将注册看成一个业务，在该业务中有一个短信发送接收处理子业务，该子业务对应一个服务进程。由于某种原因需要对短信的发送接收的流程进行改动，将原来发送一次短信修改为发送多次短信，此时按照现有技术中的处理，需要增加多个监控点，这样的处理比较繁琐，而在上述步骤中，虽然流程发生了变动，但是服务进程仍然是在运行中，监控的是服务进程，此时只需要观察服务进程的负荷是否变化即可，而不需要对监控的流程进行调整。

上述步骤中的预定的周期可以根据实际的需要进行调整，对于一个业务的所有的子业务可以采用同样的周期，也可以对不同的子业务采用不同的周期。作为一个可选的方式，对子业务采用的不同周期可以根据子业务的优先级来确定。例如，如果一个子业务的优先级很高，即该子业务比较重要，周期就可以设置的短一点，如果该子业务的级别比较低，周期可以设置的长一点。这样的处理可以把有限的监控资源使用到比较重要的地方，提高监控的效果。

在一个可选的实施方式中，可以通过定时器来实现周期，此时可以在总的业务流程中设置一个定时器，在一个固定可调整的时间段内统计每一个业务进程的运行状态。也可以对于业务的每个子业务均设置一个定时器，用来统计每个子业务的运行状态。

运行状态的表示方法有很多种，例如，可以通过获取服务进程的负载情况来判断服务进程的运行状态，服务进行的负载状况可以通过对请求的处理时间来进行表示，当然也可以使用其他的参数来进行表示，可以根据实际的需要来确定使用什么类型的参数来表示服务进程负载。在一个可选实施方式中，采用了处理时间表示，此时，获取业务中的每个子业务对应的服务进程的运行状态可以包括如下步骤：

步骤S202，统计每个子业务对应的服务进程每次对接受到请求的处理时间，即计算每次的处理耗时时间；

步骤S204，在预定周期内对处理时间进行累积得到累计结果；即计算出当前统计周期内的总处理耗时时间；

步骤S206，根据累积结果获取预定周期内的运行状态。

通过上述步骤使用了处理时间来表示运行状态，这是由于处理时间相对其他参数而言更能表示运行状态，会取得相对较好的监控效果。

为了使运行状态表示的更加形象，在一个可选实施方式中，可以使用健康度这个词来表示运行状态，例如，在每个业务进程内对当前统计周期内每一个外部请求的处理耗时做累积，进而计算出当前统计周期内的总处理耗时时间。

在确定上述业务状态之后，在一个可选实施方式中，可以针对整个业务来进行告警，也可以根据每个子业务进行告警，即，在业务的状态符合第一预定条件和/或子业务对应的服务进程的运行状态符合第二预定条件的情况下，进行告警。第一预定条件和第二预定条件可以包括很多种情况，例如，根据不同的健康度设置告警阈值。例如，当实时健康度高于75实时通过短信，可以通过即时通讯软件进行告警。此处的健康度可以是业务的健康度，一个业务的健康度可以是由组成其的子业务的健康度经过计算得到的。也可以是子业务的健康度，每个子业务的健康度不符合阈值则可以针对该子业务进行单独报警。

通过上述步骤中判断预定条件的方式判断子业务对应的服务进程的运行状态，可以更加准确快速的对业务状态进行监控，能够及时发现问题反馈，每一个子业务有所变动时可以及时的获得告警信息。下面以一个可选实施方式进行说明。

在该例子中，第一预定条件用来判断针对业务是否需要进行告警，在该情况下可以分别获取每个子业务的健康度，然后进行汇总，判断汇总后的健康度是否超过阈值，如果超过健康度阀值则进行告警。第二预定条件可以针对子业务的健康度进行告警，在这种情况下，如果一个子业务的健康度不符合条件，则针对该子业务进行单独告警。在该例子中，健康度阀值可以包括至少两个阈值，其中一个阈值对应于业务，所有的子业务可以对应一个阈值，或者也可以每个子业务均对应一个阈值，或者也可以对子业务进行分组，每组子业务对应一个阈值。满足这些阈值可以认为是符合第一预定条件和/或第二预定条件。例如，实时健康度的数值范围是0-100区间，0表示最空闲，100表示最忙。设定健康度阀值为75，当实时健康度高于75实时通过短信、易信告警。该例子的75的健康度阈值可以是针对一个子业务的，也可以是针对一组子业务的，或者也可以是针对业务的。

在一个可选的实施方式中，步骤S206累积结果获取预定时间内的运行状态包括：计算预定周期内的每个子业务对应的服务进程处理接收到请求的理论处理时间的上限；将累积结果与理论处理时间的上限的比值作为健康值，其中，健康值用于标识运行状态。

通过对健康值具体的计算，来使运行状态的评估更加精确化。

例如：用总处理耗时时间和统计周期内理论的处理时间上限做百分比除法而算出当前统计周期的实时健康度。实时健康度的数值范围是0-100区间，0表示最空闲，100表示最忙。

在一个可选的实施方式中，可以对预定时间内的每个子业务分别对应的总的运行状态进行汇总得到汇总结果，例如，可以对短信处理进行一个月内的运行状态进行汇总，然后将一个月内的所有的子业务的运行状态都进行汇总得到该业务的在这一个月内的运行情况。这一个月的时间是可以自由设定的，这样可以使用户不仅仅了解一个周期内的运行情况，还可以了解一个比较长的时间段的总体的运行情况。即，在该可选实施例中，

即，上述方法还可以包括：对预定时间段内的每个子业务对应的服务进程的每个预定周期的运行状态进行汇总得到的第二汇总结果，其中，预定时间段大于预定周期。

为了描述方便，可以将该预定时间段的汇总所有子业务状态得到的结果称为是第二汇总结果。在这种情况下，该可选实施方式可以通过如下步骤实现：

对预定时间段内的每个子业务对应的服务进程的每个预定周期的运行状态进行汇总，得到第二汇总结果；

根据第二汇总结果确定业务在预定时间段内的状态。

通过上述步骤在预定时间段内的对各子业务运行状态的汇总，可以对某一段时间内的运行状态进行监控统计，了解到每一段时间内业务的运行状态及变化。例如：也可以将当天所有子业务处理进程的实时健康度进行汇总。

在一个可选的实施方式中，对每个子业务对应的服务进程的运行状态进行汇总还包括：获取预定时间段内每个子业务对应的服务进程的总运行状态；对每个子业务对应的服务进程的总运行状态进行排序。

通过将服务进程的总运行状态排序，可以更加直观的看到运行状态的优先需要注意的次序，从而方便快捷的监控运行状态。例如，按照各个业务，把业务的所有进程当天的实时健康度求和即得到该业务的当天的总健康度，然后对所有子业务按照总健康度的值从大到小排序。通过上述方式每天都能根据健康度排序数据发现有排名异动的业务，可以快速的发现还处于异常初期的业务，便于进一步进行业务优化。随着业务需求的变动也可以了解到各个业务的服务器资源使用情况，按照健康度排序的指标可以有针对的进行系统部署调整，对健康度较高的业务增加部署，健康度较低的业务减少部署。既满足业务需求，也减少服务器资源浪费。

在一个可选的实施方式中,对每个子业务对应的服务进程的运行状态进行汇总还包括：对总运行状态的排序结果进行告警。

通过以上方法，每当业务有异常的时候会都会实时收到该子业务的告警，保证了事件处理的及时性。

告警的方式可以有很多种，作为可选的实施方式可以通过发送邮件、短信和/或即时消息进行告警，这里的即时消息是指通过即时通讯软件发送的消息。通过使用不同分类报警，能够快速的应对系统中出现的突发问题，具有很好的扩展性。

周期可以按照不同的时间粒度来进行设计，例如，可以是按照秒来设置周期，也可以是按照毫秒设置周期等，在一个可选的实施方式中，预定周期可以为系统中的时间片。通过选择使用时间片来判断业务的运行状态，根据不同的时间片准确的区分系统运行状态，即系统健康度的信息，从而降低了开发难度和工作量。

作为可选的方式可以是：在总的业务流程中设置一个定时器，服务器在一个固定可调整的时间段内统计每一个业务进程的运行状态(计算子业务的负载)，相当于计算健康度，并设置不同等级的健康度超限阈值，可以包括负载数据阀值和变化量阀值，这两个阈值均可以作为业务的阈值来进行告警判断，也可以作为每个子业务的阈值来进行判断。作为业务的阈值来进行判断的情况下，这两个阈值作为上述实施例的第一预定条件；作为子业务的阈值来进行判断的情况下，这两个阈值可以作为上述实施例的第二预定条件。根据这两个阈值可以得到健康度，如果健康度低于超限阈值时就会触发相对应的实时告警，以IM、邮件或短信的方式发出消息。同时各个业务也会每天进行一次健康度排序，发出总的统计邮件，进而对业务系统进行长期跟踪。

上述实施例通过选择使用时间片来判断业务的运行状态，能够提供较为准确的系统健康度信息，同时降低了开发难度和工作量，提供系统分类报警能够快速应对系统中出现的突发问题，具有很好的扩展性，从而能够更好的适应快速迭代的互联网产品业务。

下面结合一个可选的实施例进行说明。

图3是根据本发明实施例的一种业务状态处理方法的数据流程图，作为可选的实施方式，如图3所示，一个子业务的状态数据从产生到汇总的分级过滤处理过程可以如下：

一个典型的业务系统是由许多个子业务组合而来的，各个子业务分别对应处理各自的业务需求和任务。服务器响应请求后，通过不断的检查各个子业务的运行状态，即计算各个子业务的负载数据，然后汇总在一起进行分析过滤，根据这些子系统的运行状态数据(也就是负载数据)来确定业务系统的健康度。常见的业务产品开发是一个开发团队完成的，每个开发负责自己开发的子业务，也就更加了解自己开发的业务实现细节，能够更快速的发现问题并解决问题。通过按照子业务划分的方式可以快速找到相关开发人员，便于快速处理突发问题，同时负责该业务的开发人员也可以通过查阅相关数据来判断是否需要进行优化等操作。

其中在各子业务中设置一个固定的时间，在相隔一段时间之后就会上报一次自身的运行情况(即负载数据)；设置时间的具体的实现方法是在系统处理任务的底层类中添加一个统计任务运行时间的函数方法，每一个继承该底层类的业务处理都会执行到这个方法，也就会统计到没执行一次任务的耗时，然后在全局设定STAT_CYCLE时间片作为固定的时间段，定时上报自己的运行时间数据，同时还会与系统分配的时间上限进行百分比计算，上述计算结果作为业务运行的阈值，阈值的具体的计算公式(1)如下：

run_load＝self.pro_time/(self.thread_num×STAT_CYCLE) (1)

其中run_load为负载的值，self.pro_time为子业务在一个时间片内执行任务的耗时，self.thread_num为子业务的线程数目，STAT_CYCLE为时间片。

告警提示是在将各个子业务的负载信息汇总以后，添加一个分析过滤程序定时将汇总的数据发送到IM聊天公众号，便于开发团队及时了解系统健康度状态。同时汇总系统还会每日早上发送上一天的汇总数据邮件，这样可以更加直观的了解各项子系统的负载和变化情况。在业务汇总中还有一个分级过滤，如果某项子业务的负载数据超过设定的阈值，就会触发业务报警，系统会将该子业务的相关信息通过短信、IM、邮件等多种方式发送给相关业务责任人。这样业务的开发者就能够在第一时间处理对应的问题，保证了业务系统的安全性和稳定性。具体可以参看图5为本实施例一种业务状态处理方法的具体硬件架构示意图，如图5所示，常见的业务系统一般都采用典型的分布式系统，在多个服务器中分别运行各个子业务。各个子业务产生的状态数据汇总到一台汇总分析服务器中。

图2为本实施例的系统结构图，如图2所示，PC客户端、移动端、web端的请求都会转发到各个对应的子业务中，在子业务中统计每次的请求处理时间，然后根据负载计算公式计算出负载，将各子系统的负载数据汇总在一起。数据汇总模块还会对负载数据进行过滤，设定了负载的阈值和负载变化量的阈值。如果负载过高或者变化量过大就会触发报警。在本发明中，设定了STAT_CYCLE为60s，负载的阈值为75％，如果超过这个值就会想对应的开发人员发送短信和IM消息预警。同时数据汇总模块还会向IM消息发送子系统的负载值，随着时间的流失就描绘出一条随时间的负载曲线，描述了系统的健康度。图4是本实施例的每日汇总邮件示意图，如图4所示，从负载排序中可以清楚的看出系统各子业务的运行健康状态(具体数据参看第二行数据，数据越小代表业务越健康)。同时还可以与以前数据相对比。另外从截图中还可以看出一个常见产品一般都含有几百甚至上千个子业务，这些子业务同时还处在不断迭代和调整中。如果每个业务都需要在开发中添加监控点，提供请求来源，请求参数等信息，就会占用较大的开发资源，这样就会拖慢开发的进度。但是本发明是在基类中添加了统计任务执行时长的方法，不需要任何额外的开发工作，同时也能够较好的检测系统的健康度状态，提供负载数据，还可以提供预警功能。

本发明实施例还提供了一种业务状态处理装置。该装置可以通过获取模块和汇总模块实现其功能。需要说明的是，本发明实施例的一种业务状态处理装置装置可以用于执行本发明实施例所提供的一种业务状态处理方法，本发明实施例的一种业务状态处理方法也可以通过本发明实施例所提供的一种业务状态处理装置来执行。

图6是根据本发明实施例的一种业务状态处理装置的示意图。如图6所示，一种业务状态处理装置包括：

获取单元62，用于在预定周期内，获取业务中的每个子业务对应的服务进程的运行状态；

汇总单元64，用于对每个子业务对应的服务进程的运行状态进行汇总得到第一汇总结果；

确认单元66，根据第一汇总结果确定业务的状态。

在一个可选的实施方式中，还包括：

告警单元，用于在业务的状态符合第一预定条件和/或子业务对应的服务进程的运行状态符合第二预定条件的情况下，进行告警。

在一个可选的实施方式中，获取单元包括：

统计模块，用于统计每个子业务对应的服务进程每次对接受到请求的处理时间；

累计模块，用于在预定周期内对处理时间进行累积得到累计结果；

第一获取模块，用于根据累积结果获取预定周期内的运行状态。

在一个可选的实施方式中，第一获取模块用于计算预定周期内的每个子业务对应的服务进程处理接收到请求的理论处理时间的上限，并将累积结果与理论处理时间的上限的比值作为健康值，其中，健康值用于标识运行状态。

在一个可选的实施方式中，汇总单元还用于：对预定时间段内的每个子业务对应的服务进程的每个预定周期的运行状态进行汇总，得到第二汇总结果；

确认单元还用于：根据第二汇总结果确定业务在预定时间段内的状态。

在一个可选的实施方式中，汇总单元还包括：

第二获取模块，用于获取预定时间段内每个子业务对应的服务进程的总运行状态；

排序模块，用于对每个子业务对应的服务进程的总运行状态进行排序。

在一个可选的实施方式中，汇总单元还包括：

告警模块，用于对总运行状态的排序结果进行警告。

在一个可选的实施方式中，告警模块或告警单元用于通过发送邮件、短信和/或即时消息进行告警。

上述一种业务状态处理装置装置实施例是与一种业务状态处理方法相对应的，所以对于有益效果不再赘述。通过上述实施例的分析描述，相对于传统的业务系统的健康度(每个子业务对应的服务进程运行状态)检测来说，上述实施例中的部分可选实施方式有以下技术上的效果：

1.开发简单高效，节省人力物力

与其他常见的监控系统不同的是，本发明没有在各个子系统中添加监控点，没有定制监控模块，没有定制分析模块。不需要区分请求来源等数据，大量减少了开发的工作量。在业务的基类中添加一个统计任务用时(可以指在预定周期内统计服务进程的运行状态)，基本上没有任何新增的工作量，同时数据又能准确的反应系统的运行健康度情况，节省了人力物力。

2.实时监控各子业务的运行负载情况

本发明设定了可配置的时间片，每相隔一段时间，例如一分钟，各个子业务系统就会上报一次业务的负载情况(每个子业务对应的服务进程运行状态)，然后通过汇总服务器转发到邮件或者IM通讯软件上，方便实时的查看运行数据，即进行告警。

3.按业务划分，便于进行优化处理和应对突发情况

本发明是根据各个子业务进行区分，汇总业务的负载情况(进程运行状态)。当负载超过了设定的阈值就会触发预警信息，通知相关开发人员。可以进行有针对性的优化。同时系统如果出现问题就会出现负载异常，同样可以设定负载的判断阈值和变化阈值，当这些值超过了设定的阈值(预定的条件)之后就会通过短信、IM消息、邮件等发送给责任人，能够在第一时间发现并解决问题。

本发明上述实施例中所提及的时间片长度、过滤数据的阈值、以及判断业务异常的预警阈值都是可以动态调整的，并不一定要包含实施例中所列示的各个性能参数。

上述实施例的监控参数仅为常用的监控服务器性能指标。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、移动终端、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (16)

1.一种业务状态处理方法，其特征在于，包括：

在预定周期内，获取业务中的每个子业务对应的服务进程的运行状态；

对所述每个子业务对应的服务进程的运行状态进行汇总得到第一汇总结果；

根据所述第一汇总结果确定所述业务的状态。

2.根据权利要求1所述的方法，其特征在于，获取业务中的每个子业务对应的服务进程的运行状态包括：

统计所述每个子业务对应的服务进程每次对接受到请求的处理时间；

在所述预定周期内对所述处理时间进行累积得到累计结果；

根据累积结果获取所述预定周期内的运行状态。

3.根据权利要求2所述的方法，其特征在于，根据所述累积结果获取预定时间内的运行状态包括：

计算所述预定周期内的所述每个子业务对应的服务进程处理接收到请求的理论处理时间的上限；

将所述累积结果与所述理论处理时间的上限的比值作为健康值，其中，所述健康值用于标识所述运行状态。

4.根据权利要求3中任意一项所述的方法，其特征在于，在确定所述业务状态之后，所述方法还包括：

在所述业务的状态符合第一预定条件和/或所述子业务对应的服务进程的运行状态符合第二预定条件的情况下，进行告警。

5.根据权利要求4所述的方法，其特征在于，在使用所述健康值标识每个子业务对应的服务进程的运行状态情况下，

所述每个子业务对应的健康值或者健康值的变化超出预定范围则满足所述第二预定条件；和/或，

所述业务的所有子业务的健康值汇总之后的值超过预定范围或者汇总之后的值的变化超过预定范围则满足所述第一预定条件。

6.根据权利要求1所述的方法，其特征在于，还包括：

对预定时间段内的所述每个子业务对应的服务进程的每个所述预定周期的运行状态进行汇总得到的第二汇总结果，其中，所述预定时间段大于所述预定周期；

根据所述第二汇总结果确定所述业务的状态。

7.根据权利要求6所述的方法，其特征在于，还包括：

获取所述预定时间段内所述每个子业务对应的服务进程的总运行状态；

对所述每个子业务对应的服务进程的总运行状态进行排序。

8.根据权利要求7所述的方法，其特征在于，还包括：

对所述总运行状态的排序结果进行告警。

9.根据权利要求1至8中任意一项所述的方法，其特征在于：所述预定周期为时间片。

10.一种业务状态处理装置，其特征在于，包括：

获取单元，用于在预定周期内，获取业务中的每个子业务对应的服务进程的运行状态；

汇总单元，用于对所述每个子业务对应的服务进程的运行状态进行汇总得到第一汇总结果；

确认单元，根据所述第一汇总结果确定所述业务的状态。

11.根据权利要求10所述的装置，其特征在于，还包括：

告警单元，用于在所述业务的状态符合第一预定条件和/或所述子业务对应的服务进程的运行状态符合第二预定条件的情况下，进行告警。

12.根据权利要求10所述的装置，其特征在于，所述获取单元包括：

统计模块，用于统计所述每个子业务对应的服务进程每次对接受到请求的处理时间；

累计模块，用于在所述预定周期内对所述处理时间进行累积得到累计结果；

第一获取模块，用于根据所述累积结果获取所述预定周期内的运行状态。

13.根据权利要求12所述的装置，其特征在于，所述第一获取模块用于计算所述预定周期内的所述每个子业务对应的服务进程处理接收到请求的理论处理时间的上限，并将所述累积结果与所述理论处理时间的上限的比值作为健康值，其中，所述健康值用于标识所述运行状态。

14.根据权利要求10所述的装置，其特征在于，所述汇总单元还用于对预定时间段内的所述每个子业务对应的服务进程的每个所述预定周期的运行状态进行汇总得到的第二汇总结果，其中，所述预定时间段大于所述预定周期；

所述确认单元还用于根据所述第二汇总结果确定所述业务的状态。

15.根据权利要求14所述的装置，其特征在于，所述汇总单元还包括：

第二获取模块，用于获取所述预定时间段内所述每个子业务对应的服务进程的总运行状态；

排序模块，用于对所述每个子业务对应的服务进程的总运行状态进行排序。

16.根据权利要求15所述的装置，其特征在于，所述汇总单元还包括：

告警模块，用于对所述总运行状态的排序结果进行警告。