A method and apparatus for processing a call request

Abstract

The application discloses a kind of processing method and device of calling request, it is related to computer technical field.The specific implementation of the method includes: receiving call request;According to request parameter and pre-generated service template, generate the target worker service corresponding to call request;According to interface parameter in service parameter, determine the service interface of target worker service, and send other service parameters except interface parameter in service parameter to the server corresponding to target worker service through service interface, to make server handle call request;Receive the processing result returned by server through service interface.The implementation can adapt to various complex and changeable service environment, meet the processing target of various call requests, be extremely easy to operate, do not need to be frequently issued, while improving the efficiency of arrangement, can reduce development and maintenance cost, guarantee the stability of service.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and apparatus for processing call requests. Background Technology

[0002] With the rapid development of computer technology, the functions of various applications are constantly expanding, and the corresponding application logic is becoming more and more complex. In order to prevent the development, maintenance, and testing of application functions from becoming too complex, resulting in high costs and frequent errors, it is usually chosen to break down application functions into multiple small-granular services and implement application logic through microservice orchestration.

[0003] As a typical service orchestration framework, Netflix Conductor enables worker-based task development, orchestrating different nodes within a worker into a directed acyclic graph workflow to achieve corresponding task functions, ensuring the orderly execution of task logic. For example, a task might be an HTTP request.

[0004] In existing HTTP request processing, a custom worker interface class is typically defined for each HTTP request, task logic is written for testing, and the class is registered and deployed after successful testing. However, since different requests have different interface URLs, request parameters, etc., and HTTP requests change frequently, dealing with a huge volume of requests requires frequent changes to worker definitions, testing, and redeployment, resulting in excessively high development and maintenance costs, low efficiency, and impacting the stability of the request service. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a method and apparatus for processing call requests, which can adapt to various complex and ever-changing service environments, meet the processing goals of various call requests, are easy to operate, do not require frequent deployment, improve orchestration efficiency, reduce development and maintenance costs, and ensure service stability.

[0006] To achieve the above objectives, according to one aspect of the present invention, a method for processing a call request is provided, comprising:

[0007] Receive a call request; wherein the call request indicates request parameters;

[0008] Based on the request parameters and the pre-generated service template, a target worker service corresponding to the call request is generated; wherein, the target worker service indicates one or more service parameters, and the service template is generated by aggregating the worker services corresponding to multiple historical call requests respectively;

[0009] Based on the interface parameters in the service parameters, the service interface of the target worker service is determined, and the other service parameters in the service parameters, except for the interface parameters, are sent to the server corresponding to the target worker service through the service interface so that the server can process the call request.

[0010] Receive the processing result returned by the server through the service interface.

[0011] Optionally, generating the target worker service corresponding to the call request based on the request parameters and the pre-generated service template includes:

[0012] Based on the template parameters required by the service template, the target request parameters corresponding to the template parameters are determined from the request parameters, and the target request parameters are filled into the service template to generate the service parameters corresponding to the service template;

[0013] The target worker service is generated based on the service parameters in the filled-in service template and other request parameters other than the target request parameters.

[0014] Optionally, it also includes:

[0015] Retrieve multiple historical call requests; wherein, the historical call requests indicate worker services including historical request parameters and historical request functions;

[0016] The historical request parameters and the historical request functions are aggregated respectively to determine the template parameters and template functions of the service template;

[0017] Based on the template parameters and the template function, a service template corresponding to the worker service is generated.

[0018] Optionally, the template parameters include mandatory parameters, and also include:

[0019] Determine whether the request parameters include the target request parameters corresponding to the required parameters;

[0020] If the request parameters do not include the target request parameters corresponding to the required parameters, the call request is rejected.

[0021] Optionally, the service parameters include a URL; sending the other service parameters besides the interface parameters to the server corresponding to the target worker service through the service interface includes:

[0022] Determine whether the destination address of the target worker service is empty;

