CN106157183A - 服务提供方法及装置 - Google Patents

Abstract

本申请提供一种服务提供方法及装置。方法包括：在基于选定的服务执行业务之前，识别服务在用于该业务时是否可用；若服务在用于该业务时不可用，提示业务更换其他服务。本申请在基于选定的服务执行业务之前，识别该服务在用于该业务时是否可用，若不可用，则提示业务更换其他服务，尽量避免使用不可用服务导致业务失败，并使业务及时更换可用服务，有利于提高业务成功率。

Description

服务提供方法及装置

【技术领域】

本申请涉及互联网技术领域，尤其涉及一种服务提供方法及装置。

【背景技术】

随着互联网技术的发展，基于互联网的业务越来越多，并且越来越复杂。业务之间的关联性也越来越强，一个业务的成功执行除了与该业务自身涉及的条件等因素有关，往往还依赖于其他服务。

一般根据业务所要实现的功能，可以为其匹配到多个服务。当需要执行业务时，首先要从所匹配到的多个服务中该业务选择使用的服务，并基于所选择的服务执行业务。在该过程中，可能会因为所选择的服务不可用导致业务失败，降低业务成功率。

【发明内容】

本申请的多个方面提供一种服务提供方法及装置，用以提高业务成功率。

本申请的一方面，提供一种服务提供方法，包括：

在基于选定的服务执行业务之前，识别所述服务在用于所述业务时是否可用；

若所述服务在用于所述业务时不可用，提示所述业务更换其他服务。

本申请的另一方面，提供一种服务提供装置，包括：

识别模块，用于在基于选定的服务执行业务之前，识别所述服务在用于所述业务时是否可用；

提示模块，用于在所述服务在用于所述业务时不可用时，提示所述业务更换其他服务。

在本申请中，在基于选定的服务执行业务之前，识别该服务在用于该业务时是否可用，若该服务在用于业务时不可用，则提示业务更换其他服务，尽量避免使用不可用服务导致业务失败，并使业务及时更换可用服务，有利于提高业务成功率。

【附图说明】

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

图1为本申请一实施例提供的服务提供方法的流程示意图；

图2为本申请一实施例提供的步骤101的实施方式的流程示意图；

图3为本申请一实施例提供的支付系统的结构示意图；

图4为本申请一实施例提供的服务提供装置的结构示意图；

图5为本申请另一实施例提供的服务提供装置的结构示意图。

【具体实施方式】

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

图1为本申请一实施例提供的服务提供方法的流程示意图。如图1所示，该方法包括：

101、在基于选定的服务执行业务之前，识别该服务在用于业务时是否可用。

102、若该服务在用于上述业务时不可用，提示业务更换其他服务。

本实施例提供一种服务提供方法，可由服务提供装置来执行。服务提供装置可以是各种能够对服务进行可用性检测并在服务不可用时向选定该服务的业务提示更换其他服务的装置。不同业务所需的服务一般不相同。例如，搜索业务所需的服务可以是能够向该搜索业务提供资源的服务。又例如，管理业务所需的服务可以是能够实现某个具体管理功能的服务。又例如，支付业务所需的服务可以是提供支付渠道的服务。

服务提供装置可以向业务开放该业务可使用的各种服务。向业务开放该业务可使用的服务，实际上是将服务的服务接口提供给可以使用该服务的业务，以便于业务能够通过服务接口访问或调用该服务。

在实际应用中，由于各种原因，例如服务所在服务器宕机、访问服务需要使用的通道故障(例如网络故障)、服务因升级处于不可访问状态等都会导致服务不可用。对业务来说，在选择服务之前无法获知服务是否可用，一般只有在业务失败后，通过排查失败原因可以获知所选择的服务是不可用的。若业务选择的服务是不可用的，会导致业务失败，降低业务成功率。为了解决该问题，本实施例提供一种方法，具体的：

在基于选定的服务执行业务之前，识别该服务在用于该业务时是否可用，若该服务在用于该业务时不可用，则提示业务更换其他服务，尽量避免使用不可用服务导致业务失败，使得业务可以及时更换可用服务，有利于提高业务成功率。

在一可选实施方式中，如图2所示，服务提供装置在基于选定的服务执行业务之前，识别该服务在用于该业务时是否可用，即步骤101的一种实施方式包括：

1011、统计服务在指定时间内的服务成功率，该服务成功率是指在指定时间内使用该服务成功执行的业务数量占在指定时间内使用该服务执行的业务总数量的百分比；

1012、判断上述服务成功率是否小于指定阈值，若判断结果为是，执行步骤1013；若判断结果为否，执行步骤1014；

1013、确定上述服务在用于上述服务时不可用；

1014、确定上述服务在用于上述服务时可用。

