Remote service calling method and device, equipment and storage medium

Abstract

The invention discloses a remote service calling method and device, equipment and a storage medium, and the method is suitable for a service calling party, and comprises the steps: responding to a current method which is a method for calling a remote service, and creating an RPC request corresponding to the method according to the proxy implementation of the method; and calling the corresponding target remote service based on the RPC request and the first remote access address corresponding to the first service interface to which the method belongs, so that the development efficiency can be improved when the requirement of remote service calling under the micro-service architecture is met.

Description

Technical Field

[0001] The present application belongs to the technical field of service invocation, and in particular, relates to a remote service invocation method, apparatus, device and storage medium. Background Art

[0002] In a monolithic service architecture, the service interface and service implementation class are usually located in the same service. Inter-service calls are implemented through interface dependency injection, which is essentially a direct call between local services. However, as the scale and complexity of services continue to grow, the monolithic service architecture gradually exposes its limitations, so the evolution towards a microservice architecture has become an inevitable trend.

[0003] During this evolution, the original monolithic services had to be split, and the calls between the originally tightly integrated local services were transformed into cross-process remote service calls. This transformation caused the service interfaces and service implementation classes to be distributed in different services, and the original local service implementation method based on interface dependency injection became invalid.

[0004] In order to meet the needs of remote service calls under the microservice architecture, developers need to perform secondary development on the client and server. Specifically, the client needs to code to implement the service interface and add additional implementation logic for remote service calls; the server needs to expose the service implementation class as a remotely accessible service entry through coding. These adjustments undoubtedly increase the workload of developers and the difficulty of debugging.

[0005] In summary, in the prior art, when meeting the needs of remote service calls under the microservice architecture, the workload of developers is large, the debugging difficulty is high, and the development efficiency is low. Summary of the invention

[0006] The embodiment of the present application provides an implementation solution different from the prior art to solve the technical problems of heavy workload for developers, high debugging difficulty and low development efficiency when meeting the needs of remote service calls under a microservice architecture.

[0007] In a first aspect, the present application provides a remote service calling method applicable to a service caller, comprising: in response to a current method being a method for calling a remote service, creating an RPC request corresponding to the method according to a proxy implementation of the method; and calling a corresponding target remote service based on a first remote access address corresponding to a first service interface to which the RPC request belongs and a first service interface to which the method belongs.

[0008] In the second aspect, the present application provides a remote service calling method, applicable to the service callee, comprising: receiving an RPC request sent by a service caller through an RPC interface, the RPC request being used to call a local service; calling a local service based on the RPC request, and generating a response result; feeding back the response result to the service caller through the RPC interface; wherein the local service is the service caller responding to the current method being a method for calling a remote service, creating an RPC request corresponding to the method according to a proxy implementation of the method; and calling the first remote access address corresponding to the first service interface to which the method belongs based on the RPC request.

[0009] In a third aspect, the present application provides a remote service calling device, applicable to a service caller, comprising:

[0010] A creating unit, configured to, in response to the current method being a method for calling a remote service, create an RPC request corresponding to the method according to a proxy implementation of the method;

[0011] The calling unit is used to call the corresponding target remote service based on the RPC request and the first remote access address corresponding to the first service interface to which the method belongs.

[0012] In a fourth aspect, the present application provides an electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute any method in the first aspect, the second aspect, the possible implementation methods of the first aspect, or the possible implementation methods of the second aspect by executing the executable instructions.

[0013] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any method in the first aspect, the second aspect, the possible implementation methods of the first aspect, or the possible implementation methods of the second aspect.

[0014] In a sixth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements any method in the first aspect, the second aspect, the possible implementation methods of the first aspect, or the possible implementation methods of the second aspect.

[0015] The remote service calling method provided by the present application is applicable to the service caller, and specifically includes: in response to the current method being a method for calling a remote service, creating an RPC request corresponding to the method according to the proxy implementation of the method; calling the corresponding target remote service based on the first remote access address corresponding to the first service interface to which the RPC request belongs. The solution of the present application can avoid the need for developers to manually code the service caller service interface and remote service call, greatly reducing the coding workload and debugging difficulty of the service caller when meeting the needs of remote service calls under the microservice architecture, and can improve development efficiency when meeting the needs of remote service calls under the microservice architecture. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the prior art descriptions. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0017] Figure 1a A schematic diagram of the structure of a remote service calling system provided in one embodiment of the present application;

