Method, device and equipment for realizing remote interface function of micro-service architecture

Abstract

The invention relates to a method for realizing a remote interface function of a micro-service architecture, which comprises the following steps of: realizing remote calling of a provider and a consumer in the micro-service architecture by using a component rpc-utils, and realizing consumer interface calling through an rpc-controller module in the component, including remote interface agent management, interface calling function providing and interface calling result statistics. A provider interface proxy is realized through an rpc-provider module in the assembly, including initialization when a provider service is started, external provision of an HTTP HOST interface and monitoring and statistics of interface calling, monitoring of the interface calling is realized through a monitoring and early warning module in the assembly, early warning notification is performed on abnormal data, interface testing is realized through an rpc-test module in the assembly, and the interface testing efficiency is improved. And online stateless deployment and transverse expansion of the micro-service are realized through an Nginx module in the assembly. According to the method, the application development complexity can be simplified, the method is more concentrated on the business part, the proportion of the business code in the whole code is increased, the development period is shortened, and the original interface calling problem occurring in the development process is reduced.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, apparatus, and device for implementing a remote interface function of a microservice architecture. Background Art

[0002] The microservices architecture is the most popular and widely used architectural solution and concept in the current backend application development process. It encapsulates a type of business logic in a set of backend applications, which can be independently developed, deployed, and expanded, and provides a set of callable API interfaces. It fully embodies the engineering, high cohesion, and low coupling of the application development process. Its characteristics are: Modularity: Each microservice focuses on the implementation of specific functions and businesses. For example, the user service is only responsible for the maintenance of user information; the payment service is only responsible for the specific implementation of various payment functions.

[0003] Decentralization is mainly reflected in the decentralization of data and development. Each microservice selects and uses the corresponding data implementation solution (database selection and data storage splitting) according to the current business function, avoiding the bottleneck problem caused by centralized data storage. Different development teams can choose the most appropriate implementation technology stack and tools according to business needs. After determining the communication interface API of each microservice, parallel development can be carried out, greatly shortening the development cycle.

[0004] Dynamic expansion deployment: Each microservice can be deployed horizontally based on the current system requirements without the need for expansion deployment of the entire system. For example, when the interface scheduling times of the current user service are too high and are about to reach the upper limit of the user service's carrying capacity, the user service can be deployed horizontally without expanding the entire system.

[0005] Monitoring, early warning, and fault-tolerance scheduling: To monitor the running status of microservices in real time, monitor microservices and issue early warning notifications for urgent and important information; when other microservice APIs are abnormal, perform fault tolerance or even downgrade processing to reduce the impact on the current service.

[0006] The microservices architecture is popular in modern backend application development due to its engineering flexibility and scalability. However, its complexity requires developers to have a strong technical foundation, and the numerous implementations of its technical support lead to a sharp increase in learning pressure for developers. Summary of the Invention

[0007] In view of this, the present application proposes a method for implementing the remote interface function of a microservice architecture to solve the problems reflected in the above background technology.

[0008] The present application provides a method for implementing a remote interface function of a microservice architecture, which is characterized by comprising: Use the component rpc-utils to implement remote calls between providers and consumers in the microservice architecture; Implement consumer interface calls through the rpc-consumer module in the component, including remote interface proxy management, providing interface call functions, and statistics of interface call results; Implement the provider interface proxy through the rpc-provider module in the component, including initialization when the provider service starts, providing HTTP HOST interface to the outside world, and monitoring and statistics interface calls; Monitor interface calls and issue warning notifications for abnormal data through the monitoring and warning modules in the components; Implement interface testing through the rpc-test module in the component; The Nginx module in the component is used to realize online stateless deployment and horizontal expansion of microservices.

[0009] Optionally, the consumer interface call is implemented through the rpc-consumer module in the component, including remote interface proxy management, providing interface call functions and statistics of interface call results, including: The remote interface agent management is a link pool management based on HTTP / HTTPS, which is used for network communication with the provider; The interface call function provides two calling modes: synchronous and asynchronous, and provides a retry function for abnormal interface calls; The statistical interface call result is to perform asynchronous call statistics on successful interface calls and provide the number of calls within a period of time, the average call time, the maximum call time and the minimum call time.

