A service calling method, device, computer equipment and storage medium

Abstract

The embodiment of the present application discloses a service calling method, apparatus, computer equipment and storage medium, the method comprising: obtaining a configuration file corresponding to a task to be processed, the configuration file comprising one or more component identifiers, each component identifier being an identifier of a component corresponding to the service; determining a target component identifier from the one or more component identifiers, and obtaining component configuration information of the component corresponding to the target component identifier, the component configuration information comprising call reference information of the target service; calling the target service according to the call reference information to obtain target service return packet data; performing a return packet check on the target service return packet data, and determining the call result of the target service according to the return packet check result. By adopting this solution, a service can be efficiently called through a configuration file, and the call result of a service can be accurately determined through the return packet check result.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a service calling method, apparatus, computer equipment, and storage medium. Background Art

[0002] Task flow is a very common form of task organization. Order systems and approval systems are common task flows. The process of task flow usually involves calling services. For the service caller, the purpose of the service call is reflected in the consumption of service functions. By calling the corresponding service, business needs in specific scenarios can be met. For example, in the scenario of video processing, it is necessary to call a speech recognition service to process the voice in the video.

[0003] Currently, various business scenarios involve different types of service calls to meet different business needs. Among them, the application of artificial intelligence services has also demonstrated excellent service performance. Therefore, the implementation of service calls in task flows remains a hot topic of research. Summary of the Invention

[0004] The embodiments of the present application provide a service calling method, apparatus, computer equipment and storage medium, which can efficiently call services through configuration files and accurately determine the service calling results through packet return verification results.

[0005] An embodiment of the present application provides a service invocation method, including:

[0006] Get the configuration file corresponding to the task to be processed. The configuration file includes one or more component identifiers, each of which is the identifier of the component corresponding to the service.

[0007] Determine a target component identifier from one or more component identifiers, and obtain component configuration information of a component corresponding to the target component identifier, wherein the component configuration information includes call reference information of a target service;

[0008] Call the target service according to the call reference information and obtain the target service response data;

[0009] Perform packet verification on the target service return data and determine the target service call result based on the packet verification result.

[0010] An embodiment of the present application provides a service invoking device, including:

[0011] An acquisition module is used to obtain a configuration file corresponding to a task to be processed. The configuration file includes one or more component identifiers, each of which is an identifier of a component corresponding to a service.

[0012] A determination module, configured to determine a target component identifier from one or more component identifiers, and obtain component configuration information of the component corresponding to the target component identifier, wherein the component configuration information includes call reference information of the target service;

[0013] The calling module is used to call the target service according to the calling reference information and obtain the target service response data;

[0014] The verification module is used to perform packet verification on the target service return data and determine the call result of the target service based on the packet verification result.

[0015] On the one hand, an embodiment of the present application provides a computer device, including: a processor, a memory, and a network interface; the processor is connected to the memory and the network interface, wherein the network interface is used to provide network communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the service calling method in the embodiment of the present application.

[0016] On the one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. The computer program includes program instructions. When the program instructions are executed by a processor, the service calling method in the embodiment of the present application is executed.

[0017] Accordingly, embodiments of the present application provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the service invocation method provided in one aspect of the embodiments of the present application.

[0018] In an embodiment of the present application, component configuration information is obtained through the component identifier included in the configuration file, and the service is called according to the call reference information included in the component configuration information, thereby obtaining the service response data, and verifying it to obtain the result of the service call. Among them, the configuration file is a configuration standard language that describes the service call logic, focusing on the input and output flow configuration, and does not need to care about the specific service call address and call protocol. The component configuration information is obtained through the highly readable component identifier in the configuration file to achieve the purpose of calling the corresponding service, which reduces the complexity of the business logic designed by the user for the service call, and the configuration file is compatible with service calls under different protocols, has a unified and standardized arrangement rule, a wide range of applications, and high versatility. In addition, by verifying the service response data, the service call can be further processed to ensure the accuracy of the service call. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0020] Figure 1 is a schematic diagram of a state machine provided in an embodiment of the present application;

[0021] Figure 2 This is a network architecture diagram of a service calling system provided by an embodiment of the present application;

[0022] Figure 3 This is a business logic architecture diagram of a service call system provided in an embodiment of the present application;

[0023] Figure 4 This is a flowchart of a component creation method provided in an embodiment of the present application;

[0024] Figure 5 This is a schematic diagram of an interface for creating a custom component provided in an embodiment of the present application;

[0025] Figure 6 This is a schematic diagram of a component management interface provided in an embodiment of the present application;

[0026] Figure 7 This is a flow chart of a service calling method provided in an embodiment of the present application;

[0027] Figure 8 This is a flowchart of a model component registration provided by an embodiment of the present application;

[0028] Figure 9 This is a schematic diagram of the contents of a configuration file provided in an embodiment of the present application;

[0029] Figure 10 This is a flow chart of a model calling service provided by an embodiment of the present application;

[0030] Figure 11 This is a flowchart of a single component service call provided by an embodiment of the present application;

[0031] Figure 12 This is a flow chart of a service calling method provided in an embodiment of the present application;

[0032] Figure 13 is a schematic diagram of a data bus provided in an embodiment of the present application;

[0033] Figure 14This is a flow chart of a service calling method provided in an embodiment of the present application;

[0034] Figure 15 This is a schematic diagram of a request instance type provided in an embodiment of the present application;

[0035] Figure 16 This is a structural diagram of a service calling device provided in an embodiment of the present application;

[0036] Figure 17 It is a structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0038] To facilitate understanding, the key terms that may be involved in this application are explained below.

[0039] State machine: A model that describes a finite number of states and behaviors such as transitions and actions between these states.

[0040] State: Each step in a state machine is also called a state. A state performs a response based on its input and passes its output to the next state. Common state types include Task, Pass, Wait, Choice, Parallel, and Foreach. Task is the most commonly used state, used to describe the execution of tasks, such as executing local scripts or calling various cloud services.

[0041] State machine template: specifies the use of code language (such as Json or YAML format) to describe the entire state machine process, referred to as a template.

[0042] Component: Represents the interface information of a service, also known as a service interface or service component. The service can be called by calling the service interface (or component).

[0043] Function service: A service that provides a single interface and is automatically generated by the service framework based on a standardized Python template and can be registered as a component.

[0044] AI template service: A service that provides a single interface and is automatically generated by the service framework based on the state machine template and can be registered as a component.

[0045] resource: A unique ID that identifies a component.

[0046] Context object: used for shared storage of data flowing between each state.

[0047] PB: refers to Google's ProtoBuf, a data transmission protocol, the full name of which is Protocol Buffers. It is a platform-independent, language-independent, scalable, lightweight and efficient binary-encoded data serialization protocol that can be used for network communication and data storage.

[0048] RPC: Remote Procedure Call. It can be understood as one node requesting a service provided by another node.

[0049] gRPC: A high-performance, open-source, and general-purpose RPC framework that can use Protobuf for data encoding.

[0050] API: Application Programming Interface, application programming interface, is a set of predefined interfaces (such as functions, HTTP interfaces), or refers to the agreement for connecting different components of a software system.

[0051] For a detailed understanding of the state machine in the above key terms, see Figure 1 , is a schematic diagram of a state machine provided in an embodiment of the present application, such as Figure 1 As shown, the main function of this state machine is to process the video. Figure 1Each step shown in the figure is a state, such as preprocessing, video framing, optical character recognition (OCR), audio-to-text, natural language processing (NLP), and merging, and all are task-type states. Among them, preprocessing can be performed by calling the Serverless CloudFunction (SCF) service to perform video shot segmentation, key frame extraction, and feature extraction on the video; video framing can be performed by calling the video processing service to perform frame processing on the video, and then optical character recognition is used to perform text recognition on the video content after the frame processing to obtain text data; audio-to-text can be converted into text data by calling speech recognition services, such as automatic speech recognition (ASR); natural language processing can be performed by calling the natural language processing service to perform relevant processing on the text data obtained by optical character recognition and audio-to-text, such as sentiment analysis, extraction of comments and opinions, etc.; merging storage stores the processing results obtained by the natural language processing step in the database.

