A multi-dimensional index perception and automatic recovery-based multi-channel routing fusing method

Abstract

This invention relates to the field of microservice traffic governance technology, and particularly to a multi-channel routing circuit breaker method based on multi-dimensional metric perception and automatic recovery. The method includes: receiving user requests for channel routing; asynchronously invoking the metric reporting function to generate cached results for each route; and determining an available route pool based on the current circuit breaker status; performing a first circuit breaker determination to determine an initial route from the available route pool; performing whitelist verification on the user; if successful, obtaining the user behavior vector and the status of each initial route; performing a second circuit breaker determination to determine the route to be switched; determining the target call route based on the route to be switched, executing the request, and recording the circuit breaker log. This invention achieves differentiated circuit breaker and intelligent routing in multi-channel scenarios, balancing system stability and user experience.

Description

Technical Field

[0001] This invention relates to the field of microservice traffic governance technology, and in particular to a multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery. Background Technology

[0002] In multi-channel routing systems, multiple backend channels (such as different service instances, third-party interfaces, cloud service providers, etc.) are typically deployed to ensure high availability and stability of services. When a routing failure occurs in a certain channel (such as interface timeout, excessively high error rate, or return of abnormal status codes), the system needs to be able to quickly identify the fault and trigger the circuit breaker mechanism to automatically or manually switch traffic to the backup channel, thereby preventing the fault from spreading and ensuring business continuity.

[0003] Chinese Patent Publication No. CN118524047B discloses a strategy routing implementation method and system for a unified external data platform, responding to target business requests. Based on a dynamic rule configuration algorithm, it collects and extracts feature data from the current business environment, calls the corresponding rule engine to calculate routing rules, updates the target routing rules, and applies them to the request routing decision process to adjust the current routing strategy, generating an intelligent routing strategy. Based on the intelligent routing strategy, it executes the corresponding strategy routing and combines dynamically acquired indicators related to routing channel capabilities to calculate the target channel result that meets business needs. In normal mode, it selects each target channel according to the routing strategy selection algorithm, chooses the optimal channel as the final routing result, executes the third-party service corresponding to the target channel, and provides feedback on business execution status. It also generates a report request result and updates the monitored indicator data, improving the stability and fault tolerance of the unified external data platform service. However, this method has the following problems: in multi-channel service routing scenarios (such as SMS channels, payment gateways, API gateways, etc.), different channel routes have different performance, costs, and stability. Circuit breaking mechanisms typically rely on global statistical metrics for uniform circuit breaking, lacking the fine-grained identification of individual user differences and the ability to dynamically adjust the circuit breaking strategy based on users' service quality tolerance. Furthermore, traditional circuit breakers often employ fixed-duration or simple exponential backoff recovery strategies after a circuit breaker has triggered, making it difficult to balance system protection with user experience.

[0004] Therefore, there is an urgent need for a multi-channel routing circuit breaker method that can sense multi-dimensional indicators, support user-level differentiated circuit breaking, and can automatically recover. Summary of the Invention

[0005] To address this, the present invention provides a multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery, in order to overcome the problem that existing technologies lack multi-dimensional indicator perception, user-level differentiated circuit breaker support, and automatic recovery multi-channel routing circuit breaker methods.

[0006] To achieve the above objectives, this invention provides a multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery, comprising: Receive user requests for channel routing, asynchronously call the metric reporting function based on the requests, generate cached results for each channel route, and determine the available routing pool for each channel route based on the current circuit breaker status of each channel route. The first circuit breaker decision is executed based on the cached results to determine several initial routes from the available route pool, wherein the statistical period of the cached results is determined based on the circuit breaker statistical period. The user who made the request is whitelisted. If the user passes the whitelist verification, the user's behavior vector and the status of each initial route are obtained. Based on the user's behavior vector and the status of each initially selected route, a second circuit breaker determination is performed to determine several routes to be switched. The target call route is determined based on each route to be switched. The user's request for the channel route is executed using the target call route, and the circuit breaker logs of each channel route are recorded for metric reporting.

[0007] Furthermore, the multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery also includes: Based on the first circuit breaker determination, several first circuit breaker routes are determined; The duration of the first circuit breaker for all users is determined based on the cached results of each first circuit breaker route. Based on the second circuit breaker determination, several second circuit breaker routes are determined; The expected workload is determined based on the user's behavior vector, in order to determine the second circuit breaker duration for each second circuit breaker route for the current user.

[0008] Furthermore, the first circuit breaker determination includes: Retrieve the circuit breaker verification configuration table from the configuration center or local cache; The verification parameters for each channel route are calculated based on the cached results of each channel route. Based on the comparison between the verification parameters and the circuit breaker verification configuration table, a number of first circuit breaker routes that meet the first circuit breaker conditions are determined. Based on each of the first circuit breaker routes, several initial routes are determined from the channel routing pool to determine the available routing pool; The circuit breaker thresholds in the circuit breaker verification configuration table include: average time consumption baseline value, time consumption statistics period, time consumption growth threshold, minimum number of requests for time consumption statistics, abnormal statistics period, abnormal request count threshold, minimum number of abnormal requests for statistics, basic automatic recovery time, automatic recovery time increment, maximum number of circuit breakers, and circuit breaker statistics period.

[0009] Furthermore, the asynchronous call to the metric reporting function includes: The call result, exception identifier, and time-consuming data of the request are asynchronously written to a message queue or memory buffer; The background thread updates the statistical indicators of the channel routing within the sliding time window based on the call results, exception identifiers, and time consumption data of each request; wherein the sliding time window corresponding to the statistical indicators is aligned with the circuit breaker statistical period and is used for circuit breaker condition judgment.

[0010] Furthermore, the user behavior vector includes a quality tolerance set, a business tag set, and a compliance and security set; The initial route selection status includes the average request load and the current error rate.

[0011] Furthermore, the first circuit breaker determination also includes abnormal circuit breaker verification, and the abnormal circuit breaker verification trigger condition is: If the average time taken for a single channel route during the abnormal statistical period is greater than the correction value of the average time baseline value, and the number of requests to a single channel route is greater than or equal to the minimum number of requests for the time-taking statistics, then the single channel route is determined to be circuit breaker triggered.

[0012] Furthermore, the statistical period of the cached results is equal to the circuit breaker statistical period; the system maintains a sliding time window with a length equal to the circuit breaker statistical period for each channel route, and asynchronously updates the statistical indicators within the window according to a preset sliding step size; the sliding step size is less than the circuit breaker statistical period.

[0013] Furthermore, the statistical period for the cached results is dynamically distributed through the configuration center and supports independent configuration at the channel routing granularity; the system adaptively adjusts the statistical period based on the historical request frequency of the route. When the request frequency for a route exceeds the first threshold, the statistical period is shortened. When the request frequency for a route is lower than the second threshold, the statistical period is extended. The adjusted statistical period will be used as the new circuit breaker statistical period for subsequent circuit breaker determinations.

[0014] Further, the determination of the target route for switching includes: A matching score is calculated based on the user behavior vector and the routing status of each route to be switched; Select the route with the highest matching score as the target route to invoke; If multiple routes have the same matching score, the routes to be switched will be selected based on either the load balancing strategy or the user tolerance strategy.

[0015] Furthermore, after each route's circuit breaker fails, an automatic recovery mechanism is also included. The number of circuit breakers within the current circuit breaker statistics period is counted. Each time a circuit breaker is triggered, the first circuit breaker duration is determined based on the preset automatic recovery duration and the accumulated duration. For the circuit breaker route determined by the first circuit breaker, the corresponding circuit breaker freeze duration is the first circuit breaker duration; for the circuit breaker route determined by the second circuit breaker, the corresponding circuit breaker freeze duration is the second circuit breaker duration. After the circuit breaker determination is completed, a circuit breaker notification is sent asynchronously and a log is recorded. Before sending the circuit breaker notification, a distributed lock is acquired, and the following operations are performed under the protection of the distributed lock: updating the number of circuit breakers in the current circuit breaker statistics period, calculating the first or second circuit breaker duration for this circuit breaker, and updating the circuit breaker status and freeze expiration time of the corresponding route. After the operation is completed, the distributed lock is released to prevent concurrent requests from modifying the circuit breaker data of the same route at the same time, which may lead to counting errors or inconsistent status. During the first and second circuit breaker durations, the circuit-breaker routes are frozen. After the freeze period expires, the corresponding routes are automatically restored, and the number of circuit breaker events is reset or continues to accumulate for subsequent calculations of the first and second circuit breaker durations. The available route pool includes routes that are in the second circuit breaker duration.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: A two-tiered circuit breaker mechanism balances system stability with personalized user needs. The first circuit breaker decision is based on global channel performance metrics, enabling rapid identification and isolation of channels experiencing systemic failures to prevent the spread of the fault. The second circuit breaker decision is based on user behavior vectors, providing refined circuit breaker protection for core users: for users with low tolerance, the system proactively circuit breaks channels that do not meet their requirements, avoiding low-quality service; for users with high tolerance, unnecessary circuit breaks are reduced, improving channel utilization. These two circuit breaker mechanisms work together to ensure both overall system high availability and differentiated service quality assurance.

