Route-level fusing method and system based on Wasm plug-in

Abstract

The invention provides a routing-level fusing method and system based on a Wasm plug-in, the method is applied to a target agent of a data plane, and the target agent is an agent meeting an action range defined by a user-defined fusing resource in a plurality of agents of the data plane. The method comprises the following steps: in response to received Wasm plug-in configuration information which is sent by a control plane and is generated based on a custom fusing resource, carrying out initial configuration on a loaded Wasm plug-in; the target agent executes the following steps through the Wasm plug-in: identifying a target request of which the routing context attribute accords with a target routing rule and which is matched with a fuse from service requests flowing through the target agent; checking the current state of the fuse corresponding to the target request; if the target request is in the fusing state, feeding back a fusing response to the initiating end of the target request; and if so, releasing the target request to the upstream service. According to the method and the device, non-intrusive routing-level fusing protection is realized, and the method and the device have a flexible strategy configuration capability.

Description

Technical Field

[0001] This application belongs to the field of communication technology, specifically relating to a routing-level circuit breaker method and system based on the Wasm plugin. Background Technology

[0002] A service mesh is an infrastructure layer specifically designed to handle service communication. Its core responsibility is to ensure reliable request transmission within the complex service topologies comprised of cloud-native applications. The primary goal of a service mesh is to decouple service governance capabilities from business logic code and decentralize them to the infrastructure layer, allowing developers to focus more on the business logic itself. In actual deployment, service meshes are typically deployed alongside applications as lightweight network proxies, thus achieving service governance in a way that is transparent to the application.

[0003] From an overall architectural perspective, the service mesh comprises a data plane and a control plane. The data plane consists of a series of independent proxies deployed in a sidecar pattern, running alongside each service instance. These proxies directly handle all inbound and outbound network traffic for the service, performing functions such as traffic forwarding, routing, health checks, load balancing, authentication, and generating monitoring data. The control plane, as the management component of the service mesh, is responsible for uniformly distributing policies and configurations to the proxies in the data plane, maintaining rule consistency across the entire service mesh, and achieving centralized governance.

[0004] A typical service mesh deployment network structure is as follows: Figure 1 As shown. In Figure 1 In the diagram, a light-colored rectangle represents a microservice, which is an independent instance of a business service; a dark-colored small square represents the Sidecar proxy deployed alongside it; both are encapsulated in the same deployment unit (such as a Kubernetes Pod), forming the smallest service unit that can be governed by the mesh. The connections between microservices represent communication traffic between services. All traffic is transparently intercepted, forwarded, and managed by the Sidecar proxy, allowing the microservices themselves to focus only on business logic, thus initially decoupling business logic from communication logic.

[0005] Istio, as a currently widely used service mesh framework in the industry, adopts an architecture that separates the control plane and the data plane, such as... Figure 2As shown, this separation architecture forms the foundation for flexible and robust service governance capabilities. The data plane consists of a series of Envoy proxy extensions deployed in a Sidecar pattern. In actual deployment, each business service instance is accompanied by a Sidecar proxy, and all these distributed proxies collaborate to form a unified data plane. This data plane is responsible for the forwarding and governance of all traffic, decoupling complex network issues from the application. The control plane is the brain of the service mesh, and its core responsibilities include service discovery, configuration management, and security policy (certificate) management. It achieves centralized control by uniformly distributing configurations to the data plane.

[0006] Service mesh, through its "microservice-Sidecar" deployment model and architecture that separates the control plane and data plane, achieves transparent, unified, and refined governance of inter-service communication, ultimately decoupling business logic from communication logic.

[0007] The powerful scalability of the data plane largely benefits from its adoption of the WebAssembly (Wasm) dynamic plugin architecture. The Envoy community pioneered the use of Wasm-based filters, creating a security sandbox by embedding the Wasm runtime within the proxy, and spearheaded the development of the proxy-wasm standard, defining a series of network proxy interfaces to execute Wasm binaries. This dynamic extension mechanism based on the proxy-wasm standard has become the de facto standard for achieving a high-performance, secure, and portable plugin system. It allows users to develop custom filters in multiple languages, compile them into Wasm modules, and then dynamically load them at runtime by proxies that support the standard, thus achieving non-intrusive extensions to traffic behavior.

[0008] Figure 3 This demonstrates the core runtime architecture of the Wasm filter under the Envoy proxy: 1. Complete lifecycle management: Custom Wasm filters inject logic throughout the complete lifecycle controlled by Envoy (from startup, configuration, processing header information to processing request body) by implementing specific filter interfaces.

[0009] 2. Sandboxed execution environment: Custom code runs in the Wasm sandbox (V8 engine), which is isolated from the Envoy main process to ensure the stability and security of the proxy itself.

[0010] 3. Standardized Capability Interfaces: Through the standard API (Application Programming Interface), the Wasm filter can securely call Envoy's core functions, including: traffic intervention, reading and writing request and response headers, footers, and metadata through header and footer access interfaces and request metadata access interfaces; external communication, initiating gRPC or HTTP calls to external services through external API calls; and observability, generating custom monitoring data through statistics and logging interfaces.

[0011] The aforementioned Wasm-based plugin architecture transforms the traditional complex extension process, which requires modifying C++ code and recompiling, into a dynamic, secure, and language-independent architectural pattern. Users can dynamically load custom filters without restarting the proxy, flexibly implementing customized needs such as traffic management and security checks.

[0012] Circuit breaking is a core governance capability for ensuring the resilience of distributed systems. As the complexity of microservice architectures increases, production environments place higher demands on the granularity, flexibility, and security of circuit breaking mechanisms. Current service mesh circuit breaking solutions mainly include the following two typical implementation paths: 1. Service-level circuit breaking based on Istio's native capabilities This solution directly adopts the standard circuit breaker mechanism provided by the Istio community, implemented through the configuration of the DestinationRule resource. Its working principle is as follows: the Envoy proxy maintains a logical connection pool and anomaly detection mechanism for each upstream service it manages. When the Envoy proxy sends a request to a specific instance of an upstream service, it periodically collects the instance's anomaly metrics (e.g., consecutive 5xx error responses). When the accumulated anomalies from an instance reach a preset threshold, Envoy determines that the instance is in an unhealthy state and temporarily isolates it in its internal load balancing pool. During subsequent circuit breaker windows, new outbound requests will not be routed to the abnormal instance, thus achieving service instance-level circuit breaker protection. Although this solution is natively integrated with the Istio architecture and simple to deploy, its circuit breaker granularity is limited to the service level and cannot provide precise protection for specific interfaces or routes within a service. Once a circuit breaker is triggered, it will affect all interfaces of the entire service.

