CN109150643B - 一种业务处理异常检测方法及装置 - Google Patents

Abstract

本申请实施例公开了一种业务处理异常检测方法及装置。所述方法包括：获取目标业务场景的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据；根据所述用户请求数据，生成用户请求检测数据；发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据；若所述业务返回数据与所述业务返回检测数据不匹配，则确定所述目标业务场景的处理发生异常。利用本申请技术方案，可以及时处理异常状况，避免用户获取到异常服务。

Description

一种业务处理异常检测方法及装置

技术领域

本申请涉及数据处理技术领域，特别涉及一种业务处理异常检测方法及装置。

背景技术

目前，很多业务服务平台可以提供面对外部对象的业务接口，通过该业务接口，业务服务平台可以为所述外部对象实现业务代理等服务工作。典型的业务服务平台如阿里巴巴的支付宝平台，支付宝平台中可以接入多家商户，用户在商户进行支付时，可以利用支付宝客户端进行支付，这里支付宝平台为商户提供了代扣服务。基于外部对象与业务服务平台之间的合作关系，外部对象可以与所述业务服务平台进行协议，所述业务服务平台在对所述外部对象进行服务之后，需要传输预定参数的参数数据至所述外部对象处，以便外部对象进行必要的数据处理。

为了满足不同外部对象的业务需求，业务服务平台在后端处理逻辑上针对不同的业务对象会有不同的处理和适配。一个具体的做法包括：由于外部对象业务的多样性，在外部对象接入业务服务平台的过程中，业务服务平台为满足不同外部对象的业务需求，可以在面对外部对象的接口中设置针对各个外部对象个性化的预定参数。另外，业务服务平台也可能在内部流程中对某些特定的商户做特殊的适配处理，以满足外部对象的业务需求。

基于此，即使两个外部对象使用业务服务平台上的相同产品，但由于外部对象需求的差异性，因此从业务服务平台获取的参数数据也可能不相同。但是，随着业务的发展，业务服务平台服务的外部对象也与日俱增，业务服务平台技术改造和业务改造的节奏也随之加快。这样，很可能导致一个问题：由于业务服务平台的业务处理链路环节较多，链路上任何一个环节的改造，都可能对外部对象从某个接口接收到的参数数据产生影响，进而可能影响到外部对象正常业务的处理。

由于外部对象的数量巨大，因此不可能在每次业务服务平台改造之后，针对每个外部对象的接口进行检查。因此，现有技术中亟需一种能够发现业务服务平台与所服务外部对象之间业务回归中的异常状况的轻量级方式。

发明内容

本申请实施例的目的在于提供一种业务处理异常检测方法及装置，可以及时处理异常状况，避免用户获取到异常服务。

本申请实施例提供的一种业务处理异常检测方法及装置具体是这样实现的：

一种业务处理异常检测方法，所述方法包括：

获取目标业务场景的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据；

根据所述用户请求数据，生成用户请求检测数据；

发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据；

若所述业务返回数据与所述业务返回检测数据不匹配，则确定所述目标业务场景的处理发生异常。

一种业务处理异常检测装置，所述装置包括：

处理数据获取单元，用于获取目标业务场景的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据；

请求数据生成单元，用于根据所述用户请求数据，生成用户请求检测数据；

检测数据获取单元，用于发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据；

异常确定单元，用于若所述业务返回数据与所述业务返回检测数据不匹配，则确定所述目标业务场景的处理发生异常。

一种业务处理异常检测装置，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

获取目标业务场景的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据；

根据所述用户请求数据，生成用户请求检测数据；

发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据；

若所述业务返回数据与所述业务返回检测数据不匹配，则确定所述目标业务场景的处理发生异常。

本申请提供的业务处理异常检测方法及装置，可以根据真实的业务场景的处理数据，构建用户请求检测数据。再利用所述用户请求检测数据模拟真实的业务环境，向服务平台发送请求，并得到服务平台返回的业务返回检测数据。将真实的业务返回数据与模拟的业务返回检测数据进行对比，可以发现服务平台对目标业务场景的处理是否发生异常。通过这种方式不断地或者定期地对各个业务场景的异常状况进行巡检，可以及时发现服务平台面向外部对象的服务异常，甚至在外部对象获取异常服务之前，及时处理异常状况，避免用户获取到异常服务。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是外部对象利用服务平台进行代扣服务的流程示意图；

