Micro-service-oriented high-availability traffic protection device and method

Abstract

The application provides a micro-service-oriented high-availability traffic protection device and method, which can improve the stability of micro-service resources. The micro-service-oriented high-availability traffic protection device comprises a console module, a dynamic rule configuration module and a protection chain module. The console module is configured to confirm whether the micro-service side successfully accesses the console, monitor the running information of the accessed micro-service side resource and query the management and control rules of the resource. The console module is in communication connection with the dynamic rule configuration module. The dynamic rule configuration module is configured to import the third-party resource-related management and control rules into the console module in real time. The protection chain module is in communication connection with the console module. The protection chain module is configured to count and store the running information of the resource and perform resource allocation according to the management and control rules and the running information.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and in particular to a high-availability traffic protection device and method for microservices. Background Technology

[0002] With the rise of microservices, the stability between services has become increasingly important. Over the past decade or so, core platform traffic scenarios have revolved around events such as flash sales (controlling sudden traffic surges within system capacity), message peak shaving and valley filling, cluster traffic control, and real-time circuit breaking of unavailable downstream applications. These flash sales, live streams, and similar events inevitably cause network platform lag or even outages. Modern microservice architectures (Spring Cloud, Doubbo, gRPC, Service Mesh, etc.) are distributed, composed of numerous services that call each other, forming complex call chains. Lag and outages are amplified in these complex call chains; instability in one link can cascade, ultimately rendering the entire chain unusable. Therefore, service call stability on microservice sides is relatively poor. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention is proposed. Embodiments of this invention provide a high-availability traffic protection device and method for microservices, which can improve the stability of microservice resources.

[0004] According to one aspect of the present invention, a high-availability traffic protection device for microservices is provided. The high-availability traffic protection device for microservices is communicatively connected to a microservice endpoint. The device includes: a console module configured to confirm whether the microservice endpoint has successfully accessed the console, monitor the operational information of resources on the accessed microservice endpoint, and query the management rules of the resources; wherein the management rules include traffic control rules, circuit breaker and degradation rules, system protection rules, and permission rule parameters, and the resources include application services, interfaces, and code; a dynamic rule configuration module, communicatively connected to the console module, configured to import third-party resource-related management rules into the console module in real time; and a protection chain module, communicatively connected to the console module, configured to collect and store the operational information of the resources and perform resource allocation according to the management rules and the operational information.

[0005] In one embodiment, the console module includes: a host discovery unit, configured to determine whether the microservice has successfully accessed the console based on the heartbeat packet sent by the microservice; a real-time monitoring unit, configured to retrieve the running information of the specified resources of the microservice in real time and generate monitoring information; and a rule management unit, configured to query the control rules of the resources based on the application programming interface exposed by the microservice; wherein the host discovery unit, the real-time monitoring unit, and the rule management unit are interconnected.

[0006] In one embodiment, the protection chain module includes: a collection and statistics unit configured to collect resource path information, store resource statistical information and caller information, generate protection logs, and collect monitoring information of indicators from different dimensions; and a resource management and control unit communicatively connected to the collection and statistics unit, configured to perform authorization control based on permission rule parameters and call source information, perform system protection by controlling the total inbound traffic of the system through system status and system protection rules, perform traffic control based on traffic control rules, and perform circuit breaking and degradation based on circuit breaking and degradation rules.

[0007] In one embodiment, the collection and statistics unit includes: a collection chain configured to collect resource path information and store the path information in a tree structure; a construction chain communicatively connected to the collection chain, configured to store resource statistics and caller information; a log chain communicatively connected to the construction chain, configured to generate protection logs when flow control, circuit breaker degradation, or system protection is triggered; and a statistics chain communicatively connected to the log chain, configured to collect monitoring information of different dimensions of the resource based on the current entry point and call source.

[0008] In one embodiment, the resource management unit includes: an authorization chain configured to perform authorization control based on permission rule parameters and call source information; wherein the permission rule parameters include a blacklist and a whitelist, the blacklist representing a list of resources that cannot be accessed, and the whitelist representing a list of resources that can be accessed; a system protection chain communicatively connected to the authorization chain, configured to control the total inbound traffic of the system based on the system status and the system protection rules; a traffic control chain communicatively connected to the system protection chain, configured to perform traffic control based on the traffic control rules and the operational information of the resources collected by the collection and statistics unit; and a circuit breaker and degradation chain communicatively connected to the traffic control chain, configured to perform circuit breaker and degradation on the resources based on the operational information of the resources collected by the collection and statistics unit and the circuit breaker and degradation rules.

[0009] According to another aspect of the present invention, a high-availability traffic protection method for microservices is provided, applied to the high-availability traffic protection device for microservices described in any of the above embodiments. The high-availability traffic protection method for microservices includes: obtaining the access status of the microservice terminal through the console module; when the microservice terminal accesses the console and generates resource calls, the dynamic rule configuration module imports third-party resource-related management rules into the console module in real time, and the console module monitors the operation information of the resource and queries the management rules of the resource; the access status includes whether the microservice terminal has successfully accessed the console; the management rules include traffic control rules, circuit breaker and degradation rules, system protection rules, and permission rule parameters; the protection chain module collects and stores the operation information of the resource; and the protection chain module allocates resources according to the management rules and the operation information stored in the console module.

[0010] In one embodiment, the protection chain module includes: a collection and statistics unit and a resource management and control unit, wherein the resource management and control unit includes an authorization chain; according to the management and control rules and the running information stored in the console module, the protection chain module allocates resources, including: when the microservice terminal accesses the console and generates a resource call, the authorization chain performs authorization control according to the permission rule parameters and the call source information stored in the collection and statistics unit; wherein, the permission rule parameters include a blacklist and a whitelist, the blacklist represents a list of resources that are prohibited from accessing resources, and the whitelist represents a list of resources that are allowed to access resources; if the permission rule parameter is a blacklist, and the caller of the resource call information source matches the blacklist, then the caller is prohibited from accessing the resource; if the caller of the resource call information source does not match the blacklist, then the caller is allowed to access the resource; if the permission rule parameter is a whitelist, and the caller of the resource call information source matches the whitelist, then the caller is allowed to access the resource; if the caller of the resource call information source does not match the whitelist, then the caller is prohibited from accessing the resource.