[0013] 2. Customized circuit breakers based on source code intrusion This solution defines the circuit breaker strategy by exposing custom fuses to users. Its highly intrusive implementation architecture is as follows: Figure 4As shown, to implement customized logic, the entire chain involves customizing the circuit breaker → modifying the Envoy filter source code → rebuilding the data plane image → integrating the customized circuit breaker. While this solution attempts to provide finer-grained circuit breaking capabilities, its core problem lies in its highly invasive implementation architecture—to implement customized logic, it is necessary to directly modify the Envoy source code and rebuild the data plane image. This approach leads to two significant drawbacks: first, a heavy maintenance burden, requiring long-term maintenance of a private Envoy branch and synchronization with the open-source version; second, cumbersome updates and deployments, as any logic modification requires a full update of the data plane image, resulting in a high risk of business interruption and long iteration cycles.

[0014] Therefore, existing service mesh circuit breaker solutions face the following core technical challenges when addressing the need for refined governance: 1. The circuit breaker granularity is not fine, supporting only the service / instance level and failing to achieve precise protection at the route level; 2. The architecture is highly invasive, requiring modification of the source code, resulting in high maintenance costs and requiring restarts for updates; 3. The dynamic capabilities are poor, making it impossible to achieve flexible and rapid iteration of policies. Summary of the Invention

[0015] In view of the above problems, the purpose of this application is to provide a routing-level circuit breaker method and system based on Wasm plugin to overcome or at least partially solve the above problems.

[0016] In a first aspect, embodiments of this application provide a route-level circuit breaker method based on the Wasm plugin, applied to a target proxy in the data plane of a service mesh. The target proxy is a proxy among multiple proxies included in the data plane that conforms to the scope defined by a custom circuit breaker resource. The method includes: In response to receiving Wasm plugin configuration information generated based on the custom circuit breaker resource from the control plane, the loaded Wasm plugin is initialized and configured. The target agent performs the following steps through the Wasm plugin: From the business requests flowing through the target proxy, identify the target requests whose routing context attributes match the target routing rules and whose corresponding circuit breakers can be found in the circuit breaker list based on the request attributes. The target routing rules are defined by the custom circuit breaker resource, carried by the Wasm plugin configuration information and sent to the Wasm plugin. Before the target request is routed to the upstream service, check the current state of the circuit breaker corresponding to the target request; If the circuit breaker corresponding to the target request is in a circuit-broken state, a circuit-broken response is sent back to the initiator of the target request; or, if the circuit breaker corresponding to the target request is in an unbroken state, the target request is allowed to proceed to the upstream service.

[0017] Secondly, embodiments of this application provide a route-level circuit breaker system based on the Wasm plugin, comprising: The control plane and the data plane, wherein the data plane includes multiple agents, and the target agent is the agent among the multiple agents included in the data plane that conforms to the scope defined by the custom circuit breaker resource; The control plane receives custom circuit breaker resources, generates Wasm plugin configuration information based on the custom circuit breaker resources, and sends the Wasm plugin configuration information to the target agent. The target agent initializes the loaded Wasm plugin based on the Wasm plugin configuration information. The Wasm plugin is used for: From the business requests flowing through the target proxy, identify the target requests whose routing context attributes match the target routing rules and whose corresponding circuit breakers can be found in the circuit breaker list based on the request attributes. The target routing rules are defined by the custom circuit breaker resource, carried by the Wasm plugin configuration information and sent to the Wasm plugin. Before the target request is routed to the upstream service, check the current state of the circuit breaker corresponding to the target request; If the circuit breaker corresponding to the target request is in a circuit-broken state, a circuit-broken response is sent back to the initiator of the target request; or, if the circuit breaker corresponding to the target request is in an unbroken state, the target request is allowed to proceed to the upstream service.

[0018] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0019] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0020] In this embodiment, after receiving the Wasm plugin configuration information generated based on custom circuit breaker resources from the control plane, the loaded Wasm plugin is initialized and configured. Based on the Wasm plugin, target requests that meet the routing rules and match the circuit breaker are identified from the business requests flowing through the target proxy. The current state of the circuit breaker corresponding to the target request is identified, and a circuit breaker response is fed back to the initiator of the target request or the target request is allowed to proceed to the upstream service according to the state identification. Through custom resources and Wasm plugins, non-intrusive route-level circuit breaker protection is achieved, and it has fine-grained control and flexible policy configuration capabilities, meeting the diverse governance needs under complex microservice architectures. Through the automatic distribution and dynamic activation of circuit breaker policies, the governance capabilities of the service mesh infrastructure are enhanced, thereby improving the overall stability, availability, agility, and operational efficiency of the microservice system. Attached Figure Description

[0021] Figure 1 This diagram illustrates the network architecture of a service mesh deployment. Figure 2 This diagram illustrates the Istio service mesh framework. Figure 3 This demonstrates the core operating architecture of the Wasm filter under the Envoy proxy; Figure 4 A schematic diagram of the existing customized circuit breaker technology chain is shown; Figure 5 A schematic diagram of the routing-level circuit breaker method based on the Wasm plugin provided in an embodiment of this application is shown; Figure 6 A schematic diagram of the memory bucket mechanism provided in the application embodiment is shown; Figure 7 This application illustrates the overall implementation flowchart of the routing-level circuit breaker method based on the Wasm plugin provided in the embodiments of this application; Figure 8 This application illustrates a schematic diagram of a route-level circuit breaker system based on the Wasm plugin provided in an embodiment of the present application. Figure 9 A structural diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0024] The routing-level circuit breaker method based on the Wasm plugin provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0025] This application provides a route-level circuit breaker method based on Wasm plugins, applied to a target proxy in the data plane of a service mesh. The data plane includes multiple proxies, and the target proxy is a proxy that conforms to the scope defined by a custom circuit breaker resource (CTGCircuitBreaker), and the target proxy has the ability to load and execute Wasm plugins. This embodiment uses Envoy proxy as an example for illustration. The service mesh in this application embodiment can be a commonly used service mesh framework in the industry, such as Istio, or other service meshes that adopt a control plane and data plane separation architecture and build the data plane with proxies that support Wasm sandboxing. This application does not limit this. The custom circuit breaker resource is a configuration specification in the service mesh used to declare circuit breaker policies. It defines the scope of the circuit breaker policy. For example, the scope is defined by the matching rules declared in the resource to filter out the target proxies in the data plane that need to implement this circuit breaker policy.

