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

Abstract

The present invention provides a service invocation method, system, and device based on Java reflection and dynamic proxy. The method comprises: a consumer generates an HTTP request based on the target HTTP proxy class instance of the to-be-invoked Dubbo service corresponding to the remote procedure call request; a provider receives the HTTP request, determines the target Dubbo service interface information corresponding to the HTTP request, and uses Java reflection to implement the corresponding functionality of the to-be-invoked Dubbo service based on the target Dubbo service interface information, thereby generating an HTTP response body and feeding the HTTP response body back to the consumer. This method not only maintains the consistency and ease of use of the service interface, but also significantly reduces dependence on the registry center. It also easily removes the Dubbo framework, allowing full reliance on the HTTP protocol for inter-service communication.

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 widespread application of microservice architectures, the 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 the Dubbo framework are becoming increasingly significant, especially its limitations in cross-language integration and reliance on registry centers.

[0003] Cross-language integration is a critical requirement in modern microservices architectures. Because different programming languages ​​have their own strengths and applicable scenarios, enterprises often desire the flexibility to use multiple languages ​​to build services within a microservices architecture. However, the Dubbo framework is primarily Java-based, which limits its ability to directly integrate with services written in non-Java languages. To overcome this obstacle, additional middleware or protocol conversion layers are often required, which undoubtedly increases system complexity and maintenance costs.

[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 also faces challenges in stability and scalability. As the core component for service registration and discovery, the stability and performance of the registry center directly impact the operational efficiency of the entire microservice system. A registry center failure directly disrupts inter-service communication, posing a serious threat to system stability and availability. Furthermore, maintaining and managing the registry center requires significant resources and costs, further increasing the system's operational 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 significantly reduces the dependence on the registration center, and can easily remove the Dubbo framework and rely entirely on the HTTP protocol for inter-service communication.

[0006] In a first aspect, the present invention provides a service call method based on Java reflection and dynamic proxy, which is applied to a service call system. The service call system includes a Consumer side and a Provider side. Both the Consumer side and the Provider side are integrated with proxy components. The proxy component integrated in the Consumer side is used to create an HTTP proxy class instance using Java dynamic proxy technology. The proxy component integrated in the Provider side 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 HTTP requests 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 returns the HTTP response body of the specified data type to the original caller.

[0010] In one embodiment, before creating a target HTTP proxy class instance of the Dubbo service to be called based on 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 on 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. The call information includes call parameters and call method name.

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

[0017] If the HTTP proxy function is configured in the provider's configuration file, or if the HTTP proxy function is annotated in the Spring Boot startup class on the provider, make sure that the HTTP proxy function is enabled on the 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 side. 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 embodiment, 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 duration threshold, and / or monitor whether the time it takes for the Consumer to receive the HTTP response body exceeds the request duration threshold;

[0025] 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;

[0026] If the current retry count 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 call system based on Java reflection and dynamic proxy, the service call 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 the HTTP response body of the specified data type back 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, it 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 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 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 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, enhancing 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 inter-service communication can rely entirely on the HTTP protocol, thereby further simplifying the system architecture, reducing operation and maintenance complexity, 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 in part will become apparent from the description, or understood by practicing the present invention. The purposes 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 listed 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 embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0037] Figure 1 A flowchart of a service invocation 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 invocation 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 call system based on Java reflection and dynamic proxy provided by an embodiment of the present invention;

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

[0041] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0042] During the evolution of microservice architecture, the Dubbo framework, a highly regarded high-performance RPC solution in the Java community, has provided strong support for efficient communication between microservices. However, with the widespread adoption of microservice architecture and the rapid growth in the number of services, the registry mechanism that the Dubbo framework relies on has gradually exposed a series of stability and scalability bottlenecks. Furthermore, some of its inherent flaws have become particularly prominent in the current technological landscape. The following are the main manifestations of the flaws in 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 system's single point failure risk 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. However, this feature also brings limitations in terms of language integration. With the increasing popularity of multi-language microservice architectures, Dubbo's focus on Java services limits its ability to directly integrate with services written in non-Java languages. This means that when a 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 maintenance costs: As the number of services increases, the deployment and maintenance complexity of the Dubbo framework also increases. This includes the configuration and management of multiple components such as the registration center and monitoring center, which increases the workload and maintenance costs for operators. Furthermore, the highly complex system architecture increases the difficulty of system maintenance and troubleshooting.