[0018] Figure 1b Provides an interactive scene diagram of a service caller and a service callee in an embodiment of the present application;

[0019] Figure 2a A flowchart of a remote service calling method provided in one embodiment of the present application;

[0020] Figure 2b A schematic diagram of a data processing process of a service calling module provided in an embodiment of the present application;

[0021] Figure 3 A schematic diagram of the structure of a remote service invocation device provided in one embodiment of the present application;

[0022] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, but cannot be understood as limiting the present application.

[0024] The terms "first" and "second" etc. in the specification, claims and drawings of the embodiments of the present application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein, for example. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, the process, method, system, product or equipment comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0025] First, some terms in the embodiments of the present application are explained below to facilitate understanding by those skilled in the art.

[0026] Monolithic service architecture usually includes components such as front-end user interface, back-end server logic, database operations, etc., which are tightly coupled together to form a unified program. In this architecture, all the code is in one place, and no component can work in isolation, which means that the application must be tested as a whole.

[0027] Microservices Architecture is a software design pattern based on service splitting. Its core idea is to split an originally complex monolithic application into a set of smaller and more independent service units. Microservices Architecture is a flexible and scalable software design pattern. By splitting the application into multiple small services, the development team can collaborate more efficiently, deliver new features faster, and better respond to changing business needs. Each service unit has a well-defined interface and function, and can be independently developed, tested, deployed, and use the corresponding technology stack.

[0028] The service interface is an important concept in software design and development, especially in service-oriented architecture (SOA) and microservice architecture. It defines a set of functions or operations that a service provider exposes to a service consumer, and is the basis for communication and interaction between services. The service interface is a contract or agreement between a service provider and a service consumer, which specifies a set of methods or operations that the service provider must implement, as well as the input parameters, output results, and possible exception handling of these methods. The service interface is separate from the service implementation. The service interface defines the functions and behaviors of the service, while the service implementation provides the specific implementation of these functions. The service provider implements the service according to the definition of the service interface and registers the implemented service with the service registry or service center. The service consumer obtains the address and related information of the service interface by looking up the service registry, and then calls the service interface to communicate and interact with the service provider.

[0029] RPC (Remote Procedure Call) is a communication protocol or programming model, mainly used for communication between different processes or different machines. The RPC interface allows a program to request services or resources in another remote program through the network, just like calling a function or method in a local program. In this process, the caller (client) does not need to understand the implementation details of the remote program (server), but only needs to know the interface definition (such as method name, parameter type, return value type, etc.).

[0030] ImportBeanDefinitionRegistrar is a key interface in the Spring framework that allows developers to dynamically register additional BeanDefinitions into the Spring application context programmatically.

[0031] Interface dependency injection is a specific form of dependency injection (DI), which is widely used in object-oriented programming and frameworks (such as Spring). Interface dependency injection means that the code depends on the interface type rather than the specific implementation class of the interface. In this way, the container (such as Spring IoC container) will automatically inject the specific implementation class according to the interface. This method follows the principle of interface-oriented programming, helps to reduce the coupling between codes, and improves the reusability and testability of the code.

[0032] In a monolithic service architecture, the service interface and service implementation class are usually located in the same service. Inter-service calls are implemented through interface dependency injection, which is essentially a direct call between local services. However, as the scale and complexity of services continue to grow, the monolithic service architecture gradually exposes its limitations, so the evolution towards a microservice architecture has become an inevitable trend.

[0033] During this evolution, the original monolithic services had to be split, and the calls between the originally tightly integrated local services were transformed into cross-process remote service calls. This transformation caused the first service interface and service implementation class to be distributed in different services, and the original local service implementation method based on interface dependency injection became invalid.