[0052] The service call solution provided by this application describes the service call logic through a state machine language (i.e., a configuration file). The configuration file focuses on the flow configuration of input and output. In the service call, the component identifier of the component corresponding to the service, that is, the interface information that uniquely represents the specific service, is used to specify the called service. This can improve the convenience of user operation and make the entire service call logic more readable. Since the component is the interface information representing the service, calling the component is equivalent to calling the service. These components are pre-created, and the relevant component configuration information is stored in the database. By calling the service through the component configuration information and verifying the service data packet returned by the calling service, the accuracy of the service call can be guaranteed.

[0053] It can be seen that the solution provided in the embodiment of the present application belongs to the artificial intelligence cloud service under the cloud application. The so-called artificial intelligence cloud service is generally also referred to as AIaaS (AI as a Service, Chinese for "AI as a Service"). This is a mainstream service mode of an artificial intelligence platform. Specifically, the AIaaS platform will split several common AI services and provide independent or packaged services in the cloud. This service model is similar to opening an AI theme mall: all developers can access and use one or more artificial intelligence services provided by the platform through the API interface. Some senior developers can also use the AI framework and AI infrastructure provided by the platform to deploy and operate their own exclusive cloud artificial intelligence services. For example, calling the AI component service through the component identifier in the configuration file.

[0054] See Figure 2 , is an architecture diagram of a service calling system provided by an embodiment of the present application, such as Figure 2 As shown, the system architecture includes a user terminal 201, a service server 202, a database 203, a task scheduler 204, and a task executor 205. The user terminal 201 and the service server 202 can be directly or indirectly connected via wired or wireless communication to exchange data. The task scheduler 204 can obtain pending tasks from the service server 202 and assign them to corresponding task executors 205. The database 203 can store service data generated by the service server. The following details the functions of each entity in the system architecture.

[0055] The user terminal 201 can run a functional client, and the user can write a configuration file on the functional client in a state machine language (such as json language, a configuration standard description language) to implement the arrangement of components. The configuration file can describe the call logic of different services. The user can also manage components or services on the functional client, such as modifying or deleting already created components in the component management interface, viewing the progress of tasks being executed or viewing pending tasks in the task management interface, entering relevant component information and creating components in the new component interface, etc. The user terminal 201 can also publish the completed configuration file as a corresponding pending task or pending service, and send the pending task or pending service to the business server 202 for unified management by the business server 202, or the business server 202 receives the completed configuration file on the user terminal 201 and publishes it as a corresponding pending task or pending service. It should be noted that publishing a configuration file as a pending service is usually because the configuration file can encapsulate the complete service call logic, which involves multiple service calls. The pending service is registered as a component, and the user can use the configuration file to represent a request call through the defined grammatical specifications. It can be reused in multiple other configuration files, and when used, only the component identifier is needed to implement multiple service calls, thereby improving configuration efficiency. This is similar to the code that encapsulates functional functions. Modularizing functions can improve code reusability and simplicity.

[0056] The business server 202 can receive configuration files, pending tasks, and pending services sent by the user terminal 201, and assign the pending tasks to the corresponding task executors 205 via the task scheduler 204. The business server 202 can also receive component registration requests from the user terminal 201, create new components based on the component registration requests, assign each component a unique component identifier, such as a resource, and store the component configuration information obtained from the component registration in the database 203. The business server 202 can also receive query requests for component configuration information from the task executor 205, resolve the component identifier, obtain the corresponding component configuration information from the database 203, and generate a request instance.

[0057] The database 203 may be used to store component configuration information or service call result data, and may also receive a data acquisition request sent by the business server 202 and send the component configuration information to the business server 202 .

[0058] The task scheduler 204 can obtain the configuration file corresponding to the task to be processed from the business server 202, and then send it to the appropriate task executor 205. After obtaining the configuration file corresponding to the task to be processed, the task executor 205 will send the component identifier therein to the business server 202. The business server 202 will query the component and send the component configuration information of the component corresponding to the component identifier to the task executor 205. The task executor 205 will request the service call from the party providing the actual service based on the call reference information in the component configuration information, obtain the service return package data and process it, such as verification, to obtain the final output.

[0059] The business server 202, database 203, task scheduler 204, and task executor 205 can all be independent physical servers, or server clusters or distributed systems composed of multiple physical servers. They can also be cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The user terminal 201 can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smart watch, etc., but is not limited to these.

[0060] See Figure 3 , is a business logic architecture diagram of a service calling system according to an embodiment of the present application, such as Figure 3 As shown, it includes an access layer 301, a business layer 302, and a storage layer 303, wherein the access layer 301 communicates with the business layer 302 through the API gateway, and can initiate a request to register a component and a request to start a task to the business layer 302 through the API gateway; the business layer 302 includes a component control layer 3021, a component execution layer 3022, and a task scheduling execution layer 3023, wherein the component control layer 3021 includes component registration, component routing, component adaptation, and component identifier resolver, the component execution layer 3022 includes a variety of services, such as function services, model services, AI services, custom services, etc., and the task scheduling execution layer 3023 includes a scheduler and an executor. Among them, the corresponding contents of the component control layer 3021 and the component execution layer 3022 can be deployed in Figure 2 In the business server 202 shown, the scheduler included in the task scheduling execution layer 3023 corresponds to Figure 2 The task scheduler 204 shown in FIG. Figure 2 The task executor 205 shown in the figure and the database included in the storage layer 303 can be deployed in Figure 2 In the database 203 shown.

[0061] The logical relationship and corresponding functions between each functional layer will be explained in detail below.

[0062] The API gateway in the access layer 301 can be provided by a client with component registration and component orchestration functions. When a user triggers the corresponding function control on the client, the client can establish a connection with the business layer 302 through the API gateway and communicate to achieve data exchange. For example, when registering a component (i.e., creating a component), a component registration request is sent to the component control layer 3021. The component control layer 3021 will create the user-specified component according to the specific logical process, or start a scheduled task and send a start task request to the task scheduling execution layer 3023. The task scheduling execution layer 3023 also has a corresponding logical process to process the task, which will not be explained here.

[0063] The three parts included in the business layer 302 have different functions and there is data interaction between each other. Specifically, when the user registers a component through the API request of the gateway, that is, when the component control layer 3021 receives the component registration request of the access layer 301, it will first use the component adapter to adapt different types of components, which can include four types of components, namely function service components (components that register a script code, such as a python script code execution logic service), model components (components that register algorithm services involved in service calls), AI service components (components that register a section of well-organized task logic), and custom service components (components that register any service implemented by the user). The component adapter can determine which specific component the user requests to register through the request information included in the user component registration request, such as the model service identifier, and then use the component registration to assign a unique component identifier to each component, such as a string ID, and store the basic component information in a database, such as MySQL, Redis, etc. There is no restriction on the type of database included here.

[0064] When a user starts a task through the gateway's API request, the task scheduling execution layer 3023 will receive the task start request from the access layer 301, and dispatch the task to a specific executor through the scheduler. The executor makes a component request and queries the component from the component control layer 3021 through the component identifier included in the task. The component control layer 3021 obtains the specific component information from the storage layer and sends it to the executor. In this process, the component identifier will first be used to request resolution from the component control layer, that is, the component control layer 3021 will first use the component identifier resolver to resolve the component identifier given by the executor to obtain information such as the component call protocol and data transmission format. Since each service may have multiple instances, when the executor makes a component request, the component control layer 3021 will return the most suitable instance for this call to the executor for calling. This is also the process of component routing, which can achieve load balancing. For example, the OCR algorithm service in the model service has multiple instances, that is, there are multiple copies of the OCR algorithm. The algorithm implementation logic of each copy is the same, and the corresponding interface information (i.e., component) is the same, but the routing address of the component is different. By calling the OCR algorithm with different routing addresses, it is possible to avoid different tasks always calling the same algorithm copy, thereby increasing the flexibility and availability of service calls. The best instance of the corresponding service is obtained through component routing to form complete component information. The executor can initiate a request to call the service to the component execution layer 3022 based on the component information. Since the component execution layer 3022 is each actual component service, different component services have different instances. Therefore, the component execution layer 3022 can match the instance required for the call in the component information.

