Service calling method, system and equipment based on Java reflection and dynamic proxy

Abstract

The invention provides a service calling method, system and equipment based on Java reflection and dynamic proxy. The method comprises the steps that a Consumer end generates an HTTP request based on a target HTTP proxy class instance of a Dubbo service to be called corresponding to a remote procedure call request; and the Provider end receives the HTTP request, determines target Dubbo service interface information corresponding to the HTTP request, realizes a function corresponding to a Dubbo service to be called based on the target Dubbo service interface information by utilizing JAVA reflection so as to generate an HTTP response body, and feeds back the HTTP response body to the Consumer end. According to the method, the consistency and usability of service interfaces are kept, the dependence on a registration center can be remarkably reduced, a Dubbo framework can be easily removed, and communication among services is carried out completely depending on an HTTP (Hyper Text Transport Protocol).

Description

Technical Field

[0001] The present invention relates to the field of service communication technology under a microservice architecture, and in particular to a service calling method, system and device based on Java reflection and dynamic proxy. Background Art

[0002] In the wide application of microservice architecture, Dubbo framework has indeed won the favor of many enterprises with its significant advantages in building microservice systems and efficient RPC (Remote Procedure Call) communication capabilities. However, with the diversification and complexity of the service ecosystem, the challenges faced by Dubbo framework are becoming increasingly significant, especially its limitations in cross-language integration and registry center dependence.

[0003] Cross-language integration is an important requirement in modern microservice architecture. Since different programming languages ​​have their own advantages and applicable scenarios, enterprises often expect to be able to flexibly use multiple languages ​​to build services in microservice architecture. However, the Dubbo framework is mainly developed based on Java, which to some extent limits its direct integration capabilities with other non-Java language services. In order to overcome this obstacle, it is usually necessary to introduce additional middleware or protocol conversion layers, which undoubtedly increases the complexity and maintenance cost of the system.

[0004] At the same time, with the surge in the number of services and the increase in system complexity, the registry center that the Dubbo framework relies on is also facing challenges in stability and scalability. As the core component of service registration and discovery, the stability and performance of the registry center directly affect the operating efficiency of the entire microservice system. Once the registry center fails, it will directly lead to the interruption of communication between services, posing a serious threat to the stability and availability of the system. In addition, the maintenance and management of the registry center also requires a lot of resources and costs, further increasing the system's operation and maintenance burden. Summary of the invention

[0005] In view of this, the purpose of the present invention is to provide a service calling method, system and device based on Java reflection and dynamic proxy, which not only maintains the consistency and ease of use of the service interface, but also can significantly reduce the dependence on the registration center, and can easily remove the Dubbo framework and rely entirely on the HTTP protocol for service-to-service communication.

[0006] In a first aspect, the present invention provides a service calling method based on Java reflection and dynamic proxy, the method is applied to a service calling system, the service calling system includes a Consumer end and a Provider end, both the Consumer end and the Provider end are integrated with proxy components, the proxy component integrated in the Consumer end is used to create an HTTP proxy class instance using Java dynamic proxy technology, and the proxy component integrated in the Provider end is used to automatically create a Controller interface and scan Dubbo service interface information, the method includes:

[0007] The Consumer receives the remote procedure call request sent by the original caller, generates an HTTP request based on the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request, and sends the HTTP request to the Provider;

[0008] The Provider receives the HTTP request through the Controller interface, determines the target Dubbo service interface information corresponding to the HTTP request from the Dubbo service interface cache, and uses JAVA reflection to implement the corresponding function of the Dubbo service to be called based on the target Dubbo service interface information to generate an HTTP response body, and feeds the HTTP response body back to the Consumer.

[0009] The Consumer converts the HTTP response body to the specified data type and feeds the HTTP response body of the specified data type back to the original caller.

[0010] In one embodiment, before the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request, the method further includes:

[0011] Through the proxy component integrated in the Consumer side, load the Bean class instances of multiple Dubbo services registered in the Spring container of the Consumer side, use Java dynamic proxy technology to create an HTTP proxy class instance for each Bean class instance, and register the HTTP proxy class instance in the Spring container;

[0012] Among them, the priority of the HTTP proxy class instance is higher than the priority of the Bean class instance.

[0013] In one embodiment, generating an HTTP request based on a target HTTP proxy class instance of a Dubbo service to be called corresponding to a remote procedure call request includes:

[0014] Determine whether the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request is registered in the Spring container;

[0015] If the judgment result is yes, the target HTTP proxy class instance is used to encode the call information of the Dubbo service to be called into the HTTP request, where the call information includes the call parameters and the call method name.

[0016] In one implementation, the Provider receives an HTTP request through the Controller interface, including:

[0017] If the configuration item of HTTP proxy function is set in the configuration file of Provider, or if the annotation of HTTP proxy function is added to the Spring Boot startup class of Provider, make sure that HTTP proxy function is enabled on Provider.

[0018] When the HTTP proxy function is enabled on the Provider side, HTTP requests are received through the Controller interface.

[0019] In one embodiment, before determining the target Dubbo service interface information corresponding to the HTTP request from the Dubbo service interface cache, the method further includes:

[0020] The service scanning mechanism is automatically triggered by the proxy component integrated in the Provider. The service scanning mechanism is: the interface information marked by the @Service annotation of the Dubbo service is determined as the Dubbo service interface information;

[0021] The scanned Dubbo service interface information is stored in the Dubbo service interface cache.