[0023] If the URL is empty, the other service parameters are sent to the service interface through the default gateway, so that the other service parameters are sent to the server through the service interface;

[0024] In the case of a request where the URL is not empty, the URL is mapped to the service interface, and the other service parameters are sent to the service interface so that the other service parameters can be sent to the server through the service interface.

[0025] Optionally, it also includes:

[0026] Based on the processing result, update the execution status of the target worker service;

[0027] If the processing result is successful, the processing data corresponding to the processing result is written to the output log, and the execution status is updated to successful execution.

[0028] If the processing result is a failure, the processing result is written to the output log, and the execution status is updated to execution failure.

[0029] Optionally, where:

[0030] When the request is an HTTP request, the HTTP request includes any of the following: GET request, POST request, PUT request, DELETE request, HEAD request, OPTIONS request, TRACE request, and CONNECT request.

[0031] According to another aspect of the present invention, a processing apparatus for a call request is provided, comprising:

[0032] A receiving module is used to receive a call request; wherein the call request indicates request parameters;

[0033] The generation module is used to generate a target worker service corresponding to the call request based on the request parameters and the pre-generated service template; wherein, the target worker service indicates one or more service parameters, and the service template is generated by aggregating the worker services corresponding to multiple historical call requests respectively;

[0034] The service interface determination module is used to determine the service interface of the target worker service based on the interface parameters in the service parameters, and send the other service parameters in the service parameters other than the interface parameters to the server corresponding to the target worker service through the service interface so that the server can process the call request;

[0035] The receiving module is also used to receive the processing result returned by the server through the service interface.

[0036] According to another aspect of the present invention, an electronic device for processing call requests is provided, comprising:

[0037] One or more processors;

[0038] Storage device for storing one or more programs.

[0039] When the one or more programs are executed by the one or more processors, the one or more processors implement the call request processing method provided by the present invention.

[0040] According to another aspect of the present invention, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method for processing invocation requests provided by the present invention.

[0041] One embodiment of the above invention has the following advantages or beneficial effects: by analyzing historical call requests, aggregating historical request parameters and historical request functions, and generating a service template for the worker service corresponding to the call request, and then filling the service template according to the request parameters to generate the target worker service when processing a new call request, the technical means overcomes the existing technical problems of frequent call request changes, repeated testing, and repeated deployments, which lead to high development and maintenance costs, low efficiency, and affect the stability of the request service. This achieves the technical effect of being able to adapt to various complex and changing service environments, meet the processing goals of various call requests, be easy to operate, and not require frequent deployments, thereby improving orchestration efficiency while reducing development and maintenance costs and ensuring service stability.

[0042] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0043] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0044] Figure 1 This is a schematic diagram of the main flow of the method for processing a call request according to an embodiment of the present invention;

[0045] Figure 2 This is a schematic diagram of the main flow of the worker service generation method according to an embodiment of the present invention;

[0046] Figure 3 This is a schematic diagram of the main flow of the service template generation method according to an embodiment of the present invention;

[0047] Figure 4 This is a schematic diagram of the main flow of the service parameter forwarding method according to an embodiment of the present invention;

[0048] Figure 5 This is a schematic diagram of the cluster scaling-down process according to an embodiment of the present invention;

[0049] Figure 6(a) is a schematic flowchart of creating an HBase cluster according to an embodiment of the present invention. Figure 1 ;

[0050] Figure 6(b) is a schematic flowchart of creating an HBase cluster according to an embodiment of the present invention. Figure 2 ;

[0051] Figure 6(c) is a schematic flowchart of creating an HBase cluster according to an embodiment of the present invention. Figure 3 ;

[0052] Figure 7 This is a schematic diagram of the main flow of the worker service output method according to an embodiment of the present invention;

[0053] Figure 8 This is a schematic diagram of the main modules of a call request processing device according to an embodiment of the present invention;