[0046] 4. Performance bottlenecks: The Dubbo framework may face performance bottlenecks in high-concurrency scenarios. Although Dubbo itself provides high-performance RPC communication capabilities, the performance and stability of the registry center may become key factors restricting the performance of the entire system. In addition, when handling large-scale service calls, the Dubbo framework may require more efficient load balancing and fault tolerance mechanisms to address potential performance issues.

[0047] 5. High resource requirements: As the number of microservice instances continues to increase, each service instance needs to register with the registry and maintain a heartbeat, which significantly increases the server's CPU (Central Processing Unit) and memory burden. Furthermore, RPC calls between services and data synchronization operations with the registry consume significant network bandwidth. This bandwidth pressure is particularly pronounced in scenarios where services are widely distributed and frequently called. This surge in resource usage not only increases system operation and maintenance costs but can also limit further system expansion due to resource bottlenecks, increasing the complexity and maintenance difficulty of the system architecture.

[0048] 6. Insufficient flexibility: With the continuous development of technology and changes in business needs, microservice architectures must maintain a high degree of flexibility and adaptability. However, the traditional Dubbo framework is somewhat rigid, making it difficult to quickly adapt to new technologies and changing business models. When it comes to rapidly migrating technology stacks or optimizing system performance, the Dubbo framework's dependencies and limitations can become obstacles.

[0049] To address these pain points, particularly given resource constraints and the need for cross-language integration, the present invention provides a service invocation method, system, and device based on Java reflection and dynamic proxy. Leveraging Java reflection and dynamic proxy technology, these methods seamlessly convert RPC invocation requests, which rely on a registry, into HTTP (Hypertext Transfer Protocol) requests in real time. This conversion mechanism not only maintains the consistency and ease of use of the service interface, but also significantly reduces reliance on the registry, enhancing the system's independence and stability.

[0050] More importantly, by converting requests to HTTP, this solution greatly facilitates cross-language integration. As a universal protocol on the Internet, HTTP offers broad compatibility and optimization support. Services written in different languages ​​can communicate via HTTP without having to worry about language barriers. Therefore, in specific scenarios, such as technology stack migration, cost optimization, or environmental constraints, the system can easily remove the Dubbo framework and rely entirely on HTTP for inter-service communication, further simplifying the system architecture, reducing operational complexity, and improving system flexibility and scalability.

[0051] In summary, the embodiments of this invention not only effectively complement and enhance the Dubbo framework but also provide an innovative communication solution that replaces the Dubbo framework for cross-language integration and specific demand scenarios. By reducing reliance on the registry and introducing the HTTP communication mechanism, they provide strong support for the flexible deployment, efficient expansion, and reliable operation of microservice architectures.

[0052] To facilitate understanding of this embodiment, we first introduce in detail a service call method based on Java reflection and dynamic proxy disclosed in an embodiment of the present invention. 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 and Provider ends 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 side 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 side.

[0054] Among them, the remote procedure call (RPC) request is used to instruct the Consumer side 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 pre-create corresponding HTTP proxy class instances for multiple Dubbo services and register them with the Spring container. When the Consumer receives an RPC request from the original caller, it searches the Spring container for the target HTTP proxy class instance corresponding to the Dubbo service to be called. If so, it uses the target HTTP proxy class instance to generate the corresponding HTTP request, seamlessly converting the Dubbo service's RPC request into an HTTP request and sending the HTTP request to the Provider.

[0056] In step S104, the Provider side 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 side.

[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] In step S106 , the Consumer 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 Java reflection and dynamic proxy-based service invocation method in this embodiment cleverly combines the advantages of Java reflection and dynamic proxy technologies to fundamentally optimize the service communication mechanism in a microservices architecture. Its core goal is to dynamically remove the deep dependence on the Dubbo framework and its external registry, thereby significantly improving system stability, availability, and communication flexibility.

[0062] Specifically, the embodiment of the present invention converts the communication protocol between services in real time, from traditional RPC calls to lightweight communication based on HTTP, thereby reducing the risk of service interruption due to registration center failure and enhancing the system's self-recovery and fault tolerance. At the same time, this transformation also greatly simplifies the deployment and operation and maintenance processes, reduces dependence on external components, and thus improves 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 architectural 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 to 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 invocation method based on Java reflection and dynamic proxy shown in the figure 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 invocation, request processing, and response processing, among other key steps. The embodiment of the present invention provides a detailed description of each key step:

[0064] (1) Component integration:

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

[0066] (2) 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 Provider's configuration file contains a configuration item for the HTTP proxy function, then the Provider must enable the HTTP proxy function. In the specific implementation, in the configuration file (such as application.properties or application.yml), set the HTTP proxy function configuration item http.proxy.dubbo.enable = true to explicitly enable the HTTP proxy function of the Dubbo service.