[0022] In one implementation, the Dubbo service interface cache uses ConcurrentHashMap.

[0023] In one embodiment, the method further comprises:

[0024] Monitor whether the time it takes for the Consumer to connect to the Provider exceeds the connection time threshold, and / or monitor whether the time it takes for the Consumer to receive the HTTP response body exceeds the request time threshold;

[0025] If yes, it is determined that the remote procedure call request has failed, and the current number of retries corresponding to the remote procedure call request is updated;

[0026] If the current number of retries exceeds the retry count threshold, an error prompt is generated for the remote procedure call request.

[0027] In a second aspect, the present invention also provides a service calling system based on Java reflection and dynamic proxy, the service calling system includes a Consumer end and a Provider end, both of which are integrated with proxy components, the proxy component integrated in the Consumer end is used to create an HTTP proxy class instance using Java dynamic proxy technology, and the proxy component integrated in the Provider end is used to automatically create a Controller interface and scan Dubbo service interface information; wherein,

[0028] The Consumer side is used to: receive the remote procedure call request sent by the original caller, generate an HTTP request based on the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request, and send the HTTP request to the Provider side;

[0029] The Provider side is used to: receive HTTP requests through the Controller interface, determine the target Dubbo service interface information corresponding to the HTTP request from the Dubbo service interface cache, use JAVA reflection to implement the corresponding function of the Dubbo service to be called based on the target Dubbo service interface information, generate an HTTP response body, and feed the HTTP response body back to the Consumer side;

[0030] The Consumer side is also used to convert the HTTP response body into a specified data type and feed back the HTTP response body of the specified data type to the original caller.

[0031] In a third aspect, the present invention further provides an electronic device, comprising a processor and a memory, wherein the memory stores computer executable instructions that can be executed by the processor, and the processor executes the computer executable instructions to implement any one of the methods provided in the first aspect.

[0032] In a fourth aspect, the present invention further provides a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions prompt the processor to implement any one of the methods provided in the first aspect.

[0033] The present invention provides a service calling method, system and device based on Java reflection and dynamic proxy. The service calling system includes a Consumer end and a Provider end. Both the Consumer end and the Provider end are integrated with proxy components. The proxy component integrated in the Consumer end is used to create an HTTP proxy class instance using Java dynamic proxy technology, and the proxy component integrated in the Provider end is used to automatically create a Controller interface and scan Dubbo service interface information. If the Consumer end receives a remote procedure call request sent by the original caller, an HTTP request is generated based on the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request, and the HTTP request is sent to the Provider end. Then the Provider end receives the HTTP request through the Controller interface, determines the target Dubbo service interface information corresponding to the HTTP request from the Dubbo service interface cache, and uses JAVA reflection to implement the function corresponding to the Dubbo service to be called based on the target Dubbo service interface information to generate an HTTP response body, and feeds the HTTP response body back to the Consumer end. Finally, the Consumer end converts the HTTP response body to a specified data type, and feeds the HTTP response body of the specified data type back to the original caller. The above method uses Java reflection and dynamic proxy technology to convert remote procedure call requests that originally relied on the registration center into HTTP requests in real time and seamlessly. This conversion mechanism not only maintains the consistency and ease of use of the service interface, but also significantly reduces the dependence on the registration center and enhances the independence and stability of the system; more importantly, by converting to HTTP requests, the Dubbo framework can be easily removed in specific scenarios, and the HTTP protocol can be completely relied upon for inter-service communication, thereby further simplifying the system architecture, reducing the complexity of operation and maintenance, and improving the flexibility and scalability of the system.

[0034] Other features and advantages of the present invention will be described in the following description, and partly become apparent from the description, or understood by practicing the present invention. The purpose and other advantages of the present invention are realized and obtained by the structures particularly pointed out in the description, claims and drawings.

[0035] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the preferred embodiments are specifically mentioned below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0037] Figure 1 A flow chart of a service calling method based on Java reflection and dynamic proxy provided by an embodiment of the present invention;

[0038] Figure 2 A technical flow chart of a service calling method based on Java reflection and dynamic proxy provided by an embodiment of the present invention;

[0039] Figure 3 A schematic diagram of the structure of a service calling system based on Java reflection and dynamic proxy provided by an embodiment of the present invention;

[0040] Figure 4 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0041] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution of the present invention will be clearly and completely described in combination with the embodiments below. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0042] In the evolution of microservice architecture, Dubbo framework, as a highly respected high-performance RPC solution in the Java community, has indeed provided strong support for efficient communication between microservices. However, with the widespread application of microservice architecture and the rapid growth of the number of services, the registration center mechanism that Dubbo framework relies on has gradually exposed a series of stability and scalability bottlenecks. At the same time, some of its inherent defects are particularly prominent in the current technical context. The following are the main manifestations of the defects of this background technology:

[0043] 1. Strong dependence on the registration center: The Dubbo framework is highly dependent on the registration center for service registration and discovery. Once the registration center fails, the entire microservice system may be seriously affected, resulting in interruption of communication between services, which in turn affects the normal operation of the business. Moreover, the strong dependence on the registration center increases the risk of single point failure of the system and reduces the overall stability and availability of the system.