[0010] Optionally, the provider interface proxy is implemented through the rpc-provider module in the component, including initialization when the provider service starts, providing an HTTP HOST interface to the outside world, and monitoring and statistics interface calls, including: When the provider service is started, it is initialized as a provider that references the component. During initialization, it scans all interfaces and creates their respective sight objects. The HTTP HOST interface provided externally is an interface that maps to different interface implementation objects according to different URLs. When there is a remote call, it will be proxied to the corresponding method of the corresponding implementation object; The monitoring and statistics interface call is to perform asynchronous monitoring and statistics on each interface call.

[0011] Optionally, the monitoring of interface calls and early warning notification of abnormal data through the monitoring and early warning modules in the component include: The monitoring of the interface call is to trigger the interface call asynchronous monitoring after the interface call is successful, and different warning rules can be set according to the monitoring statistical data; The warning notification for abnormal data is to trigger the warning notification when the monitoring data reaches the abnormal rule threshold.

[0012] Optionally, the interface test is implemented by the rpc-test module in the component, including: The interface test is performed by simulating the consumer interface after the provider interface is developed.

[0013] Optionally, the online stateless deployment and horizontal expansion of microservices through the Nginx module in the component include: The Nginx is responsible for the interface direction proxy in the component. The consumer can configure the provider as the address of Nginx and proxy the interface call to the provider of Nginx reverse proxy.

[0014] Optionally, the method for implementing the remote interface function of the microservice architecture is characterized by: The rpc-consumer and rpc-provider modules implement configuration item management based on XML files; The rpc-consumer and rpc-provider modules communicate with each other through a custom interface public module, which is created by the provider.

[0015] The present application also provides a device for implementing the remote interface function of a microservice architecture, characterized in that the device includes: a memory, a processor, and a computer program stored in the memory and running on the processor.

[0016] Optionally, the device for implementing the remote interface function of the microservice architecture is characterized in that the storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium.

[0017] The present application also provides an electronic device, characterized in that it includes: a memory and a processor, the memory stores a computer program, and the processor implements a method for implementing the remote interface function of any of the microservice architectures when executing the computer program.

[0018] The beneficial effects of this application are: it can greatly simplify the complexity of application development, allowing developers to focus more on the business part, increase the proportion of business code in the overall code, shorten the development cycle, and reduce the original interface call problems that occur during the development process. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0020] Figure 1 A flowchart illustrating a method for implementing a remote interface function of a microservice architecture disclosed in this application; Figure 2 A diagram showing the internal structure of an rpu-utils module disclosed in this application is shown; Figure 3 Shows a flowchart of rpc-consumer initialization disclosed in this application; Figure 4 A flowchart showing a consumer interface call disclosed in this application is shown; Figure 5 A flowchart of a provider processing interface call disclosed in this application is shown. DETAILED DESCRIPTION

[0021] Various exemplary embodiments, features, and aspects of the present application will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise indicated.

[0022] The terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of the technical features indicated. Therefore, a feature specified as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this application, "plurality" means two or more, unless otherwise specifically defined.

[0023] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0024] In addition, numerous specific details are provided in the detailed description below to better illustrate the present application. Those skilled in the art will appreciate that the present application can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art are not described in detail in order to highlight the main purpose of the present application.

[0025] The present application is a method for implementing the remote interface function of a microservice architecture. In this method, the system implements remote calls between microservices through the component rpc-utils, which includes the rpc-consumer module and the rpc-provider module. The consumer calls the provider interface through a proxy, supporting synchronous and asynchronous calls, circuit breaking and degradation, and call statistics; the provider scans the interface during initialization and provides HTTP services to the outside world, while performing call monitoring and statistics. The solution also includes the rpc-test module for interface testing, as well as a monitoring and early warning system based on Prometheus and Grafana, which collects interface call data in real time and triggers abnormal warnings. In addition, Nginx, as a reverse proxy, supports stateless deployment and horizontal expansion of microservices.

[0026] like Figure 1 As shown, a method for implementing the remote interface function of the microservice architecture of an embodiment of the present application specifically includes the following steps: S100 uses the component rpc-utils to implement remote calls between providers and consumers in a microservice architecture.