[0026] like Figure 5 As shown, the routing-level circuit breaker method based on the Wasm plugin provided in this application includes the following steps: Step 501: Upon receiving the Wasm plugin configuration information generated based on the custom circuit breaker resource sent by the control plane, the target agent initializes the configuration of the loaded Wasm plugin.

[0027] The control plane receives user-provided custom circuit breaker resources, generates Wasm plugin configuration information based on these resources, and sends the Wasm plugin configuration information to the corresponding target proxy in the data plane (e.g., the selected Envoy proxy) based on the scope defined by the custom circuit breaker resources. The Wasm plugin configuration information generated based on the custom circuit breaker resources may not include the scope defined by the custom circuit breaker resources.

[0028] Upon receiving the Wasm plugin configuration information, the target proxy initializes the Wasm plugin already loaded in the target proxy and performs subsequent operations based on the initialized Wasm plugin.

[0029] Step 502: The Wasm plugin identifies target requests from business requests flowing through the target proxy whose routing context attributes match the target routing rules and whose corresponding circuit breakers can be found in the circuit breaker list based on the request attributes. The target routing rules are defined by custom circuit breaker resources, carried by Wasm plugin configuration information, and sent to the Wasm plugin.

[0030] For business requests flowing through the target proxy, the business request itself does not natively carry routing attributes. During the processing, the target proxy will dynamically inject the corresponding context routing attributes into the business request based on the currently effective routing configuration.

[0031] When identifying business requests that match the target routing rules, the Wasm plugin obtains the context routing attributes added by the target proxy through which the business request flows, and identifies candidate requests whose context routing attributes match the target routing rules among the business requests flowing through the target proxy.

[0032] The target routing rules defined by the custom circuit breaker resource indicate the routing matching conditions. These target routing rules, derived from the custom circuit breaker resource, are carried and distributed to the Wasm plugin through its configuration information. After obtaining the context routing attributes of the business request, the Wasm plugin identifies whether the context routing attributes of the business request match the target routing rules. If they match, the business request is designated as a candidate request.

[0033] Specifically, the context routing attributes injected by the target proxy for a business request may include a route name, and one or more route names may be pre-declared in the target routing rule. The Wasm plugin compares the route name corresponding to the business request with the predefined route name in the target routing rule to determine if they match. If they match, the business request is identified as a candidate request that conforms to the target routing rule.

[0034] After identifying candidate requests that match the target routing rules in the business requests flowing through the target proxy, the Wasm plugin searches for the corresponding circuit breaker in the circuit breaker list based on the request attributes of the candidate requests, and determines the candidate requests that match the circuit breaker as the target requests.

[0035] The business request itself contains request attributes, such as, but not limited to, one or more of the following: request path, request method, request headers, target host, and target port. Among them, the request path and request method jointly identify the specific operation endpoint and behavior; the request header carries rich contextual information, which can be used to achieve fine-grained matching based on specific business tags; the target host and target port are dynamically resolved and determined by the target proxy based on its configuration and the status of available instances.

[0036] When searching for a corresponding circuit breaker in the circuit breaker list based on the request attributes of a candidate request, the following operations are included: One or more key attributes are extracted from the request attributes of candidate requests and combined to generate a unique circuit breaker lookup key. For example, a circuit breaker lookup key can be generated based on the request path and request method, the target host and target port, or the request path and request headers. The generated circuit breaker lookup key is used to traverse a list of circuit breakers, which maintains the association between the lookup key and the corresponding circuit breaker. This list allows for quick retrieval of the associated circuit breaker based on the lookup key, and the identification of candidate requests with matching circuit breakers as target requests to be monitored.

[0037] In another implementation, the lookup key can be specifically determined by all matching conditions in the circuit breaker policy configuration to ensure that each unique policy corresponds to an independent circuit breaker instance. For example, based on a matching rule specifying method: GET and path: / api / v1 / users, a lookup key like "GET: / api / v1 / users" can be generated. Then, the generated circuit breaker lookup key is used to traverse the circuit breaker list (which maintains a mapping between lookup keys and circuit breaker instances) to retrieve the associated circuit breakers. Finally, candidate requests successfully associated with circuit breakers are identified as target requests.

[0038] By matching the context routing attributes of business requests with the target routing rules, candidate requests are filtered out from the business requests. Then, the circuit breakers corresponding to the candidate requests are found based on the request attributes, so that the requests that are successfully associated with the circuit breakers and need to be controlled by the circuit breaker mechanism are identified as the target requests to be monitored.

[0039] Step 503: Before the target request is routed to the upstream service, the Wasm plugin checks the current state of the circuit breaker corresponding to the target request.

[0040] After identifying the target request to be monitored, the Wasm plugin checks the current state of the circuit breaker corresponding to the target request before the target request is routed to the upstream service. The current state of the circuit breaker is either broken or not broken, and the appropriate processing method is adopted to handle the target request according to the different states of the circuit breaker.

[0041] Step 504: In response to the circuit breaker corresponding to the target request being in a circuit-broken state, the Wasm plugin sends a circuit-broken response to the initiator of the target request; or, in response to the circuit breaker corresponding to the target request being in an unbroken state, the Wasm plugin allows the target request to be passed to the upstream service.

[0042] If the circuit breaker corresponding to the target request is in a broken state, a circuit breaker response needs to be sent back to the initiator of the target request to perform fast failure and protect the upstream service. If the circuit breaker corresponding to the target request is in an unbroken state, it indicates that the request path is in a healthy state and the target request can be processed. At this time, the target request is allowed to pass to the upstream service to complete the normal business processing flow, and the subsequent results of this request (such as success, failure, or timeout) will be fed back to the circuit breaker in real time to update its internal statistics and trigger subsequent status decisions.

[0043] When sending a circuit breaker response back to the initiator of the target request, the Wasm plugin performs the following operations: Based on the circuit breaker response configuration, construct a circuit breaker response containing at least one of a specific status code, response header, and response body. The circuit breaker response configuration is defined by a custom circuit breaker resource and sent to the Wasm plugin through Wasm plugin configuration information. The constructed circuit breaker response is fed back to the originating end of the target request.

