A method and apparatus for implementing a declarative HTTP client supporting dynamic routing

Abstract

The application discloses a kind of declarative HTTP client implementation method and device supporting dynamic routing, belong to distributed service communication technical field.The method mainly includes: generating interface metadata set by scanning declarative interface annotation, and creating dynamic proxy object based on the set;Abstract HTTP request template is constructed by using proxy object to parse URL template, request parameter and request body;Abstract service name is replaced by specific instance address by combining routing strategy and service instance information, to form complete HTTP request;The asynchronous sending and responsive receiving of request are integrated by non-blocking HTTP client implementation;Finally, service fuse protection is realized by combining retry strategy and circuit breaker through exception capture mechanism.The application effectively improves the development efficiency of HTTP call between microservices, routing flexibility and system fault tolerance by the fusion of declarative programming model and dynamic routing mechanism.

Description

Technical Field

[0001] This invention relates to the field of computer technology, specifically to a declarative HTTP client implementation method and system that supports dynamic routing, particularly suitable for inter-service communication in microservices and cloud-native architectures. Background Technology

[0002] With the widespread adoption of microservices and cloud-native architectures, HTTP communication between services has become a core infrastructure of distributed systems. Modern distributed applications require efficient, flexible, and reliable HTTP clients to handle remote calls between services in order to decompose and integrate business functions.

[0003] Traditional HTTP client technologies mainly include programmatic clients and simple declarative clients. Programmatic clients (such as Apache HttpClient, OkHttp, etc.) require developers to manually write code for request construction, parameter setting, and response processing; while simple declarative clients (such as Spring Cloud OpenFeign) simplify interface definition, their underlying implementation usually still relies on a synchronous blocking model and has limited routing capabilities.

[0004] The closest existing technical solution is an implementation that combines declarative interfaces with client-side load balancing. This approach allows developers to define HTTP requests using annotations and perform simple load balancing using service discovery components. However, such solutions typically suffer from fixed routing strategies that cannot be dynamically adjusted based on request context; furthermore, due to the use of a synchronous blocking communication model, thread resource exhaustion and performance bottlenecks are prone to occur in high-concurrency scenarios.

[0005] Existing technologies suffer from three main drawbacks: low development efficiency (requiring extensive use of template code), rigid routing mechanisms (inability to perform intelligent scheduling based on real-time context), and limited performance (synchronous blocking models lead to resource waste and insufficient concurrency). In particular, these three dimensions are treated in isolation, often forcing developers to make difficult trade-offs and preventing them from simultaneously achieving a good development experience, flexible routing strategies, and high-performance execution capabilities. Summary of the Invention

[0006] The purpose of this invention is to provide a declarative HTTP client implementation method and system that supports dynamic routing, aiming to solve the problems of low development efficiency, rigid routing mechanism and limited performance in the prior art, and to achieve the organic integration of declarative programming model, dynamic routing mechanism and reactive execution capability.

[0007] To achieve the above objectives, the technical solution provided by the present invention is as follows:

[0008] A declarative HTTP client implementation method that supports dynamic routing includes the following steps:

[0009] Based on declarative interface definition information, interfaces with reactive HTTP client annotations are identified, and the identified interface information and method annotations are recorded to form an interface metadata set.

[0010] Based on the interface metadata set, a proxy implementation class factory for the corresponding interface is created, and a dynamic proxy object instance is generated by calling the proxy implementation class factory.

[0011] The URL path template is extracted using the dynamic proxy object instance. The path variables and query parameters in the URL path template are replaced according to the path variable annotation and request parameter annotation. The request header annotation and request body annotation are parsed, and the HTTP request header and request body are set. Based on the URL path template obtained after replacement, the request header and the request body, an abstract HTTP request template is generated.

[0012] Based on the abstract HTTP request template, a pre-determined routing strategy and optimal service instance are invoked, the abstract service name is replaced with the specific instance address, and a complete HTTP request is generated.

[0013] The complete HTTP request is transformed using a non-blocking HTTP client, and the target HTTP request is output. The asynchronous sending and receiving of the target HTTP request and the generation of a reactive return value are achieved through a reactive processing pipeline.

[0014] The system captures raw exceptions generated during the underlying communication process. Based on these raw exceptions, it implements a retry mechanism with a backoff algorithm using reactive operators and monitors the exception frequency through a circuit breaker to circuit breakers for frequently failing service calls.

[0015] Optionally, based on declarative interface definition information, interfaces with reactive HTTP client annotations are identified, and the identified interface information and method annotations are recorded to form an interface metadata set, including:

[0016] Based on the interface with reactive HTTP client annotations, client-level annotations and method-level annotations are defined, and annotation specifications are established based on the client-level annotations and method-level annotations;

[0017] When the application starts, the annotation specification is scanned to identify interfaces with reactive HTTP client annotations, and the identified interface information and method annotations are recorded to form an interface metadata set.

[0018] Optionally, the step of creating a proxy implementation class factory for the corresponding interface based on the interface metadata set, and generating a dynamic proxy object instance by calling the proxy implementation class factory, includes:

[0019] Based on the interface metadata set, a factory of proxy implementation classes for the corresponding interface is created using JDK dynamic proxy technology or code generation library technology.

[0020] The proxy implementation class factory generates a dynamic proxy object instance for each declarative interface and registers the dynamic proxy object instance to the IoC container.

[0021] Optionally, the step of extracting a URL path template through the dynamic proxy object instance, replacing path variables and query parameters in the URL path template according to path variable annotations and request parameter annotations, parsing request header annotations and request body annotations, setting HTTP request headers and request bodies, and generating an abstract HTTP request template based on the replaced URL path template, the request headers, and the request body, includes:

[0022] By intercepting interface method calls through the dynamic proxy object instance, the method signature, annotation information and actual call parameters are obtained. Based on the method signature and the annotation information, the HTTP request mapping annotation is identified and parsed to extract the URL path template.

[0023] Based on the path variable annotation and request parameter annotation, the actual call parameters replace the path variables and query parameters in the URL path template, and the request header annotation and request body annotation are parsed to set the HTTP request header and request body;

[0024] An abstract HTTP request template is generated based on the URL path template obtained after replacement, the request header, and the request body.

[0025] Optionally, the step of invoking a pre-determined routing strategy and optimal service instance based on the abstract HTTP request template, replacing the abstract service name with the specific instance address, and generating a complete HTTP request includes:

[0026] Based on the abstract HTTP request template, the service instance list and its metadata can be obtained in real time by integrating the service registry client;

[0027] Implement a routing selector interface based on the aforementioned metadata, construct a basic load balancing algorithm, then call the routing selector interface and the load balancing algorithm, and combine them with the service instance list to select the optimal service instance;

[0028] Replace the abstract service name of the optimal service instance with the specific instance address to generate a complete HTTP request.

[0029] Optionally, the step of transforming the complete HTTP request using a non-blocking HTTP client, outputting a target HTTP request, and asynchronously sending and receiving the target HTTP request and generating a reactive return value through a reactive processing pipeline includes:

[0030] The complete HTTP request is transformed using a non-blocking HTTP client to generate a transformed request object;

[0031] Through a reactive processing pipeline, based on the transformed request object, the asynchronous sending and receiving of the target HTTP request is realized, and an HTTP response is obtained;

[0032] Based on the return type information of the interface method, the HTTP response is deserialized and type-converted to generate a reactive return value.

[0033] Optionally, the process of capturing raw exceptions generated during underlying communication, implementing a retry mechanism with a backoff algorithm based on these raw exceptions using reactive operators, and monitoring the exception frequency through a circuit breaker to circuit break frequently failing service calls includes:

[0034] Capture raw exceptions generated during underlying communication and convert them into standard exceptions to generate a unified exception object;

[0035] Based on the exception information of the unified exception object, it is determined whether the retry conditions are met. If they are met, a retry request is initiated based on the reactive operator provided by the non-blocking HTTP client. When the number of retries reaches the upper limit, the final exception is output. Furthermore, the exception frequency is monitored through a circuit breaker, and service calls that fail frequently are circuit-broken.

[0036] Optionally, the step of invoking the route selector interface and the load balancing algorithm, and selecting the optimal service instance in conjunction with the service instance list, includes:

[0037] Based on the service instance list and the metadata, the route selector interface is called to obtain a set of candidate instances filtered based on the request content, instance metadata, or custom rules.

[0038] The load balancing algorithm is invoked to perform an instance selection operation on the service instances in the candidate instance set, and the optimal service instance is selected. The load balancing algorithm includes at least one of the round-robin algorithm, random algorithm, and least connection algorithm.

[0039] Optionally, after monitoring the abnormal frequency through the circuit breaker and circuit breaking the circuit for frequently failing service calls, the method further includes:

[0040] Define the standard interfaces and data transfer objects between the declarative interface proxy module, request parser and constructor, dynamic routing module, reactive execution engine and exception handling module, and generate a module integration framework;

[0041] Based on the module integration framework, client configuration parameters are dynamically loaded from an external configuration center. Monitoring data, including request success rate, response time, and concurrency data, are collected through an observability framework. Plugin interfaces for extending request interceptors, routing strategies, and response processors are also configured.

[0042] The module integration framework, client configuration parameters, monitoring data, and plugin interface are integrated into a system to obtain an executable HTTP client instance.

[0043] Optionally, the method further includes:

[0044] A multi-objective optimization model for service routing is constructed. The multi-objective optimization model includes objective functions for minimizing instance response time, maximizing load balancing, and minimizing network resource consumption, and introduces constraints such as service instance health status, regional affinity requirements, and specific label matching rules.