[0027] Specifically, with the component rpc-utils as the core, the consumer interface call, provider interface proxy, interface monitoring statistics and interface testing functions in the remote interface call process are implemented. Through this component, the rapid construction, development and testing of microservices can be achieved.

[0028] S200, implements consumer interface calls through the rpc-consumer module in the component, including remote interface proxy management, providing interface call functions, and counting interface call results.

[0029] Specifically, the core functions of the rpc-consumer module include generating interface proxy objects through dynamic proxy technology, converting local calls to remote calls, processing network communication and serialization, and recording data indicators for monitoring and optimization. The rpc-consumer module implements remote interface proxy management through interface definition, dynamic proxy, proxy cache, and proxy destruction. The rpc-consumer module provides parameter serialization, request construction, network communication, response reception, and exception handling required for interface calls. It also integrates load balancing strategies and a fault-tolerant mechanism consisting of a retry mechanism and a circuit breaker mechanism. The statistical interface call results are statistically analyzed for the number of calls, success and failure times, response time, and exception information.

[0030] S300 implements the provider interface proxy through the rpc-provider module in the component, including initialization when the provider service starts, providing HTTP HOST interface to the outside world, and monitoring and statistics interface calls.

[0031] Specifically, the core functions of the rpc-provider module include registering the service and loading the local implementation class at startup, receiving consumer requests and calling the local service through the HTTP server, and recording data indicators for monitoring and optimization. The initialization work is to register the local service with the service registration center and store the metadata information of the service, as well as load the implementation class of the local service and expose the interface implementation class as a remote service. The HTTP HOST interface provided to the outside world is to use the HTTP server to listen to the HTTP request to obtain the request body, deserialize it into an RPC request object, and then call the implementation class of the local service according to the interface name and method name in the request, and serialize the call result into the corresponding data, and finally return it to the consumer. The statistical interface call result is to count and analyze the number of calls, the number of successes and failures, the response time and exception information.

[0032] S400, monitors interface calls and issues warning notifications for abnormal data through the monitoring and warning modules in the component.

[0033] Specifically, the core function of the monitoring module is to collect, store, and display data related to interface calls. This data is collected through point-of-use, log, and metric collection. Monitoring data is stored in a database, and call logs are stored in a logging system. Data presentation can be achieved through visualization tools or report generation. The core function of the early warning module is to determine whether early warning rules are triggered based on monitoring data and send early warning information. It supports multiple early warning rules, including threshold warnings, trend warnings, and anomaly warnings, and can make corresponding early warning judgments for different warning rules.

[0034] Among them, this solution develops exporter components and collector services based on Prometheuse and Grafana deployment; the exporter is used to collect and store monitoring data and report it to the collector service at regular intervals, and the collector exposes the HTTP interface to Prometheuse for monitoring data statistics.

[0035] S500, implements interface testing through the rpc-test module in the component.

[0036] Specifically, the rpc-test module performs interface testing by simulating consumer interface calls after the provider interface is developed. The rpc-test module is a separate backend consumer application that can perform visual interface testing after the service is deployed and built.

[0037] S600 uses the Nginx module in its components to achieve online stateless deployment and horizontal expansion of microservices.

[0038] Specifically, Nginx is a high-performance Web server. Consumers can configure the provider as the address of Nginx and proxy the interface call to the provider of Nginx reverse proxy.

[0039] In summary, the present invention uses the rpc-utils tool component, allowing consumers to call remote interfaces just like calling local methods, which simplifies communication development between microservices and improves development efficiency; enhances the system's fault tolerance and stability, reduces the service pressure on providers; supports custom warning rules to help quickly locate and solve problems; uses Nginx to implement reverse proxy, enhancing the scalability and high availability of the system; provides an efficient, stable, and easy-to-use solution for enterprise-level microservice development, significantly improving development, testing, and operation and maintenance efficiency.