[0044] 2. Language integration limitations: The current core advantage of the Dubbo framework lies in its deep support for the Java language, but this feature also brings limitations in language integration. As multi-language microservice architectures become increasingly popular, Dubbo's focus on Java services limits its ability to directly integrate with services written in non-Java languages. This means that when the system needs to integrate microservices written in multiple languages, Dubbo may not be able to be used directly as a unified communication framework, thereby increasing the complexity and cost of system integration. To overcome this limitation, developers may need to find or develop additional bridging solutions to ensure that services written in different languages ​​can communicate smoothly, which undoubtedly increases the complexity and maintenance difficulty of the system.

[0045] 3. High deployment and operation and maintenance costs: As the number of services increases, the deployment and operation and maintenance complexity of the Dubbo framework also increases. This includes the configuration and management of multiple components such as the registration center and the monitoring center, which increases the workload and operation and maintenance costs of the operation and maintenance personnel. At the same time, the highly complex system architecture also increases the difficulty of system maintenance and troubleshooting.

[0046] 4. Performance bottleneck: In high-concurrency scenarios, the Dubbo framework may face performance bottlenecks. Although Dubbo itself provides high-performance RPC communication capabilities, the performance and stability of the registration center may also become a key factor restricting the performance of the entire system. In addition, when processing large-scale service calls, the Dubbo framework may need more efficient load balancing and fault tolerance mechanisms to deal with possible performance issues.

[0047] 5. Large resource demand: As the number of microservice instances continues to increase, each service instance needs to register with the registration center and maintain a heartbeat, which greatly increases the CPU (Central Processing Unit) and memory burden of the server. At the same time, RPC calls between services and data synchronization operations in the registration center will occupy a large amount of network bandwidth, especially in scenarios where services are widely distributed and frequently called, bandwidth pressure is particularly prominent. This surge in resource usage not only increases the system's operation and maintenance costs, but may also limit the further expansion of the system due to resource bottlenecks, increasing the complexity of the system architecture and the difficulty of maintenance.

[0048] 6. Lack of flexibility: With the continuous development of technology and changes in business needs, microservice architecture needs to maintain a high degree of flexibility and adaptability. However, the traditional Dubbo framework is relatively rigid in some aspects and it is difficult to quickly adapt to changes in new technologies and business models. When it is necessary to quickly migrate the technology stack or optimize system performance, the dependencies and limitations of the Dubbo framework may become an obstacle.

[0049] In view of the above pain points, especially under the demand of resource limitation and cross-language integration, the present invention provides a service calling method, system and device based on Java reflection and dynamic proxy, which uses Java reflection and dynamic proxy technology to convert the RPC call request originally dependent on the registration center into HTTP (Hypertext Transfer Protocol) request in real time and seamlessly. This conversion mechanism not only maintains the consistency and ease of use of the service interface, but also significantly reduces the dependence on the registration center, and enhances the independence and stability of the system.

[0050] More importantly, by converting to HTTP requests, this solution greatly facilitates cross-language integration. As a common protocol on the Internet, HTTP has wide compatibility and optimization support. Services written in different languages ​​can communicate through the HTTP protocol without worrying about the obstacles caused by language differences. Therefore, in specific scenarios, such as technology stack migration, cost optimization, or environmental restrictions, the system can easily remove the Dubbo framework and rely entirely on the HTTP protocol for inter-service communication, thereby further simplifying the system architecture, reducing the complexity of operation and maintenance, and improving the flexibility and scalability of the system.

[0051] In summary, the embodiments of the present invention are not only an effective supplement and enhancement to the Dubbo framework, but also provide an innovative communication solution to replace the Dubbo framework in cross-language integration and specific demand scenarios. By reducing the dependence on the registration center and introducing the HTTP communication mechanism, it can provide strong support for the flexible deployment, efficient expansion and reliable operation of the microservice architecture.

[0052] To facilitate understanding of this embodiment, a service call method based on Java reflection and dynamic proxy disclosed in an embodiment of the present invention is first introduced in detail. The method is applied to a service call system, which includes a Consumer (service consumer) end and a Provider (service provider) end. Both the Consumer end and the Provider end are integrated with proxy components. The proxy component integrated in the Consumer end is used to create an HTTP proxy class instance using Java dynamic proxy technology, and the proxy component integrated in the Provider end is used to automatically create a Controller interface and scan Dubbo service interface information. Figure 1 The flowchart of a service calling method based on Java reflection and dynamic proxy is shown, and the method mainly includes the following steps S102 to S106:

[0053] In step S102, the Consumer receives the remote procedure call request sent by the original caller, generates an HTTP request based on the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request, and sends the HTTP request to the Provider.

[0054] Among them, the remote procedure call (RPC) request is used to instruct the Consumer to call the Dubbo service to be called, and it can carry the identifier of the Dubbo service to be called; the target HTTP proxy class instance is the HTTP proxy class instance created for the Dubbo service to be called, and the HTTP proxy class instance is used to encode the call information of the Dubbo service to be called into the HTTP request.

[0055] In one implementation, it is necessary to create corresponding HTTP proxy class instances for multiple Dubbo services in advance and register them in the Spring container. When the Consumer receives the RPC request sent by the original caller, the Consumer can search the Spring container for the target HTTP proxy class instance corresponding to the Dubbo service to be called. If it exists, the target HTTP proxy class instance can be used to generate the corresponding HTTP request, so that the RPC request of the Dubbo service is seamlessly converted into an HTTP request, and the HTTP request is sent to the Provider.