[0045] The multi-objective optimization model is decomposed into multiple sub-problems using the proximal splitting algorithm. The consistency of the solutions to each sub-problem is maintained by the proximal terms, and the alternating direction multiplier method is used to iteratively solve each sub-problem.

[0046] Using a Monte Carlo sampling-based stochastic exploration method, multiple candidate routing schemes are randomly generated in each iteration. A comprehensive score is calculated for each candidate routing scheme, and the next exploration direction is selected probabilistically based on the score.

[0047] Optionally, the application of the proximal splitting algorithm decomposes the multi-objective optimization model into multiple sub-problems, including:

[0048] The multi-objective optimization problem is transformed into a subproblem that can be solved in parallel using Lagrange dual decomposition, and each subproblem corresponds to a local optimization of an objective function;

[0049] In each iteration, the Lagrange multipliers are updated, and the coordination parameters between the subproblems are adjusted by the gradient ascent method to ensure that the solutions to the subproblems converge toward the global optimum.

[0050] Set convergence criteria. When the change in the objective function value during continuous iteration is less than a preset threshold or the maximum number of iterations is reached, terminate the iteration and output the current optimal service instance selection scheme.

[0051] Optionally, the method further includes:

[0052] Establish a set-value mapping model to map each service instance to its set of performance metric vectors, define a set of mapping functions, where each function represents an evaluation metric, and introduce uncertainty to represent the possible range of each instance mapping to the metric.

[0053] Using the trust region algorithm framework, a trust region is defined around the current optimal solution to limit the search range of each iteration. An approximate model is constructed to predict the objective function value of each point within the trust region. An adaptive step size mechanism is designed to dynamically adjust the size of the trust region according to the difference between the predicted value and the actual value.

[0054] For each candidate service instance, all objective functions are evaluated in parallel to identify the non-dominated solution set using the Pareto optimization criterion, and a weighted comprehensive score is calculated based on the weights of each objective function configured according to the business scenario.

[0055] The present invention also provides a declarative HTTP client implementation apparatus that supports dynamic routing, comprising:

[0056] The metadata generation module is used to identify interfaces with reactive HTTP client annotations based on declarative interface definition information, and record the identified interface information and method annotations to form an interface metadata set.

[0057] The proxy object instance generation module is used to create a proxy implementation class factory for the corresponding interface based on the interface metadata set, and generate a dynamic proxy object instance by calling the proxy implementation class factory;

[0058] The request generation module is used to extract the URL path template through the dynamic proxy object instance, replace the path variables and query parameters in the URL path template according to the path variable annotation and the request parameter annotation, parse the request header annotation and the request body annotation, set the HTTP request header and the request body, and generate an abstract HTTP request template based on the URL path template obtained after replacement, the request header and the request body.

[0059] The HTTP request generation module is used to generate a complete HTTP request by calling a pre-determined routing strategy and optimal service instance based on the abstract HTTP request template, replacing the abstract service name with the specific instance address;

[0060] The reactive return value generation module is used to transform the complete HTTP request through a non-blocking HTTP client, output the target HTTP request, realize the asynchronous sending and response reception of the target HTTP request through a reactive processing pipeline, and generate a reactive return value.

[0061] The circuit breaker module is used to capture the original exceptions generated during the underlying communication process. Based on the original exceptions, a retry mechanism with a backoff algorithm is implemented using reactive operators. The circuit breaker monitors the exception frequency and circuit breaks the service calls that fail frequently.

[0062] Compared with the prior art, the beneficial effects of the present invention are:

[0063] 1. Significantly improves development efficiency and code maintainability: Through the declarative interface programming model, developers only need to define a Java interface and add annotations to complete the definition of an HTTP request, without having to write any specific implementation code for request construction, sending, and response processing, thus eliminating a large amount of repetitive template code.

[0064] 2. Achieve intelligent and refined traffic scheduling: Through an extensible dynamic routing module, it realizes routing decisions based on real-time context (such as request content, service instance metadata, and health status), supports advanced release strategies such as canary releases, blue-green deployments, and A / B testing, and can perceive the health status of instances in real time and automatically shield faulty instances.

[0065] 3. Significantly improve system throughput and reduce resource consumption: Through the reactive execution engine and its underlying asynchronous non-blocking I / O model, a large number of concurrent network connections can be handled with very few threads, avoiding problems such as thread resource exhaustion and high context switching overhead caused by the synchronous blocking model of "one request, one thread". Attached Figure Description

[0066] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the described drawings are only a part of the embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0067] Figure 1 A flowchart illustrating a declarative HTTP client implementation method supporting dynamic routing provided in an embodiment of the present invention;

[0068] Figure 2 This is a structural block diagram of a declarative HTTP client implementation device that supports dynamic routing, provided in an embodiment of the present invention. Detailed Implementation

[0069] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0070] The implementation of the present invention will be described in detail below with reference to specific embodiments.

[0071] like Figure 1 As shown, this embodiment of the invention provides a declarative HTTP client implementation method that supports dynamic routing, including the following steps:

[0072] Step S1: Based on the declarative interface definition information, identify interfaces with reactive HTTP client annotations, and record the identified interface information and method annotations to form an interface metadata set.

[0073] Step S1 is the foundation and starting point of the entire declarative HTTP client framework. This step is essentially a metadata collection process. The system scans and parses the annotation information on the Java interface to build a complete metadata repository, providing the necessary information support for subsequent dynamic proxy generation and request processing.

[0074] In some embodiments, step S1 may specifically include the following steps: defining client-level annotations and method-level annotations based on interfaces with reactive HTTP client annotations, establishing annotation specifications based on the client-level annotations and method-level annotations; scanning the annotation specifications when the application starts, identifying interfaces with reactive HTTP client annotations, and recording the identified interface information and method annotations to form an interface metadata set.

[0075] Design a complete annotation system, including client-level annotations (@ReactiveHttpClient) and method-level annotations (@GetMapping, @PostMapping, etc.), supporting declarations of URLs, HTTP methods, request parameters, etc. When the application starts, scans interfaces annotated with @ReactiveHttpClient, records the information of these interfaces and various annotations on their methods, forming a complete metadata set to provide necessary information for subsequent dynamic proxy creation.

[0076] Specifically, this invention designs a complete annotation system, including two levels of annotation types. At the client level, the `@ReactiveHttpClient` annotation is defined to mark an interface as a reactive HTTP client interface. This annotation typically includes global configuration information such as the service name (name attribute) and the request base path (baseUrl attribute). At the method level, a series of annotations corresponding to HTTP methods are defined, such as `@GetMapping`, `@PostMapping`, `@PutMapping`, and `@DeleteMapping`. These annotations are used to declare the HTTP request method and path template corresponding to the interface method. Furthermore, parameter-level annotations such as `@PathVariable`, `@RequestParam`, `@RequestHeader`, and `@RequestBody` are supported to refine the processing of request parameters.

[0077] When the application starts, the system actively scans all interface classes annotated with `@ReactiveHttpClient`. This scanning process is typically implemented using the Spring framework's component scanning mechanism or a custom classpath scanner. For each identified interface, the system further parses all its methods and their annotations. The system records the fully qualified class name, package name, the content of the `@ReactiveHttpClient` annotation, and information about all methods declared in the interface. For each method, the system records the method name, return type (paying special attention to whether it is a reactive type such as Mono or Flux), method parameter list, and detailed configuration of HTTP request mapping annotations (such as `@GetMapping`) on the method.

[0078] Next, the system performs a deep analysis of the method parameters, identifying the annotation type (@PathVariable, @RequestParam, etc.) and configuration value of each parameter, and recording this information along with the parameter type and name in the metadata. This parameter-level metadata is crucial for the correct construction of subsequent HTTP requests; it determines how parameter values ​​are processed and integrated into the final request. For example, parameters annotated with @PathVariable will be used to replace the variable portion in the URL path template, while parameters annotated with @RequestParam will be converted into query parameters and appended to the URL.

[0079] The system also handles composition relationships at the method and interface levels, such as how the baseUrl attribute on the interface is combined with the path template on the method to form a complete URL. In addition, the system analyzes and records other functional annotations that may exist on interfaces and methods, such as timeout configurations, retry strategies, and circuit breaker configurations. This metadata will affect the behavior of subsequent request execution.

[0080] Ultimately, all collected interface, method, and parameter-level metadata is integrated into a structured metadata set, typically organized by interface, containing complete request definition information. This metadata set is stored in system memory, serving as a crucial reference for subsequent creation of dynamic proxy objects and handling method calls. Essentially, it transforms the HTTP call intent expressed by developers through declarative interfaces into a set of instructions that the system can understand and execute, acting as a bridge between the declarative programming model and the actual execution logic.

[0081] The biggest advantage of this annotation-based metadata collection mechanism is that developers only need to define intuitive interfaces and configure annotations to complete the entire description of an HTTP request, without writing any implementation code. The system automatically handles the entire process of request construction, sending, and response parsing at runtime based on this metadata, greatly simplifying the development of inter-service communication and improving code readability and maintainability. This mechanism also lays the foundation for subsequent dynamic routing and reactive processing, enabling the entire client framework to provide powerful functionality while maintaining a concise interface.

[0082] Step S2: Based on the interface metadata set, create a proxy implementation class factory for the corresponding interface, and generate a dynamic proxy object instance by calling the proxy implementation class factory.