[0040] like Figure 2 As shown in the figure, the internal structure of the rpu-utils module includes the following: Nginx, as a high-performance web server, plays the role of interface proxy in this solution; the monitoring and warning module develops exporter components and collector services based on Prometheuse and Grafana deployment to monitor data and push data that reaches the abnormal threshold to relevant people or groups; the rpc-test module is used to simulate consumer interface calls for interface testing; the rpc-consumer module is referenced by consumers to implement proxy calls of remote interfaces; the rpc-provider module is referenced by providers and initialized when the provider service starts, providing an HTTP HOST interface and monitoring and counting each interface call.

[0041] Specifically, the remote interface proxy management is a link pool management based on HTTP / HTTPS, which is used for network communication with the provider; the interface call function is to provide both synchronous and asynchronous calling methods, as well as an interface exception call retry function; the statistical interface call results are to perform asynchronous call statistics on successful interface calls and give the number of calls within a period of time, the average call time, the maximum call time and the minimum call time.

[0042] like Figure 4 As shown in the figure, the consumer interface calling process of the rpc-consumer module includes the following: First, determine whether an asynchronous interface callback is required. If the asynchronous callback object needs to be cached, the asynchronous callback method object will be stored in the ThreadLocal object when the asynchronous call is made and deleted after use.

[0043] Secondly, the system will try to obtain the interface proxy. If the acquisition fails, the consumer interface call process will end; if the acquisition is successful, the interface provider ID, asynchronous callback object, interface method and parameter serialization will be obtained.

[0044] Then, it will be decided whether the interface needs to receive verification. If verification is accepted, the number of retries will not be set during the verification process until the verification passes, and then asynchronous judgment will be performed. If there is asynchrony, the next process can be directly carried out. If there is no asynchrony, it is necessary to determine whether it is within the retry limit. If it passes, it will enter the next process. If it fails, the consumer interface call process will be terminated.

[0045] If verification is not accepted, an interface exception call retry function is provided, and a retry will be triggered after a non-verification business interface POST exception. The specific number of retries comes from the configuration item of the configuration file. Interfaces that do not accept verification also need to undergo consumer circuit breaking. The consumer circuit breaking is only for non-verification methods. The verification method does not determine the circuit breaking. After the interface responds, the circuit breaking asynchronous processing is called back. The interface call that enters the circuit breaking state will be downgraded. The downgraded interface will throw a specific downgraded exception and end the consumer interface call process. Consumers who pass the interface circuit breaking will then make asynchronous judgments. If there is asynchrony, they can proceed directly to the next process. If there is no asynchrony, they need to determine whether it is within the retry limit. If it passes, they will proceed to the next process. If it fails, the consumer interface call process will end.

[0046] Next, each consumer interface call will trigger a dynamic proxy. One interface call corresponds to an HTTP POST request, and the interface method and parameter data will be serialized into the parameter Body of this POST request. Serialization and deserialization of method objects and parameter objects are implemented through Hessian. Hessian is a lightweight, cross-language binary serialization protocol with a small data size, faster network transmission, and less resource consumption. Therefore, it is chosen as the tool for object serialization. If the result of the interface call is successful, it will enter the next process; if it fails, the consumer interface call process will end. In addition, each successful interface call will be asynchronously counted and the statistical results of all interface calls within a period of time (number of calls, average call time, maximum call time, and minimum call time) will be regularly given. This can be used as a data indicator for interface optimization.

[0047] Finally, the successful consumer interface call result is input into the fuse for callback. The callback result can be selected whether to be verified. If it is verified, the result can be output after completing the verification process. If it is not verified, the consumer interface call statistics and deserialization interface return value must be performed before the result is output.

[0048] The aforementioned circuit breaker is embedded and self-implemented. When a provider encounters an exception, it enters the blown state. During this state, abnormal interface calls are downgraded. The blown state is terminated when the maximum blown duration is reached or when the provider is detected to have recovered, thereby reducing the interface pressure on the provider's service and providing consumers with a unified interface exception handling method. The circuit breaker design has been simplified, retaining only two states: open and closed. The condition for opening is: if the failure rate of at least a certain number of requests within a period of time exceeds a certain value, the circuit breaker opens. The scope of the circuit breaker is a group of interface providers. Once opened, all interface calls within the group are downgraded unless closed. The closed state is entered when the open group of interfaces loses the conditions for opening or reaches the maximum blown duration.

