具体实施方式

下面将参照附图更加详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

如图1所示，本发明实施例提供了一种第三方接口调用方法，该方法主要包括：

101、确定适用于目标任务的各第三方接口的优先级顺序以及各所述第三方接口的目标服务次数，其中，所述目标服务次数表征对应的第三方接口单位时间内能够提供稳定服务的理想次数。

在实际应用中，任意一个需要依赖第三方提供接口服务的任务均可作为目标任务，本实施例对目标任务的具体类型步骤具体限定。当存在目标任务时，需要确定适用于目标任务的第三方接口，以便利用这些第三方接口服务于目标任务。

在确定出适用于目标任务的第三方接口后，为了降低成本以及保证接口服务的稳定性，则需要对这些第三方接口服务进行优先级排序，以便根据优先级排序来调用第三方接口以响应目标任务的调用请求。

下面对如何确定各第三方接口的优先级顺序进行说明，该确定方法为：根据各第三方接口的服务参数，确定各所述第三方接口的优先级顺序，其中，所述服务参数包括如下中的至少一种：响应耗时、服务次数、服务价格。其中，目标服务次数表征对应的第三方接口单位时间内能够提供稳定服务的理想次数。

确定各第三方接口的优先级排序可单独考虑服务参数中的一种，也可综合考虑服务参数中的两种或两种以上。示例性的，若用户要求降低成本，服务价格越低的第三方接口其优先级越高。示例性的，若用户要求响应耗时尽可能短，则响应耗时越小的第三方接口其优先级越高。示例性的，用户要求成本的同时要求服务次数，则可综合考虑目标服务次数和服务价格来确定各第三方接口的优先级。

示例性的，目标任务A需要依赖第三方提供接口服务，其适用的第三方接口如下：第三方接口A，服务价格1元，目标服务次数500次，响应耗时300ms；第三方接口B，服务价格1.5元，目标服务次数700次，响应耗时250ms；第三方接口C，服务价格1.5元，目标服务次数300次,响应耗时400ms。优先级排序时综合考虑了服务价格和响应耗时，则优先级从高到低的顺序为：第三方接口A，第三方接口B，第三方接口C。

在确定各第三方接口的优先级排序后，可针对目标任务进行第三方接口的绑定。示例性的，目标任务A绑定调用接口配置{"1":{"tps":"500","interface":"第三方接口A"},"2":{"tps":"700","interface":"第三方接口B"},"3":{"tps":"300","interface":"第三方接口C"}}，将该配置持久化至mysql或redis等数据库中，以供调用第三方接口时使用。需要说明的是，配置中的1、2、3表征接口的优先级顺序，tps表征第三方接口当前无异常处于可调用状态。

102、在单位时间内，每接收一次所述目标任务的调用请求均执行：确定当前无异常的第三方接口为目标第三方接口，从所述单位时间内累计调用次数未达到对应的目标服务次数的目标第三方接口中，选取优先级最高的目标第三方接口为针对所述调用请求的目标第三方接口，调用所选取的目标第三方接口。

这里所述的单位时间可以根据目标任务的要求确定，本实施例不做具体限定。示例性的，该单位时间为1秒、2秒、1分钟等。在单位时间内目标任务可发起多次调用请求，每一次调用请求需要选用一个第三方接口进行调用，以对目标任务进行响应。

在单位时间内，无论接收到多少次调用请求，均需要进行相同的处理，该处理过程可包括如下步骤一至步骤三：

步骤一、确定当前无异常的第三方接口为目标第三方接口。

由于任何第三方接口在被调用时，均可能会存在出现异常的风险，该异常风险的出现会导致目标任务不能稳定执行，因此为了保证目标任务的稳定性，则在调用第三方接口时，需要调用当前无异常的第三方接口。因此，需要确定当前无异常的第三方接口为目标第三方接口，以在目标第三方接口中选取针对调用请求的第三方接口。

下面对如何选取无异常的第三方接口的方法进行说明，该方法为：将未记录在故障文本中的第三方接口，确定为所述目标第三方接口，其中，所述故障文本中记录有在第一预设时长内出现异常的次数达到预设次数阈值的第三方接口。

故障文本用于记录当前出现异常不能被调用的第三方接口，该故障文本的存在形式本实施例中不做具体限定，可选的，该故障文本可以以数据库表的形式存在。故障文本中记录的第三方接口会随着第三方接口的状态随时发生变动，也就是说，新发生异常的第三方接口会被记录到故障文本中，而异常被排除的第三方接口从故障文本中删除。