[0056] In step S104, the Provider receives the HTTP request through the Controller interface, determines the target Dubbo service interface information corresponding to the HTTP request from the Dubbo service interface cache, and uses JAVA reflection to implement the function corresponding to the Dubbo service to be called based on the target Dubbo service interface information to generate an HTTP response body, and feeds the HTTP response body back to the Consumer.

[0057] Among them, the Dubbo service interface cache can use ConcurrentHashMap; the Dubbo service interface information, that is, the information of the interface marked by the @Service annotation of the Dubbo service, is stored in ConcurrentHashMap; the HTTP response body, that is, the response data generated for the HTTP request.

[0058] In one implementation, the Provider side needs to start the HTTP proxy service, on this basis, it can receive HTTP requests through the Controller interface; after the Provider side receives the HTTP request, the proxy component integrated in the Provider side will obtain the target Dubbo service interface information corresponding to the HTTP request from the ConcurrentHashMap, including the full class name, method name, request parameters, response parameters, etc., obtain the method object of the local method through JAVA reflection, and execute the invoke method to implement the function corresponding to the Dubbo service to be called, thereby obtaining the HTTP response body, and finally feeding back the HTTP response body to the Consumer side.

[0059] Step S106: The Consumer end converts the HTTP response body into a specified data type, and feeds back the HTTP response body of the specified data type to the original caller.

[0060] The specified data type is also the return type of the original Dubbo service. In one embodiment, the HTTP response body is converted to the return type of the original Dubbo service, and the converted HTTP response body is fed back to the original caller according to the method signature of the Dubbo service.

[0061] The service calling method based on Java reflection and dynamic proxy in the embodiment of the present invention cleverly combines the advantages of Java reflection and dynamic proxy technology, aiming to fundamentally optimize the service communication mechanism in the microservice architecture. Its core goal is to dynamically remove the deep dependence on the Dubbo framework and its external registration center, thereby significantly improving the stability, availability and communication flexibility of the system.

[0062] Specifically, the embodiment of the present invention converts the communication protocol between services in real time, from the traditional RPC call to lightweight communication based on HTTP, thereby reducing the risk of service interruption caused by the failure of the registration center and enhancing the self-recovery ability and fault tolerance of the system. At the same time, this transformation also greatly simplifies the deployment and operation and maintenance process, reduces the dependence on external components, thereby improving resource utilization and system scalability. In addition, the embodiment of the present invention is also intended to enhance the maintainability of the microservice architecture, making the system easier to understand and maintain by reducing complex configurations and dependencies. This lightweight and flexible communication method also provides greater flexibility and convenience for future technology upgrades and architecture adjustments. In summary, the purpose of the embodiment of the present invention is to optimize the service communication experience under the microservice architecture through the innovative application of Java reflection and dynamic proxy technology, and achieve a comprehensive improvement in system stability, availability, communication flexibility, resource utilization, scalability and maintainability.

[0063] For ease of understanding, the present invention provides a specific implementation of a service invocation method based on Java reflection and dynamic proxy, see Figure 2 The technical flow chart of a service call method based on Java reflection and dynamic proxy shown mainly includes component integration; component configuration, service scanning, and service exposure on the Provider side; component configuration, HTTP proxy creation, and HTTP proxy registration on the Consumer side; remote call, request processing, and response processing. The embodiment of the present invention describes each key step in detail:

[0064] 1. Component Integration:

[0065] In the Spring Boot projects on both the Provider and Consumer sides, you need to introduce the spring-boot-starter-http-proxy-dubbo (hereinafter referred to as the proxy component) component. This step is the basis for enabling the dynamic proxy function of the Dubbo service, allowing the Dubbo service to communicate through the HTTP protocol.

[0066] (II) Provider integration and processing:

[0067] (2.1) Component configuration:

[0068] On the Provider side, the main purpose is to enable the HTTP proxy function of the Dubbo service so that the Consumer side can call these services through the HTTP protocol. There are usually two configuration methods:

[0069] Method 1, configuration file method: If the configuration item of HTTP proxy function is set in the configuration file of Provider, then make sure that HTTP proxy function is enabled on Provider. In specific implementation, in the configuration file (such as application.properties or application.yml), set the configuration item of HTTP proxy function http.proxy.dubbo.enable = true to explicitly enable the HTTP proxy function of Dubbo service.

[0070] Method 2: Annotation method: If the HTTP proxy function annotation is added to the Spring Boot startup class on the Provider side, the HTTP proxy function is enabled on the Provider side. In the specific implementation, add the @EnableHttpProxyDubbo annotation to the Spring Boot startup class to enable the HTTP proxy function programmatically. The @EnableHttpProxyDubbo annotation is also the annotation for the HTTP proxy function.

[0071] (2.2) Service Scan:

[0072] The proxy component automatically scans and caches Dubbo service interface information.

[0073] In one embodiment, a service scanning mechanism is automatically triggered by a proxy component integrated in the Provider end. The service scanning mechanism is: the interface information marked by the @Service annotation of the Dubbo service is determined as the Dubbo service interface information; and the scanned Dubbo service interface information is stored in the Dubbo service interface cache.

[0074] Specifically, when the Spring Boot application is started, the proxy component automatically triggers the service scanning mechanism. The scanning process will traverse all classes defined in the application and look for interfaces marked with the @Service annotation of the Dubbo service. The Dubbo service interface information identified during the scanning process is stored in ConcurrentHashMap. Due to its high concurrency characteristics, ConcurrentHashMap can ensure fast access and update of cached data in a multi-threaded environment, thereby further improving the response speed and stability of the system.