[0070] Method 2, annotation method: If the Spring Boot startup class on the provider side has an annotation that enables the HTTP proxy feature, the provider side will be enabled for the HTTP proxy feature. To implement this, add the @EnableHttpProxyDubbo annotation to the Spring Boot startup class to programmatically enable the HTTP proxy feature. The @EnableHttpProxyDubbo annotation also enables the HTTP proxy feature.

[0071] (2.2) Service Scan:

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

[0073] In one embodiment, 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 with 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.

[0074] Specifically, when a Spring Boot application starts, the proxy component automatically triggers a service scan. This scan traverses all classes defined in the application, searching for interfaces annotated with the @Service annotation for Dubbo services. The identified Dubbo service interfaces are stored in a ConcurrentHashMap. Due to its high concurrency, ConcurrentHashMap ensures fast access and updates to cached data in a multi-threaded environment, further improving system responsiveness and stability.

[0075] (2.3) Service exposure:

[0076] The proxy component automatically creates a Controller interface to receive HTTP requests from the Consumer side. 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] (3) 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, in the configuration file, specify the provider service interface information to be proxied, 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}: The 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 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 embodiment, 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 Java dynamic proxy technology is used to create an HTTP proxy class instance for each Bean class instance.

[0095] Specifically, for each Dubbo service to be proxied, the proxy component implements 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 does not directly call the Dubbo service method, but instead initiates an HTTP request to the corresponding Controller interface on the Provider side.

[0096] (3.3) Register HTTP proxy:

[0097] In one embodiment, 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 is registered with the Spring container and marked as Primary to ensure it takes priority during autowiring. This way, when the Dubbo service is injected and used on the Consumer side, the HTTP proxy class instance is actually injected. The HTTP proxy class instance converts RPC requests to the Dubbo service into HTTP requests and sends them to the Provider side.

[0099] Through the above process, RPC calls of the Dubbo service are seamlessly converted into HTTP requests, allowing the Consumer and Provider to communicate directly through the HTTP protocol. This conversion process does not require extensive modifications to the original service code, greatly improving the flexibility and interoperability of the microservice architecture. At the same time, this transformation also greatly facilitates 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 via HTTP. The specific content is 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. 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 function 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 side, 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 side.

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

[0114] The Consumer converts the HTTP response body to the specified data type and returns the HTTP response body of the specified data type 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 connecting to the Provider exceeds a connection duration threshold, and / or monitor whether the duration of the Consumer receiving the HTTP response body exceeds a request duration threshold. In one example, the aforementioned connection timeout may be used as the connection duration threshold to determine whether a connection timeout has occurred; and the aforementioned request timeout may be used as the request duration threshold to determine whether a request timeout has occurred.

[0118] (II) If yes, the remote procedure call request is determined to have failed, and the current retry count corresponding to the remote procedure call request is updated. In one example, if a connection timeout or request timeout occurs, 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 threshold, an error message 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 threshold. If the new current number of retries exceeds the retry threshold, an error message is generated.

[0120] The embodiment of the present invention not only achieves 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, requiring reduced dependence on the RPC framework or a complete switch to an HTTP-based communication mode, this solution does not require extensive 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 optionality for the long-term development of the microservice architecture. The detailed description is as follows:

[0121] 1. Enhanced system stability and fault tolerance: By reducing reliance on the registry, the system can maintain smooth communication between services in the event of a registry failure, preventing a single point of failure from causing a complete system crash. This mechanism significantly improves system stability and fault tolerance, ensuring business continuity and availability.

[0122] 2. Reduced deployment and operation and maintenance costs: Since there is no longer a need to maintain a complex registry 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 universal protocol on the internet, boasts extensive optimization support and rich network infrastructure. By converting RPC calls to HTTP requests, it's easier to leverage existing load balancing, caching, and acceleration mechanisms to improve system performance. Furthermore, HTTP requests typically utilize lower resource usage than RPC calls, helping maintain stable system operation in high-concurrency scenarios.

[0124] 4. Optimize resource usage: Reducing reliance on the registry and the use of RPC calls can significantly reduce server CPU, memory, and network bandwidth consumption. This resource optimization not only helps reduce system operation and maintenance costs but also provides greater room for further system expansion. This optimization is particularly important in resource-constrained environments.

