A multi-thread remote interface calling method, system and device

Abstract

The application discloses a kind of multithread remote interface calling method, system and device, it is related to multithread task scheduling field.This application is when receiving remote interface calling instruction when task encapsulation, automatically generates the agent object of remote interface calling tool, the encapsulation of first task to be executed is implemented, according to remote interface calling instruction time determines interface request parameter, according to interface request parameter can know which interface is called this time, then based on first thread pool and second thread pool, task is handled, and then interface calling is implemented, without extra filling url and request header information when calling interface each time, automation operation replaces manual operation, so that the complexity of whole process is reduced, and efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of multithreaded task scheduling, and in particular to a multithreaded remote interface invocation method, system, and apparatus. Background Technology

[0002] In existing technologies, when performing multi-threaded task scheduling, the task to be executed is first encapsulated into a Runnable or Callable state before it can be executed. In addition, when implementing remote interface calls through multi-threaded task scheduling, it is necessary to explicitly pass the URL and request header information required by the interface to complete the call.

[0003] When encapsulating tasks, manual operation is required. In multi-threaded task scheduling, there are many tasks to be processed, and each task requires encapsulation. This manual operation reduces processing efficiency and may also lead to incorrect encapsulation. When passing information required for calling an interface, explicit transmission is required, which necessitates filling in the required URL and request headers. This filling process is also manual, requiring a clear understanding of the URL and request headers of the interface being called, further reducing task scheduling efficiency. All these manual steps significantly increase the complexity of the entire task scheduling process. Summary of the Invention

[0004] The purpose of this invention is to provide a multi-threaded remote interface invocation method, system, and apparatus. In the task encapsulation process, upon receiving a remote interface invocation instruction, this application automatically generates a proxy object for the remote interface invocation tool to encapsulate the first task to be executed. The interface request parameters are determined based on the remote interface invocation instruction, allowing the system to identify the specific interface to be invoked. The task is then processed using a first thread pool and a second thread pool to achieve the interface invocation. This eliminates the need to manually input URLs and request headers for each interface invocation, reducing complexity and improving efficiency.

[0005] To address the aforementioned technical problems, this invention provides a multi-threaded remote interface invocation method, comprising:

[0006] Upon receiving a remote interface call instruction, generate the corresponding interface request parameters and the corresponding proxy object of the remote interface call tool.

[0007] Generate a remote interface call request corresponding to the remote interface call instruction based on the proxy object and the interface request parameters;

[0008] Invoke the first thread pool corresponding to the remote interface call request, and add the first task corresponding to sending the remote interface call request to the first thread pool so as to send the remote interface call request to the receiving object;

[0009] Obtain the response result sent back by the receiving object corresponding to the remote interface call request;

[0010] The second thread pool corresponding to the response result is invoked, and the second task corresponding to obtaining the actual call result based on the response result is added to the second thread pool so that the actual call result can be obtained based on the response result.

[0011] Preferably, after generating the remote interface call request corresponding to the remote interface call instruction based on the proxy object and the interface request parameters, the method further includes:

[0012] Convert the remote interface call request into a first string;

[0013] Add the first task corresponding to sending the remote interface call request to the first thread pool so as to send the remote interface call request to the receiving object, including:

[0014] The first task corresponding to the sending of the first string is added to the first thread pool so that the first string can be sent to the receiving object.

[0015] Preferably, obtaining the response result sent back by the receiving object corresponding to the remote interface call request includes:

[0016] Receive the second string sent back by the receiving object corresponding to the remote interface call request;

[0017] The second string is converted into the response result.

[0018] Preferably, converting the remote interface call request into a first string includes:

[0019] Invoke the serialization converter tool and convert the remote interface call request into a first string based on the serialization converter tool.

[0020] Preferably, the second task corresponding to obtaining the actual call result based on the response result is added to the second thread pool so that the actual call result can be obtained based on the response result, including:

[0021] Determine the time-consuming task in the second task corresponding to the actual call result based on the response result, and add the time-consuming task to the second thread pool in order to obtain the actual call result.

[0022] Preferably, obtaining the actual call result based on the response result includes:

[0023] The conversion tool is invoked and the response result is converted into the actual call result based on the conversion tool. The conversion tool includes one or more of the map tool, flatMap tool, and filter tool.

[0024] Preferred options also include:

[0025] When it is detected that a new first task cannot be added to the first thread pool and / or a new second task cannot be added to the second thread pool, the event of this inability to add a new first task to the first thread pool and / or the inability to add a new second task to the second thread pool is stored in a log file.

[0026] Preferably, invoking the first thread pool corresponding to the remote interface call request includes:

[0027] The built-in scheduler or custom thread pool corresponding to the first task is determined based on the remote interface call request.

[0028] The first thread pool corresponding to the remote interface call request is invoked based on the determined built-in scheduler or the custom thread pool.

[0029] Invoking the second thread pool corresponding to the response result includes:

[0030] The built-in scheduler or the custom thread pool corresponding to the second task is determined based on the response result;

[0031] The second thread pool corresponding to the response result is invoked based on the determined built-in scheduler or the custom thread pool.

[0032] To address the aforementioned technical problems, the present invention also provides a multi-threaded remote interface invocation system, comprising:

[0033] The interface request parameter and proxy object generation unit is used to generate interface request parameters corresponding to the remote interface call instruction and a proxy object corresponding to the remote interface call tool when a remote interface call instruction is received.

[0034] A remote interface call request generation unit is used to generate a remote interface call request corresponding to the remote interface call instruction based on the proxy object and the interface request parameters;

[0035] The first processing unit is used to call the first thread pool corresponding to the remote interface call request, and add the first task corresponding to sending the remote interface call request to the first thread pool so as to send the remote interface call request to the receiving object.

[0036] The response result acquisition unit is used to acquire the response result sent back by the receiving object corresponding to the remote interface call request;

[0037] The second processing unit is used to call the second thread pool corresponding to the response result, and add the second task corresponding to obtaining the actual call result based on the response result to the second thread pool so as to obtain the actual call result based on the response result.

[0038] To address the aforementioned technical problems, the present invention also provides a multi-threaded remote interface invocation device, comprising:

[0039] Memory, used to store computer programs;

[0040] A processor for executing the computer program to implement the steps of the multi-threaded remote interface invocation method described above.

[0041] This application provides a multi-threaded remote interface invocation method, system, and apparatus. Upon receiving a remote interface invocation instruction, the system generates interface request parameters corresponding to the instruction and a proxy object for the remote interface invocation tool. Based on the proxy object and the interface request parameters, it generates a remote interface invocation request corresponding to the instruction. It then invokes a first thread pool corresponding to the remote interface invocation request and adds a first task corresponding to this request to the first thread pool to send the request to the receiving object. Finally, it obtains the response result sent back by the receiving object. Finally, it invokes a second thread pool corresponding to the response result and adds a second task corresponding to obtaining the actual invocation result based on the response result to the second thread pool to obtain the actual invocation result based on the response result. In this application, when encapsulating tasks, upon receiving a remote interface call instruction, a proxy object for the remote interface call tool is automatically generated to encapsulate the first task to be executed. The interface request parameters are determined based on the remote interface call instruction, and the interface to be called can be identified from these parameters. Then, the task is processed based on the first and second thread pools to realize the interface call. There is no need to fill in the URL and request header information for each interface call. The automated operation replaces manual operation, reducing the complexity of the entire process and improving efficiency. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the prior art and embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 A flowchart of a multi-threaded remote interface invocation method provided by the present invention;

[0044] Figure 2 This invention provides a schematic diagram of the structure of a multi-threaded remote interface calling system.

[0045] Figure 3 This is a schematic diagram of the structure of a multi-threaded remote interface calling device provided by the present invention. Detailed Implementation

[0046] The core of this invention is to provide a multi-threaded remote interface invocation method, system, and apparatus. During task encapsulation, upon receiving a remote interface invocation instruction, this application automatically generates a proxy object for the remote interface invocation tool to encapsulate the first task to be executed. The interface request parameters are determined based on the remote interface invocation instruction, allowing the system to identify the specific interface to be invoked. The task is then processed using a first thread pool and a second thread pool to achieve the interface invocation. This eliminates the need to manually input URLs and request headers for each interface invocation, reducing complexity and improving efficiency.