为了及时将恢复正常的第三方接口从故障文本中排除，进入可调用状态，则需要监测记录在故障文本中的各第三方接口在其各自对应的第二预设时长内是否排除异常，若排除了，则将排除异常的第三方接口从故障文本中删除。

故障文本中记录的第三方接口均是在第一预设时长内出现异常的次数达到预设次数阈值的第三方接口，需要说明的是，每一个第三方接口对应的第一预设时长以及预设次数阈值均可根据第三方接口自身的特性确定，并非所有的第三方接口均相同。每一个第三方接口对应的第二预设时长也可根据第三方接口自身的特性确定，并非所有的第三方接口均相同。

第三方接口的异常检测可通过如下方式进行，对每一个第三方接口进行故障配置，然后使用故障配置对第三方接口进行故障检测，故障配置的具体示例如下所示：针对每个第三方接口绑定故障配置{"20s":{"第三方接口A":"30","第三方接口B":"30"},"1min":{"第三方接口C":"20"}}，配置的含义为：第三方接口A、第三方接口B的配置阈值都为20s内30次，若第三方接口A在20s内出现30次异常，则认定为第三方接口A故障，同理，第三方接口B在20s内出现30次异常，则认定第三方接口B故障。第三方接口C的配置阈值为1min内20次，若第三方接口C在1min内出现20次异常，则认定第三方接口C故障。将该配置持久化至mysql或redis数据库中。当任一第三方接口当前被调用时，则使用其对应的故障配置进行异常判断。当判断其异常时，将其记录到设定的故障文本中，故障文本中记录有当前异常的第三方接口，若记录异常的第三方接口排除异常后，其将从该故障列表中剔除。也就是说，故障列表中的第三方接口随着第三方接口的状态发生变动。当任一第三方接口记录在故障文本中时，则会将其对应配置中的tps修改为0，说明其当前不能被调用。

步骤二、从所述单位时间内累计调用次数未达到对应的目标服务次数的目标第三方接口中，选取优先级最高的目标第三方接口为针对所述调用请求的目标第三方接口。

单位时间内累计调用次数未达到对应的目标服务次数的目标第三方接口，均为当前能够提供稳定服务的第三方接口。虽然这些第三方接口当前都可提供稳定服务，但是它们被调用时消耗的诸如成本、响应时间等可能不同，因此为了选取最优的第三方接口，则选取优先级最高的目标第三方接口为针对调用请求的目标第三方接口。

步骤三、调用所选取的目标第三方接口。

在选取出针对调用请求的目标第三方接口，则说明该目标第三方接口是当前可调用接口中最符合调用需求的第三方接口，故直接调用该被选取的目标第三方接口即可。

本发明实施例提供的第三方接口调用方法，当需要调用第三方接口为目标任务服务时，确定适用于目标任务的各第三方接口的优先级顺序以及各第三方接口的提供稳定服务的目标服务次数。在单位时间内，每接收一次目标任务的调用请求均执行：确定当前无异常的第三方接口为目标第三方接口，从单位时间内累计调用次数未达到对应的目标服务次数的目标第三方接口中，选取优先级最高的目标第三方接口为针对调用请求的目标第三方接口，调用所选取的目标第三方接口。可见，本发明实施例提供的方案当存在目标任务的调用请求时，能够在当前无异常情况的第三方接口中根据各第三方接口的优先级顺序和目标服务次数来确定针对调用请求的第三方接口，因此在调用第三方接口为目标任务服务时，能够在最大限度节约调用成本的同时，保证调用服务的稳定性、性能及吞吐能力。

进一步的，根据图1所示的方法，本发明的另一个实施例还提供了一种第三方接口调用方法，如图2所示，该方法主要包括：

201、确定适用于目标任务的各第三方接口的优先级顺序以及各所述第三方接口的目标服务次数，其中，所述目标服务次数表征对应的第三方接口单位时间内能够提供稳定服务的理想次数。

202、在单位时间内，每接收一次所述目标任务的调用请求均执行：确定当前无异常的第三方接口为目标第三方接口。

若当前存在无异常的第三方接口，则说明存在可调用的第三方接口，直接将当前无异常的第三方接口确定为目标第三方接口。

若当前不存在无异常的第三方接口，则说明第三方接口均异常，当前不存在可调用的第三方接口，此时为了保证目标任务可继续进行，则需要告警，以使业务人员基于告警，进行异常处理。

203、确定各所述第三方接口的累计调用次数是否均达到对应的目标服务次数；若否，执行204；若是，执行205。