[0075] (2.3) Service exposure:

[0076] The proxy component automatically creates a Controller interface to receive HTTP requests from the Consumer. The path of the Controller interface follows the format of / {service-class-name} / {method}, where {service-class-name} is the class name of the Dubbo service interface and {method} is the name of the method in the interface.

[0077] On this basis, after receiving the HTTP request, the Provider will use the Dubbo framework to execute the Dubbo bean method through Java reflection and return the result to the Consumer.

[0078] (III) Consumer integration and processing:

[0079] (3.1) Component configuration: On the Consumer side, the focus of configuration is to specify the Dubbo service to be proxied and its HTTP access details. For example: specify the Provider service interface information to be proxied in the configuration file, including the HTTP service address and service interface name. Configuration is usually performed in the application configuration file. The specific configuration items are as follows:

[0080] (a) Basic URL configuration: http.proxy.dubbo.service.{service-class-name}.base-url=http: / / {ip}:{port} / {content-path};

[0081] {service-class-name}: The full path name of the Dubbo service interface class that needs to be proxied, and each configuration item needs to be set separately for each Dubbo service you want to proxy.

[0082] {ip} and {port}: IP address and port number of the HTTP service on the Provider side.

[0083] {content-path}: The end of the base URL, indicating the root path of the service.

[0084] (b) Class name configuration: http.proxy.dubbo.service.{service-class-name}.class-name = dubbo interface class name;

[0085] Explicitly specifying the full path name of the Dubbo interface class helps the framework to perform accurate matching and proxying.

[0086] (c) Set the connection timeout and request timeout, usually in milliseconds:

[0087] Connection timeout: http.proxy.dubbo.service.{service-class-name}.connect-timeout=100;

[0088] Request timeout: http.proxy.dubbo.service.{service-class-name}.read-timeout=1000.

[0089] (d) Set the number of retries when a request fails:

[0090] http.proxy.dubbo.service.{service-class-name}.retries=1.

[0091] (e) Asynchronous call configuration, specify whether to use asynchronous call by default:

[0092] http.proxy.dubbo.service.{service-class-name}.async=true.

[0093] (3.2) Create an HTTP proxy:

[0094] In one implementation, a proxy component integrated in the Consumer side is used to load multiple Bean class instances of Dubbo services registered in the Spring container of the Consumer side, and a HTTP proxy class instance is created for each Bean class instance using Java dynamic proxy technology.

[0095] Specifically, for each Dubbo service to be proxied, the proxy component will implement the InvocationHandler interface based on Java dynamic proxy technology to create an HTTP proxy class instance. When the HTTP proxy class instance receives an RPC request, it will not directly call the Dubbo service method, but will initiate an HTTP request to the corresponding Controller interface on the Provider side.

[0096] (3.3) Register HTTP proxy:

[0097] In one implementation, the HTTP proxy class instance is registered in the Spring container, and the priority of the HTTP proxy class instance is higher than the priority of the Bean class instance.

[0098] Specifically, the created HTTP proxy class instance will be registered in the Spring container and marked as Primary to ensure that it has priority during automatic assembly. In this way, when the Dubbo service on the Consumer side is injected and used, the HTTP proxy class instance is actually injected. The HTTP proxy class instance converts the RPC request that calls the Dubbo service into an HTTP request and sends it to the Provider side.

[0099] Through the above process, the RPC calls of the Dubbo service are seamlessly converted to HTTP requests, allowing the Consumer and Provider to communicate directly through the HTTP protocol. This conversion process does not require a lot of modifications to the original service code, greatly improving the flexibility and interoperability of the microservice architecture. At the same time, this transformation also provides great convenience for cross-network and cross-language service calls, making the microservice architecture more flexible and efficient in deployment, expansion and maintenance. It is worth noting that this conversion capability can easily remove the Dubbo framework and rely entirely on the HTTP protocol for inter-service communication, further simplifying the system architecture and operation and maintenance complexity.

[0100] (IV) Remote call and response processing: The remote call and response processing process is transparent to the developer on the Consumer side. It is the same as directly calling the local Dubbo service. There is no need to worry about how the underlying layer communicates through HTTP. The specific contents are as follows:

[0101] (4.1) Remote call, including the following process:

[0102] First, the Consumer receives the remote procedure call request sent by the original caller;

[0103] Then, determine whether the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request is registered in the Spring container;

[0104] Then, if the judgment result is yes, the target HTTP proxy class instance is used to encode the call information of the Dubbo service to be called into the HTTP request, and the call information includes the call parameters and the call method name;

[0105] Finally, the HTTP request is sent to the Provider.

[0106] In the specific implementation, when the Consumer sends an RPC request to call the Dubbo service, the HTTP proxy class instance encodes the parameters, method name and other information of the Dubbo service call into the HTTP request, and initiates an HTTP request to the Provider.

[0107] (4.2) Request processing, including the following process:

[0108] First, when the HTTP proxy function is enabled on the Provider side, HTTP requests are received through the Controller interface;

[0109] Then, determine the target Dubbo service interface information corresponding to the HTTP request from the Dubbo service interface cache;

[0110] Next, use JAVA reflection to implement the corresponding functions of the Dubbo service to be called based on the target Dubbo service interface information to generate an HTTP response body;

[0111] Finally, the HTTP response body is fed back to the Consumer.

