业务的异常恢复检测方法及装置与流程

本申请涉及通信领域，尤其涉及一种业务的异常恢复检测方法及装置。
背景技术：
：在第三方的在线支付业务中，当支付机构(例如银行等合作机构)与第三方支付平台对接的系统发生宕机、升级服务或者程序出现bug等业务异常时，将会导致用户的交易请求发往支付机构后不被处理或者被处理失败，从而造成线上支付异常。在这种情况下，当支付机构出现业务异常时，用户的交易请求通常会被阻止发往支付机构，并在确认支付机构的业务异常恢复后，再将所述用户的交易请求放行到支付机构。然而，目前在确认支付机构的业务异常是否恢复时，由于支付机构的系统通常不对外公开，因此整个确认流程通常是在线下由人工来确认完成，而通过人工来确认存在风险，可能存在确认失误的情况发生，一旦人工确认失误，在将大量的交易请求放行到支付机构后，将会造成大面积的交易异常，对用户的交易造成影响。技术实现要素：有鉴于此，本申请提出一种业务的异常恢复检测方法，应用于服务端，该方法包括：当第三方业务发生异常时，基于预设的筛选策略从用户发起的业务请求中筛选预设数量的测试请求；将筛选出的所述测试请求发送至所述第三方业务的服务端；基于所述第三方业务的服务端在收到所述测试请求后返回的业务处理结果针对所述第三方业务的服务端进行异常恢复检测。可选的，所述基于预设的筛选策略从用户发起的业务请求中筛选预设数量的测试请求之前，还包括：获取所述第三方业务的业务特征参数；基于获取到的所述业务特征参数设定对应的筛选策略。可选的，所述将筛选出的所述测试请求发送至所述第三方业务的服务端包括：将筛选出的所述测试请求按照预设的发送周期发送至所述第三方业务的服务端。可选的，所述基于所述第三方业务的服务端在收到所述测试请求后返回的业务处理结果针对所述第三方业务的服务端进行异常恢复检测包括：判断是否收到所述第三方业务的服务端返回的所述业务处理结果；当在预设时长内未收到所述第三方业务的服务端返回的所述业务处理结果时，确定所述第三方业务的服务端未从业务异常中恢复；当在预设时长内收到所述第三方业务的服务端返回的所述业务处理结果时，基于所述业务处理结果判断所述第三方业务的服务端是否成功处理所述测试请求；当基于所述业务处理结果判断出所述第三方业务的服务端成功处理所述测试请求时，确定所述第三方业务的服务端已从业务异常中恢复；当基于所述业务处理结果判断出所述第三方业务的服务端未成功处理所述测试请求时，确定所述第三方业务的服务端未从业务异常中恢复。可选的，所述第三方业务包括第三方的线上支付业务；所述业务特征参数包括所述线上支付业务的交易金额、交易地区、交易商品类型、支付工具类型、交易受理机构类型以及交易时效中的一个或者多个的组合。本申请还提出一种业务的异常恢复检测装置，应用于服务端，该装置包 括：筛选模块，用于在第三方业务发生异常时，基于预设的筛选策略从用户发起的业务请求中筛选预设数量的测试请求；发送模块，用于将筛选出的所述测试请求发送至所述第三方业务的服务端；检测模块，用于基于所述第三方业务的服务端在收到所述测试请求后返回的业务处理结果针对所述第三方业务的服务端进行异常恢复检测。可选的，所述装置还包括：获取模块，用于在所述筛选模块基于预设的筛选策略从用户发起的业务请求中筛选预设数量的测试请求之前，获取所述第三方业务的业务特征参数；设定模块，用于基于获取到的所述业务特征参数设定对应的筛选策略。可选的，所述发送模块具体用于：将筛选出的所述测试请求按照预设的发送周期发送至所述第三方业务的服务端。可选的，所述检测模块具体用于：判断是否收到所述第三方业务的服务端返回的所述业务处理结果；当在预设时长内未收到所述第三方业务的服务端返回的所述业务处理结果时，确定所述第三方业务的服务端未从业务异常中恢复；当在预设时长内收到所述第三方业务的服务端返回的所述业务处理结果时，基于所述业务处理结果判断所述第三方业务的服务端是否成功处理所述测试请求；当基于所述业务处理结果判断出所述第三方业务的服务端成功处理所述测试请求时，确定所述第三方业务的服务端已从业务异常中恢复；当基于所述业务处理结果判断出所述第三方业务的服务端未成功处理所述测试请求时，确定所述第三方业务的服务端未从业务异常中恢复。可选的，所述第三方业务包括第三方的线上支付业务；所述业务特征参数包括所述线上支付业务的交易金额、交易地区、交易商品类型、支付工具 类型、交易受理机构类型以及交易时效中的一个或者多个的组合。本申请通过在第三方业务发生异常时，基于预设的筛选策略从用户发起的业务请求中筛选预设数量的测试请求，并将筛选出的所述测试请求发送至所述第三方业务的服务端；然后基于所述第三方业务的服务端在收到所述测试请求后返回的业务处理结果针对所述第三方业务的服务端进行异常恢复检测，实现了利用真实的交易来自动的检测第三方业务的服务端的异常恢复情况。当本申请的技术方案应用于第三方的线上支付业务时，可以实现利用真实的线上交易请求，来检测第三方业务的服务端的异常恢复情况，而且无需引入额外的检测系统。附图说明图1是本申请一实施例示出的一种业务的异常恢复检测方法的流程图；图2是本申请一实施例示出的一种第三方的线上支付业务在交易正常情况下的业务流程图；图3是本申请一实施例示出的一种第三方的线上支付业务在交易异常情况下的业务流程图；图4是本申请一实施例示出的另一种业务的异常恢复检测方法的流程图；图5是本申请一实施例示出的另一种第三方的线上支付业务在交易异常情况下的业务流程图；图6是本申请一实施例示出的一种业务的异常恢复检测装置的逻辑框图；图7是本申请一实施例示出的承载所述业务的异常恢复检测装置的服务器的硬件结构图。具体实施方式本申请通过在第三方业务发生异常时，基于预设的筛选策略从用户发起的业务请求中筛选预设数量的测试请求，并将筛选出的所述测试请求发送至 所述第三方业务的服务端；然后基于所述第三方业务的服务端在收到所述测试请求后返回的业务处理结果针对所述第三方业务的服务端进行异常恢复检测，实现了利用真实的交易来自动的检测第三方业务的服务端的异常恢复情况。当本申请的技术方案应用于第三方的线上支付业务时，可以实现利用真实的线上交易请求，来检测第三方业务的服务端的异常恢复情况，而且无需引入额外的检测系统。下面通过具体实施例并结合具体的应用场景对本申请进行描述。请参考图1，图1是本申请一实施例提供的一种业务的异常恢复检测方案，该方法的执行主体可以为服务端，其中所述服务端在物理上可以是服务器、服务器集群或者云平台；该方法执行以下步骤：步骤101、当第三方业务发生异常时，基于预设的筛选策略从用户发起的业务请求中筛选预设数量的测试请求；步骤102、将筛选出的所述测试请求发送至所述第三方业务的服务端；步骤103、基于所述第三方业务的服务端在收到所述测试请求后返回的业务处理结果针对所述第三方业务的服务端进行异常恢复检测。在第三方业务中，本地服务端在收到用户通过业务客户端发送的业务请求时，通常可以通过对该业务请求的内容进行分析，为该用户筛选正确可用的第三方合作机构，然后将该业务请求转发到第三方合作机构对应的服务端进行业务处理；例如，以第三方业务为第三方的在线支付业务为例，业务客户端可以是支付客户端(例如支付宝)，本地服务端在收到用户通过支付客户端发起的业务请求时，可以通过识别该业务请求中携带的第三方银行或者合作机构的业务标识或接口，来为该业务请求筛选正确可用的第三方银行或者合作机构，然后将该业务请求转发到筛选出的第三方银行或者合作机构。当第三方合作机构的服务端在收到业务请求进行业务处理的过程中，如果系统发生宕机、升级服务或者程序出现bug等业务异常时，此时该业务请求可能无法得到正确的处理，在这种情况下，第三方合作机构的服务端可以 向本地服务端返回一个处理失败的反馈消息或者不针对所述业务请求向我方服务端进行反馈。当本地服务端收到所述第三方合作机构的服务端返回的处理失败的反馈消息或者未收到针对所述业务请求的反馈时，此时可以确定第三方业务发生异常，在这种情况下，本地服务端可以向发送该业务请求的用户侧的业务客户端发送一个业务异常的通告消息，以阻止用户通过业务客户端继续发起业务，通过业务客户端向本地服务端发送业务请求。在本实施例中，当本地服务端确定第三方业务发生异常时，除了可以阻止用户通过业务客户端向本地服务端发送业务请求以外，还可以基于预设的筛选策略从用户发起的业务请求中筛选预设数量的测试请求，然后将筛选出的测试请求发送至所述第三方合作机构的服务端。而且，由于测试请求是从真实的业务请求中筛选出来的，因此当本地服务端将测试请求发送至第三方合作机构的服务端后，可以通过监控所述第三方合作机构的服务端在收到该测试请求后返回的处理结果，来对所述第三方合作机构的服务端进行异常恢复检测，实时的获取所述第三方合作机构的服务端异常恢复情况。其中，所述预设数量的具体数值在本实施例中不进行特别限定，本领域技术人员可以根据实际的业务需求进行设定。在本实施例中，所述筛选策略可以基于发生异常的第三方业务的业务特征参数进行设定，该第三方业务的业务特征参数可以通过从第三方业务对应的业务请求中获取得到，通常可以包括业务发起方所在区域、业务类型、业务发起方的信息、业务详情信息等参数。同时，为了尽量降低测试请求对用户造成的影响，在设定所述筛选策略时，可以对所述筛选策略进行严格的控制，只将测试请求针对的用户人群限定在一个特定的用户群中，从而在发出测试请求后，即使第三方合作机构的服务端的业务异常尚未恢复，由于已经提前将测试请求针对的用户人群限定在一个特定的用户群中，因此不会对大范围的用户业务造成影响。其中，在根据第三方业务的业务特征参数设定筛选策略时，可以由系统管理员参照业务特征参数进行人工设定，也可以由本地服务端基于获取到的 业务特征参数自动进行设定。例如，当本地服务端将用户从业务客户端发出的业务请求转发到对应的第三方合作机构的服务端后，该第三方合作机构的服务端业务发生异常，此时本地服务端可以从该业务请求中获取业务发起方所在区域、业务类型、业务发起方的信息、业务详情信息等业务特征参数，在获取完成后，可以由系统管理员人工或者由本地服务端自动从以上各参数中选取一种或者多种参数的组合进行筛选策略的设定，将所述测试请求针对的用户人群限定在一个特定的用户群中。在本实施例中，当本地服务端基于设定的筛选策略，从用户发起的业务请求中筛选出预设数量的测试请求后，可以将筛选出的测试请求发送至所述第三方合作机构的服务端，然后通过监控第三方合作机构的服务端在收到所述测试请求后返回的处理结果，来实时获取第三方合作机构的服务端的异常恢复情况。值得说明的是，本地服务端在向所述第三方合作机构的服务端发送测试请求时，为了避免大量放行业务请求后对用户的业务造成影响，同时由于本地服务端在获取所述第三方合作机构的服务端的异常恢复情况时，是通过监控所述第三方合作机构的服务端在收到所述测试请求后返回的处理结果来实现的，而所述第三方合作机构的服务端在收到所述测试请求进行业务处理时，通常需要一个响应的时间，因此我方服务端在基于设定的筛选策略成功筛选出预设数量的测试请求后，可以按照预设的发送周期向所述第三方合作机构的服务端周期性的发送测试请求。在本实施例中，当第三方合作机构的服务端在收到本地服务端发送的测试请求后，可以根据接收到的测试请求进行业务处理。此时，如果所述第三方合作机构的服务端未从业务异常中恢复过来，由于目前仍然无法正确处理该测试请求，因此第三方合作机构的服务端可以向本地服务端返回一个处理失败的反馈消息或者不针对所述测试请求向本地服务端进行反馈。同样的道理，如果所述第三方合作的服务端已经从业务异常中恢复过来，此时可以正 确处理该测试请求，因此所述第三方合作机构的服务端可以向本地服务端正常的返回处理结果。当本地服务端在预设的时长内未收到所述处理结果，此时可以确定所述第三方合作机构的服务端未从业务异常中恢复过来。当本地服务端在预设的时长内收到所述处理结果，此时本地服务端可以通过接收到的所述处理结果来判断所述第三方合作机构的服务端是否已经成功处理了所述测试请求。例如，所述处理结果中通常可以携带处理成功或者处理失败的返回码，本地服务端可以检查所述处理结果中携带的返回码来确定第三方合作机构的服务端是否成功处理了所述测试请求。如果本地服务端通过所述处理结果判断出所述第三方合作机构的服务端是否已经成功处理了所述测试请求，则可以确定所述第三方合作机构的服务端已从业务异常中恢复；相反的，如果本地服务端通过所述处理结果判断出所述第三方合作机构的服务端未成功处理了所述测试请求，则可以确定所述第三方合作机构的服务端尚未从业务异常中恢复过来。在以上实施例中，通过在第三方业务发生异常时，基于预设的筛选策略从用户发起的业务请求中筛选预设数量的测试请求，并将筛选出的所述测试请求发送至所述第三方合作机构的服务端；然后基于所述第三方合作机构的服务端在收到所述测试请求后返回的业务处理结果针对所述第三方合作机构的服务端进行异常恢复检测，实现了利用真实的交易来自动的检测第三方合作机构的服务端的异常恢复情况。在实际应用中，上述实施例的技术方案可以应用到第三方的线上支付业务中。当应用到第三方的线上支付业务中时，所述第三方业务可以是第三方的线上支付业务；所述用户的业务客户端可以是支付客户端，例如支付宝；本地服务端可以是面向所述支付客户端提供服务的服务器、服务器集群或者云平台。所述第三方合作机构的服务端可以是与所述支付客户端合作的银行或者其它第三方的合作机构面向用户提供服务的服务器、服务器集群或者云平台。以下以所述支付客户端为支付宝，所述第三方合作机构为与支付宝合作的银行为例，并结合线上支付业务的应用场景对本申请的技术方案进行说明。请参见图2和图3，图2为现有实现中第三方的线上支付业务在交易正常情况下的业务流程图；图3为现有实现中第三方的线上支付业务在交易异常情况下的业务流程图。如图2所示，在交易正常的情况下，当用户通过支付宝发起一笔面向第三方银行的支付业务时，支付宝的服务端在收到用户通过支付宝客户端发出的交易请求后，可以通过识别该交易请求中携带的第三方银行的业务标识或接口，来为该业务请求筛选正确可用的第三方银行，然后将该交易请求转发到筛选出的第三方银行，当第三方银行对这笔交易处理完成后，将处理结果返回给支付宝的服务端，再由支付宝的服务端返回到用户的支付宝客户端上。如图3所示，在交易异常的情况下，此时第三方银行与支付宝进行对接的系统可能发生了宕机、升级服务或者程序出现bug等异常事件，此时用户通过支付宝客户端发起的面向该第三方银行的交易请求无法得到正常的处理，此时支付宝的服务端在确定所述第三方银行交易异常后，可以向用户的支付宝客户端发送一个无可用银行的通告消息，以阻止用户通过支付宝客户端继续发起相同的交易。请参考图4，图4是本申请的技术方案应用在在线支付场景中时提供的一种业务的异常恢复检测方法，该方法的执行主体可以是服务端；该方法执行以下步骤：步骤401、当第三方的线上支付业务发生异常时，基于预设的筛选策略从用户发起的交易请求中筛选预设数量的测试交易请求；步骤402、将筛选出的所述测试交易请求发送至所述第三方的线上支付业务的服务端；步骤403、基于所述第三方的线上支付业务的服务端在收到所述测试交易请求后返回的交易处理结果针对所述第三方的线上支付业务的服务端进行异常恢复检测。请参见图5，图5为本实施例示出的改进后的第三方的线上支付业务在交易异常情况下的业务流程图。在交易异常的情况下，当用户通过支付宝发起一笔面向第三方银行的支付业务后，支付宝的服务端仍然按照正常流程将对应的交易请求转发到第三方银行的服务端，如果此时第三方银行与支付宝进行对接的系统发生了宕机、升级服务或者程序出现bug等异常事件，此时用户通过支付宝客户端发起的面向该第三方银行的交易请求无法得到正常的处理，在这种情况下，支付宝的服务端可以确定所述第三方银行的服务端发生交易异常，并立即从所述交易请求中获取这笔交易的业务特征参数，然后由系统管理员根据所述业务特征参数人工设定对应的筛选策略，或者由支付宝的服务端根据所述业务特征参数自动设定对应的筛选策略，并基于设定的所述筛选策略从用户发起的交易请求中筛选出预设数量的测试交易请求。其中，在线上支付业务的应用场景中，所述业务特征参数通常包括交易金额、交易地区、交易商品类型、支付工具类型、交易受理机构类型以及交易时效等参数，其中，所述交易地区是指交易请求发起的地区；所述交易商品类型是指用户购买或者支付购买的商品的类型，例如可以是虚拟类的商品；所述支付工具类型是指用户交易时选择的支付工具，例如可以是借记卡、信用卡或者支付宝的余额等；所述交易受理机构类型是指交易受理的机构，例如可以是第三方的银行，或者其它类型的诸如保险公司、基金公司等金融机构；所述交易时效是指交易完成的时限，例如可以两小时到账等交易时限。因此，系统管理员或者支付宝的服务端可以基于以上各参数来设定筛选策略。在设定所述筛选策略时，可以通过选择所述业务特征参数中的任意一个参数或者对所述业务特征参数中的各参数进行组合，来对筛选策略进行严格控制，将最终筛选出的测试交易请求针对的用户人群限定在一个特定的用户群中，从而在发出测试请求后，即时所述第三方业务的服务端的业务异常尚未恢复，由于已经提前将所述测试请求针对的用户人群限定在一个特定的用户群中，因此不会对大范围的用户业务造成影响。例如，假设用户通过支付宝发起一笔在线支付的交易请求，该交易请求中的业务特征参数如下表：交易金额9元交易地区江苏商品类型虚拟类支付工具信用卡受理机构工商银行交易时效2小时到账在设定所述筛选策略时，可以选定上表中的交易地区、商品类型、支付工具以及受理机构等参数的组合，来对筛选策略进行严格控制。假设设定出的筛选策略如下表：交易金额小于10元交易地区江苏商品类型虚拟类支付工具信用卡按照以上筛选策略筛选出的测试交易请求，将会被限定在所有在江苏地区通过信用卡支付的金额小于10元的虚拟类商品的交易请求，而该测试交易请求所针对的用户人群，则相应的被限定在发起以上交易请求的用户人群中。当然在实现时，也可以只选择所述业务特征参数中的一个参数来设定筛选策略；例如，可以只选择所述业务特征参数中的交易地区来设定筛选策略，在这种情况下，虽然对筛选策略的控制不够严格，但是基于该筛选策略筛选出的测试交易请求所针对的用户人群仍然会被限定在江苏地区，从而在发出测试请求后，即时所述第三方业务的服务端的业务异常尚未恢复，由于已经提前将所述测试请求针对的用户人群限定在江苏地区的用户群中，因此不会对更大大范围的用户业务造成影响。当支付宝的服务端基于设定的筛选策略成功筛选出测试交易请求后，可以按照预设的发送周期向所述第三方银行的服务端周期性的发送所述测试交易请求；例如，可以设定每5秒发送1笔交易。当所述第三方银行收到所述测试交易请求时，如果第三方银行的服务端 未从业务异常中恢复过来，无法正确处理该测试请求，那么所述第三方银行的服务端可以向支付宝的服务端返回一个处理失败的反馈消息或者不针对该测试交易请求向支付宝的服务端进行反馈；同样的道理，如果所述第三银行的服务端已经从业务异常中恢复过来，此时可以正确处理该测试请求，因此所述第三方银行的服务端可以向支付宝的服务端正常的返回处理结果。当支付宝的服务端在预设的时长内未收到所述处理结果，此时可以确定所述第三方银行的服务端未从业务异常中恢复过来。当支付宝的服务端在预设的时长内收到所述处理结果，此时支付宝的服务端可以检查所述处理结果中携带的返回码来确定所述第三方银行的服务端是否成功处理了所述测试请求；例如，在实现时，可以设定返回码为00时代表成功处理，返回码为01代表未成功处理。如果支付宝的服务端通过所述处理结果中的返回码判断出所述第三方业务的服务端是否已经成功处理了所述测试请求，则可以确定所述第三方银行的服务端已从业务异常中恢复；相反的，如果支付宝的服务端通过所述处理结果判断出所述第三方银行的服务端未成功处理了所述测试请求，则可以确定所述第三方银行的服务端尚未从业务异常中恢复过来。通过以上实施例的描述可知，当本申请的技术方案应用于线上支付的场景中时，通过第三方的线上支付业务发生异常时，基于预设的筛选策略从用户发起的交易请求中筛选预设数量的测试交易请求，并将筛选出的所述测试交易请求发送至所述第三方的线上支付业务的服务端；然后基于所述第三方的线上支付业务的服务端在收到所述测试交易请求后返回的交易处理结果针对所述第三方的线上支付业务的服务端进行异常恢复检测。可以实现利用真实的线上交易请求，来检测第三方业务的服务端的异常恢复情况，而且无需引入额外的检测系统。与上述方法实施例相对应，本申请还提供了装置的实施例。请参见图6，本申请提出一种业务的异常恢复检测装置60，应用于服务端，所述服务端可以是服务器；其中，请参见图7，作为承载所述商品评价 业务的异常恢复检测装置60的服务器所涉及的硬件架构中，通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等；以软件实现为例，所述商品评价业务的异常恢复检测装置50通常可以理解为加载在内存中的计算机程序，通过CPU运行之后形成的软硬件相结合的逻辑装置，所述装置60包括：筛选模块601，用于在第三方业务发生异常时，基于预设的筛选策略从用户发起的业务请求中筛选预设数量的测试请求；发送模块602，用于将筛选出的所述测试请求发送至所述第三方业务的服务端；检测模块603，用于基于所述第三方业务的服务端在收到所述测试请求后返回的业务处理结果针对所述第三方业务的服务端进行异常恢复检测。在本实施例中，所述装置60还包括：获取模块604，用于在所述筛选模块基于预设的筛选策略从用户发起的业务请求中筛选预设数量的测试请求之前，获取所述第三方业务的业务特征参数；设定模块605，用于基于获取到的所述业务特征参数设定对应的筛选策略。在本实施例中，所述发送模块602具体用于：将筛选出的所述测试请求按照预设的发送周期发送至所述第三方业务的服务端。在本实施例中，所述检测模块603具体用于：判断是否收到所述第三方业务的服务端返回的所述业务处理结果；当在预设时长内未收到所述第三方业务的服务端返回的所述业务处理结果时，确定所述第三方业务的服务端未从业务异常中恢复；当在预设时长内收到所述第三方业务的服务端返回的所述业务处理结果时，基于所述业务处理结果判断所述第三方业务的服务端是否成功处理所述测试请求；当基于所述业务处理结果判断出所述第三方业务的服务端成功处理所述测试请求时，确定所述第三方业务的服务端已从业务异常中恢复；当基于所述业务处理结果判断出所述第三方业务的服务端未成功处理所述测试请求时，确定所述第三方业务的服务端未从业务异常中恢复。在本实施例中，所述第三方业务包括第三方的线上支付业务；所述业务特征参数包括所述线上支付业务的交易金额、交易地区、交易商品类型、支付工具类型、交易受理机构类型以及交易时效中的一个或者多个的组合。本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本
技术领域：
中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。当前第1页1 2 3