[0034] In order to meet the needs of remote service calls under the microservice architecture, developers need to perform secondary development on the client (service caller) and the server (service callee). Specifically, the client needs to code to implement the service interface and add additional implementation logic for remote service calls; the server needs to expose the service implementation class as a remotely accessible service entry through coding. These adjustments undoubtedly increase the workload of developers and the difficulty of debugging.

[0035] In summary, in the prior art, when meeting the needs of remote service calls under the microservice architecture, the workload of developers is large, the debugging difficulty is high, and the development efficiency is low.

[0036] In order to solve the above problems, it is necessary to design and implement a unified service framework that can achieve seamless switching between local calls and remote calls without any coding adjustments. Such a service framework will greatly simplify the development process, reduce debugging difficulty, and improve development efficiency.

[0037] In summary, by designing and implementing a unified service framework, we can effectively cope with the challenges faced in the evolution of monolithic services to microservice architecture, achieve seamless switching between local calls and remote calls, and thus promote the widespread application and development of microservice architecture.

[0038] Figure 1a A schematic diagram of a remote service calling system provided for an exemplary embodiment of the present application, the system includes: a service caller and a service callee. Optionally, both the service caller and the service callee can be servers. Optionally, the service caller is a client device and the service callee is a server, which is not limited by the present application.

[0039] In some optional embodiments of the present application, the service caller includes: a service configuration module, a service scanning registration module, and a service proxy implementation module.

[0040] The service configuration module is used to configure the package where the service interface that needs to be proxied is located and the corresponding remote access address. The service configuration module can configure at least one configuration item.

[0041] The service scanning registration module is used to parse the service interface that needs to be proxied and automatically register the service proxy implementation for it according to at least one configuration item configured in the service configuration module.

[0042] The service proxy implementation module is used to proxy each method in the service interface through a Java dynamic proxy, and implement the call to the remote service based on the proxy of each method. When the remote service, that is, the service in the service callee, is called based on the method proxy implementation, the specific implementation steps are as follows S001-S003:

[0043] S001. Construct RPC request parameters according to method context;

[0044] S002. Send the RPC request carrying the RPC request parameters to the service entry corresponding to the remote access address corresponding to the service interface. The RPC protocol here is not limited to a specific RPC protocol, such as REST, gRPC, Dubbo, etc. It only needs to be consistent with the RPC protocol in the remote service entry module in the service callee.

[0045] S003. Upon receiving the RPC response result fed back by the service callee, determine whether the call is successful. If the call is successful, deserialize and generate the corresponding return result object according to the resultClass and resuleValue in the RPC response result and return it.

[0046] The service caller configures, scans, automatically proxy implements and registers the service interface that needs to be called across services, avoiding the need for developers to manually code the service caller service interface and remote service calls.

[0047] The service callee is mainly responsible for the unified exposure of the service callee interface and the call processing of the local service. The unified remote service entry and automatic service call processing avoid the need for developers to manually code and expose the server interface. When the monolith is disassembled into a microservice architecture, the coding workload and debugging difficulty of the server are greatly reduced. The service callee is divided into the remote service entry module and the service call module.

[0048] For details, please refer to the interaction between the service caller and the service callee. Figure 1b As shown, Figure 1b This application proposes an interaction scenario diagram between a service caller and a service callee, wherein the interaction details between the service caller and the service callee are described in detail below.

[0049] Figure 2aA flowchart of a remote service calling method provided by an exemplary embodiment of the present application is provided. The execution subject of the method may be a service caller. The method at least includes the following steps S201-S202:

[0050] S201, in response to the current method being a method for calling a remote service, creating an RPC request corresponding to the method according to a proxy implementation of the method;

[0051] Optionally, the method further comprises: in response to the current mode being the remote call mode, determining that the current method is a method for calling a remote service. In response to the current mode being the local call mode, determining that the current method is not a method for calling a remote service.

[0052] Furthermore, the above method also includes: in response to the current method not being a method invoking a remote service, implementing the calling of a local service corresponding to the method through interface dependency injection.

[0053] Optionally, relevant personnel can set the service call mode to a local call mode or a remote call mode through a mode setting instruction.