图2是本申请提供的业务处理异常检测方法的一种实施例的方法流程示意图；

图3是本申请提供的生成用户请求检测数据方法的一种实施例的方法流程图；

图4是本申请提供的获取检测数据方法的一种实施例的方法流程图；

图5是本申请提供的一个应用场景的流程图；

图6是本申请提供的业务处理异常检测装置的一种实施例的模块结构示意图；

图7是本申请提供的业务处理异常检测装置的另一种实施例的模块结构示意图。

具体实施方式

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

为了使本技术领域的人员更好地理解本申请中的技术方案，下面非限制性地通过互联网代扣服务的应用场景对本申请技术方案的应用场景环境进行说明。

近两年，在电子商务平台，几乎无时无刻不在发生着业务代扣服务。业务代扣服务是指各个商户将代扣业务转交给具有代扣资质的服务平台进行处理，典型的场景如各个线上、线下商户均可以利用支付宝、微信等服务平台进行代扣服务。图1是外部对象利用服务平台进行代扣服务的流程示意图。如图1所示，其中外部对象可以指需要服务平台提供代扣服务的用户，如超市、苹果商店、滴滴等商户。服务平台可以指能够提供代扣服务的平台，如支付宝、微信等平台。业务网关可以指服务平台提供给外部对象的开放平台，所述业务网关中可以包括多个业务接口，每个业务接口具有各自的业务逻辑，实现相应的业务功能。具体地，所述业务接口可以包括代扣接口、退款接口、查询接口等等。

基于此，个人用户A在苹果商店(App Store)的商品网页中购买某应用，由于苹果商店与支付宝平台之间签订代扣协议，因此，在用户A在购物页面中确认购买之后，苹果商店立即进行业务前置处理，生成面向支付宝平台的代扣请求，所述代扣请求中可以包括商品ID、用户ID、下单时间等信息。然后，苹果商店根据与支付宝平台之间的代扣协议，将所述代扣请求发送至支付宝平台业务网关中的代扣接口，所述代扣接口将所述代扣请求转发至支付宝平台。支付宝平台在接收到所述代扣请求之后，进行代扣业务逻辑处理，并生成代扣结果，再将所述代扣结果返回至代扣接口。所述代扣接口在接收到代扣结果之后，将所述代扣结果转发至苹果商店。苹果商店在接收到代扣结果之后，可以根据所述代扣结果进行业务处理，并将所述代扣结果和业务处理结果返回至个人用户客户端。

苹果商店与支付宝平台签订代扣协议时，可以约定需要支付宝平台在进行代扣处理之后返回的传输参数。所述传输参数中可以包括支付完成时间、资金渠道等信息。也就是，在上述流程中，支付宝平台在返回的代扣结果中需要包含所述传输参数的参数值。而外部对象根据业务需求很依赖其中的一个或者多个传输参数。例如，苹果商店比较依赖资金渠道，当用户使用与苹果商店合作的信用卡支付时，可以免费获得优惠券或者 限量应用的使用权等。若在支付宝升级过程中，代扣接口出现故障，不再将个人用户的资金渠道返回给苹果商店，那么苹果商店也无法知道用户是否使用合作信用卡支付，也就无法给应该享受优惠的用户发放优惠券。这样，很容易导致对苹果商店以及个人用户不好的体验，甚至影响互相之间的合作关系。

但是，支付宝平台不可能在每次平台有稍微变动时，都根据与商户之间的日志数据分析并检查与所有商户之间的数据传输是否正常。因为接入支付宝平台的商户有成千上万个，且每日生成的日志数据也是不计其数，由于时间成本、计算成本等因素，这种方式的检查工作难以实现。

基于类似于上文描述的实际技术需求，本申请提供的技术方案可以利用已有的业务处理数据，针对各个业务场景进行模拟检测，并将模拟检测结果与实际结果进行对比，若两者不相同，则确定针对该业务场景的处理发生异常。

下面结合附图对本申请所述的业务处理异常检测方法进行详细的说明。图2是本申请提供的业务处理异常检测方法的一种实施例的方法流程示意图。虽然本申请提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑性上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。所述方法在实际中的业务处理异常检测过程中，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

具体的本申请提供的一种业务处理异常检测方法的一种实施例如图2所示，所述方法可以包括：