[0044] The custom circuit breaker resource defines the circuit breaker response configuration. This configuration, derived from the custom circuit breaker resource, is distributed to the Wasm plugin via the Wasm plugin configuration information. When the circuit breaker corresponding to the target request is in a circuit-broken state and a circuit breaker response needs to be sent back to the client (the initiator of the target request), the Wasm plugin constructs a circuit breaker response based on the circuit breaker response configuration. This response includes at least one of the following: a specific status code, a response header, and a response body. The specific status code indicates to the client that the API endpoint or upstream business logic expected to be accessed by the current request is unavailable. The response header may contain custom business headers, and the response body may carry structured error information. By sending the constructed circuit breaker response back to the initiator of the target request, fast failure can be achieved, interrupting the request chain and avoiding additional load on upstream business nodes.

[0045] The above-described implementation scheme of this application, upon receiving the Wasm plugin configuration information generated based on custom circuit breaker resources from the control plane, initializes the loaded Wasm plugin configuration. Based on the Wasm plugin, it identifies target requests that meet routing rules and match circuit breakers from business requests flowing through the target proxy, identifies the current state of the circuit breaker corresponding to the target request, and, based on the state identification, feeds back a circuit breaker response to the initiator of the target request or allows the target request to be passed to the upstream service. Through custom resources and Wasm plugins, non-intrusive route-level circuit breaker protection is achieved, and it has fine-grained control and flexible policy configuration capabilities, meeting the diverse governance needs under complex microservice architectures. Through the automatic distribution and dynamic activation of circuit breaker policies, the governance capabilities of the service mesh infrastructure are enhanced, thereby improving the overall stability, availability, agility, and operational efficiency of the microservice system.

[0046] The process for determining the melting state of a fuse is described below. As an optional embodiment of this application, the method further includes the following steps: For each circuit breaker, based on the monitoring metrics of multiple target requests corresponding to the circuit breaker collected within the sliding statistical time window, it is determined whether the circuit breaker conditions are met. The circuit breaker conditions are defined by the custom circuit breaker resource, carried by the Wasm plugin configuration information, and sent to the Wasm plugin. If the fusing condition is met, the fuse is marked as frozen and the fusing timer is started; After the timeout period is reached, the fuse will be restored to the unfrozen state. The monitoring metrics include at least one of HTTP status codes and request duration; the duration of the sliding statistical time window and the circuit breaker duration are both parameters defined in the custom circuit breaker resource and are sent to the Wasm plugin through the Wasm plugin configuration information. The monitoring metrics within the sliding statistical time window are dynamically updated based on the arrival of new business requests, and trigger a reassessment of whether the circuit breaker conditions are met.

[0047] The target proxy also uses the Wasm plugin to assess the status of circuit breakers. For each circuit breaker, the Wasm plugin collects monitoring metrics for multiple target requests sharing that circuit breaker within a sliding statistical time window. The duration of the sliding statistical time window is defined by a custom circuit breaker resource, such as 10 seconds or 12 seconds. For multiple target requests corresponding to a circuit breaker, each target request is associated with the same circuit breaker because the key attributes (such as the target host and target port) of its generated circuit breaker lookup key are the same. The monitoring metrics for target requests are derived from the response information of upstream services, including at least one of HTTP status codes and request duration. HTTP status codes are used to identify the HTTP layer processing result of the request. Based on the HTTP status code, it can be determined whether the target request has been processed incorrectly; for example, requests with status codes of 5xx (server error) are usually considered errors. Request duration measures the total time elapsed from when the proxy sends a request to when it receives a complete response, and is a key metric for identifying slow calls.

[0048] For each circuit breaker, the Wasm plugin collects monitoring metrics for multiple target requests corresponding to the circuit breaker within a sliding statistics time window. Based on the collected metrics, it determines whether the circuit breaker meets the circuit breaker conditions defined by the custom circuit breaker resource. If the conditions are met, the circuit breaker is marked as open and a circuit breaker timer is started. After the circuit breaker timer expires, the circuit breaker is restored to an open state. The circuit breaker timer is defined by the custom circuit breaker resource and determines how long the circuit breaker will remain open once the circuit breaker is triggered.

[0049] The sliding statistical time window is a dynamically updated time interval. The monitoring indicators within this window are dynamically updated as new business requests arrive. After each new request is processed, the corresponding monitoring indicators are added to the window's statistical range. After each monitoring indicator is updated, the statistical values ​​within the current time window need to be recalculated, and a re-evaluation of whether the circuit breaker conditions are met is triggered, thereby ensuring the timeliness and accuracy of the circuit breaker decision.

[0050] Optionally, when determining whether the circuit breaker condition is met based on monitoring metrics of multiple target requests corresponding to the circuit breaker collected within a sliding statistical time window, the following steps are included: Within the sliding statistical time window, perform at least one of the following steps: Based on HTTP status codes, erroneous target requests are identified, and the erroneous request ratio is calculated based on the number of erroneous target requests and the total number of target requests corresponding to the circuit breaker. The erroneous request ratio is then compared with an error rate threshold. Based on the comparison between request duration and slow call time threshold, slow call target requests whose request duration is greater than the slow call time threshold are identified, and the slow call ratio is calculated based on the number of slow call target requests and the total number of target requests corresponding to the circuit breaker. The slow call ratio is then compared with the slow call rate threshold. Specifically, if the proportion of erroneous requests is greater than or equal to the error rate threshold, and / or the proportion of slow calls is greater than or equal to the slow call rate threshold, the circuit breaker condition is determined to be met.

[0051] If the monitoring metrics include HTTP status codes, then for each target request within the sliding statistical time window, the Wasm plugin identifies errors based on the error identification rules defined in the custom circuit breaker resource (e.g., classifying requests with status codes of 5xx as errors). Finally, all requests identified as errors are combined for calculation to determine whether the circuit breaker conditions are met.

[0052] The number of erroneous target requests identified within the sliding statistical time window is counted. Based on the number of erroneous target requests corresponding to the sliding statistical time window and the total number of target requests corresponding to the circuit breaker within the sliding statistical time window, the erroneous request ratio is calculated and compared with an error rate threshold. The error rate threshold is the threshold for triggering circuit breaking based on the erroneous request ratio within the sliding statistical time window; that is, when the erroneous request ratio reaches or exceeds (is greater than or equal to) the error rate threshold, the circuit breaker trigger condition is determined to be met.