[0047] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0048] Please refer to Figure 1 , Figure 1 A flowchart illustrating a multi-threaded remote interface invocation method provided by this invention. The method includes:

[0049] S11: Upon receiving a remote interface call instruction, generate the corresponding interface request parameters for the remote interface call instruction and the corresponding proxy object for the remote interface call tool;

[0050] When making a remote interface call, upon receiving the remote interface call instruction, the necessary interface request parameters for calling the corresponding interface can be generated. Then, the remote interface call tool is encapsulated to generate a proxy object for that tool. This allows subsequent execution of the remote interface call based on the proxy object, improving the reliability of the solution. Please refer to Table 1, which lists the basic tools required for this application.

[0051] Table 1 Remote Interface Calling Tools

[0052]

[0053]

[0054] The principles and scripts in this solution are based on the aforementioned rxjava, retrofit, adapter-rxjava, and fastjson. Using these tools can further improve the processing efficiency of this solution and reduce the complexity of handling multi-threaded tasks.

[0055] Furthermore, this solution applies the observer pattern, where the client sending the request can be considered the observed object, and the receiving object is the observer. The observer will execute its own logic as the state of the observed object changes.

[0056] S12: Generate a remote interface call request corresponding to the remote interface call instruction based on the proxy object and interface request parameters;

[0057] Based on the generated proxy object and the interface request parameters, the remote interface call request required for this remote interface call can be generated. The encapsulation step is completed when the proxy object is generated. The interface request parameters directly contain the parameters required to generate the remote interface call request, without the need to explicitly pass the required URL and request header information, which reduces the overall complexity of the solution and improves efficiency.

[0058] S13: Call the first thread pool corresponding to the remote interface call request, and add the first task corresponding to this remote interface call request to the first thread pool so as to send the remote interface call request to the receiving object;

[0059] Since there may be many API call tasks to be processed, adding the tasks to a thread pool for execution can improve the processing efficiency when handling multiple tasks. For tasks that send requests, they can be added to the first thread pool for invocation, and then the tasks can be processed in the first thread pool so that the remote API call request can be sent to the receiving object. The whole process is automated, which improves the automation level of the solution.

[0060] Before sending a remote API call request, the client that sends the request needs to be initialized.

[0061]

[0062] Please refer to the script above to initialize the Retofit client, which mainly involves three parameters.

[0063] Base URL: The base address for API interface requests. Configurable injection can be used to flexibly configure the URL.

[0064] Serialization converter factory: A class that determines how to serialize and deserialize request and response data.

[0065] Retrofit and RxJava Adapter: Through this adapter, Retrofit requests can directly return RxJava heavy observables, thus enabling better use of reactive programming to handle API requests.

[0066] S14: Obtain the response result sent back by the receiving object of the corresponding remote interface call request;

[0067] When a remote API call request is sent to a receiving object, the receiving object will have its own processing logic. After processing, it will send the response back. The client then receives the returned response to perform subsequent actions based on the response, thus improving the automation and reliability of the solution.

[0068] When receiving a response from an object, you need to use a response body converter to get the type of the receiving object. The constructor can be used to get the type of the receiving object that sent the response. Please refer to the script below.

[0069]

[0070]

[0071] S15: Call the second thread pool corresponding to the response result, and add the second task corresponding to obtaining the actual call result based on the response result to the second thread pool so that the actual call result can be obtained based on the response result.

[0072] When calling different thread pools, it is necessary to know the thread number and thread name prefix of each thread pool. For the first and second thread pools mentioned above, it is necessary to know which thread pool is currently being used. Afterwards, as long as the thread number and thread name prefix of the thread pool are known, the content of the task executed by the thread pool can be known, which improves the reliability of the solution.

[0073]

[0074]

[0075] The received response needs to be processed to obtain the actual call result. The response result indicates whether the target of each task has responded, while the actual call result indicates whether the interface corresponding to the response result is usable. When converting the response result into the actual call result, the task can be added to a second thread pool. The actual call result is obtained from the second thread pool, and the entire process is automated, improving the level of automation.