[0083] After obtaining the complete set of interface metadata, the next key step of this invention is to "create a proxy implementation class factory for the corresponding interface based on the interface metadata set, and generate a dynamic proxy object instance by calling the proxy implementation class factory." This step is the core link connecting declarative definitions and actual execution logic, and uses dynamic proxy technology to "transform" the developer-defined interface into an object instance with actual functionality.

[0084] In some embodiments, step S2 may specifically include: based on the interface metadata set, creating a proxy implementation class factory for the corresponding interface using JDK dynamic proxy technology or code generation library technology; generating a dynamic proxy object instance for each declarative interface through the proxy implementation class factory, and registering the dynamic proxy object instance in the IoC container.

[0085] Using the Java reflection API or a dedicated code generation library (such as Bytecode Buddy, ASM, etc.), a corresponding proxy implementation class factory is created for each declarative interface based on the metadata collected in step S1. Through the proxy implementation class factory, a proxy object for each interface is instantiated and registered in the IoC container of a dependency injection framework such as Spring, allowing business components to directly use these proxy objects via dependency injection.

[0086] Specifically, firstly, the system creates a corresponding proxy implementation class factory for each interface annotated with `@ReactiveHttpClient`. These factories are responsible for generating dynamic proxy objects that implement specific interfaces; they act as a bridge connecting the interface definition and the underlying HTTP communication logic. On the Java platform, this invention primarily employs two technical approaches to achieve this process: JDK dynamic proxies and bytecode-enhanced proxy technologies (such as CGLIB, ByteBuddy, or ASM). For pure interfaces without inheritance relationships, the system preferentially uses JDK dynamic proxy technology because it is a built-in JDK feature and requires no additional dependencies; while for scenarios that may contain abstract classes or require inheritance from specific classes, the system uses bytecode-enhanced proxy technologies.

[0087] When creating a proxy implementation class factory, the system passes the interface metadata collected in the previous step to the factory as a reference for generating proxy objects. Each factory instance holds all the metadata for the corresponding interface, including interface information, method signatures, annotation configurations, etc. This metadata plays a crucial role in the subsequent creation of proxy objects and handling of method calls, ensuring that the proxy object can accurately implement the functional semantics defined by the interface.

[0088] The creation process of the proxy implementation factory is a highly dynamic one. The system analyzes the characteristics of the interface based on its metadata (such as whether it contains special methods or has inheritance relationships) and selects the most suitable proxy implementation strategy. For complex interfaces, the system may generate dedicated intermediate classes to optimize the performance and functionality of the proxy implementation. It is worth noting that this creation process is usually completed during the application startup phase to avoid runtime redundant computation overhead.

[0089] Once the proxy implementation class factory is created, the system instantiates dynamic proxy objects for each interface through these factories. Specifically, for scenarios using JDK dynamic proxy technology, the system calls the `Proxy.newProxyInstance` method, passing in the interface's class loader, the interface class object, and a call handler that implements the `InvocationHandler` interface. This call handler is the core of the proxy object; it defines the logic the system should execute when an interface method is invoked. In this invention, the call handler typically includes complete processing logic for request parsing, parameter handling, routing decisions, HTTP communication, and response transformation.

[0090] For bytecode-enhanced proxy implementations, the system uses a code generation library to dynamically create subclasses that implement the target interface and inserts corresponding processing logic into the method implementations. Regardless of the technology used, the generated proxy object can respond to all method calls defined in the interface and execute the corresponding HTTP request processing according to the annotation configuration.

[0091] These generated dynamic proxy objects are then registered in the application's dependency injection container (such as the Spring IoC container). The registration process typically utilizes the container's programmatic registration API to register the proxy objects as singleton beans of the corresponding interface type. This allows business code to obtain references to these proxy objects using standard dependency injection methods (such as the `@Autowired` annotation), making it as simple and intuitive as using ordinary service components.

[0092] The ingenious aspect of dynamic proxy mechanisms lies in their decoupling of interfaces and implementations. Developers only need to define interfaces and annotations, without needing to concern themselves with the specific implementation details; the system then dynamically creates the implementation classes of these interfaces at runtime and injects complete HTTP communication processing logic. This approach greatly simplifies development, improves code maintainability, and provides flexibility for subsequent feature expansion. For example, the system can embed cross-cutting concerns such as performance monitoring, logging, and exception handling into the proxy object without modifying the business interface definition.

[0093] Overall, this step, through dynamic proxy technology, transforms declarative definitions into executable components, and is a crucial part of the entire declarative HTTP client framework. It not only hides the complex details of HTTP communication but also provides a unified programming model, enabling developers to implement remote service calls as easily as calling local methods, thereby significantly improving the development efficiency and code quality of distributed systems.

[0094] Step S3: Extract the URL path template using the dynamic proxy object instance, and replace the path variables and query parameters in the URL path template according to the path variable annotation and request parameter annotation. Also, parse the request header annotation and request body annotation, set the HTTP request header and request body, and generate an abstract HTTP request template based on the URL path template obtained after replacement, the request header and the request body.

[0095] After the dynamic proxy object instance is created, the core functionality of this invention begins to manifest in the precise construction of HTTP requests. The step of "extracting the URL path template through the dynamic proxy object instance, replacing the path variables and query parameters in the URL path template according to the path variable annotation and request parameter annotation, parsing the request header annotation and request body annotation, setting the HTTP request header and request body, and generating an abstract HTTP request template based on the replaced URL path template, the request header, and the request body" is essentially the process of precisely converting interface method calls into HTTP requests, achieving a complete mapping from method signatures and parameters to HTTP requests.

[0096] In some embodiments, step S3 may specifically include: intercepting interface method calls through the dynamic proxy object instance, obtaining method signatures, annotation information, and actual call parameters; identifying and parsing HTTP request mapping annotations based on the method signatures and annotation information to extract a URL path template; replacing path variables and query parameters in the URL path template with actual call parameters according to path variable annotations and request parameter annotations, and parsing request header annotations and request body annotations to set HTTP request headers and request bodies; generating an abstract HTTP request template based on the URL path template obtained after replacement, the request headers, and the request body.

[0097] When business code calls interface methods, the dynamic proxy intercepts these calls and extracts necessary information from the method signature, annotations, and parameters. It identifies HTTP request mapping annotations such as `@GetMapping` and `@PostMapping`, parses the annotation values ​​to extract the URL path template, and processes annotations like `@PathVariable` and `@RequestParam`, replacing variables and query parameters in the URL template with actual parameter values. Simultaneously, it parses annotations like `@RequestHeader` and `@RequestBody` to set the HTTP request headers and request body content. The processed URL, request headers, and request body are then integrated into a complete HTTP request template containing all necessary information, but without specifying the exact target service instance address.

[0098] Specifically, when business code calls an interface method (such as userService.getUser(123)), the dynamic proxy object intercepts this call. After interception, the proxy object first retrieves the relevant metadata of the currently called method from the interface metadata, including HTTP mapping annotations on the method (such as @GetMapping(" / api / user / {id}")), parameter annotation configurations, and return type information. From this metadata, the system first extracts the original URL path template. For compound URLs, the system merges the interface-level baseUrl configuration and the method-level path template to form a complete request path template. For example, if the @ReactiveHttpClient annotation is configured with baseUrl=" / api", and the method has @GetMapping(" / user / {id}"), then the final URL path template is " / api / user / {id}".

[0099] Next, the system analyzes the method parameters and their annotations, and performs corresponding parameter processing. For parameters annotated with `@PathVariable`, the system extracts their values ​​and replaces the corresponding placeholders in the URL path template. For example, replacing "{id}" in " / api / user / {id}" with the actual passed parameter value "123" results in " / api / user / 123". This process requires precise matching of parameter names and placeholder names, while handling possible type conversions to ensure that the replacement result conforms to URL specifications.

[0100] For parameters annotated with `@RequestParam`, the system converts them into URL query parameters and appends them to the path. For example, if the method signature is `getUser(@PathVariable("id") Long id, @RequestParam("detail") boolean detail)`, and the parameters passed in are `123` and `true`, the final URL will be like `" / api / user / 123 detail=true"`. The system supports automatic conversion of basic type parameters and can also handle query parameters of collection types (such as Lists), converting them into multi-value parameters or formatting them as JSON strings, depending on the configured serialization strategy.

[0101] In addition to the path and query parameters, the system also processes the HTTP request headers and request body. For parameters annotated with `@RequestHeader`, the system extracts their values ​​and adds them to the HTTP request header. These headers can be used to convey authentication information, content type indications, or custom metadata. The system supports both static request headers (configured directly via annotations) and dynamic request headers (passed in via method parameters) to meet the needs of different scenarios.

[0102] For parameters annotated with `@RequestBody`, the system serializes them into the request body. The serialization process typically relies on configured content converters (such as JSON converters, XML converters, etc.) to accurately convert complex Java object structures into their corresponding string or binary representations. Simultaneously, the system automatically sets the Content-Type request header to ensure matching with the serialization format. For special scenarios such as file uploads, the system also supports multipart / form-data encoding, enabling the handling of request bodies with mixed content types.

[0103] Through the above processing steps, the system integrates all information from the interface method call into an abstract HTTP request template. This template includes the request method (GET, POST, etc.), the processed URL path, the complete set of request headers, and a formatted request body (if any). It's important to note that this request template is still "abstract" at this point because it hasn't yet been bound to a specific target server address. The host portion of the URL is usually still a service name (e.g., "user-service"), which needs to be resolved to a specific service instance address in subsequent steps using service discovery and dynamic routing mechanisms.