[0011] In one embodiment, the protection chain module includes a collection and statistics unit and a resource management and control unit. The collection and statistics unit includes a collection chain, a construction chain, and a statistics chain. The resource management and control unit includes a traffic control chain. When the protection chain module allocates resources according to the management and control rules and the running information stored in the console module, the protection chain module performs the following: when the microservice terminal accesses the console and generates a resource call, it collects the resource path information according to the collection chain, the resource statistics information and caller information stored in the construction chain, and the indicator monitoring information of different dimensions counted by the statistics chain to obtain the resource traffic status and the corresponding traffic control rules. When the resource traffic is greater than or equal to a preset traffic threshold, the traffic control chain traverses all traffic control rules corresponding to the resource until a traffic control rule triggers a traffic restriction or all traffic control rules have been traversed.

[0012] In one embodiment, the protection chain module includes a resource management unit, which includes a circuit breaker and degradation chain. Based on the management rules and operational information stored in the console module, the protection chain module allocates resources, including: when the microservice client accesses the console and generates resource calls, obtaining resource operational information through the console module; when the resource operational information indicates that the resource is unstable, the circuit breaker and degradation chain restricts resource calls according to circuit breaker and degradation rules and strategies; wherein the circuit breaker and degradation strategies include a slow call ratio strategy, an abnormal call ratio strategy, and an abnormal call count strategy.

[0013] In one embodiment, when the resource's operational information indicates that the resource is unstable, the circuit breaker and degradation chain restricts the access to the resource according to circuit breaker and degradation rules and strategies, including: if the response time of a request needs to be greater than a preset slow call response time, the request is counted as a slow call; when the number of slow call requests within a unit statistical period is greater than a preset minimum number of requests, and the proportion of slow calls is greater than a preset first threshold, a slow call proportion strategy is executed, and the circuit breaker is automatically triggered within the circuit breaker period; if a request call throws an exception, the request is counted as an abnormal request; when the number of abnormal requests within a unit statistical period is greater than a preset minimum number of requests, and the proportion of exceptions is greater than a preset second threshold, an exception proportion strategy is executed, and the request is automatically circuit-breakered within the circuit breaker period; if a request call throws an exception, the request is counted as an abnormal request; when the number of abnormal requests within a unit statistical period is greater than a set minimum number of requests, and the number of abnormal requests is greater than a preset abnormal request number threshold, an exception number strategy is executed, and the request is automatically circuit-breakered within the circuit breaker period.

[0014] The high-availability traffic protection device and method for microservices provided by this invention provides a console function that can monitor the operation of each resource in real time and can dynamically adjust the rate limiting rules in real time to cope with sudden traffic, control the traffic within the range that the system capacity can bear, control the traffic, and block unavailable downstream applications in real time, thereby improving the stability of service calls on the microservice side. Attached Figure Description

[0015] The above and other objects, features, and advantages of the present invention will become more apparent from the more detailed description of the embodiments of the invention in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same parts or steps.

[0016] Figure 1 This is a structural schematic diagram of the scenario to which this invention applies.

[0017] Figure 2 This is a schematic diagram of the structure of a high-availability traffic protection device for microservices provided in an exemplary embodiment of the present invention.

[0018] Figure 3 This is a schematic diagram of the structure of a high-availability traffic protection device for microservices provided in another exemplary embodiment of the present invention.

[0019] Figure 4 This is a flowchart illustrating a high-availability traffic protection device method for microservices provided in an exemplary embodiment of the present invention.

[0020] Figure labeling: 1. High-availability traffic protection device for microservices; 11. Console module; 111. Host discovery unit; 112. Real-time monitoring unit; 113. Rule management unit; 12. Dynamic rule configuration module; 13. Protection chain module; 131. Collection and statistics unit; 1311. Collection chain; 1312. Construction chain; 1313. Log chain; 1314. Statistics chain; 1315. Authorization chain; 1316. System protection chain; 1317. Traffic control chain; 1318. Circuit breaker and degradation chain; 132. Resource management unit. Detailed Implementation

[0021] Hereinafter, exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments of the present invention. It should be understood that the present invention is not limited to the exemplary embodiments described herein.

[0022] Figure 1 This is a schematic diagram of the scene to which this invention applies, such as... Figure 1 As shown, both microservice A and microservice B can be registered in the console module. The console module can then call the APIs (Application Programming Interfaces) of the registered microservices A and B to monitor and manage traffic on the microservice side.

[0023] The high-availability traffic protection device for microservices communicates with the microservice endpoint. Figure 2 This is a schematic diagram of the structure of a high-availability traffic protection device for microservices provided in an exemplary embodiment of the present invention, as shown below. Figure 2 As shown, the high-availability traffic protection device 1 for microservices includes: a console module 11, configured to confirm whether the microservice has successfully connected to the console, monitor the operation information of the resources of the connected microservice, and query the management rules of the resources; wherein, the management rules include traffic control rules, circuit breaker and degradation rules, system protection rules, and permission rule parameters, and the resources include application services, interfaces, and code; a dynamic rule configuration module 12, which is communicatively connected to the console module 11, and is configured to import third-party resource-related management rules into the console module 11 in real time; and a protection chain module 13, which is communicatively connected to the console module 11, and is configured to collect and store the operation information of the resources, and allocate resources according to the management rules and operation information.

[0024] First, APIs (Application Programming Interfaces) that are adapted to or explicitly displayed for mainstream frameworks are provided to define the resources that need to be protected. These resources can be anything within a Java application, such as services provided by the application itself, services provided by other applications called by the application, RPC (Remote Procedure Call) interface methods, or even a piece of code. The console module 11 is primarily responsible for managing push rules, monitoring, rule management, and machine discovery. For example, it monitors whether microservices have successfully connected to the console. Through the monitoring API exposed by the connected microservices, it periodically pulls and aggregates application monitoring information to monitor the microservices and uniformly manage control rules. The control rules managed in the console module 11 can be queried using the request API exposed by the microservices or obtained in real-time from the dynamic rule configuration module 12. The dynamic rule configuration module 12 is used to import existing external control rules into the console module 11. When configuring control rules, only the resource definition needs to be considered. Once the resource definition is successful, various flow control and degradation rules can be dynamically added. For example, Nacos, Zookeeper, and Redis can be used as the rule configuration data source. The dynamic rule configuration module 12 retrieves the rules and pushes them to the console module 11, which then manages them centrally. Microservices monitor changes to the control rules in the console module 11 by registering listeners. It's understandable that the dynamic rule configuration module 12 provides an open interface, facilitating the definition and modification of rules and allowing for adjustments to resource control based on application scenarios, thus offering greater flexibility. In the high-availability traffic protection device 1 for microservices, all resources correspond to a resource name (resourceName), and an Entry object is created for each resource call. When an Entry is created, the protection chain module 13 also creates a series of protection chains. These protection chains are used to collect, count, and store resource-related operational information, and to manage and control resources based on the collected, counted, and stored operational information, thus playing a protective role. Taking traffic as the entry point, from multiple dimensions such as real-time monitoring, dynamic rule configuration, traffic control, circuit breaking and degradation, and system load protection, it can effectively monitor a large amount of traffic and help ensure the stability of microservice (Spring Cloud, Doubbo, gRPC, Service Mesh, etc.) resources.