[0054] Figure 9 An exemplary system architecture diagram is shown, illustrating a method or apparatus for processing invocation requests suitable for application in embodiments of the present invention.

[0055] Figure 10 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

[0056] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0057] Figure 1 This is a schematic diagram of the main flow of the method for processing a call request according to an embodiment of the present invention, as shown below. Figure 1 As shown, the method for processing a call request according to the present invention includes the following steps:

[0058] In an HTTP request task, the worker sends instructions to different services based on the request's direction to fulfill the corresponding event request processing set.

[0059] Step S101: Receive a call request; wherein the call request indicates request parameters.

[0060] In this embodiment of the invention, the call request can be an HTTP request, which can be any of the following: GET request, POST request, PUT request, DELETE request, HEAD request, OPTIONS request, TRACE request, CONNECT request, etc.

[0061] Step S102: Generate a target worker service corresponding to the call request based on the request parameters and the pre-generated service template; wherein, the target worker service indicates one or more service parameters, and the service template is generated by aggregating the worker services corresponding to multiple historical call requests.

[0062] In this embodiment of the invention, the service template includes template parameters and template functions. The template parameters include required parameters and optional parameters. For example, taking an HTTP request service template as an example, the required parameters of the service template include requestPath and requestType, and the optional parameters include url, headerMaps, and jsonHeaderMaps. Specifically:

[0063] `requestPath` is a required parameter that specifies the path corresponding to the HTTP request method, such as: ` / jmr / v1 / clustermanager / releaseShrinkedInstances`.

[0064] The `requestType` parameter is required and indicates the types of HTTP requests that are supported, including GET, POST, and POST with header maps. The default is POST.

[0065] The url parameter is optional and can be used to customize the access URL. For example, the url could be http: / / baize-test.jdcloud.com. If the url is empty, the default access will be to the JFC-API gateway.

[0066] `headerMaps` is an optional parameter. It takes effect when `requestType` is `post_with_headermaps` and the data type is `Map`.<String,String> .

[0067] jsonHeaderMaps is an optional parameter. It takes effect when requestType is set to post_with_headermaps. The data type is String, corresponding to Map.<String,String> The converted JSON string, for example, "{\"X-API\":\"baize.hbase.cluster.ip_server.list.upd--ate\",\"Content-Type\":\"application / json\"}".

[0068] In this embodiment of the invention, the template parameters may also include Headers parameters or Params parameters, which can be determined according to the actual implementation needs of the call request. Accordingly, before generating the target worker service, it is determined whether Headers parameters or Params parameters are needed. If Headers parameters are needed, headerMaps are assembled; if Params parameters are needed, ParamsMaps are assembled, and they are assembled into parameter formats such as Form Data, RAW, and Params according to different HTTP request types. The specific format can be determined according to the service interface.

[0069] In embodiments of the present invention, such as Figure 2 As shown, the method for generating worker services according to the present invention includes the following steps:

[0070] Step S201: Based on the template parameters required by the service template, determine whether the request parameters include the target request parameters corresponding to the mandatory parameters of the service template. If the request parameters include the target request parameters corresponding to the mandatory parameters, proceed to step S202; if the request parameters do not include the target request parameters corresponding to the mandatory parameters, proceed to step S205.

[0071] In this embodiment of the invention, taking an HTTP request as an example, based on the template parameters (requestPath, requestType, url, headerMaps, and jsonHeaderMaps) required by the service template of the HTTP request, it is determined whether the request parameters of the received HTTP request include the target request parameters corresponding to the required parameters (requestPath and requestType).

[0072] Step S202: Determine the target request parameters corresponding to the optional parameters of the service template.

[0073] In this embodiment of the invention, taking an HTTP request as an example, the target request parameters corresponding to the optional parameters (url, headerMaps, and jsonHeaderMaps) in the received HTTP request are determined according to the template parameters required by the service template of the HTTP request.