[0017] Asynchronous metric reporting and sliding window statistics reduce main process latency and resource consumption. By asynchronously writing call results, latency, and other data to a message queue or memory buffer, background threads use and update sliding window statistics in batches, completely decoupling the data collection required for circuit breaker judgment from the main request chain. Compared to synchronous collection, this invention significantly reduces the impact of the circuit breaker mechanism on request response time while supporting stable metric aggregation in high-concurrency scenarios.

[0018] The whitelist mechanism implements resource tiering and reduces system overhead. The second circuit breaker decision is only made for users on the whitelist; for ordinary users, the initial routing is used directly to complete the request. This tiered protection strategy allows the system to prioritize limited CPU and memory resources for whitelisted users, while maintaining the lightweight operation of the circuit breaker module even with a large number of users.

[0019] The incremental automatic recovery time effectively addresses recurring failures. For the first circuit breaker route, the system uses a cumulative dynamic calculation of the freeze time. This design achieves adaptive circuit breaker operation for unstable channels: a short recovery period is provided for an occasional failure; for repeated failures within the same cycle, the freeze time is gradually extended, avoiding frequent circuit breaker-recovery-re-circuit breaker operations in chronic abnormal states, thereby reducing system turbulence and user disruption.

[0020] Distributed locks ensure the consistency of circuit breaker notifications. When a circuit breaker is triggered, a distributed lock is acquired during asynchronous notification sending to prevent data corruption caused by multiple threads concurrently updating the circuit breaker status or counter for the same route. This mechanism guarantees the accuracy of the number of circuit breakers within the circuit breaker statistics period, thereby ensuring the correctness of the incremental duration formula calculation. Attached Figure Description

[0021] Figure 1 This is a flowchart of the channel routing circuit breaker method of the present invention; Figure 2 This is a schematic diagram of the first circuit breaker determination method of the present invention; Figure 3 This is a flowchart of the whitelist verification process of the present invention; Figure 4 This is a schematic diagram of the branching process for whitelist verification in this invention. Detailed Implementation

[0022] To make the objectives and advantages of the present invention clearer, the present invention will be further described below with reference to embodiments; it should be understood that the specific embodiments described herein are merely for explaining the present invention and are not intended to limit the present invention.

[0023] Preferred embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0024] It should be noted that in the description of this invention, the terms "upper", "lower", "left", "right", "inner", "outer", etc., which indicate directions or positional relationships, are based on the directions or positional relationships shown in the accompanying drawings. This is only for the convenience of description and is not intended to indicate or imply that the device or element must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, it should not be construed as a limitation of this invention.

[0025] Furthermore, it should be noted that, in the description of this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0026] In this specification, unless otherwise expressly stated, the following terms shall have the following meanings: In this specification, a circuit breaker is a fault-tolerant protection mechanism in a distributed system used to prevent service routing avalanche. Its core idea comes from the "fuse" in a power system—when a fault reaches a threshold, the call link is actively "disconnected" to prevent the fault from spreading.

[0027] In this specification, channel route circuit breaking is a special operating state that indicates that the route has exceeded the maximum workload limit threshold, triggering the circuit breaker freezing mechanism. Channel routes that have been circuit broken and frozen can no longer be trusted as currently available routes.

[0028] In multi-channel routing systems, multiple backend channels (such as different service instances, third-party interfaces, cloud service providers, etc.) are typically deployed to ensure high availability and stability of services. When a routing failure occurs in a certain channel (such as interface timeout, excessively high error rate, or return of abnormal status codes), the system needs to be able to quickly identify the fault and trigger the circuit breaker mechanism to automatically or manually switch traffic to the backup channel, thereby preventing the fault from spreading and ensuring business continuity.

[0029] In multi-channel service routing scenarios (such as SMS channels, payment gateways, API gateways, etc.), different channel routes have different performance, costs, and stability. Circuit breaking mechanisms are usually based on global statistical indicators for uniform circuit breaking, lacking fine-grained identification of individual user differences and unable to dynamically adjust the circuit breaking strategy according to the user's service quality tolerance. In addition, traditional circuit breakers usually adopt a fixed duration or simple exponential backoff recovery strategy after the circuit is broken, which makes it difficult to balance system protection and user experience.

[0030] Based on this, the present invention provides a multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery, realizing a two-level circuit breaker determination that balances system stability and user-specific needs. The first circuit breaker determination is based on global channel performance indicators, enabling rapid identification and isolation of channels with overall failures to prevent the spread of faults. The second circuit breaker determination is based on user behavior vectors, providing refined circuit breaker protection for core users: for users with low tolerance, the system proactively circuit breaks channels that do not meet their requirements to avoid low-quality service; for users with high tolerance, unnecessary circuit breaking is reduced to improve channel utilization. The two circuit breaker mechanisms work together to ensure both overall system high availability and differentiated service quality assurance.

[0031] This invention enables asynchronous metric reporting and sliding window statistics, reducing main process latency and resource consumption. By asynchronously writing call results, latency, and other data to a message queue or memory buffer, background threads can use and update sliding window statistics in batches, completely decoupling the data collection required for circuit breaker judgment from the main request chain. Compared to synchronous collection, this invention significantly reduces the impact of the circuit breaker mechanism on request response time while supporting stable metric aggregation in high-concurrency scenarios.

[0032] A whitelist mechanism is implemented to achieve resource tiering and reduce system overhead. The second circuit breaker decision is only executed for users on the whitelist; for ordinary users, the initial route is used directly to complete the request. This tiered protection strategy allows the system to prioritize limited CPU and memory resources for whitelisted users, while maintaining the lightweight operation of the circuit breaker module even with a large number of users.

[0033] The system implements an incremental automatic recovery time to effectively address recurring failures. For the first circuit breaker route, the system uses a cumulative dynamic calculation of the freeze time. This design achieves adaptive circuit breaker operation for unstable channels: a short recovery period is provided for an occasional failure; for repeated failures within the same cycle, the freeze time is gradually extended, avoiding frequent circuit breaker-recovery-re-circuit breaker operations in chronic abnormal states, thereby reducing system turbulence and user disruption.

[0034] This invention ensures the consistency of circuit breaker notifications through a distributed lock. When a circuit breaker is triggered, a distributed lock is acquired during asynchronous notification sending to prevent data corruption caused by multiple threads concurrently updating the circuit breaker status or counter of the same route. This mechanism guarantees the accuracy of the number of circuit breakers within the circuit breaker statistics period, thereby ensuring the correctness of the calculation of the incrementing duration formula.

[0035] Please see the appendix Figure 1 This is a flowchart of the channel routing circuit breaker method of the present invention; A multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery includes the following steps: Step S1: Receive user requests for channel routing, asynchronously call the metric reporting function based on the requests, generate cached results for each channel route, and determine the available routing pool for each channel route based on the current circuit breaker status of each channel route. Step S2: Perform the first circuit breaker determination based on the cached results to determine several initial routes from the available route pool, wherein the statistical period of the cached results is determined based on the circuit breaker statistical period; Step S3: Perform whitelist verification on the user who made the request; Step S4: Obtain the user's behavior vector and the status of each initially selected route; Step S5: Based on the user's behavior vector and the status of each initially selected route, perform a second circuit breaker determination to determine several routes to be switched; Step S6: Determine the target call route based on each route to be switched, use the target call route to execute the user's request for the channel route, and record the circuit breaker logs of each channel route for metric reporting; Step S7: Automatic recovery mechanism and circuit breaker notification.