[0025] Figure 3 This is a schematic diagram of the structure of a high-availability traffic protection device for microservices provided in another exemplary embodiment of the present invention, as shown below. Figure 3As shown, the console module 11 includes: a host discovery unit 111, configured to determine whether the microservice has successfully accessed the console based on the heartbeat packets sent by the microservice; a real-time monitoring unit 112, configured to pull the running information of the specified microservice resources in real time and generate monitoring information; and a rule management unit 113, configured to query the control rules of the resources based on the application programming interfaces exposed by the microservice. The host discovery unit 111, the real-time monitoring unit 112, and the rule management unit 113 are interconnected.

[0026] The host discovery unit 111 is used to view the list of machines and their health status. For example, it collects heartbeat packets sent by the microservice to determine whether a machine is online. By default, the high-availability traffic protection device 1 for microservices initializes when the microservice is first called and starts sending heartbeat packets to the console. Seeing the corresponding machine in the machine list means that the microservice has successfully connected to the console. The real-time monitoring unit 112 is used for the monitoring API exposed by the microservice to pull the running status of specified microservice resources in real time, periodically pull and aggregate application monitoring information, and ultimately achieve second-level real-time monitoring. The real-time monitoring unit 112 provides two display modes: one displays the call chain of resources in a tree structure, and the other displays the real-time status of resources without distinguishing the call chain. The rule management unit 113 manages push rules in a unified manner. It can query rules from the request API exposed by the microservice and obtain control rules from the dynamic rule configuration module 12. The control rules mainly include flow control rules, circuit breaker and degradation rules, system protection rules, and permission rule parameters. All rules can be dynamically adjusted in real time. For example, if a resource needs to be rate-limited, the condition for rate limiting is the rule. Later, when rate limiting is performed, the decision on whether rate limiting is needed will be based on this rule.

[0027] In one embodiment, such as Figure 3 As shown, the protection chain module 13 includes: a collection and statistics unit 131, which is configured to collect resource path information, store resource statistical information and caller information, generate protection logs, and statistically analyze monitoring information of different dimensions; and a resource management and control unit 132, which is communicatively connected to the collection and statistics unit 131. The resource management and control unit 132 is configured to perform authorization control based on permission rule parameters and call source information, control the total inbound traffic of the system through the system status and system protection rules, perform traffic control based on traffic control rules, and perform circuit breaking and degradation based on circuit breaking and degradation rules.

[0028] The data collection and statistics unit 131 is primarily responsible for collecting resource path information, storing resource statistics and caller information, generating protection logs, and recording and statistically analyzing monitoring information from different dimensions. This collected and statistical information can be used to provide data support for subsequent traffic control. The resource control unit 132 is mainly used to execute specific control measures based on the information collected and statistically analyzed by the data collection and statistics unit 131. That is, it determines which rule the resource is restricted by, and based on the corresponding rule, determines whether the resource needs to be controlled and what kind of control measures to implement. Control measures may include: authorization, rate limiting, and circuit breaking.

[0029] In one embodiment, such as Figure 3 As shown, the collection and statistics unit 131 includes: a collection chain 1311, configured to collect resource path information and store the path information in a tree structure; a construction chain 1312, which is communicatively connected to the collection chain 1311 and configured to store resource statistics and caller information; a log chain 1313, which is communicatively connected to the construction chain 1312 and configured to generate protection logs when flow control, circuit breaker degradation, or system protection is triggered; and a statistics chain 1314, which is communicatively connected to the log chain 1313 and configured to collect and monitor different dimensions of resource indicators based on the current entry point and call source of the resource.

[0030] Collection Chain 1311 is responsible for collecting resource paths and storing these resource call paths in a tree structure for rate limiting and degradation based on the call path. Construction Chain 1312 stores resource statistics and caller information, such as the resource's RT (Response Time), QPS (Query Per Second), and number of threads. This information is used as the basis for multi-dimensional rate limiting and degradation. Response time refers to the time it takes for the system to respond to a request, and QPS is a measure of the amount of traffic a specific query server processes within a specified time. On the Internet, the performance of machines acting as Domain Name System servers is often measured using QPS. Log Chain 1313 generates protection logs. When rate limiting, circuit breaking, degradation, or system protection is triggered, protection logs are generated for developers to view. Statistics Chain 1314 records and statistically analyzes monitoring information from different dimensions. It can select corresponding statistical content based on the current entry point and call source of the resource, such as adding the number of access threads for the resource, the number of requests for the resource, etc. It also performs statistics on the system's entry point QPS, number of threads, and average response time. Collection chain 1311, construction chain 1312, log chain 1313 and statistics chain 1314 are all used to collect operational information of statistical resources, so as to provide data support and data tracking for subsequent management and control.

[0031] In one embodiment, such as Figure 3 As shown, the resource management unit 132 includes: an authorization chain 1315, configured to perform authorization control based on permission rule parameters and call source information; wherein, the permission rule parameters include a blacklist and a whitelist, the blacklist representing a list of resources that cannot be accessed, and the whitelist representing a list of resources that can be accessed; a system protection chain 1316, which is communicatively connected to the authorization chain 1315, configured to control the total inbound traffic of the system based on the system status and system protection rules; a traffic control chain 1317, which is communicatively connected to the system protection chain 1316, configured to perform traffic control based on traffic control rules and the resource operation information collected by the statistics unit 131; and a circuit breaker and degradation chain 1318, which is communicatively connected to the traffic control chain 1317, configured to perform circuit breaker and degradation on resources based on the resource operation information collected by the statistics unit 131 and the circuit breaker and degradation rules.