[0104] This abstract HTTP request template design has several key advantages: First, it decouples request construction from target selection, enabling the system to select the optimal service instance based on real-time conditions at a later stage; second, it retains all the original information of the request, facilitating subsequent request logging, metric collection, or diagnostic analysis; and finally, this design also facilitates the implementation of request interceptor mechanisms, allowing for global or targeted modifications before the request is sent, such as adding unified authentication information, tracking IDs, or business tags.

[0105] Overall, this step, through precise parameter processing and information transformation, achieves a complete mapping from interface method calls to abstract HTTP requests, and is the core transformation link of the entire declarative HTTP client framework. It not only ensures the accuracy and completeness of request construction but also lays the foundation for subsequent dynamic routing and reactive execution.

[0106] Step S4: Based on the abstract HTTP request template, call the pre-determined routing strategy and optimal service instance, replace the abstract service name with the specific instance address, and generate a complete HTTP request.

[0107] After the abstract HTTP request template is constructed, the system needs to perform a crucial transformation step: "Based on the abstract HTTP request template, the system calls a pre-determined routing strategy and the optimal service instance, replacing the abstract service name with the specific instance address to generate a complete HTTP request." This step is the core implementation of service discovery and intelligent routing in a microservice architecture. It resolves the logical service name into an actual accessible physical address and comprehensively considers multiple factors to select the best service instance, ensuring that the request can reach the target service efficiently and reliably.

[0108] In some embodiments, step S4 may specifically include: based on the abstract HTTP request template, by integrating the service registry client, obtaining the service instance list and its metadata in real time; implementing a route selector interface based on the metadata, and constructing a basic load balancing algorithm, then calling the route selector interface and the load balancing algorithm, and combining the service instance list to select the optimal service instance; replacing the abstract service name of the optimal service instance with the specific instance address to generate a complete HTTP request.

[0109] Furthermore, the step of calling the routing selector interface and the load balancing algorithm, and selecting the optimal service instance in conjunction with the service instance list, may specifically include: based on the service instance list and the metadata, calling the routing selector interface to obtain a candidate instance set filtered based on request content, instance metadata, or custom rules; calling the load balancing algorithm to perform an instance selection operation on the service instances in the candidate instance set, and selecting and determining the optimal service instance, wherein the load balancing algorithm includes at least one of a round-robin algorithm, a random algorithm, and a least-connections algorithm.

[0110] Integrate with service registry clients (such as Nacos or Eureka clients) to obtain a list of all available instances of the target service, along with metadata information for each instance (such as health status and region tags). Based on the service instance list and metadata, call the route selector interface to obtain a set of candidate instances filtered based on the request content, instance metadata, or custom rules. Then, invoke a load balancing algorithm to perform an instance selection operation on the service instances in the candidate instance set, determining the optimal service instance. The load balancing algorithm includes at least one of round-robin, random, and least-connections algorithms. Replace the abstract service name in the request template with the specific address (IP:port) of the selected optimal service instance to form an HTTP request containing the complete target address.

[0111] In a microservices architecture, service instances are typically deployed and scaled dynamically, and their network addresses (IP addresses and ports) may change frequently. To shield service consumers from the impact of these changes, the system uses the "service name" as a logical identifier instead of directly using the physical address. In the abstract HTTP request template, the URL typically includes the service name instead of the actual IP address, such as "http: / / user-service / api / users / 123". This design allows service consumers to disregard the specific deployment location of the service provider, achieving transparency in service discovery and routing.

[0112] When an actual request needs to be sent, the system first retrieves a list of all available instances corresponding to the specified service name from the configuration or service registry. This process typically relies on service registration and discovery components such as Netflix Eureka, Consul, Nacos, or Kubernetes Service. The system periodically queries and caches service instance information from these components, including each instance's IP address, port number, health status, and metadata tags. In a high-availability design, the system employs a mechanism of local caching combined with periodic updates to ensure that service routing continues even if the service registry is temporarily unavailable.

[0113] After obtaining the list of available instances, the system will invoke pre-configured routing strategies to select the optimal instance. These routing strategies typically consider multiple factors:

[0114] First, there are basic load balancing strategies, such as Round Robin, Random, and Weighted Round Robin. These strategies ensure that requests are distributed across different instances, avoiding single-point overload. In particular, when considering instance weights, the system assigns different weights based on the instance's processing capacity, resource configuration, or manually set priorities, allowing more powerful instances to handle a larger request load.

[0115] Secondly, there are advanced routing strategies, such as Least Response Time and Least Connection. These strategies monitor the performance metrics of each instance and dynamically select the least busy or fastest responding instance to improve overall service quality. The system continuously collects and analyzes metrics such as response time, error rate, and concurrent connections for each instance to create a real-time performance profile that guides routing decisions.

[0116] Thirdly, there are high availability-related strategies, such as fault detection and circuit breaker mechanisms. The system continuously monitors the health status of each instance, automatically removing unhealthy instances from the routing table and reinstating them once they recover. For instances with abnormal responses or frequent timeouts, the system activates the circuit breaker mechanism to temporarily skip these instances, preventing fault propagation and cascading failures.

[0117] In addition, the system supports more complex routing strategies, such as Zone Affinity, Version Routing, and Tag Routing. Zone Affinity prioritizes instances located in the same data center or geographical region as the caller, reducing network latency; Version Routing allows the simultaneous deployment of different versions of the service and selects a specific version based on configuration or caller characteristics; Tag Routing performs precise matching based on the service instance's metadata tags (such as environment type, hardware specifications, etc.) to meet specific business needs.

[0118] Routing strategies can be flexibly configured through global settings, interface-level annotations, or method-level annotations. The system supports strategy combinations and multi-level decision-making. For example, instances can be filtered by region affinity first, and then the minimum response time strategy can be applied within the subset for final selection. This multi-dimensional routing decision-making ensures that the system can select the most suitable service instance in various complex scenarios.

[0119] Once the target instance is identified, the system replaces the service name in the abstract HTTP request template with the actual host address and port to form a complete HTTP request URL. For example, "http: / / user-service / api / users / 123" is transformed into "http: / / 192.168.1.100:8080 / api / users / 123". Simultaneously, the system adjusts the HTTP request headers based on the characteristics of the target instance, such as adding a tracking identifier, setting specific authentication information, or adjusting content negotiation parameters according to the instance version.

[0120] After the complete HTTP request is constructed, the system performs final request preparation work, including setting network parameters such as connection timeout, read timeout, and maximum retries, and applying possible request interceptors to make final modifications or enhancements to the request. These parameters and interceptors can be set at the global level or configured specifically at the interface or method level through annotations to achieve fine-grained request control.

[0121] Through this complex and precise routing decision-making process, the system transforms abstract service calls into concrete network requests, while introducing advanced features such as intelligent load balancing, fault isolation, and precise routing. This design not only simplifies the programming model for service callers but also significantly improves the reliability, performance, and maintainability of the microservice architecture. Service consumers do not need to concern themselves with the specific deployment details and network topology of service instances; they only need to express their call intent through declarative interfaces. The system automatically handles all complex service discovery and routing logic, making cross-service communication simple and reliable.

[0122] Step S5: Using a non-blocking HTTP client, perform request transformation on the complete HTTP request, output the target HTTP request, and use a reactive processing pipeline to achieve asynchronous sending and receiving of the target HTTP request and generate a reactive return value.

[0123] After generating a complete HTTP request, the system enters the execution phase: "Using a non-blocking HTTP client, the complete HTTP request is transformed into a target HTTP request. Through a reactive processing pipeline, the asynchronous sending and receiving of the target HTTP request and the generation of a reactive return value are achieved." This step is the core of the invention's execution. It utilizes modern non-blocking I / O technology and a reactive programming model to achieve highly efficient, low-resource-consumption asynchronous HTTP communication, significantly improving system performance in high-concurrency scenarios.

[0124] In some embodiments, step S5 may specifically include: performing request transformation on the complete HTTP request using a non-blocking HTTP client to generate a transformed request object; using a reactive processing pipeline, based on the transformed request object, to asynchronously send and receive the target HTTP request and obtain an HTTP response; and deserializing and type-converting the HTTP response according to the return type information of the interface method to generate a reactive return value.

[0125] Transform the complete HTTP request into a request format recognizable by the underlying non-blocking client (such as WebClient), handling necessary serialization and protocol adaptation. Use a reactive processing pipeline to send HTTP requests and receive responses asynchronously and non-blockingly, ensuring that the entire I / O process does not block the thread. Deserialize the HTTP response into the corresponding Java object based on the return type declared in the interface method (such as Mono or Flux), and wrap it as a reactive type for return.

[0126] First, the system converts the complete HTTP request object generated in the previous step into a request representation that can be understood by a non-blocking HTTP client. This invention supports various mainstream non-blocking HTTP client implementations, such as Reactor Netty, Spring WebClient, and AsyncHttpClient, and provides a unified adaptation layer, allowing developers to flexibly choose or replace the underlying implementation without affecting the upper-layer business code. The conversion process involves mapping all HTTP elements, including request methods, URLs, request headers, and request bodies, ensuring semantic consistency while optimizing request efficiency by leveraging the characteristics of the target client.

[0127] During the request transformation phase, the system also applies a series of optimization strategies. For example, for large request bodies, the system may employ chunked transfer encoding to avoid loading the entire request body into memory at once; for data requiring streaming processing (such as file uploads), the system uses the Reactive Streams interface to transmit data, implementing backpressure control to prevent fast producers from overwhelming slow consumers. These optimizations ensure that the system remains efficient and stable when handling requests of different sizes and types.