[0053] If the monitoring metric includes request duration, for each target request within the sliding statistical time window, the request duration is compared with a slow call time threshold, which is the critical time value for determining whether a request is executing too slowly. By comparison, target requests with a request duration greater than the slow call time threshold are identified as slow call target requests. Based on the number of slow call target requests within the sliding statistical time window and the total number of target requests corresponding to the circuit breaker within the sliding statistical time window, the slow call ratio is calculated. This slow call ratio is then compared with a slow call rate threshold, which is the minimum ratio required to trigger a slow call circuit breaker. When the slow call ratio is greater than or equal to the slow call rate threshold, the circuit breaker condition is met.

[0054] If the monitoring metrics include request duration and status codes, the slow call ratio and / or error request ratio can be calculated. Circuit breaker conditions can be flexibly defined according to user configuration; that is, they can be triggered in response to one or more of the following conditions: the error request ratio is greater than or equal to the error rate threshold; the slow call ratio is greater than or equal to the slow call rate threshold. Through this flexible judgment logic, the circuit breaker strategy has the ability to govern any dimension, such as service availability (error rate) and service performance (slow calls), and can accurately adapt to complex business scenarios.

[0055] In the aforementioned implementation scheme for determining whether a fuse meets the triggering conditions based on monitoring indicators, monitoring indicators of multiple target requests associated with the fuse are statistically analyzed within a sliding statistical time window. By analyzing the proportion of erroneous requests and / or slow calls based on these monitoring indicators, and comparing the analyzed proportions of erroneous requests and / or slow calls with thresholds, fuses that meet the triggering conditions can be accurately identified, enabling rapid anomaly detection and automatic protection. This dynamic decision-making mechanism based on real-time data effectively avoids the lag of traditional fixed thresholds or manual intervention, ensuring the timeliness and accuracy of triggering decisions.

[0056] The following describes the process of loading the Wasm plugin. When the target proxy loads the Wasm plugin, it performs the following operations: Based on the image address issued by the control plane, pull the Wasm plugin image, extract Wasm bytecode from the Wasm plugin image, load the Wasm bytecode into the Wasm sandbox of the target proxy, and instantiate it into an executable Wasm plugin.

[0057] Based on the image address issued by the control plane to the target agent, the target agent pulls the Wasm plugin image from the container image repository, extracts the Wasm bytecode from the Wasm plugin image, and loads the extracted Wasm bytecode into the target agent's Wasm sandbox, completing the instantiation of the Wasm plugin. The Wasm sandbox, as an independent and secure execution environment, can run in isolation from the target agent's main process, ensuring that the loading and execution of custom code does not affect the stability and security of the agent itself.

[0058] After the instantiation of the Wasm plugin is completed, the target agent initializes the Wasm plugin based on the Wasm plugin configuration information provided by the control plane. This process injects the relevant content defined in the custom circuit breaker resources (such as circuit breaker conditions, duration of sliding statistical time window, circuit breaker duration, etc.) into the plugin instance, completing the full setting of the plugin's business logic and enabling the Wasm plugin to execute route-level circuit breaker decisions.

[0059] In response to a change in the image address, the target agent automatically pulls the Wasm plugin image corresponding to the changed image address and executes a process including loading Wasm bytecode, instantiating the Wasm plugin, and initializing the configuration to update the running Wasm plugin.

[0060] To enable dynamic updates of the circuit breaker logic, this embodiment supports hot updates of running plugins. The control plane monitors for changes in the image address. When the image address changes, the control plane provides the latest image address to the target agent. In response to receiving the latest image address, the target agent automatically pulls the corresponding Wasm plugin image from the container image repository based on the latest image address (the changed image address). It then executes a process of extracting Wasm bytecode from the Wasm plugin image, loading the extracted Wasm bytecode into the target agent's Wasm sandbox to instantiate the Wasm plugin, and performing initial configuration based on the Wasm plugin configuration information. This updates the running Wasm plugin, allowing for seamless updates without restarting the agent.

[0061] The above implementation scheme pulls the Wasm plugin image based on the image address issued by the control plane, extracts Wasm bytecode from the Wasm plugin image and loads it into the Wasm sandbox for plugin instantiation. After plugin instantiation, the target agent initializes the plugin based on the Wasm plugin configuration information, which can realize the dynamic deployment, secure execution and flexible configuration of circuit breaker logic, thereby achieving agile delivery of route-level circuit breaker capabilities without restarting the agent.

[0062] In an optional embodiment of this application, the target agent further performs the following steps via the Wasm plugin: The shared memory of the target agent is divided into N memory buckets. Each memory bucket corresponds to a unique index and is associated with a CAS value for concurrency control. Each memory bucket stores a data list. The data items in the data list include the circuit breaker ID, circuit breaker data and associated timestamp. Calculate the hash value based on the target circuit breaker ID and take the modulo N to determine the index of the target memory bucket; Read the current data list and current CAS value of the target memory bucket; Add a new data item containing the target fuse ID, new fuse data, and the current timestamp to the current data list to generate the updated data list; The updated data list is committed to the target memory bucket using the conditional write mechanism of CAS operation. The circuit breaker data includes configuration data and statistical data generated by aggregation of monitoring indicators within a sliding statistical time window for calculating statistical results. The configuration data originates from custom circuit breaker resources, is carried by the Wasm plugin configuration information and sent to the Wasm plugin, and is stored in a memory bucket by the Wasm plugin.

[0063] like Figure 6As shown, the Wasm plugin organizes the shared memory of the target agent based on a memory bucketing mechanism, dividing the shared memory into N memory buckets (10001 are shown in the figure). Each bucket has a unique index, and the range of the N memory buckets is from index 0 to index N-1 (e.g., from index 0 to index 10000). Each memory bucket is associated with a CAS (compare and swap) value, which is used to implement optimistic locking concurrency control.

[0064] Each circuit breaker corresponds to a unique ID. To locate circuit breaker data, the Wasm plugin hashes the circuit breaker ID to obtain a hash value, then takes the modulo of N based on the hash value. The modulo result determines the memory bucket index corresponding to the circuit breaker, thus identifying the memory bucket to which the circuit breaker belongs. Each memory bucket stores a data list containing data items. Each data item is an array structure, including the circuit breaker ID, circuit breaker data, and associated timestamp. This hash-based bucketing design, by distributing massive amounts of circuit breaker data across a fixed number of memory buckets, achieves deterministic control over the number of shared memory keys (the number of buckets), fundamentally avoiding the risk of "key explosion" caused by the unlimited growth of the number of circuit breakers, while simultaneously optimizing data distribution and access efficiency.

[0065] For data updates of the target fuse (any one of multiple fuses), the Wasm plugin performs the following steps: 1. After determining the target memory bucket based on the target fuse ID (the ID corresponding to the target fuse), read the current data list and the current CAS value of the target memory bucket.