[0065] It should be noted here that the function services and AI services in the component execution layer 3022 are both business encapsulations, and the model services and custom services are essentially actual services, which are deployed in a cluster together with the business services. In addition, the aforementioned "component services" and "services" are expressions with the same meaning, and "component information" and "component configuration information" are also the same expressions, and the terms can be used interchangeably. The above content can also be briefly summarized as when the user starts a task, the scheduler will schedule the task to a suitable executor, and then meet certain business needs by serially calling different component services. Whenever a component service call is executed, it first goes to the component control layer 3021 to obtain basic component information, and obtains the best instance through component routing, and then goes to the component execution layer 3022 to call the service.

[0066] The storage layer 303 is used to store the basic component information sent by the component control layer 3021 when registering the component. When querying the component, the component control layer 3021 will obtain the component information from the storage layer 303 to assist the task execution layer 3023 in calling the service from the component execution layer 3022 based on the component information.

[0067] It can be found that the above-mentioned business logic architecture diagram for service calls includes two main parts: component registration and component service calls. Through component registration, different services can be registered as components, and component identification is used to obtain component information and then call services. The convenience of service calls and the reusability of component information are increased through components, which simplifies the implementation process of business logic for users or developers. In addition, when calling, the appropriate instance can be matched according to the component information corresponding to the component to achieve load balancing during the call process. The business logic architecture diagram provided by this application can be compatible with different types of service calls and improve the efficiency of service calls in different business scenarios.

[0068] For a visualization of the above component registration process, see Figure 4 , is a flowchart of a component creation method provided in an embodiment of the present application. This embodiment is described with the execution subject of the method being a server. The component creation method may include at least the following steps S401 to S404:

[0069] S401: Control the user terminal to display a component creation interface, where the component creation interface includes one or more associated parameter input boxes associated with the component to be created.

[0070] In one embodiment, the server may control the user terminal to display a component creation interface, which may be a component creation interface for a custom component. The user may enter corresponding data in one or more associated parameter input boxes included in the component creation interface. Figure 5 , is a schematic diagram of an interface for creating a custom component provided in an embodiment of the present application, such as Figure 5 As shown, the custom component creation interface includes parameter input boxes for the component English name, component Chinese name, service English name, calling service IP port, calling service URL, timeout period, and return code (return code), as well as associated parameter options such as request method, interface type, and data type. Below the above-mentioned associated parameter input box, the input specifications and input examples of the corresponding associated parameter input box can also be displayed to help users accurately enter the associated parameters. These associated parameters can constitute component configuration information and be saved in the database when the component is successfully registered. Optionally, the component creation interface can also be an interface for creating components for other services, such as model services and AI services. In this way, services can be directly imported to obtain corresponding information. There is no restriction on the component creation interface here.

[0071] S402: Acquire data input into one or more associated parameter input boxes.

[0072] In one embodiment, users can input data in these input boxes according to corresponding input specifications or input examples, or the data in these input boxes are automatically generated after importing into the corresponding service, so that the server can obtain the input data and use it as component configuration information.

[0073] S403: Create a component according to the data input into one or more associated parameter input boxes.

[0074] In one embodiment, after obtaining corresponding data and inputting it into the associated parameter input box, the server may create a component in response to a certain triggering operation, and the specific triggering operation is not limited here.

[0075] S404: Control the user terminal to display a component management interface, and control the user terminal to display associated parameters of the created component in the component management interface.

[0076] In one embodiment, the server can control the user terminal to display the component management interface, see Figure 6 , is a schematic diagram of a component management interface provided in an embodiment of the present application. This component management interface displays various types of components and component information, as well as the time when a component was created, and allows users to edit or delete already created components. Furthermore, from this component management interface, users can trigger a new component to enter the component creation interface.

[0077] The component creation solution provided in the embodiments of this application improves component creation efficiency by enabling component creation through a visual interface. Custom components can register any user-defined service as a component, enabling a wide variety of services and making components more scalable. Furthermore, centralized management of created components through the component management interface enables unified component deployment and enhanced intelligent effects.

[0078] It should be noted that the visual interface for creating components shown above is only one way to enter components. Components can also be created by writing code, such as generating a function service component based on a submitted code file. This application does not limit the method of creating components. Although the method of entering components can be different, the configuration file can handle each component in the same way.

[0079] The above method of creating a component can be implemented on an artificial intelligence service platform, where the artificial intelligence platform can be used as follows: Figure 6As shown, in addition to component management, template management, task management, and service management, it can also include menu bars such as application center, algorithm warehouse, data center, and management center. Based on the corresponding functions provided by the artificial intelligence service platform, it can realize the registration and orchestration of components and the calling of component services, thereby providing users with functions such as multi-algorithm fusion scheduling and big data normalization processing. Among them, AI tasks (i.e. task management), AI services (i.e. service management), and AI templates (i.e. template management) are all part of the AI studio. The functions of each part of the AI studio are described below.

[0080] Component management is mainly used to integrate various callable components and enrich the capabilities of the orchestration engine. A component can be seen as describing a Web service interface; an algorithm service interface, etc. Therefore, component management mainly stores information such as the component's protocol, parameters, and calling method. The core function of template management is to orchestrate state machine templates. The front-end supports dragging and dropping or directly writing state process language. Once you have a template, you can select the corresponding template to create a task or service. Task management allows the orchestrated state machine template to be published as a distributed task. During the execution of the task, the requests configured in the template will be called sequentially. Service management allows the orchestrated state machine template to be published as a service, which users can then call directly through the API interface and treat as a Web service.