[0112] In the specific implementation, after receiving the request from the Consumer, the proxy component will obtain the interface metadata (that is, the target Dubbo service interface information) from the Dubbo service interface cache, including the full class name, method name, request parameters, response parameters, etc., obtain the method object of the local method through JAVA reflection, execute the invoke method, and return the generated HTTP response body to the Consumer.

[0113] (4.3) Response processing, including the following processes:

[0114] The Consumer converts the HTTP response body to the specified data type and feeds the HTTP response body of the specified data type back to the original caller.

[0115] In the specific implementation, the HTTP response body is received, the data in the HTTP response body is parsed, and it is converted from the HTTP transmission format (such as JSON, XML) back to the return type of the original Dubbo service method. According to the method signature of the Dubbo service, the converted HTTP response body is returned to the original caller on the Consumer side.

[0116] Furthermore, the embodiment of the present invention can also monitor the success or failure of the RPC request, including:

[0117] (I) Monitor whether the duration of the Consumer end connecting to the Provider end exceeds the connection duration threshold, and / or monitor whether the duration of the Consumer end receiving the HTTP response body exceeds the request duration threshold. In one example, the aforementioned connection timeout time can be used as the connection duration threshold to determine whether there is a connection timeout; the aforementioned request timeout time can be used as the request duration threshold to determine whether there is a request timeout.

[0118] (II) If yes, it is determined that the remote procedure call request has failed, and the current retry count corresponding to the remote procedure call request is updated. In one example, if there is a connection timeout or request timeout, it can be determined that the RPC request to call the Dubbo service has failed, and the current retry count is increased by 1 as the new current retry count.

[0119] (III) If the current number of retries exceeds the retry number threshold, an error prompt is generated for the remote procedure call request. In one example, the number of retries set when the request fails can be used as the retry number threshold, and if the new current number of retries exceeds the retry number threshold, an error can be reported.

[0120] The embodiment of the present invention not only realizes the seamless HTTP conversion of Dubbo service RPC calls by introducing Java reflection and dynamic proxy technology, but also gives the system the ability to easily remove the Dubbo framework in specific scenarios. This feature enables the microservice architecture to quickly adapt and reduce migration risks when faced with scenarios such as technology stack adjustments, cost optimization, or specific environmental restrictions. Specifically, when business needs or technical environment changes require reducing reliance on the RPC framework or completely switching to an HTTP-based communication mode, this solution does not require a lot of modifications to the service code to achieve a smooth transition. This not only simplifies the system architecture, but also further reduces the complexity of operation and maintenance, providing greater flexibility and selectivity for the long-term development of the microservice architecture. The detailed description is as follows:

[0121] 1. Enhance system stability and fault tolerance: By reducing the reliance on the registration center, the system can maintain smooth communication between services when the registration center fails, avoiding the entire system crash caused by a single point of failure. This mechanism significantly improves the stability and fault tolerance of the system and ensures business continuity and availability.

[0122] 2. Reduce deployment and operation and maintenance costs: Since there is no need to maintain complex registration centers and other related components, the system deployment and operation and maintenance process is simplified. Operation and maintenance personnel can devote more energy to the core business logic and performance optimization of the service instead of spending time on configuring and managing various middleware, reducing operation and maintenance costs and improving operation and maintenance efficiency.

[0123] 3. Improve system performance: HTTP, as a common protocol on the Internet, has extensive optimization support and rich network facilities. By converting RPC calls to HTTP requests, it is easier to use existing load balancing, caching, and acceleration mechanisms to improve system performance. In addition, HTTP requests usually have lower resource usage than RPC calls, which helps to maintain stable operation of the system in high-concurrency scenarios.

[0124] 4. Optimize resource usage: Reducing dependence on the registry and the use of RPC calls can significantly reduce the consumption of resources such as the server's CPU, memory, and network bandwidth. This resource optimization not only helps to reduce the system's operation and maintenance costs, but also provides more room for further expansion of the system. This optimization is particularly important in a resource-constrained environment.

[0125] 5. Maintain the consistency and usability of the service interface: This solution cleverly maintains the consistency and usability of the original service interface of the Dubbo framework, which means that developers can easily migrate services to the new communication mechanism without changing the existing code structure. This smooth migration feature reduces the difficulty and cost of technology upgrades and protects developers' investments.

[0126] 6. Improve the flexibility and scalability of the system: By introducing dynamic proxy and reflection mechanisms, this solution makes communication between services more flexible and scalable. Developers can dynamically adjust the communication protocol and transmission method as needed. In specific scenarios, the Dubbo framework can be removed through this solution to adapt to different business scenarios and performance requirements. This flexibility provides more possibilities for the future development of the system.

[0127] In summary, the Dubbo removal solution based on Java reflection and dynamic proxy has significant beneficial effects in improving system stability, reducing operation and maintenance costs, improving performance, optimizing resource utilization, and maintaining service interface consistency and ease of use.

[0128] Based on the above embodiments, the present invention provides a service calling system based on Java reflection and dynamic proxy. Figure 3 The structure diagram of a service call system based on Java reflection and dynamic proxy is shown, the service call system includes a Consumer end 302 and a Provider end 304, both of which are integrated with proxy components, the proxy component integrated in the Consumer end 302 is used to create an HTTP proxy class instance using Java dynamic proxy technology, and the proxy component integrated in the Provider end 304 is used to automatically create a Controller interface and scan Dubbo service interface information; wherein,