[0076] Each remote API call request corresponds to a Java method. The request method and URL are added to the method as annotations, the request parameters are passed as method parameters, and the response result is returned as the method result. Thanks to the introduction of adapter-rxjava (an adapter for rxjava3 and retrofit), the method result can directly return an Oberservable, making the remote API call request an observable in reactive programming.

[0077]

[0078]

[0079] Based on the above embodiments:

[0080] In a preferred embodiment, after generating the remote interface call request corresponding to the remote interface call instruction based on the proxy object and interface request parameters, the method further includes:

[0081] Convert the remote API call request into the first string;

[0082] Add the first task corresponding to this remote API call request to the first thread pool so that the remote API call request can be sent to the receiving object, including:

[0083] Add the first task corresponding to sending the first string to the first thread pool so that the first string can be sent to the receiving object.

[0084] When actually sending an API call request, what is transmitted is not an object, but only characters. Therefore, the remote API call request first needs to be converted into a first string, and then the first string is sent to the receiving object. After the receiving object parses the first string, it can send the response result back. The whole process is automated, which improves the reliability of the solution.

[0085] The script below illustrates the transformation process after generating a remote interface call request.

[0086]

[0087]

[0088] In the script above, the remote interface call request is converted into a first string through serialization, and the serialized string is actually transmitted to the receiving object, thus demonstrating the feasibility of the call solution.

[0089] As a preferred embodiment, obtaining the response result sent back by the receiving object of the corresponding remote interface call request includes:

[0090] Receive the second string sent back by the receiving object corresponding to the remote interface call request;

[0091] Convert the second string into a response result.

[0092] Since the interaction with the receiving object can only transmit serialized strings, the receiving object also sends back a response string. After receiving the second string sent back by the receiving object, the second string can be converted into a response, which improves the reliability of the solution.

[0093] The script shown below works on the opposite principle of serializing a remote interface call request. It converts the received second string into a response result, which is a deserialization process. Data is transmitted serially, but when the client actually receives the data, it needs to receive the object converted from the second string, which is the response result.

[0094]

[0095]

[0096] As a preferred embodiment, converting the remote interface call request into a first string includes:

[0097] Invoke the serialization converter tool and use it to convert the remote interface call request into a first string.

[0098] In practice, when converting a string to an object or vice versa, a serialization conversion tool is required. This tool is pre-stored in the processor. When sending a remote interface call request, the request can be converted into a first string using the serialization conversion tool. Similarly, when receiving the second string of the response result, the tool can be used to convert it into the response result, thus improving the reliability of the solution.

[0099] Because network requests transmit data as simple byte sequences, the system at the underlying level doesn't recognize objects, only byte sequences. To achieve inter-process communication, data needs to be serialized, which is the process of converting objects into byte sequences. Conversely, when a byte sequence is delivered to the corresponding process, the process must deserialize it to recognize the data, that is, convert the byte sequence back into an object.

[0100] It should be noted that in this invention, fastjson is introduced as a JSON data conversion tool, and Retrofit is used to serialize and deserialize request and response data respectively. The custom serialization tool inherits from Retrofit's converter factory and implements request and response converters respectively, thereby achieving the purpose of serialization and deserialization and ensuring compatibility with Retrofit.

[0101] As a preferred embodiment, the second task corresponding to obtaining the actual call result based on the response result is added to the second thread pool so that the actual call result can be obtained based on the response result, including:

[0102] Determine the time-consuming task in the second task corresponding to the actual call result based on the response result, and add the time-consuming task to the second thread pool in order to obtain the actual call result.

[0103] The tasks actually added to the second thread pool are the time-consuming tasks in the second task pool. These tasks take more time to process, so they are added to the second thread pool to obtain the actual call results and improve the processing efficiency of the solution.

[0104] As a preferred embodiment, obtaining the actual call result based on the response result includes:

[0105] The transformation tool is invoked and the response result is converted into the actual call result based on the transformation tool. The transformation tool includes one or more of the map tool, flatMap tool, and filter tool.