[0081] Further, see Figure 7 , Figure 7 This is a flow chart of a service calling method provided by an embodiment of the present application. In this embodiment, the execution subject of the method is a server (such as Figure 2 The service calling method may include at least the following steps S701 to S704:

[0082] S701: Obtain a configuration file corresponding to the task to be processed. The configuration file includes one or more component identifiers, each of which is an identifier of a component corresponding to the service.

[0083] In one embodiment, the task to be processed can be a distributed task created by any state machine template, which calls the request configured in the state machine template according to the logical relationship during execution. Among them, the state machine template is a process of a finite number of states described by a code language (such as json language, which can also be regarded as a state machine language). In an embodiment of the present application, it includes multiple task nodes, each task node can correspond to a service, and accordingly, a state machine template can also be understood as a configuration file, which can be used to indicate the service call logic, that is, the order of service calls, and for the state machine template, that is, the execution logic of the task node. The configuration file includes one or more component identifiers, which are identifiers of the components corresponding to the service. Each service can be uniquely identified by the interface identifier and the service identifier. Each service can correspond to multiple service instances, such as two identical OCR algorithm services. The corresponding components have different routing addresses and represent two service instances. The services here include but are not limited to the aforementioned function services, model services, AI services, and custom services. The corresponding components are function service components, model components, AI service components, and custom components. These components can be components that are pre-registered and stored in the server. Each component has a unique component identifier assigned. The definition of the component identifier can support multiple request protocols and data formats. For component registration, you can Figure 3 The provided service call system implementation is shown in Figure 8 , is a flow chart of a model component registration process provided by an embodiment of the present application, such as Figure 8 As shown, first, the user can create a component through the console or through the interface (i.e., API gateway). After the user creates a new model component, the console or API gateway requests registration from the component adapter in the component control layer through the model component identifier and interface identifier. When the component adapter finds that it is a model component, it will request the algorithm warehouse (i.e., model management EMS service) to obtain service information based on the model service identifier and interface identifier. The obtained service information and interface information are then given to the component registration of the component control layer as complete registration information, and a component identifier that uniquely represents the model component is assigned. After that, some key information in the registration information, such as the service call address, service port, service request input parameter, request output parameter, request return packet verification code, timeout period, and other necessary information, can be stored in the database. The database sends a storage success message to the component registration of the component control layer, and then the component registration can send a registration success message to the console or API gateway, and finally inform the user that the registration is successful.

[0084] The above is explained using the model service component as an example. It can be understood as an atomic service component, that is, it provides a single service function, or it can be a component that combines and encapsulates the service functions of different service providers. The registration of other service components does not require interaction with the algorithm warehouse to obtain the registration information of the component. Specifically, if it is a function service, the component adapter will automatically obtain the component information of the function service and store the script code; if it is an AI service, the component adapter will automatically obtain the service engine related information; if it is a custom component, the user is required to fill in the key information of the component, and the component adapter can directly obtain it from the user terminal through the console. The interface corresponding to the component registration can be seen in Figure 4 The contents of the corresponding embodiments are not described in detail here.

[0085] In embodiments of the present application, component identification can employ a five-part definition, such as a resource. This definition includes the request protocol, data transmission format, component type, service name, and component name. This basic information identifies the specific service and component. Based on this information, other relevant information about the corresponding component can be uniquely retrieved from a database for subsequent processing. For a specific example of a resource definition, see the following.

[0086] Resource: HTTP::JSON::algorithm::yt-server-video-snippet-cut::VideoLensCut. The HTTP in the first section is the protocol name. In addition to HTTP, it can also support grpc or trpc (a high-performance RPC development framework built on cloud native principles and supporting multiple languages). The second section, JSON, indicates the data transmission format and also supports PB. The third section, algorithm, indicates that the component type is a model component. It also supports function for function service components, customized for custom components, and AI service components. The fourth section, yt-server-video-snippet-cut, indicates the service name, which can be user-defined or generated based on a service name provided by the developer. The fifth section, VideoLensCut, indicates the interface name, i.e., the component name, which can also be user-defined or generated based on an interface name provided by the developer. As you can see, resource supports various request protocols, including HTTP+JSON, HTTP+PB, GRPC, GRPC server-side streaming and bidirectional streaming, as well as different component inputs, such as proprietary function service components and AI service components. Resource is a declarative definition that does not involve specific call addresses. Instead, it clearly and intuitively reflects the component service to be called and the corresponding call form, making it a highly readable method. It should be noted that string IDs can also be used to represent components instead of resources.

[0087] In order to better understand the above content, motor vehicle identification is taken as an example. The motor vehicle identification process is regarded as a task to be processed. The motor vehicle identification task includes the steps that must be executed, such as the motor vehicle monitoring equipment capturing the vehicle, the human and vehicle detection and following service, the motor vehicle attribute identification service, the vehicle identification result processing, and the vehicle warning. Each step corresponds to a state, and can also be regarded as a task node. The corresponding service needs to be called to implement the specified function. The component is the interface information of the service, and it has a unique component identifier to indicate it. The component information of the component can be obtained through the component identifier to call the service. In fact, calling the service is achieved by calling the service interface (ie component). The entire process of the motor vehicle identification task can be achieved by writing a configuration file to specify the order between the steps. For example, the component identifiers of the components corresponding to the human and vehicle detection and following service, the motor vehicle identification service, etc. can appear in the configuration file in the corresponding execution order. This includes that the service can be determined by the specific service name and component name in the resource as shown above. For an example of the content of the configuration file, please refer to Figure 9This is a structured configuration file for face recognition in a video. It involves multiple task nodes, each of which has a corresponding resource identifier component, a next field indicating the service corresponding to the current node's downstream node, and other parameter configurations. These task nodes connect different services in series, representing specific business logic. The specific code language in the configuration file is not restricted.

[0088] S702: Determine a target component identifier from one or more component identifiers, and obtain component configuration information of the component corresponding to the target component identifier, where the component configuration information includes call reference information of the target service.

[0089] In one embodiment, one or more component identifiers correspond to components that have a sequential execution order. The target component identifier here can be any component identifier, and there is a component identifier before or after it to indicate the call of the corresponding service. For example, in the aforementioned example, the motor vehicle identification step includes corresponding component identifiers for the motor vehicle monitoring device capturing the vehicle, the vehicle detection and following service, the motor vehicle attribute identification service, the vehicle identification result processing, and the vehicle warning. If the target component identifier is the component identifier corresponding to the motor vehicle attribute identification service, then according to the logical order of execution, there is a component identifier corresponding to the vehicle detection and following service before the target component identifier, and there is a component identifier corresponding to the vehicle identification result processing after the target component identifier. The target service can be a service determined by the component identifier. When calling the service, the component routing can be used to match the best instance of the service. For example, the motor vehicle attribute identification service has three copies, A, B, and C, all with the same identification function. The components provided to the service caller are the same, that is, the service interface is the same, but the routing addresses of the components are different. Therefore, the best instance, such as the motor vehicle attribute identification service A, can be matched by the routing address of the component to achieve balanced service calls. During the process of the task executor obtaining component configuration information, the business server will parse the target component identifier and obtain the component configuration information of the corresponding component from the database, and send it to the task executor. The information related to the service call in the component configuration information can be regarded as call reference information, such as the service call address, service port, service request input parameters, request output parameters, request return packet verification code, timeout period, etc. The above component configuration information is the key information stored in the database when the component is registered.

[0090] It should be noted that during the execution of pending tasks, they will be executed in the service call logic order indicated by the configuration file. Each component identifier included in the configuration file can be processed in the same way as the target component identifier.

[0091] S703: Call the target service according to the call reference information and obtain the target service response data.

[0092] In one embodiment, the target service can be uniquely determined based on the service call address in the call reference information, such as the component IP, domain name or URL (Uniform Resource Locator), and an RPC call is made to the target service based on the service call address. After the specific target service is executed, the processing result of the target service can be returned as the target service response data. For example, if the call reference information calls a face recognition service, the service response data may include some facial attribute values, such as age, gender, emotion, etc. The target service response data can be the service response data returned by the corresponding server to the execution engine (i.e., the task executor).

[0093] S704: Perform packet verification on the target service return data, and determine the target service call result according to the packet verification result.

[0094] In one embodiment, performing packet verification on the target service packet data returned by calling the target service is a method for determining whether the packet verification meets expectations or whether a retry is required, wherein the packet verification result obtained by the packet verification indicates whether the target service is successfully called. Based on the call result, the target service packet data can also be further processed to realize data flow.

[0095] For the specific technical implementation of the above steps S701 to S704, please refer to Figure 10 , is a flow chart of a calling model service provided by an embodiment of the present application. Figure 10As shown in the figure, the interaction includes the execution engine Task State, the component control layer, and the component execution layer. The component execution layer can be considered an external service. The specific execution steps are as follows: First, the execution engine requests the component control layer using the component identifier. The component control layer queries the component for detailed information based on the component identifier and returns the component information (such as protocol and proto information) to the execution engine. The execution engine then generates and assembles the request parameters based on syntax descriptors such as the input path field (InputPath) and the parameter field (Parameter). The InputPath field can be used to filter the original input parameters to determine the selected content, and the Parameter field can be used to further process the selected content, such as adding new values. The actual component service is called using the call address obtained from the component control layer. The result returned by the component execution layer is then determined to determine whether the response packet meets expectations and whether a retry is required. Finally, the response packet is processed using syntax descriptors such as the result path (ResultPath) and the output path (OutputPath) to generate the output. The output of a state can be a copy of its input, the result of calling the target service, or a combination of both. This means that using ResultPath, you can combine the task result with the task input, or select one of them, as the information passed to the state output. OutputPath, on the other hand, allows you to pass a portion of the state output to the next state, filtering out unnecessary information and passing only the required information. It should be noted that the specific grammatical rules or descriptions mentioned above, such as the InputPath field, are merely examples and do not limit the specific grammatical expressions.

[0096] In one embodiment, after determining the call result of the target service, any of the following processing methods may be included: when the call result indicates that the target service call failed, if the number of call failures of the target service is less than or equal to the call number threshold, then when the interval time corresponding to the number of call failures is reached, the target service is re-called; when it is determined that the target service call failed, if the number of call failures of the target service is greater than the call number threshold, the call of the target service is stopped.

[0097] Specifically, when the call result indicates that the target service call has failed, the failure retry mechanism will be started. That is to say, if the request to the backend service fails or the verification service return packet data fails, the service request can be retried through the failure retry mechanism. The following parameters will be configured during the retry: 1) The number of retries (i.e., the call number threshold) refers to the number of retries for the request to the backend service after the target service call fails; 2) The failure retry interval refers to the interval between each retry if multiple calls fail; 3) The failure retry interval time multiple is a way to set the time of the failure retry interval. For example, an exponential backoff method can be configured. If the interval multiple is configured to 2 and the retry interval is configured to 2 seconds, the first retry time interval is 2 seconds, the second retry time interval is 4 seconds, the third retry time interval is 8 seconds, and so on. The parameters configured during the above retries can be set according to user needs, and the corresponding values are not limited here. It can be understood that the above failure retry interval and the failure retry interval time multiple can be combined to form the retry time interval, that is, the interval time corresponding to the number of call failures. If the number of call failures does not reach the set call threshold, the target service can be re-initiated after the call fails and the retry interval is reached. This process is also a retry of the request backend service. However, if the number of call failures exceeds the retry threshold, the retry of the request will be stopped. This method can avoid frequent conflicts during the request call process.