[0129] The Consumer end 302 is used to: receive the remote procedure call request sent by the original caller, generate an HTTP request based on the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request, and send the HTTP request to the Provider end 304;

[0130] The Provider end 304 is used to: receive HTTP requests through the Controller interface, determine the target Dubbo service interface information corresponding to the HTTP request from the Dubbo service interface cache, use JAVA reflection to implement the function corresponding to the Dubbo service to be called based on the target Dubbo service interface information, so as to generate an HTTP response body, and feed the HTTP response body back to the Consumer end 302;

[0131] The Consumer end 302 is further used to convert the HTTP response body into a specified data type, and feed back the HTTP response body of the specified data type to the original caller.

[0132] The service calling device based on Java reflection and dynamic proxy provided by the embodiment of the present invention utilizes Java reflection and dynamic proxy technology to convert the remote procedure call request that originally relied on the registration center into HTTP request in real time and seamlessly. This conversion mechanism not only maintains the consistency and ease of use of the service interface, but also significantly reduces the dependence on the registration center, and enhances the independence and stability of the system; more importantly, by converting to HTTP requests, the Dubbo framework can be easily removed in specific scenarios, and the HTTP protocol can be completely relied upon for service-to-service communication, thereby further simplifying the system architecture, reducing the complexity of operation and maintenance, and improving the flexibility and scalability of the system.

[0133] In one embodiment, before the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request, the method further includes:

[0134] Through the proxy component integrated in the Consumer end 302, multiple Bean class instances of Dubbo services registered in the Spring container of the Consumer end 302 are loaded, and the HTTP proxy class instance is created for each Bean class instance using the Java dynamic proxy technology, and the HTTP proxy class instance is registered in the Spring container;

[0135] Among them, the priority of the HTTP proxy class instance is higher than the priority of the Bean class instance.

[0136] In one embodiment, generating an HTTP request based on a target HTTP proxy class instance of a Dubbo service to be called corresponding to a remote procedure call request includes:

[0137] Determine whether the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request is registered in the Spring container;

[0138] If the judgment result is yes, the target HTTP proxy class instance is used to encode the call information of the Dubbo service to be called into the HTTP request, where the call information includes the call parameters and the call method name.

[0139] In one implementation, the Provider 304 receives an HTTP request through the Controller interface, including:

[0140] If a configuration item of the HTTP proxy function is set in the configuration file of the Provider end 304, or if an annotation of the HTTP proxy function is added to the Spring Boot startup class of the Provider end 304, it is determined that the HTTP proxy function is enabled on the Provider end 304;

[0141] When the HTTP proxy function is enabled on the Provider side 304, HTTP requests are received through the Controller interface.

[0142] In one embodiment, before determining the target Dubbo service interface information corresponding to the HTTP request from the Dubbo service interface cache, the method further includes:

[0143] The service scanning mechanism is automatically triggered by the proxy component integrated in the Provider end 304. The service scanning mechanism is: the interface information marked by the @Service annotation of the Dubbo service is determined as the Dubbo service interface information;

[0144] The scanned Dubbo service interface information is stored in the Dubbo service interface cache.

[0145] In one implementation, the Dubbo service interface cache uses ConcurrentHashMap.

[0146] In one embodiment, the method further comprises:

[0147] Monitor whether the duration of the connection between the Consumer end 302 and the Provider end 304 exceeds a connection duration threshold, and / or monitor whether the duration of the reception of the HTTP response body by the Consumer end 302 exceeds a request duration threshold;

[0148] If yes, it is determined that the remote procedure call request has failed, and the current number of retries corresponding to the remote procedure call request is updated;

[0149] If the current number of retries exceeds the retry count threshold, an error prompt is generated for the remote procedure call request.

[0150] The device provided in the embodiment of the present invention has the same implementation principle and technical effects as those of the aforementioned method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference may be made to the corresponding contents in the aforementioned method embodiment.

[0151] An embodiment of the present invention provides an electronic device. Specifically, the electronic device includes a processor and a storage device. The storage device stores a computer program, and when the computer program is executed by the processor, it executes the method described in any one of the above-mentioned implementation methods.

[0152] Figure 4A structural diagram of an electronic device provided in an embodiment of the present invention, the electronic device 100 includes: a processor 40, a memory 41, a bus 42 and a communication interface 43, wherein the processor 40, the communication interface 43 and the memory 41 are connected via the bus 42; the processor 40 is used to execute an executable module stored in the memory 41, such as a computer program.

[0153] The memory 41 may include a high-speed random access memory (RAM), and may also include a non-volatile memory, such as at least one disk memory. The communication connection between the system network element and at least one other network element is realized through at least one communication interface 43 (which may be wired or wireless), and the Internet, wide area network, local area network, metropolitan area network, etc. may be used.

[0154] The bus 42 may be an ISA bus, a PCI bus, or an EISA bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0155] Among them, the memory 41 is used to store programs, and the processor 40 executes the program after receiving the execution instruction. The method executed by the device for flow process definition disclosed in any embodiment of the above-mentioned embodiment of the present invention can be applied to the processor 40 or implemented by the processor 40.

[0156] The processor 40 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit or software instructions in the processor 40. The above processor 40 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present invention can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the embodiments of the present invention can be directly embodied as a hardware decoding processor to execute, or can be executed by a combination of hardware and software modules in the decoding processor. 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, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 41, and the processor 40 reads the information in the memory 41 and completes the steps of the above method in combination with its hardware.