[0032] Authorization Chain 1315 performs blacklist and whitelist control based on configured blacklists and whitelists and call source information; it authorizes resource callers by adding permission rule parameters through the console. Authorization Chain 1315 retrieves the resource caller and then matches it against the "resource application" option in the permission rule parameters. There are two authorization scenarios: 1. If the authorization type is blacklist, and the resource caller matches the blacklist (meaning the caller is on the blacklist), the service cannot access the resource; otherwise, the caller can access the resource. 2. If the authorization type is whitelist, and the resource caller matches the whitelist (meaning the caller is on the whitelist), the service can access the resource; otherwise, the caller cannot access the resource.

[0033] System Protection Chain 1316 controls total inbound traffic based on system status, such as load, and limits flow based on overall system statistics to prevent excessive system load. System Protection Chain 1316 starts a scheduled task that reads the current system CPU and load every second. Statistics Chain 1314 tracks system inbound QPS, thread count, average response time, and other metrics. System protection rules control inbound traffic at the application level, monitoring application metrics from several dimensions, including single-machine load, CPU utilization, average response time, inbound query rate per second, and concurrent threads, to ensure the system runs at maximum throughput while maintaining overall system stability. Throughput (TPS) refers to the number of requests a system processes per unit of time. System protection rules are application-wide, not resource-based, and only apply to inbound traffic, which refers to traffic entering the application, such as requests received by web services or Dubbo servers.

[0034] The traffic control chain 1317 performs traffic control based on preset traffic control rules and the status statistics collected by the collection and statistics unit 131. Traffic control works by monitoring application traffic metrics such as QPS or concurrent threads. When a specified threshold is reached, traffic is controlled to prevent the application from being overwhelmed by sudden traffic spikes, thus ensuring high availability. The traffic control chain 1317 performs traffic control based on the traffic control rules and the real-time information collected by the collection and statistics unit 131. The direct manifestation of rate limiting is throwing a traffic exception during execution. Developers can capture these exceptions to customize the processing logic after rate limiting. Multiple traffic control rules can be created for the same resource. The traffic control chain 1317 iterates through all traffic control rules for the resource until a traffic control rule triggers rate limiting or all traffic control rules have been iterated.

[0035] A flow control rule consists of the following attributes: (1) Resource name: a unique name, which defaults to the microservice API request path; (2) Target source: the protection device can limit the flow for the caller. Fill in the microservice name, which defaults to default (does not distinguish the source); (3) Threshold type: the flow limit condition. When the QPS of the resource or the number of accessing threads reaches the set single-machine threshold, the flow limit will be triggered.

[0036] Rate limiting is implemented when the QPS of the API calls reaches the threshold, or when the number of threads calling the API reaches the threshold. The flow control rules are only effective for the threshold type QPS, and are ineffective when the threshold type is the number of threads. There are three modes: direct, associated, and linked: (1) Direct: When the API reaches the rate limiting condition, rate limiting is implemented directly; (2) Associated: When the associated resource reaches the threshold, rate limiting is implemented. When the QPS of the associated resource reaches the set threshold, the rate limiting operation of the current resource will be triggered; (3) Linked: Only the traffic on the specified path is recorded. The traffic from the specified resource to the ingress resource is rate-limited if the threshold is reached. This is API-level rate limiting.

[0037] When the system's QPS traffic exceeds the set threshold, the flow control chain 1317 takes measures to control the flow. The flow control effect is divided into three types: fast failure, warm up, and queuing: (1) Fast failure: Once the rate limit is triggered, the request will be immediately rejected and fail, throwing a blocking exception; (2) Warm up: In order to prevent the system from being overwhelmed by a sudden increase in system traffic, there will be a buffer phase from the initial threshold to the maximum QPS threshold. The initial threshold is 1 / 3 of the maximum QPS threshold, and then it slowly increases until the maximum threshold. This is suitable for converting a sudden increase in traffic into a gradual increase, avoiding server crashes caused by a sudden large flow. (3) Queuing: When the rate limit is triggered, the interval between requests will be strictly controlled, and requests will be queued for a certain period of time to allow requests to pass at a uniform speed. In addition, a queueing timeout can be set. If the request is not processed within the timeout period, the request will be rejected.

[0038] The circuit breaker and degradation chain 1318 performs circuit breaker and degradation by collecting resource operation information and circuit breaker and degradation rules from the statistics unit 131. Furthermore, the circuit breaker and degradation chain 1318 is the final processing step. Resources are first verified by the authorization chain 1315, the system protection chain 1316, and the flow control chain 1317. If a resource is authorized by the authorization chain 1315, it does not need to undergo rate limiting by the system protection chain 1316 or the flow control chain 1317 before reaching the circuit breaker and degradation chain 1318. The circuit breaker and degradation chain 1318 performs circuit breaker and degradation on unstable resources in the call chain, temporarily cutting off unstable calls and preventing request backlog that could cause a service avalanche.

[0039] A service often calls other modules, which may be other remote services, databases, or third-party APIs. For example, when making a payment, it may need to remotely call the API provided by UnionPay; querying the price of a product may require a database query. However, the stability of the dependent service cannot be guaranteed. If the dependent service becomes unstable, the response time of the request will increase, and the response time of the method calling the service will also increase, leading to thread backlog, which may eventually exhaust the thread pool of the business logic and make the service itself unavailable. Due to the complexity of the call relationship, if a resource in the call chain is unstable, it will eventually lead to request backlog. Therefore, the circuit breaker degradation chain 1318 will restrict calls to a resource when it becomes unstable (e.g., call timeout or increased exception rate), causing requests to fail quickly and preventing it from affecting other resources and causing cascading errors. Once a resource is degraded, calls to that resource will be automatically circuit-broken within the subsequent degradation time window (the default behavior is to throw a circuit breaker exception).

[0040] Each rule setting creates a circuit breaker, which has three states: OPEN, HALF_OPEN, and CLOSED. (1) When in the CLOSED state, the circuit breaker does not work. Resources can be accessed, and after access, the slow call ratio, exception ratio, and exception number are statistically analyzed. Once the set threshold is reached, the circuit breaker state is set to OPEN. (2) When in the OPEN state, the circuit breaker works, and all requests are downgraded. The system determines whether the circuit breaker time has been reached. If not, access is rejected. If it has, the state is changed to HALF_OPEN, and then the resource is accessed. After access, the access result is judged. If it meets the requirements of the rule setting, the circuit breaker is directly set to CLOSED and closed. If it does not meet the requirements, it is changed back to the OPEN state. (3) When in the HALF_OPEN state, the next normal process is attempted. If it cannot proceed, the OPEN state is maintained. Otherwise, it is changed to the CLOSED state.

