A remote invocation method, system, device and medium

Abstract

The application discloses a remote calling method, system, device and medium, wherein the method comprises the following steps: receiving a calling request initiated from a client, and performing interface declaration on a target calling interface based on the calling request; customizing a class object of the target interface, creating a dynamic proxy, and generating a calling chain corresponding to the calling request; modifying the target calling interface based on extension data in the calling request, so as to complete custom extension of the target calling interface and obtain a request object; after serializing parameters of the request object, sending an Http request to a server; receiving return parameters from the server, and sending the return parameters after deserialization to the client. By proposing a remote calling tool, the underlying layer adopts an Http request based remote method calling, and supports dynamic proxy interface calling. The calling mode is simpler, and only needs to declare an interface to describe an API.

Description

Technical Field

[0001] This application relates to the field of remote invocation, specifically to a remote invocation method, system, device, and medium. Background Technology

[0002] Remote method invocation (RPC) is a common development method for distributed applications. Common RPC methods include RPC and HTTP. RPC does not specify the data transmission format; only the two ends need to agree on it, making it more transparent and convenient for users. However, this method requires encapsulation of the invocation process at the application programming interface (API) level, necessitating the use of a unified technology stack during development. In contrast, HTTP specifies the data transmission format and does not require API encapsulation, offering greater flexibility and cross-language / cross-platform compatibility. For distributed and microservice systems that emphasize independence, autonomy, and flexibility, HTTP is more suitable, typically employing an HTTP-based RESTful service.

[0003] Currently, mainstream HTTP-based remote procedure call (RPC) tools in the industry can be broadly divided into two categories:

[0004] The first type is the traditional code-based call. Since the HTTP remote call service is not encapsulated at the application programming interface layer, requests, responses, resource location, operation methods, etc. need to be implemented in code. The core of the code is to use classes such as HttpUrlConnection to code the request process to call the remote method. This method can interfere with the entire complete HTTP request call process, including constructing information such as request headers, cookies, and body, and customizing the serialization and deserialization methods of interfaces and parameters. The advantage of this method is that it has a high degree of freedom and can flexibly choose different methods, such as HttpClient, OKHttp, URLConnection, etc. The disadvantages are as follows: (1) The remote call process lacks effective management, and it is difficult to track problems in a unified manner once a call exception occurs; (2) A lot of repetitive code, such as logging, access control, load balancing, and application programming interface call management, need to be implemented repeatedly, resulting in low development efficiency; (3) It is not conducive to later expansion and the addition of new functions.

[0005] The second type is Feign, a declarative, template-based HTTP client enhanced by Spring Cloud. It supports Spring MVC annotations, simple load balancing, and remote method invocation using dynamic proxy. The client only needs to describe the remote server application's programming interface using the remote call interface. After the program starts, the remote call logic is generated using dynamic proxy, making calling remote services as simple as calling local services, greatly simplifying traditional code and tool-based remote calls. However, its shortcomings are also very obvious: (1) The remote server must be a specific HTTP interface and does not support calls to other methods; (2) It does not fully consider the issue of authorization, requiring separate interceptors to supplement authorization; (3) The load balancing logic is relatively simple, using round-robin and random strategies, making it difficult to support complex load balancing scenarios. Summary of the Invention

[0006] To address the aforementioned problems, this application proposes a method, apparatus, and medium, wherein the method includes:

[0007] The system receives a call request from the client and, based on the call request, declares the target call interface; it defines a custom class object for the target interface, creates a dynamic proxy, and generates a call chain corresponding to the call request; based on the extended data within the call request, it modifies the target call interface to complete the custom extension of the target call interface and obtains a request object; it serializes the parameters of the request object and sends the HTTP request to the server; it receives the return parameters from the server and sends the deserialized return parameters to the client.

[0008] In one example, the declaration of the target call interface specifically includes: determining the input parameters, method name, and return parameters of the declaration method corresponding to the target call interface based on the call request; indicating the service name and basic path of the call using annotations, and injecting the service information of the interface using annotations.

[0009] In one example, the custom class object of the target interface specifically includes: obtaining the basic path to be scanned by scanning annotations; obtaining the configuration meta information interface of all path annotations by traversing the basic path and scanning the path annotations corresponding to the basic path; wrapping the configuration meta information interface into a utility class of type FactoryBean; and injecting basic properties into the utility class, wherein the basic properties include at least the service name and the call type.

[0010] In one example, the extended data includes at least one of authorization extended data, load extended data, and log extended data.

[0011] In one example, the remote invocation method includes at least one of HTTP application programming interface (API) invocation and fixed application programming interface (API) reflection invocation.

