一种服务调用方法、装置、计算机设备及存储介质与流程

1.本技术涉及计算机技术领域，尤其涉及一种服务调用方法、装置、计算机设备及存储介质。


背景技术：

2.任务流是十分常见的一种任务组织形式，如订单系统、审批系统，都是常见的任务流，在任务流转的过程中，通常会涉及对服务的调用，对于服务调用方来说，服务调用的目的体现在对服务功能的消费上，通过相应服务的调用，可以实现特定场景下的业务需求，例如在视频处理的场景下需要调用语音识别服务对视频中的语音进行处理。
3.当前，在各种业务场景涉及不同类型的服务调用，来满足不同的业务需求，其中人工智能服务的应用也显现出卓越的服务性能。因此，对于任务流中的服务调用的实现方式仍旧是目前的研究热点。


技术实现要素：

4.本技术实施例提供一种服务调用方法、装置、计算机设备及存储介质，可以通过配置文件高效地调用服务，以及通过回包校验结果准确确定服务的调用结果。
5.本技术实施例一方面提供了一种服务调用方法，包括：
6.获取待处理任务对应的配置文件，配置文件包括一个或多个组件标识，每一个组件标识为服务对应的组件的标识；
7.从一个或多个组件标识中确定目标组件标识，并获取目标组件标识所对应组件的组件配置信息，组件配置信息包括目标服务的调用参考信息；
8.根据调用参考信息调用目标服务，得到目标服务回包数据；
9.对目标服务回包数据进行回包校验，根据回包校验结果确定目标服务的调用结果。
10.本技术实施例一方面提供了一种服务调用装置，包括：
11.获取模块，用于获取待处理任务对应的配置文件，配置文件包括一个或多个组件标识，每一个组件标识为服务对应的组件的标识；
12.确定模块，用于从一个或多个组件标识中确定目标组件标识，并获取目标组件标识所对应组件的组件配置信息，组件配置信息包括目标服务的调用参考信息；
13.调用模块，用于根据调用参考信息调用目标服务，得到目标服务回包数据；
14.校验模块，用于对目标服务回包数据进行回包校验，根据回包校验结果确定目标服务的调用结果。
15.本技术实施例一方面提供了一种计算机设备，包括：处理器、存储器以及网络接口；处理器与存储器、网络接口相连，其中，网络接口用于提供网络通信功能，存储器用于存储程序代码，处理器用于调用程序代码，以执行本技术实施例中的服务调用方法。
16.本技术实施例一方面提供了一种计算机可读存储介质，计算机可读存储介质存储
有计算机程序，计算机程序包括程序指令，程序指令当被处理器执行时，执行本技术实施例中的服务调用方法。
17.相应的，本技术实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本技术实施例中一方面提供的服务调用方法。
18.在本技术实施例中，通过配置文件中包括的组件标识获取组件配置信息，并根据组件配置信息包括的调用参考信息调用服务，进而得到服务回包数据，并对其进行校验，得到服务调用的结果。其中，配置文件是描述服务调用逻辑的配置化标准语言，关注输入输出流转配置，不需要关心具体的服务调用地址以及调用协议。通过配置文件中可读性高的组件标识来获取组件配置信息，达到调用相应服务的目的，这样降低了用户设计服务调用的业务逻辑的复杂度，并且该配置文件兼容不同协议下的服务调用，具备统一规范地编排规则，适用范围广泛，通用性高，此外，通过对服务回包数据进行校验处理，可以对服务调用进行进一步处理，保证服务调用的准确度。
附图说明
19.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
20.图1是本技术实施例提供的一种状态机的示意图；
21.图2是本技术实施例提供的一种服务调用系统的网络架构图；
22.图3是本技术实施例提供的一种服务调用系统的业务逻辑架构图；
23.图4是本技术实施例提供的一种组件创建方法的流程示意图；
24.图5是本技术实施例提供的一种自定义组件创建界面的界面示意图；
25.图6是本技术实施例提供的一种组件管理界面的界面示意图；
26.图7是本技术实施例提供的一种服务调用方法的流程示意图；
27.图8是本技术实施例提供的一种模型组件注册的流程示意图；
28.图9是本技术实施例提供的一种配置文件的内容示意图；
29.图10是本技术实施例提供的一种调用模型服务的流程示意图；
30.图11是本技术实施例提供的一种单次组件服务调用的流程示意图；
31.图12是本技术实施例提供的一种服务调用方法的流程示意图；
32.图13是本技术实施例提供的一种数据总线的示意图；
33.图14是本技术实施例提供的一种服务调用方法的流程示意图；
34.图15是本技术实施例提供的一种请求实例类型的示意图；
35.图16是本技术实施例提供的一种服务调用装置的结构示意图；
36.图17是本技术实施例提供的一种计算机设备的结构示意图。
具体实施方式
37.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
38.为便于理解，下面先对本技术可能涉及的关键术语进行解释。
39.状态机：描述有限个状态以及在这些状态之间的转移和动作等行为的模型。
40.状态：状态机的每一个步骤也称之为状态，状态会根据输入来执行响应操作，并将输出传递给下一个状态。状态的类型普遍有：task(任务)、pass(传递)、wait(等待)、choice(选择)、parallel(并行)、foreach(循环)等；其中task类型是最常用的状态，用来描述执行一些工作，比如执行本地脚本、调用各种云服务等。
41.状态机模版：指定是通过代码语言(如json或yaml格式等语言)，描述整个状态机的流程，简称模版。
42.组件：表示某个服务的接口信息，也可称为服务接口或服务组件，通过调用服务接口(或组件)可以实现对服务的调用。
43.函数服务：根据标准化python模板通过服务框架自动生成的可提供单接口的服务，可注册成组件。
44.ai模板服务：根据状态机模板通过服务框架自动生成的可提供单接口的服务，可注册成组件。
45.resource：一种可以标志组件的唯一id。
46.上下文对象(context)：用于每个状态之间流转的数据共享存储。
47.pb：指google的protobuf，一种数据传输协议，全称protocol buffers，是一种与平台无关、语言无关、可扩展且轻便高效的二进制编码的数据序列化协议，可用于网络通讯和数据存储。
48.rpc：remote procedure call，远程过程调用。可理解为一个节点请求另一个节点提供的服务。
49.grpc：一种高性能、开源且通用的rpc框架，可以使用protobuf进行数据编码。
50.api：application programming interface，应用程序接口，是一些预先定义的接口(如函数、http接口)，或指软件系统不同组成部分衔接的约定。
51.对于上述关键术语中状态机的具体理解，请参见图1，是本技术实施例提供的一种状态机的示意图，如图1所示，该状态机所实现的主要功能是对视频进行处理，图1中示出的每一个步骤即一个状态，如预处理、视频截帧、光学字符识别(optical character recognition，ocr)、音频转文字、自然语言处理(natural language processing，nlp)以及合并处理，且均是任务类型的状态。其中，预处理可以通过调用云函数(serverless cloud function，scf)服务对视频进行视频镜头分割、关键帧提取以及特征提取的处理；视频截帧可以通过调用视频处理服务对视频进行截帧处理，再通过光学字符识别对截帧处理后的视频内容进行文字识别，得到文本数据；音频转文字可以通过调用语音识别服务，如自动语音识别(automatic speech recognition，asr)将视频中携带的语音数据转换为文本数据；自然语言处理可以通过调用自然语言处理服务，对光学字符识别以及音频转文字得到的文本
数据进行相关处理，如进行情感倾向分析、抽取评论观点等；合并存储将自然语言处理步骤得到的处理结果存储到数据库中。
52.本技术提供的服务调用方案通过状态机语言(即配置文件)描述服务调用逻辑，该配置文件关注输入输出的流转配置，在服务调用中通过服务对应组件的组件标识，也即唯一代表具体服务的接口信息来指定调用的服务，这样可以提高用户操作的简便性，使得整个服务调用逻辑的可读性更强。由于组件是表示服务的接口信息，对组件的调用就相当于对服务的调用，这些组件是预先创建好的，并且相关组件配置信息存储在数据库中，通过组件配置信息调用服务并对调用服务返回的服务数据回包进行校验处理，可以保证服务调用的准确性。
53.可以看出，本技术实施例提供的方案属于云应用下的人工智能云服务，所谓人工智能云服务，一般也被称作是aiaas(ai as a service，中文为“ai即服务”)。这是目前主流的一种人工智能平台的服务方式，具体来说aiaas平台会把几类常见的ai服务进行拆分，并在云端提供独立或者打包的服务。这种服务模式类似于开了一个ai主题商城：所有的开发者都可以通过api接口的方式来接入使用平台提供的一种或者是多种人工智能服务，部分资深的开发者还可以使用平台提供的ai框架和ai基础设施来部署和运维自已专属的云人工智能服务。如通过配置文件中的组件标识调用ai组件服务。
54.请参见图2，是本技术实施例提供的一种服务调用系统的架构图，如图2所示，该系统架构包括用户终端201、业务服务器202、数据库203、任务调度器204、任务执行器205。其中，用户终端201和业务服务器202之间可以通过有线或无线通信方式进行直接或间接连接，并进行数据交互。任务调度器204可以从业务服务器202中获取待处理任务，并给待处理任务分配对应的任务执行器205，数据库203可以存储业务服务器产生的服务数据。下面对系统架构中包括的各实体设备的功能进行详细介绍。
55.用户终端201可以运行功能客户端，用户可以在该功能客户端上用状态机语言(如json语言，一种配置化标准描述的语言)编写配置文件，实现对组件的编排。在配置文件中可以描述不同服务的调用逻辑。用户还可以在该功能客户端上对组件或服务进行管理，如在组件管理界面对已经创建的组件进行修改或删除等，在任务管理界面查看正在执行的任务进度或查看待处理的任务，在新建组件界面输入相关组件信息并创建组件等等。用户终端201也可以将编写完成的配置文件发布为相应的待处理任务或待调用服务，并将待处理任务或待调用服务发送给业务服务器202，由业务服务器202统一管理，或者由业务服务器202接收用户终端201上编写完成的配置文件，并将其发布为相应的待处理任务或待调用服务。需要说明的是，将配置文件发布为待调用服务通常是因为该配置文件中可以封装完整地服务调用逻辑，其中涉及多种服务调用，将该待调用服务注册为组件，用户通过定义的语法规范，使用配置文件即可表示一次请求调用。可以在其他多个配置文件中重复使用，并且在使用时只需要组件标识就可以实现多种服务调用，提高配置的效率，这一点和封装功能函数的代码类似，将功能模块化，可以提高代码的复用性和简洁性。
56.业务服务器202可以接收用户终端201发送过来的配置文件或者待处理任务和待调用服务，通过任务调度器204将待处理任务分配给相应的任务执行器205。业务服务器202还可以接收用户终端201的组件注册请求，根据该组件注册请求创建新的组件，并赋予每个组件一个唯一的组件标识，如resource，同时将组件注册得到的组件配置信息存储到数据
库203中。业务服务器202还可以接收任务执行器205对组件配置信息的查询请求，通过对组件标识进行解析，从数据库203中获取相应的组件配置信息，生成请求实例。
57.数据库203可以用于存储组件配置信息或服务调用结果数据，也可以接收业务服务器202发送的数据获取请求，将组件配置信息发送给业务服务器202。
58.任务调度器204可以从业务服务器202中获取待处理任务对应的配置文件，然后将其发送给合适的任务执行器205，任务执行器205在获取待处理任务对应的配置文件之后，会将其中的组件标识发送给业务服务器202，由业务服务器202查询组件，并将该组件标识对应组件的组件配置信息发送给任务执行器205，任务执行器205根据该组件配置信息中的调用参考信息去提供实际服务的一方请求服务的调用，拿到服务回包数据并对其进行处理，如校验，得到最终的输出。
59.上述业务服务器202、数据库203、任务调度器204、任务执行器205均可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。用户终端201可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。
60.请参见图3，是本技术实施例一种服务调用系统的业务逻辑架构图，如图3所示，包括接入层301、业务层302和存储层303，其中接入层301通过api网关和业务层302进行网络通信，可以通过该api网关向业务层302发起注册组件的请求以及启动任务的请求；业务层302包括组件控制层3021、组件执行层3022以及任务调度执行层3023，其中，组件控制层3021包括组件注册、组件路由、组件适配、组件标识解析器，组件执行层3022包括多种服务，如函数服务、模型服务、ai服务、自定义服务等，任务调度执行层3023包括调度器和执行器。其中，组件控制层3021和组件执行层3022对应的内容可以部署在图2所示的业务服务器202中，任务调度执行层3023中包括的调度器对应图2所示的任务调度器204，执行器对应如图2所示的任务执行器205，存储层303中包括的数据库可以部署在图2所示的数据库203中。
61.针对各功能层之间的逻辑关系和对应的功能，下面将进行详细解释。
62.接入层301中的api网关可以是具备组件注册和组件编排功能客户端提供的，当用户在该客户端触发相应功能控件，客户端可以通过该api网关和业务层302建立连接，并进行通信，实现数据交互。如注册组件(即创建组件)时向组件控制层3021发起组件注册请求，组件控制层3021会根据具体地逻辑流程来创建用户指定的组件，或者启动已编排好的任务，向任务调度执行层3023发起启动任务请求，任务调度执行层3023同样也有相应的逻辑流程来对任务进行处理，在此不做说明。
63.业务层302包括的三个部分有不同的功能，互相之间也有数据的交互。具体地，当用户通过网关的api请求来注册组件，也即组件控制层3021接收到接入层301的组件注册请求时，首先会利用组件适配器适配不同类型的组件，可以包括四种类型的组件，分别是函数服务组件(将一段脚本代码，如python脚本代码执行逻辑的服务注册的组件)、模型组件(服务调用中涉及到的算法服务注册的组件)、ai服务组件(将一段以及编排好的任务逻辑注册的组件)、自定义服务组件(用户实现的任意服务注册的组件)。组件适配器可以通过用户组件注册请求中包括的请求信息，如模型服务标识等来确定用户请求注册的具体是哪一种组件，然后利用组件注册给每个组件赋予一个唯一的组件标识，如字符串id，并将基本的组件
信息存储到数据库中，如mysql、redis等，对于数据库的包括的类型在此不做限制。
64.当用户通过网关的api请求来启动任务时，任务调度执行层3023会接收到接入层301的启动任务请求，通过调度器将任务调度给具体的执行器，执行器进行组件请求，通过任务中包括的组件标识去组件控制层3021查询组件，组件控制层3021从存储层中获取具体的组件信息并发送给执行器，在这个过程中，会先通过组件标识向组件控制层请求解析，即组件控制层3021首先会利用组件标识解析器将执行器给到的组件标识进行解析，得到如组件调用协议、数据传输格式这样的信息，由于每个服务均可能有多个实例，执行器进行组件请求时，组件控制层3021会将本次调用最合适的实例返回给执行器以供调用，这也是组件路由的过程，可以实现负载均衡。示例的，模型服务中的ocr算法服务有多个实例，也就是ocr算法有多个副本，每个副本的算法实现逻辑是相同的，对应的接口信息(即组件)是相同的，只是组件的路由地址不同，通过调用不同路由地址的ocr算法，可以避免不同任务一直调用同一个算法副本，增加服务调用的灵活性和可用性。经过组件路由获取到对应服务的最佳实例，构成完整的组件信息，执行器根据该组件信息就可以向组件执行层3022发起调用服务的请求，由于组件执行层3022是每个实际的组件服务，不同的组件服务均有不同的实例，因此组件执行层3022中是可以匹配到组件信息中所需要的调用的实例。
65.这里需要说明的是，组件执行层3022中函数服务和ai服务均为业务封装，模型服务和自定义服务本质上均为实际服务，和业务服务一起部署在一个集群内。另外，前述提及的“组件服务”和“服务”是相同含义的表达，“组件信息”和“组件配置信息”也是相同的表达，用词上可以互相替代，针对上述内容也可简要概括为当用户启动任务后，调度器会将任务调度到一个合适的执行器中，然后通过串联不同的组件服务调用来满足一定的业务需求，每当执行组件服务调用时，先去组件控制层3021获取基本的组件信息，并通过组件路由拿到最佳实例，然后去组件执行层3022调用服务。
66.存储层303用于存储注册组件时组件控制层3021发送过来的基本组件信息，以及在组件查询时，组件控制层3021会从存储层303中获取组件信息，以协助任务执行层3023根据该组件信息从组件执行层3022中调用服务。
67.可以发现，上述针对服务调用的业务逻辑架构图包括组件注册和组件服务调用这两个主要部分，通过组件注册可以将不同服务注册为组件，利用组件标识来获取组件信息进而调用服务，通过组件增加了服务调用的便捷性以及组件信息的可复用性，为用户或开发人员简化了业务逻辑的实现流程。另外，在调用时根据该组件对应的组件信息可以匹配合适的实例，实现调用过程中的负载均衡。采用本技术提供的业务逻辑架构图可以兼容对不同类型的服务调用，提升不同业务场景的服务调用效率。
68.针对上述组件注册的可视化过程，请参见图4，是本技术实施例提供的一种组件创建方法的流程示意图，本实施例以该方法的执行主体为服务器进行说明。其中，该组件创建方法至少可以包括以下步骤s401～s404：
69.s401，控制用户终端显示组件创建界面，组件创建界面包括与待创建组件相关联的一个或多个关联参数输入框。
70.在一实施例中，服务器可以控制用户终端显示组件创建界面，该组件创建界面可以是自定义组件的组件创建界面，用户可以该组件创建界面包括的一个或多个关联参数输入框中输入相应数据。请参见图5，是本技术实施例提供的一种自定义组件创建界面的界面
示意图，如图5所示，该自定义组件创建界面包括组件英文名称、组件中文名称、服务英文名称、调用服务ip端口、调用服务url、超时时间、返回码(returncode)的参数输入框，另外还包括请求方法、接口类型、数据类型这些关联参数选项。在上述关联参数输入框的下方，还可以显示对应关联参数输入框的输入规范和输入示例，以帮助用户准确地输入关联参数，这些关联参数可以构成组件配置信息，在组件注册成功时保存在数据库中。可选的，该组件创建界面还可以是针对其他服务，如模型服务、ai服务创建组建的界面，在这种方式下，可以直接导入服务，获取相应的信息。在此对组件创建界面不做限制。
71.s402，获取针对一个或多个关联参数输入框所输入的数据。
72.在一实施例中，用户可以在这些输入框中按照相应输入规范或输入示例输入数据，或者这些输入框中的数据是导入相应服务后自动生成的，这样服务器可以获取到输入的数据，将其作为组件配置信息。
73.s403，根据针对一个或多个关联参数输入框所输入的数据创建组件。
74.在一实施例中，在获取到关联参数输入框中输入相应数据之后，服务器可以响应一定的触发操作来创建组件，在此对具体的触发操作不做限定。
75.s404，控制用户终端显示组件管理界面，并控制用户终端在组件管理界面中展示创建的组件的关联参数。
76.在一实施例中，服务器可以控制用户终端显示组件管理界面，请参见图6，是本技术实施例提供的一种组件管理界面的界面示意图，在该组件管理界面上，可以显示各种类型的组件以及组件信息，还可以显示组件创建的时间，以及对已经创建的组件进行编辑或删除。此外，从该组件管理界面可以通过触发新建组件进入组件创建界面。
77.在本技术实施例提供的组件创建方案，可以通过在可视化界面实现组件的创建，提高了组件创建的效率，其中自定义组件可以将用户定义的任意服务注册为组件，实现各式各样服务，使得组件可扩展性更强。此外，通过组件管理界面对已创建的组件进行集中化管理，可以实现组件的统一部署，提升智能化效果。
78.需要说明的是，上述示出的可视化界面创建组件只是录入组件的一种方式，还可以包括通过编写代码的方式创建组件，如函数服务组件是根据提交的代码文件生成的等等，对于组件创建的方式在本技术中不做限制。虽然组件录入的方式可以不同，但配置文件对每个组件的处理可以是相同的。
79.上述创建组件的方法可以是在人工智能服务平台上实现的，在该人工智能平台可以如图6所示，除了组件管理、模板管理、任务管理、服务管理，还可以包括应用中心、算法仓库、数据中心、管理中心等菜单栏，基于该人工智能服务平台的提供的相应功能，可以实现对组件的注册、编排以及组件服务的调用，进而为用户提供多算法融合调度、大数据规范化处理等功能。其中，ai任务即任务管理、ai服务即服务管理、ai模板即模板管理，均属于ai工作室中的内容，其中ai工作室各个部分的功能如下所述。
80.组件管理主要是用来集成各类可调用组件，丰富编排引擎的能力。组件可以看做是描述一个web服务接口；一个算法服务的接口等，因此组件管理主要存储组件的协议、参数和调用方式等信息。模版管理的核心功能是对状态机模版编排，前端支持拖拽或直接编写状态流程语言，有了模版后就可以选择相应模版创建任务或服务。任务管理是可以将编排后的状态机模版，可以发布成分布式任务，任务执行的过程中就会按照顺序调用模板中
配置的请求。服务管理可以将编排后的状态机模版，可以发布成服务，然后用户就可以通过api接口直接调用，可以当作是一个web服务。
81.进一步地，请参见图7，图7是本技术实施例提供的一种服务调用方法的流程示意图。本实施例以该方法的执行主体为服务器(如图2所示的任务执行器205)进行说明。其中，该服务调用方法至少可以包括以下步骤s701～s704：
82.s701，获取待处理任务对应的配置文件，配置文件包括一个或多个组件标识，每一个组件标识为服务对应的组件的标识。
83.在一实施例中，待处理任务可以是任一状态机模板创建的分布式任务，它在执行的过程中会按照逻辑关系调用状态机模板中配置的请求。其中，状态机模板是通过代码语言(如json语言，也可视为状态机语言)描述的有限个状态的流程，在本技术实施例中，其包括多个任务节点，每个任务节点可以对应一种服务，相应地，一个状态机模板也可以理解为一个配置文件，可以用于指示服务调用逻辑，即服务调用的先后顺序，对于状态机模板而言，也即任务节点的执行逻辑。在配置文件中包括一个或多个组件标识即是服务对应组件的标识，每个服务可以通过接口标识和服务标识来唯一确定，每种服务可以对应多个服务实例，如两个相同的ocr算法服务对应组件的路由地址不同，代表两个服务实例。这里的服务包括但不限于前述提及的函数服务、模型服务、ai服务、自定义服务这几种服务，相应的组件即函数服务组件、模型组件、ai服务组件、自定义组件。这些组件可以是预先注册后存储到服务端中的组件，每个组件有分配唯一的组件标识，该组件标识的定义可以支持多种请求协议和数据格式。对于组件注册可以基于图3提供的服务调用系统实现，请参见图8，是本技术实施例提供的一种模型组件注册的流程示意图，如图8所示，首先用户可以通过控制台或者通过接口(即api网关)来创建组件，用户新建模型组件之后，控制台或者api网关通过模型组件标识和接口标识向组件控制层中的组件适配器请求注册，当组件适配器发现是模型组件，会请求算法仓库(也即模型管理ems服务)，根据模型服务标识和接口标识获取服务信息。然后将获得的服务信息和接口信息作为完整的注册信息给到组件控制层的组件注册，并分配唯一表示该模型组件的组件标识，之后可以将注册信息中一些关键信息，如服务调用地址、服务端口、服务请求入参、请求出参、请求回包校验码、超时时间等必要的信息存储到数据库，数据库向组件控制层的组件注册发送存储成功的消息，进而组件注册能够给控制台或api网关发送注册成功的消息，最终能够告知用户注册成功。
84.上述是以模型服务组件作为示例进行说明，可以理解为一种原子服务组件，即提供单一的服务功能，也可以是对不同服务提供者的服务功能进行组合和封装的组件。其他服务组件的注册不需要和算法仓库进行交互获取组件的注册信息，具体的，若是函数服务，则组件适配器会自动获取函数服务的组件信息，并将脚本代码存储起来；若是ai服务，则组件适配器会自动获取服务引擎相关信息；若是自定义组件，则需要用户填写组件的关键信息，组件适配器直接就能够从通过控制台从用户终端获取。该组件注册对应的界面可以参见图4对应实施例的内容，在此不做赘述。
85.在本技术实施例中，组件标识可以采用例如resource的五段式定义，该定义中包括请求协议、数据传输格式、组件类型、服务名、组件名，这些基本的信息标识了具体的服务和组件，根据这些信息可以在数据库中唯一检索到对应组件其他相关信息，以进行后续的处理。对于resource定义的具体示例可参见如下内容。
86.resource：http::json::algorithm::yt-server-video-snippet-cut::videolenscut，其中第一段中的http为协议名，除了http，还可以支持grpc或trpc(一种基于云原生的思想打造的一套高性能并支持多语言的rpc开发框架)等，第二段json表示数据传输格式，除此还支持pb，第三段algorithm表示组件类型为模型组件，还支持表示函数服务组件的function、表示自定义组件的customized以及ai服务组件，第四段yt-server-video-snippet-cut表示服务名，可以由用户自定义或根据开发者提供的服务名来生成，第五段videolenscut表示接口名，即组件名，同样也可以由用户自定义或开发者提供的接口名来生成。可以发现，resource支持各种请求协议，包括http json、http pb、grpc、grpc服务端流式与双向流式、以及不同组件录入，如自有函数服务组件与ai服务组件等，resource是一种声明式的定义，其中并未涉及具体的调用地址，而是以直观明了的方式体现需要调用的组件服务以及对应的调用形式，是一种可读性比较高的方式。需要说明的是，对于组件标识也可以用字符串id来替代resource表示组件的方式。
87.为了更好地理解上述内容，以机动车识别作为示例。将机动车识别这个过程作为待处理任务，机动车识别任务中包括机动车监控设备抓拍车辆、人车检测跟踪服务、机动车属性识别服务、车辆识别结果处理、车辆警告等必须执行的步骤，每一个步骤都对应一个状态，也可以视为一个任务节点，都需要调用相应服务来实现指定的功能。组件作为服务的接口信息，有唯一的组件标识来表明，通过组件标识获取组件的组件信息也就可以调用服务，实质上，调用服务是通过调用服务接口(即组件)来实现的。机动车识别任务的整个过程可以是通过编写配置文件的方式来规定步骤之间的顺序，如人车检测跟踪服务、机动车识别服务等服务对应组件的组件标识就可以按照相应执行顺序依次出现在配置文件中。其中包括服务可以是通过如上述示出的resource中具体的服务名和组件名来确定。对于配置文件的内容示例可以参见图9，是针对一个视频做人脸识别的结构化功能的配置文件，其中涉及多个任务节点，每个任务节点下有相应的resource标识组件、next字段指示当前节点的下游节点对应的服务，以及其他参数的一些配置。可以发现，这些任务节点把不同的服务串联起来，是一种具体的业务逻辑，其中对于配置文件中具体代码语言在此不做限制。
88.s702，从一个或多个组件标识中确定目标组件标识，并获取目标组件标识所对应组件的组件配置信息，组件配置信息包括目标服务的调用参考信息。
89.在一实施例中，一个或多个组件标识对应组件有先后执行顺序，这里的目标组件标识可以是任一个组件标识，在其之前或之后还有组件标识表示调用对应服务。如前述示例的机动车识别步骤中包括机动车监控设备抓拍车辆、人车检测跟踪服务、机动车属性识别服务、车辆识别结果处理、车辆警告都有对应的组件标识，若目标组件标识是机动车属性识别服务对应的组件标识，那么按照执行的逻辑顺序，在目标组件标识之前还有人车检测跟踪服务对应的组件标识，其之后还有车辆识别结果处理对应的组件标识。目标服务可以是根据组件标识确定的一种服务，在调用该服务时，可以利用组件路由为该服务匹配的最佳实例，如机动车属性识别服务有a、b、c三个副本，均有相同的识别功能，提供给服务调用方的组件相同，即服务接口相同，但组件的路由地址不同，因此，可以通过组件的路由地址匹配到的最佳实例，如机动车属性识别服务a，实现均衡地服务调用。在任务执行器获取组件配置信息的过程中，业务服务器会解析目标组件标识并从数据库中获取对应组件的组件配置信息，将其发送给任务执行器，组件配置信息中和服务调用相关的信息可以视为调用
参考信息，如服务调用地址、服务端口、服务请求入参、请求出参、请求回包校验码、超时时间等，上述组件配置信息是在组件注册时存储到数据库中的关键信息。
90.需要说明的是，在待处理任务执行过程中，会按照配置文件指示的服务调用逻辑顺序执行，针对配置文件所包括的每一个组件标识，都可以和目标组件标识有相同的处理方式。
91.s703，根据调用参考信息调用目标服务，得到目标服务回包数据。
92.在一实施例中，根据调用参考信息中的服务调用地址，如组件ip、域名或url(uniform resource locator，统一资源定位符)可以唯一确定目标服务，根据服务调用地址对该目标服务进行rpc调用，在具体的目标服务被执行之后，就可以返回该目标服务的处理结果，将其作为目标服务回包数据。示例的，若调用参考信息调用的是人脸识别服务，该服务回包数据中可能包括部分人脸属性值，如年龄、性别、情绪等。该目标服务回包数据可以是相应服务端返回给执行引擎(即任务执行器)的服务回包数据。
93.s704，对目标服务回包数据进行回包校验，根据回包校验结果确定目标服务的调用结果。
94.在一实施例中，对调用目标服务返回的目标服务回包数据进行回包校验，是判断回包是否符合预期或是否需要重试的一种方法，其中，回包校验得到的回包校验结果指示了目标服务是否调用成功的调用结果，根据该调用结果，还可以对该目标服务回包数据进行更进一步地处理来实现数据的流转。
95.上述步骤s701～s704在具体的技术实现中，可以参见图10，是本技术实施例提供的一种调用模型服务的流程示意图。如图10所示，包括执行引擎task state、组件控制层和组件执行层这三者之间的交互，组件执行层可以视为外部服务。具体执行步骤如下：首先，执行引擎通过组件标识请求组件控制层，组件控制层根据组件标识查询详细的组件信息并返回组件信息(例如协议和proto信息等)给执行引擎，然后执行引擎根据输入路径字段(inputpath)和参数字段(parameter)等一些语法描述符来生成并组装请求参数，其中，应用inputpath字段可以对原始输入参数进行筛选，确定所选的内容，应用parameter字段可以进一步处理所选的内容，如添加新值等。通过从组件控制层获取到的调用地址来调用实际的组件服务，接着获得从组件执行层返回的结果，判断回包是否符合预期，是否需要重试，最后通过结果路径(resultpath)和输出路径(outputpath)等一些语法描述符对回包进行处理，生成输出。状态的输出可以是输入的副本、调用目标服务生成的结果或者输入和结果的组合，也就是说使用resultpath可以将任务结果与任务输入组合，或者选择其中之一，作为传递到状态输出的信息，而outputpath是可以将状态输出的一部分传递到下一个状态，这样可以将不需要的信息筛选掉，仅传递需要的信息。需要说明的是，上述内容中涉及的具体语法规则或描述，如inputpath字段只是一种示例方式，对于具体的语法表达在此不做限制。
96.在一实施例中，确定目标服务的调用结果之后可以包括以下任一种处理方式：当调用结果指示目标服务调用失败时，若目标服务的调用失败次数小于或等于调用次数阈值，则在达到调用失败次数所对应的间隔时间时，重新调用目标服务；当确定目标服务调用失败时，若目标服务的调用失败次数大于调用次数阈值，停止调用目标服务。
97.具体地，当调用结果指示目标服务调用失败之后，会启动失败重试机制，也就是说
如果请求后端服务失败或者校验服务回包数据失败，都可以通过该失败重试机制对服务请求进行重试，在重试时会配置以下参数：1)重试次数(即调用次数阈值)，是指目标服务调用失败后对请求后端服务的重试次数；2)失败重试间隔，是指如果多次调用失败，每次重试的间隔时间；3)失败重试间隔时间倍数，是对失败重试间隔的时间设定的一种方式，例如可以配置指数退避的方式，如间隔倍数配置为2，重试间隔配置2秒，则第一次重试时间间隔为2秒，第二次重试时间间隔为4秒，第三次重试时间间隔为8秒，以此类推。上述重试时配置的参数都可以根据用户需求设定，相应的取值在此不做限定。可以理解的是上述失败重试间隔和失败重试间隔时间倍数结合可以构成重试时间间隔，即调用失败次数所对应的间隔时间。若调用失败次数没有达到设定的调用次数阈值，在调用失败后等达到重试的时间间隔就可以对目标服务重新发起调用，这个过程也是对该请求后端服务的重试，但是如果调用失败次数大于重试次数，会停止对该请求的重试。通过这样的方式可以避免在请求调用的过程中频繁触发冲突。
98.在一实施例中，确定目标服务的调用结果之后还可以包括：当所述调用结果指示所述目标服务调用失败时，获取重试错误码；根据所述重试错误码将所述目标服务之后执行的服务进行重定向处理。
99.其中，重试错误码是执行引擎返回，由用户在配置文件中自定义，可以是字符串的表达形式。在状态流转过程中，可参见下述图11，其中任何一个步骤出现错误，如网络传输出错或者回包校验出错，可以通过catch字段捕获该重试错误码，将当前节点指向的下游节点进行重定向处理，即变更当前任务节点指向的下游节点，对应的也就是将原有的目标服务之后执行的服务调整为其他服务，在数据流转时不走之前的下游节点。示例的，若当前节点a至下游节点b之间的服务调用过程中，由于数据总线中的数据不能流转到下游节点b，导致回包校验失败，此时将下游节点b更换为其他下游节点，如节点c，此时数据流转是由当前节点a至下游节点c。作为一种可扩展的内容，还可以在目标服务的调用失败次数大于调用次数阈值后，通过捕获重试错误码将下游节点对应的服务重定向为其他下游节点对应的服务。
100.需要说明的是，上述确定目标服务的调用结果之后的两种处理方式均可以属于失败重试机制中的内容，且均可以通过该重试错误码来启动。
101.综上，本技术实施例至少具备以下优点：
102.通过配置文件指示待处理任务中调用服务的逻辑关系，主要是通过配置文件中可读性和兼容性高的组件标识，降低使用代码对服务调用逻辑编排的复杂度，提高调用不同服务组件的效率。其中，组件标识表示唯一组件并且根据该组件标识能获取到详细的组件配置信息，通过组件配置信息调用组件服务，并根据服务回包数据可以判断调用是否成功，在服务调用失败时会利用失败重试机制重新对目标服务进行调用，或者根据重试错误码重定向下游节点，保证服务调用和数据流转的成功率。
103.针对以上实施例提供的内容，请参见图11，是本技术实施例提供的一种单次组件调用的流程示意图，其完整的步骤囊括了从接收上游节点数据到将数据发给下游节点的组件服务调用逻辑。
104.步骤1：接收上游节点，获取上游节点传递和共享的数据，具体是在数据总线上传递和共享的全局变量、局部变量、状态输出变量等。
105.步骤2：初始化步骤，通过初始化对调用组件服务做准备工作。
106.步骤3：检查状态，检查状态机是否处于运行状态。因为在任务执行过程中，状态机可能会被用户中断掉，如果检查出状态机没有运行，那么后续的步骤也不会继续执行。
107.步骤4：模板参数解析，这里的模板参数是状态机中节点信息的参数，在这里即上游节点的参数，例如入参、出参、最大秒查询率(query per second，qps)以及组件标识。
108.步骤5：获取组件，主要是根据组件标识，如resource获取组件协议、url、pb、配置等，通过将模板参数和组件信息进行解析，并组装成请求参数。
109.步骤6：请求策略检查，在开始请求前对组件服务的请求策略进行检查，例如当前是否满足该组件qps的限制，不同的组件服务可以配置不同请求策略，如直接请求、异步回调、最大调用qps和重试等待策略等。
110.步骤7：协议适配，针对组件请求协议做协议的适配，构建出请求实例，通过抽象函数实现，组件请求协议可以包括grpc、http、unixsoket(一种socket方式实现进程间通信(ipc)的功能)、tencentcloudsdk，针对不同的请求协议构建不同的请求协议，可参见下述图14对应实施例提供流式请求实例和非流式请求实例对应内容。
111.步骤8：路由寻址，根据组件的路由策略，寻找合适服务实例，并发起实际请求，具体是根据组件路由确定某一种服务下具体的服务实例。
112.步骤9：网络传输，主要是与根据路由策略确定的合适服务实例建立通信连接，将组件配置信息传输给相应服务提供方，以使得服务提供方处理该组件配置信息。
113.步骤10：协议解析，通过协议解析确定服务回包数据中的目标业务字段，可以通过jsonpath语法来解决业务字段路径。
114.步骤11：回包策略检查，连接请求成功后拿到回包做回包检查，判断调用请求是否成功，如果调用请求失败则判断是否需要重试，如果调用请求成功则开始组装输出参数并传递给下游节点。在具体的回包策略检查中，可以通过判断结果码result.code是否是预先设置的，进而判定服务调用成功。示例的，配置文件中有如下针对result.code的代码设置：
[0115][0116]
上述示例表示如果结果码result.code返回的值是200，那么会返回“成功！”的消息。这种方式是针对http协议下的服务回包数据的校验。当然，对应回包策略检查还可以是下述内容中根据组件配置信息中包括的参考校验码来验证服务回包数据中是否匹配，具体内容在此不做赘述，对于服务回包数据的校验方式也不做限制。
[0117]
步骤12：失败重试，可以通过回包校验检查判断是否需要启动失败重试机制，若上述步骤中任一步骤出错，捕获到重试错误码可以启动该失败重试机制。具体的内容可参见图7对应实施例步骤s704的内容，在此不做赘述。需要说明的是，这是一个可选的步骤，当回
包校验成功可以不用执行此步骤。
[0118]
步骤13：存储步骤，将调用服务实例产生的服务回包数据和组装好的输出参数存储到数据库中。
[0119]
步骤14：检查是否结束，如果上述步骤执行结束，可以准备将组装好的输出参数传递给下游节点。
[0120]
步骤15：发给下游节点，可以将调用组件服务产生的数据共享到数据总线，并将指定字段的数据(也即组装输出)发送给下游节点。
[0121]
需要说明的是，上述示出的是单次组件调用的过程，针对状态机中每个任务节点所包括的组件调用都可以采用同样的方式。组件提供的服务可以是单一功能的原子服务，也可以是多种功能组合的服务，对外可以提供可调用的接口。该单次组件调用可以基于图2或图3所示的服务调用系统实现，在具体的实体设备或技术实现上可以参照前述内容，在此不再赘述。
[0122]
请参见图12，是本技术实施例提供的一种服务调用方法的流程示意图。本实施例以该方法的执行主体为服务器(如图2所示的任务执行器205)进行说明。其中，该服务调用方法至少可以包括以下步骤s1201～s1206：
[0123]
s1201，对目标服务回包数据进行回包校验，根据回包校验结果确定目标服务的调用结果。
[0124]
s1202，从一个或多个组件标识中确定目标组件标识，并获取目标组件标识所对应组件的组件配置信息，组件配置信息包括目标服务的调用参考信息。
[0125]
s1203，根据调用参考信息调用目标服务，得到目标服务回包数据。
[0126]
s1204，对目标服务回包数据进行回包校验，根据回包校验结果确定目标服务的调用结果。
[0127]
上述步骤具体内容可参见图7所示的实施例中步骤s701～s704，在此不再赘述。
[0128]
s1205，当调用结果指示目标服务调用成功时，根据目标服务回包数据生成第一参考数据。
[0129]
在一实施例中，当根据回包校验结果确定出来的调用结果能够说明该目标组件标识对应组件的目标服务调用成功时，可以对目标服务回包数据中的字段进行增添或删除等操作，如前述技术实现中提及的利用resultpath语法描述符对目标服务回包数据进行处理，当然也可以采用其他语法来处理，在此不做限制。与组件配置信息中请求出参匹配来达到预期的结果即第一参考数据，是待处理任务当前任务节点执行目标服务最终的输出数据。
[0130]
此步骤的可选实现方式可以是：获取第二参考数据，第二参考数据是根据调用第二组件标识所对应的服务得到的服务回包数据所生成的，第二参考数据存储在数据总线中，第二组件标识所对应的服务为配置文件的服务调用逻辑所指示的在目标服务之前执行的服务；根据第二参考数据以及目标服务回包数据确定第一参考数据。
[0131]
该方式可以视为对当前任务节点的上一个任务节点输出数据的配置，由于上下游节点是相对的，这里的当前任务节点在此可以视为下游节点，上一个任务节点可以视为上游节点，第二参考数据是在目标服务的前一个服务执行输出的结果，也就是上游节点输出到数据总线中的结果，可以根据第二参考数据和目标服务回包数据构造第一参考数据，具
体方式可参见下述介绍的对于输出流转配置的几种方式。
[0132]
其中，上下游数据的传递整体可以通过数据总线的方式，数据总线在状态机内称为上下文对象(context)，用于存储数据。其可以存储待处理任务启动的全局变量、状态输出变量(根据任务节点输出数据创建的变量)，局部变量(引擎循环状态、分支状态的一些内部使用的特殊变量)。请参见图13，是本技术实施例提供的一种数据总线的示意图，如图13所示，上游状态(也可理解为上游节点)可以输出数据并将相应数据存储到数据总线的全局变量或局部变量中，下游状态(也可理解为下游节点)可以从全局变量或局部变量中取值作为请求入参。这里的上游状态和下游状态之间的数据传递可以视为调用一个服务实例过程中，输出的数据可以给到下一个服务使用，这样在每次调用服务时，不用每次调用服务都重新设置请求入参，而是使用全局变量或局部变量的值作为输入参数，实现数据共享，从而能够减少配置文件编写的冗余程度。
[0133]
对于输出流转配置，有以下几种方式：输出到全局变量、替换全局变量以及插入变量。假设收到的服务回包数据为{“a”:“bbb”}，可以拿到服务调用回包后可以将结果输出到全局变量，以便给下游使用，例如，通过“$.x”:”$.a”表示将回包中的a字段注册到上下文对象context中，并命名为x，则最终context中含有x＝“bbb”的变量，如果全局变量中已经含有x变量，则可以用新的数据将原有数据直接替换，也就是改变变量x的值，当然，也可以通过”$”:”$”表示将回包全量替换上下文对象，最终上下文对象为{“a”:“bbb”}，与服务回包相同。如果想要将服务回包数据中的某个字段插入到上下文对象的某个对象中，可以这样表示。“$.a.b”:”$”如果context原对象为x＝{“a”:{“c”:”c”}}，则本次输出结束后，context中变为x＝{“a”:{“c”:”c”,”b”:{“a”:“bbb”}}}，数组同理，如果context原对象为x＝[{“c”:”c”}]，如果用“$.x.[1]”:”$”表示将回包插入到x对象的数组中，则本次输出结束后，context中变为x＝{“a”:[{“c”:”c”},{“a”:“bbb”}]}。
[0134]
可以发现，输出流转配置过程中，用户只需关心请求入参、请求出参以及对服务回包数据的处理具体是什么，通过在配置文件中定义可以实现相应内容，进一步降低服务调用逻辑设计的复杂度，并在调用服务的过程中自动实现节点数据流转。
[0135]
s1206，调用第一组件标识所对应的服务，根据第一参考数据执行第一组件标识所对应的服务；其中，第一组件标识为一个或多个组件标识中的组件标识，第一组件标识所对应的服实为配置文件的服务调用逻辑所指示的在目标服务之后执行的服务。
[0136]
在一实施例中，调用第一组件标识所对应的服务，也就是在目标服务执行完毕之后，继续执行下一个步骤，根据下一个步骤(即下一个任务节点)中的组件标识(在这里即第一组件标识)调用其对应的服务。在实现过程中，通过outputpath语法描述符来可以将第一参考数据作为调用该服务的调用参考信息中的请求入参，即将当前任务节点的输出结果传递到下一个任务节点，根据该请求入参执行第一组件标识所对应的服务，在这个过程中，第一参考数据作为请求入参，会根据对应的服务所支持的数据格式进行转换处理，然后以对应的数据传输协议传送给服务。可以理解的是，当前任务节点可以作为上游节点，下一个任务节点可以作为下游节点。
[0137]
对于请求入参(即输入参数或请求参数)的构建可以包括常量设置、通过json方式获取变量、获取局部变量、通过通配符构造输入参数这几种方式。
[0138]
其中，通过常量设置的方式来构建输入参数的过程中，可以通过例如声明“aaa”＝“bbb”，在请求服务(即调用服务)时构造{“aaa”:“bbb”}的请求包体，该请求包体即可视为请求参数；通过jsonpath的方式获取变量，具体可以通过声明“aaa.$”＝”$.bbb”，其中构造入参末尾带有$标志，表明这是一个变量，如上述aaa。其值为上下文对象context中存储的变量名为bbb变量的值，此外，jsonpath还可以支持深层次的获取，例如上下文对象context中有一个字典变量{“bbb”：{“ccc”:123}}，则可以通过”aaa.$”:”$.bbb.ccc”来表示，最终构造出{“aaa”:123}的请求包体；通过jsonpath的方式获取局部变量，和上述获取变量类似，只是在表述方式上略有不同。局部变量是一些引擎节点的特定变量，例如for循环的index和值，声明“aaa.$$”:”$$.index”，其中$$结束表示该参数为局部变量中获取，$$.index为特定表示，表示该循环的当前次数。若该循环的第1次，则最终构造出{“aaa”：0}的请求包体；通过通配符构造输入参数，具体是通过通配符*来构造一个列表或者字典，例如上下文对象context中有一个列表对象x＝[{“a”:{“b”:123}}，{“a”:{“c”:123}]，可以通过”aaa.$”:”$.x.[*].b”，来构造一个{“a”:[{“b”：123}，{“c”:123}]}的请求包体。其中，上下文对象既可以存储在状态机内存中，也可以存储redis、云存储等外部存储。
[0139]
综上所述，本技术实施例具备以下优点：
[0140]
用户通过配置文件可以专注输入输出的流转配置，无需关心服务调用的协议或地址，使得服务调用逻辑更加简单，能够实现更高效地调用。其中，通过多种方式进行输入流转配置，根据输入流转配置可以将上游节点的数据流转到下游节点。在输出的流转配置中，通过数据总线的方式将不同状态输出的数据共享到不同的任务节点，将本次调用服务产生的数据流转给下游节点，也可以实现数据流转。
[0141]
请参见图14，是本技术实施例提供的一种服务调用方法的流程示意图。本实施例以该方法的执行主体为服务器(如图2所示的任务执行器205)进行说明。其中，该服务调用方法至少可以包括以下步骤s1401～s1407：
[0142]
s1401，获取待处理任务对应的配置文件，配置文件包括一个或多个组件标识，每一个组件标识为服务对应的组件的标识。
[0143]
s1402，从一个或多个组件标识中确定目标组件标识，并获取目标组件标识所对应组件的组件配置信息，组件配置信息包括目标服务的调用参考信息。
[0144]
上述步骤具体内容可参见图7对应实施例中步骤s701～s702所示出的具体内容，在此不做赘述。
[0145]
s1403，根据调用参考信息调用目标服务，得到目标服务回包数据。
[0146]
在一实施例中，目标服务可以根据目标组件标识所对应组件的组件配置信息自动生成的请求实例在多个服务实例中确定，针对不同的协议有不同的请求实例，请参见图15，是本技术实施例提供的一种请求实例类型的示意图，如图15所示，对于每个任务节点，可以包括非流式的rpc调用(function)和流式的rpc调用(datastream)，非流式的rpc调用是有一个请求(request)，就会有返回一个结果(response)，也即简单的单发单收，而流式的rpc调用是可以批量返回结果，当数据量大或者需要不断传输数据时候，采用流式的rpc调用可以边处理边传输数据，是一种十分高效调用方式。由于协议不同，对应的不同请求实例也将通过不同的方式来构造请求入参，例如，grpc协议请求需要构造grpc请求实例(grpc-func)，然后通过前述图12对应实施例中提及的构建请求参数的方式生成请求包体，再通过反射机制，将请求包体注入到请求实例中，然后对相应服务端发起请求。需要说明的是，这
里自动生成的请求实例可以是组件路由指定的最佳实例，该请求实例可以用于在调用服务时匹配相同的服务实例，而匹配到和请求实例相同的服务实例即本技术实施例中的目标服务。
[0147]
此步骤的其他内容可参见图7对应实施例中步骤s703所示出的具体内容，在此不做赘述。
[0148]
s1404，获取目标服务回包数据包括的校验信息。
[0149]
在一实施例中，校验信息可以包括两个字段，分别是校验路径和校验值，校验路径表示通过jsonpath的方式需要校验的回包中的路径，校验值表示将回包中的校验路径取出。
[0150]
s1405，将组件配置信息包括的参考校验信息与目标服务回包数据包括的校验信息进行比对处理，得到回包校验结果。
[0151]
在一实施例中，组件配置信息可以包括参考校验信息，其参考校验信息也可以涉及校验路径和校验值两个字段，将组件配置信息包括的参考校验信息与服务回包数据包括的校验信息进行比对处理，实质是将校验数据包括两个校验字段分别进行比对，检查相应字段或值是否匹配，进而得到回包校验结果。该回包校验结果有两种情况，一种目标服务回包数据校验成功，另一种是目标回包数据校验失败，当校验成功，说明组件配置信息中的参考校验信息和目标服务回包数据中的校验信息相同，当校验失败，说明组件配置信息中的参考校验信息和目标服务回包数据中的校验信息不同。
[0152]
示例的，假设收到的目标服务回包数据为{“a”:“bbb”}，组件配置信息中含有校验信息，分别是校验路径为“$.a”，校验值为bbb，则表示校验服务回包数据中的a字段，且值需要等于bbb。通过比对可以发现，目标服务回包数据中有组件配置信息中包括的校验字段且值相同，校验成功。
[0153]
s1406，若回包校验结果指示校验信息和参考校验信息一致，则确定目标服务的调用结果为第一调用结果，第一调用结果用于指示目标服务调用成功。
[0154]
在一实施例中，通过比对参考校验信息和校验信息中包括的两个校验字段，可以得出参考校验信息和校验信息是否一致的回包校验结果。仍旧采用上述示例，根据上述目标服务回包数据{“a”:“bbb”}表示的是a字段的值需要等于bbb，可以发现校验成功，代表本次rpc调用成功，也就是目标服务调用结果是说明目标服务调用成功。
[0155]
s1407，若回包校验结果指示校验信息和参考校验信息不一致，则确定目标服务的调用结果为第二调用结果，第二调用结果用于指示目标服务调用失败。
[0156]
在一实施例中，和上述步骤s1405相同的方式得到回包校验结果，若该回包校验结果是表明校验信息和参考校验信息不一致的结果，例如服务回包数据中没有组件配置信息中需要校验的字段(即校验路径)，或者校验路径相同但是校验值不相同的情况，则会校验失败，代表本次rpc调用失败，那么本次调用目标服务调用结果是说明目标服务调用失败。上述对服务回包数据进行校验，可以帮助用户自动判断是否是所需的目标字段的内容，以便用户根据该校验结果进行后续的操作，例如前述提及的启用失败重试机制，或者捕获重试错误码等。
[0157]
综上所述，本技术实施例至少包括以下优点：
[0158]
对于目标服务，由于不同协议下构建的请求实例除了常用的非流式请求实例，还
增加了流式请求实例，丰富了调用服务的请求实例。此外，根据目标服务的服务回包数据判断调用是否成功，具体是匹配服务回包数据和组件配置信息中的校验信息，包括校验路径字段和校验值，以保证服务调用的准确性。
[0159]
请参见图16，图16是本技术实施例提供的一种服务调用装置的结构示意图。上述服务调用装置可以是运行于服务器中的一个计算机程序(包括程序代码)，例如该服务调用装置为一个应用软件；该服务调用装置可以用于执行本技术实施例提供的方法中的相应步骤。如图16所示，该服务调用装置160可以包括：获取模块1601、确定模块1602、调用模块1603、校验模块1604，其中：
[0160]
获取模块1601，用于获取待处理任务对应的配置文件，配置文件包括一个或多个组件标识，每一个组件标识为服务对应的组件的标识；
[0161]
确定模块1602，用于从一个或多个组件标识中确定目标组件标识，并获取目标组件标识所对应组件的组件配置信息，组件配置信息包括目标服务的调用参考信息；
[0162]
调用模块1603，用于根据调用参考信息调用目标服务，得到目标服务回包数据；
[0163]
校验模块1604，用于对目标服务回包数据进行回包校验，根据回包校验结果确定目标服务的调用结果。
[0164]
在一实施例中，该服务调用装置160还包括：生成模块1605，其中：
[0165]
生成模块1605，用于当调用结果指示目标服务调用成功时，根据目标服务回包数据生成第一参考数据；
[0166]
调用模块1603，用于调用第一组件标识所对应的服务，根据第一参考数据执行第一组件标识所对应的服务；其中，第一组件标识为一个或多个组件标识中的组件标识，第一组件标识所对应的服务为配置文件的服务调用逻辑所指示的在目标服务之后执行的服务。
[0167]
在一实施例中，生成模块1605具体用于：获取第二参考数据，第二参考数据是根据调用第二组件标识所对应的服务得到的服务回包数据所生成的，第二参考数据存储在数据总线中，第二组件标识所对应的服务为配置文件的服务调用逻辑所指示的在目标服务之前执行的服务；根据第二参考数据以及目标服务回包数据确定第一参考数据。
[0168]
在一实施例中，调用模块1603具体用于：当调用结果指示目标服务调用失败时，若目标服务的调用失败次数小于或等于调用次数阈值，则在达到调用失败次数所对应的间隔时间时，重新调用目标服务；当调用结果指示目标服务调用失败时，若目标服务的调用失败次数大于调用次数阈值，停止调用目标服务。
[0169]
在一实施例中，该服务调用装置160还包括重定向模块1606，用于：当调用结果指示目标服务调用失败时，获取重试错误码；根据重试错误码将目标服务之后执行的服务进行重定向处理。
[0170]
在一实施例中，校验模块1604具体用于：获取目标服务回包数据包括的校验信息；将组件配置信息包括的参考校验信息与目标服务回包数据包括的校验信息进行比对处理，得到回包校验结果；若回包校验结果指示校验信息和参考校验信息一致，则确定目标服务的调用结果为第一调用结果，第一调用结果用于指示目标服务调用成功；若回包校验结果指示校验信息和参考校验信息不一致，则确定目标服务的调用结果为第二调用结果，第二调用结果用于指示目标服务调用失败。
[0171]
在一实施例中，该服务调用装置160还包括控制模块1607，用于：控制用户终端显
示组件创建界面，组件创建界面包括与待创建组件相关联的一个或多个关联参数输入框；获取针对一个或多个关联参数输入框所输入的数据；根据针对一个或多个关联参数输入框所输入的数据创建组件；控制用户终端显示组件管理界面，并控制用户终端在组件管理界面中展示创建的组件的关联参数。
[0172]
本技术提供的服务调用装置中各功能模块的功能可根据上述方法实施例中的方法具体实现，其具体实现过程可以参照上述方法实施例的相关描述，此处不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
[0173]
请参见图17，是本技术实施例提供的一种计算机设备的结构示意图，该计算机设备170可以包括处理器1701、存储器1702、网络接口1703和至少一个通信总线1704。其中，处理器1701用于调度计算机程序，可以包括中央处理器、控制器、微处理器；存储器1702用于存储计算机程序，可以包括高速随机存取存储器ram，非易失性存储器，例如磁盘存储器件、闪存器件；网络接口1703可选的可以包括标准的有线接口、无线接口(如wi-fi接口)，提供数据通信功能，通信总线1704负责连接各个通信元件。该计算机设备170可以对应于前文的任务执行器205。
[0174]
其中，处理器1701可以用于调用存储器中的计算机程序，以执行如下操作：
[0175]
获取待处理任务对应的配置文件，配置文件包括一个或多个组件标识，每一个组件标识为服务对应的组件的标识；从一个或多个组件标识中确定目标组件标识，并获取目标组件标识所对应组件的组件配置信息，组件配置信息包括目标服务的调用参考信息；根据调用参考信息调用目标服务，得到目标服务回包数据；对目标服务回包数据进行回包校验，根据回包校验结果确定目标服务的调用结果。
[0176]
在一实施例中，处理器1701还用于：当调用结果指示目标服务调用成功时，根据目标服务回包数据生成第一参考数据；调用第一组件标识所对应的服务，根据第一参考数据执行第一组件标识所对应的服务；其中，第一组件标识为一个或多个组件标识中的组件标识，第一组件标识所对应的服务为配置文件的服务调用逻辑所指示的在目标服务之后执行的服务。
[0177]
在一实施例中，处理器1701具体用于：获取第二参考数据，第二参考数据是根据调用第二组件标识所对应的服务得到的服务回包数据所生成的，第二参考数据存储在数据总线中，第二组件标识所对应的服务为配置文件的服务调用逻辑所指示的在目标服务之前执行的服务；根据第二参考数据以及目标服务回包数据确定第一参考数据。
[0178]
在一实施例中，处理器1701还用于：当调用结果指示目标服务调用失败时，若目标服务的调用失败次数小于或等于调用次数阈值，则在达到调用失败次数所对应的间隔时间时，重新调用目标服务；当调用结果指示目标服务调用失败时，若目标服务的调用失败次数大于调用次数阈值，停止调用目标服务。
[0179]
在一实施例中，处理器1701还用于：当调用结果指示目标服务调用失败时，获取重试错误码；根据重试错误码将目标服务之后执行的服务进行重定向处理。
[0180]
在一实施例中，处理器1701具体用于：获取目标服务回包数据包括的校验信息；将组件配置信息包括的参考校验信息与目标服务回包数据包括的校验信息进行比对处理，得到回包校验结果；若回包校验结果指示校验信息和参考校验信息一致，则确定目标服务的调用结果为第一调用结果，第一调用结果用于指示目标服务调用成功；若回包校验结果指
示校验信息和参考校验信息不一致，则确定目标服务的调用结果为第二调用结果，第二调用结果用于指示目标服务调用失败。
[0181]
在一实施例中，处理器1701还用于：控制用户终端显示组件创建界面，组件创建界面包括与待创建组件相关联的一个或多个关联参数输入框；获取针对一个或多个关联参数输入框所输入的数据；根据针对一个或多个关联参数输入框所输入的数据创建组件；控制用户终端显示组件管理界面，并控制用户终端在组件管理界面中展示创建的组件的关联参数。
[0182]
应当理解，本技术实施例中所描述的计算机设备170可执行前文图7所对应实施例中对该服务调用方法的描述，也可执行前文图16所对应实施例中对该服务调用装置160的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
[0183]
此外，这里需要指出的是：本技术实施例还提供了一种计算机可读存储介质，且上述计算机可读存储介质中存储有前文提及的服务调用的计算机设备170所执行的计算机程序，且上述计算机程序包括程序指令，当上述处理器执行上述程序指令时，能够执行前文图7所对应实施例中对上述服务调用方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本技术所涉及的计算机可读存储介质实施例中未披露的技术细节，请参照本技术方法实施例的描述。
[0184]
上述计算机可读存储介质可以是前述任一实施例提供的服务调用装置或者上述计算机设备的内部存储单元，例如计算机设备的硬盘或内存。该计算机可读存储介质也可以是该计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(smart media card，smc)，安全数字(secure digital，sd)卡，闪存卡(flash card)等。进一步地，该计算机可读存储介质还可以既包括该计算机设备的内部存储单元也包括外部存储设备。该计算机可读存储介质用于存储该计算机程序以及该计算机设备所需的其他程序和数据。该计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的数据。
[0185]
本技术的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本技术实施例中一方面提供的服务调用方法。
[0186]
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
[0187]
以上所揭露的仅为本技术较佳实施例而已，当然不能以此来限定本技术之权利范围，因此依本技术权利要求所作的等同变化，仍属本技术所涵盖的范围。