[0041] Circuit breaker degradation strategies include slow call ratio strategy, abnormal call ratio strategy, and abnormal call count strategy:

[0042] 1. Slow call ratio strategy

[0043] 1.1 Slow call ratio: SLOW_REQUEST_RATIO, using the slow call ratio as a threshold;

[0044] 1.2 Slow Call: If the response time of a request is longer than the set slow call response time, the request is counted as a slow call;

[0045] 1.3 Circuit Breaker Trigger: If the number of requests within a unit statistical time (statIntervalMs) exceeds the set minimum number of requests, and the proportion of slow calls exceeds the threshold, the circuit breaker will be automatically triggered within the circuit breaker time (an exception will be thrown when the method is called);

[0046] 1.4 Circuit Breaker Recovery: After the circuit breaker has been in operation for the specified duration, it enters a probe recovery state (half-open state). If the response time of the next request is less than the set slow call response time, the circuit breaker will end. If the response time of the next request is greater than the set slow call response time, the circuit breaker will continue to operate for the specified duration.

[0047] 2. Abnormal Proportion Strategy

[0048] 2.1 Error Ratio: ERROR_RATIO, which uses the percentage of requests that are abnormal as a threshold, with a threshold range of [0.0, 1.0].

[0049] 2.2 Abnormal Requests: If a request throws an exception, the request is classified as an abnormal request.

[0050] 2.3 Circuit Breaker Trigger: If the number of requests within a unit statistical time interval (statIntervalMs) exceeds the set minimum number of requests, and the proportion of exceptions exceeds the threshold, the circuit breaker will be automatically triggered within the circuit breaker time interval.

[0051] 2.4 After the circuit breaker has been in operation for the specified duration, it enters the HALF-OPEN state. If the next request is executed successfully, the circuit breaker will terminate; if the request fails, the circuit breaker will continue to operate for the specified duration.

[0052] 3. Outlier Strategy

[0053] 3.1 Number of exceptions: ERROR_COUNT, with the number of exception requests as the threshold;

[0054] 3.2 Abnormal Requests: If a request throws an exception, the request is classified as an abnormal request.

[0055] 3.3 Circuit Breaker Trigger: If the number of requests within a unit statistical time interval (statIntervalMs) exceeds the set minimum number of requests, and the number of abnormal requests exceeds the set threshold for the number of abnormal requests, the circuit breaker will be automatically triggered within the circuit breaker time interval.

[0056] 3.4 Fuse Recovery: After the fuse has been tripped for a certain period of time, the fuse enters the HALF-OPEN state. If the next request is executed successfully, the fuse tripping ends; if the request fails, the fuse tripping continues for the remaining duration of the tripping period.

[0057] It's understandable that circuit breaking and degradation are primarily for the service caller. In projects, other services or third-party interfaces are frequently called. If these interfaces become unstable, it can cause the service itself to wait for extended periods, leading to response delays and other issues. The service caller can address this by using circuit breaking and degradation. If a third-party interface takes too long to respond, a slow call ratio rule can be applied. When a large number of long response times occur, the circuit breaker will be triggered, and no further requests will be made.

[0058] Figure 4 This is a flowchart illustrating a high-availability traffic protection method for microservices provided in an exemplary embodiment of the present invention, as shown below. Figure 4 As shown, the high-availability traffic protection method for microservices is applied to the high-availability traffic protection device for microservices in any of the above embodiments. The high-availability traffic protection method for microservices includes:

[0059] Step 100: Obtain the access status of the microservice through the console module.

[0060] The host discovery unit in the console module can determine whether a microservice has successfully connected to the console based on the heartbeat packets sent by the microservice. For example, it collects heartbeat packets sent by the microservice to determine if a machine is online. By default, the high-availability traffic protection device 1 for microservices initializes when the microservice is first invoked and begins sending heartbeat packets to the console. Seeing the corresponding machine in the machine list indicates that the microservice has successfully connected to the console.

[0061] Step 200: When the microservice client connects to the console and generates resource calls, the dynamic rule configuration module imports the third-party resource-related management rules into the console module in real time, and the console module monitors the resource's operation information and queries the resource's management rules.

[0062] Access status includes whether the microservice has successfully connected to the console, and management rules include traffic control rules, circuit breaker and degradation rules, system protection rules, and permission rule parameters.

[0063] After the microservice is integrated with the console, a high-availability traffic protection device for the microservice can act as an intermediary for resource calls. The control rules managed in the console module can be queried from the request API exposed by the microservice or obtained in real-time from the dynamic rule configuration module. The dynamic rule configuration module imports existing external control rules into the console module. When configuring control rules, only the resource definition needs to be considered. Once the resource is successfully defined, various flow control and degradation rules can be dynamically added. For example, Nacos, Zookeeper, and Redis can be used as rule configuration data sources. The dynamic rule configuration module retrieves these rules and pushes them to the console module for unified management. The microservice monitors changes to the control rules in the console module by registering listeners. It's understandable that the dynamic rule configuration module provides an open interface, facilitating the definition and modification of rules, and allowing for adjustments to resource control based on application scenarios, offering greater flexibility. The real-time monitoring unit in the console module is used for monitoring APIs exposed by microservices. It pulls the running status of specified microservice resources in real time, and periodically pulls and aggregates application monitoring information, ultimately achieving second-level real-time monitoring. The rule management unit manages push rules in a unified manner. Rules can be queried from the request API exposed by the microservice, and control rules can also be obtained from the dynamic rule configuration module 12. Control rules mainly include flow control rules, circuit breaker and degradation rules, system protection rules, and permission rule parameters. All rules can be dynamically adjusted in real time. For example, if a resource needs to be rate-limited, the condition for rate limiting is the rule, and the subsequent rate limiting will be based on this rule to determine whether rate limiting is necessary.

[0064] Step 300: Collect and store the operational information of resources through the protection chain module.

[0065] The collection and statistics unit in the protection chain module is mainly responsible for collecting resource path information, storing resource statistics and caller information, generating protection logs, recording and statistically analyzing monitoring information of different dimensions. This collected and statistical information can be used to provide data support for subsequent traffic management.

[0066] Step 400: Based on the control rules and operational information stored in the console module, the protection chain module allocates resources.

[0067] The resource management unit in the protection chain module is mainly used to execute specific management measures based on the information collected and statistically analyzed by the collection and statistics unit. That is, to determine which rule the resource is restricted by, and based on the corresponding rule, to determine whether the resource needs to be managed and what kind of management measures to take. Management measures may include: authorization, rate limiting, and circuit breaking.