[0012] In one example, serializing the request object parameters specifically includes: determining that the input parameter type of the request object is an object type; serializing the input parameter into a string; and setting the request body using the string.

[0013] In one example, after sending the returned parameters after deserialization to the client, the method further includes: storing the call logs in a log library; and tracing the call logs in the log library based on a call chain tracing request.

[0014] This application also provides a service remote invocation system, comprising: an interface declaration module, which receives an invocation request initiated by a client and declares an interface for a target invocation interface based on the invocation request; a customization module, which customizes a class object of the target interface, creates a dynamic proxy, and generates an invocation chain corresponding to the invocation request; an extension module, which modifies the target invocation interface based on extension data within the invocation request to complete the custom extension of the target invocation interface and obtain a request object; a parameter serialization module, which serializes the parameters of the request object and sends the HTTP request to the server; and a deparameter serialization module, which receives the return parameters from the server and sends the deserialized return parameters to the client.

[0015] This application also provides a service remote invocation device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform: receiving a call request initiated by a client, and based on the call request, declaring an interface for a target call interface; defining a custom class object of the target interface, creating a dynamic proxy and generating a call chain corresponding to the call request; modifying the target call interface based on extended data within the call request to complete the custom extension of the target call interface and obtain a request object; serializing the parameters of the request object and sending an HTTP request to a server; receiving return parameters from the server and sending the deserialized return parameters to the client.

[0016] This application also provides a non-volatile computer storage medium storing computer-executable instructions, the computer-executable instructions being configured to: receive a call request initiated by a client, and based on the call request, declare an interface for a target call interface; define a class object of the target interface, create a dynamic proxy, and generate a call chain corresponding to the call request; modify the target call interface based on extended data within the call request to complete the custom extension of the target call interface and obtain a request object; serialize the parameters of the request object and send the HTTP request to the server; receive return parameters from the server and send the deserialized return parameters to the client.

[0017] The method proposed in this application offers the following advantages: It provides a remote invocation tool that uses HTTP requests to complete remote method calls and supports dynamic proxy interface calls. The invocation method is simpler, requiring only an API description; the invocation scope is broader, supporting remote calls to both APIs and ordinary methods; it includes custom serialization and deserialization tools; and it supports custom load balancing. Based on commonly used microservice registries, it provides basic strategies such as round-robin, proportional, and random balancing, and callers can also customize load balancing strategies according to their needs; it supports unified log management and call chain tracing; it supports custom authentication; and it supports custom extensions, allowing callers to control the invocation process and modify or adjust parameters during request sending. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 This is a flowchart illustrating a method for remotely invoking a service according to an embodiment of this application;

[0020] Figure 2 This is a schematic diagram of a remote call operation process in an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of a service remote invocation system module in an embodiment of this application;

[0022] Figure 4 This is a schematic diagram of the structure of a service remote invocation device in an embodiment of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0025] Figure 1 This diagram illustrates a remote invocation method provided in one or more embodiments of this specification. The method can be applied to services in various fields, such as internet financial services, e-commerce services, instant messaging services, gaming services, and public services. The process can be executed by computing devices in the corresponding field (e.g., risk control servers or smart mobile terminals for payment services). Certain input parameters or intermediate results in the process can be manually adjusted to help improve accuracy.

[0026] The analysis method involved in the embodiments of this application can be implemented by a terminal device or a server, and this application does not impose any special limitations on it. For ease of understanding and description, the following embodiments are all described in detail using a server as an example.

[0027] It should be noted that the server can be a single device or a system composed of multiple devices, i.e., a distributed server. This application does not make any specific limitations in this regard.

[0028] like Figure 1 and Figure 2 As shown in the figure, this application provides a method for remote service invocation, including:

[0029] S101: Receive a call request initiated by the client, and declare the target call interface based on the call request.

[0030] In one embodiment, when declaring an interface, the first step is to determine the input parameters, method name, and return parameters of the method corresponding to the target interface based on the call request. The service name and basic path of the call are then indicated using annotations, and the interface's service information is injected using annotations. Specifically, the interface declaration is largely consistent with the ordinary Java API declaration method, including declaring the method's input parameters, method name, and return parameters, indicating the service name and basic path of the call using annotations, and injecting the interface's service information (including service identifier, service IP, load balancing method, etc.) using annotations. For example, a custom annotation `MsuHttpClient(serviceId = "app1", serviceIp = "192.168.1.1", loadBalance = true)` can be used. Here, `serviceIp` is empty by default, but can be configured through a configuration file or obtained dynamically.