[0036] In this embodiment, step S1: receive the user's request for channel routing, asynchronously call the indicator reporting function based on the request, generate the cached results of each channel route, and determine the available routing pool of the channel route based on the current circuit breaker status of each channel route. Specifically, the process of receiving requests and asynchronously reporting metrics includes: the gateway receiving channel routing requests initiated by users and parsing the user identifier (user_id) and target channel identifier (channel_id) carried in the request header. Outside the main request processing flow, the metric reporting function is asynchronously invoked, writing data such as whether the call was abnormal (is_error), the call time (cost_time), and the call result (result_code) for each request to a message queue or memory buffer. A background thread uses this data in batches to update the statistical metrics within the sliding time window based on the channel identifier. The sliding window size of the statistical metrics is aligned with the circuit breaker statistical period for subsequent circuit breaker condition judgment.

[0037] The aggregated statistics from the aforementioned sliding window are periodically or actively fetched and written to a local cache (such as Caffeine or Guava Cache) or a distributed cache (such as Redis) to generate cached results. The core purpose of the cached results is to allow the circuit breaker decision-making module to read them quickly, avoiding the need to recalculate the original logs for each decision.

[0038] Specifically, the data structure for cached results typically includes: Route identifier (channel_id); The start and end times of the statistical period; the total number of requests within the window (total_requests); The number of abnormal requests within the window (error_requests); Average latency within the window (avg_latency); Standard deviation of latency within the window (std_latency); Consecutive failures (number of consecutive failures within the window); Last updated timestamp.

[0039] The lifecycle of cached results is tied to the circuit breaker statistics period: whenever the current time crosses a sliding step, the system asynchronously updates the statistics in the cache. For routes with no requests for a long time, the cached results will naturally decay (or be reset to the initial value), avoiding outdated data from misleading circuit breaker decisions.

[0040] Specifically, the statistical period for cached results is determined based on the circuit breaker statistical period. Each channel route maintains an independent sliding time window, the length of which is the circuit breaker statistical period T (in this embodiment, the initial value is T = 300 seconds). To ensure smooth statistical updates, the window is evenly divided into K consecutive sub-windows (or "buckets"), and the duration of each sub-window is the sliding step size Δt = T / K (in this embodiment, K = 30, so Δt = 10 seconds). The system drives the window sliding with a period of Δt. Every Δt time interval, the current timestamp moves to the next sub-window, and the system asynchronously triggers a cache update: discarding the oldest sub-window statistics, incorporating the latest sub-window data, and re-aggregating the metrics (total number of requests, average time taken, number of exceptions, etc.) from all K sub-windows to generate a new cache result.

[0041] For routes that have been inactive for a long time, the statistical values ​​corresponding to each sub-window gradually become zero, and the average value of the sliding window naturally decays.

[0042] The system maintains a current circuit breaker state machine for each channel route, which includes at least the following three states: Closed state: The route is in normal working state and can receive and process requests.

[0043] Global Circuit Breaker Status (OPEN_GLOBAL): This route is frozen due to triggering the first circuit breaker (global performance metrics exceeding limits), and is unavailable to all users. The freeze duration is calculated using an incremental formula.

[0044] User-level circuit breaker status (OPEN_USER): This route is frozen due to triggering the second circuit breaker criterion (failure to meet the behavior vector of a specific user). It is unavailable only to the specific user, while other users can still use it normally. The freeze duration is calculated based on personalized parameters such as the user's expected workload.

[0045] In some embodiments, a half-open state (HALF_OPEN) can also be set for detection and recovery after the circuit breaker freeze period expires. In this embodiment, the processing is simplified by directly recovering after the freeze period expires, but the supplementary implementation of the half-open state is not excluded.

[0046] When performing the "Determine the available route pool for channel routing" operation, the system filters according to the following rules: Exclude routes with global circuit breaker: Iterate through all channel routes managed by the system. If a route is currently in a global circuit breaker state (i.e., within the freeze period of the first circuit breaker type), then directly exclude the route from the available route pool. Such routes are unavailable to all users until the freeze period expires and they automatically return to the closed state.

[0047] Temporarily retain user-level circuit breaker routes: Routes in the user-level circuit breaker state (within the freeze period of the second circuit breaker type) are not directly excluded when building the fully available route pool because they are only unavailable to specific users but still available to other users. They will be excluded for that specific user after the whitelist verification is passed and the behavior vector of the specific user is obtained, at the second circuit breaker determination stage.

[0048] Retain normal routes: Routes in the closed (normal) state are unconditionally added to the available route pool.

[0049] In some embodiments, optional health pre-checks can be performed: in addition to circuit breaker status, the system can also perform pre-filtering based on basic health checks of routes, such as using heartbeat probes to pre-filter basic health checks of routes. If a route is in a closed circuit breaker state but the number of consecutive heartbeat failures exceeds a threshold, it is temporarily considered unavailable and excluded to prevent routes that have actually failed but have not yet triggered circuit breaker from being included in the pool.

[0050] Through the above filtering process, the system obtains an initial pool of available routes. This pool serves as input for the first circuit breaker determination, and subsequently, failed routes determined in the first circuit breaker determination are removed from it to obtain the initial selected routes.

[0051] In some embodiments, a dynamic update mechanism is also included: the available route pool is not statically generated, but dynamically calculated in real time based on the current circuit breaker status of each route (including the remaining circuit breaker duration and whether it has been restored) each time a request arrives. Changes in the circuit breaker status (such as automatic recovery upon expiration of the freeze period) are triggered through background scheduled tasks or event listening mechanisms to ensure the accuracy of the available route pool.

[0052] In this embodiment, step S2: perform a first circuit breaker determination based on the cached results to determine a number of initial routes from the available route pool, wherein the statistical period of the cached results is determined based on the circuit breaker statistical period; Please see the appendix Figure 2 This is a schematic diagram of the first circuit breaking determination of the present invention; The first circuit breaker determination is a global circuit breaker detection mechanism based on the channel's own real-time performance indicators. Its purpose is to quickly identify and isolate channel routes that show significant performance degradation (such as a surge in average latency or frequent abnormal requests) within the statistical period, preventing these degraded routes from affecting the request quality of all users.

[0053] Specifically, the inputs for this determination include: Available route pool (obtained by filtering based on the current circuit breaker status of each route in step S1); The cached results for each route are the statistical aggregated data within the sliding time window (such as average time consumption, number of abnormal requests, total number of requests, etc.). Circuit breaker verification configuration table (obtained from configuration center or local cache).

[0054] The output is the initial set of routes, which is the remaining routes after removing the first circuit breaker route from the available route pool.

[0055] Obtaining the circuit breaker verification configuration table for the initial route set includes: the system retrieves the corresponding circuit breaker verification configuration table from the configuration center or local cache based on the cached results.

[0056] Please refer to Table 1, which is the circuit breaker verification configuration table of this invention. Different users or different channel routes correspond to different circuit breaker verification configuration tables, thereby realizing differentiated circuit breaker strategies at the user level.

[0057] Table 1. Fuse verification configuration table of the present invention ; Based on the user name and product identifier, retrieve the corresponding circuit breaker verification configuration table from the configuration center or local cache; the circuit breaker verification configuration table shall contain at least the following fields: average time consumption baseline value, time consumption statistics period, time consumption growth threshold, minimum number of requests for time consumption statistics, abnormal statistics period, abnormal request count threshold, minimum number of requests for abnormal statistics, basic automatic recovery time, automatic recovery time increment, maximum number of circuit breakers, and circuit breaker statistics period.

[0058] It is understood that the default values ​​for each value in the table are determined based on the actual situation, and the values ​​in this embodiment are only for a specific embodiment.

[0059] In some embodiments, multiple detection time windows of the indicators in the circuit breaker verification configuration table are obtained based on the circuit breaker strategy, and the call indicator records within the window are obtained sequentially.

[0060] Specifically, based on the obtained circuit breaker verification configuration table, the system performs the first circuit breaker determination.