[0128] After the transformation is complete, the system constructs a reactive processing pipeline, which is one of the core architectures of this invention. The reactive processing pipeline adopts a declarative data flow processing model, organizing the sending of HTTP requests, the receiving and processing of responses into a series of composable operators. This design follows the core principles of reactive programming, making the entire request-response process an end-to-end data flow, rather than traditional blocking calls and nested callbacks.

[0129] In a reactive processing pipeline, each stage is non-blocking, meaning no thread is tied up waiting for I / O operations to complete. For example, when sending an HTTP request, the system doesn't block the current thread to wait for a network response. Instead, it registers a callback function and immediately releases the thread to handle other tasks. When the network response arrives, the system automatically invokes the registered callback function using an event loop to continue processing the response data. This design allows limited thread resources to handle more concurrent requests, significantly improving system throughput.

[0130] Another key feature of reactive processing pipelines is their rich set of operators, supporting various data transformation, filtering, combination, and error handling functions. For example, the map operator can convert the HTTP response body into a business object; the filter operator can filter responses based on specific conditions; the flatMap operator can handle nested asynchronous operations, such as the response of one HTTP request triggering another HTTP request; the timeout operator can set operation timeouts and provide alternative strategies; and the retry operator can automatically retry requests on failure, supporting advanced retry strategies such as exponential backoff.

[0131] Error handling is a crucial component of the reactive processing pipeline. The system provides a comprehensive error handling mechanism capable of capturing and transforming various exceptions, including network errors, timeout exceptions, and server-side errors (such as the HTTP 500 status code). Developers can use operators like `onErrorResume` and `onErrorReturn` to define recovery strategies for specific errors, such as returning default values, rolling back to an alternative data source, or executing compensation logic. The system also supports a global error handler to uniformly handle uncaught exceptions, ensuring that errors are properly handled without causing the entire application to crash.

[0132] At the end of the reactive processing pipeline, the system converts the HTTP response into the return type declared in the method declaration. This invention supports multiple reactive types, including Reactor's Mono and Flux, RxJava's Single and Observable, Java 9's CompletableFuture and Flow, and the standard Reactive Streams Publisher implementation. The conversion process involves steps such as response status code checking, response body parsing, and object mapping. Different processing strategies are employed for different return types.

[0133] For single-value response types (such as Mono and Single), the system will parse the entire HTTP response body into a single object. For example, the JSON response body will be parsed into a User object, and Mono will be returned.

[0134] For multi-valued reactive types (such as Flux and Observable), the system supports two modes: one is to parse the response body into a collection of objects, such as parsing a JSON array into Flux; the other is to support streaming parsing for large responses, processing the response data element by element to avoid loading all content into memory at once.

[0135] For non-reactive return types (such as ordinary POJO objects), the system maintains a reactive processing flow internally, but automatically blocks and waits before returning the result, converting the reactive result into a synchronous result. This design allows the system to support both reactive and traditional programming models, facilitating gradual migration and hybrid architecture applications.

[0136] The execution of a reactive processing pipeline is lazy, meaning that the construction of the pipeline does not immediately trigger an HTTP request; the request is only actually sent when the caller subscribes to the returned reactive object. This design provides more flexible control, allowing the caller to trigger requests at the appropriate time, and also lays the foundation for advanced features such as request batching, request merging, and request caching.

[0137] Overall, this step achieves a highly efficient asynchronous HTTP communication mechanism through non-blocking I / O and a reactive programming paradigm. It not only improves system performance and resource utilization in high-concurrency scenarios but also provides a simpler, more declarative programming model, enabling developers to easily handle complex asynchronous interaction scenarios such as parallel requests, request chaining, request cancellation, and timeout control. This reactive paradigm-based design represents best practices for modern distributed system communication and is better suited to the needs of cloud-native and microservice architectures.

[0138] Step S6: Capture the original exceptions generated during the underlying communication process. Based on the original exceptions, implement a retry mechanism with a backoff algorithm using reactive operators, and monitor the exception frequency through a circuit breaker to circuit break the service calls that fail frequently.

[0139] In HTTP communication within a distributed system, network instability, service overload, or temporary failures are unavoidable challenges.

[0140] This invention constructs a comprehensive and intelligent elastic communication system by "capturing the original exceptions generated during the underlying communication process, implementing a retry mechanism with a backoff algorithm based on the original exceptions using reactive operators, and monitoring the exception frequency through circuit breakers to circuit break frequently failed service calls," thereby significantly improving the stability and reliability of microservice architecture.

[0141] In some embodiments, step S6 may specifically include: capturing the original exception generated during the underlying communication process and converting it into a standard exception to generate a unified exception object; determining whether the retry conditions are met based on the exception information of the unified exception object; if so, initiating a retry request based on the reactive operator provided by the non-blocking HTTP client; outputting the final exception when the number of retries reaches the upper limit; and monitoring the exception frequency through a circuit breaker to circuit break the service calls that fail frequently.

[0142] Design a layered exception handling system to capture various raw exceptions during communication (such as connection timeouts and service unreachability) and convert them into application-defined standard exception types to ensure consistent exception handling. Based on the exception type and configured retry policy, determine whether to trigger a retry; if a retry is required, use reactive operators (such as `retryWhen`) in conjunction with a backoff algorithm to re-initiate the request; simultaneously, monitor the exception frequency using a circuit breaker pattern, and when the failure rate of a specific service exceeds a threshold, activate the circuit breaker mechanism to temporarily block requests to that service and prevent cascading failures.

[0143] Specifically, firstly, the system incorporates a comprehensive exception handling layer within its reactive processing pipeline, capable of capturing various raw exceptions that may occur during communication. These exceptions can generally be categorized into several types: network transmission exceptions (such as connection timeouts, read / write timeouts, connection resets, etc.), protocol parsing exceptions (such as HTTP response format errors, content parsing failures, etc.), server-returned error status codes (such as HTTP 500 Internal Server Error, HTTP 503 Service Unavailable, etc.), and client-side internal exceptions (such as resource exhaustion, thread interruption, etc.). The system not only captures these exceptions but also retains their original contextual information, including the request URL, request method, request headers, request body summary, response status code (if any), and response headers (if any). This information is crucial for subsequent exception analysis and processing.

[0144] Upon capturing a raw exception, the system first categorizes and evaluates it. Different types of exceptions require different handling strategies: some exceptions are temporary and suitable for retries (such as timeouts caused by network jitter); some exceptions are permanent and cannot be resolved by retries (such as HTTP 400 errors caused by incorrect request parameters); and some exceptions may indicate server resource constraints, requiring a backoff strategy before retrying (such as HTTP 429 errors caused by too many requests). The system intelligently determines the nature of each exception and the appropriate handling method based on pre-configured exception classification rules and the response header information returned by the server (such as the Retry-After header).

[0145] For exceptions deemed retryable, the system initiates an intelligent retry mechanism based on reactive operators. The core of this mechanism lies in its finely controlled retry strategy and advanced backoff algorithm. The system supports various retry strategy configurations, including maximum number of retries, retry interval, conditional retries (retrying only when specific conditions are met), and retry timeout (maximum total retry time). Developers can flexibly customize these strategies through global configurations, interface-level annotations, or method-level annotations to meet the needs of different business scenarios.

[0146] In terms of retry interval control, the system implements a variety of advanced backoff algorithms, far exceeding simple fixed-interval retries:

[0147] Exponential backoff is one of the most commonly used strategies. It causes the retry interval to increase exponentially (e.g., initially 100ms, then 200ms, 400ms, 800ms...), avoiding a "retry storm" for services already under pressure while giving them sufficient recovery time. The system supports configuring initial and maximum interval parameters to prevent the interval from growing too large.

[0148] Jitter backoff adds a random fluctuation factor to exponential backoff, causing the retry interval to fluctuate randomly around the calculated value. This design effectively prevents the "Thundering Herd" effect caused by multiple clients retrying simultaneously after a failure, distributing retry requests over a wider time range and reducing the server load.

[0149] Response-based dynamic backoff algorithms can dynamically adjust retry strategies based on server responses. For example, if the server returns an HTTP 429 (Too Many Requests) error with a Retry-After header, the system will prioritize using the time specified in that header as the waiting time for the next retry; or it can adjust backoff parameters based on the trend of response time changes, adopting a more aggressive backoff strategy when a sustained increase in response time is detected.

[0150] For certain special scenarios, the system also supports more complex retry strategies, such as priority backoff (using a more aggressive retry strategy for important requests), resource-aware retries (dynamically adjusting retry behavior based on the resource status of the client and server), and circuit breaker-aware retries (reducing the retry frequency when approaching the circuit breaker threshold).

[0151] The retry mechanism fully leverages the declarative nature and composition capabilities of reactive programming. By combining reactive operators such as `retryWhen` and `delayWhen`, the system can express complex retry logic in a concise and elegant way. For example, implementing a retry strategy with exponential backoff and a maximum retry limit requires only a few lines of declarative code, without the need for complex imperative programming and state management. This implementation is not only concise but also seamlessly integrates with the backpressure mechanism of reactive streams, ensuring that the retry process does not lead to resource exhaustion.

[0152] Working in parallel with the retry mechanism is the Circuit Breaker implementation, which monitors the success and failure status of service calls. When frequent service call failures are detected, it can promptly "break the circuit," preventing more requests from being sent to the already problematic service, thus preventing cascading failures and resource waste. The circuit breaker implementation of this invention employs a state machine design, containing three core states: closed (normally allowing requests), open (blocking requests), and half-open (allowing limited test requests).