S201：获取目标业务场景的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据。

本实施例中，所述目标业务场景可以包括服务平台提供的产品项目中的场景等，所述产品项目例如支付宝平台提供的代扣服务、城市服务、共享单车等等，而每个产品项目中还可以包括多个场景，例如代扣服务中可以包括代扣、退款、查询等多个业务场景。所述处理数据可以包括所述目标业务场景中已经处理完成的数据，且所述处理数据中可以包括用户请求数据以及对应的业务返回数据。其中，所述用户请求数据例如上述应用场景中苹果商店生成的代扣请求，所述业务返回数据例如上述场景中支付宝平台生成的代扣结果。本实施例中，所述处理数据可以存储于所述服务平台的后台数据库中，所述后台数据库可以从所述服务平台的业务网关中获取所述处理数据，并存储所述处理数据。在一个实施例中，所述后台数据库可以从所述业务网关实时同步所述处理数据。

在本申请的一个实施例中，所述处理数据可以包括已经处理成功的处理数据，具体地，所述获取目标业务场景的处理数据可以包括：

SS1：获取目标业务场景中的多个处理数据；

SS3：从所述多个处理数据中筛选出处理成功的处理数据。

本实施例中，可以从所述目标业务场景中的多个处理数据中筛选出处理成功的处理数据。所述处理成功的处理数据包括所述服务平台按照与外部对象的协议，向外部对象返回包含外部对象所要求的数据。例如，在上述场景中，所述处理成功的处理数据即为支付宝平台返回的代扣结果中包含苹果商店所 要求的所有传输参数，例如资金渠道、支付时间等等。在本申请的一个实施例中，所述处理成功的处理数据中可以包括相应的标识，通过所述标识可以识别出所述处理成功的处理数据。

在本申请的一个实施例中，在所述从所述多个处理数据中筛选出处理成功的数据之后，所述方法还可以包括：

按照预设规则从筛选之后的处理数据中去除重复的处理数据。

本实施例中，可以从上述筛选之后的处理数据中去除重复的处理数据。例如在上述应用场景中，在获取的成功的处理数据中，有针对张三的处理数据、李四的处理数据，两者都是购买苹果商店中的产品，并利用支付宝平台进行支付。那么，这两个处理数据具有大部分重复的地方，因此，可以只保留其中的一个处理数据作为后续的参考数据。

本实施例中，对处理数据进行去重之后，可以降低后续进行数据检测的工作量，提高发现业务处理异常的检测效率。

在本申请的一个实施例中，还可以分别获取所述目标业务场景中各个业务接口的处理数据。具体地，所述获取目标业务场景的处理数据可以包括：

SS_1：确定目标业务场景中所调用的多个业务接口；

SS_3：分别获取各个业务接口的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据。

本实施例中，所述目标业务场景中可以调用多个业务接口，例如代扣服务中可以包括多个业务场景，对应地，代扣服务可以调用代扣接口、退款接口、查询接口等多种接口。其中，各个业务接口可以接收用户请求数据和返回对应的业务返回请求。本实施例中，可以从所述目标业务场景中确定出所需要调用的一个或者多个业务接口，并分别获取各个业务接口的处理数据。

S203：根据所述用户请求数据，生成用户请求检测数据。

本实施例中，可以根据所述用户请求数据，生成用户请求检测参数。如图3所示，在本申请的一个实施例中，所述根据所述用户请求数据，生成用户请求检测数据可以包括：

S301：提取所述用户请求数据中的多个请求参数；

S303：按照业务规则确定所述多个请求参数中需要重置的请求参数；

S305：设置所述用户请求数据中所述需要重置的请求参数的参数值，生成用户请求检测数据。

本实施例中，外部对象可以向服务平台发送用户请求数据(如代扣请求)，所述用户请求数据中可以包括多个请求参数，例如，所述请求参数包括但不限于商户ID、用户ID、交易号、协议号、外部订单号、通知地址等参数。本实施例中，可以利用所述请求参数，模拟用户请求，向服务平台发送用户检测请求。由于上述用户请求数据可以源于真实的业务数据，因此，其中的各个请求参数的参数值均是真实的数据。若直接利用所述用户请求数据进行检测，则会发生业务重复执行的状况，例如，在代扣服务中，如果直接使用用户请求数据请求代扣，则会发生从用户账户中重复扣款的状况。因此，需要对所述请求参数中的部分参数进行重置，避免发生业务重复执行的情况发生。例如请求参数包括商户ID、用户ID、交易号、协议号、外部订单号、通知地址等参数时，需要可以对用户ID、交易号、协议号、外部订单号、通知地址等参数进行重置。本实施例中，还可以预先设置需要重置的请求参数，并设置需要重置的请求参数，生成用户请求检测数据。例如，在支付宝平台，可以设置专门用于检测使用的用户ID、交易号、协议号、外部订单号、通知地址等参数的参数值，生成用户请求检测数据。