[0054] In some optional embodiments of the present application, in the aforementioned step S201, the creating an RPC request corresponding to the method according to the proxy implementation of the method includes the following steps S2011-S2012:

[0055] S2011, creating RPC request parameters in the RPC request corresponding to the method according to the proxy implementation of the method;

[0056] S2012. Generate an RPC request corresponding to the method based on the RPC request parameters.

[0057] The RPC request parameters may include at least one attribute name and an attribute value of each attribute name.

[0058] Specifically, the format of the RPC request parameter may include: attribute name, attribute type, and attribute content, as shown in Table 1:

[0059] Table 1 RPC request parameter format specification

[0060]

[0061] Optionally, the attribute name and attribute value in the RPC request parameter of the RPC request of the service caller may refer to Table 2:

[0062] Table 2 RPC request parameters

[0063]

[0064]

[0065] The serialized values ​​in the serialized value list in Table 1 above are not limited to a certain serialization method, such as JDK built-in, JSON, etc.

[0066] S202: Call a corresponding target remote service based on a first remote access address corresponding to the RPC request and the first service interface to which the method belongs.

[0067] In some optional embodiments of the present application, the method further includes the following steps S01-S02:

[0068] S01. Obtain configuration information related to the service interface proxy;

[0069] The aforementioned configuration information can be generated according to the configuration instructions of relevant personnel.

[0070] S02. Determine a first remote access address corresponding to the first service interface based on the configuration information.

[0071] In some optional embodiments of the present application, the configuration information includes at least one configuration item, each configuration item includes service interface information and a second remote access address corresponding to the service interface information.

[0072] Optionally, the service interface information includes: the first package name of the package where the second service interface to be proxied is located and the interface name of the second service interface. At this time, the second remote access address corresponding to the service interface information is: the remote access address corresponding to the second service interface.

[0073] Optionally, the service interface information includes: the first package name of the package where the second service interface to be proxied is located, and part of the interface name of the second service interface. In this case, the second remote access address corresponding to the service interface information is: the remote access address corresponding to the service interface whose interface name includes part of the interface name of the second service interface under the package where the second service interface is located.

[0074] Optionally, the service interface information includes: the first package name of the package where the second service interface to be proxied is located. In this case, the second remote access address corresponding to the service interface information is: the remote access address corresponding to all interfaces under the package where the second service interface is located. Among them, the remote access addresses corresponding to all interfaces under the package where the second service interface is located are the same remote access address.

[0075] Optionally, different service interfaces under the same package name may be in different configuration items.

[0076] Optionally, the package names of different sub-packages under the same parent package may be in different configuration items.

[0077] In some optional embodiments of the present application, in the aforementioned S02, determining the first remote access address corresponding to the first service interface based on the configuration information includes the following steps S021-S024:

[0078] S021. Obtain the full path of the first service interface;

[0079] The full path of the first service interface refers to the location of the first service interface in the code, specifically the complete path from the root package (or top-level package) to the specific package where the first service interface is located. This path is used in software development and code management to ensure that developers can accurately find and reference the required interface.

[0080] Optionally, the full path of the first service interface consists of a series of package names and interface names of the first service interface separated by dots (.), starting from the root package (or the top-level package of the project) and going down step by step to the package containing the interface name of the service interface.

[0081] Suppose there is a Java project with a top-level package named com.example, a package named service under the project, and a sub-package named user under it, which defines a service interface named UserService. Then, the full path of the UserService interface is: com.example.service.user.UserService.

[0082] S022, obtaining the package information in the full path;

[0083] Optionally, the package information in the full path refers to the interface name of the first service interface and the package names of each level of the package where the first service interface is located.

[0084] Optionally, the package information in the full path may be the same as the full path.

[0085] S023, determining a target configuration item in the configuration information that matches the package information;

[0086] Optionally, in the aforementioned S023, determining the target configuration item in the configuration information that matches the package information includes the following steps S231-S233:

[0087] S231. For any one of the at least one configuration item included in the configuration information, extract service interface information in the configuration item to obtain at least one service interface information;

[0088] S232, sorting the at least one service interface information in descending order of data length to obtain a sorting result;