在该实施方式中，考虑到可用服务的服务成功率一般比较高，例如大于或等于指定阈值，而不可用服务的服务成功率一般比较低，例如小于指定阈值。指定阈值可以根据实际应用场景适应性设置，例如可以是但不限于：87％、90％、92％、95％甚至是100％。基于此，当业务选定所使用的服务后，服务提供装置统计该服务在指定时间内的服务成功率，将该服务在指定时间内的服务成功率与指定阈值相比，若大于或等于指定阈值，说明该服务的服务成功率较高，确定该服务是可用的，若该服务在指定时间内的服务成功率小于指定阈值，说明该服务的服务成功率较低，则可以确定该服务是不可用的。

进一步，在业务选定所使用的服务后，服务提供装置可以确定执行该服务的服务器；统计该服务器在指定时间内成功处理的该服务的调用请求个数占在指定时间内该服务的调用请求总个数的百分比，以作为该服务的服务成功率。其中，服务器成功处理该服务的调用请求意味着服务器成功执行该服务；若服务器故障，则将无法处理该服务的调用请求。

在一可选实施方式中，当识别出为业务选定的服务不可用时，指示业务更换其他服务的方式包括以下至少一种：

在展示该服务的页面上，标记该服务不可用；例如，可以将该服务对应的图标或入口设置为不可操作；

以文本形式提示该服务不可用；例如，可以弹出一文本框或窗口等向用户显示用于指示该服务不可用的文本信息；

以音频形式提示该服务不可用；例如可以向用户播放用于指示该服务不可用的语音信息，或者可以向用户发出预设的报警提示音。

在一可选实施方式中，在基于选定的服务执行业务之前，服务提供装置识别该服务在用于该业务时是否可用；若该服务在用于该业务时可用，则可以基于该服务执行所述业务。

值得说明的是，根据业务不同，基于服务执行业务的流程也会有所不同。对此本实施例不做关注，故不做详述。

为便于理解本申请技术方案，本申请以下方法实施例将结合支付场景对本申请技术方案做详细说明。

在支付场景中，上述实施例中的服务具体可以是支付方式(或称为支付渠道)，上述实施例中使用服务的业务具体可以是支付业务；在实际应用中，发卡行系统故障是导致支付方式不可用的原因之一，在以下实施例中重点以该原因为例，基于此，上述实施例中的服务提供装置具体可以是支付系统中的卡中心模块。

一般根据支付方式在支付系统提供的收银页面上的展现方式的不同，可以分为路由型支付方式和非路由型支付方式。路由型支付方式一般用户不可见，是隐藏在收银页面之后，例如各种信用卡支付方式通常属于路由型支付方式，后台可能有不同支付公司提供的支付网关，如WPG和HCG等，根据一定的风控规则和路由比例，为用户的支付业务选择某一种支付方式。非路由型支付方式，即用户可以在收银页面看到该支付方式并且直接使用该支付方式完成支付业务。

图3为本申请一实施例提供的支付系统的结构示意图。如图3所示，该支付系统需要使用第三方提供的支付方式完成支付业务，该支付系统具体包括：收银台模块、支付核心模块、网关模块、支付决策模块、内部支付模块、支付运维模块和卡中心模块。

用户使用支付系统进行一次支付业务具体包括以下几个步骤：

用户进入收银台模块提供的收银页面，收银台模块调用支付决策模块向用户展示支付方式；

用户点击收银页面上的支付按钮进行支付，并选择使用的支付方式，例如输入信用卡卡号或选择已快捷绑定的信用卡，以选择使用信用卡支付方式，支付决策模块和支付运维模块确定用户选择的支付方式；

支付决策模块向卡中心模块发送可用性识别请求，以供卡中心模块对用户选择使用的支付方式进行可用性识别并返回是否可用的识别结果。卡中心模块根据卡柄(cardbin)规则，识别出用户所选支付方式对应的发卡行，并且统计出该发卡行在一定时间内的支付成功率，如果该支付成功率小于一定的阀值，即可以确定该支付方式不可用；反之，则可以确定该支付方式为可用。上述cardbin规则是由卡组织规定的规则，用于限定发卡行与支付卡(例如信用卡或借记卡)之间的关系。

当卡中心模块返回的识别结果为用户选择的支付方式可用的时，支付核心模块根据选择的支付方式处理支付业务，具体包括使用内部支付模块提供的内部支付方式和/或第三方提供的支付方式完成支付；对于需要使用第三方提供的支付方式的情况，支付核心模块通过网关模块调用第三方提供的支付方式进行支付。

在一次支付业务完成后，支付核心模块会将支付结果推给支付运维模块，或者支付运维模块会通过日志或者数据同步等方式采集支付结果。支付运维模块会将支付结果推送给卡中心模块。其中，支付运维模块可以从支付方式的维度，分析各个支付方式的支付成功率，错误数等信息，以便确定支付方式是否可用。卡中心模块可以从发卡行的角度，分析各发卡行的支付成功率，从而确定该发卡行对应的支付方式是否可用。

值得说明的是，上述卡中心模块可以与支付运维模块合并为一模块来实现。