具体地，在本申请的一个实施例中，所述根据所述用户请求数据，生成用户请求检测数据可以包括：

根据各个业务接口的用户请求数据，分别生成所述业务接口的用户请求检测数据。

由上述可知，产品项目中可以产生多个业务场景，各个业务场景中可以调用一个或者多个业务接口。因此，本实施例中，可以根据 各个业务接口的用户请求数据，分别生成所述业务接口的用户请求检测数据。

S205：发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据。

本实施例中，可以将所述用户请求检测数据发送至服务平台，并接收服务平台返回的与所述用户请求检测数据对应的业务返回检测数据。对真实的用户请求数据进行参数替换，生成用户请求检测数据，并向服务平台发送所述用户请求检测数据，可以模拟真实的业务环境，并获取当前服务平台的处理状态。

如图4所示，在本申请的一个实施例中，所述发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据可以包括：

S401：根据所述多个业务接口之间的依赖关系，确定所述多个业务接口的先后调用顺序；

S403：按照所述先后调用顺序依次向所述多个业务接口发送所述业务接口所对应的用户请求检测数据；

S405：接收所述业务接口针对所述用户请求检测数据返回的业务返回检测数据。

本实施例中，在所述目标业务场景中，所调用的多个业务接口之间具有依赖关系，即 一个业务接口的处理需要依赖另一个业务接口的处理。举例来说，在代扣服务中，退款的业务场景是基于代扣的业务场景，即不能在没有代扣在前的业务直接进行退款业务，也就是说，对退款业务接口的调用是基于代扣业务接口的。本实施例中，可以根据所述多个业务接口之间的依赖关系，确定所述多个业务接口的先后调用顺序。然后，按照所述先后调用顺序依次向所述多个业务接口发送所述业务接口所对应的用户请求检测数据。最后，再接收所述业务接口针对所述用户请求检测数据返回的业务返回检测数据。

S207：若所述业务返回数据与所述业务返回检测数据不匹配，则确定所述目标业务场景的处理发生异常。

本实施例中，可以对所述业务返回数据与所述业务返回检测数据进行对比，若发现两者不匹配，则确定所述目标业务场景的处理发生异常。本实施例中，由于所述业务返回数据基于真实的且处理成功的业务数据，若在进行模拟请求之后，返回的业务返回检测数据与所述业务返回数据不匹配，则表明服务平台针对目标业务场景的处理发生异常。具体地，在一个实施例中，可以通过正则表达式对比所述业务返回数据与所述业务返回检测数据。

当所述目标业务场景具有多个业务接口时，所述若所述业务返回数据与所述业务返回检测数据不匹配，则确定所述目标业务场景的处理发生异常可以包括：

SSS1：分别对比各个业务接口的业务返回数据和业务返回检测数据；

SSS3：若所述业务返回数据和所述业务返回检测数据不匹配，则确定对应的业务接口发生处理异常。

本实施例中，当所述目标业务场景包括多个业务接口时，可以分别对比各个业务接口的业务返回数据和业务返回 检测数据。当所述业务返回数据和所述业务返回检测数据不匹配，则确定对应的业务接口发生处理异常。这样，可以将目标业务场景的异常处理定位到具体的业务接口。

下面结合图5继续通过上述苹果商店与支付宝平台的业务场景说明本申请实施例方法。

如图5所示，根据本申请实施例方法，支付宝平台可以创建一个专门用于检测业务处理异常状况的平台，以及时发现支付宝平台向用户返回数据的异常状况。在支付宝平台，可以设置相应的数据库，用于从业务网关同步业务处理日志，所述业务处理日志可以包括外部对象调用各个业务接口所产生的处理数据，所述处理数据可以包括用户请求数据和业务返回数据。此后，所述数据库可以对所述处理数据进行筛选、去重，筛选出处理成功的处理数据，去除重复的处理数据。所述数据库还可以根据业务场景中各个业务接口的依赖关系设置所述业务接口的调用顺序。需要说明的是，上述对处理数据进行筛选、去重、接口调用顺序设置的处理还可以由所述巡检平台执行，本申请在此不做限制。