[0074] Step S203: Fill the target request parameters into the service template to generate the service parameters corresponding to the service template.

[0075] In this embodiment of the invention, taking an HTTP request as an example, the target request parameters corresponding to requestPath, requestType, url, headerMaps and jsonHeaderMaps are determined according to the request parameters of the HTTP request, and the target request parameters are filled into the service template to generate the service parameters corresponding to the service template.

[0076] Step S204: Generate the target worker service based on the service parameters in the filled service template and other request parameters other than the target request parameters.

[0077] In this embodiment of the invention, other request parameters besides the template parameters are kept as they are used as other service parameters. Based on the service parameters and other service parameters determined in step S203, the target worker service is generated.

[0078] Step S205: Deny the call request.

[0079] In this embodiment of the invention, the worker service generation method of the present invention can generate a target worker service corresponding to a call request based on a pre-arranged service template corresponding to the call request. Thus, for each call request, there is no need to repeatedly write the worker; only the corresponding service template needs to be filled in according to the request parameters of the call request to generate the corresponding worker service, thereby improving processing efficiency and reducing development and maintenance costs.

[0080] With the worker service generation method of the present invention, when orchestrating workflows in the Netflix Conductor service orchestration framework, for related HTTP requests, there is no need to write workers and deploy services independently. Instead, a general service template can be used directly, and the required input parameters can be configured to achieve rapid orchestration of the corresponding services.

[0081] In embodiments of the present invention, such as Figure 3 As shown, the method for generating a service template according to the present invention includes the following steps:

[0082] Step S301: Obtain multiple historical call requests; wherein, the historical call request indicates a worker service including historical request parameters and historical request functions.

[0083] Step S302: Aggregate the historical request parameters and historical request functions respectively to determine the template parameters and template functions of the service template.

[0084] Step S303: Generate the service template corresponding to the worker service based on the template parameters and template function.

[0085] In this embodiment of the invention, the service template determination method can be used for worker service orchestration of any type of call request. The service template determination method of the present invention can be applied to the definition of service templates for worker services such as HTTP, TCP, general Windows, and Linux command execution.

[0086] Furthermore, different types of call requests can correspond to different types of worker service templates, and parameters and nodes can be adjusted adaptively according to actual needs.

[0087] In this embodiment of the invention, the service template generation method of the present invention can determine the service template corresponding to the call request by analyzing historical call requests, thereby eliminating the need to rewrite the worker for each call request, improving orchestration efficiency, and reducing development and maintenance costs.

[0088] In this embodiment of the invention, the code implementation example of the HTTP request worker service template (referred to as http_worker) is as follows:

[0089]

[0090]

[0091]

[0092]

[0093]

[0094]

[0095] Step S103: Based on the interface parameters in the service parameters, determine the service interface of the target worker service, and send the other service parameters in the service parameters, excluding the interface parameters, to the server corresponding to the target worker service through the service interface, so that the server can process the call request.

[0096] In this embodiment of the invention, taking an HTTP request as an example, the service parameter corresponding to the requestPath of the target worker service is the interface parameter, and the value of the interface parameter is the service interface.

[0097] In embodiments of the present invention, such as Figure 4 As shown, the service parameter forwarding method of the present invention includes the following steps:

[0098] Step S401: Based on the service parameters, determine whether the URL of the target worker service is empty. If the URL is empty, proceed to step S402; if the URL is not empty, proceed to step S403.

[0099] Step S402: Send other service parameters to the service interface through the default gateway, so that the other service parameters can be sent to the server through the service interface.

[0100] In this embodiment of the invention, for example, the default gateway is the JFC-API gateway.

[0101] Step S403: Use URL mapping to the service interface to send other service parameters to the service interface, so that the other service parameters can be sent to the server through the service interface.

[0102] In this embodiment of the invention, when handling HTTP requests using URL-specified routing, a mapping between the URL and the service interface is established based on the URL address, such as http: / / baize-test.jdcloud.com, thereby sending service parameters.