[0089] S233: Determine a target configuration item in the configuration information that matches the package information based on the sorting result.

[0090] In some optional embodiments of the present application, in S233, the determining, based on the sorting result, a target configuration item in the configuration information that matches the package information includes:

[0091] Match each service interface information in the sorting result with the package information in order from front to back. When service interface information included in the package information or the same as the package information is matched, stop matching and use the configuration item where the matched service interface information is located as the target configuration item to match the package information.

[0092] S024. Use the second remote access address in the target configuration item as the first remote access address corresponding to the first service interface.

[0093] In some optional embodiments of the present application, the method further includes: generating a proxy implementation of each method in the first service interface based on the first service interface and the first remote service address, and registering the proxy implementation of each method.

[0094] Specifically, generating a proxy implementation of the first service interface and registering the proxy implementation of the first service interface also depend on the first remote access address corresponding to the first service interface. The method for determining the first remote access address corresponding to the first service interface can refer to the above content.

[0095] Generating a proxy implementation of the first service interface and registering the proxy implementation of the first service interface realizes generating proxy implementations of each method in the first service interface and registering the proxy implementations of each method.

[0096] The method in the aforementioned step S201 is one of the at least one method included in the first service interface.

[0097] It should be noted that the proxy implementation of the method needs to be generated and registered in advance before the method can be processed based on the proxy implementation.

[0098] In some optional embodiments of the present application, in the scheme of the present application, when registering each service interface proxy implementation, the automatic registration of the service interface proxy implementation can be completed through the ImportBeanDefinitionRegistrar mechanism in the SpringBoot framework. The process of automatic registration of the service interface proxy implementation by ImportBeanDefinitionRegistrar can be seen in the following steps S1-S4:

[0099] S1. Parse all configuration items and extract the package name list consisting of the package names of the packages where the service interface is located;

[0100] S2. Obtain the interface name of the service interface under each package name in the package name list through the reflection mechanism to obtain at least one service interface information;

[0101] S3. Parse the full path of the service interface (including the package name) in sequence. If the service interface information contained in the configuration item or the same as the full path of the service interface is matched, extract the remote access address corresponding to the configuration item as the remote access address of the current service interface.

[0102] S4. Generate each service interface proxy implementation according to the definition of each service interface and its corresponding remote access address, and complete the registration of each service interface proxy implementation in turn.

[0103] Accordingly, the service callee may perform the following steps S301-S303:

[0104] S301, receiving an RPC request sent by a service caller through an RPC interface, wherein the RPC request is used to call a local service;

[0105] S302, calling a local service based on the RPC request and generating a response result;

[0106] S303, feeding back the response result to the service caller through the RPC interface;

[0107] Among them, the local service is the service caller's response to the current method being a method for calling a remote service, creating an RPC request corresponding to the method according to the proxy implementation of the method; and calling the first remote access address corresponding to the first service interface to which the RPC request belongs.

[0108] The service callee is mainly responsible for the unified exposure of the service callee interface and the call processing of the local service. The unified remote service entry and automatic service call processing avoid the need for developers to manually code and expose the server interface. When the monolith is disassembled into a microservice architecture, the coding workload and debugging difficulty of the server are greatly reduced. The service callee is divided into the remote service entry module and the service call module.

[0109] The remote service entry module is used to provide a unified RPC interface (not limited to a specific RPC protocol, such as REST, gRPC, Dubbo, etc.). The RPC interface of the service callee needs to be consistent with the RPC interface initiated by the service proxy implementation module in the service caller (RPC protocol, request parameters, response results). The service caller uniformly initiates cross-service RPC calls to the remote service entry module of the service callee. After receiving the service request from the service caller, this module entrusts it to the service call module, which completes the call of the local service on the server side and encapsulates the returned results.

[0110] The service call module is used to delegate the request to the corresponding local service implementation after receiving the service call request, and encapsulate and return the processing result of the local service. The data processing process of the service call module can be as follows: Steps S11-S16, and the details can also be seen in Figure 2b As shown:

[0111] S11. Generate a service interface type serviceInterfaceClass based on the sevInterface (service interface name) in the RPC request parameter and obtain the corresponding local service implementation object serviceImpl;