所述巡检平台在获取所述数据库处理之后的处理数据之后，可以对所述处理数据中用户请求数据中的部分参数进行重置，生成用户请求检测数据。在生成所述用户请求检测数据之后，可以依次调用业务接口，将与业务接口对应的用户请求检测数据发送至所述业务接口。所述业务接口接收到用户请求检测数据之后，可以将所述用户请求检测数据转发至服务平台。服务平台在接收到所述用户请求检测数据之后，可以进行业务逻辑处理，生成并返回业务返回检测数据。业务接口在接收到所述业务返回检测数据之后，可以将所述业务返回检测数据转发至所述巡检平台。所述巡检平台在获取所述业务返回检测数据之后，可以对比所述业务返回数据和所述业务返回检测数据，并生成巡检报告。

回到一开始的应用场景，数据库可以获取到苹果商店的代扣场景中处理成功的处理数据，所述处理数据中可以包括用户请求数据和业务返回数据。其中，所述用户请求数据中可以包括商户ID、用户ID、交易号、协议号、外部订单号、通知地址等请求参数。在进行检测时，所述巡检平台可以对部分需要重置的请求参数进行重置，生成用户请求检测数据，例如可以对用户ID、交易号、协议号、外部订单号、通知地址等参数进行重置。将所述用户请求检测数据发送至支付宝平台，支付宝平台在进行处理之后，可以返回支付时间、支付地点、资金渠道等多种信息。若在一次检测过程中，巡检平台在对业务返回数据和业务检测返回数据进行对比时，发现业务检测返回数据中缺少资金渠道的参数值，则可以确定代扣业务接口发生异常。后续地，可以生成检测报告，用于对代扣业务接口的异常情况进行处理。

本申请提供的业务处理异常检测方法，可以根据真实的业务场景的处理数据，构建用户请求检测数据。再利用所述用户请求检测数据模拟真实的业务环境，向服务平台发送请求，并得到服务平台返回的业务返回检测数据。将真实的业务返回数据与模拟的业务返回检测数据进行对比，可以发现服务平台对目标业务场景的处理是否发生异常。通过这种方式不断地或者定期地对各个业务场景的异常状况进行巡检，可以及时发现服务平台面向外部对象的服务异常，甚至在外部对象获取异常服务之前，及时处理异常状况，避免用户获取到异常服务。

本申请另一方面还提供一种业务处理异常检测装置，图6是本申请提供的业务处理异常检测装置的一种实施例的模块结构示意图，如图6所示，所述装置60可以包括：

处理数据获取单元61，用于获取目标业务场景的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据；

请求数据生成单元63，用于根据所述用户请求数据，生成用户请求检测数据；

检测数据获取单元65，用于发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据；

异常确定单元67，用于若所述业务返回数据与所述业务返回检测数据不匹配，则确定所述目标业务场景的处理发生异常。

可选的，在本申请的一个实施例中，所述处理数据获取单元可以包括：

第一处理数据获取子单元，用于获取目标业务场景中的多个处理数据；

数据筛选单元，用于从所述多个处理数据中筛选出处理成功的处理数据。

可选的，在本申请的一个实施例中，所述处理数据获取单元还可以包括：

数据去重单元，用于按照预设规则从筛选之后的处理数据中去除重复的处理数据。

可选的，在本申请的一个实施例中，所述处理数据获取单元可以包括：

业务接口确定单元，用于确定目标业务场景中所调用的多个业务接口；

第二处理数据获取子单元，用于分别获取各个业务接口的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据。

可选的，在本申请的一个实施例中，所述根据所述用户请求数据，生成用户请求检测数据可以包括：

根据各个业务接口的用户请求数据，分别生成所述业务接口的用户请求检测数据。

可选的，在本申请的一个实施例中，所述检测数据获取单元可以包括：

顺序确定单元，用于根据所述多个业务接口之间的依赖关系，确定所述多个业务接口的先后调用顺序；