[0103] In this embodiment of the invention, the service parameter forwarding method of the present invention can determine the forwarding method of the service parameters according to the URL of the worker service, thereby facilitating the server to process the call request. Furthermore, for various types of HTTP requests, regardless of whether a specified access URL exists, they can be processed through http_worker, thereby improving orchestration efficiency and reducing development and maintenance costs.

[0104] In this embodiment of the invention, the execution of the worker service is defined by the run method in WorkerRunner during the target worker service's runtime. An example of the code implementation is as follows:

[0105]

[0106]

[0107] In this embodiment of the invention, the general template for HTTP requests is applicable to a variety of scenarios. In the conductor orchestration process, the input parameters of the HTTP request worker node and the corresponding parameters of the service interface can be adjusted as needed to realize the processing of the call request in the corresponding scenario. As shown in Demo1 to Demo3 below, these are code implementation examples of http_worker for scenarios such as inserting logs, interface callbacks, and updating node status.

[0108] Demo1: Inserting an operation log by calling the JD.com internal JFC-API gateway interface.

[0109]

[0110] Demo2: Calling the nurse API callback at a specified URL

[0111]

[0112]

[0113] Demo3: Calling the internal gateway interface to update the service status of a single node

[0114]

[0115]

[0116] In this embodiment of the invention, as shown in Demo1 to Demo3, when adding an HTTP request to the orchestration process, only the corresponding code needs to be copied and the values ​​of the template parameters modified to complete the request invocation orchestration. The process then runs according to the updated parameters, which is convenient and quick, eliminating the need to repeatedly write and publish worker services. If the service needs to be changed, the process definition of the service template is modified, and the process is updated. The next time it is executed, the latest process definition is used to call the latest service.

[0117] In this embodiment of the invention, the general http_worker provides a more significant improvement in orchestration efficiency when orchestrating workflows that include multiple HTTP requests, such as... Figure 5 As shown, the cluster scaling down process includes 3 http_workers:

[0118] Call the logging interface to record a result log of the cluster scaling down process (the service of the cluster scaling down node has been stopped);

[0119] Call the resource release interface to release cloud host resources that the cluster needs to shrink;

[0120] Call the logging interface to record an operation log indicating that the cluster has been scaled down.

[0121] In this embodiment of the invention, as shown in Figure 6(a), the flowchart for creating an HBase cluster is a directed acyclic graph consisting of multiple nodes. The logic for creating an HBase cluster is implemented according to the order shown in the figure. The process for creating an HBase cluster may include one or more HTTP request nodes. For example, the black box corresponds to the http_worker for updating operation logs.

[0122] In this embodiment of the invention, as shown in Figure 6(b), the definition of http_worker is implemented in JSON format. During the HBase cluster creation process, when the URL of the request parameter of the call request (i.e., the HTTP request) corresponding to the http_worker for updating the operation log is empty, the default request is made to the JD.com internal gateway interface (e.g., JFC-API gateway). The JFC-API gateway forwards all request parameters except requestPath and requestType to the service interface / cmdb / v1 / log / newOperLogRecord as is. The input parameters and return results of the target worker service corresponding to the HTTP request are shown in Figure 6(c).

[0123] Step S104: Receive the processing result returned by the server through the service interface.

[0124] In this embodiment of the invention, the service template receives the processing result of the call request returned by the corresponding server through the service interface, and can continue to serve other call requests to generate the target worker service to process the corresponding call request.

[0125] In embodiments of the present invention, such as Figure 7 As shown, the output method of the worker service of the present invention includes the following steps:

[0126] Step S701: Update the execution status of the target worker service based on the processing result.

[0127] Step S702: Determine whether the processing result is successful. If the processing result is successful, proceed to step S703; if the processing result is unsuccessful, proceed to step S704.

[0128] Step S703: Write the processing data corresponding to the processing result into the output log and update the execution status to execution success.