[0049] Specifically, when the provider service is started, it is initialized as the provider referencing the component. During initialization, all interfaces are scanned and their respective sight objects are created; the HTTP HOST interface provided to the outside world is an interface mapped to different interface implementation objects according to different URLs, and when there is a remote call, it will be proxied to the corresponding method of the corresponding implementation object; the monitoring and statistics interface call is to perform asynchronous monitoring and statistics on each interface call.

[0050] like Figure 3 As shown in the figure, the consumer initialization process of the rpc-consumer module includes the following: First, load the xml configuration file. If the loading is successful, continue to create the interface proxy object. If it fails, end the initialization process. The loaded consumer configuration file configures all the interfaces to be used by the consumer.

[0051] Then, create an interface proxy object according to the configuration file. If the creation is successful, initialize the Http connection pool. If the creation fails, end the initialization process.

[0052] The Http connection pool is implemented based on OkHttpClient. The connection pool will set the read timeout of the interface according to the loaded configuration file, thereby realizing the call of the interface in a high-concurrency consumption scenario.

[0053] Next, the rpc-consumer module calls provider-validation as a special module to provide optional provider service validity validation during the initialization process.

[0054] Finally, if the provider service validity check is not required, the successful result can be output directly; if the provider service validity check is required, the check result is judged. If the result is successful, it can be output. If the result is a failure, the check needs to be reproduced until the result is successfully passed.

[0055] Specifically, the monitoring of interface calls is to trigger asynchronous monitoring of interface calls after the interface call is successful, and different warning rules can be set according to the monitoring statistical data; the warning notification of abnormal data is to trigger a warning notification when the monitoring data reaches the abnormal rule threshold.

[0056] like Figure 5 As shown, after the HTTP interface receives a POST request, it includes the following: The rpc-provider module first provides an Http interface to receive POST requests and verify whether it is a verification interface.

[0057] If it is a verification interface, there is no need for parameter verification, data deserialization and parsing, and reflection call, and a direct response is given.

[0058] Otherwise, parameter verification is required first, and then the interface parameter deserialization process is performed. That is, the Body of the POST request is deserialized through Hessian in the same way as the consumer, and the interface method called by the consumer and its parameter values are obtained. Finally, the interface provider implementation object and the corresponding method are obtained through Java reflection. Failure in any of the above steps will terminate the process.

[0059] Next, use reflection to obtain the implementation object and method. Specifically, call the corresponding method through the invoke() method and obtain the return value without parsing the return value result.

[0060] Then, the interface return value is serialized and responded to, specifically by serializing the result through Hessian as the result response of the POST request. Correspondingly, after receiving the POST response, the consumer deserializes it and returns it to the interface caller.

[0061] Specifically, the interface test is performed by simulating the consumer interface after the provider interface is developed.

[0062] In this solution, the rpc-test module simulates the consumer interface for testing. rpc-test is a special consumer that selects the interface method to be tested based on visual interface input, and its parameter values also come from the visual interface input. The test interface is implemented through Swagger, documenting the test interface display instructions. By filling in the request parameters, the corresponding interface call results are displayed on the Swagger interface. Developers and testers can use this to complete the testing and verification of the corresponding interface after deployment.

[0063] Specifically, the Nginx takes on the work of interface direction proxy in the component. The consumer can configure the provider as the address of Nginx and proxy the interface call to the provider of Nginx reverse proxy.

[0064] Among them, the calling method provided by the interface provider is HTTP POST. In order to realize the online deployment and horizontal expansion of the provider, it can be implemented based on Nginx. Nginx is a very excellent interface reverse proxy tool. The operation steps for online deployment and horizontal expansion of the interface provider are: first, deploy and start a new provider service process; second, mount the HTTP interface provided by the new provider service process on Nginx; finally, reload the Nginx configuration online.

[0065] Specifically, the rpc-consumer and rpc-provider modules implement configuration item management based on XML files; the rpc-consumer and rpc-provider modules perform parsing and communication through a custom interface public module, and the interface module is created by the provider.

[0066] This includes all interface files provided by the provider, public object files associated with the interfaces, constant files, public method files, the provider implementation class implements all interfaces of the module, and the consumer references the module for remote interface calls.