若各第三方接口中存在有累计调用次数未达到对应的目标服务次数的目标第三方接口，则说明还存在能够提供稳定服务的第三方接口，则执行步骤204即可。

若确定各第三方接口的累计调用次数均达到对应的目标服务次数，则说明各第三方接口在当前单位时间内能够提供较为稳定服务的次数已经耗尽，为了继续维持第三方接口提供服务时的稳定性，则执行步骤205。

204、从所述单位时间内累计调用次数未达到对应的目标服务次数的目标第三方接口中，选取优先级最高的目标第三方接口为针对所述调用请求的目标第三方接口，并执行208。

单位时间内累计调用次数未达到对应的目标服务次数的目标第三方接口，均为当前能够提供稳定服务的第三方接口。虽然这些第三方接口当前都可提供稳定服务，但是它们被调用时消耗的诸如成本、响应时间等可能不同，因此为了选取最优的第三方接口，则选取优先级最高的目标第三方接口为针对调用请求的目标第三方接口。

205、确定上一次调用请求的目标第三方接口是否是优先级最低的第三方接口，执行206或207。

为了继续维持第三方接口提供服务时的稳定性，在各第三方接口的累计调用次数均达到对应的目标服务次数时，需要分散各第三方接口的调用压力。该分散压力的做法为在各第三方接口的累计调用次数均达到对应的目标服务次数时，每一个第三方接口被调用一次后，由位于其优先级下一位的第三方接口进行下一次调用。

206、若是优先级最低的第三方接口，确定各所述目标第三方接口中优先级最高的目标第三方接口为针对所述调用请求的目标第三方接口，并执行208。

若确定上一次调用请求的目标第三方接口是优先级最低的第三方接口，确定各目标第三方接口中优先级最高的目标第三方接口为针对调用请求的目标第三方接口。

207、若不是优先级最低的第三方接口，确定优先级位于上一次调用请求的目标第三方接口下一位的目标第三方接口为针对所述调用请求的目标第三方接口。

208、调用所选取的目标第三方接口。

进一步的，根据图1和图2所示的方法，下面提供一个具体实施例，对第三方接口调用方法进行具体说明：

本实施例的具体应用场景为：目标任务A需要依赖第三方提供接口服务，其适用的第三方接口如下：第三方接口A，服务价格1元，目标服务次数500次，响应耗时300ms；第三方接口B，服务价格1.5元，目标服务次数700次，响应耗时250ms；第三方接口C，服务价格1.5元，目标服务次数300次,响应耗时400ms。

综合考虑成本、稳定性及服务能力，为适用于目标任务A的各第三方接口确定一个优先级顺序。例如上述场景中，优先级排序时综合考虑了服务价格和额定服务次数，给成本低廉、服务能力也不差的第三方接口A的优先级定为1，成本较高、服务能力出色的第三方接口B的优先级定为2，成本及服务能力均垫底的第三方接口C的优先级定为3。则优先级从高到低的顺序为：第三方接口A，第三方接口B，第三方接口C。

在确定各第三方接口的优先级排序后，可针对目标任务进行第三方接口的绑定。目标任务A绑定调用接口配置{"1":{"tps":"500","interface":"第三方接口A"},"2":{"tps":"700","interface":"第三方接口B"},"3":{"tps":"300","interface":"第三方接口C"}}，将该配置持久化至mysql或redis中，以供调用第三方接口时使用。需要说明的是，配置中的1、2、3表征接口的优先级顺序，tps表征第三方接口当前无异常处于可调用状态。

为了避免调用异常的第三方接口提供服务，则需要对每一个第三方接口进行故障配置：针对每个第三方接口绑定故障配置{"20s":{"第三方接口A":"30","第三方接口B":"30"},"1min":{"第三方接口C":"20"}}，配置的含义为：第三方接口A、第三方接口B的配置阈值都为20s内30次，若第三方接口A在20s内出现30次异常，则认定为第三方接口A故障，同理，第三方接口B在20s内出现30次异常，则认定第三方接口B故障。第三方接口C的配置阈值为1min内20次，若第三方接口C在1min内出现20次异常，则认定第三方接口C故障。将该配置持久化至mysql或redis数据库中。当任一第三方接口异常时，则将其记录到设定的故障文本中，故障文本中记录有当前异常的第三方接口，若记录异常的第三方接口排除异常后，其将从该故障列表中剔除。也就是说，故障文本中的第三方接口随着第三方接口的状态发生变动。当任一第三方接口记录在故障列表中时，则会将其对应配置中的tps修改为0，说明其当前不能被调用。