由上述可见，用户选择所使用的支付方式之后，且在根据所选择的支付方式执行支付操作之前，支付决策模块和支付运维模块除了确定用户选择的支付方式之外，还需要通过卡中心模块识别所选择支付方式的可用性；若该支付方式可用，则继续执行后续支付步骤，否则提示用户该支付方式不可用，请更换其他支付方式，例如更换为其他行信用卡或者使用非信用卡的支付方式，有利于提高支付业务的成功率。

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

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

图4为本申请一实施例提供的服务提供装置的结构示意图。如图4所示，该装置包括：识别模块41和提示模块42。

识别模块41，用于在基于选定的服务执行业务之前，识别该服务在用于该业务时是否可用。

提示模块42，与识别模块41连接，用于在识别模块41识别出该服务在用于上述业务时不可用时，提示业务更换其他服务。

在一可选实施方式中，如图5所示，该装置还包括：执行模块43。

执行模块43，与识别模块41连接，用于在识别模块41识别出上述服务在用于上述业务时可用时，基于上述服务执行上述业务。

在一可选实施方式中，识别模块41具体可用于：

统计服务在指定时间内的服务成功率，该服务成功率是指在指定时间内使用该服务成功执行的业务数量占在指定时间内使用该服务执行的业务总数量的百分比；

判断该服务成功率是否小于指定阈值；

若判断结果为是，确定该服务在用于上述业务时不可用；

若判断结果为否，确定该服务在用于上述业务时可用。

在一可选实施方式中，识别模块41在统计服务在指定时间内的服务成功率时，进一步具体用于：

确定执行服务的服务器；

统计该服务器在指定时间内成功处理的该服务的调用请求个数占在指定时间内该服务的调用请求总个数的百分比。

在一可选实施方式中，提示模块42具体可用于执行以下至少一种操作：

在展示服务的页面上，标记该服务不可用；

以文本形式提示该服务不可用；

以音频形式提示该服务不可用。

在一可选实施方式中，上述业务为支付业务，为所述业务选定的服务为支付渠道。

本实施例提供的服务提供装置，在业务选定使用的服务后，识别该服务是否可用，若不可用，则提示业务更换其他服务，尽量避免使用不可用服务导致业务失败，并使业务及时更换可用服务，有利于提高业务成功率。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

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

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

1.一种服务提供方法，其特征在于，包括：

在基于选定的服务执行业务之前，识别所述服务在用于所述业务时是否可用；

若所述服务在用于所述业务时不可用，提示所述业务更换其他服务。

2.根据权利要求1所述的方法，其特征在于，所述识别所述服务在用于所述业务时是否可用，包括：

统计所述服务在指定时间内的服务成功率，所述服务成功率是指在所述指定时间内使用所述服务成功执行的业务数量占在所述指定时间内使用所述服务执行的业务总数量的百分比；

判断所述服务成功率是否小于指定阈值；

若判断结果为是，确定所述服务在用于所述业务时不可用；

若判断结果为否，确定所述服务在用于所述业务时可用。

3.根据权利要求2所述的方法，其特征在于，所述统计所述服务在指定时间内的服务成功率，包括：

确定执行所述服务的服务器；

统计所述服务器在所述指定时间内成功处理的所述服务的调用请求个数占在所述指定时间内所述服务的调用请求总个数的百分比。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述提示所述业务更换其他服务包括执行以下至少一种操作：

在展示所述服务的页面上，标记所述服务不可用；

以文本形式提示所述服务不可用；

以音频形式提示所述服务不可用。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述业务为支付业务，所述服务为支付渠道。

6.一种服务提供装置，其特征在于，包括：

识别模块，用于在基于选定的服务执行业务之前，识别所述服务在用于所述业务时是否可用；

提示模块，用于在所述服务在用于所述业务时不可用时，提示所述业务更换其他服务。

7.根据权利要求6所述的装置，其特征在于，所述识别模块具体用于：

统计所述服务在指定时间内的服务成功率，所述服务成功率是指在所述指定时间内使用所述服务成功执行的业务数量占在所述指定时间内使用所述服务执行的业务总数量的百分比；

判断所述服务成功率是否小于指定阈值；

若判断结果为是，确定所述服务在用于所述业务时不可用；

若判断结果为否，确定所述服务在用于所述业务时可用。

8.根据权利要求7所述的装置，其特征在于，所述识别模块进一步具体用于：

确定执行所述服务的服务器；

统计所述服务器在所述指定时间内成功处理的所述服务的调用请求个数占在所述指定时间内所述服务的调用请求总个数的百分比。

9.根据权利要求6-8任一项所述的装置，其特征在于，所述提示模块具体用于执行以下至少一种操作：

在展示所述服务的页面上，标记所述服务不可用；

以文本形式提示所述服务不可用；

以音频形式提示所述服务不可用。

10.根据权利要求6-9任一项所述的装置，其特征在于，所述业务为支付业务，所述服务为支付渠道。