[0106] When transforming the response results into actual call results, one or more of the map, flatMap, and filter tools can be used. These tools can filter, select, and transform the response results into actual call results. The results of the observed response can be transformed, filtered, and selected through intermediate methods such as map, flatMap, and filter, which improves the processing efficiency of the solution.

[0107] As a preferred embodiment, it also includes:

[0108] When it is detected that a new first task cannot be added to the first thread pool and / or a new second task cannot be added to the second thread pool, the event of this inability to add a new first task to the first thread pool and / or the inability to add a new second task to the second thread pool is stored in a log file.

[0109] When it is detected that a new first task cannot be added to the first thread pool, or a new second task cannot be added to the second thread pool, the corresponding events are stored in a log file for later review. This allows users to understand the current task status in a timely manner, improving the reliability of the solution and the user experience.

[0110]

[0111] The script above is a custom rejection policy that handles rejections when the thread pool and blocking queue are full. Log entries can be added to facilitate maintenance personnel's handling during subsequent troubleshooting, thus improving the reliability of the solution.

[0112] In a preferred embodiment, invoking the first thread pool corresponding to the remote interface call request includes:

[0113] The built-in scheduler or custom thread pool corresponding to the first task is determined based on the remote interface call request;

[0114] The first thread pool for the corresponding remote interface call request is invoked based on a defined built-in scheduler or a custom thread pool;

[0115] Invoke the second thread pool corresponding to the response result, including:

[0116] The built-in scheduler or custom thread pool corresponding to the second task is determined based on the response result;

[0117] A second thread pool is invoked based on the corresponding response result from a defined built-in scheduler or a custom thread pool.

[0118] When calling the first or second thread pool, either the built-in scheduler or a custom thread pool can be used for execution. The choice between the built-in scheduler and the custom thread pool can be determined based on the remote interface call request. When determining the second thread pool, the choice can be based on the response result. This allows for more flexible use of the thread pool and improves the flexibility and reliability of the solution.

[0119] When defining the thread pools for observers and observables, refer to the script below, where the thread pools for observables and observers are defined in a similar way.

[0120]

[0121]

[0122] Table 2 RxJava's built-in scheduler table

[0123]

[0124] As shown in Table 2, Table 2 lists RxJava's built-in schedulers. Users can choose to use the built-in scheduler or a custom thread pool based on their actual situation and usage needs. For example, the built-in scheduler can be used when no customization is required, while a custom thread pool can be used when it is more convenient.

[0125] While using RxJava's built-in scheduler is simple and convenient, it's recommended to use a custom thread pool, specifying the scheduler using `Schedulers.from(executor)`. By using a custom thread pool, you can tailor it to your specific needs, such as concurrency, memory size, and whether to accept rejected tasks. This ensures a thread pool perfectly suited to your business requirements, preventing memory shortages while maintaining an appropriate number of threads to guarantee efficient task execution. Furthermore, it logs rejected tasks for future reference.

[0126] The script below is the actual script for implementing remote interface calls. It also includes the subscription relationship between the observable and the observer in developer mode, as well as error handling, which improves the comprehensiveness of the solution.

[0127]

[0128]

[0129]

[0130]

[0131] The overall content of the above script is as follows:

[0132] Use the Retrofit client to generate proxy objects for API interface methods, call the methods of this proxy object to make remote API calls, and directly obtain the corresponding observable.

[0133] The `subscribeOn` method specifies the thread pool used by the observable, making it an asynchronous call.

[0134] Intermediate methods such as map, flatMap, and filter can be used to transform, filter, and select the results of the observed response.

[0135] By specifying the thread pool used by the observer using the observerOn method, operations that consume a lot of time in processing the response results can be treated as asynchronous tasks, such as I / O and database operations.

[0136] The observed object has four reactive tasks: onSubscribe (triggered when a subscription occurs), onNext (triggered when data is received), onError (triggered when an error occurs), and onComplete (triggered when the response is complete). These four methods allow for easy event handling, enabling monitoring, exception handling, logging, and other operations.

[0137] Please refer to Figure 2 , Figure 2 This is a schematic diagram of the structure of a multi-threaded remote interface calling system provided by the present invention.