[0066] 2. Add the new data item corresponding to the target fuse (including the target fuse ID, new fuse data and current timestamp) to the current data list to obtain the updated data list.

[0067] 3. Conditional write using CAS operation: Compare the current CAS value of the target memory bucket with the original CAS value at the time of reading. If they match, write the updated data list to the target memory bucket. If they do not match, a concurrency conflict is determined, the write operation is abandoned, and the entire process is retried. The retry process includes: re-executing the reading of the current data list and the current CAS value, generating the updated data list, and performing conditional write using CAS operation.

[0068] The circuit breaker data stored in the memory bucket includes configuration data and statistical data aggregated based on monitoring metrics within a sliding statistical time window, used to calculate statistical results. The configuration data originates from custom circuit breaker resources, is carried by the Wasm plugin configuration information and distributed to the Wasm plugin, which then stores it in the corresponding memory bucket. Configuration data includes parameters such as circuit breaker duration, error rate threshold, slow call rate threshold, sliding statistical time window length, circuit breaker response configuration, and target routing rules. The Wasm plugin configuration information can carry the configuration data for one or more circuit breakers. By storing configuration data in the memory bucket, a stable and consistent policy basis is maintained for circuit breaker operation, ensuring the consistency of configuration across multiple circuit breaker instances when processing requests. The statistical data is aggregated in real-time by the Wasm plugin based on monitoring metrics within the sliding statistical time window, used to calculate key statistical results such as the proportion of incorrect requests and slow calls. The statistical data is dynamically updated with the arrival of new requests, providing accurate real-time data for circuit breaker decisions.

[0069] The step of generating the updated data list also includes: Clean up expired data items in the current data list; where expired data items are those whose timestamps differ from the current time by more than a preset cleanup threshold, and the preset cleanup threshold is not less than the duration corresponding to the sliding statistical time window.

[0070] See also Figure 6 The cleanup operation is integrated into the step of generating the updated data list. That is, the corresponding data list cleanup is performed every time data is updated. This cleanup strategy avoids the additional overhead of separate scheduled cleanup tasks. During data cleanup, the timestamp of each data item is compared with the current time, and data items whose lifespan (the difference between the current time and the timestamp) exceeds a preset cleanup threshold are removed. The preset cleanup threshold defines the maximum lifespan of a data item, and it must be greater than or equal to the duration of the sliding statistical time window to ensure that valid data required for statistical calculations is not prematurely removed. For example, if the duration of the sliding statistical time window is 12 seconds, the preset cleanup threshold should be at least 12 seconds (e.g., set to 30 seconds).

[0071] By automatically removing expired data, we prevent unlimited memory growth and keep the data list in each memory bucket concise and efficient. The setting that synchronizes the cleanup process with data updates can maintain the timeliness of the data. By setting a preset cleanup threshold that is not less than the duration corresponding to the sliding statistical time window, we ensure that statistical calculations are based on data within the effective time range.

[0072] The above mechanism achieves deterministic control of memory usage through hash bucketing and lazy cleanup, eliminating the risk of memory leaks and overflows. Combined with lock-free concurrency control based on CAS, it significantly improves throughput and response speed while ensuring data consistency, providing a controllable, stable and efficient memory management foundation for high-concurrency services.

[0073] The following describes a specific implementation process for the route-level circuit breaker method based on the Wasm plugin provided in this application, such as... Figure 7 As shown: The control plane receives custom circuit breaker resources provided by developers, determines the target agent in the data plane based on the scope defined by the custom circuit breaker resources, generates Wasm plugin configuration information (excluding the scope defined by the custom circuit breaker resources) based on the custom circuit breaker resources, and sends the Wasm plugin configuration information to the target agent in the data plane.

[0074] The target agent pulls the Wasm plugin image from the image address provided by the control plane, extracts the Wasm bytecode from the Wasm plugin image, loads the Wasm bytecode into the Wasm sandbox, and instantiates it into an executable Wasm plugin. The target agent then initializes and configures the Wasm plugin based on the Wasm plugin configuration information provided by the control plane.

[0075] The business requests initiated by the client flow through the target proxy. The target proxy, through the Wasm plugin, identifies the target requests that meet the target routing rules and match the circuit breaker among the business requests flowing through the target proxy. For other business requests that are different from the target requests, they are routed to the upstream service, and the upstream service returns normal business packets to the client.

[0076] For a target request, the Wasm plugin checks the status of its corresponding circuit breaker. If the circuit breaker is in a broken state, the Wasm plugin directly intercepts the target request without routing it to the upstream service, constructs a circuit breaker response, and returns it directly to the client. If the circuit breaker is in an unbroken state, the Wasm plugin routes the target request to the upstream service, which processes the target request and returns a normal business response to the client. Simultaneously, the Wasm plugin collects monitoring metrics for this request (such as HTTP status code, request duration, etc.) and updates these raw metrics in real time to the corresponding circuit breaker data storage area in shared memory. Based on the newly added monitoring metrics, the monitoring metrics within the current sliding statistical time window are recalculated, and the percentage of erroneous requests and / or slow calls is recalculated based on the statistics. The recalculated percentages determine whether the circuit breaker conditions are met, and the results drive dynamic decision-making and maintenance of the circuit breaker status.

[0077] Figure 7In the process shown, developers can flexibly define the scope and content of circuit breaker policies through custom resources, providing highly flexible circuit breaker policy configuration capabilities to meet the diverse governance needs under complex microservice architectures; the circuit breaker logic is implemented based on Wasm plugin technology, without modifying the source code, achieving non-intrusive functional expansion; through unified management and configuration distribution in the control plane, the automated deployment and dynamic updates of circuit breaker policies are realized, taking effect without restarting, greatly improving operational efficiency and agility.

[0078] This application provides a route-level circuit breaker system based on the Wasm plugin, such as... Figure 8 As shown, it includes: a control plane 81 and a data plane 82. The data plane 82 includes multiple agents, and the target agent 821 is the agent among the multiple agents included in the data plane 82 that conforms to the scope defined by the custom circuit breaker resource. The control plane 81 receives custom circuit breaker resources, generates Wasm plugin configuration information based on the custom circuit breaker resources, and sends the Wasm plugin configuration information to the target agent 821. The target agent 821 initializes and configures the loaded Wasm plugin 8211 based on the Wasm plugin configuration information; Wasm plugin 8211 is used for: From the business requests flowing through the target proxy 821, identify the target requests whose routing context attributes match the target routing rules and whose corresponding circuit breakers can be found in the circuit breaker list based on the request attributes. The target routing rules are defined by custom circuit breaker resources, carried by Wasm plugin configuration information, and sent to Wasm plugin 8211. Before the target request is routed to the upstream service, check the current state of the circuit breaker corresponding to the target request; If the circuit breaker corresponding to the target request is in a closed state, a circuit breaker response is sent back to the initiator of the target request; or, if the circuit breaker corresponding to the target request is in an open state, the target request is allowed to proceed to the upstream service.