[0125] 5. Maintaining consistency and ease of use of service interfaces: This solution cleverly maintains the consistency and ease of use of the original service interfaces of the Dubbo framework, meaning developers can easily migrate services to the new communication mechanism without changing the existing code structure. This smooth migration reduces the difficulty and cost of technology upgrades and protects developers' investments.

[0126] 6. Improved system flexibility and scalability: By introducing dynamic proxies and reflection mechanisms, this solution makes inter-service communication more flexible and scalable. Developers can dynamically adjust communication protocols and transmission methods as needed. In specific scenarios, this solution can even remove the Dubbo framework to adapt to different business scenarios and performance requirements. This flexibility provides more possibilities for future system development.

[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 the Consumer end 302 and the Provider end 304 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. The proxy component integrated in the Provider end 304 is used to automatically create a Controller interface and scan Dubbo service interface information.

[0129] The Consumer side 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 side 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 to-be-called Dubbo service based on the target Dubbo service interface information, 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 an embodiment of the present invention 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 inter-service communication can be completely dependent on the HTTP protocol, 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 creating a target HTTP proxy class instance of the Dubbo service to be called based on the remote procedure call request, the method further includes:

[0134] Through the proxy component integrated in the Consumer end 302, multiple Dubbo service Bean class instances registered in the Spring container of the Consumer end 302 are loaded, and an HTTP proxy class instance is created for each Bean class instance using 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. The call information includes call parameters and call method name.

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

[0140] If the configuration item of the HTTP proxy function is set in the configuration file of the provider end 304, or if the HTTP proxy function annotation is added to the Spring Boot startup class of the provider end 304, then 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 with 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 embodiment, 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 retry count corresponding to the remote procedure call request is updated;

[0149] If the current retry count 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 in the aforementioned method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference can be made to the corresponding content 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 embodiments.

[0152] Figure 4This is a 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. 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 high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage. The system network element communicates with at least one other network element via at least one communication interface 43 (which may be wired or wireless), and may utilize the Internet, a wide area network, a local area network, a metropolitan area network, or the like.

[0154] The bus 42 may be an ISA bus, a PCI bus, or an EISA bus. The bus may be divided into an address bus, a data bus, a control bus, and the like. 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 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] Processor 40 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method may be completed by hardware integrated logic circuits or software instructions in processor 40. The above processor 40 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may 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 gate or transistor logic devices, or discrete hardware components. It may implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in conjunction with the embodiments of the present invention may be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or the like. 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. The instructions included in the program code can be used to execute the method described in the previous method embodiment. The specific implementation can be referred to the previous method embodiment and 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 and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0159] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the above-described embodiments, those skilled in the art should understand that any person skilled in the art can modify or easily conceive of changes to the technical solutions described in the above-described embodiments within the technical scope disclosed by the present invention, or replace some of the technical features therein with equivalents. Such modifications, changes, or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection 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 call system, which includes a Consumer side and a Provider side. Both the Consumer side and the Provider side are integrated with a proxy component. The proxy component integrated in the Consumer side is used to create an HTTP proxy class instance using Java dynamic proxy technology, and the proxy component integrated in the Provider side is used to automatically create a Controller interface and scan Dubbo service interface information. The method includes: The Consumer side 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 side. The 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 call parameters and call method name; 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, uses Java reflection to implement the function corresponding to the to-be-called Dubbo service based on the target Dubbo service interface information, 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; 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 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 of the Bean class instances, 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, and the integration of the Java reflection and the Java dynamic proxy technology is used to dynamically remove the deep dependence on the Dubbo framework and its external registration center.

2. The service calling method based on Java reflection and dynamic proxy according to claim 1, 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.

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

4. The service calling method based on Java reflection and dynamic proxy according to claim 1, 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 with the @Service annotation of the Dubbo service is determined as the Dubbo service interface information; The Dubbo service interface information obtained by scanning is stored in the Dubbo service interface cache.

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

6. The service calling method based on Java reflection and dynamic proxy according to claim 1, 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 by the Consumer exceeds a request duration threshold; If yes, determining that the remote procedure call request has failed, and updating the current retry count corresponding to the remote procedure call request; If the current number of retries exceeds a retry number threshold, an error prompt is generated for the remote procedure call request.

7. A service calling system based on Java reflection and dynamic proxy, characterized in that: Used to implement the service call method based on Java reflection and dynamic proxy as described in claim 1, the service call system includes a Consumer end and a Provider end, and 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; wherein, 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; The Provider 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, generate an HTTP response body, and feed the HTTP response body back to the Consumer; The Consumer end is further configured 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.

8. 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 6.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium 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 the method according to any one of claims 1 to 6.

Images