[0153] The circuit breaker operates as follows: Initially, it is in the closed state, allowing all requests to be sent normally. The system continuously monitors the results of each service call, recording the success rate and exception type. When the failure rate exceeds a preset threshold (e.g., 50%) or the number of consecutive failures exceeds a specific value (e.g., 5 times) within a specified time window (e.g., 10 seconds), the circuit breaker switches to the open state, short-circuiting all requests to that service and immediately returning a preset degraded response or exception. This design avoids continuously sending requests destined to fail to an unhealthy service, while giving the service a chance to recover.

[0154] After remaining in the open state for a configured period (e.g., 30 seconds), the circuit breaker will switch to a half-open state, allowing a limited number of "probe requests" to pass through to test whether the service has recovered. If these probe requests succeed, the circuit breaker returns to the closed state and resumes normal service calls; if the probe requests still fail, the circuit breaker returns to the open state and continues to short-circuit requests. This self-healing mechanism allows the circuit breaker to automatically adapt to changes in service status without manual intervention.

[0155] The circuit breaker supports fine-grained configuration, allowing developers to customize parameters such as failure thresholds, time window sizes, the number of half-open state probe requests, failure counting strategies (whether to treat all exceptions as failures, or only specific types of exceptions), and the duration of the open state. Furthermore, the system supports independent configuration of circuit breakers at the service, method, or even specific parameter combination level, enabling refined circuit breaker control.

[0156] The circuit breaker and retry mechanism of this invention are organically combined to form a coordinated and consistent resilient strategy. For example, when a service call failure rate is detected to be rising but has not yet reached the circuit breaker threshold, the system may automatically adjust the retry strategy and adopt more conservative backoff parameters; or probe requests in the circuit breaker half-open state can use a special retry strategy to ensure accurate assessment of the service status. This multi-layered resilient mechanism works together to greatly improve the system's resilience in the face of network fluctuations and service instability.

[0157] In addition to retries and circuit breakers, the system also implements a series of supplementary resilience strategies, such as timeout control (to prevent requests from waiting indefinitely), bulkhead isolation (to prevent the spread of failures through resource isolation), and degraded response (to provide alternative results when the service is unavailable). These strategies can be flexibly combined according to business needs to build resilience solutions suitable for specific application scenarios.

[0158] It's worth noting that the operational status and statistics of all these resilience mechanisms are collected and sent to the monitoring system, generating real-time health metrics, alarm signals, and historical trend charts. Developers and operations personnel can use this information to understand the system's operational status, promptly identify potential problems, and optimize resilience strategy configurations based on historical patterns.

[0159] In summary, by capturing raw anomalies, implementing intelligent retry mechanisms and circuit breaker protection, and combining these with other resilient strategies, this invention constructs an adaptive, highly reliable distributed communication system. This system can effectively cope with various fault scenarios, minimizing the impact of failures and maintaining service availability and responsiveness. In the increasingly complex microservice architecture environment where failures are inevitable, this comprehensive resilient design provides the system with powerful self-protection and self-healing capabilities, serving as a key foundation for building highly reliable distributed systems.

[0160] In some embodiments, after monitoring the abnormal frequency through the circuit breaker and circuit breaking the circuit for frequently failing service calls, the following steps may also be included:

[0161] Step A: Define the standard interfaces and data transfer objects between the declarative interface proxy module, request parser and constructor, dynamic routing module, reactive execution engine and exception handling module, and generate the module integration framework.

[0162] In this embodiment, standard interfaces and data transmission objects are designed between modules to ensure loose coupling between modules while enabling smooth data exchange, forming an integrated framework.

[0163] Step B: Based on the module integration framework, dynamically load client configuration parameters from the external configuration center, collect monitoring data including request success rate, response time and concurrency data through the observability framework, and configure plugin interfaces for extending request interceptors, routing strategies and response processors.

[0164] In this embodiment, an integrated configuration center (such as Apollo or Spring Cloud Config) is used to support dynamic loading and updating of client configurations; an observability framework is also integrated to collect key operational metrics and provide support for monitoring and fault diagnosis; and a plug-in extension mechanism is designed to allow developers to customize the behavior of key components.

[0165] Step C: Integrate the module integration framework, the client configuration parameters, the monitoring data, and the plugin interface into a system to obtain an executable HTTP client instance.

[0166] In this embodiment, all modules, configurations, monitoring, and extension points are integrated into a complete, configurable, monitorable, and scalable HTTP client system, providing applications with declarative, dynamically routed, and responsive HTTP communication capabilities.

[0167] Optionally, the method further includes:

[0168] A multi-objective optimization model for service routing is constructed. The multi-objective optimization model includes objective functions for minimizing instance response time, maximizing load balancing, and minimizing network resource consumption, and introduces constraints such as service instance health status, regional affinity requirements, and specific label matching rules.

[0169] The multi-objective optimization model is decomposed into multiple sub-problems using the proximal splitting algorithm. The consistency of the solutions to each sub-problem is maintained by the proximal terms, and the alternating direction multiplier method is used to iteratively solve each sub-problem.

[0170] Using a Monte Carlo sampling-based stochastic exploration method, multiple candidate routing schemes are randomly generated in each iteration. A comprehensive score is calculated for each candidate routing scheme, and the next exploration direction is selected probabilistically based on the score.

[0171] Optionally, the application of the proximal splitting algorithm decomposes the multi-objective optimization model into multiple sub-problems, including:

[0172] The multi-objective optimization problem is transformed into a subproblem that can be solved in parallel using Lagrange dual decomposition, and each subproblem corresponds to a local optimization of an objective function;

[0173] In each iteration, the Lagrange multipliers are updated, and the coordination parameters between the subproblems are adjusted by the gradient ascent method to ensure that the solutions to the subproblems converge toward the global optimum.

[0174] Set convergence criteria. When the change in the objective function value during continuous iteration is less than a preset threshold or the maximum number of iterations is reached, terminate the iteration and output the current optimal service instance selection scheme.

[0175] Optionally, the method further includes:

[0176] Establish a set-value mapping model to map each service instance to its set of performance metric vectors, define a set of mapping functions, where each function represents an evaluation metric, and introduce uncertainty to represent the possible range of each instance mapping to the metric.

[0177] Using the trust region algorithm framework, a trust region is defined around the current optimal solution to limit the search range of each iteration. An approximate model is constructed to predict the objective function value of each point within the trust region. An adaptive step size mechanism is designed to dynamically adjust the size of the trust region according to the difference between the predicted value and the actual value.

[0178] For each candidate service instance, all objective functions are evaluated in parallel to identify the non-dominated solution set using the Pareto optimization criterion, and a weighted comprehensive score is calculated based on the weights of each objective function configured according to the business scenario.

[0179] In some embodiments, the present invention further optimizes the dynamic routing decision-making process through a near-end splitting algorithm, transforming the routing problem into a multi-objective optimization problem for solution. This method is particularly suitable for routing decision-making scenarios in complex microservice environments that require comprehensive consideration of multiple factors.

[0180] Specifically, the system first constructs a multi-objective optimization model for service routing. This model models routing decisions as an optimization problem with multiple potentially conflicting objectives. The main objective functions include: minimizing instance response time, aiming to select the fastest-responding service instance to improve user experience; maximizing load balancing, ensuring that requests are evenly distributed across instances to avoid single-point overload; and minimizing network resource consumption, prioritizing instances with lower network overhead, such as those in the same region or data center. Simultaneously, the model introduces various constraints, including service instance health status constraints to ensure that only healthy and available instances are selected; regional affinity requirements, prioritizing geographically proximate instances; and specific tag matching rules to support precise routing based on tags such as environment and version.

[0181] During the optimization phase, the system employs a proximity splitting algorithm to decompose the complex multi-objective optimization problem into a series of relatively simple subproblems. Each subproblem focuses on optimizing a specific metric; for example, one subproblem minimizes response time, while another maximizes load balancing. By introducing a proximity term, the system maintains consistency between the solutions to each subproblem; that is, a regularization term is added to limit the distance between the solution of each subproblem and the current global optimum, preventing conflicts between solutions. The system uses the Alternating Directional Multiplier Method (ADMM) or its variants to iteratively solve each subproblem, updating the estimate of the global optimum with each iteration until a satisfactory solution is found.

[0182] To avoid getting trapped in local optima, the system implements a Monte Carlo sampling-based stochastic exploration mechanism. In each iteration, the system randomly generates multiple candidate routing schemes, each representing a different combination of instance selections. For each candidate scheme, the system calculates its comprehensive score under multiple objective functions, comprehensively considering performance factors such as response time, load balancing, and resource consumption. Based on the calculated comprehensive score, the system employs a probabilistic selection strategy to determine the next exploration direction; schemes with higher scores have a greater probability of being selected, but schemes with lower scores also retain a certain chance of being selected to maintain the algorithm's exploration capability. As the iteration process progresses, the system gradually reduces the degree of randomness, making greater use of discovered high-quality solutions, achieving a smooth transition from exploration to utilization.