[0098] In one embodiment, after determining the call result of the target service, the method may further include: when the call result indicates that the call of the target service fails, obtaining a retry error code; and redirecting a service executed after the target service according to the retry error code.

[0099] The retry error code is returned by the execution engine and is customized by the user in the configuration file. It can be expressed in the form of a string. Figure 11 , if an error occurs in any of the steps, such as a network transmission error or a packet verification error, the retry error code can be captured through the catch field, and the downstream node pointed to by the current node can be redirected, that is, the downstream node pointed to by the current task node is changed, which corresponds to adjusting the service executed after the original target service to other services, and not going through the previous downstream node during data flow. For example, if during the service call process between the current node A and the downstream node B, the packet verification fails because the data in the data bus cannot flow to the downstream node B, then the downstream node B is replaced with another downstream node, such as node C, and the data flow is from the current node A to the downstream node C. As an extensible content, after the number of call failures of the target service exceeds the call number threshold, the service corresponding to the downstream node can be redirected to the service corresponding to other downstream nodes by capturing the retry error code.

[0100] It should be noted that the two processing methods after determining the call result of the target service can both belong to the content of the failure retry mechanism, and can both be started by the retry error code.

[0101] In summary, the embodiments of the present application have at least the following advantages:

[0102] The configuration file indicates the logical relationship between the service calls in the pending tasks. This is mainly achieved through the highly readable and compatible component identifiers in the configuration file, which reduces the complexity of the logical arrangement of service calls using code and improves the efficiency of calling different service components. Among them, the component identifier represents a unique component and detailed component configuration information can be obtained based on the component identifier. The component service is called based on the component configuration information, and the success of the call can be determined based on the service response data. If the service call fails, the failure retry mechanism will be used to re-call the target service, or the downstream node will be redirected based on the retry error code to ensure the success rate of service calls and data flow.

[0103] For the content provided in the above examples, please refer to Figure 11 , is a flow chart of a single component call provided in an embodiment of the present application, and its complete steps include the component service call logic from receiving upstream node data to sending data to downstream nodes.

[0104] Step 1: Receive the upstream node and obtain the data transmitted and shared by the upstream node, specifically the global variables, local variables, state output variables, etc. transmitted and shared on the data bus.

[0105] Step 2: Initialization step, prepare for calling component services through initialization.

[0106] Step 3: Check the state machine to see if it is running. During the task execution, the state machine may be interrupted by the user. If the state machine is not running, the subsequent steps will not be executed.

[0107] Step 4: Template parameter parsing. The template parameters here are the parameters of the node information in the state machine, which are the parameters of the upstream node, such as input parameters, output parameters, maximum query per second (QPS) and component identification.

[0108] Step 5: Get the component, mainly based on the component identifier, such as resource to obtain the component protocol, URL, PB, configuration, etc., by parsing the template parameters and component information and assembling them into request parameters.

[0109] Step 6: Request strategy check. Before starting the request, check the request strategy of the component service, for example, whether the current QPS limit of the component is met. Different component services can be configured with different request strategies, such as direct request, asynchronous callback, maximum call QPS, and retry waiting strategy.

[0110] Step 7: Protocol adaptation. Adapt the protocol to the component request protocol, build a request instance, and implement it through abstract functions. The component request protocol can include grpc, http, unixsoket (a socket method to implement inter-process communication (IPC) function), Tencentcloudsdk. Different request protocols are built for different request protocols. See the following Figure 14 The corresponding embodiments provide corresponding contents of streaming request instances and non-streaming request instances.

[0111] Step 8: Routing addressing, according to the routing strategy of the component, find the appropriate service instance and initiate the actual request. Specifically, it determines the specific service instance under a certain service based on the component routing.

[0112] Step 9: Network transmission, mainly establishing a communication connection with the appropriate service instance determined according to the routing strategy, and transmitting the component configuration information to the corresponding service provider so that the service provider can process the component configuration information.

[0113] Step 10: Protocol parsing: Determine the target business field in the service response data through protocol parsing. The business field path can be resolved using jsonpath syntax.

[0114] Step 11: Check the return packet strategy. After the connection request is successful, the return packet is checked to determine whether the call request is successful. If the call request fails, it is determined whether a retry is required. If the call request is successful, the output parameters are assembled and passed to the downstream node. In the specific return packet strategy check, the service call is determined to be successful by checking whether the result code result.code is pre-set. For example, the configuration file has the following code settings for result.code:

[0115]

[0116] The above example indicates that if the result code, result.code, returns a value of 200, a "Success!" message will be returned. This method verifies service response data under the HTTP protocol. Alternatively, the corresponding response policy check can verify whether the service response data matches the reference verification code included in the component configuration information, as described below. The specific details are not detailed here, and there is no limitation on the verification method for service response data.

[0117] Step 12: Failure retry, you can check the return packet to determine whether to start the failure retry mechanism, if any of the above steps go wrong, capture the retry error code to start the failure retry mechanism. Figure 7 The content of step S704 of the corresponding embodiment is not described in detail here. It should be noted that this is an optional step and can be skipped when the return packet verification is successful.

[0118] Step 13: Storage step, storing the service response data generated by calling the service instance and the assembled output parameters into the database.

[0119] Step 14: Check whether the process is complete. If the above steps are completed, you can prepare to pass the assembled output parameters to the downstream nodes.

[0120] Step 15: Send to downstream nodes. The data generated by calling component services can be shared to the data bus, and the data of the specified fields (ie, assembly output) can be sent to the downstream nodes.

[0121] It should be noted that the above shows the process of a single component call. The same method can be used for component calls included in each task node in the state machine. The service provided by the component can be an atomic service with a single function or a service with multiple functions, and can provide a callable interface to the outside world. The single component call can be based on Figure 2 or Figure 3 The service calling system shown is implemented. For specific physical devices or technical implementations, please refer to the above content and will not be repeated here.