[0129] In this embodiment of the invention, the output log and execution status can be log templates independent of the service template of the worker service, which are filled in according to the processing results to form the output log; or they can be template parameters of the service template of the worker service, which are filled in according to the processing results to generate service parameters corresponding to the output log of the target worker service.

[0130] Step S704: If the processing result is a failure, write the processing result to the output log and update the execution status to execution failure.

[0131] In this embodiment of the invention, the execution results of the worker service can be output through steps such as the output of the worker service, so as to sort out the execution results in a timely manner for reference in subsequent processes, or to analyze problems, improve the service template, reduce development and maintenance costs, and ensure the stability of the worker service for the call request.

[0132] In this embodiment of the invention, the following steps are employed: receiving a call request; the call request indicating request parameters; generating a target worker service corresponding to the call request based on the request parameters and a pre-generated service template; the target worker service indicating one or more service parameters, the service template being generated by aggregating worker services corresponding to multiple historical call requests; determining the service interface of the target worker service based on the interface parameters in the service parameters, and sending the other service parameters in the service parameters, excluding the interface parameters, to the server corresponding to the target worker service through the service interface, so that the server processes the call request; and receiving the processing result returned by the server through the service interface. These steps enable the invention to adapt to various complex and changing service environments, meet the processing goals of various call requests, are easy to operate, do not require frequent deployments, improve orchestration efficiency, reduce development and maintenance costs, and ensure service stability.

[0133] Figure 8 This is a schematic diagram of the main modules of a call request processing device according to an embodiment of the present invention, such as... Figure 8 As shown, the call request processing apparatus 800 of the present invention includes:

[0134] The receiving module 801 is used to receive a call request; wherein the call request indicates request parameters.

[0135] In this embodiment of the invention, the receiving module 801 is used to receive a call request; wherein, the call request may be an HTTP request, and the HTTP request may be any of the following: GET request, POST request, PUT request, DELETE request, HEAD request, OPTIONS request, TRACE request, CONNECT request, etc.

[0136] The generation module 802 is used to generate a target worker service corresponding to the call request based on the request parameters and the pre-generated service template; wherein the target worker service indicates one or more service parameters, and the service template is generated by aggregating the worker services corresponding to multiple historical call requests.

[0137] In this embodiment of the invention, the generation module 802 is used to generate a target worker service corresponding to the call request based on the request parameters, the service template generated by the service template generation method of the present invention, and the worker service generation method of the present invention. The service template includes template parameters and template functions, and the template parameters include required parameters and optional parameters.

[0138] The service interface determination module 803 is used to determine the service interface of the target worker service based on the interface parameters in the service parameters, and send the other service parameters in the service parameters other than the interface parameters to the server corresponding to the target worker service through the service interface so that the server can process the call request.

[0139] In this embodiment of the invention, the service interface determination module 803 is used to determine the service interface of the target worker service based on the interface parameters in the service parameters. The service interface determination module 803 is also used to send other service parameters besides the interface parameters in the service parameters to the server corresponding to the target worker service through the service interface, according to the service parameter forwarding method of the present invention, so that the server can process the call request.

[0140] The receiving module 804 is also used to receive the processing result returned by the server through the service interface.

[0141] In this embodiment of the invention, the receiving module 804 receives the processing result of the call request returned by the corresponding server through the service interface. The service template can continue to serve other call requests to generate target worker services to process the corresponding call requests.

[0142] In this embodiment of the invention, modules such as the receiving module, the generating module, and the service interface determining module are used to adapt to various complex and ever-changing service environments, meet the processing goals of various call requests, are easy to operate, do not require frequent deployment, improve orchestration efficiency, reduce development and maintenance costs, and ensure service stability.

[0143] Figure 9 An exemplary system architecture diagram is shown, illustrating a method or apparatus for processing call requests suitable for application in embodiments of the present invention, such as... Figure 9 As shown, an exemplary system architecture for the method or apparatus for processing call requests according to embodiments of the present invention includes:

[0144] like Figure 9 As shown, system architecture 900 may include terminal devices 901, 902, and 903, network 904, and server 905. Network 904 is used as a medium to provide a communication link between terminal devices 901, 902, and 903 and server 905. Network 904 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0145] Users can use terminal devices 901, 902, and 903 to interact with server 905 via network 904 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 901, 902, and 903, such as worker service applications, shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0146] Terminal devices 901, 902, and 903 can be various electronic devices with displays that support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0147] Server 905 can be a server providing various services, such as a backend management server supporting worker service websites browsed by users using terminal devices 901, 902, and 903. The backend management server can analyze and process received call requests and other data, and feed back the processing results (such as the target worker service) to terminal devices 901, 902, and 903.

[0148] It should be noted that the method for processing call requests provided in this embodiment of the invention is generally executed by server 905, and correspondingly, the device for processing call requests is generally located in server 905.

[0149] It should be understood that Figure 9The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0150] Figure 10 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention, such as... Figure 10 As shown, the computer system 1000 of the terminal device or server in this embodiment of the invention includes:

[0151] The central processing unit (CPU) 1001 can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1002 or programs loaded from storage section 1008 into random access memory (RAM) 1003. RAM 1003 also stores various programs and data required for the operation of system 1000. CPU 1001, ROM 1002, and RAM 1003 are interconnected via bus 1004. Input / output (I / O) interface 1005 is also connected to bus 1004.

[0152] The following components are connected to I / O interface 1005: an input section 1006 including a keyboard, mouse, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to I / O interface 1005 as needed. A removable medium 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 1010 as needed so that computer programs read from it can be installed into storage section 1008 as needed.

[0153] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1009, and / or installed from removable medium 1011. When the computer program is executed by central processing unit (CPU) 1001, it performs the functions defined in the system of this invention.

[0154] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0155] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0156] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor may be described as including a receiving module, a generating module, and a service interface determining module. The names of these modules do not necessarily limit the module itself; for example, the generating module may also be described as "a module that generates the target worker service corresponding to the call request based on request parameters and a pre-generated service template."

[0157] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include: receiving a call request; wherein the call request indicates request parameters; generating a target worker service corresponding to the call request based on the request parameters and a pre-generated service template; wherein the target worker service indicates one or more service parameters, and the service template is generated by aggregating worker services corresponding to multiple historical call requests; determining a service interface of the target worker service based on interface parameters in the service parameters, and sending other service parameters in the service parameters besides the interface parameters to a server corresponding to the target worker service through the service interface, so that the server processes the call request; and receiving a processing result returned by the server through the service interface.

[0158] The existing approach to developing HTTP request worker nodes involves implementing a custom worker interface class, writing and testing the functional logic and HTTP request logic within the custom worker, registering it with the startup items, and then recompiling and deploying the worker project service. However, adding or changing any HTTP sub-service call results in a long and inefficient development cycle from worker development to project deployment, severely impacting workflow development and change efficiency. Furthermore, due to the large number of services and interfaces and frequent changes (e.g., changes in online / offline status, domain names, and interface parameters), frequent changes to worker definitions and repeated deployments are required, leading to extremely high development costs. Deploying a worker project requires stopping the existing service and deploying a new one, which may disrupt the stable operation of the online workflow.

[0159] According to the technical solution of this invention, commonly used HTTP call methods, including input parameter assembly methods, request addresses, and output parameter methods, are extracted and aggregated into general configurable parameters to generate service templates. Therefore, by simply changing the configuration in the worker nodes of the service template, multiple HTTP requests can be initiated without repeatedly writing and publishing worker services. This improves service orchestration efficiency, effectively addresses the problem of frequent changes and deployments of HTTP request worker nodes, eliminates security risks to service stability caused by frequent deployments, and greatly facilitates the operation and use by developers, testers, and maintenance personnel.