[0157] The computer program product of the readable storage medium provided in the embodiment of the present invention includes a computer-readable storage medium storing program code, and the instructions included in the program code can be used to execute the methods described in the previous method embodiments. The specific implementation can be referred to the previous method embodiments, which will not be repeated here.

[0158] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc., which can store program codes.

[0159] Finally, it should be noted that the above-described embodiments are only specific implementations of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The protection scope of the present invention is not limited thereto. Although the present invention is described in detail with reference to the above-described embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-described embodiments within the technical scope disclosed by the present invention, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A service calling method based on Java reflection and dynamic proxy, characterized in that: The method is applied to a service calling system, the service calling system includes a Consumer end and a Provider end, both the Consumer end and the Provider end are integrated with a proxy component, the proxy component integrated in the Consumer end is used to create an HTTP proxy class instance using Java dynamic proxy technology, and the proxy component integrated in the Provider end is used to automatically create a Controller interface and scan Dubbo service interface information, the method includes: The Consumer receives the remote procedure call request sent by the original caller, generates an HTTP request based on the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request, and sends the HTTP request to the Provider; The Provider receives the HTTP request through the Controller interface, determines the target Dubbo service interface information corresponding to the HTTP request from the Dubbo service interface cache, implements the function corresponding to the to-be-called Dubbo service based on the target Dubbo service interface information using JAVA reflection, generates an HTTP response body, and feeds the HTTP response body back to the Consumer; The Consumer end converts the HTTP response body into a specified data type, and feeds back the HTTP response body of the specified data type to the original caller.

2. The service calling method based on Java reflection and dynamic proxy according to claim 1 is characterized in that: Before the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request, the method further includes: Through the proxy component integrated in the Consumer end, load the Bean class instances of multiple Dubbo services registered in the Spring container of the Consumer end, create an HTTP proxy class instance for each of the Bean class instances using Java dynamic proxy technology, and register the HTTP proxy class instance in the Spring container; Among them, the priority of the HTTP proxy class instance is higher than the priority of the Bean class instance.

3. The service calling method based on Java reflection and dynamic proxy according to claim 2 is characterized in that: Generate an HTTP request based on the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request, including: Determine whether the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request is registered in the Spring container; If the judgment result is yes, the target HTTP proxy class instance is used to encode the call information of the to-be-called Dubbo service into the HTTP request, wherein the call information includes call parameters and a call method name.

4. The service calling method based on Java reflection and dynamic proxy according to claim 1 is characterized in that: The Provider receives the HTTP request through the Controller interface, including: If a configuration item of the HTTP proxy function is set in the configuration file of the Provider, or if an annotation of the HTTP proxy function is added to the Spring Boot startup class of the Provider, it is determined that the HTTP proxy function is enabled on the Provider; When the HTTP proxy function is enabled on the Provider side, the HTTP request is received through the Controller interface.

5. The service calling method based on Java reflection and dynamic proxy according to claim 1 is characterized in that: Before determining the target Dubbo service interface information corresponding to the HTTP request from the Dubbo service interface cache, the method further includes: The service scanning mechanism is automatically triggered by the proxy component integrated in the Provider end. The service scanning mechanism is: the interface information marked by the @Service annotation of the Dubbo service is determined as the Dubbo service interface information; The scanned Dubbo service interface information is stored in the Dubbo service interface cache.

6. The service calling method based on Java reflection and dynamic proxy according to claim 5 is characterized in that: The Dubbo service interface cache uses ConcurrentHashMap.

7. The service calling method based on Java reflection and dynamic proxy according to claim 1 is characterized in that: The method further comprises: Monitor whether the duration of the connection between the Consumer and the Provider exceeds a connection duration threshold, and / or monitor whether the duration of the reception of the HTTP response body by the Consumer exceeds a request duration threshold; If yes, determining that the remote procedure call request has failed, and updating the current number of retries corresponding to the remote procedure call request; If the current number of retries exceeds the retry number threshold, an error prompt is generated for the remote procedure call request.

8. A service calling system based on Java reflection and dynamic proxy, characterized in that: The service call system includes a Consumer end and a Provider end, wherein both the Consumer end and the Provider end are integrated with a proxy component, wherein the proxy component integrated in the Consumer end is used to create an HTTP proxy class instance using Java dynamic proxy technology, and the proxy component integrated in the Provider end is used to automatically create a Controller interface and scan Dubbo service interface information; wherein, The Consumer end is used to: receive the remote procedure call request sent by the original caller, generate an HTTP request based on the target HTTP proxy class instance of the Dubbo service to be called corresponding to the remote procedure call request, and send the HTTP request to the Provider end; The Provider end is used to: receive the HTTP request through the Controller interface, determine the target Dubbo service interface information corresponding to the HTTP request from the Dubbo service interface cache, use JAVA reflection to implement the function corresponding to the to-be-called Dubbo service based on the target Dubbo service interface information, so as to generate an HTTP response body, and feed the HTTP response body back to the Consumer end; The Consumer end is further used to convert the HTTP response body into a specified data type, and feed back the HTTP response body of the specified data type to the original caller.

9. An electronic device, characterized in that: The method comprises a processor and a memory, wherein the memory stores computer executable instructions that can be executed by the processor, and the processor executes the computer executable instructions to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are called and executed by a processor, the computer-executable instructions prompt the processor to implement the method according to any one of claims 1 to 7.

Images