[0079] Optionally, Wasm plugin 8211 is also used for: For each circuit breaker, based on the monitoring metrics of multiple target requests corresponding to the circuit breaker collected within the sliding statistical time window, it is determined whether the circuit breaker conditions are met. The circuit breaker conditions are defined by the custom circuit breaker resource, carried by the Wasm plugin configuration information, and sent to the Wasm plugin 8211. If the fusing condition is met, the fuse is marked as frozen and the fusing timer is started; After the timeout period is reached, the fuse will be restored to the unfrozen state. The monitoring metrics include at least one of HTTP status codes and request duration; the duration of the sliding statistical time window and the circuit breaker duration are both parameters defined in the custom circuit breaker resource and are sent to the Wasm plugin 8211 through the Wasm plugin configuration information. The monitoring metrics within the sliding statistical time window are dynamically updated based on the arrival of new business requests, and trigger a reassessment of whether the circuit breaker conditions are met.

[0080] Optionally, Wasm plugin 8211 is also used for: Within the sliding statistical time window, perform at least one of the following operations: Based on HTTP status codes, erroneous target requests are identified, and the erroneous request ratio is calculated based on the number of erroneous target requests and the total number of target requests corresponding to the circuit breaker. The erroneous request ratio is then compared with an error rate threshold. Based on the comparison between request duration and slow call time threshold, slow call target requests whose request duration is greater than the slow call time threshold are identified, and the slow call ratio is calculated based on the number of slow call target requests and the total number of target requests corresponding to the circuit breaker. The slow call ratio is then compared with the slow call rate threshold. Specifically, if the proportion of erroneous requests is greater than or equal to the error rate threshold, and / or the proportion of slow calls is greater than or equal to the slow call rate threshold, the circuit breaker condition is determined to be met.

[0081] Optionally, when loading Wasm plugin 821, target proxy 821 is also used for: According to the image address issued by the control plane 81, the Wasm plugin image is pulled, the Wasm bytecode is extracted from the Wasm plugin image, the Wasm bytecode is loaded into the Wasm sandbox of the target agent 821 and instantiated into an executable Wasm plugin 8211.

[0082] Optionally, the target agent 821 is also used for: In response to a change in the image address, the system automatically pulls the Wasm plugin image corresponding to the changed image address and executes a process that includes loading Wasm bytecode, instantiating Wasm plugin 8211, and initializing the configuration to update the running Wasm plugin 8211.

[0083] Optionally, Wasm plugin 8211 is also used for: Obtain the context route attributes added by the target proxy 821 through which the business request flows; Among the business requests flowing through target proxy 821, candidate requests that match the context routing attributes with the target routing rules are identified; Based on the request attributes of the candidate request, find the corresponding circuit breaker in the circuit breaker list; The candidate requests that find the corresponding fuse are identified as the target requests.

[0084] Optionally, Wasm plugin 8211 is also used for: Based on the circuit breaker response configuration, construct a circuit breaker response containing at least one of a specific status code, response header, and response body. The circuit breaker response configuration is defined by a custom circuit breaker resource and sent to Wasm plugin 8211 through Wasm plugin configuration information. The constructed circuit breaker response is fed back to the originating end of the target request.

[0085] Optionally, Wasm plugin 8211 is also used for: The shared memory of the target agent 821 is divided into N memory buckets. Each memory bucket corresponds to a unique index and is associated with a CAS value used for concurrency control. Each memory bucket stores a data list. The data items in the data list include the fuse ID, fuse data and associated timestamp. Calculate the hash value based on the target circuit breaker ID and take the modulo N to determine the index of the target memory bucket; Read the current data list and current CAS value of the target memory bucket; Add a new data item containing the target fuse ID, new fuse data, and the current timestamp to the current data list to generate the updated data list; The updated data list is written to the target memory bucket using a conditional write mechanism that uses CAS operations. The circuit breaker data includes configuration data and statistical data generated by aggregation of monitoring indicators within a sliding statistical time window for calculating statistical results. The configuration data originates from custom circuit breaker resources, is carried by the Wasm plugin configuration information and sent to the Wasm plugin, and is stored in a memory bucket by the Wasm plugin.

[0086] Optionally, Wasm plugin 8211 is also used for: Clean up expired data items in the current data list; where expired data items are those whose timestamps differ from the current time by more than a preset cleanup threshold, and the preset cleanup threshold is not less than the duration corresponding to the sliding statistical time window.

[0087] As the system implementation is basically similar to the method implementation, it is described in a relatively simple way. For relevant details, please refer to the description of the method implementation.

[0088] On the other hand, embodiments of this application also provide an electronic device, including a memory, a processor, a bus, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps in the above-described routing-level circuit breaker method based on the Wasm plugin.

[0089] For example, Figure 9 A schematic diagram of the physical structure of an electronic device is shown.

[0090] like Figure 9 As shown, the electronic device may include a processor 910, a communications interface 920, a memory 930, and a communication bus 940. The processor 910, communications interface 920, and memory 930 communicate with each other via the communication bus 940. The processor 910 can call logical instructions from the memory 930. The processor 910 is used to execute various processes of the routing-level circuit breaker method based on the Wasm plugin in this embodiment of the application, which will not be described in detail here.

[0091] Furthermore, the logical instructions in the aforementioned memory 930 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0092] In another aspect, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps in the above-described routing-level circuit breaker method based on the Wasm plugin.

[0093] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0094] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0095] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A route-level circuit breaker method based on the Wasm plugin, applied to a target proxy in the data plane of a service mesh, characterized in that... The target proxy is a proxy among the multiple proxies included in the data plane that conforms to the scope defined by the custom circuit breaker resource, and the method includes: In response to receiving Wasm plugin configuration information generated based on the custom circuit breaker resource from the control plane, the loaded Wasm plugin is initialized and configured. The target agent performs the following steps through the Wasm plugin: From the business requests flowing through the target proxy, identify the target requests whose routing context attributes match the target routing rules and whose corresponding circuit breakers can be found in the circuit breaker list based on the request attributes. The target routing rules are defined by the custom circuit breaker resource, carried by the Wasm plugin configuration information and sent to the Wasm plugin. Before the target request is routed to the upstream service, check the current state of the circuit breaker corresponding to the target request; If the circuit breaker corresponding to the target request is in a circuit-broken state, a circuit-broken response is sent back to the initiator of the target request; or, if the circuit breaker corresponding to the target request is in an unbroken state, the target request is allowed to proceed to the upstream service.