[0068] In one embodiment, the protection chain module includes: a collection and statistics unit and a resource management and control unit, the resource management and control unit including an authorization chain; the above step 400 may include: when the microservice terminal accesses the console and generates a resource call, the authorization chain performs authorization control according to the permission rule parameters and the call source information stored in the collection and statistics unit; wherein, the permission rule parameters include a blacklist and a whitelist, the blacklist represents a list of resources that are prohibited from accessing resources, and the whitelist represents a list of resources that are allowed to access resources; if the permission rule parameter is a blacklist, and the caller of the resource call information source matches the blacklist, then the caller is prohibited from accessing the resource, and if the caller of the resource call information source does not match the blacklist, then the caller is allowed to access the resource; if the permission rule parameter is a whitelist, and the caller of the resource call information source matches the whitelist, then the caller is allowed to access the resource, and if the caller of the resource call information source does not match the whitelist, then the caller is prohibited from accessing the resource.

[0069] The authorization chain uses configured blacklists / whitelists and call source information for blacklist / whitelist control. It authorizes resource callers by adding permission rule parameters via the console. The authorization chain retrieves the resource caller and matches it against the "resource application" option in the permission rule parameters. There are two authorization scenarios: 1. If the authorization type is blacklist, and the resource caller matches the blacklist (meaning the caller is on the blacklist), the service cannot access the resource. If the caller does not match the blacklist, it can access the resource. 2. If the authorization type is whitelist, and the resource caller matches the whitelist (meaning the caller is on the whitelist), the service can access the resource. If the caller does not match the whitelist, it cannot access the resource.

[0070] In one embodiment, the protection chain module includes a collection and statistics unit and a resource management and control unit. The collection and statistics unit includes a collection chain, a construction chain, and a statistics chain. The resource management and control unit includes a traffic control chain. The above step 400 may include: when the microservice terminal accesses the console and generates a resource call, collecting the resource path information according to the collection chain, storing the resource statistics information and caller information according to the construction chain, and collecting the indicator monitoring information of different dimensions of the statistics chain to obtain the traffic status of the resource and the corresponding traffic control rules; when the traffic of the resource is greater than or equal to a preset traffic threshold, the traffic control chain traverses all traffic control rules corresponding to the resource until a traffic control rule triggers a traffic restriction or all traffic control rules have been traversed.

[0071] The traffic control chain is used to control traffic based on preset traffic control rules and the status statistics collected by the statistical unit. The principle of traffic control is to monitor application traffic metrics such as QPS or concurrent threads, and control traffic when a specified threshold is reached to prevent it from being overwhelmed by sudden traffic spikes, thus ensuring high application availability. The traffic control chain performs traffic control based on traffic control rules and real-time information collected by the statistical unit. Rate limiting is directly manifested by throwing a traffic exception during execution. Developers can catch the thrown exceptions to customize the handling logic after rate limiting. Multiple traffic control rules can be created for the same resource. The traffic control chain iterates through all traffic control rules for the resource until a traffic control rule triggers rate limiting or all traffic control rules have been iterated.

[0072] A flow control rule consists of the following attributes: (1) Resource name: a unique name, which defaults to the microservice API request path; (2) Target source: the protection device can limit the flow for the caller. Fill in the microservice name, which defaults to default (does not distinguish the source); (3) Threshold type: the flow limit condition. When the QPS of the resource or the number of accessing threads reaches the set single-machine threshold, the flow limit will be triggered.

[0073] Rate limiting is implemented when the QPS of the API calls reaches the threshold, or when the number of threads calling the API reaches the threshold. The flow control rules are only effective for the threshold type QPS, and are ineffective when the threshold type is the number of threads. There are three modes: direct, associated, and linked: (1) Direct: When the API reaches the rate limiting condition, rate limiting is implemented directly; (2) Associated: When the associated resource reaches the threshold, rate limiting is implemented. When the QPS of the associated resource reaches the set threshold, the rate limiting operation of the current resource will be triggered; (3) Linked: Only the traffic on the specified path is recorded. The traffic from the specified resource to the ingress resource is rate-limited if the threshold is reached. This is API-level rate limiting.

[0074] When the system's QPS traffic exceeds the set threshold, the flow control chain takes measures to control the flow. The flow control effect is divided into three types: fast failure, warm up, and queuing: (1) Fast failure: Once the rate limit is triggered, the request will be immediately rejected and fail, throwing a blocking exception; (2) Warm up: In order to prevent the system from being overwhelmed by a sudden increase in system traffic, there will be a buffer phase from the initial threshold to the maximum QPS threshold. The initial threshold is 1 / 3 of the maximum QPS threshold, and then it slowly increases until the maximum threshold. This is suitable for converting a sudden increase in traffic into a gradual increase, avoiding server crashes caused by a sudden large flow. (3) Queuing: When the rate limit is triggered, the interval between requests will be strictly controlled, and requests will be queued for a certain period of time to allow requests to pass at a uniform speed. In addition, a timeout period for queuing can be set. If the request is not processed within the timeout period, the request will be rejected.

[0075] In one embodiment, the protection chain module includes a resource management unit, which includes a circuit breaker and degradation chain. The above step 400 may include: when the microservice terminal accesses the console and generates a resource call, obtaining the resource's operation information through the console module; when the resource's operation information indicates that the resource is unstable, the circuit breaker and degradation chain restricts the resource call according to the circuit breaker and degradation rules and the circuit breaker and degradation strategy; wherein, the circuit breaker and degradation strategy includes a slow call ratio strategy, an abnormal ratio strategy, and an abnormal number strategy.

[0076] The circuit breaker and degradation chain performs circuit breaking and degradation by collecting resource operation information and circuit breaking and degradation rules from the statistics unit. Furthermore, the circuit breaker and degradation chain is the final processing step. Resources are first verified by the authorization chain, system protection chain, and flow control chain. If a resource is authorized by the authorization chain, it does not need to be rate-limited by the system protection chain or the flow control chain before reaching the circuit breaker and degradation chain. The circuit breaker and degradation chain performs circuit breaking and degradation on unstable resources in the call chain, temporarily cutting off unstable calls and preventing request backlog that could cause a cascading failure of the overall service.