[0122] See Figure 12 , is a flow chart of a service calling method provided by an embodiment of the present application. In this embodiment, the execution subject of the method is a server (such as Figure 2 The service calling method may include at least the following steps S1201 to S1206:

[0123] S1201, performing packet verification on the target service return packet data, and determining the target service call result according to the packet verification result.

[0124] S1202: Determine a target component identifier from one or more component identifiers, and obtain component configuration information of the component corresponding to the target component identifier, where the component configuration information includes call reference information of the target service.

[0125] S1203: Call the target service according to the call reference information and obtain the target service response data.

[0126] S1204: Perform packet verification on the target service return packet data, and determine the target service call result based on the packet verification result.

[0127] For details of the above steps, please refer to Figure 7 Steps S701 to S704 in the illustrated embodiment are not described in detail here.

[0128] S1205: When the call result indicates that the target service call is successful, generate first reference data according to the target service response data.

[0129] In one embodiment, when the call result determined based on the packet verification result indicates that the target service call of the target component identifier corresponding to the component is successful, operations such as adding or deleting fields in the target service packet data can be performed, such as using the ResultPath syntax descriptor mentioned in the aforementioned technical implementation to process the target service packet data. Of course, other syntaxes can also be used for processing, which is not limited here. The first reference data is matched with the requested parameters in the component configuration information to achieve the expected result, which is the final output data of the target service executed by the current task node of the task to be processed.

[0130] An optional implementation method for this step may be: obtaining second reference data, the second reference data is generated based on the service return package data obtained by calling the service corresponding to the second component identifier, the second reference data is stored in the data bus, and the service corresponding to the second component identifier is the service executed before the target service as indicated by the service call logic of the configuration file; determining the first reference data based on the second reference data and the target service return package data.

[0131] This method can be regarded as the configuration of the output data of the previous task node of the current task node. Since the upstream and downstream nodes are relative, the current task node here can be regarded as the downstream node, and the previous task node can be regarded as the upstream node. The second reference data is the result of the output of the previous service execution of the target service, that is, the result output by the upstream node to the data bus. The first reference data can be constructed based on the second reference data and the target service return packet data. For specific methods, please refer to the several methods for output flow configuration introduced below.

[0132] The entire upstream and downstream data can be transmitted through the data bus. The data bus is called the context object in the state machine and is used to store data. It can store global variables for the start of pending tasks, state output variables (variables created based on the output data of task nodes), and local variables (special variables used internally in engine loop states and branch states). See Figure 13 , is a schematic diagram of a data bus provided in an embodiment of the present application, such as Figure 13As shown in the figure, the upstream state (also understood as the upstream node) can output data and store the corresponding data in the global variables or local variables of the data bus, and the downstream state (also understood as the downstream node) can take the value of the global variable or local variable as the request input parameter. The data transfer between the upstream state and the downstream state here can be regarded as the process of calling a service instance, and the output data can be given to the next service for use. In this way, when calling a service each time, there is no need to reset the request input parameter each time. Instead, the value of the global variable or local variable is used as the input parameter to achieve data sharing, thereby reducing the redundancy of configuration file writing.

[0133] Output flow configurations offer several options: output to global variables, replace global variables, and insert variables. For example, if the service response packet contains data like {"a":"bbb"}, you can output the result to a global variable after receiving the service call response packet for downstream use. For example, using "$.x":"$.a" registers field a in the response packet to the context object and names it x. The resulting context variable contains x="bbb". If the global variable already contains x, the new data can be directly replaced, effectively changing the value of variable x. Alternatively, using "$":"$" replaces the entire response packet with the context object, resulting in a context object of {"a":"bbb"}, identical to the service response packet. To insert a field from the service response packet into an object in the context object, you can do so. “$.ab”:”$”If the original context object is x={“a”:{“c”:”c”}}, then after this output is completed, the context will become x={“a”:{“c”:”c”,”b”:{“a”:”bbb”}}}. The same is true for arrays. If the original context object is x=[{“c”:”c”}], if “$.x.[1]”:”$” is used to indicate that the return packet will be inserted into the array of the x object, then after this output is completed, the context will become x={“a”:[{“c”:”c”},{“a”:”bbb”}]}.

[0134] It can be found that during the output flow configuration process, users only need to care about the request input parameters, request output parameters, and the specific processing of the service return packet data. By defining the corresponding content in the configuration file, the complexity of the service call logic design can be further reduced, and the node data flow can be automatically realized during the service call process.

[0135] S1206, call the service corresponding to the first component identifier, and execute the service corresponding to the first component identifier according to the first reference data; wherein, the first component identifier is a component identifier among one or more component identifiers, and the service corresponding to the first component identifier is a service executed after the target service as indicated by the service call logic of the configuration file.

[0136] In one embodiment, the service corresponding to the first component identifier is called, that is, after the target service is executed, the next step is continued, and the corresponding service is called according to the component identifier (here, the first component identifier) in the next step (i.e., the next task node). In the implementation process, the first reference data can be used as the request input parameter in the call reference information for calling the service through the OutputPath syntax descriptor, that is, the output result of the current task node is passed to the next task node, and the service corresponding to the first component identifier is executed according to the request input parameter. In this process, the first reference data is used as the request input parameter, and will be converted and processed according to the data format supported by the corresponding service, and then transmitted to the service using the corresponding data transmission protocol. It can be understood that the current task node can be used as an upstream node, and the next task node can be used as a downstream node.

[0137] The construction of request input parameters (i.e., input parameters or request parameters) can include constant setting, obtaining variables through JSON, obtaining local variables, and constructing input parameters through wildcards.

[0138] In the process of constructing input parameters by setting constants, for example, by declaring "aaa" = "bbb", a request body of {"aaa": "bbb"} can be constructed when requesting a service (i.e., calling a service). This request body can be regarded as a request parameter. To obtain variables through jsonpath, you can declare "aaa.$" = "$.bbb", where the $ sign at the end of the constructed input parameter indicates that this is a variable, such as the above aaa. Its value is the value of the variable named bbb stored in the context object context. In addition, jsonpath can also support deep-level retrieval. For example, if there is a dictionary variable {"bbb": {"ccc": 123}} in the context object context, it can be represented by "aaa.$": "$.bbb.ccc", and finally a request body of {"aaa": 123} is constructed. Obtaining local variables through jsonpath is similar to obtaining variables as described above, but with a slight difference in the expression method. Local variables are specific to some engine nodes, such as the index and value of a for loop. The declaration "aaa.$$":"$$.index" is used, where the ending $$ indicates that the parameter is retrieved from a local variable, and $$.index is a special representation of the current iteration of the loop. If this is the first iteration of the loop, the resulting request body is {"aaa":0}. Input parameters are constructed using wildcards, specifically using the wildcard * to construct a list or dictionary. For example, if the context object contains a list object x = [{"a":{"b":123}}, {"a":{"c":123}], you can construct a request body of {"a":[{"b":123},{"c":123}]} using "aaa.$":"$.x.[*].b". The context object can be stored in state machine memory or in external storage such as Redis or cloud storage.

[0139] In summary, the embodiments of the present application have the following advantages:

[0140] Through the configuration file, users can focus on the input and output flow configuration without having to worry about the protocol or address of the service call, making the service call logic simpler and enabling more efficient calls. Among them, input flow configuration can be performed in a variety of ways, and data from upstream nodes can be transferred to downstream nodes according to the input flow configuration. In the output flow configuration, data output in different states can be shared to different task nodes through the data bus, and the data generated by this service call can be transferred to downstream nodes to achieve data flow.

[0141] See Figure 14, is a flow chart of a service calling method provided by an embodiment of the present application. In this embodiment, the execution subject of the method is a server (such as Figure 2 The service calling method may include at least the following steps S1401 to S1407:

[0142] S1401, obtaining a configuration file corresponding to the task to be processed, the configuration file including one or more component identifiers, each component identifier being an identifier of a component corresponding to the service.

[0143] S1402: Determine a target component identifier from one or more component identifiers, and obtain component configuration information of the component corresponding to the target component identifier, where the component configuration information includes call reference information of the target service.

[0144] For details of the above steps, please refer to Figure 7 The specific contents shown in steps S701 to S702 in the corresponding embodiment are not described in detail here.

[0145] S1403: Call the target service according to the call reference information and obtain the target service response data.

[0146] In one embodiment, the target service can be determined from multiple service instances by automatically generating a request instance based on the component configuration information of the component corresponding to the target component identifier. There are different request instances for different protocols. Figure 15 , is a schematic diagram of a request instance type provided in an embodiment of the present application, such as Figure 15 As shown, for each task node, it can include non-streaming RPC calls (function) and streaming RPC calls (datastream). Non-streaming RPC calls have a request (request) and will return a result (response), which is a simple single send and single receive. Streaming RPC calls can return results in batches. When the amount of data is large or data needs to be transmitted continuously, streaming RPC calls can be used to process and transmit data at the same time, which is a very efficient calling method. Due to different protocols, the corresponding different request instances will also construct request input parameters in different ways. For example, the grpc protocol request needs to construct a grpc request instance (grpc-func), and then through the aforementioned Figure 12 The request body is generated by constructing the request parameters in the corresponding embodiment, and then the request body is injected into the request instance through the reflection mechanism, and then a request is initiated to the corresponding server. It should be noted that the automatically generated request instance here can be the best instance specified by the component routing. The request instance can be used to match the same service instance when calling the service, and the service instance that matches the same as the request instance is the target service in the embodiment of this application.

[0147] For more information about this step, see Figure 7 The specific content shown in step S703 in the corresponding embodiment is not repeated here.

[0148] S1404: Obtain verification information included in the target service response packet data.

[0149] In one embodiment, the verification information may include two fields, namely, a verification path and a verification value. The verification path indicates the path in the return packet that needs to be verified through jsonpath, and the verification value indicates extracting the verification path in the return packet.

[0150] S1405: Compare the reference verification information included in the component configuration information with the verification information included in the target service response packet data to obtain a response packet verification result.

[0151] In one embodiment, the component configuration information may include reference verification information, which may also include two fields: a verification path and a verification value. The reference verification information included in the component configuration information is compared with the verification information included in the service response packet data. In essence, the two verification fields included in the verification data are compared separately to check whether the corresponding fields or values match, thereby obtaining a response packet verification result. There are two cases for the response packet verification result: one is that the verification of the target service response packet data is successful, and the other is that the verification of the target response packet data fails. When the verification is successful, it indicates that the reference verification information in the component configuration information and the verification information in the target service response packet data are the same. When the verification fails, it indicates that the reference verification information in the component configuration information and the verification information in the target service response packet data are different.

[0152] For example, suppose the target service response data received is {"a":"bbb"}, and the component configuration contains verification information, with the verification path being "$.a" and the verification value being bbb. This means that the a field in the verification service response data must be equal to bbb. A comparison shows that the target service response data contains the verification field included in the component configuration information and the values are the same, indicating a successful verification.

[0153] S1406: If the return packet verification result indicates that the verification information is consistent with the reference verification information, the target service call result is determined to be a first call result, and the first call result is used to indicate that the target service call is successful.

[0154] In one embodiment, by comparing the reference verification information with the two verification fields included in the verification information, a packet verification result can be obtained to determine whether the reference verification information and the verification information are consistent. Still using the above example, based on the target service response packet data {"a":"bbb"}, which indicates that the value of the a field must be equal to bbb, it can be found that the verification is successful, indicating that the RPC call was successful. In other words, the target service call result indicates that the target service call was successful.

[0155] S1407: If the return packet verification result indicates that the verification information is inconsistent with the reference verification information, the target service call result is determined to be a second call result, and the second call result is used to indicate that the target service call failed.

[0156] In one embodiment, the packet return verification result is obtained in the same manner as in the above step S1405. If the packet return verification result indicates that the verification information and the reference verification information are inconsistent, for example, the service packet return data does not contain the field that needs to be verified in the component configuration information (i.e., the verification path), or the verification path is the same but the verification value is different, the verification will fail, indicating that the RPC call failed. Then, the result of calling the target service this time indicates that the target service call failed. The above verification of the service packet return data can help the user automatically determine whether it is the content of the required target field, so that the user can perform subsequent operations based on the verification result, such as enabling the failure retry mechanism mentioned above, or capturing the retry error code, etc.

[0157] In summary, the embodiments of the present application include at least the following advantages:

[0158] For the target service, the request instances constructed under different protocols include streaming request instances in addition to the commonly used non-streaming request instances, enriching the request instances for calling the service. Furthermore, the call success is determined based on the service response data of the target service. Specifically, the service response data is matched with the verification information in the component configuration information, including the verification path field and verification value, to ensure the accuracy of the service call.

[0159] See Figure 16 , Figure 16 This is a structural diagram of a service calling device provided in an embodiment of the present application. The above service calling device can be a computer program (including program code) running on a server, for example, the service calling device is an application software; the service calling device can be used to execute the corresponding steps in the method provided in an embodiment of the present application. Figure 16 As shown, the service calling device 160 may include: an acquisition module 1601, a determination module 1602, a calling module 1603, and a verification module 1604, wherein:

[0160] The acquisition module 1601 is used to acquire a configuration file corresponding to the task to be processed, where the configuration file includes one or more component identifiers, each of which is an identifier of a component corresponding to the service;

[0161] Determining module 1602, configured to determine a target component identifier from one or more component identifiers, and obtain component configuration information of the component corresponding to the target component identifier, wherein the component configuration information includes call reference information of the target service;

[0162] The calling module 1603 is used to call the target service according to the calling reference information and obtain the target service response data;

[0163] The verification module 1604 is used to perform packet verification on the target service return data and determine the call result of the target service according to the packet verification result.

[0164] In one embodiment, the service calling device 160 further includes: a generating module 1605, wherein:

[0165] A generating module 1605 is configured to generate first reference data according to the target service response data when the call result indicates that the target service call is successful;

[0166] Calling module 1603 is used to call the service corresponding to the first component identifier and execute the service corresponding to the first component identifier according to the first reference data; wherein, the first component identifier is a component identifier among one or more component identifiers, and the service corresponding to the first component identifier is the service executed after the target service as indicated by the service calling logic of the configuration file.

[0167] In one embodiment, the generation module 1605 is specifically used to: obtain second reference data, the second reference data is generated based on the service return package data obtained by calling the service corresponding to the second component identifier, the second reference data is stored in the data bus, and the service corresponding to the second component identifier is the service executed before the target service as indicated by the service call logic of the configuration file; determine the first reference data based on the second reference data and the target service return package data.

[0168] In one embodiment, the calling module 1603 is specifically used to: when the calling result indicates that the target service call fails, if the number of call failures of the target service is less than or equal to the call number threshold, then when the interval time corresponding to the number of call failures is reached, re-call the target service; when the calling result indicates that the target service call fails, if the number of call failures of the target service is greater than the call number threshold, stop calling the target service.

[0169] In one embodiment, the service calling device 160 further includes a redirection module 1606 for: obtaining a retry error code when the calling result indicates that the target service call fails; and redirecting the service executed after the target service according to the retry error code.

[0170] In one embodiment, the verification module 1604 is specifically used to: obtain the verification information included in the target service return packet data; compare the reference verification information included in the component configuration information with the verification information included in the target service return packet data to obtain a return packet verification result; if the return packet verification result indicates that the verification information and the reference verification information are consistent, then the call result of the target service is determined to be the first call result, and the first call result is used to indicate that the call of the target service is successful; if the return packet verification result indicates that the verification information and the reference verification information are inconsistent, then the call result of the target service is determined to be the second call result, and the second call result is used to indicate that the call of the target service has failed.

[0171] In one embodiment, the service calling device 160 also includes a control module 1607, which is used to: control the user terminal to display a component creation interface, the component creation interface includes one or more associated parameter input boxes associated with the component to be created; obtain data entered into one or more associated parameter input boxes; create a component based on the data entered into one or more associated parameter input boxes; control the user terminal to display a component management interface, and control the user terminal to display the associated parameters of the created component in the component management interface.

[0172] The functions of each functional module in the service calling device provided by this application can be specifically implemented according to the method in the above method embodiment. The specific implementation process can refer to the relevant description of the above method embodiment, which will not be repeated here. In addition, the description of the beneficial effects of adopting the same method will not be repeated.

[0173] See Figure 17 , is a structural diagram of a computer device provided in an embodiment of the present application. The computer device 170 may include a processor 1701, a memory 1702, a network interface 1703, and at least one communication bus 1704. Among them, the processor 1701 is used to schedule computer programs and may include a central processing unit, a controller, and a microprocessor; the memory 1702 is used to store computer programs and may include a high-speed random access memory RAM, a non-volatile memory, such as a disk storage device, a flash memory device; the network interface 1703 may optionally include a standard wired interface, a wireless interface (such as a WI-FI interface), and provide data communication functions. The communication bus 1704 is responsible for connecting various communication elements. The computer device 170 may correspond to the task executor 205 mentioned above.

[0174] The processor 1701 may be configured to call a computer program in the memory to perform the following operations:

[0175] Obtain the configuration file corresponding to the task to be processed, which includes one or more component identifiers, each of which is the identifier of the component corresponding to the service; determine the target component identifier from the one or more component identifiers, and obtain the component configuration information of the component corresponding to the target component identifier, wherein the component configuration information includes the call reference information of the target service; call the target service according to the call reference information to obtain the target service return packet data; perform a return packet check on the target service return packet data, and determine the call result of the target service according to the return packet check result.

[0176] In one embodiment, the processor 1701 is also used to: when the call result indicates that the target service call is successful, generate first reference data based on the target service return package data; call the service corresponding to the first component identifier, and execute the service corresponding to the first component identifier according to the first reference data; wherein the first component identifier is a component identifier among one or more component identifiers, and the service corresponding to the first component identifier is a service indicated by the service call logic of the configuration file to be executed after the target service.

[0177] In one embodiment, the processor 1701 is specifically used to: obtain second reference data, the second reference data is generated based on the service return package data obtained by calling the service corresponding to the second component identifier, the second reference data is stored in the data bus, and the service corresponding to the second component identifier is the service executed before the target service indicated by the service call logic of the configuration file; determine the first reference data based on the second reference data and the target service return package data.

[0178] In one embodiment, the processor 1701 is also used to: when the call result indicates that the target service call fails, if the number of call failures of the target service is less than or equal to the call number threshold, then re-call the target service when the interval time corresponding to the number of call failures is reached; when the call result indicates that the target service call fails, if the number of call failures of the target service is greater than the call number threshold, stop calling the target service.

[0179] In one embodiment, the processor 1701 is further configured to: obtain a retry error code when the call result indicates that the target service call fails; and redirect a service executed after the target service according to the retry error code.

[0180] In one embodiment, the processor 1701 is specifically used to: obtain the verification information included in the target service return packet data; compare the reference verification information included in the component configuration information with the verification information included in the target service return packet data to obtain a return packet verification result; if the return packet verification result indicates that the verification information and the reference verification information are consistent, then the call result of the target service is determined to be the first call result, and the first call result is used to indicate that the call of the target service is successful; if the return packet verification result indicates that the verification information and the reference verification information are inconsistent, then the call result of the target service is determined to be the second call result, and the second call result is used to indicate that the call of the target service has failed.

[0181] In one embodiment, the processor 1701 is also used to: control the user terminal to display a component creation interface, the component creation interface includes one or more associated parameter input boxes associated with the component to be created; obtain data entered into one or more associated parameter input boxes; create a component based on the data entered into one or more associated parameter input boxes; control the user terminal to display a component management interface, and control the user terminal to display the associated parameters of the created component in the component management interface.

[0182] It should be understood that the computer device 170 described in the embodiment of the present application can execute the above Figure 7 The description of the service calling method in the corresponding embodiment can also be performed as described above. Figure 16 The description of the service calling device 160 in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of adopting the same method will not be repeated here either.

[0183] In addition, it should be noted that: the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores a computer program executed by the computer device 170 of the aforementioned service call, and the computer program includes program instructions. When the processor executes the program instructions, the aforementioned Figure 7 The description of the above-mentioned service calling method in the corresponding embodiment will therefore not be repeated here. In addition, the description of the beneficial effects of adopting the same method will not be repeated. For technical details not disclosed in the computer-readable storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application.

[0184] The computer-readable storage medium may be the service invocation device provided in any of the aforementioned embodiments or the internal storage unit of the computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computer device. Furthermore, the computer-readable storage medium may also include both the internal storage unit of the computer device and an external storage device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store data that has been output or is to be output.

[0185] In one aspect of the present application, a computer program product or computer program is provided. The computer program product or computer program includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the service invocation method provided in one aspect of an embodiment of the present application.

[0186] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0187] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A service calling method, characterized in that: The method comprises: Obtain a configuration file corresponding to the task to be processed, wherein the configuration file includes one or more component identifiers, each of which is an identifier of a component corresponding to the service; Determine a target component identifier from the one or more component identifiers, and obtain component configuration information of the component corresponding to the target component identifier, wherein the component configuration information includes call reference information of the target service, and the call reference information is used to indicate a call method of the target service; In the case where there are multiple replica services corresponding to the target service, determining the target replica service from the multiple replica services according to the service call status of each replica service; the multiple replica services implement the same function; Call the target replica service according to the call reference information to obtain target service response data; Performing packet verification on the target service return data, and determining the call result of the target service according to the packet verification result; When the call result indicates that the call of the target service fails, a retry error code is obtained, and the service executed after the target service is redirected according to the retry error code. Redirecting the service executed after the target service means: changing the first service to be executed next after the target service as indicated by the service call logic of the configuration file to the second service to be executed after the target service as indicated by the service call logic of the configuration file, where the second service is different from the first service.

2. The method according to claim 1, characterized in that The method further comprises: When the call result indicates that the target service call is successful, generating first reference data according to the target service return packet data; calling a service corresponding to the first component identifier, and executing the service corresponding to the first component identifier according to the first reference data; The first component identifier is a component identifier among the one or more component identifiers, and the service corresponding to the first component identifier is a service executed after the target service as indicated by the service call logic of the configuration file.

3. The method according to claim 2, characterized in that When the call result indicates that the target service call is successful, generating first reference data according to the target service return packet data includes: Obtaining second reference data, where the second reference data is generated based on service response data obtained by invoking a service corresponding to a second component identifier, the second reference data being stored in a data bus, and the service corresponding to the second component identifier being a service executed before the target service as indicated by the service invocation logic of the configuration file; The first reference data is determined according to the second reference data and the target service return packet data.

4. The method according to claim 1, wherein The method further includes any of the following: When the call result indicates that the target service call fails, if the number of call failures of the target service is less than or equal to the call number threshold, the target service is called again when the interval time corresponding to the number of call failures is reached; When the call result indicates that the target service call fails, if the number of call failures of the target service is greater than the call number threshold, the call of the target service is stopped.

5. The method according to claim 1, wherein The component configuration information includes reference verification information, and performing packet verification on the target service return data, and determining the call result of the target service according to the packet verification result, includes: Obtain verification information included in the target service return packet data; Comparing the reference verification information included in the component configuration information with the verification information included in the target service return packet data to obtain a return packet verification result; If the return packet verification result indicates that the verification information is consistent with the reference verification information, determining that the target service call result is a first call result, where the first call result is used to indicate that the target service call is successful; If the return packet verification result indicates that the verification information is inconsistent with the reference verification information, the call result of the target service is determined to be a second call result, and the second call result is used to indicate that the call of the target service has failed.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: Controlling the user terminal to display a component creation interface, wherein the component creation interface includes one or more associated parameter input boxes associated with the component to be created; Obtaining data entered into the one or more associated parameter input boxes; Creating a component according to the data input into the one or more associated parameter input boxes; The user terminal is controlled to display a component management interface, and the user terminal is controlled to display associated parameters of the created component in the component management interface.

7. A service calling device, characterized in that: include: An acquisition module is used to acquire a configuration file corresponding to the task to be processed, wherein the configuration file includes one or more component identifiers, each of which is an identifier of a component corresponding to the service; a determination module, configured to determine a target component identifier from the one or more component identifiers, and obtain component configuration information of the component corresponding to the target component identifier, wherein the component configuration information includes call reference information of the target service, and the call reference information is used to indicate a call method of the target service; The determining module is further configured to determine a target replica service from among multiple replica services corresponding to the target service based on service call conditions of the respective replica services when multiple replica services exist; the multiple replica services implement the same function; A calling module, configured to call the target replica service according to the calling reference information and obtain target service response data; A verification module is used to perform packet verification on the target service return data and determine the call result of the target service according to the packet verification result; The redirection module is used to obtain a retry error code when the call result indicates that the target service call fails, and redirect the service executed after the target service according to the retry error code. Redirecting the service executed after the target service means: changing the first service that is indicated by the service call logic of the configuration file to be executed next after the target service to the second service that is indicated by the service call logic of the configuration file to be executed after the target service, and the second service is different from the first service.

8. A computer device, characterized in that: include: processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide network communication function, the memory is used to store program code, and the processor is used to call the program code to execute the service calling method described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that include: The computer-readable storage medium stores a computer program, wherein the computer program includes program instructions. When the program instructions are executed by a processor, the service calling method according to any one of claims 1 to 6 is executed.

10. A computer program product, characterized in that The computer program product includes computer instructions, which are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the service calling method described in any one of claims 1 to 6.

Images