[0067] The above steps use a device for implementing the remote interface function of a microservice architecture, characterized in that the device includes: a memory, a processor, and a computer program stored in the memory and running on the processor.

[0068] An electronic device used in the above steps is characterized in that it includes: a memory and a processor, the memory stores a computer program, and the processor implements the remote interface function of any of the microservice architectures when executing the computer program.

[0069] The embodiments of the present application have been described above. The above description is illustrative and not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or improvements to the technology in the market, or to enable other persons skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for implementing a remote interface function of a microservice architecture, characterized in that: include: Use the component rpc-utils to implement remote calls between providers and consumers in the microservice architecture; Implement consumer interface calls through the rpc-consumer module in the component, including remote interface proxy management, providing interface call functions, and statistics of interface call results; Implement the provider interface proxy through the rpc-provider module in the component, including initialization when the provider service starts, providing HTTP HOST interface to the outside world, and monitoring and statistics interface calls; Monitor interface calls and issue warning notifications for abnormal data through the monitoring and warning modules in the components; Implement interface testing through the rpc-test module in the component; The Nginx module in the component is used to realize online stateless deployment and horizontal expansion of microservices.

2. The method for implementing the remote interface function of the microservice architecture according to claim 1, characterized in that: The rpc-consumer module in the component implements consumer interface calls, including remote interface proxy management, providing interface call functions, and statistics of interface call results, including: The remote interface agent management is a link pool management based on HTTP / HTTPS, which is used for network communication with the provider; The interface call function provides two calling modes: synchronous and asynchronous, and provides a retry function for abnormal interface calls; The statistical interface call result is to perform asynchronous call statistics on successful interface calls and provide the number of calls within a period of time, the average call time, the maximum call time and the minimum call time.

3. The method for implementing the remote interface function of the microservice architecture according to claim 1, characterized in that: The provider interface proxy is implemented through the rpc-provider module in the component, including initialization when the provider service starts, providing HTTP HOST interface to the outside world, and monitoring and statistics interface calls, including: When the provider service is started, it is initialized as a provider that references the component. During initialization, it scans all interfaces and creates their respective sight objects. The HTTP HOST interface provided externally is an interface that maps to different interface implementation objects according to different URLs. When there is a remote call, it will be proxied to the corresponding method of the corresponding implementation object; The monitoring and statistics interface call is to perform asynchronous monitoring and statistics on each interface call.

4. The method for implementing the remote interface function of the microservice architecture according to claim 1, wherein: The monitoring and warning modules in the components are used to monitor interface calls and issue warning notifications for abnormal data, including: The monitoring of the interface call is to trigger the interface call asynchronous monitoring after the interface call is successful, and different warning rules can be set according to the monitoring statistical data; The warning notification for abnormal data is to trigger the warning notification when the monitoring data reaches the abnormal rule threshold.

5. The method for implementing the remote interface function of the microservice architecture according to claim 1, characterized in that: The interface test is implemented by the rpc-test module in the component, including: The interface test is performed by simulating the consumer interface after the provider interface is developed.

6. The method for implementing the remote interface function of the microservice architecture according to claim 1, characterized in that: The online stateless deployment and horizontal expansion of microservices achieved through the Nginx module in the component include: The Nginx is responsible for the interface direction proxy in the component. The consumer can configure the provider as the address of Nginx and proxy the interface call to the provider of Nginx reverse proxy.

7. The method for implementing the remote interface function of the microservice architecture according to claim 1, characterized in that: The rpc-consumer and rpc-provider modules implement configuration item management based on XML files; The rpc-consumer and rpc-provider modules communicate with each other through a custom interface public module, which is created by the provider.

8. A device for implementing remote interface functions of a microservice architecture, characterized in that: The apparatus includes a memory, a processor, and a computer program stored in the memory and running on the processor.

9. The device for implementing the remote interface function of the microservice architecture according to claim 8, characterized in that The storage medium is a computer-readable storage medium, and a computer program is stored in the storage medium.

10. An electronic device, characterized in that: include: A memory and a processor, wherein a computer program is stored in the memory, wherein the processor implements the method for implementing the remote interface function of the microservice architecture described in any one of claims 1 to 7 when executing the computer program.

Images