[0112] S12. Generate a method parameter type list paramTypeList for local service implementation based on the parameter paramClassLIst (parameter type list) in the RPC request parameter through reflection;

[0113] S13, deserialize the parameter type list paramTypeList and the paramValueLIst (parameter serialization value list) in the RPC request parameter to generate the method parameter object list paramObjList of the local service implementation class;

[0114] S14. Obtain the corresponding method serviceImplMethod of the local service implementation class through reflection according to serviceInterfaceClass, paramTypeList and the parameter serviceMethod (service interface method name) in the RPC request parameter;

[0115] S15. Call the corresponding method serviceImplMethod of the local service implementation class serviceImpl through reflection, with the parameter being paramsObjList;

[0116] S16. Encapsulate and return the RPC response result, record the success or failure of the call in the success attribute, record the serialized value of the local service method return result servcieResult, and the return result type in the resultValue and resultClass attributes. If the call fails, the corresponding failure prompt information must also be recorded in the errMsg attribute.

[0117] This application can implement a solution for seamless switching (zero coding adjustment) between local calls and remote calls. The service caller configures, scans, automatically proxy-implements and registers the service interface that needs to be called across services, thereby avoiding the need for developers to manually code the service caller interface and remote service calls. This greatly reduces the client's coding workload and debugging difficulty when decomposing a monolith into a microservice architecture.

[0118] The remote service calling method provided by the present application is applicable to the service caller, and specifically includes: in response to the current method being a method for calling a remote service, creating an RPC request corresponding to the method according to the proxy implementation of the method; calling the corresponding target remote service based on the first remote access address corresponding to the first service interface to which the RPC request belongs. The solution of the present application can avoid the need for developers to manually code the service caller service interface and remote service call, greatly reducing the coding workload and debugging difficulty of the service caller when meeting the needs of remote service calls under the microservice architecture, and can improve development efficiency when meeting the needs of remote service calls under the microservice architecture.

[0119] An exemplary embodiment of the present application further provides a remote service calling method, the execution subject of the method may be a service callee, and the method at least includes the following steps S301-S303:

[0120] S301, receiving an RPC request sent by a service caller through an RPC interface, wherein the RPC request is used to call a local service;

[0121] Among them, the local service is the target remote service that needs to be called by the method corresponding to the RPC request.

[0122] S302, calling a local service based on the RPC request and generating a response result;

[0123] S303, feeding back the response result to the service caller through the RPC interface;

[0124] Among them, the local service is the service caller's response to the current method being a method for calling a remote service, creating an RPC request corresponding to the method according to the proxy implementation of the method; and calling the first remote access address corresponding to the first service interface to which the RPC request belongs.

[0125] Optionally, the format of the specific RPC response result may include: attribute name, attribute type, and attribute content, as shown in Table 3:

[0126] Table 3 RPC response result format

[0127]

[0128]

[0129] Optionally, the RPC response result of the service callee may be as shown in Table 4:

[0130] Table 4 RPC response results

[0131] RPC response result attribute name Property Value success true errorMsg success resultClass "com.biz.BizResult" resultValue "BizResult object serialized value..."

[0132] The solution of this application can avoid the need for developers to manually code the service caller service interface and remote service calls. When meeting the needs of remote service calls under the microservice architecture, the coding workload and debugging difficulty of the service caller are greatly reduced, which can improve development efficiency when meeting the needs of remote service calls under the microservice architecture. The service callee is mainly responsible for the unified exposure of the service callee interface and the call processing of the local service. The unified remote service entry and automatic service call processing avoid the need for developers to manually code and expose the server interface, which greatly reduces the coding workload and debugging difficulty of the server when the monomer is disassembled into a microservice architecture. The service callee is divided into a remote service entry module and a service call module.

[0133] Figure 3 A schematic diagram of a remote service invocation device provided as an exemplary embodiment of the present application; wherein the device is applicable to a service invocation party, including:

[0134] A creating unit 31, configured to create an RPC request corresponding to the method according to a proxy implementation of the method in response to the current method being a method for calling a remote service;