[0061] Based on the baseline value of average time consumption and the time consumption growth threshold, the correction value of the baseline value of average time consumption is determined, and the correction value of the baseline value of average time consumption is calculated according to the following formula: Correction value of average time baseline = Average time baseline value (1 + time consumption growth threshold); The time consumption growth threshold is a set value. For core channels, a lower threshold, such as 10%, can be set to detect performance degradation earlier; for non-core channels, a higher threshold, such as 50%, can be set to avoid overly sensitive circuit breakers. Preferably, the time consumption growth threshold ranges from 10% to 50%, which can be selected according to the specific scenario requirements, and will not be elaborated further here.

[0062] A multi-time-window sequential verification method is adopted to obtain the call indicator records of each indicator in the configuration table within multiple detection time windows. The first circuit breaker determination includes two mechanisms: abnormal circuit breaker verification and time consumption verification, with abnormal circuit breaker verification having higher priority than time consumption verification.

[0063] The trigger condition for abnormal circuit breaker verification is that any one of the following conditions must be met: (1) The average time consumed during the abnormal statistical period is greater than the average time baseline value. (1 + the time consumption growth threshold) and the number of requests ≥ the minimum number of requests for time consumption statistics; (2) The number of abnormal requests within the abnormal statistical period is greater than the number of abnormal requests.

[0064] If both conditions are met, the routing circuit breaker will be triggered.

[0065] The trigger condition for time-consuming verification is: the number of requests within the anomaly statistics period is greater than or equal to the minimum number of requests in the anomaly statistics. In this case, circuit breaking is not triggered, and the anomaly circuit breaking verification process begins.

[0066] Understandably, the average time is based on the average time required for each request to be received and completed within the statistical window.

[0067] Specifically, after traversing all available routes, the system determines several initial routes based on routes that are not marked as the first circuit breaker route. The first circuit breaker route will have its first circuit breaker duration calculated in the subsequent automatic recovery mechanism (step S7) and will enter a global freeze state, which will take effect immediately for all users.

[0068] The determined initial routes will be passed to step S3. For users who fail the whitelist verification, the system will directly select a target route from the initial routes; for users who pass the whitelist verification, the system will also input the initial routes along with the user behavior vector into the second circuit breaker decision (step S5) for more refined personalized filtering.

[0069] Step S3: Perform whitelist verification on the user who made the request; Since the second circuit breaker determination (user-level personalized circuit breaker) requires obtaining user behavior vectors and calculating matching scores with the states of each initial route, these operations involve additional memory access, vector computation, and even remote calls. Performing these operations on all users would significantly increase system resource consumption. In actual production environments, whitelisted users (such as paid VIPs, core enterprise customers, and high-frequency callers) typically only account for a small portion (5%–20%) of all users. Therefore, this invention uses a whitelist mechanism to limit the refined second circuit breaker determination to users within the whitelist, while for ordinary users, only the first circuit breaker determination (global performance circuit breaker) is performed, and the target route is directly selected from the initial routes (this embodiment uses simple round-robin or least connections), thereby significantly reducing system overhead while ensuring a core user experience. It is understood that the list of users in the whitelist can be predefined according to actual scenario needs, which will not be elaborated here.

[0070] The whitelist cache includes the following fields, please refer to Table 2.

[0071] Table 2 Whitelist Cache Fields Table ; The whitelist can be configured at multiple granularities: it can be at the "user-route" level (i.e., specifying that a user enables the second circuit breaker only for a specific route) or at the user level (i.e., the user enables the second circuit breaker for all routes). This embodiment uses a user-level whitelist (i.e., the whitelist only stores the user identifier, indicating that the user needs to accept the second circuit breaker decision).

[0072] Please see the appendix Figure 3 This is a flowchart of the whitelist verification process of the present invention; The whitelist verification process includes the following steps: S3.1 Extract User Information: Parse the user's unique identifier, user_id, from the user request received in step S1. If the request does not carry a valid user identifier (e.g., anonymous access), it is considered a non-whitelisted user by default, and the second circuit breaker decision is skipped.

[0073] S3.2 Querying the Whitelist Cache: The system maintains a high-speed whitelist cache, typically implemented using a local cache (such as Caffeine or Guava Cache) or a distributed cache (such as Redis) to support low-latency (sub-millisecond) verification. The verification process is as follows: using user_id as the key, perform a containsKey or get operation in the whitelist cache. If a corresponding valid entry exists, the user is considered to have passed the whitelist verification; otherwise, the user is considered to have failed the whitelist verification.

[0074] S3.3 Branching: Please see the appendix Figure 4 This is a schematic diagram of the branch processing of whitelist verification in this invention; Scenario 1: The user failed the whitelist verification. The system skips the second circuit breaker decision and directly uses the set of preliminary routes obtained in step S2, selecting a target from these routes to invoke the route. The selection strategy could be: Lowest load (minimum number of connections or minimum average latency); Round Robin; random; The default route.

[0075] Meanwhile, the system will still record the call log of this request, which will be used to update the indicators for the first circuit breaker determination, ensuring that the global circuit breaker still applies to all users.

[0076] Scenario 2: Users enter a more refined second circuit breaker decision process through the whitelist verification system, namely, executing step S4 and subsequent steps (obtaining user behavior vectors and the status of each initially selected route, performing the second circuit breaker decision, determining the route to be switched, etc.). Whitelisted users will enjoy intelligent route selection based on their personalized tolerance and the real-time status of the routes.

[0077] S3.4 Dynamic Update Mechanism for Whitelist Caching: To ensure the real-time nature and configurability of the whitelist, the system dynamically updates the whitelist cache by subscribing to change events from configuration centers (such as Nacos, Apollo, and ZooKeeper), without requiring service restarts. Specifically, this includes: Configuration Center Storage: Whitelist data is stored in the configuration center in the form of configuration files or database tables, supporting CRUD operations. Operations personnel can dynamically adjust the whitelist through the management interface (e.g., adding new VIP users, removing expired test accounts).

[0078] Change event push: When whitelist data changes, the configuration center pushes the change event to all service instances via a long-lived connection (such as gRPC stream) or a message broker (such as Kafka). The event content typically includes the change type (ADD / UPDATE / DELETE) and the affected whitelist entries.

[0079] Local cache update: Each service instance registers a listener upon startup. Upon receiving a change event, the listener thread immediately updates the local whitelist cache (e.g., adding a new user, deleting an expired user, or modifying the expiration date). To ensure cache consistency under high concurrency, read-write locks or atomic reference techniques can be used, making the verification thread almost unblocked.

[0080] In some embodiments, a periodic full refresh may also be included: In order to prevent event loss due to network problems, the system may also set a scheduled task (such as every 5 minutes) to pull the whitelist data from the configuration center once as a backup synchronization mechanism.

[0081] Whitelist verification relies on several initial route sets generated in step S2. If step S2 results in several initial route sets being empty due to all routes being removed by the first circuit breaker decision, the system needs to execute a degradation strategy (e.g., return an error or use a preset backup route) regardless of whether the user is in the whitelist. This step can add an empty set check: if several initial route sets are empty, return an error or degradation response directly, and no longer perform whitelist verification.

[0082] Once the user passes the whitelist verification, step S3 transfers control to step S4 and transmits the current user's user_id and several initial route sets for subsequent use in obtaining behavior vectors and initial route status.

[0083] Whitelist caching typically stores thousands of user identifiers, so it can be implemented using high-performance caching methods such as ConcurrentHashMap or Caffeine.

[0084] For distributed deployments, each instance independently maintains a local whitelist cache and maintains eventual consistency through configuration center events. This approach avoids remotely calling the configuration center for every request, resulting in extremely low latency (typically in the microsecond range).

[0085] For very large user bases (such as whitelists of millions), a Bloom filter can be used as a pre-filter to quickly determine whether a user is "likely" in the whitelist. If "likely," then the exact cache can be checked. However, whitelists are usually small, so a Bloom filter is not always necessary.

[0086] Step S4: Obtain the user's behavior vector and the status of each initially selected route; In step S3, the user passed the whitelist verification, indicating that the user needs to undergo a more refined second circuit breaker decision. Step S4 is responsible for collecting two types of key data: user behavior vector U, which includes three subsets—quality tolerance set Q, business tag set B, and compliance and security set C.

[0087] Initial route state Ri: For each initial route i∈R_primary, obtain its real-time average request load Li and current error rate Ei. R_primary is the set of initial routes.

[0088] Input: User ID user_id, a set of initial routes R_primary={r1,r2,...,rm}.