[0183] The system also incorporates an adaptive learning mechanism to continuously collect and analyze the actual effects of historical routing decisions to improve the optimization model. Specifically, the system records each routing decision instance and its subsequent performance, including metrics such as actual response time, success rate, and error type. Based on this feedback data, the system dynamically adjusts the weight coefficients of each objective function in the optimization model. For example, if it finds that response time has a more critical impact on business operations within a certain period, the system automatically increases the weight of the response time objective; if it detects performance issues caused by load imbalance, it adjusts the weight of the load balancing objective accordingly. The system also introduces a time decay factor, making the model more focused on recent data and trends, enabling it to quickly adapt to changes in the network environment and service status. During periods of relatively stable network conditions, the system reduces the intensity of random sampling, making greater use of validated optimization strategies; while during periods of significant environmental fluctuation, the system increases the intensity of random exploration.

[0184] To balance decision quality and efficiency, the system implements a pre-computation and caching mechanism. The system continuously runs optimization algorithms in the background, pre-computing optimal routing decisions for different network conditions, load patterns, and service states, and storing these pre-computation results in a multi-level cache. The caching system includes a memory cache for storing the most frequently accessed routing decisions, a local file cache for persisting medium-frequency routing schemes, and a distributed cache for sharing routing strategies across instances. For common request patterns, the system can directly retrieve the pre-computed optimal routing results from the cache, significantly reducing the overhead of real-time computation. When a new request is encountered that does not hit the cache, the system quickly constructs an initial solution based on the results of the most recent similar requests, and then performs a limited number of optimization iterations to control response time while ensuring decision quality.

[0185] Through this optimization mechanism based on the near-end splitting algorithm, the originally simple rule-matching routing decision is upgraded to a mathematically optimized intelligent routing system. This system not only handles multi-objective constrained optimization problems but also possesses adaptive learning and continuous improvement capabilities, making it particularly suitable for complex and dynamic microservice environments. Compared to traditional routing strategies, this method significantly improves the accuracy and adaptability of routing decisions, ensuring the selection of the optimal service instance under various load and network conditions.

[0186] In other embodiments, the present invention employs a set-value mapping-optimized trust region approach to achieve a more accurate and robust router. This approach is particularly suitable for scenarios where service performance is uncertain and tradeoffs need to be made between multiple potentially conflicting objectives.

[0187] First, the system establishes a set-valued mapping model to accurately express the uncertainty characteristics of service instance performance. In this model, each service instance is treated as a discrete point in the decision space, rather than a simple scalar value. The system defines a set of mapping functions F = {f1, f2, ..., f...} n}, where each function f i Each performance metric represents a specific evaluation indicator, such as f1 representing response time, f2 representing availability, and f3 representing resource utilization. Unlike traditional methods, the system constructs a set-value mapping G: X → 2^Y, mapping each service instance x to a set of its performance metric vectors G(x), rather than a single, fixed value. This design better reflects the volatility and uncertainty of service performance in real-world network environments. For example, the response time of a service instance might vary between [100ms, 150ms] at different times, rather than a fixed 125ms value. Through historical data analysis and real-time monitoring, the system dynamically maintains the possible value ranges for each instance across various metrics, forming a more realistic and reliable performance profile.

[0188] Building upon this foundation, the system implements a trust region algorithm framework for robust optimization. The core idea of ​​the trust region method is to define a "trust region" within the neighborhood of the current optimal solution, construct an approximate model of the objective function within this region, and solve the optimization problem on this approximate model. Specifically, the system defines a trust region around the current optimal routing scheme, limiting the search range for each iteration and avoiding drastic fluctuations in decision-making due to incorrect evaluations. Within the trust region, the system constructs surrogate models to predict the objective function values ​​of each candidate instance. These surrogate models are typically more efficient than the original objective function computation and can capture the main features of the objective function. The system employs an adaptive step-size mechanism, dynamically adjusting the size of the trust region by comparing the predicted values ​​of the surrogate models with the actual objective function values. When the prediction matches the actual results well, the system expands the trust region, allowing for a wider exploration; when the prediction error is large, the system shrinks the trust region, adopting a more conservative search strategy. To handle various constraints in routing decisions, the system introduces a penalty function method, which transforms constraints (such as label matching requirements and health status requirements that service instances must meet) into penalty terms of the objective function, thus transforming the constrained optimization problem into an unconstrained optimization problem to be solved.

[0189] The system's multi-function collaborative evaluation mechanism effectively handles complex trade-offs in multi-objective optimization. For each candidate service instance, the system evaluates all objective functions in parallel, fully utilizing the computing power of modern multi-core processors. When processing multi-objective optimization results, the system implements the Pareto optimization criterion, identifying the non-dominated solution set (Pareto front), which is the set of solutions that are optimal on at least one objective and not inferior to other solutions on other objectives. Through Pareto analysis, the system can show decision-makers the trade-offs between different objectives, providing more comprehensive information for the final decision. Depending on the specific business scenario and operating environment, the system supports flexible configuration of the weights of each objective function and calculates a weighted comprehensive score. Weight configuration can be static (preset via configuration file) or dynamic (automatically adjusted according to real-time business needs). The system also features a context-sensitive weight adjustment mechanism that automatically adjusts the importance of each indicator based on request characteristics (such as request type, user priority, time period, etc.). For example, for requests with high real-time requirements, the system automatically increases the weight of response time indicators; for batch processing requests, the system may focus more on throughput and resource utilization indicators.

[0190] To continuously improve the quality of routing decisions, the system constructs a real-time feedback adaptive learning system. This system records the expected performance and actual results of each routing decision, including comparative data such as predicted and actual response times, and expected and actual success rates. Based on this continuously accumulated historical data, the system dynamically updates the uncertainty representation of the set value mapping G, making performance predictions more accurate. The system implements an incremental learning algorithm, which can continuously adjust the parameters of the proxy model without rebuilding the entire model, improving prediction accuracy. This incremental learning mechanism is particularly suitable for the frequent changes in service states in microservice environments, enabling rapid adaptation to new performance patterns. To ensure the model reflects the latest system state, a forgetting mechanism is designed, gradually reducing the influence weight of historical data through a time decay factor, making the model more focused on recent performance and trend changes.

[0191] Considering the stringent response time requirements in practical applications, the system implements a hierarchical decision optimization strategy to balance decision quality and efficiency. This strategy employs a two-stage decision-making process: a coarse-screening stage and a fine-tuning stage. In the coarse-screening stage, the system uses lightweight rules and simple heuristics to quickly eliminate obviously unsuitable instances, such as unhealthy instances, instances with mismatched regions, or instances with excessive load. This stage has minimal computational overhead, rapidly reducing the size of the candidate set. In the fine-tuning stage, the system applies a complete trust region optimization algorithm to the coarse-screened candidate instance set, performing precise multi-objective optimization calculations to select the instance with the best overall performance. The system also introduces a computational budget control mechanism, dynamically adjusting the algorithm's accuracy and iteration count based on request priority and time constraints. For high-priority requests or requests with ample time, the system can perform more iterations to obtain more accurate results; for low-priority requests or requests with tight deadlines, the system appropriately reduces the computational load to ensure a routing decision is made within an acceptable timeframe.

[0192] Through this trust region approach based on set-value mapping optimization, the system implements a theoretically rigorous and practically effective intelligent routing mechanism. This method not only handles the uncertainty of service performance but also determines the optimal balance among multiple potentially conflicting optimization objectives. Compared to traditional simple routing strategies, this approach significantly improves the scientific rigor and reliability of routing decisions, providing strong technical support for building high-performance, highly available microservice architectures. Especially when facing complex and ever-changing network environments and business requirements, this method demonstrates excellent adaptability and robustness, ensuring that the system makes optimal routing choices under various conditions.

[0193] like Figure 2 As shown, the present invention also provides a declarative HTTP client implementation system that supports dynamic routing, which may specifically include:

[0194] The metadata generation module is used to identify interfaces with reactive HTTP client annotations based on declarative interface definition information, and record the identified interface information and method annotations to form an interface metadata set.

[0195] The proxy object instance generation module is used to create a proxy implementation class factory for the corresponding interface based on the interface metadata set, and generate a dynamic proxy object instance by calling the proxy implementation class factory;

[0196] The request template generation module is used to extract the URL path template through the dynamic proxy object instance, replace the path variables and query parameters in the URL path template according to the path variable annotation and the request parameter annotation, parse the request header annotation and the request body annotation, set the HTTP request header and the request body, and generate an abstract HTTP request template based on the URL path template obtained after replacement, the request header and the request body.

[0197] The HTTP request generation module is used to generate a complete HTTP request by calling a pre-determined routing strategy and optimal service instance based on the abstract HTTP request template, replacing the abstract service name with the specific instance address;

[0198] The reactive return value generation module is used to transform the complete HTTP request through a non-blocking HTTP client, output the target HTTP request, realize the asynchronous sending and response reception of the target HTTP request through a reactive processing pipeline, and generate a reactive return value.

[0199] The circuit breaker module is used to capture the original exceptions generated during the underlying communication process. Based on the original exceptions, a retry mechanism with a backoff algorithm is implemented using reactive operators. The circuit breaker monitors the exception frequency and circuit breaks the service calls that fail frequently.