[0160] According to the technical solutions of the present invention, they can adapt to various complex and ever-changing service environments, meet the processing goals of various call requests, are easy to operate, do not require frequent deployment, improve orchestration efficiency, reduce development and maintenance costs, and ensure service stability.

[0161] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for processing invocation requests, characterized in that, include: Receive a call request; wherein the call request indicates request parameters; Based on the request parameters and the pre-generated service template, a target worker service corresponding to the call request is generated; wherein, the target worker service indicates one or more service parameters, and the service template is generated by aggregating the worker services corresponding to multiple historical call requests respectively; Based on the interface parameters in the service parameters, the service interface of the target worker service is determined, and the other service parameters in the service parameters, except for the interface parameters, are sent to the server corresponding to the target worker service through the service interface so that the server can process the call request. Receive the processing result returned by the server through the service interface; Also includes: Retrieve multiple historical call requests; wherein, the historical call requests indicate worker services including historical request parameters and historical request functions; The historical request parameters and the historical request functions are aggregated respectively to determine the template parameters and template functions of the service template; Based on the template parameters and the template function, a service template corresponding to the worker service is generated.

2. The method according to claim 1, characterized in that, The step of generating the target worker service corresponding to the call request based on the request parameters and the pre-generated service template includes: Based on the template parameters required by the service template, the target request parameters corresponding to the template parameters are determined from the request parameters, and the target request parameters are filled into the service template to generate the service parameters corresponding to the service template; The target worker service is generated based on the service parameters in the filled-in service template and other request parameters other than the target request parameters.

3. The method according to claim 1, characterized in that, The template parameters include required parameters and also include: Determine whether the request parameters include the target request parameters corresponding to the required parameters; If the request parameters do not include the target request parameters corresponding to the required parameters, the call request is rejected.

4. The method according to claim 1, characterized in that, The service parameters include the URL; sending the other service parameters, excluding the interface parameters, to the server corresponding to the target worker service through the service interface includes: Determine whether the destination address of the target worker service is empty; If the URL is empty, the other service parameters are sent to the service interface through the default gateway, so that the other service parameters are sent to the server through the service interface; In the case of a request where the URL is not empty, the URL is mapped to the service interface, and the other service parameters are sent to the service interface so that the other service parameters can be sent to the server through the service interface.

5. The method according to claim 1, characterized in that, Also includes: Based on the processing result, update the execution status of the target worker service; If the processing result is successful, the processing data corresponding to the processing result is written to the output log, and the execution status is updated to successful execution. If the processing result is a failure, the processing result is written to the output log, and the execution status is updated to execution failure.

6. The method according to claim 2, characterized in that, in: When the request is an HTTP request, the HTTP request includes any of the following: GET request, POST request, PUT request, DELETE request, HEAD request, OPTIONS request, TRACE request, and CONNECT request.

7. A device for processing invocation requests, characterized in that, include: A receiving module is used to receive a call request; wherein the call request indicates request parameters; The generation module is used to generate a target worker service corresponding to the call request based on the request parameters and the pre-generated service template; wherein, the target worker service indicates one or more service parameters, and the service template is generated by aggregating the worker services corresponding to multiple historical call requests. The service interface determination module is used to determine the service interface of the target worker service based on the interface parameters in the service parameters, and send the other service parameters in the service parameters other than the interface parameters to the server corresponding to the target worker service through the service interface, so that the server can process the call request; The receiving module is also used to receive the processing result returned by the server through the service interface; The generation module is also used for: Retrieve multiple historical call requests; wherein, the historical call requests indicate worker services including historical request parameters and historical request functions; The historical request parameters and the historical request functions are aggregated respectively to determine the template parameters and template functions of the service template; Based on the template parameters and the template function, a service template corresponding to the worker service is generated.

8. An electronic device for processing invocation requests, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-6.

9. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-6.

Images