当接收到一次目标任务A的调用请求时，确定上述的三个第三方接口均无异常，则将上述的三个第三方接口均确定为目标第三方接口。当前单位时间内第三方接口A的累计调用次数已达到500次，而第三方接口B和第三方接口C的累计调用次数均未到其各自的目标服务次数，因此选取第三方接口B和第三方接口C中优先级最高的第三方接口B为针对调用请求的目标第三方接口，调用第三方接口B即可。

进一步的，依据上述方法实施例，本发明的另一个实施例还提供了一种第三方接口调用装置，如图3所示，所述装置包括：

确定单元31，用于确定适用于目标任务的各第三方接口的优先级顺序以及各所述第三方接口的目标服务次数，其中，所述目标服务次数表征对应的第三方接口单位时间内能够提供稳定服务的理想次数；

调用单元32，用于在单位时间内，每接收一次所述目标任务的调用请求均执行：确定当前无异常的第三方接口为目标第三方接口，从所述单位时间内累计调用次数未达到对应的目标服务次数的目标第三方接口中，选取优先级最高的目标第三方接口为针对所述调用请求的目标第三方接口，调用所选取的目标第三方接口。

本发明实施例提供的第三方接口调用装置，当需要调用第三方接口为目标任务服务时，确定适用于目标任务的各第三方接口的优先级顺序以及各第三方接口的提供稳定服务的目标服务次数。在单位时间内，每接收一次目标任务的调用请求均执行：确定当前无异常的第三方接口为目标第三方接口，从单位时间内累计调用次数未达到对应的目标服务次数的目标第三方接口中，选取优先级最高的目标第三方接口为针对调用请求的目标第三方接口，调用所选取的目标第三方接口。可见，本发明实施例提供的方案当存在目标任务的调用请求时，能够在当前无异常情况的第三方接口中根据各第三方接口的优先级顺序和目标服务次数来确定针对调用请求的第三方接口，因此在调用第三方接口为目标任务服务时，能够在最大限度节约调用成本的同时，保证调用服务的稳定性、性能及吞吐能力。

可选的，如图4所示，所述装置还包括：

判断单元33，用于在调用单元32从所述单位时间内累计调用次数未达到对应的目标服务次数的目标第三方接口中，选取优先级最高的目标第三方接口为针对所述调用请求的目标第三方接口之前，确定各所述第三方接口的累计调用次数是否均达到对应的目标服务次数；若否，触发调用单元32从所述单位时间内累计调用次数未达到对应的目标服务次数的目标第三方接口中，选取优先级最高的目标第三方接口为针对所述调用请求的目标第三方接口。

可选的，如图4所示，所述装置还包括：

选定单元34，用于若判断单元33确定各所述第三方接口的累计调用次数均达到对应的目标服务次数，则确定上一次调用请求的目标第三方接口是否是优先级最低的第三方接口；若是优先级最低的第三方接口，确定各所述目标第三方接口中优先级最高的目标第三方接口为针对所述调用请求的目标第三方接口；若不是优先级最低的第三方接口，确定优先级位于上一次调用请求的目标第三方接口下一位的目标第三方接口为针对所述调用请求的目标第三方接口。

可选的，如图4所示，调用单元32，具体用于将未记录在故障文本中的第三方接口，确定为所述目标第三方接口，其中，所述故障文本中记录有在第一预设时长内出现异常的次数达到预设次数阈值的第三方接口。

可选的，如图4所示，所述装置还包括：

删除单元35，用于监测记录在故障文本中的各第三方接口在其各自对应的第二预设时长内是否排除异常；将排除异常的第三方接口从所述故障文本中删除。

可选的，如图4所示，确定单元31，具体用于根据各所述第三方接口的服务参数，确定各所述第三方接口的优先级顺序，其中，所述服务参数包括如下中的至少一种：响应耗时、目标服务次数、服务价格。

可选的，如图4所示，所述装置还包括：

告警单元36，用于若调用单元32确定当前不存在无异常的第三方接口，告警。

本发明实施例提供的第三方接口调用装置中，各个功能模块运行过程中所采用的方法详解可以参见图1或图2方法实施例的对应方法详解，在此不再赘述。

进一步的，依据上述实施例，本发明的另一个实施例还提供了一种计算机可读存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行图1或图2所述的第三方接口调用方法。

进一步的，依据上述实施例，本发明的另一个实施例还提供了一种存储管理设备，所述存储管理设备包括：

存储器，用于存储程序；

处理器，耦合至所述存储器，用于运行所述程序以执行图1或图2所述的第三方接口调用方法。

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

可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

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

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的深度神经网络模型的运行方法、装置及框架中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。