[0089] Output: User behavior vector U, and initial route state mapping {ri↦(Li,Ei)}.

[0090] The construction and acquisition of user behavior vectors includes the following steps: The user behavior vector U=(Q,B,C) is defined as follows: Quality tolerance set Q: The quality tolerance set describes the acceptable range of service quality (latency, error rate, etc.) for users. In this embodiment, Q includes the following three numerical parameters: When a whitelisted user participates in the second circuit breaker decision, the t in their behavior vector... latency (Average time tolerance) and e error The error rate tolerance is determined using a dynamic learning approach to adapt to the actual usage characteristics and changing trends of different users.

[0091] The system continuously records the historical request logs for each whitelisted user. Each log entry includes at least the request time, success status, and call timestamp. The data is aggregated at an hourly granularity and stored in a time-series database or user profiling platform.

[0092] Average time tolerance t latency (Unit: milliseconds): The maximum average response time acceptable to the user.

[0093] The system analyzes the time distribution of all successful requests made by a user over a past statistical period (e.g., the last 7 days) and selects the P90 (90th percentile) as the user's time tolerance. The calculation formula is as follows: ; Among them, {dk|status k=success} represents the set of times taken for successful user requests, and Q90 represents the 90th percentile. P90 is chosen instead of the average or maximum value to exclude the influence of extreme outliers while covering the time range of the vast majority of normal requests. If the number of historical successful user requests is less than the minimum statistical sample size (e.g., less than 100), the system's global default value is used; in this embodiment, the default value is 2000ms.

[0094] Error rate tolerance e error (Value range [0,1]): The maximum percentage of failed requests that the user can accept.

[0095] The system calculates the natural failure rate (rfail) of user requests within the same statistical period (the average failure rate under normal fluctuations). To avoid artificially low values ​​due to short-term fluctuations, a weighted moving average method is used to smooth historical data. Then, the natural failure rate is multiplied by a leniency coefficient α (α=2 in this embodiment), and a maximum tolerance limit Emax (10% in this embodiment) is set to prevent excessive tolerance from negating the purpose of circuit breaker protection. The formula is as follows: ; Where SMA(rfail) is the simple moving average failure rate over the past N days (7 days in this example). Both α and Emax can be dynamically adjusted through the configuration center. If the total number of historical requests from a user is less than the minimum sample size (e.g., less than 200 times), then e... error Use the system's global default value (0.05, or 5%, in this example).

[0096] Minimum statistical base n for request volume min (Positive integer): The minimum number of requests required to determine whether the statistical significance is met. In this embodiment, the default value is 10.

[0097] Q can be obtained from the user profile service or configuration using the following formula: ; If the user has not configured any tolerance, the system default value will be used. In this embodiment, we take... =3000ms =0.1, (def)=10.

[0098] Regular updates: The system is set to perform a scheduled task (in this example, 2:00 AM daily) to recalculate the tolerance levels of all whitelisted users.

[0099] Event trigger: When a user actively adjusts their preferences on the client interface (such as selecting "more concerned about speed" or "more concerned about success rate" on the slider), or when the customer service system enters a user complaint, the system immediately triggers a recalculation and cache update.

[0100] Cold Start and New Users: For newly added users with insufficient historical data, the global default tolerance will be used first; after enough data is accumulated, it will automatically switch to a dynamic value for the next scheduled task.

[0101] Business Tag Set B describes the business context of the user's current request and is used for subsequent filtering of compliant routes. B includes: Business type b type ∈{sms,payment,query,…}: Determines which channels can be selected (e.g., payment requests can only go through channels with payment licenses). Here, sms, payment, and query are all definitions of business types. For example, payment is the payment type. This is a technology that is easy to understand in this field and will not be elaborated here.

[0102] Request priority b priority ∈{1,2,3,4,5}: Higher values ​​indicate more important requests and greater sensitivity to circuit breaker switching. Priority b priority The value can be predefined in the user information, which will not be elaborated here.

[0103] Data sensitivity b sensitive ∈{low,medium,high}: When privacy or financial data is involved, only channels meeting the security level are allowed. Similarly, its value can be predefined in the user information, which will not be elaborated further.

[0104] Business tag set B: Usually obtained directly from request headers, user sessions or business systems, without the need for additional calculation.

[0105] Compliance and security set C: The compliance and security set describes user requirements regarding data processing location, encryption strength, etc. C includes: Compliance Area C region : Strings such as "CN", "US", "EU" indicate that user data must be stored or processed within this region.

[0106] Minimum security level c security ∈{L1,L2,L3}: L1 represents basic security, and L3 represents the highest level of security (such as PCI-DSS certification). The compliant security set is typically read from user contracts or enterprise attributes and cached locally.

[0107] Specifically, the process of obtaining user behavior vectors is as follows: If the local cache (such as Caffeine) is queried based on the user_id, and a match is found and the cache has not expired (30 seconds in this example), the cache is returned directly.

[0108] The user profiling microservice (RPC / HTTP) is invoked to retrieve the specific values ​​of Q, B, and C mentioned above. If the service times out or returns empty, the default values ​​for the user are retrieved from the configuration center. If there is no record in the configuration center either, the user behavior vector U is constructed using the system default values. The result is written to the local cache, an expiration time is set (60 seconds in this example), and then returned.

[0109] The formulas for obtaining and calculating the initial route selection status include: Initial route selection state for each r i For ∈R_primary, the average request load Li and the current error rate Ei need to be calculated. Both of these metrics are calculated based on the sliding window statistics maintained in step S1. The length of the sliding window is denoted as T (i.e., the circuit breaker statistical period, which is set to 300 seconds in this embodiment). The window is divided into K equal-length sub-windows (also called buckets), and the length of each bucket is Δ=T / K (in this embodiment, K=30, and each bucket is 10 seconds).

[0110] Request average load (Li) is defined as the average request rate (requests / minute) per unit time (e.g., 1 minute) within the current sliding window. Its calculation formula is: ; Among them: total_requests i For route r i The total number of requests within the current sliding window (obtained by accumulating asynchronous reports).

[0111] window_length_minutes=T / 60, in minutes.

[0112] If a smoother instantaneous load is required, the number of requests in the most recent full bucket (i.e., the most recent Δ second) can be directly divided by Δ and then multiplied by 60. However, this embodiment recommends using the full window average to reduce random fluctuations.

[0113] The current error rate Ei is defined as the proportion of the number of abnormal requests within the sliding window to the total number of requests: ; in: error_requests i This represents the number of requests that route ri has been marked as exceptions (timeout, service failure, network error, etc.) within the current sliding window.

[0114] total_requests i This represents the total number of requests within the window.

[0115] ϵ is a very small positive number (in this example, it is taken as 10). −6This prevents the denominator from being zero when the total number of requests is zero.

[0116] When there are no requests in the window, Ei is defined as 0 (indicating unknown, considered healthy). The value range is [0,1], for example, Ei=0.02 means that 2% of requests failed.

[0117] Step S5: Based on the user's behavior vector and the status of each initially selected route, perform a second circuit breaker determination to determine several routes to be switched; The second circuit breaker decision is a user-level, personalized circuit breaker decision mechanism. Its purpose is to further eliminate routes from the initial set of routes R_primary that, although they passed the global first circuit breaker decision, are unacceptable under the current user's service quality tolerance or business compliance requirements. The routes remaining after the second circuit breaker decision are called the set of routes to be switched, R_candidate, which will be used for the final target route matching (step S6).