2. The method according to claim 1, characterized in that, The method further includes: For each circuit breaker, based on the monitoring metrics of multiple target requests corresponding to the circuit breaker collected within the sliding statistical time window, it is determined whether the circuit breaker condition is met. The circuit breaker condition is defined by the custom circuit breaker resource, carried by the Wasm plugin configuration information, and sent to the Wasm plugin. If the aforementioned fusing condition is met, the fuse is marked as in a fusing state, and the fusing timer is started; After the timing period reaches the fuse's tripping duration, the fuse will be restored to its un-fuse state. The monitoring metrics include at least one of HTTP status codes and request duration; the duration of the sliding statistical time window and the circuit breaker duration are both parameters defined in the custom circuit breaker resource and are sent to the Wasm plugin through the Wasm plugin configuration information. The monitoring metrics within the sliding statistical time window are dynamically updated based on the arrival of new service requests, and trigger a reassessment of whether the circuit breaker conditions are met.

3. The method according to claim 2, characterized in that, The determination of whether the circuit breaker condition is met based on monitoring metrics of multiple target requests corresponding to the circuit breaker collected within a sliding statistical time window includes: Within the sliding statistical time window, perform at least one of the following steps: Based on the HTTP status code, erroneous target requests are identified, and the erroneous request ratio is calculated based on the number of erroneous target requests and the total number of target requests corresponding to the circuit breaker, and the erroneous request ratio is compared with an error rate threshold. Based on the comparison between the request duration and the slow call time threshold, slow call target requests whose request duration is greater than the slow call time threshold are identified, and the slow call ratio is calculated based on the number of slow call target requests and the total number of target requests corresponding to the circuit breaker. The slow call ratio is then compared with the slow call rate threshold. If the proportion of erroneous requests is greater than or equal to the error rate threshold, and / or the proportion of slow calls is greater than or equal to the slow call rate threshold, the circuit breaker condition is determined to be met.

4. The method according to any one of claims 1 to 3, characterized in that, When loading the Wasm plugin, the following is included: Based on the image address sent by the control plane, pull the Wasm plugin image; Extract Wasm bytecode from the Wasm plugin image, load the Wasm bytecode into the Wasm sandbox of the target proxy, and instantiate it into an executable Wasm plugin.

5. The method according to claim 4, characterized in that, The method further includes: In response to a change in the image address, the system automatically pulls the Wasm plugin image corresponding to the changed image address and executes a process that includes loading Wasm bytecode, instantiating the Wasm plugin, and initializing the configuration to update the running Wasm plugin.

6. The method according to claim 1, characterized in that, The step of identifying target requests to be monitored from service requests flowing through the target proxy whose routing context attributes match the target routing rules and whose corresponding circuit breakers can be found in the circuit breaker list based on the request attributes includes: Obtain the context routing attributes added by the target proxy through which the business request flows; Among the service requests flowing through the target proxy, candidate requests whose context routing attributes match the target routing rules are identified; Based on the request attributes of the candidate request, the corresponding fuse is searched in the fuse list; The candidate request that finds the corresponding fuse is determined as the target request.

7. The method according to claim 1, characterized in that, The step of sending a circuit breaker response back to the initiating end of the target request includes: Based on the circuit breaker response configuration, a circuit breaker response is constructed that includes at least one of a specific status code, a response header, and a response body. The circuit breaker response configuration is defined by the custom circuit breaker resource and sent to the Wasm plugin through the Wasm plugin configuration information. The constructed circuit breaker response is fed back to the initiator of the target request.

8. The method according to claim 2, characterized in that, The target agent also performs the following steps through the Wasm plugin: The shared memory of the target agent is divided into N memory buckets. Each memory bucket corresponds to a unique index and is associated with a CAS value for concurrency control. Each memory bucket stores a data list. The data items in the data list include the fuse ID, fuse data, and associated timestamp. Calculate the hash value based on the target circuit breaker ID and take the modulo N to determine the index of the target memory bucket; Read the current data list and current CAS value of the target memory bucket; Add a new data item containing the target fuse ID, new fuse data, and the current timestamp to the current data list to generate an updated data list; The updated data list is written to the target memory bucket using a conditional write mechanism based on CAS operations. The circuit breaker data includes configuration data and statistical data generated by aggregating the monitoring indicators within a sliding statistical time window for calculating statistical results. The configuration data originates from the custom circuit breaker resource, is carried by the Wasm plugin configuration information and sent to the Wasm plugin, and is stored in a memory bucket by the Wasm plugin.

9. The method according to claim 8, characterized in that, The step of generating the updated data list also includes: Clean up expired data items in the current data list; wherein, the expired data item is a data item whose timestamp differs from the current time by a preset cleanup threshold, and the preset cleanup threshold is not less than the duration corresponding to the sliding statistical time window.

10. A routing-level circuit breaker system based on the Wasm plugin, characterized in that, include: The control plane and the data plane, wherein the data plane includes multiple agents, and the target agent is the agent among the multiple agents included in the data plane that conforms to the scope defined by the custom circuit breaker resource; The control plane receives custom circuit breaker resources, generates Wasm plugin configuration information based on the custom circuit breaker resources, and sends the Wasm plugin configuration information to the target agent. The target agent initializes the loaded Wasm plugin based on the Wasm plugin configuration information. The Wasm plugin is used for: From the business requests flowing through the target proxy, identify the target requests whose routing context attributes match the target routing rules and whose corresponding circuit breakers can be found in the circuit breaker list based on the request attributes. The target routing rules are defined by the custom circuit breaker resource, carried by the Wasm plugin configuration information and sent to the Wasm plugin. Before the target request is routed to the upstream service, check the current state of the circuit breaker corresponding to the target request; In response to the circuit breaker corresponding to the target request being in a blown state, a circuit breaker response is sent back to the initiator of the target request; Alternatively, in response to the circuit breaker corresponding to the target request being in an unbroken state, the target request is allowed to proceed to the upstream service.

Images