[0200] The apparatus in this application embodiment can execute the method provided in this application embodiment, and the implementation principle is similar. The actions performed by each module in the apparatus of each embodiment of this application correspond to the steps in the method of each embodiment of this application. For detailed functional descriptions of each module of the apparatus, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0201] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A declarative HTTP client implementation method supporting dynamic routing, characterized in that, Includes the following steps: Based on declarative interface definition information, interfaces with reactive HTTP client annotations are identified, and the identified interface information and method annotations are recorded to form an interface metadata set. Based on the interface metadata set, a proxy implementation class factory for the corresponding interface is created, and a dynamic proxy object instance is generated by calling the proxy implementation class factory. The URL path template is extracted using the dynamic proxy object instance. The path variables and query parameters in the URL path template are replaced according to the path variable annotation and request parameter annotation. The request header annotation and request body annotation are parsed, and the HTTP request header and request body are set. Based on the URL path template obtained after replacement, the request header and the request body, an abstract HTTP request template is generated. Based on the abstract HTTP request template, a pre-determined routing strategy and optimal service instance are invoked, the abstract service name is replaced with the specific instance address, and a complete HTTP request is generated. The complete HTTP request is transformed using a non-blocking HTTP client, and the target HTTP request is output. The asynchronous sending and receiving of the target HTTP request and the generation of a reactive return value are achieved through a reactive processing pipeline. The system captures raw exceptions generated during the underlying communication process. Based on these raw exceptions, it implements a retry mechanism with a backoff algorithm using reactive operators and monitors the exception frequency through a circuit breaker to circuit breakers for frequently failing service calls.

2. The method according to claim 1, characterized in that, The method, based on declarative interface definition information, identifies interfaces with reactive HTTP client annotations and records the identified interface information and method annotations to form an interface metadata set, including: Based on the interface with reactive HTTP client annotations, client-level annotations and method-level annotations are defined, and annotation specifications are established based on the client-level annotations and method-level annotations; When the application starts, the annotation specification is scanned to identify interfaces with reactive HTTP client annotations, and the identified interface information and method annotations are recorded to form an interface metadata set.

3. The method according to claim 1, characterized in that, The step of creating a proxy implementation class factory for the corresponding interface based on the interface metadata set, and generating a dynamic proxy object instance by calling the proxy implementation class factory, includes: Based on the interface metadata set, a factory of proxy implementation classes for the corresponding interface is created using JDK dynamic proxy technology or code generation library technology. The proxy implementation class factory generates a dynamic proxy object instance for each declarative interface and registers the dynamic proxy object instance to the IoC container.

4. The method according to claim 1, characterized in that, The process involves extracting a URL path template from the dynamic proxy object instance, replacing path variables and query parameters in the URL path template based on path variable annotations and request parameter annotations, parsing request header annotations and request body annotations, setting HTTP request headers and request bodies, and generating an abstract HTTP request template based on the replaced URL path template, the request headers, and the request body. By intercepting interface method calls through the dynamic proxy object instance, the method signature, annotation information and actual call parameters are obtained. Based on the method signature and the annotation information, the HTTP request mapping annotation is identified and parsed to extract the URL path template. Based on the path variable annotation and request parameter annotation, the actual call parameters replace the path variables and query parameters in the URL path template, and the request header annotation and request body annotation are parsed to set the HTTP request header and request body; An abstract HTTP request template is generated based on the URL path template obtained after replacement, the request header, and the request body.

5. The method according to claim 1, characterized in that, The process involves using the abstract HTTP request template to invoke a pre-determined routing strategy and optimal service instance, replacing the abstract service name with the specific instance address, and generating a complete HTTP request, including: Based on the abstract HTTP request template, the service instance list and its metadata can be obtained in real time by integrating the service registry client; Implement a routing selector interface based on the aforementioned metadata, construct a basic load balancing algorithm, then call the routing selector interface and the load balancing algorithm, and combine them with the service instance list to select the optimal service instance; Replace the abstract service name of the optimal service instance with the specific instance address to generate a complete HTTP request.

6. The method according to claim 1, characterized in that, The process involves using a non-blocking HTTP client to transform the complete HTTP request, outputting a target HTTP request, and then using a reactive processing pipeline to asynchronously send and receive the target HTTP request and generate a reactive return value. This includes: The complete HTTP request is transformed using a non-blocking HTTP client to generate a transformed request object. Based on the transformed request object, the target HTTP request is sent asynchronously and the response is received using a reactive processing pipeline to obtain an HTTP response. Based on the return type information of the interface method, the HTTP response is deserialized and type-converted to generate a reactive return value.

7. The method according to claim 1, characterized in that, The exception is converted into a standard exception. The original exception generated during the underlying communication process is captured. Based on the original exception, a retry mechanism with a backoff algorithm is implemented using reactive operators. The exception frequency is monitored via a circuit breaker, and frequent service calls that fail are circuit-broken. This includes: Capture raw exceptions generated during underlying communication and convert them into standard exceptions to generate a unified exception object; Based on the exception information of the unified exception object, it is determined whether the retry conditions are met. If they are met, a retry request is initiated based on the reactive operator provided by the non-blocking HTTP client. When the number of retries reaches the upper limit, the final exception is output. Furthermore, the exception frequency is monitored through a circuit breaker, and service calls that fail frequently are circuit-broken.

8. The method according to claim 5, characterized in that, The step of calling the route selector interface and the load balancing algorithm, and selecting the optimal service instance in conjunction with the service instance list, includes: Based on the service instance list and the metadata, the route selector interface is called to obtain a set of candidate instances filtered based on the request content, instance metadata, or custom rules. The load balancing algorithm is invoked to perform an instance selection operation on the service instances in the candidate instance set, and the optimal service instance is selected. The load balancing algorithm includes at least one of the round-robin algorithm, random algorithm, and least connection algorithm.

9. The method according to claim 1, characterized in that, After monitoring the abnormal frequency through circuit breakers and triggering circuit breakers for frequently failing service calls, the following steps are also included: Define the standard interfaces and data transfer objects between the declarative interface proxy module, request parser and constructor, dynamic routing module, reactive execution engine and exception handling module, and generate a module integration framework; Based on the module integration framework, client configuration parameters are dynamically loaded from an external configuration center. Monitoring data, including request success rate, response time, and concurrency data, are collected through an observability framework. Plugin interfaces for extending request interceptors, routing strategies, and response processors are also configured. The module integration framework, client configuration parameters, monitoring data, and plugin interface are integrated into a system to obtain an executable HTTP client instance.

10. The method according to claim 1, characterized in that, The method further includes: A multi-objective optimization model for service routing is constructed. The multi-objective optimization model includes objective functions for minimizing instance response time, maximizing load balancing, and minimizing network resource consumption, and introduces constraints such as service instance health status, regional affinity requirements, and specific label matching rules. The multi-objective optimization model is decomposed into multiple sub-problems using the proximal splitting algorithm. The consistency of the solutions to each sub-problem is maintained by the proximal terms, and the alternating direction multiplier method is used to iteratively solve each sub-problem. Using a Monte Carlo sampling-based stochastic exploration method, multiple candidate routing schemes are randomly generated in each iteration. A comprehensive score is calculated for each candidate routing scheme, and the next exploration direction is selected probabilistically based on the score.

11. The method according to claim 10, characterized in that, The application of the proximal splitting algorithm decomposes the multi-objective optimization model into multiple sub-problems, including: The multi-objective optimization problem is transformed into a subproblem that can be solved in parallel using Lagrange dual decomposition, and each subproblem corresponds to a local optimization of an objective function; In each iteration, the Lagrange multipliers are updated, and the coordination parameters between the subproblems are adjusted by the gradient ascent method to ensure that the solutions to the subproblems converge toward the global optimum. Set convergence criteria. When the change in the objective function value during continuous iteration is less than a preset threshold or the maximum number of iterations is reached, terminate the iteration and output the current optimal service instance selection scheme.

12. The method according to claim 10 or 11, characterized in that, The method further includes: Establish a set-value mapping model to map each service instance to its set of performance metric vectors, define a set of mapping functions, where each function represents an evaluation metric, and introduce uncertainty to represent the possible range of each instance mapping to the metric. Using the trust region algorithm framework, a trust region is defined around the current optimal solution to limit the search range of each iteration. An approximate model is constructed to predict the objective function value of each point within the trust region. An adaptive step size mechanism is designed to dynamically adjust the size of the trust region according to the difference between the predicted value and the actual value. For each candidate service instance, all objective functions are evaluated in parallel to identify the non-dominated solution set using the Pareto optimization criterion, and a weighted comprehensive score is calculated based on the weights of each objective function configured according to the business scenario.

13. A declarative HTTP client implementation apparatus supporting dynamic routing, characterized in that, include: The metadata generation module is used to identify interfaces with reactive HTTP client annotations based on declarative interface definition information, and record the identified interface information and method annotations to form an interface metadata set. The proxy object instance generation module is used to create a proxy implementation class factory for the corresponding interface based on the interface metadata set, and generate a dynamic proxy object instance by calling the proxy implementation class factory; The request generation module is used to extract the URL path template through the dynamic proxy object instance, replace the path variables and query parameters in the URL path template according to the path variable annotation and the request parameter annotation, parse the request header annotation and the request body annotation, set the HTTP request header and the request body, and generate an abstract HTTP request template based on the URL path template obtained after replacement, the request header and the request body. The HTTP request generation module is used to generate a complete HTTP request by calling a pre-determined routing strategy and optimal service instance based on the abstract HTTP request template, replacing the abstract service name with the specific instance address; The reactive return value generation module is used to transform the complete HTTP request through a non-blocking HTTP client, output the target HTTP request, realize the asynchronous sending and response reception of the target HTTP request through a reactive processing pipeline, and generate a reactive return value. The circuit breaker module is used to capture the original exceptions generated during the underlying communication process. Based on the original exceptions, a retry mechanism with a backoff algorithm is implemented using reactive operators. The circuit breaker monitors the exception frequency and circuit breaks the service calls that fail frequently.

Images