[0138] This invention also provides a multi-threaded remote interface invocation system, comprising:

[0139] The interface request parameter and proxy object generation unit 20 is used to generate the interface request parameters corresponding to the remote interface call instruction and the proxy object corresponding to the remote interface call tool when a remote interface call instruction is received.

[0140] The remote interface call request generation unit 21 is used to generate a remote interface call request corresponding to the remote interface call instruction based on the proxy object and the interface request parameters.

[0141] The first processing unit 22 is used to call the first thread pool corresponding to the remote interface call request, and add the first task corresponding to this remote interface call request to the first thread pool so as to send the remote interface call request to the receiving object.

[0142] The response result acquisition unit 23 is used to acquire the response result sent back by the receiving object of the corresponding remote interface call request;

[0143] The second processing unit 24 is used to call the second thread pool corresponding to the response result, and add the second task corresponding to obtaining the actual call result based on the response result to the second thread pool so as to obtain the actual call result based on the response result.

[0144] The remote interface call request generation unit includes, after the following:

[0145] Convert the remote API call request into the first string;

[0146] The first processing unit includes:

[0147] Add the first task corresponding to sending the first string to the first thread pool so that the first string can be sent to the receiving object.

[0148] The response result acquisition unit includes:

[0149] The second string receiving unit is used to receive the second string sent back by the receiving object of the corresponding remote interface call request;

[0150] The response result conversion unit is used to convert the second string into a response result.

[0151] The multi-threaded remote interface call system includes:

[0152] Invoke the serialization converter tool and use it to convert the remote interface call request into a first string.

[0153] The second processing unit includes:

[0154] Determine the time-consuming task in the second task corresponding to the actual call result based on the response result, and add the time-consuming task to the second thread pool in order to obtain the actual call result.

[0155] The second processing unit includes:

[0156] The transformation tool is invoked and the response result is converted into the actual call result based on the transformation tool. The transformation tool includes one or more of the map tool, flatMap tool, and filter tool.

[0157] The multi-threaded remote interface call system also includes:

[0158] When it is detected that a new first task cannot be added to the first thread pool and / or a new second task cannot be added to the second thread pool, the event of this inability to add a new first task to the first thread pool and / or the inability to add a new second task to the second thread pool is stored in a log file.

[0159] The first processing unit includes:

[0160] The first determining unit is used to determine the built-in scheduler or custom thread pool corresponding to the first task based on the remote interface call request;

[0161] The first thread pool invocation unit is used to invoke the first thread pool corresponding to the remote interface invocation request based on a determined built-in scheduler or a custom thread pool.

[0162] The second processing unit includes:

[0163] The second determining unit is used to determine the built-in scheduler or custom thread pool corresponding to the second task based on the response result;

[0164] The second thread pool invocation unit is used to invoke the second thread pool corresponding to the response result based on a determined built-in scheduler or a custom thread pool.

[0165] For an introduction to the multi-threaded remote interface calling system provided in this solution, please refer to the above-described implementation of the multi-threaded remote interface calling method; it will not be repeated here.

[0166] Please refer to Figure 3 , Figure 3 This is a schematic diagram of the structure of a multi-threaded remote interface calling device provided by the present invention.

[0167] The present invention also provides a multi-threaded remote interface invocation device, comprising:

[0168] Memory 30 is used to store computer programs;

[0169] Processor 31 is used to execute computer programs to implement the steps of the above-described multi-threaded remote interface invocation method.

[0170] For an introduction to the multi-threaded remote interface calling device provided in this solution, please refer to the above-described embodiment of the multi-threaded remote interface calling method; it will not be repeated here.

[0171] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the aforementioned element.