请求数据发送单元，用于按照所述先后调用顺序依次向所述多个业务接口发送所述业务接口所对应的用户请求检测数据；

检测数据接收单元，用于接收所述业务接口针对所述用户请求检测数据返回的业务返回检测数据。

可选的，在本申请的一个实施例中，所述异常确定单元可以包括：

检测数据对比单元，用于分别对比各个业务接口的业务返回数据和业务返回检测数据；

异常确定子单元，用于若所述业务返回数据和所述业务返回检测数据不匹配，则确定对应的业务接口发生处理异常。

可选的，在本申请的一个实施例中，所述请求数据生成单元可以包括：

请求参数提取单元，用于提取所述用户请求数据中的多个请求参数；

重置参数获取单元，用于按照业务规则确定所述多个请求参数中需要重置的请求参数；

参数设置单元，用于设置所述用户请求数据中所述需要重置的请求参数的参数值，生成用户请求检测数据。

本申请另一方面还提供一种业务处理异常检测装置，图7是本申请提供的业务处理异常检测装置的一种实施例的模块结构示意图，如图7所示，所述装置70可以包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时可以实现：

获取目标业务场景的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据；

根据所述用户请求数据，生成用户请求检测数据；

发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据；

若所述业务返回数据与所述业务返回检测数据不匹配，则确定所述目标业务场景的处理发生异常。

可选的，在本申请的一个实施例中，所述处理器在实现步骤获取目标业务场景的处理数据时可以包括：

确定目标业务场景中所调用的多个业务接口；

分别获取各个业务接口的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据。

可选的，在本申请的一个实施例中，所述处理器在实现步骤根据所述用户请求数据，生成用户请求检测数据时可以包括：

根据各个业务接口的用户请求数据，分别生成所述业务接口的用户请求检测数据。

可选的，在本申请的一个实施例中，所述处理器在实现步骤发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据时可以包括：

根据所述多个业务接口之间的依赖关系，确定所述多个业务接口的先后调用顺序；

按照所述先后调用顺序依次向所述多个业务接口发送所述业务接口所对应的用户请求检测数据；

接收所述业务接口针对所述用户请求检测数据返回的业务返回检测数据。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、 CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language) 等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上客户端或服务器时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和 /或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和 /或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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

Claims (20)

1.一种业务处理异常检测方法，所述方法包括：在服务平台为外部对象提供业务服务的过程中，定期通过以下方法对各个业务场景的异常状况进行巡检，以用于在外部对象获取异常服务之前发现服务平台面向外部对象的服务异常：

获取目标业务场景的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据；

根据所述用户请求数据，生成用户请求检测数据；

发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据；

若所述业务返回数据与所述业务返回检测数据不匹配，则确定所述目标业务场景的处理发生异常。

2.根据权利要求1所述的方法，所述获取目标业务场景的处理数据包括：

获取目标业务场景中的多个处理数据；

从所述多个处理数据中筛选出处理成功的处理数据。

3.根据权利要求2所述的方法，在所述从所述多个处理数据中筛选出处理成功的数据之后，所述方法还包括：

按照预设规则从筛选之后的处理数据中去除重复的处理数据。

4.根据权利要求1所述的方法，所述获取目标业务场景的处理数据包括：

确定目标业务场景中所调用的多个业务接口；

分别获取各个业务接口的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据。

5.根据权利要求4所述的方法，所述根据所述用户请求数据，生成用户请求检测数据包括：

根据各个业务接口的用户请求数据，分别生成所述业务接口的用户请求检测数据。

6.根据权利要求5所述的方法，所述发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据包括：

根据所述多个业务接口之间的依赖关系，确定所述多个业务接口的先后调用顺序；

按照所述先后调用顺序依次向所述多个业务接口发送所述业务接口所对应的用户请求检测数据；

接收所述业务接口针对所述用户请求检测数据返回的业务返回检测数据。

7.根据权利要求6所述的方法，所述若所述业务返回数据与所述业务返回检测数据不匹配，则确定所述目标业务场景的处理发生异常包括：

分别对比各个业务接口的业务返回数据和业务返回检测数据；

若所述业务返回数据和所述业务返回检测数据不匹配，则确定对应的业务接口发生处理异常。

8.根据权利要求1-7中任意一项所述的方法，所述根据所述用户请求数据，生成用户请求检测数据包括：