[0031] S102: Define a custom class object of the target interface, create a dynamic proxy, and generate the call chain corresponding to the call request.

[0032] In one embodiment, when customizing a bean and creating a dynamic proxy, the main implementation involves the interfaces ImportBeanDefinitionRegistrar and SmartFactoryBean. The specific logic is as follows: Implement the ImportBeanDefinitionRegistrar interface and the registerBeanDefinitions method. Scan the EnableMsuHttpClient annotation to obtain the base package. Iterate through the base package, scanning for the MsuHttpClient annotation based on the path to obtain all BeanDefinitions annotated with MsuHttpClient. Wrap each BeanDefinition with a FactoryBean type BeanDefinitionBuilder and inject its basic properties using the addPropertyValue method: service name and call type (HTTP request call, normal method call).

[0033] When implementing the SmartFactoryBean interface, all interfaces requiring dynamic proxies must specify a FactoryBean. The FactoryBean, during the container's bean instance loading process, calls the getObject() method to return the actual instance. The getObject() method uses JDK dynamic proxies to return the actual proxy. The key implementation logic of dynamic proxies is the critical logic during the interface call process, primarily involving the encapsulation of HTTP requests. Implementing the InvocationHandler interface and the invoke method handles the specific HTTP request construction, parameter serialization, permission settings, deserialization of the returned result, recording of the call process, etc.

[0034] S103: Based on the extended data in the call request, modify the target call interface to complete the custom extension of the target call interface and obtain the request object.

[0035] In one embodiment, when performing custom extensions, it is necessary to obtain the basic path to be scanned by scanning annotations; by traversing the basic path, scanning the path annotations corresponding to the basic path to obtain the configuration meta-information interface of all path annotation annotations; wrapping the configuration meta-information interface into a utility class of type FactoryBean; and injecting basic properties into the utility class, wherein the basic properties include at least the service name and the call type.

[0036] In one embodiment, the extended data includes at least one of authorization extended data, load extended data, and log extended data. Common load balancing strategies are round-robin, random, and proportional. The key to load balancing is effectively pulling instances of the service being called. The `MsuDiscovery` interface is provided to obtain instance information corresponding to the service. This information includes instance ID, service name, IP address, etc. The `MsuServiceStrategy` interface is also provided; the default strategy is round-robin, and the caller can override the implementation to complete a custom load balancing strategy according to its needs. A suitable instance is selected based on the load balancing strategy for remote calls. Then, the `RequestTemplate` object is constructed, with the following key properties:

[0037]

[0038] S104: After serializing the request object parameters, send the HTTP request to the server.

[0039] In one embodiment, if the input parameter type of the interface method is an object, serialization is required. Jackson is used here to perform the serialization operation. The object is serialized into a string, which is then used to set the request body.

[0040] Once the request object is constructed and the parameters are serialized, an HTTP request can be sent to complete the remote method call. There are two types of remote method calls: the first is the call to a common HTTP API, and the second is the call to a regular method. For regular method calls, we use a fixed interface. When the caller calls a regular method of the callee, the callee provides a fixed API. This API uses reflection to complete the call to the local method, depending on the method being called.

[0041] S105: Receive the return parameters from the server and send the deserialized return parameters to the client.

[0042] The tool retrieves the Type of the return parameter from the called method and then performs deserialization. Using this tool reduces the need for developers to manually encapsulate HTTP request remote call methods and supports multi-functional extensions. It solves both the drawback of manually encapsulating remote calls (which offers flexibility but involves a large amount of code) and the limitation of tools like Feign (which are convenient but have limited extensibility).

[0043] In one embodiment, after the returned parameters after deserialization are sent to the client, in order to support unified log management and call chain tracing, the call logs can be stored in a log library, and the call logs in the log library can be traced based on the call chain tracing request.

[0044] like Figure 3 As shown in the illustration, this application also provides a service remote invocation system, including:

[0045] The interface declaration module 301 receives a call request initiated by the client and declares the target call interface based on the call request.

[0046] Custom module 302 defines a custom class object of the target interface, creates a dynamic proxy, and generates the call chain corresponding to the call request.

[0047] The extension module 303 modifies the target call interface based on the extension data in the call request to complete the custom extension of the target call interface and obtain the request object.

[0048] The parameter serialization module 304 serializes the request object parameters and sends the HTTP request to the server.

[0049] The deserialization module 305 receives the return parameters from the server and sends the deserialized return parameters to the client.

[0050] like Figure 4 As shown in the illustration, this application also provides a service remote invocation device, including:

[0051] At least one processor; and,

[0052] A memory communicatively connected to the at least one processor; wherein,