[0077] In one embodiment, when the resource's operational information indicates that the resource is unstable, the circuit breaker and degradation chain restricts resource calls according to circuit breaker and degradation rules and strategies, including: if the response time of a request needs to be greater than a preset slow call response time, the request is counted as a slow call; when the number of slow call requests within a unit statistical period is greater than a preset minimum number of requests, and the proportion of slow calls is greater than a preset first threshold, a slow call proportion strategy is executed, and the circuit breaker is automatically triggered within the circuit breaker period; if a request call throws an exception, the request is counted as an abnormal request; when the number of abnormal requests within a unit statistical period is greater than a preset minimum number of requests, and the proportion of exceptions is greater than a preset second threshold, an exception proportion strategy is executed, and the request is automatically circuit-breakered within the circuit breaker period; if a request call throws an exception, the request is counted as an abnormal request; when the number of abnormal requests within a unit statistical period is greater than a set minimum number of requests, and the number of abnormal requests is greater than a preset abnormal request number threshold, an exception number strategy is executed, and the request is automatically circuit-breakered within the circuit breaker period.

[0078] Each rule setting creates a circuit breaker, which has three states: OPEN, HALF_OPEN, and CLOSED. (1) When in the CLOSED state, the circuit breaker does not work. Resources can be accessed, and after access, the slow call ratio, exception ratio, and exception number will be statistically analyzed. For example, if the unit statistical time (statIntervalMs) exceeds the threshold and is greater than the minimum number of requests, the circuit breaker will be triggered, and the state of the circuit breaker will be set to OPEN. (2) When in the OPEN state, the circuit breaker works, and all requests are downgraded. The system determines whether the circuit breaker time has been reached. If not, access is rejected. If it has been reached, the state is changed to HALF_OPEN, and then the resource is accessed. After access, the access result is judged. If it meets the requirements of the rule setting, the circuit breaker is directly set to CLOSED and closed. If it does not meet the requirements, it is changed back to the OPEN state. (3) When in the HALF_OPEN state, the next normal process is attempted. If it cannot proceed, the OPEN state is maintained. Otherwise, it is converted to the CLOSED state.

[0079] Circuit breaker degradation strategies include slow call ratio strategy, abnormal call ratio strategy, and abnormal call count strategy:

[0080] 1. Slow call ratio strategy

[0081] 1.1 Slow call ratio: SLOW_REQUEST_RATIO, using the slow call ratio as a threshold;

[0082] 1.2 Slow Call: If the response time of a request is longer than the set slow call response time, the request is counted as a slow call;

[0083] 1.3 Circuit Breaker Trigger: If the number of requests within a unit statistical time (statIntervalMs) exceeds the set minimum number of requests, and the proportion of slow calls exceeds the threshold, the circuit breaker will be automatically triggered within the circuit breaker time (an exception will be thrown when the method is called);

[0084] 1.4 Circuit Breaker Recovery: After the circuit breaker has been in operation for the specified duration, it enters a probe recovery state (half-open state). If the response time of the next request is less than the set slow call response time, the circuit breaker will end. If the response time of the next request is greater than the set slow call response time, the circuit breaker will continue to operate for the specified duration.

[0085] 2. Abnormal Proportion Strategy

[0086] 2.1 Error Ratio: ERROR_RATIO, which uses the percentage of requests that are abnormal as a threshold, with a threshold range of [0.0, 1.0].

[0087] 2.2 Abnormal Requests: If a request throws an exception, the request is classified as an abnormal request.

[0088] 2.3 Circuit Breaker Trigger: If the number of requests within a unit statistical time interval (statIntervalMs) exceeds the set minimum number of requests, and the proportion of exceptions exceeds the threshold, the circuit breaker will be automatically triggered within the circuit breaker time interval.

[0089] 2.4 After the circuit breaker has been in operation for the specified duration, it enters the HALF-OPEN state. If the next request is executed successfully, the circuit breaker will terminate; if the request fails, the circuit breaker will continue to operate for the specified duration.

[0090] 3. Outlier Strategy

[0091] 3.1 Number of exceptions: ERROR_COUNT, with the number of exception requests as the threshold;

[0092] 3.2 Abnormal Requests: If a request throws an exception, the request is classified as an abnormal request.

[0093] 3.3 Circuit Breaker Trigger: If the number of requests within a unit statistical time interval (statIntervalMs) exceeds the set minimum number of requests, and the number of abnormal requests exceeds the set threshold for the number of abnormal requests, the circuit breaker will be automatically triggered within the circuit breaker time interval.

[0094] 3.4 Fuse Recovery: After the fuse has been tripped for a certain period of time, the fuse enters the HALF-OPEN state. If the next request is executed successfully, the fuse tripping ends; if the request fails, the fuse tripping continues for the remaining duration of the tripping period.

[0095] This invention provides a high-availability traffic protection device for microservices. The device can be implemented in software, hardware, or a combination of both. From a hardware perspective, in addition to the CPU, memory, network interface, and non-volatile memory, the device in the embodiment typically includes other hardware, such as a forwarding chip responsible for processing packets. Taking software implementation as an example, as a logical device, it is formed by the CPU of the device loading the corresponding computer program instructions from the non-volatile memory into memory for execution.

[0096] According to another aspect of the present invention, a computer-readable storage medium is provided, the storage medium storing a computer program for performing the microservice-oriented high-availability traffic protection method of any of the above embodiments.

[0097] In addition to the methods and devices described above, embodiments of the present invention may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the microservice-oriented high availability traffic protection methods described in the "Exemplary Methods" section of this specification according to various embodiments of the present invention.

[0098] According to another aspect of the present invention, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; and a processor for executing the microservice-oriented high-availability traffic protection method of any of the above embodiments.

[0099] Furthermore, embodiments of the present invention may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps in the microservice-oriented high availability traffic protection method described in the "Exemplary Methods" section of this specification according to various embodiments of the present invention.