[0118] Specifically, the input is a user behavior vector U=(Q,B,C). Where: Q=(t) latency ,e error ,n min — A set of quality tolerances (time tolerance, error rate tolerance, minimum statistical base); B=(b type ,b priority ,b sensitive —A collection of business tags; C=(c region ,c security — Compliance and security set.

[0119] Initial route state mapping Map<channel_id,(Li,Ei)> , where Li is the average request load (requests / minute) and Ei is the current error rate (0 to 1).

[0120] Output: The set of routes to be switched is R_candidate⊆R_primary.

[0121] The second circuit breaker determination consists of three parts, which are executed sequentially according to priority: First, compliance and security filtering is performed: based on the user compliance and security set C and the business tag set B, routes that do not meet the requirements of data region, security level or business type are excluded.

[0122] Then, error rate circuit breaking is implemented: based on the user's error rate tolerance e. error Based on the current error rate Ei of the route, exclude routes with excessively high error rates.

[0123] Finally, perform time-consuming fusing: based on the user's time-consuming tolerance t latency and the average time-consuming of the route (the average time-consuming is not directly included in the current primary-selected route status and needs to be supplemented from the cache result), exclude the routes whose average time-consuming exceeds the tolerance.

[0124] If any rule is triggered, mark this route as the second-fused route (i.e., perform user-level fusing for this user) and remove it from R_primary. If all rules are not triggered, the route remains in R_candidate.

[0125] Compliance and security filtering (highest priority) For a certain route r_i in the primary-selected routes, the system first checks whether its static metadata (which can be pre-cached in the route configuration table) meets the user's compliance, security, and business constraints.

[0126] Define the region where the data center of the route r_i belongs as region_i (such as "CN", "US", "EU"). If region_i ≠ c_region, then this route does not meet the compliance requirements, mark this route as the second-fused route and remove it.

[0127] Define the security level supported by the route r_i as security_i (for example, "L2"). If security_i is lower than the minimum security level c_security required by the user (such as the numerical comparison of L1 < L2 < L3), then mark this route as the second-fused route and remove the route.

[0128] Define the set of business types supported by the route r_i as types_i (for example, {sms, payment}). If the business type b_type requested by the user is not in types_i, then mark this route as the second-fused route and remove the route.

[0129] After passing the compliance and security filtering, the system checks whether the current error rate Ei of the route exceeds the user's tolerance.

[0130] To avoid distortion of the error rate caused by too few requests, the system needs to judge the total number of requests total_requests of the route r_i within the current sliding window i whether it reaches the minimum statistical base n min (from the set of quality tolerances Q).

[0131] If total_requests i < n min , it is considered that the data is insufficient and the error rate fusing is not triggered (the route is retained).

[0132] If total_requests i ≥ nmin Then, an error rate comparison is performed, and the error rate circuit breaker is triggered when Ei > e. error Where e error The user's error rate tolerance is set, for example, 0.02 represents 2%. Once triggered, the route is marked as the second circuit breaker route.

[0133] The time-consuming circuit breaker assesses whether the response time of the evaluated routes meets user expectations. The current status of several initially selected routes includes the average request load Li and error rate Ei, but not the average latency. Therefore, in step S5, the system needs to additionally read the current average latency avg_latency for each route from the cached results of step S1. i (millisecond).

[0134] The minimum statistical cardinality requirement must also be met: total_requests i ≥n min If the conditions are not met, skip the timed circuit breaker. The trigger condition for the timed circuit breaker is: avg_latency i >t_latency. Where t_latency is the user's average latency tolerance (milliseconds). If the condition is met, the route is marked as the second circuit breaker route.

[0135] After the above three layers of filtering, the initial routes that are not marked as the second circuit breaker route constitute the set of routes to be switched.

[0136] If R_candidate is an empty set, it means that none of the initially selected routes meet the user's quality or compliance requirements. In this case, the system should not return failure directly, but should adopt a degradation strategy: Option 1: Fall back to the initial route R_primary after the first circuit breaker decision, and select the route with the lowest load as the target route (ignoring user-level tolerance).

[0137] Option 2: Return the default error response (e.g., 500) and log the alarm.

[0138] This embodiment prioritizes Scheme 1 to ensure usability.

[0139] If R_primary itself is empty (i.e., the first circuit breaker decision has removed all routes), then step S5 is skipped directly, and the system enters global degradation (e.g., using the preset backup channel).

[0140] The static metadata of the route (region, security level, supported service types) should be loaded into the local cache at system startup to avoid reading the database every time a decision is made. (Average latency: avg_latency) iThe result can be directly obtained from the cached result of step S1, without the need for repeated calculation. For scenarios with a large number of initial route selections and a large user whitelist, the second circuit breaker determination can be performed in parallel.

[0141] Step S6: Determine the target call route based on each route to be switched, execute the user's request for the channel route using the target call route, and record the circuit breaker logs of each channel route for metric reporting; The objective is to select an optimal route from the set of routes to be switched R_candidate obtained in step S5, based on the user behavior vector and route status data, as the target call route, then send the current user request through this route, and finally record the call result and circuit breaker-related logs for subsequent metric reporting and circuit breaker status updates.

[0142] Specifically, in order to select the best route from the routes to be switched, the system calculates a matching score for each ri∈R_candidate. i A higher score indicates that the route better meets the user's current needs. The scoring function comprehensively considers factors such as the user's quality tolerance, the route's real-time load and error rate, and business priority. This embodiment uses the following weighted addition model: ; Where: w L ,w E ,w T ,w P The weighting coefficients are configurable and satisfy w L +w E +w T +w P =1, the default value in this embodiment is set to w L =0.2,w E =0.3,w T =0.4,w P =0.1.

[0143] f L (Li) is the load scoring function; the lower the load, the higher the score. It is defined as: ; Wherein, α is the load sensitivity coefficient (in this embodiment, α = 0.001, and Li is in units of "times / minute").

[0144] f E (E i () is an error rate scoring function; the lower the error rate, the higher the score. It is defined as: ; f E (Ei) takes values ​​in the range [0,1].

[0145] f T (avg_latency i ) is a time consumption rating function, based on the user's time consumption tolerance t. latency Normalize: f T (avg_latency i )=max(0,1- ); That is, when the average latency exceeds the user's tolerance, the score is 0 (step S5 has already removed routes with average latency exceeding the tolerance, so the actual avg_latency of the routes entering step S6 is...). i ≤t latency The score is between [0,1].

[0146] P i This is the route priority factor, derived from static route configuration (e.g., primary routes have higher priority, backup routes have lower priority), and its value ranges from [0,1]. When a route has no specific priority, it takes the default value of 0.5.

[0147] After calculating the matching scores for all ri∈R_candidater, the system selects the route with the highest score as the target route for invocation: ; If multiple routes have the same highest score, a secondary selection will be made based on the load balancing strategy or the user's historical preferences: Load balancing strategy: Select the option with the lowest average load Li for current requests; User history preferences: Query the routes that the user has successfully called in the last N times (10 times in this example), and prioritize routes that appear frequently in the history; If it is still impossible to distinguish, then select one randomly or select in a round-robin fashion.

[0148] After determining the target call route (rtarget), the system sends the original user request to the backend service corresponding to that route. The call can be made via synchronous HTTP / RPC, asynchronous messaging, or other communication protocols. The system records the core data for this call: Start timestamp tstart; End timestamp (tend); Call result status: success, business failure, timeout, network error, etc.; Actual time consumed Δt = tend − tstart; The returned business code or error message; After the call is completed, the above data is encapsulated into a call record object.

[0149] The result of the call must be recorded so that the asynchronous metric reporting function in step S1 can update the sliding window statistics of each channel route and affect subsequent circuit breaker determination. The recording method is as follows: Synchronous write to the memory queue: The calling thread immediately appends the call record to a global circuit breaker log queue (such as a lock-free circular buffer or BlockingQueue). This queue is used by a separate background thread pool.

[0150] Log content: Each log entry must contain at least: channel_id (route identifier), user_id, timestamp, duration_ms, is_error (boolean value), and error_type.

[0151] Batch write to persistence: Backend users write logs to local files, databases, or directly to message queues (such as Kafka) every second or after accumulating a certain number (e.g., 100 logs) for offline analysis and real-time metric aggregation. Log recording operations should be non-blocking and should not cause the main request to fail due to a full log queue. System stability can be ensured by setting a queue capacity limit (e.g., 10,000) and a discarding strategy (e.g., discarding the oldest logs).

[0152] Special case handling: Scenario 1: R_candidater has only one route: Select the route directly, and the score will still be calculated (for recording), but no comparison is needed.

[0153] Scenario 2: R_candidater is empty: As mentioned above, degradation processing has been performed in step S5. In this case, step S6 will obtain a non-empty set (the degradation route set). If the degradation in step S5 fails and the set is still empty, the system will reject the request, return an error code (such as 503), and record a special circuit breaker log (marked as no_route).

[0154] Scenario 3: An exception occurs when calling the target route (e.g., connection timeout): The call itself may throw an exception. In this case, the exception should be caught, and the `is_error` flag in the call log should be set to `true`, with the timeout set to the time from the start of the call to the exception. Then, log normally (the exception is also an important indicator) and return a failure response to the upper layer. Log recording should not be skipped due to an exception during the call.

[0155] To enhance the system's adaptability to different business scenarios and load fluctuations, this embodiment supports the dynamic distribution of the statistical period for cached results (i.e., the circuit breaker statistical period) through the configuration center, and it can be configured independently at the channel routing granularity. Operations personnel can set different circuit breaker statistical period values ​​for different channel routes through the configuration center's management interface, and these settings will take effect without requiring a service restart. Each service instance updates the period parameters in its local cache in real time by listening for change events in the configuration center.

[0156] In addition, the system also has the ability to adaptively adjust the statistical period. The specific mechanism is as follows: The system continuously monitors the historical request frequency of each channel route (in this embodiment, the average number of requests per second (QPS) or requests per minute over the last 5 minutes is counted).

[0157] Two thresholds are preset: a first threshold (high-frequency threshold) and a second threshold (low-frequency threshold). The settings in this embodiment are as follows: The first threshold can be set to 500 times / minute, and the second threshold can be set to 10 times / minute.

[0158] When the request frequency for a channel exceeds a first threshold, it indicates that the channel is under high load or high activity. In this case, the system automatically shortens its circuit breaker statistics period (e.g., from 300 seconds to 60 seconds). The shortened statistics period can reflect channel performance fluctuations more quickly, triggering circuit breakers or recovery in a timely manner, effectively protecting the system.

[0159] When the request frequency of a channel route falls below the second threshold, it indicates that the channel is in a low-frequency access state. At this time, the system automatically extends its circuit breaker statistics period (e.g., from 300 seconds to 600 seconds). The extended statistics period can accumulate more request data with a small sample size, avoiding accidental circuit breakers triggered by a small number of occasional failures or time fluctuations.

[0160] The adjusted statistical period will serve as the new circuit breaker statistical period for this channel route, used for subsequent first circuit breaker determination (step S2) and the statistical period for the number of circuit breakers n (step S7). At the same time, the sliding time window length (i.e., the statistical period for cached results) corresponding to this route will also be adjusted to the new value. The sub-window division (sliding step size) within the window can be adjusted proportionally or the preset absolute value of the sliding step size can be retained.

[0161] The adaptive adjustment algorithm can employ simple threshold comparison or combine with smoother strategies such as PID control, but this invention does not limit the specific implementation method. To avoid frequent periodic fluctuations, a cooling-off time can be set after adjustment (e.g., no repeated adjustment within 5 minutes) or a hysteresis interval can be introduced (e.g., after high-frequency triggering, it needs to remain stable for a period of time before recovering). These optimization measures are common choices for those skilled in the art.

[0162] Step S7: Automatic recovery mechanism and circuit breaker notification; In steps S2 and S5, the system may trigger either a first circuit breaker decision (global circuit breaker) or a second circuit breaker decision (user-level circuit breaker). The circuit-broken route needs to be frozen for a period of time to prevent further deterioration of service quality. Simultaneously, to accommodate different levels of failure and recovery expectations, the circuit breaker duration should have an increasing penalty characteristic (the more circuit breakers within the same statistical period, the longer the freeze time). Furthermore, circuit breaker events need to reliably notify operations personnel and relevant subsystems, and ensure the atomicity of state updates in a distributed environment.

[0163] Step S7 includes: Calculate the first circuit breaker duration (applicable to global circuit breaker routes) and the second circuit breaker duration (applicable to user-level circuit breaker routes); Perform route freezing (global or user-level); Asynchronous circuit breaker notifications are sent, and data consistency is ensured through distributed locks. The route will be automatically restored after the freeze period expires, and you can choose to reset or continue accumulating the number of circuit breakers.

[0164] Specifically, calculating the first circuit breaker duration includes: counting the number of circuit breakers within the current circuit breaker statistics period; and determining the final circuit breaker duration for each circuit breaker triggered based on the preset automatic recovery duration and accumulated duration. Channel route freezing includes: freezing the channel route within the final circuit breaker duration; automatically restoring the channel route after the freeze period expires; and resetting or continuing to accumulate the number of circuit breakers for use in calculating subsequent circuit breaker durations.

[0165] The system will count the number of circuit breakers that have occurred within the current circuit breaker statistics period. Whenever a new circuit breaker is triggered, the system does not use a fixed freeze duration. Instead, it dynamically calculates the final circuit breaker duration based on the preset automatic recovery duration (denoted as x) and accumulated duration (denoted as y), combined with the accumulated number of circuit breakers within the current statistics period (denoted as n), according to the following formula: ; Where n represents the total number of circuit breakers occurring within the current circuit breaker statistical period (including the current one). For example, if the preset automatic recovery time x is 30 seconds and the cumulative time y is 10 seconds, then the final circuit breaker duration for the first circuit breaker (n=1) is 30 seconds; the final circuit breaker duration for the second circuit breaker (n=2) is 30 + 10 = 40 seconds; the final circuit breaker duration for the third circuit breaker (n=3) is 50 seconds, and so on. This design ensures that within the same statistical period, as the number of circuit breakers increases, the freeze time of the channel routing gradually increases, reflecting punitive protection for channels with frequent failures.

[0166] Second circuit breaker duration: For routes marked with the second circuit breaker determination flag (denoted as r_user, and specifically for the second circuit breaker of user u), the circuit breaker duration D is... user The system dynamically adjusts the circuit breaker based on the user's expected workload W (e.g., the number of requests expected within the next minute). The system first reads the baseline duration D of the user-level circuit breaker from the circuit breaker verification configuration table. user_base (This example uses 20 seconds), and then the impact factor is calculated based on the expected workload: ; in: β is a configurable sensitivity coefficient (ranging from 0 to 1, and 0.5 in this embodiment), which represents the degree to which the workload reduces the circuit breaker duration; W norm The normalization constant (120 times / minute in this embodiment) makes W / W norm Clamped to [0,1]; When users anticipate a large workload, the circuit breaker duration should be appropriately shortened to avoid frequent switching that could negatively impact the user experience. When the workload is small, the circuit breaker duration can be close to the baseline duration.

[0167] If the expected task volume cannot be obtained or is not configured, then D user =D user_base .

[0168] When the system determines that a certain route's rglobal needs to be the first circuit breaker: Read the current n of the route from the circuit breaker status manager and calculate Dglobal; Set the route's state to global circuit breaker (OPEN_GLOBAL) and record the freeze expiration timestamp expire_time=now()+Dglobal; During the freeze, all user requests will be automatically excluded from the route when the available route pool is determined in step S1.

[0169] When the system determines that a certain router requires a second circuit breaker for a specific user u: Calculate Duser; In the user-route mapping table (e.g., the UserCircuitState structure), the freeze expiration time of the entry (u, r_user) is recorded; During the freeze, when user u makes another request, the second circuit breaker decision in step S5 will directly mark the route as unavailable (fail fast), but other users can still use r_user.

[0170] Request processing during the freeze period: For globally circuit-breaking routes: they are excluded during the available route pool construction phase in step S1 and are not visible to any user.

[0171] For user-level circuit breaker routes: In the second circuit breaker determination in step S5, the system first checks whether (u,r_user) is in the frozen mapping table and has not expired. If so, the route is immediately removed (without needing to repeat the time consumption / error rate check).

[0172] Circuit Breaker Notification and Distributed Locks: Circuit breaker events need to be promptly notified to the operations and maintenance monitoring system so that manual intervention or alarm triggering can be initiated. Meanwhile, since the system may deploy multiple instances to process requests concurrently, updating the circuit breaker status (e.g., the n-count) of the same route may lead to race conditions. Therefore, this invention introduces distributed locks to ensure consistency.

[0173] Notification content: After each circuit breaker is triggered, the system asynchronously constructs a circuit breaker notification object, which includes, but is not limited to, the following fields: channel_id: The identifier of the route that was blocked by the circuit breaker; circuit_type: Fuse type (OPEN_GLOBAL or OPEN_USER); user_id (valid only for user-level circuit breakers); trigger_reason: The reason for the trigger (such as "average time exceeded", "error rate exceeded", "compliance failed", etc.). duration_sec: Duration of this circuit breaker interruption (in seconds); timestamp: Trigger time; current_n (Global Circuit Breaker Only): Number of circuit breakers in the current statistical period.

[0174] Distributed lock acquisition and release: To prevent multiple threads from simultaneously modifying the circuit breaker counter n or state of the same route, the system needs to acquire a distributed lock before performing the following operations: update the value of n for the first circuit breaker route and calculate Dglobal; write the route state to a global state store (such as Redis). Once the lock is released, other instances or threads can read the latest circuit breaker state. If a circuit breaker state update fails due to lock contention, the system can rely on the next request to trigger a re-circuit breaker (because persistently abnormal metrics will trigger the condition again), and eventual consistency is acceptable.

[0175] Specifically, a recovery scanner (either a timed thread or a time-wheel-based scheduler) runs in the background to periodically check all frozen entries: for global circuit breakers, it scans routes in the OPEN_GLOBAL state, and if expire_time <= now(), it changes the state to CLOSED and optionally records a recovery log.

[0176] For user-level circuit breaking: Scan the user-routing mapping table and delete expired entries.

[0177] Once restored, the route will re-enter the pool of available routes (for global circuit breaking, it applies to all users; for user-level circuit breaking, it applies only to specific users).

[0178] For the first circuit breaker route, the cumulative strategy for n is determined by the reset_mode field in the circuit breaker verification configuration table: Reset mode (default): Whenever the circuit breaker statistics period T_circuit times out, the system will reset the counter n=0 for this route. In this example, the counting will restart every 300 seconds.

[0179] Cumulative mode: n accumulates over a long period (or uses a sliding window counter) and is not automatically reset to zero. This mode is suitable for scenarios that require permanent penalties.

[0180] The reset operation is usually triggered in the recovery scanner when a new circuit breaker statistics period is detected (e.g., when the end time of the last period is recorded), n=0 is executed.

[0181] Distributed lock timeout: If acquiring the lock times out, the system should record the error and abandon the current circuit breaker status update (only the update is abandoned, but the route will still be marked as circuit breaker by the current request, although the counter may not be updated). You can choose to retry once.

[0182] Notification sending failed: The circuit breaker notification uses an asynchronous queue and retry mechanism (3 retries in this embodiment), which does not affect the main process.

[0183] Recovery scanner failure: If the recovery scanner stops working, you can set each circuit breaker entry to perform a lazy check when a request arrives: when a request accesses a route and it is found that its freeze expiration time has expired, recovery is actively triggered and the freeze mark is deleted.

[0184] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery, characterized in that, include: Receive user requests for channel routing, asynchronously call the metric reporting function based on the requests, generate cached results for each channel route, and determine the available routing pool for each channel route based on the current circuit breaker status of each channel route. The first circuit breaker decision is executed based on the cached results to determine several initial routes from the available route pool, wherein the statistical period of the cached results is determined based on the circuit breaker statistical period. The user who made the request is whitelisted. If the user passes the whitelist verification, the user's behavior vector and the status of each initial route are obtained. Based on the user's behavior vector and the status of each initially selected route, a second circuit breaker determination is performed to determine several routes to be switched. The target call route is determined based on each route to be switched. The user's request for the channel route is executed using the target call route, and the circuit breaker logs of each channel route are recorded for metric reporting.

2. The multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery according to claim 1, characterized in that, Also includes: Based on the first circuit breaker determination, several first circuit breaker routes are determined; The duration of the first circuit breaker for all users is determined based on the cached results of each first circuit breaker route. Based on the second circuit breaker determination, several second circuit breaker routes are determined; The expected workload is determined based on the user's behavior vector, in order to determine the second circuit breaker duration for each second circuit breaker route for the current user.

3. The multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery according to claim 2, characterized in that, The first circuit breaker determination includes: Retrieve the circuit breaker verification configuration table from the configuration center or local cache; Calculate the verification parameters of each channel route based on the cache results of each channel route; Based on the comparison between the verification parameters and the circuit breaker verification configuration table, a number of first circuit breaker routes that meet the first circuit breaker conditions are determined. Based on each of the first circuit breaker routes, several initial routes are determined from the channel routing pool to determine the available routing pool; The circuit breaker thresholds in the circuit breaker verification configuration table include: average time consumption baseline value, time consumption statistics period, time consumption growth threshold, minimum number of requests for time consumption statistics, abnormal statistics period, abnormal request count threshold, minimum number of abnormal requests for statistics, basic automatic recovery time, automatic recovery time increment, maximum number of circuit breakers, and circuit breaker statistics period.

4. The multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery according to claim 1, characterized in that, The asynchronous call to the metric reporting function includes: The call result, exception identifier, and time-consuming data of the request are asynchronously written to a message queue or memory buffer; The background thread updates the statistical indicators of the channel routing within the sliding time window based on the call results, exception identifiers, and time consumption data of each request; wherein the sliding time window corresponding to the statistical indicators is aligned with the circuit breaker statistical period and is used for circuit breaker condition judgment.

5. The multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery according to claim 1, characterized in that, The user behavior vector includes a quality tolerance set, a business tag set, and a compliance and security set. The initial route selection status includes the average request load and the current error rate.

6. The multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery according to claim 1 or 3, characterized in that, The first circuit breaker determination also includes abnormal circuit breaker verification, and the abnormal circuit breaker verification trigger condition is: If the average time taken for a single channel route during the abnormal statistical period is greater than the correction value of the average time baseline value, and the number of requests to a single channel route is greater than or equal to the minimum number of requests for the time-taking statistics, then the single channel route is determined to be circuit breaker triggered.

7. The multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery according to claim 1, characterized in that, The statistical period for the cached results is set to the circuit breaker statistical period; Each channel route corresponds to a sliding time window with a length equal to the circuit breaker statistical period, and the statistical indicators within the sliding time window are updated asynchronously according to a preset sliding step size. The sliding step size is less than the circuit breaker statistical period.

8. The multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery according to claim 1, characterized in that, The statistical period for the cached results is dynamically distributed through the configuration center, and the statistical period for the cached results of each channel route corresponds independently. The statistical period is adaptively adjusted based on the historical request frequency of the route, wherein... When the request frequency of a channel route exceeds the first threshold, the statistical period corresponding to the current channel route is shortened. When the request frequency of a channel route is lower than the second threshold, the statistical period corresponding to the current channel route is extended. The adjusted statistical period will be used as the new circuit breaker statistical period for subsequent circuit breaker determinations.

9. The multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery according to claim 1, characterized in that, The determination of the target route to be switched includes: A matching score is calculated based on the user behavior vector and the routing status of each route to be switched; Select the route with the highest matching score as the target route to invoke; If multiple routes have the same matching score, the routes to be switched will be selected based on either the load balancing strategy or the user tolerance strategy.

10. The multi-channel routing circuit breaker method based on multi-dimensional indicator perception and automatic recovery according to any one of claims 1 to 9, characterized in that, After each route is tripped, an automatic recovery mechanism is also included. The number of circuit breakers within the current circuit breaker statistics period is counted. Each time a circuit breaker is triggered, the first circuit breaker duration is determined based on the preset automatic recovery duration and the accumulated duration. For a circuit breaker route determined by the first circuit breaker, the corresponding circuit breaker freeze duration is the first circuit breaker duration; for a circuit breaker route determined by the second circuit breaker, the corresponding circuit breaker freeze duration is the second circuit breaker duration. After the circuit breaker determination is completed, a circuit breaker notification is sent asynchronously and a log is recorded. Before sending a circuit breaker notification, acquire a distributed lock and perform the following operations under the protection of the distributed lock: update the number of circuit breakers in the current circuit breaker statistics period, calculate the first or second circuit breaker duration for this circuit breaker, and update the circuit breaker status and freeze expiration time of the corresponding route. After the operation is completed, the distributed lock is released to prevent concurrent requests from simultaneously modifying the circuit breaker data of the same route, which could lead to counting errors or inconsistent states. During the first and second circuit breaker durations, the circuit-breaker routes are frozen. After the freeze period expires, the corresponding routes are automatically restored, and the number of circuit breaker events is reset or continues to accumulate for subsequent calculations of the first and second circuit breaker durations. The available route pool includes routes that are in the second circuit breaker duration.

Images