提取所述用户请求数据中的多个请求参数；

按照业务规则确定所述多个请求参数中需要重置的请求参数；

设置所述用户请求数据中所述需要重置的请求参数的参数值，生成用户请求检测数据。

9.一种业务处理异常检测装置，所述装置包括：

处理数据获取单元，用于获取目标业务场景的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据；

请求数据生成单元，用于根据所述用户请求数据，生成用户请求检测数据；

检测数据获取单元，用于发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据；

异常确定单元，用于若所述业务返回数据与所述业务返回检测数据不匹配，则确定所述目标业务场景的处理发生异常；

所述处理数据获取单元、所述请求数据生成单元、所述检测数据获取单元、所述异常确定单元在服务平台为外部对象提供业务服务的过程中，定期对各个业务场景的异常状况进行巡检，以用于在外部对象获取异常服务之前发现服务平台面向外部对象的服务异常。

10.根据权利要求9所述的装置，所述处理数据获取单元包括：

第一处理数据获取子单元，用于获取目标业务场景中的多个处理数据；

数据筛选单元，用于从所述多个处理数据中筛选出处理成功的处理数据。

11.根据权利要求10所述的装置，所述处理数据获取单元还包括：

数据去重单元，用于按照预设规则从筛选之后的处理数据中去除重复的处理数据。

12.根据权利要求9所述的装置，所述处理数据获取单元包括：

业务接口确定单元，用于确定目标业务场景中所调用的多个业务接口；

第二处理数据获取子单元，用于分别获取各个业务接口的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据。

13.根据权利要求12所述的装置，所述根据所述用户请求数据，生成用户请求检测数据包括：

根据各个业务接口的用户请求数据，分别生成所述业务接口的用户请求检测数据。

14.根据权利要求13所述的装置，所述检测数据获取单元包括：

顺序确定单元，用于根据所述多个业务接口之间的依赖关系，确定所述多个业务接口的先后调用顺序；

请求数据发送单元，用于按照所述先后调用顺序依次向所述多个业务接口发送所述业务接口所对应的用户请求检测数据；

检测数据接收单元，用于接收所述业务接口针对所述用户请求检测数据返回的业务返回检测数据。

15.根据权利要求14所述的装置，所述异常确定单元包括：

检测数据对比单元，用于分别对比各个业务接口的业务返回数据和业务返回检测数据；

异常确定子单元，用于若所述业务返回数据和所述业务返回检测数据不匹配，则确定对应的业务接口发生处理异常。

16.根据权利要求9-15中任意一项所述的装置，所述请求数据生成单元包括：

请求参数提取单元，用于提取所述用户请求数据中的多个请求参数；

重置参数获取单元，用于按照业务规则确定所述多个请求参数中需要重置的请求参数；

参数设置单元，用于设置所述用户请求数据中所述需要重置的请求参数的参数值，生成用户请求检测数据。

17.一种业务处理异常检测装置，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：在服务平台为外部对象提供业务服务的过程中，定期通过以下方法对各个业务场景的异常状况进行巡检，以用于在外部对象获取异常服务之前发现服务平台面向外部对象的服务异常：

获取目标业务场景的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据；

根据所述用户请求数据，生成用户请求检测数据；

发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据；

若所述业务返回数据与所述业务返回检测数据不匹配，则确定所述目标业务场景的处理发生异常。

18.根据权利要求17所述的装置，所述处理器在实现步骤获取目标业务场景的处理数据时包括：

确定目标业务场景中所调用的多个业务接口；

分别获取各个业务接口的处理数据，所述处理数据中包括用户请求数据以及对应的业务返回数据。

19.根据权利要求18所述的装置，所述处理器在实现步骤根据所述用户请求数据，生成用户请求检测数据时包括：

根据各个业务接口的用户请求数据，分别生成所述业务接口的用户请求检测数据。

20.根据权利要求19所述的装置，所述处理器在实现步骤发送所述用户请求检测数据，并接收与所述用户请求检测数据对应的业务返回检测数据时包括：

根据所述多个业务接口之间的依赖关系，确定所述多个业务接口的先后调用顺序；

按照所述先后调用顺序依次向所述多个业务接口发送所述业务接口所对应的用户请求检测数据；

接收所述业务接口针对所述用户请求检测数据返回的业务返回检测数据。

Images