本申请涉及互联网技术领域，尤其涉及一种服务提供方法及装置。
背景技术：
随着互联网技术的发展，基于互联网的业务越来越多，并且越来越复杂。业务之间的关联性也越来越强，一个业务的成功执行除了与该业务自身涉及的条件等因素有关，往往还依赖于其他服务。一般根据业务所要实现的功能，可以为其匹配到多个服务。
当某个服务不可用时，该服务一般会被屏蔽掉，当该服务重新变得可用时，该服务会重新对外开放。现有技术中，一般采用定时机制来判断服务是否重新变得可用，具体的，预先设定一个屏蔽时长，当服务不可用的时间超过该屏蔽时长后，默认该服务重新变得可用，并自动将该服务对外开放。对于未能在屏蔽时长内重新变得可用的服务来说，目前这种方式会发生误判，提供给业务的服务的可靠性较低，导致使用该服务的业务无法正常开展，降低业务成功率。
技术实现要素：
本申请的多个方面提供一种服务提供方法及装置，用以提高提供给业务的服务的可靠性，提高业务成功率。
本申请的一方面，提供一种服务提供方法，包括：
在服务变得不可用后，与所述服务进行交互，以检测所述服务是否重新变得可用；
当检测到所述服务重新变得可用时，向可以使用所述服务的业务开放所述服务。
本申请的另一方面，提供一种服务提供装置，包括：
检测模块，用于在服务变得不可用后，与所述服务进行交互，以检测所述服务是否重新变得可用；
开放模块，用于当检测到所述服务重新变得可用时，向可以使用所述服务的业务开放所述服务。
在本申请中，在服务变得不可用后，通过与该服务进行交互，以检测服务是否重新变得可用，并在检测到服务重新变得可用时，向可以使用该服务的业务开放该服务。与现有技术相比，本申请可以在准确确定服务重新变得可用后提供给相应的业务，提高了提供给业务的服务的可靠性，有利于提高业务成功率。
【附图说明】
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本申请一实施例提供的服务提供方法的流程示意图；
图2为本申请一实施例提供的步骤101的实施方式的流程示意图；
图3为本申请一实施例提供的服务提供方法对应的状态图；
图4为本申请一实施例提供的支付系统的结构示意图；
图5为本申请一实施例提供的服务提供装置的结构示意图。
【具体实施方式】
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
图1为本申请一实施例提供的服务提供方法的流程示意图。如图1所示，该方法包括：
101、在服务变得不可用后，与该服务进行交互，以检测该服务是否重新变得可用。
102、当检测到上述服务重新变得可用时，向可以使用该服务的业务开放该服务。
本实施例提供一种服务提供方法，可由服务提供装置来执行。服务提供装置可以是各种能够对服务进行可用性检测并在服务可用时可以向需要该服务的业务平台提供服务的装置。不同业务平台开展业务所需的服务一般不相同。例如，业务平台可以是搜索业务平台，则所需的服务可以是能够向搜索业务平台提供资源的服务。又例如，业务平台可以是管理业务平台，则所需的服务可以是能够实现某个具体管理功能的服务。又例如，业务平台可以是支付业务平台，则所需的服务可以是提供支付渠道的服务。
在服务可用时，服务提供装置可以向可以使用服务的业务开放该服务。向可以使用服务的业务开放该服务，实际上是将该服务的服务接口提供给可以使用该服务的业务，以便于这些业务能够通过服务接口访问或调用该服务。
但是，由于各种原因，例如服务所在服务器宕机、访问服务需要使用的通道故障(例如网络故障)、服务因升级处于不可访问状态等都会导致服务不可用。服务不可用后，维护人员或设备一般会查找原因并进行解决，当造成服务不可用的原因解决后，服务会重新变得可用。
若不能准确判断服务是否真的重新变得可用，有可能向业务开放尚不可用的服务，意味着业务可以使用的服务的可靠性较低，当业务使用了该尚不可用的服务，就会导致业务失败。为了解决该问题，本实施例提供一种方法，具体的：
在服务变得不可用后，服务提供装置通过与该服务进行交互，以便检测服务是否重新变得可用，并且只有当检测到服务重新变得可用时，才向可以使用该服务的业务开放该服务。这样可以保证提供给业务的服务都是可用的，提高了提供给业务的服务的可靠性，这样当业务使用服务时，不会因为服务不可用而失败，有利于提高业务成功率。
在一可选实施方式中，如图2所示，服务提供装置在服务变得不可用后，与服务进行交互，以检测服务是否重新变得可用，即步骤101的一种实施方式包括：
1011、在服务变得不可用后，向服务发送测试请求。
1012、根据服务对测试请求的响应检测服务是否重新变得可用。
在该实施方式中，在服务变得不可用后，服务提供装置具体向服务发送测试请求，若服务重新变得可用的，一般会对服务提供装置发送的测试请求有所响应，例如在一定时间内返回一响应消息，相反的，若服务仍不可用，一般不会做出响应，或者不会及时做出响应，因此，服务提供装置可以根据服务对测试请求的响应来检测服务是否重新变得可用。与现有技术中的定时机制相比，不容易发生误判，检测出的服务是否重新变得可用的结果的准确性较高。
在一可选实施方式中，服务可以提供专用测试接口，用于供服务提供装置检测服务是否重新变得可用，该测试接口不同于服务提供的服务接口，不会影响服务的正常使用。
基于上述，服务提供装置在服务变得不可用后，可以通过服务提供的测试接口向服务发送测试请求，并根据服务对测试请求的响应检测服务是否重新变得可用。
一种具体实施方式可以是：服务提供装置在服务变得不可用后，可以通过服务提供的测试接口向服务发送测试请求，并在每次向服务发送测试请求之后，判断服务在该次发送测试请求后的一定时间内是否返回响应消息；若服务发送测试请求后的一定时间内返回响应消息，则确定服务重新变得可用；反之，若服务在发送测试请求后的一定时间内未返回响应消息，则确定服务仍不可用。该实施方式的实现效率较高。另外，本实施方式还可以通过调整前后两次发送测试请求的时间间隔，来提高检测到服务是否重新变得可用的及时性。其中，前后两次发送测试请求的时间间隔越小，检测到服务是否重新变得可用的及时性就越高。
另一种具体实施方式可以是：服务提供装置在服务变得不可用后，可以通过服务提供的测试接口周期性的向服务发送一次测试请求；获取该服务针对指定时间内发送的测试请求的响应成功率，该响应成功率是该服务针对指定时间内发送的测试请求成功返回的响应消息的个数与该指定时间内发送的测试请求的个数的比值；若响应成功率大于或等于预设的第一门限，确定服务重新变得可用；若响应成功率小于第一门限，确定服务仍不可用。简单来说，服务提供装置可以周期性的向服务发送测试请求；通过统计指定时间内发送的测试请求的个数以及服务针对该指定时间内发送的测试请求的返回的响应消息的个数，进而获得响应消息的个数与该指定时间内发送的测试请求的个数的比值，作为服务的响应成功率；将响应成功率与预设的第一门限进行比较，若大于或等于第一门限，则认为服务重新变得可用；反之，认为服务仍不可用。该实施方式具体通过与服务进行多次交互来确定服务是否重新变得可用，可以进一步提高给出的服务是否重新变得可用的结果的准确性，进一步有利于提高提供给相应业务的服务的可靠性。另外，本实施方式可以通过调整发送测试请求的周期，来提高检测到服务是否重新变得可用的及时性。其中，周期越小，检测到服务是否重新变得可用的及时性就越高。
在另一可选实施方式中，服务提供装置在服务变得不可用后，可以通过服务提供的服务接口向服务发送测试请求，并根据服务对测试请求的响应检测服务是否重新变得可用。在该实施方式中，由于直接使用服务提供的服务接口对服务的可用性进行检测，对服务来说，不需要进行任何改动，实现成本较低。优选的，由于该检测过程会占用服务接口，为了降低对服务正常使用的影响，服务提供装置可以通过服务接口向服务发送一次测试请求，并根据服务针对该测试请求的响应检测服务是否重新变得可用。具体的，若服务在服务提供装置发送测试请求后的一定时间内返回响应消息，则确定服务重新变得可用；反之，确定服务仍不可用。
服务提供装置与服务进行交互的方式并不限于在图2所示由服务提供装置主动与服务进行交互，例如，还可以是服务在重新变得可用后，主动向服务提供装置发送通知消息，使得服务提供装置获知服务重新变得可用。
在一可选实施方式中，上述步骤102的一种实施方式包括：当检测到服务重新变得可用时，服务提供装置可以逐步向可以使用该服务的业务开放该服务。具体来说，服务提供装置可以按照预设的开放比例，逐次向部分可以使用该服务的业务开放该服务。其中，开放比例用于限定每次开放新增的业务数量。例如，服务提供装置可以按照预设的开放比例，逐渐提高该服务的服务权重，以便于能够有更多业务被分配到该服务。又例如，服务提供装置可以按照该开放比例，直接将更多的业务分配给该服务。
值得说明的是，开放比例可以根据服务的不同特性，适应性配置，例如可以是5％、10％或25％等。
进一步，上述按照预设的开放比例，逐次向部分可以使用服务的业务开放该服务的实施方式包括：
判断是否已经向全部可以使用该服务的业务开放该服务；
若判断结果为否，确定该服务在当前已开放该服务的业务中的使用成功率，并在该使用成功率大于或等于预设的第二门限时，按照预设的开放比例，继续向当前未开放该服务的业务开放该服务。
可选的，若上述使用成功率小于第二门限，则可以对全部可以使用该服务的业务屏蔽该服务。
可选的，若已经对全部可以使用服务的业务开放该服务，则可以结束操作。
该实施方式提供的逐步开放服务的方法，可以防止大量业务同时使用该服务，可以减轻该服务的处理压力，避免服务所在物理设备(例如服务器)发生崩溃。
结合上述逐步开放服务的可选实施方式，则本申请一实施例提供的服务提供方法对应的状态图如图3所示。
为便于理解本申请技术方案，本申请以下方法实施例将结合支付场景对本申请技术方案做详细说明。在该支付场景中，上述实施例中的服务具体可以是支付方式(或称为支付渠道)，上述实施例中使用服务的业务具体可以是支付业务；上述实施例中的服务提供装置具体可以是支付运维模块。
随着支付公司对支付方式可用率的要求越来越高，支付方式的监控需求也越来越高，支付方式发生故障之后，一般都会人工或者自动切换掉不可用的支付方式。
一般根据支付方式在支付系统提供的收银页面上的展现方式的不同，可以分为路由型支付方式和非路由型支付方式。路由型支付方式一般用户不可见，是隐藏在收银页面之后，例如各种信用卡支付方式通常属于路由型支付方式，后台可能有不同支付公司提供的支付网关，如WPG和HCG等，根据一定的风控规则和路由比例，为用户的支付业务选择某一种支付方式。非路由型支付方式，即用户可以在收银页面看到该支付方式并且直接使用该支付方式完成支付业务。
图4为本申请一实施例提供的支付系统的结构示意图。如图4所示，该
支付系统需要使用第三方提供的支付方式完成支付业务，该支付系统具体
包括：收银台模块、支付核心模块、网关模块、支付决策模块、内部支付
模块和支付运维模块。
用户使用支付系统进行一次支付业务具体包括以下几个步骤：
用户进入收银台模块提供的收银页面，收银台模块调用支付决策模块向用户展示可用的支付方式；
用户点击收银页面上的支付按钮进行支付，支付决策模块和支付运维模块选择所需的支付方式；
支付核心模块根据选择的支付方式处理支付业务，具体包括使用内部支付模块提供的内部支付方式和/或第三方提供的支付方式完成支付；对于需要使用第三方提供的支付方式的情况，支付核心模块通过网关模块调用第三方提供的支付方式进行支付。
在一次支付业务完成后，支付核心模块会将支付结果推给支付运维模块，或者支付运维模块会通过日志或者数据同步等方式采集支付结果。支付运维模块会分析各个支付方式的支付成功率，错误数等纬度，一旦超于预期阀值，认为支付方式不可用，并会通知支付决策模块进行支付方式的屏蔽。具体的，对于路由型支付方式，将其路由权重置为0，对于非路由型支付方式，在收银页面不展示该支付方式。
针对被屏蔽的支付方式，支付运维模块通过与该支付方式进行交互以检测该支付方式是否重新变得可用，若支付方式重新变得可用，则重新将支付方式开放给支付业务。其中，支付运维模块可以通过支付方式提供的测试接口，向支付方式发送测试请求，根据支付方式对该测试请求的响应判断支付方式是否变得可用；或者，可以模拟支付业务，通过支付方式提供的服务接口向支付方式发送虚拟的支付业务请求，根据支付方式对该虚拟支付业务请求的响应判断支付方式是否变得可用。重新将支付方式开放给支付业务主要是根据预先配置的开放比例，以逐步灰度的方式向支付业务开放该支付方式。具体来说，对于路由型支付方式，可以逐步提高该支付方式的路由权重；对于非路由型支付方式，在收银页面对支付方式进行灰度展示，即控制一定数量的买家使用该支付方式。
其中，对每个开放阶段，可以判断支付方式是否已经完全开放给支付业务，若已完全开放给支付业务，则把支付方式的状态置为打开；否则根据支付方式开放后的支付成功率，决定是进一步向支付业务开放该支付方式，还是屏蔽该支付方式。
本实施例通过对支付方式进行检测，能够准确判断支付方式是否已经重新变得可用，从而可以更加准确的向支付业务提供支付方式，提高提供给支付业务的支付方式的可靠性，有利于提高支付业务的成功率。另外，本实施例还可以提高发现支付方式重新变得可用的及时性。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
图5为本申请一实施例提供的服务提供装置的结构示意图。如图5所示，该装置包括：检测模块51和开放模块52。
检测模块51，用于在服务变得不可用后，与服务进行交互，以检测服务是否重新变得可用。
开放模块52，与检测模块51连接，用于当检测模块51检测到服务重新变得可用时，向可以使用服务的业务开放服务。
在一可选实施方式中，检测模块51的实现结构可以包括：发送单元和检测单元。
发送单元，用于在服务变得不可用后，向服务发送测试请求。检测单元，用于根据服务对测试请求的响应检测服务是否重新变得可用。
进一步，发送单元具体用于：在服务变得不可用后，通过服务提供的测试接口周期性的向服务发送测试请求。检测单元具体用于：获取服务针对指定时间内发送的测试请求的响应成功率；响应成功率是服务针对指定时间内发送的测试请求成功返回的响应消息的个数与指定时间内发送的测试请求的个数的比值；若响应成功率大于或等于预设的第一门限，确定服务重新变得可用；若响应成功率小于第一门限，确定服务不可用。
在一可选实施方式中，开放模块52具体用于：当检测到服务重新变得可用时，按照预设的开放比例，逐次向部分可以使用服务的业务开放服务，开放比例用于限定每次开放新增的业务数量。
开放模块52进一步具体用于：判断是否已经向全部可以使用服务的业务开放服务；若判断结果为否，确定服务在当前已开放服务的业务中的使用成功率，并在使用成功率大于或等于预设的第二门限时，按照开放比例，继续向当前未开放服务的业务开放服务。
开放模块52进一步具体用于：判断是否已经向全部可以使用服务的业务开放服务；若判断结果为否，获取当前已开放服务的业务中使用了服务且执行结果为成功的业务的数量与当前已开放服务的业务中使用了服务的业务的数量的比值作为成功使用率，并在使用成功率大于或等于预设的第二门限时，按照开放比例，继续向当前未开放服务的业务开放服务。
本实施例提供的服务提供装置，在服务变得不可用后，通过与该服务进行交互，以检测服务是否重新变得可用，并在检测到服务重新变得可用时，向可以使用该服务的业务开放该服务。与现有技术相比，本实施例提供的服务提供装置可以在准确确定服务重新变得可用后提供给相应的业务，提高了提供给业务的服务的可靠性，有利于提高业务成功率。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(RandomAccessMemory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。