[0172] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0173] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A multi-threaded remote interface invocation method, characterized in that, include: Upon receiving a remote interface call instruction, generate the corresponding interface request parameters and the corresponding proxy object of the remote interface call tool. Generate a remote interface call request corresponding to the remote interface call instruction based on the proxy object and the interface request parameters; Invoke the first thread pool corresponding to the remote interface call request, and add the first task corresponding to sending the remote interface call request to the first thread pool so as to send the remote interface call request to the receiving object; Obtain the response result sent back by the receiving object corresponding to the remote interface call request; The second thread pool corresponding to the response result is invoked, and the second task corresponding to obtaining the actual call result based on the response result is added to the second thread pool so that the actual call result can be obtained based on the response result. The first thread pool corresponding to the remote interface call request includes: The built-in scheduler or custom thread pool corresponding to the first task is determined based on the remote interface call request. The first thread pool corresponding to the remote interface call request is invoked based on the determined built-in scheduler or the custom thread pool. Invoking the second thread pool corresponding to the response result includes: The built-in scheduler or the custom thread pool corresponding to the second task is determined based on the response result; The second thread pool corresponding to the response result is invoked based on the determined built-in scheduler or the custom thread pool.

2. The multi-threaded remote interface invocation method according to claim 1, characterized in that, After generating the remote interface call request corresponding to the remote interface call instruction based on the proxy object and the interface request parameters, the method further includes: Convert the remote interface call request into a first string; The step of adding the first task corresponding to the remote interface call request to the first thread pool so as to send the remote interface call request to the receiving object includes: The first task corresponding to the sending of the first string is added to the first thread pool so that the first string can be sent to the receiving object.

3. The multi-threaded remote interface invocation method according to claim 1, characterized in that, The step of obtaining the response result sent back by the receiving object corresponding to the remote interface call request includes: Receive the second string sent back by the receiving object corresponding to the remote interface call request; The second string is converted into the response result.

4. The multi-threaded remote interface invocation method according to claim 2, characterized in that, The step of converting the remote interface call request into a first string includes: Invoke a serialization converter tool and convert the remote interface call request into the first string based on the serialization converter tool.

5. The multi-threaded remote interface invocation method according to claim 1, characterized in that, The step of adding the second task corresponding to the actual call result obtained based on the response result to the second thread pool so as to obtain the actual call result based on the response result includes: Determine the time-consuming task in the second task corresponding to the actual call result based on the response result, and add the time-consuming task to the second thread pool in order to obtain the actual call result.

6. The multi-threaded remote interface invocation method according to claim 1, characterized in that, The step of obtaining the actual call result based on the response result includes: The conversion tool is invoked and the response result is converted into the actual call result based on the conversion tool. The conversion tool includes one or more of the map tool, flatMap tool, and filter tool.

7. The multi-threaded remote interface invocation method according to claim 1, characterized in that, Also includes: When it is detected that a new first task cannot be added to the first thread pool and / or a new second task cannot be added to the second thread pool, the event of this inability to add a new first task to the first thread pool and / or the inability to add a new second task to the second thread pool is stored in a log file.

8. A multi-threaded remote interface invocation system, characterized in that, include: The interface request parameter and proxy object generation unit is used to generate interface request parameters corresponding to the remote interface call instruction and a proxy object corresponding to the remote interface call tool when a remote interface call instruction is received. A remote interface call request generation unit is used to generate a remote interface call request corresponding to the remote interface call instruction based on the proxy object and the interface request parameters; The first processing unit is used to call the first thread pool corresponding to the remote interface call request, and add the first task corresponding to sending the remote interface call request to the first thread pool so as to send the remote interface call request to the receiving object. The response result acquisition unit is used to acquire the response result sent back by the receiving object corresponding to the remote interface call request; The second processing unit is used to call the second thread pool corresponding to the response result, and add the second task corresponding to obtaining the actual call result based on the response result to the second thread pool so as to obtain the actual call result based on the response result. The first processing unit includes: The first determining unit is used to determine the built-in scheduler or custom thread pool corresponding to the first task based on the remote interface call request; The first thread pool invocation unit is used to invoke the first thread pool corresponding to the remote interface invocation request based on a determined built-in scheduler or a custom thread pool. The second processing unit includes: The second determining unit is used to determine the built-in scheduler or custom thread pool corresponding to the second task based on the response result; The second thread pool invocation unit is used to invoke the second thread pool corresponding to the response result based on a determined built-in scheduler or a custom thread pool.

9. A multi-threaded remote interface invocation device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the multithreaded remote interface invocation method described in any one of 1 to 7 above.

Images