[0135] The calling unit 32 is configured to call a corresponding target remote service based on the RPC request and a first remote access address corresponding to the first service interface to which the method belongs.

[0136] In some optional embodiments of the present application, the aforementioned apparatus is further used for: in response to the current mode being the remote call mode, determining that the current method is a method for calling a remote service.

[0137] In some optional embodiments of the present application, when the aforementioned apparatus is used to create an RPC request corresponding to the method according to the proxy implementation of the method, it is specifically used to:

[0138] Creating RPC request parameters in the RPC request corresponding to the method according to the proxy implementation of the method;

[0139] Generate an RPC request corresponding to the method based on the RPC request parameters.

[0140] In some optional embodiments of the present application, the device is also used for:

[0141] Get configuration information related to the service interface proxy;

[0142] A first remote access address corresponding to the first service interface is determined based on the configuration information.

[0143] In some optional embodiments of the present application, when the aforementioned apparatus is used to determine the first remote access address corresponding to the first service interface based on the configuration information, it is specifically used to:

[0144] Obtain the full path of the first service interface;

[0145] Obtaining package information in the full path;

[0146] Determine a target configuration item in the configuration information that matches the package information;

[0147] The second remote access address in the target configuration item is used as the first remote access address corresponding to the first service interface.

[0148] In some optional embodiments of the present application, when the aforementioned apparatus is used to determine the target configuration item in the configuration information that matches the package information, it is specifically used to:

[0149] For any one of the at least one configuration item included in the configuration information, extract the service interface information in the configuration item to obtain at least one service interface information;

[0150] Sorting the at least one service interface information in descending order of data length to obtain a sorting result;

[0151] A target configuration item in the configuration information that matches the package information is determined based on the sorting result.

[0152] In some optional embodiments of the present application, the present application further provides a remote service calling device, which is suitable for serving a called party, including:

[0153] A receiving unit, configured to receive an RPC request sent by a service caller through an RPC interface, wherein the RPC request is used to call a local service;

[0154] A generating unit, used to call a local service based on the RPC request and generate a response result;

[0155] A feedback unit, used for feeding back the response result to the service caller through the RPC interface;

[0156] Among them, the local service is the service caller's response to the current method being a method for calling a remote service, creating an RPC request corresponding to the method according to the proxy implementation of the method; and calling the first remote access address corresponding to the first service interface to which the RPC request belongs.

[0157] It should be understood that the device embodiment and the method embodiment may correspond to each other, and similar descriptions may refer to the method embodiment. To avoid repetition, no further description is given here. Specifically, the device may perform the above method embodiment, and the above and other operations and / or functions of each module in the device are the corresponding processes in each method in the above method embodiment, respectively, and no further description is given here for the sake of brevity.

[0158] The above describes the device of the embodiment of the present application from the perspective of the functional module in conjunction with the accompanying drawings. It should be understood that the functional module can be implemented in hardware form, can be implemented by instructions in software form, and can also be implemented by a combination of hardware and software modules. Specifically, the steps of the method embodiment in the embodiment of the present application can be completed by the hardware integrated logic circuit and / or software form instructions in the processor, and the steps of the method disclosed in the embodiment of the present application can be directly embodied as a hardware decoding processor to perform, or a combination of hardware and software modules in the decoding processor to perform. Optionally, the software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, a register, etc. The storage medium is located in a memory, and the processor reads the information in the memory, and completes the steps in the above method embodiment in conjunction with its hardware.

[0159] Figure 4 is a schematic block diagram of an electronic device provided in an embodiment of the present application, and the electronic device may include:

[0160] The memory 401 and the processor 402, the memory 401 is used to store the computer program and transmit the program code to the processor 402. In other words, the processor 402 can call and run the computer program from the memory 401 to implement the method in the embodiment of the present application.

[0161] For example, the processor 402 may be configured to execute the above method embodiments according to instructions in the computer program.

[0162] In some embodiments of the present application, the processor 402 may include but is not limited to:

[0163] General-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, etc.

[0164] In some embodiments of the present application, the memory 401 includes but is not limited to:

[0165] Volatile memory and / or non-volatile memory. Among them, the non-volatile memory can be read-only memory (ROM), programmable ROM (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus random access memory (DR RAM).

[0166] In some embodiments of the present application, the computer program may be divided into one or more modules, which are stored in the memory 401 and executed by the processor 402 to complete the method provided by the present application. The one or more modules may be a series of computer program instruction segments capable of completing specific functions, and the instruction segments are used to describe the execution process of the computer program in the electronic device.

[0167] like Figure 4 As shown, the electronic device may also include:

[0168] The transceiver 403 may be connected to the processor 402 or the memory 401 .

[0169] The processor 402 may control the transceiver 403 to communicate with other devices, specifically, to send information or data to other devices, or to receive information or data sent by other devices. The transceiver 403 may include a transmitter and a receiver. The transceiver 403 may further include an antenna, and the number of antennas may be one or more.

[0170] It should be understood that the various components in the electronic device are connected via a bus system, wherein the bus system includes not only a data bus but also a power bus, a control bus and a status signal bus.

[0171] The present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a computer, the computer can perform the method of the above method embodiment. In other words, the present application embodiment also provides a computer program product containing instructions, and when the instructions are executed by a computer, the computer can perform the method of the above method embodiment.

[0172] When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integration. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a digital video disc (digital video disc, DVD)), or a semiconductor medium (e.g., a solid state drive (solid state disk, SSD)), etc.

[0173] Those of ordinary skill in the art will appreciate that the modules and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0174] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the module is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0175] The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. For example, each functional module in each embodiment of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0176] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A remote service calling method, characterized in that: Applicable to service callers, including: In response to the current method being a method for calling a remote service, creating an RPC request corresponding to the method according to a proxy implementation of the method; The corresponding target remote service is called based on the first remote access address corresponding to the first service interface to which the method belongs and the RPC request.

2. The method according to claim 1, characterized in that The method further comprises: In response to the current mode being the remote call mode, the current method is determined to be a method for calling a remote service.

3. The method according to claim 1, characterized in that The creating an RPC request corresponding to the method according to the proxy implementation of the method includes: Creating RPC request parameters in the RPC request corresponding to the method according to the proxy implementation of the method; Generate an RPC request corresponding to the method based on the RPC request parameters.

4. The method according to claim 1, characterized in that: The method further comprises: Get configuration information related to the service interface proxy; A first remote access address corresponding to the first service interface is determined based on the configuration information.

5. The method according to claim 4, characterized in that The determining, based on the configuration information, a first remote access address corresponding to the first service interface includes: Obtain the full path of the first service interface; Obtaining package information in the full path; Determine a target configuration item in the configuration information that matches the package information; The second remote access address in the target configuration item is used as the first remote access address corresponding to the first service interface.

6. The method according to claim 5, characterized in that The determining a target configuration item in the configuration information that matches the package information includes: For any one of the at least one configuration item included in the configuration information, extract the service interface information in the configuration item to obtain at least one service interface information; Sorting the at least one service interface information in descending order of data length to obtain a sorting result; A target configuration item in the configuration information that matches the package information is determined based on the sorting result.

7. A remote service calling method, characterized in that: Applicable to the service callee, including: Receive an RPC request sent by a service caller through an RPC interface, wherein the RPC request is used to call a local service; Calling a local service based on the RPC request and generating a response result; Feedback the response result to the service caller through the RPC interface; Among them, the local service is the service caller's response to the current method being a method for calling a remote service, creating an RPC request corresponding to the method according to the proxy implementation of the method; and calling the first remote access address corresponding to the first service interface to which the RPC request belongs.

8. A remote service calling device, characterized in that: Applicable to service callers, including: A creating unit, configured to, in response to the current method being a method for calling a remote service, create an RPC request corresponding to the method according to a proxy implementation of the method; The calling unit is used to call the corresponding target remote service based on the RPC request and the first remote access address corresponding to the first service interface to which the method belongs.

9. An electronic device, characterized in that: include: processor; as well as A memory, configured to store executable instructions of the processor; The processor is configured to perform the method of any one of claims 1 to 7 by executing the executable instructions.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images