[0100] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A microservice-oriented high-availability traffic protection device, characterized in that, The micro-service-oriented high-availability traffic protection device is in communication connection with the micro-service side, and the micro-service-oriented high-availability traffic protection device comprises: A console module configured to confirm whether the micro-service side successfully accesses the console, monitor running information of resources of the accessed micro-service side, and query management and control rules of the resources; wherein the management and control rules comprise traffic control rules, fuse degradation rules, system protection rules and permission rule parameters, and the resources comprise application services, interfaces and codes; A dynamic rule configuration module in communication connection with the console module, and configured to import third-party management and control rules related to the resources into the console module in real time; A protection chain module in communication connection with the console module, and configured to statistically store running information of the resources, and perform resource allocation according to the management and control rules and the running information; The console module comprises: A host discovery unit configured to determine whether the micro-service side successfully accesses the console according to a heartbeat packet sent by the micro-service side; A real-time monitoring unit configured to pull running information of resources of the micro-service side in real time to generate monitoring information; A rule management unit configured to query management and control rules of the resources according to application program interfaces exposed by the micro-service side; Wherein the host discovery unit, the real-time monitoring unit and the rule management unit are in communication connection with each other; The protection chain module comprises: A collection and statistical unit configured to collect path information of resources, store statistical information of resources and caller information, generate protection logs and statistical index monitoring information of different latitudes; A resource management and control unit in communication connection with the collection and statistical unit, and configured to perform authorization control according to permission rule parameters and caller information, perform system protection by controlling system total entry traffic according to system states and system protection rules, perform traffic control according to traffic control rules, and perform fuse degradation according to fuse degradation rules; The collection and statistical unit comprises: A collection chain configured to collect path information of resources, and store the path information in a tree structure; A construction chain in communication connection with the collection chain, and configured to store statistical information of resources and caller information; A log chain in communication connection with the construction chain, and configured to generate protection logs when traffic control, fuse degradation or system protection is triggered; A statistical chain in communication connection with the log chain, and configured to statistically count index monitoring information of different latitudes of resources according to current entry and caller sources of the resources.

2. The microservice-oriented high-availability traffic protection device according to claim 1, characterized in that, The resource management and control unit comprises: An authorization chain configured to perform authorization control according to permission rule parameters and call source information, wherein the permission rule parameters include a blacklist and a whitelist, the blacklist indicating a list of resources that cannot be accessed, and the whitelist indicating a list of resources that can be accessed; A system protection chain in communication connection with the authorization chain, the system protection chain being configured to control system total entry flow according to a state of the system and the system protection rule; A flow control chain in communication connection with the system protection chain, the flow control chain being configured to perform flow control according to the flow control rule and the running information of the resources collected and counted by the collection and counting unit; A fuse degradation chain in communication connection with the flow control chain, the fuse degradation chain being configured to perform fuse degradation on the resources according to the running information of the resources collected and counted by the collection and counting unit and the fuse degradation rule.

3. A method for microservice-oriented high-availability traffic protection, applied to the microservice-oriented high-availability traffic protection device in any one of claims 1-2, characterized in that, The microservice-oriented high-availability flow protection method includes: Access state of the microservice side is acquired through the console module; When the microservice side accesses the console and generates resource calling, the dynamic rule configuration module imports third-party and resource-related management and control rules into the console module in real time, and the console module monitors running information of the resources and queries the management and control rules of the resources; the access state includes whether the microservice side successfully accesses the console; the management and control rules include flow control rules, fuse degradation rules, system protection rules, and permission rule parameters; Running information of the resources is counted and stored through the protection chain module; The protection chain module allocates resources according to the management and control rules stored in the console module and the running information.

4. The microservice-oriented high-availability traffic protection method of claim 3, wherein, The protection chain module includes a collection and counting unit and a resource management and control unit, the resource management and control unit including an authorization chain; the protection chain module allocates resources according to the management and control rules stored in the console module and the running information, including: When the microservice side accesses the console and generates resource calling, the authorization chain performs authorization control according to the permission rule parameters and the call source information stored by the collection and counting unit; wherein the permission rule parameters include a blacklist and a whitelist, the blacklist indicating a list of resources that cannot be accessed, and the whitelist indicating a list of resources that can be accessed; If the permission rule parameters are the blacklist, and the caller of the calling information of the resources matches the blacklist, the caller is prohibited from accessing the resources, and if the caller of the calling information of the resources does not match the blacklist, the caller is allowed to access the resources; If the permission rule parameters are the whitelist, and the caller of the calling information of the resources matches the whitelist, the caller is allowed to access the resources, and if the caller of the calling information of the resources does not match the whitelist, the caller is prohibited from accessing the resources.

5. The microservice-oriented high-availability traffic protection method of claim 4, wherein, The protection chain module comprises a collection and statistics unit and a resource management and control unit, the collection and statistics unit comprises a collection chain, a construction chain and a statistics chain, and the resource management and control unit comprises a flow control chain; when the protection chain module allocates resources according to the management and control rules stored in the console module and the running information, the following steps are included: When the micro service side accesses the console and generates a resource call, the path information of the resource is collected by the collection chain, the statistics information of the resource and the caller information are stored by the construction chain, and the index monitoring information of different latitudes is counted by the statistics chain, so as to obtain the flow condition of the resource and the corresponding flow control rules; When the flow of the resource is greater than or equal to a preset flow threshold, the flow control chain traverses all flow control rules corresponding to the resource until a flow control rule triggers to limit the flow or all flow control rules are traversed.

6. The microservice-oriented high-availability traffic protection method of claim 5, wherein, The protection chain module comprises a resource management and control unit, the resource management and control unit comprises a fuse degradation chain, and the protection chain module allocates resources according to the management and control rules stored in the console module and the running information, including: When the micro service side accesses the console and generates a resource call, the running information of the resource is obtained through the console module; When the running information of the resource indicates that the resource is unstable, the fuse degradation chain limits the call of the resource according to the fuse degradation rules and the fuse degradation strategy; wherein the fuse degradation strategy comprises a slow call proportion strategy, an exception proportion strategy and an exception number strategy.

7. The microservice-oriented high-availability traffic protection method of claim 6, wherein, When the running information of the resource indicates that the resource is unstable, the fuse degradation chain limits the call of the resource according to the fuse degradation rules and the fuse degradation strategy, including: If the response time of the request needs to be greater than a preset slow call response time, the request is counted as a slow call, when the number of requests of the slow call in a unit statistical time length is greater than a preset minimum request number and the proportion of the slow call is greater than a preset first threshold, the slow call proportion strategy is executed, and the fuse is automatically triggered in a fuse time length; If the request call throws an exception, the request is counted as an exception request, when the number of requests of the exception request in a unit statistical time length is greater than a preset minimum request number and the proportion of the exception is greater than a preset second threshold, the exception proportion strategy is executed, and the fuse is automatically triggered in a fuse time length; If the request call throws an exception, the request is counted as an exception request, when the number of requests of the exception request in a unit statistical time length is greater than a preset minimum request number and the proportion of the exception is greater than a preset second threshold, the exception proportion strategy is executed, and the fuse is automatically triggered in a fuse time length.

Images