[0053] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0054] The system receives a call request from the client and, based on the call request, declares the target call interface; it defines a custom class object for the target interface, creates a dynamic proxy, and generates a call chain corresponding to the call request; based on the extended data within the call request, it modifies the target call interface to complete the custom extension of the target call interface and obtains a request object; it serializes the parameters of the request object and sends the HTTP request to the server; it receives the return parameters from the server and sends the deserialized return parameters to the client.

[0055] This application embodiment also provides a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as follows:

[0056] The system receives a call request from the client and, based on the call request, declares the target call interface; it defines a custom class object for the target interface, creates a dynamic proxy, and generates a call chain corresponding to the call request; based on the extended data within the call request, it modifies the target call interface to complete the custom extension of the target call interface and obtains a request object; it serializes the parameters of the request object and sends the HTTP request to the server; it receives the return parameters from the server and sends the deserialized return parameters to the client.

[0057] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and medium embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the method embodiments.

[0058] The devices and media provided in this application are one-to-one with the methods. Therefore, the devices and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

[0059] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0060] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0061] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0062] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0063] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0064] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash memory. Memory is an example of computer-readable media.

[0065] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media do not include transient computer-readable media, such as modulated data signals and carrier waves.

[0066] It should also be noted that 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 limitation, 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 said element.

[0067] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for remote service invocation, characterized in that, include: Receive a call request initiated by the client, and declare the target call interface based on the call request; Define a custom class object for the target interface, create a dynamic proxy, and generate the call chain corresponding to the call request; the call chain includes the construction of the HTTP request, the serialization of parameters, the setting of permissions, and the deserialization of the returned result; Based on the extended data within the call request, the target call interface is modified to complete the custom extension of the target call interface and obtain the request object; the extended data includes at least one of authorization extended data, load extended data, and log extended data; After serializing the request object parameters, the HTTP request is sent to the server. Receive the return parameters from the server and send the deserialized return parameters to the client; The interface declaration for the target calling interface specifically includes: Based on the call request, determine the input parameters, method name, and return parameters of the declared method corresponding to the target call interface; The service name and basic path to be called are specified using annotations, and the service information of the interface is injected using annotations. The custom class object of the target interface specifically includes: The basic scanning path is obtained by scanning annotations; By traversing the basic paths and scanning the path annotations corresponding to the basic paths, the configuration meta-information interface of all path annotations is obtained. The configuration metadata interface is wrapped into a utility class of type FactoryBean; Inject basic attributes into the utility class, including at least the service name and the call type.

2. The method according to claim 1, characterized in that, The remote invocation method includes at least one of HTTP application programming interface (API) invocation and fixed application programming interface (API) reflection invocation.

3. The method according to claim 1, characterized in that, The serialization of the request object parameters specifically includes: The input parameter type of the request object is determined to be an object type; The input parameters are serialized into strings, and the request body is set using the strings.

4. The method according to claim 1, characterized in that, After sending the deserialized return parameters to the client, the method further includes: Store the call logs in a log library; Based on the call chain tracing request, the call logs in the log library are traced.

5. A service remote invocation system, characterized in that, include: The interface declaration module receives a call request from the client and declares the target call interface based on the call request. A custom module is used to define a class object of the target interface, create a dynamic proxy, and generate the call chain corresponding to the call request. The extension module modifies the target call interface based on the extension data within the call request to complete the custom extension of the target call interface and obtain the request object; the extension data includes at least one of authorization extension data, load extension data, and log extension data; The parameter serialization module serializes the parameters of the request object and then sends the HTTP request to the server. The deserialization module receives the return parameters from the server and sends the deserialized return parameters to the client. The interface declaration for the target calling interface specifically includes: Based on the call request, determine the input parameters, method name, and return parameters of the declared method corresponding to the target call interface; The service name and basic path to be called are specified using annotations, and the service information of the interface is injected using annotations. The custom class object of the target interface specifically includes: The basic scanning path is obtained by scanning annotations; By traversing the basic paths and scanning the path annotations corresponding to the basic paths, the configuration meta-information interface of all path annotations is obtained. The configuration metadata interface is wrapped into a utility class of type FactoryBean; Inject basic attributes into the utility class, the basic attributes including at least the service name and the call type; Remote invocation methods include at least one of HTTP application programming interface (API) invocation and fixed application programming interface (API) reflection invocation.

6. A service remote invocation device, characterized in that, include: At least one processor; And, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform: a service remote invocation method as described in any one of claims 1-4.

7. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are configured to execute a service remote invocation method as described in any one of claims 1-4.

Images