An overload protection method, apparatus, device and computer readable storage medium

Abstract

The application provides an overload protection method, device, equipment and computer readable storage medium; the method comprises the following steps: receiving at least one fuse rule corresponding to at least one fuse granularity of a target microservice sent by a rule configuration device; the at least one fuse granularity indicates the range level of fuse; according to each fuse rule in the at least one fuse rule, the statistical indicators corresponding to the execution units in each fuse granularity are counted; the statistical indicators are used to represent the response of the execution units in each fuse granularity to the request; based on the statistical indicators corresponding to the execution units and the fuse rules corresponding to each fuse granularity in the at least one fuse rule, the fuse state of the execution units is determined; according to the fuse state, the execution units in each fuse granularity are controlled, and the overload protection of the target microservice is realized. Through the application, the service quality of the microservice can be improved.

Description

Technical Field

[0001] This application relates to microservices technology, and more particularly to an overload protection method, apparatus, device, and computer-readable storage medium. Background Technology

[0002] Microservices refer to dividing a single software product into multiple individual services. These services work together to provide services to users, thereby realizing the functionality of the software product. Furthermore, microservices can leverage cloud technology. In other words, each microservice can be deployed independently, thus improving system fault tolerance. The complexity of microservices increases significantly with the number of services and the number of instances within a single service. Overload protection is a mechanism to prevent excessive complexity in a single microservice from negatively impacting system performance.

[0003] In related technologies, most microservice overload protection is implemented at a single granularity. This can impact the responsiveness of microservices during overload protection. For example, if only a small number of instances experience problems, but the entire microservice is tripped, it can affect other microservices. Therefore, overload protection at a single granularity reduces the robustness of microservices, thus impacting their service quality. Summary of the Invention

[0004] This application provides an overload protection method, apparatus, device, and computer-readable storage medium that can improve the service quality of microservices.

[0005] The technical solution of this application embodiment is implemented as follows:

[0006] This application provides an overload protection method, including:

[0007] The receiving rule configuration device sends at least one circuit breaker rule corresponding to at least one circuit breaker granularity of the target microservice; the at least one circuit breaker granularity specifies the scope level of the circuit breaker.

[0008] Based on each of the at least one circuit breaker rules, statistical indicators are calculated for the execution units within each circuit breaker granularity; the statistical indicators are used to characterize the response of the execution units within each circuit breaker granularity to the request;

[0009] Based on the statistical indicators corresponding to the execution unit and the circuit breaker rules corresponding to each circuit breaker granularity in the at least one circuit breaker rule, the circuit breaker status of the execution unit is determined; the circuit breaker status indicates whether the circuit breaker is activated.

[0010] Based on the circuit breaker status, circuit breaker control is performed on the execution unit within each circuit breaker granularity to achieve overload protection for the target microservice.

[0011] In some embodiments of this application, the statistical indicators include: request failure rate; the step of calculating the statistical indicators for the execution units within each circuit breaker granularity within the statistical period includes:

[0012] The total number of requests made by the execution unit within the statistical period is calculated.

[0013] The number of failed requests by the execution unit within the statistical period is counted; the failed requests represent requests that were not successfully responded to.

[0014] Using the number of failed requests and the total number of requests, the request failure rate of the execution unit within each circuit breaker granularity during the statistical period is calculated.

[0015] In some embodiments of this application, the statistical indicators include: request timeout rate; the statistical indicators for calculating the execution units within each circuit breaker granularity within the statistical period include...

[0016] The total number of requests made by the execution unit within the statistical period is calculated.

[0017] The number of timeout requests by the execution unit within the statistical period is counted; the timeout request represents a request that has timed out.

[0018] Using the number of timeout requests and the total number of requests, the timeout request rate of the execution unit within each circuit breaker granularity in the statistical period is calculated.

[0019] This application provides an overload protection method, including:

[0020] When a circuit breaker rule configuration instruction is received, the system will switch from the current display interface to the circuit breaker configuration interface in response to the instruction; the current display interface can be any display interface.

[0021] In the microservice selection window displayed on the circuit breaker configuration interface, obtain the target microservice for rule configuration, and in the circuit breaker granularity selection window displayed on the circuit breaker configuration interface, extract at least one circuit breaker granularity of the target microservice.

[0022] In the rule configuration window displayed in the rule configuration area of ​​the circuit breaker configuration interface, the configuration parameters for each of the at least one circuit breaker granularity are obtained;

[0023] Using the configuration parameters of each circuit breaker granularity, a circuit breaker rule corresponding to each circuit breaker granularity is generated. When a corresponding circuit breaker rule is generated for each of the at least one circuit breaker granularity, at least one circuit breaker rule corresponding to the at least one circuit breaker granularity is obtained.

[0024] The at least one circuit breaker rule is sent to the overload protection device so that the overload protection device can use the at least one circuit breaker rule to perform overload protection on the target microservice.

[0025] In some embodiments of this application, sending the at least one circuit breaker rule to the overload protection device includes:

[0026] When a screen navigation command is received, the system navigates from the circuit breaker configuration interface to the rule control interface in response to the command; the rule control interface is used to control the at least one circuit breaker rule.

[0027] When a rule-issuing instruction is received on the rule control interface, the at least one circuit breaker rule is sent to the overload protection device in response to the rule-issuing instruction.

[0028] This application provides an overload protection device, including:

[0029] The rule receiving module is used to receive at least one circuit breaker rule sent by the rule configuration device, which corresponds to at least one circuit breaker granularity of the target microservice; the at least one circuit breaker granularity specifies the scope level of the circuit breaker.

[0030] The indicator statistics module is used to calculate the statistical indicators corresponding to the execution units within each circuit breaker granularity based on each of the at least one circuit breaker rule; the statistical indicators are used to characterize the response status of the execution units within each circuit breaker granularity to the request;

[0031] The circuit breaker determination module is used to determine the circuit breaker status of the execution unit based on the statistical indicators corresponding to the execution unit and the circuit breaker rules corresponding to each circuit breaker granularity in the at least one circuit breaker rule; the circuit breaker status indicates whether the circuit breaker is activated.

[0032] The circuit breaker control module is used to perform circuit breaker control on the execution unit within each circuit breaker granularity according to the circuit breaker status, so as to realize overload protection for the target microservice.

[0033] In some embodiments of this application, the circuit breaker rule corresponding to each circuit breaker granularity includes an indicator threshold; the circuit breaker determination module is further configured to determine that the circuit breaker state of the execution unit is enabled when the statistical indicator corresponding to the execution unit is greater than or equal to the indicator threshold; the indicator threshold is specified by the rule configuration device, and the execution unit is a microservice, interface, or instance; when the statistical indicator corresponding to the execution unit is less than the indicator threshold, the circuit breaker state of the execution unit is disabled.

[0034] In some embodiments of this application, the indicator statistics module is further configured to parse a statistical period and a request threshold from each circuit breaker rule; the request threshold is used to determine whether to start acquiring the statistical indicators; based on the statistical period, the number of requests of the execution unit within each circuit breaker granularity is acquired; when the number of requests is greater than or equal to the request threshold, the statistical indicators of the execution unit within each circuit breaker granularity within the statistical period are calculated.

[0035] In some embodiments of this application, the statistical metric includes: request failure rate;

[0036] The indicator statistics module is also used to count the total number of requests made by the execution unit within the statistical period; count the number of failed requests made by the execution unit within the statistical period; the failed request represents a request that was not successfully responded to; and calculate the request failure rate of the execution unit within each circuit breaker granularity within the statistical period using the number of failed requests and the total number of requests.

[0037] In some embodiments of this application, the statistical metrics include: request timeout rate;

[0038] The indicator statistics module is also used to count the total number of requests made by the execution unit within the statistical period; count the number of timeout requests made by the execution unit within the statistical period; the timeout request represents a request that has timed out; and calculate the timeout request rate of the execution unit within each circuit breaker granularity within the statistical period using the number of timeout requests and the total number of requests.

[0039] In some embodiments of this application, the overload protection device further includes: a circuit breaker recovery module; when the circuit breaker state indicates that the circuit breaker is activated, the circuit breaker recovery module is further configured to parse a circuit breaker recovery time threshold and a circuit breaker recovery request threshold from the circuit breaker rules of each circuit breaker granularity; wherein, the circuit breaker recovery time threshold indicates the time required to recover from the circuit breaker activated state to the state allowing a single request, and the circuit breaker recovery request threshold indicates the number of requests required to recover from the state allowing a single request to the normal state; when the circuit breaker duration reaches the circuit breaker recovery time threshold, the execution unit within each circuit breaker granularity is controlled. The circuit breaker is restored from the circuit breaker enabled state to the state where a single request is allowed; the circuit breaker duration represents the time the circuit breaker has been enabled; when the number of circuit breaker requests reaches the circuit breaker recovery request threshold, the request processing index of the execution unit within each circuit breaker granularity is calculated; the number of circuit breaker requests represents the number of requests responded to by the execution unit when the state where a single request is allowed is enabled; when the request processing index is less than the processing index threshold specified by the circuit breaker rule corresponding to each circuit breaker granularity, the execution unit within each circuit breaker granularity is restored from the state where a single request is allowed to the normal state.

[0040] In some embodiments of this application, the circuit breaker determination module is further configured to extract the maximum range circuit breaker granularity with the largest effective range from the at least one circuit breaker granularity; the at least one circuit breaker granularity includes at least one of microservice granularity, interface granularity, and instance granularity; determine the circuit breaker status of the maximum execution unit within the maximum range circuit breaker granularity based on the maximum statistical index corresponding to the maximum execution unit within the maximum range circuit breaker granularity and the maximum range circuit breaker rule corresponding to the maximum range circuit breaker granularity; extract other range circuit breaker granularities besides the maximum range circuit breaker granularity from the at least one circuit breaker granularity; repeat the process of extracting new maximum range circuit breaker granularities from the other range circuit breaker granularities and determining the circuit breaker status of the new maximum execution unit within the new maximum range circuit breaker granularity until the other range circuit breaker granularities are empty, thereby obtaining the circuit breaker status of the execution unit.

[0041] This application provides a rule configuration device, including:

[0042] The instruction receiving module is used to receive circuit breaker rule configuration instructions;

[0043] The interface jump module is used to jump from the current display interface to the circuit breaker configuration interface in response to the circuit breaker rule configuration command; the current display interface can be any display interface;

[0044] The selection extraction module is used to obtain the target microservice for rule configuration in the microservice selection window displayed on the circuit breaker configuration interface, and to extract at least one circuit breaker granularity of the target microservice in the circuit breaker granularity selection window displayed on the circuit breaker configuration interface.

[0045] The parameter acquisition module is used to acquire configuration parameters for each of the at least one circuit breaker granularities in the rule configuration window displayed in the rule configuration area of ​​the circuit breaker configuration interface.

[0046] The rule generation module is used to generate a circuit breaking rule corresponding to each circuit breaking granularity using the configuration parameters of each circuit breaking granularity. When corresponding circuit breaking rules are generated for each of the at least one circuit breaking granularity, at least one circuit breaking rule corresponding to the at least one circuit breaking granularity is obtained.

[0047] The rule sending module is used to send the at least one circuit breaker rule to the overload protection device, so that the overload protection device can use the at least one circuit breaker rule to perform overload protection on the target microservice.

[0048] In some embodiments of this application, the rule sending module is further configured to, upon receiving an interface jump instruction, jump from the circuit breaker configuration interface to the rule control interface in response to the interface jump instruction; the rule control interface is configured to control the at least one circuit breaker rule; and upon receiving a rule sending instruction acting on the sending operation control of the rule control interface, in response to the rule sending instruction, send the at least one circuit breaker rule to the overload protection device.

[0049] This application provides an overload protection device, including:

[0050] The first memory is used to store executable overload protection instructions;

[0051] The first processor is configured to execute executable overload protection instructions stored in the first memory to implement the overload protection method provided by the overload protection device side in this application embodiment.

[0052] This application provides a rule configuration device, including:

[0053] The second memory is used to store executable overload protection instructions;

[0054] The second processor, when executing executable overload protection instructions stored in the second memory, implements the overload protection method provided by the rule configuration device side in the embodiments of this application.

[0055] This application provides a computer-readable storage medium storing executable overload protection instructions, which are used to implement the overload protection method provided by the overload protection side of this application when executed by a first processor; or to implement the overload protection method provided by the rule configuration device side of this application when executed by a second processor.

[0056] The embodiments of this application have the following beneficial effects: the overload protection device can, along with the circuit breaking rules corresponding to each circuit breaking granularity, statistically analyze the corresponding statistical indicators of the execution units within each circuit breaking granularity. Then, by combining the statistical indicators of the execution units within each circuit breaking granularity with the circuit breaking rules of each circuit breaking granularity, it can determine whether to circuit break the execution units. This enables circuit breaking judgment for execution units in one or more circuit breaking granularities, thereby achieving control over circuit breaking at multiple levels of granularity, improving the flexibility of circuit breaking control for microservice systems, enhancing the robustness and availability of microservices, and ultimately improving the service quality of microservices. Attached Figure Description

[0057] Figure 1 This is an optional architecture diagram of the overload protection system 100 provided in this application embodiment;

[0058] Figure 2(a) is an example of an embodiment provided in this application. Figure 1 A schematic diagram of the overload protection device in the diagram;

[0059] Figure 2(b) shows the embodiment provided in this application. Figure 1 A schematic diagram of the structure of the rule configuration device in the diagram;

[0060] Figure 3 This is an optional flowchart illustrating the overload protection method provided in this application embodiment. Figure 1 ;

[0061] Figure 4 This is an example of the circuit breaker configuration interface provided in the embodiments of this application. Figure 1 ;

[0062] Figure 5 Figure 2 is an example of the circuit breaker configuration interface provided in this application embodiment;

[0063] Figure 6 This is a second optional flowchart of the overload protection method provided in the embodiments of this application;

[0064] Figure 7 This application provides an example diagram of a rule control interface.

[0065] Figure 8 This is an example diagram of the interface for configuring rules for a specified microservice, provided in an embodiment of this application. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0067] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0068] The terms “first, second, third, fourth” are used merely to distinguish similar objects and do not represent a specific ordering of objects. Understandably, “first, second, third, fourth” can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0069] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0070] In the implementation of this application, the collection and processing of relevant data should be strictly in accordance with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0071] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0072] 1) Cloud technology refers to a managed technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to realize the computing, storage, processing, and sharing of data.

[0073] Cloud technology is a collective term for network technology, information technology, integration technology, management platform technology, and application technology applied to the cloud computing business model. It can form resource pools, be used on demand, and flexibly accessed. Cloud computing technology will become a crucial support. The backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system backend support, which can be achieved intelligently through cloud computing.

[0074] 2) Microservices refer to breaking down a single service program into a set of small, independent services that coordinate and cooperate with each other to complete the functions provided by the service program. For example, a social application can be divided into data acquisition services, security verification services, etc., and through the collaborative operation of these services, social services are provided to users. Therefore, microservices emphasize loose coupling, independent service deployment, and facilitate improved system fault tolerance.

[0075] 3) Circuit breaking refers to the process where, when a microservice in a microservice system meets certain pre-defined threshold conditions, it is determined that the microservice has encountered a problem and is disconnected from the microservice system to prevent the problematic microservice from affecting other microservices, thereby avoiding the collapse of the entire microservice system. Therefore, circuit breaking is a proactive measure taken by a microservice system to protect itself.

[0076] 4) Circuit breaking granularity represents the scope and level of circuit breaking, that is, the isolation level of microservices. For example, during circuit breaking, it can be performed at the microservice level (i.e., circuit breaking is performed on a single microservice unit), at the application programming interface (API) level (i.e., circuit breaking is performed on a single API unit), or at the instance level (an instance can be understood as a node, process, etc. in a microservice, i.e., circuit breaking is performed on a single instance unit) to isolate the microservice.

[0077] 5) The execution unit refers to the smallest unit of service execution within the circuit breaker granularity. The execution unit differs depending on the circuit breaker granularity. For example, at the microservice granularity, the execution unit is an individual microservice; during circuit breaking, the operation is performed on the microservice, meaning one or more microservices are directly circuit-broken in a given circuit breaker instance. At the API granularity, circuit breaking operates on the API; one or more APIs supporting the microservice's operation are directly circuit-broken in a given circuit breaker instance. At the instance granularity, circuit breaking operates on the instance; one or more instances supporting the microservice's operation, or one or more instances called by the API, are directly circuit-broken in a given circuit breaker instance.

[0078] 6) The time period is the time interval used to statistically analyze the service performance of each execution unit within the circuit breaker granularity. The duration of the time period is fixed. The time period can be understood as a sliding event window, a time range, etc. That is, a sliding event window is used to move left and right on the running time axis of each execution unit, and the indicators within the sliding time window are statistically analyzed only at one time. Thus, the service performance of each execution unit is statistically analyzed multiple times during the running period of each execution unit.

[0079] 7) The circuit breaker state must have at least an open and a closed state. In some cases, the circuit breaker state can also be a half-open state, in which case the execution unit only allows one request to pass through, that is, only one request is processed.

[0080] 8) A fuse is a component specifically used to perform the melting operation. The fuse records metadata such as status and indicators.

[0081] 9) Jitter refers to the rapid fluctuation in the average response time of a service.

[0082] Microservices refer to dividing a single software product into multiple individual services, which work together to provide services to users. In other words, each microservice can be deployed independently, thereby improving system fault tolerance. In practical applications, server complexity increases significantly with the number of services and the number of instances within a single service. Overload protection is designed to prevent a single microservice from becoming too complex, thus avoiding a system-wide collapse caused by a problem with that microservice.

[0083] In related technologies, microservice overload protection is mostly implemented at a single granularity, such as circuit breaking only for a specific service or a method call within a microservice. In other words, circuit breaking in these technologies either applies to a single microservice or a specific method within a microservice. This means that even if only a small number of instances or the API within a microservice experience a problem, the entire microservice or the entire method calling that microservice needs to be circuit broken. This inevitably causes other microservices that depend on that microservice to malfunction, thus impacting the overall service quality of the microservice system. Therefore, it is clear that overload protection at a single granularity reduces the robustness of microservices, thereby affecting their service quality.

[0084] Meanwhile, in related technologies, the recovery of a circuit breaker from an open state that meets set conditions to a closed state is mostly determined by time. For example, when a circuit breaker is open, it may directly return to the closed state after a certain open time without any detection. In this case, if the service does not recover, the microservice system is likely to experience significant instability until the circuit breaker is triggered again. In other cases, although the circuit breaker has a half-open state, it only probes one request. If the request is responded to correctly, the circuit breaker will return to the closed state; if the request is not responded to correctly or not responded to at all, the circuit breaker will remain open. In this case, if the downstream microservice experiences instability, this microservice will also experience instability. Therefore, the recovery control of circuit breakers in related technologies is relatively simple, making the microservice system prone to instability and thus affecting the quality of microservices.

[0085] This application provides an overload protection method, apparatus, device, and computer-readable storage medium, which can improve the service quality of microservices. The following describes exemplary applications of the overload protection device and rule configuration device provided in this application. The overload protection device provided in this application can be implemented as a terminal or a server. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited herein. Exemplary applications of the overload protection device will be described below.

[0086] See Figure 1 , Figure 1FIG. 0 is an optional schematic architecture diagram of the overload protection system 100 provided by an embodiment of the present application. To implement an overload protection application, a rule configuration device 400 is connected to an overload protection device 200 through a network 300. The network 300 can be a wide area network, a local area network, or a combination of both.

[0087] When the rule configuration device 400 receives a fuse rule configuration instruction, in response to the fuse rule configuration instruction, it jumps from the current display interface to the fuse configuration interface 510. The rule configuration device 400 obtains a target microservice for rule configuration in the microservice selection window displayed on the fuse configuration interface 510. The fuse configuration device 500 extracts at least one fuse granularity of the target microservice in the fuse granularity selection window displayed on the fuse configuration interface 510. Then, in the rule configuration window displayed in the rule configuration area of the fuse configuration interface 510, the rule configuration device 400 obtains configuration parameters for each of the at least one fuse granularities, and uses the configuration parameters of each fuse granularity to generate a fuse rule corresponding to each fuse granularity. When fuse rules corresponding to all of the at least one fuse granularities are generated, at least one fuse rule corresponding to the at least one fuse granularities is obtained. Then, the rule configuration device 400 sends the at least one fuse rule to the overload protection device 200 through the network 300.

[0088] The overload protection device 200 receives the at least one fuse rule corresponding to at least one fuse granularity of the target microservice sent by the rule configuration device 400. Here, the at least one fuse granularities indicate the fuse range levels. The overload protection device 200 calculates statistical metrics corresponding to the execution units within each fuse granularity according to each fuse rule in the at least one fuse rule. The statistical metrics are used to represent the response of the execution units within each fuse granularity to requests. Then, the overload protection device 200 determines the fuse status of the execution units based on the statistical metrics corresponding to the execution units and the fuse rules corresponding to each fuse granularity in the at least one fuse rule. The fuse status indicates whether to start fusing. Finally, the overload protection device 200 performs fuse control on the execution units of each fuse granularity according to the fuse status, thereby implementing overload protection for the target microservice.

[0089] In some embodiments, the overload protection device 200 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The rule configuration device 400 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0090] Referring to Figure 2(a), Figure 2(a) is an embodiment provided in this application. Figure 1 A schematic diagram of the overload protection device is shown in Figure 2(a). The overload protection device 200 includes at least one first processor 210, a first memory 250, at least one first network interface 220, and a first user interface 230. The various components of the overload protection device 200 are coupled together via a first bus system 240. It is understood that the first bus system 240 is used to realize the connection and communication between these components. In addition to a data bus, the first bus system 240 also includes a power bus, a control bus, and a status signal bus. However, for clarity, all buses are labeled as the first bus system 240 in Figure 2(a).

[0091] The first processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., wherein the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0092] The first user interface 230 includes one or more first output devices 231 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. The first user interface 230 also includes one or more first input devices 232, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0093] The first memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The first memory 250 may optionally include one or more storage devices physically located remote from the first processor 210.

[0094] The first memory 250 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The first memory 250 described in this application embodiment is intended to include any suitable type of memory.

[0095] In some embodiments, the first memory 250 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0096] The first operating system 251 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, for implementing various basic business functions and handling hardware-based tasks.

[0097] The first network communication module 252 is used to reach other computing devices via one or more (wired or wireless) first network interfaces 220, exemplary first network interfaces 220 including: Bluetooth, Wi-Fi, and Universal Serial Bus (USB), etc.

[0098] The first presentation module 253 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more first output devices 231 (e.g., a display screen, a speaker, etc.) associated with the first user interface 230.

[0099] The first input processing module 254 is configured to detect and translate one or more user inputs or interactions from one or more first input devices 232.

[0100] In some embodiments, the overload protection device provided in this application can be implemented in software. Figure 2(a) shows an overload protection device 255 stored in the first memory 250, which can be software in the form of programs and plug-ins, including the following software modules: rule receiving module 2551, index statistics module 2552, circuit breaker judgment module 2553, circuit breaker control module 2554, and circuit breaker recovery module 2555. These modules are logical, so they can be arbitrarily combined or further split according to the functions implemented.

[0101] The functions of each module will be explained below.

[0102] In other embodiments, the overload protection device provided in this application can be implemented in hardware. As an example, the overload protection device provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the overload protection method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0103] For example, an embodiment of this application provides an overload protection device, including:

[0104] The first memory is used to store executable overload protection instructions;

[0105] The first processor is configured to execute executable overload protection instructions stored in the first memory to implement the overload protection method provided by the overload protection device side in this application embodiment.

[0106] Referring to Figure 2(b), Figure 2(b) is an embodiment provided in this application. Figure 1 A schematic diagram of the rule configuration device is shown in Figure 2(b). The rule configuration device 400 includes at least one second processor 410, a second memory 450, at least one second network interface 420, and a second user interface 430. The various components in the rule configuration device 400 are coupled together via a second bus system 440. It is understood that the second bus system 440 is used to implement communication between these components. In addition to a data bus, the second bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, all buses are labeled as the second bus system 440 in Figure 2(b).

[0107] The second processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0108] The second user interface 430 includes one or more second output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. The second user interface 430 also includes one or more second input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0109] The second memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The second memory 450 may optionally include one or more storage devices physically located remote from the second processor 410.

[0110] The second memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The second memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0111] In some embodiments, the second memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0112] The second operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, for implementing various basic business functions and handling hardware-based tasks.

[0113] The second network communication module 452 is used to reach other computing devices via one or more (wired or wireless) second network interfaces 420, exemplary second network interfaces 420 including: Bluetooth, Wi-Fi, and Universal Serial Bus (USB), etc.

[0114] The second presentation module 453 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more second output devices 431 (e.g., a display screen, a speaker, etc.) associated with the second user interface 430.

[0115] The second input processing module 454 is used to detect and translate one or more user inputs or interactions from one or more second input devices 432.

[0116] In some embodiments, the apparatus provided in this application can be implemented in software. FIG2(b) shows a rule configuration apparatus 455 stored in a second memory 450, which can be software in the form of programs and plug-ins, including the following software modules: instruction receiving module 4551, interface jump module 4552, selection extraction module 4553, parameter acquisition module 4554, rule generation module 4555, and rule sending module 4556. These modules are logical, so they can be arbitrarily combined or further split according to the functions implemented.

[0117] The functions of each module will be explained below.

[0118] In other embodiments, the rule configuration device provided in this application can be implemented in hardware. As an example, the rule configuration device provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the rule configuration method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0119] For example, an embodiment of this application provides a rule configuration device, including:

[0120] The second memory is used to store executable overload protection instructions;

[0121] The second processor, when executing executable overload protection instructions stored in the second memory, implements the overload protection method provided by the rule configuration device side in the embodiments of this application.

[0122] The overload protection method provided in this application will be described below with reference to exemplary applications and implementations of the overload protection device and rule configuration device provided in the embodiments of this application. It should be noted that this application can be implemented using cloud technology.

[0123] See Figure 3 , Figure 3 This is an optional flowchart illustrating the overload protection method provided in this application embodiment. Figure 1 , will combine Figure 3The steps shown are explained below. It should be noted that this application can be implemented using cloud technology.

[0124] S101. When the rule configuration device receives the circuit breaker rule configuration instruction, it responds to the circuit breaker rule configuration instruction by jumping from the current display interface to the circuit breaker configuration interface.

[0125] This application embodiment is implemented in a scenario where circuit breaker rules are configured manually or automatically for microservices, and overload protection is provided to the target microservices according to the configured rules, thereby preventing service quality from being affected by microservice problems. In this scenario, the rule configuration device monitors and parses each received instruction in real time to determine what operation is required. When the rule configuration device receives an instruction to start configuring circuit breaker rules for the microservice, it immediately responds by jumping from the current display interface to the circuit breaker rule configuration interface, so that configuration parameters can be selected subsequently in the circuit breaker rule configuration interface.

[0126] It should be noted that the current display interface is arbitrary. This means that before receiving the circuit breaker rule configuration command, the rule configuration device can display any interface, such as the standby screen, a video screen, or the user interface of office software. However, once the rule configuration device receives the circuit breaker rule configuration command, it will immediately create and generate the circuit breaker configuration interface and then enter that interface to begin configuring the circuit breaker rules as quickly as possible.

[0127] It is understandable that circuit breaker rule configuration commands can be triggered manually. For example, microservice administrators can trigger the circuit breaker configuration command by touching the circuit breaker rule trigger control on the display interface of the rule configuration device, or by speaking the voice command "Start circuit breaker rule configuration" to the circuit breaker configuration device. Circuit breaker rule configuration commands can also be triggered by the rule configuration device itself. For example, the rule configuration device can trigger the circuit breaker rule configuration command at a fixed time to enter the circuit breaker configuration interface. This could be when microservice administrators have set up adjustments to the circuit breaker rules on the 1st of each month, or when the microservice system is first built and needs to be reminded to configure the circuit breaker rules in a timely manner to improve the robustness of the microservice system. The specific triggering method for the circuit breaker rule configuration command can be set according to actual needs, and this application embodiment does not limit it.

[0128] S102. The rule configuration device obtains the target microservice for rule configuration in the microservice selection window displayed on the circuit breaker configuration interface, and extracts at least one circuit breaker granularity of the target microservice in the circuit breaker granularity selection window displayed on the circuit breaker configuration interface.

[0129] After entering the circuit breaker configuration interface, the rule configuration device can retrieve the currently selected microservice from the microservice selection window displayed in the interface. This retrieved microservice is the target microservice for rule configuration as determined by the rule configuration device. Therefore, the microservice to be configured can be specified through the microservice selection window in the circuit breaker configuration interface. Simultaneously, the rule configuration device will also retrieve the currently selected level granularity from the circuit breaker granularity selection window displayed in the interface. This level granularity is the circuit breaker granularity. Since the level granularity selectable in the circuit breaker granularity selection window can be one (e.g., microservice granularity) or multiple (e.g., microservice granularity and instance granularity), the rule configuration device can retrieve at least one circuit breaker granularity. In other words, the level granularity for rule configuration can be executed through the circuit breaker granularity selection window in the circuit breaker configuration interface.

[0130] It is understandable that the microservice selection window can be set in the first preset area of ​​the circuit breaker configuration interface. The size and position of this first preset area can be set according to actual needs. For example, the first preset area can be set at the top of the circuit breaker configuration interface with a size of 100×50, or it can be set on the left side of the circuit breaker configuration interface with a size of 100×100, etc. In some embodiments of this application, the microservice currently selected in the microservice selection window, i.e., the target microservice, can be manually selected. For example, the microservice administrator can select the target microservice through a drop-down menu provided in the microservice selection window, or the microservice administrator can select the target microservice by entering the microservice's number or name in the microservice selection window. In other embodiments, the microservice currently selected in the microservice selection window can also be automatically filled in by the rule configuration device. For example, when entering the circuit breaker configuration interface, the rule setting device fills in the default microservice in the microservice selection window, thereby using the default microservice as the target microservice. Alternatively, the rule setting device can directly fill in the microservice that is filled in the most times in the microservice selection window, thereby using the microservice that is filled in the most times as the target microservice.

[0131] Similarly, the circuit breaker granularity selection window can be set in the second preset area of ​​the circuit breaker configuration interface. The size and position of this second preset area can be set according to actual needs. For example, the second preset area can be set in the upper right part of the circuit breaker configuration interface with a size of 100×50, or it can be set in the lower left part of the interface with a size of 100×100. Furthermore, the currently selected level granularity in the circuit breaker granularity selection window can be manually selected or automatically filled in by the rule configuration device; this embodiment does not limit this selection.

[0132] For example, this application provides a sample of a circuit breaker configuration interface. Figure 1 See Figure 4 In the upper part of the circuit breaker configuration interface 4-1, there are two windows: a microservice selection window 4-11 and a circuit breaker granularity window 4-12. The microservice selection window 4-11 contains the microservice entered by the microservice administrator through a drop-down menu (not shown): consumer-demo4-111. The circuit breaker granularity selection window 4-12 contains the level granularity automatically filled in by the rule configuration device: microservice 4-121.

[0133] S103. The rule configuration device obtains the configuration parameters for each of the at least one fuse granularity in the rule configuration window displayed in the rule configuration area of ​​the fuse configuration interface.

[0134] The rule configuration device also extracts the content entered in one or more rule configuration windows in the rule configuration area of ​​the circuit breaker configuration interface, and uses this extracted content as configuration parameters to obtain configuration parameters for each circuit breaker granularity, so that the circuit breaker rules can be generated subsequently using the configuration parameters. It is understandable that there may be more than one rule configuration window displayed in the rule configuration area.

[0135] It should be noted that since the rule configuration device may extract more than one circuit breaker granularity from the circuit breaker granularity selection window, the configuration parameters extracted by the rule configuration device from each rule configuration window are for all extracted circuit breaker granularities. In other words, when there are multiple different circuit breaker granularities in the circuit breaker granularity selection window, the rule configuration device will use the parameters extracted from each rule configuration window as the configuration parameters corresponding to each circuit breaker granularity.

[0136] In some embodiments of this application, the rule configuration window can be a time period setting window, a request quantity setting window, a trigger indicator condition setting window, etc. Correspondingly, the configuration parameters can be used to obtain the time period for statistical indicators, the request threshold for determining whether to start statistical indicators, and the indicator threshold for determining whether to initiate circuit breaking. In other embodiments, the rule configuration window may also include a circuit breaker recovery time threshold setting window and a circuit breaker recovery request threshold setting window. Correspondingly, the configuration parameters may include the circuit breaker recovery time threshold and the circuit breaker recovery request threshold. Of course, the rule configuration window may also include other content, such as the units corresponding to each configuration parameter and descriptions of the configuration parameters, etc., which are not limited herein.

[0137] It is understood that the rule configuration area can be set in the third preset area of ​​the circuit breaker configuration interface. Similarly, the size and position of the third preset area can also be set according to the actual situation. For example, the third preset area can be set in the lower half of the circuit breaker configuration interface with a size of 1000×500, or the third preset area can be set in the right half of the circuit breaker configuration interface with a size of 500×500, etc. This application does not limit this.

[0138] Furthermore, the position and size of each rule configuration window in the rule configuration area can also be set according to actual needs. For example, the rule configuration windows can be arranged sequentially on the left side of the rule configuration area, each with a size of 100×50, or the rule configuration windows can be arranged sequentially on the right side of the rule configuration area, each with a size of 100×100, etc. This application does not limit this.

[0139] For example, this application provides a sample diagram of the circuit breaker configuration interface, see Figure 2. Figure 5In the lower half of the circuit breaker configuration interface 5-1, there is a rule configuration area 5-11. Within rule configuration area 5-11, there are windows for setting time period (5-12), request quantity (5-13), and three trigger indicator condition settings (5-14, 5-15, and 5-16), each used to receive different indicator thresholds. Specifically, the currently selected time period in time period setting window 5-12 is 10 seconds, and the currently selected request quantity setting window 5-13 has a current request threshold of 10 times. In area 5-15, the three trigger indicator condition setting windows and brief explanations of the thresholds for these three indicators are also displayed. For example, around window 5-14, it shows that a circuit breaker will be triggered when the percentage reaches __% (5-141), while window 5-14 shows 50, indicating that a circuit breaker will be triggered when the percentage reaches 50%. Around window 5-15, it shows that requests with a response time exceeding __ milliseconds are considered timed out (5-151), while window 5-15 shows 60000, indicating that a request with a response time of 60000 milliseconds is a timed-out request. Around window 5-16, it shows that a circuit breaker will be triggered when the percentage of timed-out requests reaches __% (5-161), while window 5-16 shows 50, indicating that a circuit breaker will be triggered when the percentage of timed-out requests reaches 50%. This, combined with the text, more clearly indicates what the parameters entered are.

[0140] S104. The rule configuration device uses the configuration parameters of each fuse granularity to generate the fuse rule corresponding to each fuse granularity. When corresponding fuse rules are generated for at least one fuse granularity, at least one fuse rule corresponding to at least one fuse granularity is obtained.

[0141] After obtaining the configuration parameters for each circuit breaker granularity, the rule configuration device packages and integrates these parameters to generate a circuit breaker rule corresponding to each granularity. When the rule configuration device has generated corresponding circuit breaker rules for all circuit breaker granularities in at least one circuit breaker granularity in this manner, the rule configuration device obtains at least one circuit breaker rule corresponding to at least one circuit breaker granularity.

[0142] It should be noted that the rule configuration device can directly package and integrate the configuration parameters of each circuit breaker granularity to obtain the circuit breaker rule corresponding to each circuit breaker granularity. Alternatively, it can process and calculate the configuration parameters, such as rounding the configuration parameters or weighting the most commonly used configuration parameters corresponding to each configuration parameter, and then package and organize the processed configuration parameters to obtain the circuit breaker rule corresponding to each circuit breaker implementation.

[0143] S105. The overload protection device receives at least one circuit breaker rule sent by the rule configuration device, which corresponds to at least one circuit breaker granularity of the target microservice.

[0144] In some embodiments of this application, the rule configuration device may send at least one circuit breaker rule directly to the overload protection device via the network after obtaining at least one circuit breaker rule, or it may send at least one circuit breaker rule to the overload protection device after obtaining at least one circuit breaker rule and receiving a rule issuance instruction.

[0145] It is understandable that rule issuance commands can be triggered manually, such as by microservice administrators; rule issuance commands can also be triggered by rule configuration devices, for example, the rule configuration device can automatically trigger rule issuance commands when a preset time is reached.

[0146] It should be noted that at least one circuit breaker granularity specifies the scope level of the circuit breaker. The execution and processing of requests within each circuit breaker scope level are implemented by individual execution units belonging to that scope level. Therefore, when the overload protection device performs overload protection on the target microservice, it essentially determines whether to circuit breaker some execution units within a certain circuit breaker scope level. In the embodiments of this application, at least one circuit breaker granularity includes any one or more of microservice granularity, interface granularity, and instance granularity. That is, at least one circuit breaker granularity may include only one of microservice granularity, interface granularity, and instance granularity, or it may include multiple of these granularities; this application does not impose any limitations on this.

[0147] S106. The overload protection device, based on each of the at least one circuit breaker rules, calculates the statistical indicators corresponding to the execution unit within each circuit breaker granularity.

[0148] After obtaining at least one circuit breaker rule, the overload protection device will obtain the statistical indicators of each execution unit within each circuit breaker granularity according to the method of obtaining statistical indicators provided in each circuit breaker rule. This will facilitate the subsequent use of statistical indicators to determine whether the execution unit within each circuit breaker granularity needs to be circuit breakered.

[0149] It should be noted that statistical metrics are used to characterize the response of the execution unit to the request within each circuit breaker granularity. The response of the request can indicate whether there is a problem with the processing performance of the execution unit. In other words, statistical metrics indicate the performance of the execution unit within each circuit breaker granularity.

[0150] It is understandable that, for the entire microservice system, requests at different circuit breaker granularities are handled and implemented by separate execution units. Therefore, the execution unit should correspond to the circuit breaker granularity. Thus, in the embodiments of this application, the execution unit is a microservice, an interface, or an instance. Specifically, when the circuit breaker granularity includes a microservice granularity, the execution unit can be a microservice; when the circuit breaker granularity is an interface granularity, the execution unit can be an interface; and when the circuit breaker granularity includes an instance granularity, the execution unit can be an instance. In some embodiments of this application, when at least one circuit breaker granularity includes multiple of the microservice, interface, and instance granularities, there will also be multiple execution units. For example, when at least one circuit breaker granularity includes both microservice and instance granularities, the execution units are also microservice and instance, respectively.

[0151] Since the triggering conditions differ for different triggering granularities, in this embodiment, the decision to activate the circuit breaker is based on the execution unit's response to the request, i.e., through statistical indicators. Therefore, the methods for obtaining statistical indicators provided by the triggering rules corresponding to different triggering granularities should also be different. To accurately trigger circuit breakers at different triggering granularities, the overload protection device needs to first obtain the statistical indicators corresponding to each granularity. Therefore, the overload protection device obtains the statistical indicators according to the methods provided in the triggering rules corresponding to different triggering granularities.

[0152] It should be noted that the circuit breaker rules can provide the time period for obtaining statistical metrics, i.e., the statistical period, or the trigger threshold for starting to obtain statistical metrics. This trigger threshold can be a request threshold, i.e., specifying how many requests must be received within the statistical period before obtaining statistical metrics can begin; or it can be a duration threshold, i.e., specifying how long the response time of a request must be before obtaining statistical metrics can begin, etc.

[0153] In some embodiments of this application, the statistical metric may be the request failure rate, the request timeout rate, or other metrics, such as the duration of the request response, etc., which are not limited here.

[0154] It should be noted that the same statistical metric can be obtained in the same or different ways at different circuit breaker granularities. For example, the statistical metric for both microservice and interface granularities may be request failure rate, but the statistical period for microservice granularity may be 10 seconds, while the statistical period for interface granularity may be 5 seconds; the statistical metric for both microservice and instance granularities may be request timeout rate, and the statistical period for both may be 10 seconds, etc.

[0155] S107. The overload protection device determines the fuse status of the execution unit based on the statistical indicators corresponding to the execution unit and the fuse rule corresponding to each fuse granularity in at least one fuse rule; the fuse status indicates whether the fuse is activated.

[0156] After obtaining the statistical indicators corresponding to the execution units within each fuse granularity, the overload protection device first parses the fuse rules for each granularity to obtain the indicator thresholds specified by the fuse rules for each granularity. Then, the overload protection device compares the statistical indicators with the parsed indicator thresholds to determine whether to activate the fuse for the execution unit, thus obtaining the fuse status corresponding to the execution unit within each fuse granularity. In other words, the overload protection device determines whether to activate the fuse for the execution unit based on the statistical indicators of the execution unit and the indicator thresholds specified by each fuse rule.

[0157] Therefore, in this application, when the circuit breaker granularity includes the microservice granularity, the overload protection device, when performing overload protection on the target microservice, determines whether to apply circuit breaker to a specific microservice. When the circuit breaker granularity includes the interface granularity, the overload protection device determines whether to apply circuit breaker to a specific interface. When the circuit breaker granularity includes the instance granularity, the overload protection device determines whether to apply circuit breaker to a specific instance. Thus, when performing overload protection on the target microservice, the determination of which specific object to apply circuit breaker to can be based on multiple different levels of granularity.

[0158] In some embodiments of this application, the overload protection device also determines the circuit breaker status according to the order of the level granularity. That is, when at least one circuit breaker granularity includes multiple circuit breaker granularities, the overload protection device will first determine the circuit breaker granularity with a larger effective range, and then determine the circuit breaker granularity with a smaller effective range. For example, when at least one circuit breaker granularity includes microservice granularity and interface granularity, the overload protection device first determines the circuit breaker status for each execution unit in the microservice granularity, and then determines the circuit breaker status for each execution range in the interface granularity.

[0159] S108. The overload protection device performs circuit breaking control on the execution unit within each circuit breaking granularity according to the circuit breaking status, thereby achieving overload protection for the target microservice.

[0160] The overload protection device performs circuit breaker control on each execution unit within the determined circuit breaker granularity. When the circuit breaker status of an execution unit indicates that the circuit breaker is open, the overload protection device will activate the circuit breaker for that execution unit. Conversely, when the circuit breaker status of an execution unit indicates that the circuit breaker is closed, the overload protection device will keep the circuit breaker closed for that execution unit, thus allowing various requests to continue to pass. This allows for circuit breaker control of execution units at different circuit breaker granularities, thereby improving the flexibility of circuit breaker control in microservice systems.

[0161] It's important to note that when the circuit breaker granularity is at the microservice level, and the target microservice's performance degradation is due to problems with its dependent downstream microservices, the overload protection device will apply circuit breakers to the downstream microservices it depends on when providing overload protection for the target microservice. Conversely, if the target microservice experiences a problem due to its own internal issues, the overload protection device will apply circuit breakers to the target microservice itself to prevent the entire microservice system from crashing. When the circuit breaker granularity is at the interface level, the overload protection device will directly apply circuit breakers to the interface as soon as it identifies the problematic one. Similarly, when the circuit breaker granularity is at the instance level, the overload protection device will directly apply circuit breakers to the instance as soon as it identifies the problematic one, regardless of which microservice the interface or instance belongs to.

[0162] In this embodiment, the overload protection device can calculate the statistical indicators corresponding to the execution units within each circuit breaker granularity based on the circuit breaker rules corresponding to each circuit breaker granularity. Then, by combining the statistical indicators of the execution units within each circuit breaker granularity with the circuit breaker rules of each circuit breaker granularity, it can determine whether to circuit breaker the execution units. This enables circuit breaker judgment for execution units in one or more circuit breaker granularities, thereby achieving control over circuit breakers at multiple granularity levels. This improves the flexibility of circuit breaker control for microservice systems, enhances the robustness and availability of microservices, and ultimately improves the service quality of microservices.

[0163] In some embodiments of this application, the fusing rule corresponding to each fusing granularity includes an index threshold. In this case, the overload protection device determines the fusing state of the fusing unit based on the statistical index corresponding to the execution unit and at least one fusing rule corresponding to each fusing granularity. The implementation process of S107 may include: S1071 or S1072, as follows:

[0164] S1071. When the statistical index corresponding to the execution unit is greater than or equal to the index threshold, the overload protection device determines that the fuse state of the execution unit is open.

[0165] S1072. When the statistical index corresponding to the fuse unit is less than the index threshold, the overload protection device determines the fuse state of the execution unit to be closed fuse.

[0166] The overload protection device compares the statistical indicators corresponding to the execution unit within each circuit breaker granularity with the indicator thresholds specified by the circuit breaker rules for each granularity. When the statistical indicator corresponding to the execution unit is greater than or equal to the indicator threshold, it indicates that the performance of the execution unit is very low, and circuit breaker protection is required for the execution unit. In this case, the overload protection device will determine the circuit breaker status of the execution unit to be enabled to prevent the execution unit from affecting the overall performance of the microservice system. When the statistical indicator is less than the indicator threshold, it indicates that the performance of the execution unit is still relatively normal, that is, it can respond to and process requests in a timely manner. In this case, the overload protection device will determine the circuit breaker status to remain disabled, that is, circuit breaker protection will not be enabled, thus allowing the execution unit to operate normally. The execution unit can be a microservice, interface, or instance.

[0167] It should be noted that the metric threshold is specified by the rule configuration device and corresponds to the statistical metric. That is, when the statistical metric is the request failure rate, the metric threshold can be the failure rate threshold; when the statistical metric is the timeout request rate, the metric threshold is the timeout rate threshold; and when the statistical metric is the request response time, the metric threshold is the timeout threshold.

[0168] It is understandable that the specific value of the indicator threshold can be set according to the actual situation. For example, when the indicator threshold is the failure rate threshold or the timeout rate threshold, the indicator threshold can be set to 50% or 70%; when the indicator threshold is the duration of the request response, the indicator threshold can be set to 10s or 5s, etc. This application does not limit it here.

[0169] In this embodiment of the application, the overload protection device can determine whether to initiate the circuit breaker for the execution unit based on the relationship between the index threshold and the statistical index, thereby realizing the judgment of the circuit breaker status of the execution unit.

[0170] See Figure 6 , Figure 6 This is a second optional flowchart of the overload protection method provided in this application. In some embodiments of this application, the overload protection device calculates the statistical index corresponding to the execution unit within each fuse granularity based on each fuse rule in at least one fuse rule. That is, the specific implementation process of S106 may include: S1061-S1063, as follows:

[0171] S1061, the overload protection device parses the statistical period and request threshold from each circuit breaker rule; the request threshold is used to determine whether to start acquiring statistical indicators.

[0172] The overload protection device parses each circuit breaker rule in at least one circuit breaker rule, breaks down each circuit breaker rule into configuration parameters corresponding to each circuit breaker granularity, and then extracts two parameters, namely the statistical period and the request threshold, from each configuration parameter. This is to facilitate the subsequent acquisition of statistical indicators within the statistical period for the execution unit, and to use the request threshold to determine whether to start acquiring the corresponding statistical indicators for the execution unit.

[0173] It's important to note that using a request threshold to determine whether to start acquiring statistical metrics is necessary because if the number of requests within a statistical period is relatively small, these requests are highly likely to be responded to normally, meaning there's no need to activate the circuit breaker. Acquiring statistical metrics in this case would be a waste of hardware resources. Furthermore, when the number of requests within a statistical period is low, the process of determining whether to activate the circuit breaker relies too heavily on individual requests, introducing noise into the determination of the circuit breaker status and lowering the accuracy of the determination. Therefore, overload protection devices need to use a request threshold to determine whether to start acquiring statistical metrics.

[0174] It is understood that in this embodiment, the statistical period can be set in the rule configuration device according to actual needs, for example, the statistical period can be set to 10s or 20s, etc., and this application does not impose any restrictions here. Similarly, the request threshold can also be set in the rule configuration device according to actual needs, for example, the request threshold can be set to 10 or 5, etc., and this application does not impose any restrictions here.

[0175] S1062. The overload protection device obtains the number of requests from the execution unit within each fuse granularity according to the statistical period.

[0176] After parsing the statistical period and request threshold, the overload protection device will start extracting requests within the statistical period closest to the current time, and then count the number of these extracted requests to obtain the number of requests per execution unit.

[0177] It is understandable that the statistical period closest to the current time can refer to a statistical period preceding the current time. For example, when the statistical period is 10 seconds, the overload protection device extracts all requests from the 10 seconds preceding the current time.

[0178] S1063. When the number of requests is greater than or equal to the request threshold, the overload protection device calculates the statistical indicators of the execution unit within each circuit breaker granularity within the statistical period.

[0179] After receiving the number of requests, the overload protection device compares this number with the parsed request threshold. If the number of requests is greater than or equal to the threshold, the overload protection device considers that each execution unit at each circuit breaker granularity has enough requests within a statistical period to determine whether to activate the circuit breaker. In this case, the overload protection device begins to calculate the statistical indicators for each execution unit within the statistical period. If the number of requests is less than the threshold, the overload protection device considers that the number of requests for each execution unit at each circuit breaker granularity is insufficient to determine whether to activate the circuit breaker. In this case, the overload protection device does not calculate the statistical indicators for each execution unit within the statistical period.

[0180] Understandably, the statistical method for calculating statistical indicators is determined based on the specific content of the statistical indicator. When the statistical indicator is the request failure rate or request timeout rate, the overload protection device calculates it based on the number of failed requests, or the number of timeout requests and the total number of requests; when the statistical indicator is the duration of request timeout, the overload protection device directly obtains the timeout duration of each request.

[0181] In this embodiment, the overload protection device can parse the statistical period and request threshold from the circuit breaking rules corresponding to each circuit breaking granularity, and then obtain the number of requests of the execution unit based on the statistical period. Only when the number of requests is greater than the request threshold will the statistical indicators of the execution unit be counted, thereby avoiding noise to the circuit breaking status judgment when the number of requests is too small, and ensuring the accuracy of the circuit breaking status judgment.

[0182] In some embodiments of this application, the statistical indicators include: request failure rate. In this case, the overload protection device calculates the statistical indicators of the execution unit within each fuse granularity within the statistical period. That is, the specific implementation process of S1063 may include: S301-S303, as follows:

[0183] S301, the overload protection device counts the total number of requests from the executing unit within the statistical period.

[0184] S302. The overload protection device counts the number of failed requests from the executing unit within the statistical period.

[0185] Among them, a failed request represents a request that was not successfully responded to.

[0186] The overload protection device first counts the number of all requests within the statistical period to obtain the total number of requests received by the execution unit within the statistical period. Then, the overload protection device extracts the requests that were not successfully responded to from all the requests received by the execution unit, that is, extracts the failed requests, and then counts the number of failed requests.

[0187] S303. The overload protection device uses the number of failed requests and the total number of requests to calculate the request failure rate of the execution unit within each circuit breaker granularity in the statistical period.

[0188] After obtaining the number of failed requests and the total number of requests, the overload protection device will use the number of identified requests as the numerator and the total number of requests as the denominator to perform a proportional calculation. The result of the proportional calculation will be used as the request failure rate within the execution unit of each circuit breaker granularity in that statistical period.

[0189] In this embodiment, the overload protection device can count the total number of requests from the execution unit within a statistical period, and simultaneously count the number of failed requests that were not successfully responded to. Then, the number of failed requests is compared with the total number to obtain the request failure rate. In this way, the overload protection device extracts statistical indicators, which can be used subsequently to determine whether to activate the circuit breaker for the execution unit.

[0190] In some embodiments of this application, the statistical indicators include: request timeout rate. In this case, the overload protection device calculates the statistical indicators of the execution unit within each fuse granularity within the statistical period. That is, the specific implementation process of S1063 may include: S304-S306, as follows:

[0191] S304. The overload protection device counts the total number of requests from the executing unit within the statistical period.

[0192] S305. The overload protection device counts the number of timeout requests from the executing unit within the statistical period.

[0193] Among them, timeout request represents a request that timed out.

[0194] When the statistical indicators include the request timeout rate, the overload protection device, when calculating the statistical indicators of the execution unit, first calculates the total number of requests made by the execution unit within the statistical period. Then, from all the requests made by the execution unit within the statistical period, the overload protection device extracts the timeout requests, obtains the timeout requests, and calculates the number of timeout requests.

[0195] S306. The overload protection device uses the number of timeout requests and the total number of requests to calculate the timeout request rate of the execution unit within each circuit breaker granularity in the statistical period.

[0196] The overload protection device uses the number of timeout requests as the numerator and the total number of requests as the denominator to perform a proportional calculation. The result of this calculation is used as the request overrun rate of the execution unit within the statistical period. In this way, the overload protection device completes the process of obtaining statistical indicators.

[0197] In this embodiment, the overload protection device can count the total number of requests from the execution unit within a statistical period, as well as the number of timed-out requests. Then, it compares the number of timed-out requests with the total number to obtain the request timeout rate. In this way, the overload protection device extracts statistical indicators, which can be used subsequently to determine whether to activate the circuit breaker for the execution unit.

[0198] In some embodiments of this application, when the circuit breaker state indicates that the circuit breaker is activated, the overload protection device performs circuit breaker control on each execution unit at each circuit breaker granularity according to the circuit breaker state to achieve overload protection for the target microservice. That is, after S108, the method may further include: S109-S112, as follows:

[0199] S109. The overload protection device parses the fuse recovery time threshold and fuse recovery request threshold from the fuse rules of each fuse granularity.

[0200] Among them, the circuit breaker recovery time threshold represents the time required to recover from the circuit breaker enabled state to the state where a single request is allowed, and the circuit breaker recovery request threshold represents the number of requests required to recover from the state where a single request is allowed to the normal state.

[0201] After determining that the circuit breaker needs to be activated for each execution unit at each circuit breaker granularity and activating it, the overload protection device must also be able to promptly determine whether these execution units can end the circuit breaker and return to a normal state. At this point, the overload protection device will continue to parse the circuit breaker rules for each circuit breaker granularity, extracting the circuit breaker recovery time threshold for determining whether the execution unit can recover from the circuit breaker activated state to the state allowing a single request (i.e., recovering to the circuit breaker half-open state), and the number of requests for determining whether the execution unit can recover from the circuit breaker half-open state to the circuit breaker closed state (i.e., the normal state).

[0202] It is understood that the circuit breaker recovery time threshold can be set in the rule configuration device according to the actual situation, for example, the circuit breaker recovery time threshold can be set to 10s or 20s, and this application does not limit it here. Similarly, the circuit breaker recovery request threshold can be set in the rule configuration device according to the actual situation, for example, the circuit breaker recovery request threshold can be set to 5 or 10, and this application does not limit it here.

[0203] S110. When the duration of the circuit breaker reaches the circuit breaker recovery time threshold, the overload protection device controls the execution unit within each circuit breaker granularity to return from the circuit breaker open state to the state that allows a single request.

[0204] The duration of the circuit breaker indicates the time during which the circuit breaker has been activated.

[0205] The overload protection device starts timing the moment the actuator begins to blow the fuse, and the recorded time is the fuse duration. When the fuse duration reaches the fuse recovery time threshold for an extended period, the overload protection device will change the actuator's fuse status from open to half-open, allowing the actuator to respond to and process only a single request at a time. This allows the device to determine whether the actuator has returned to normal based on its response to and processing of individual requests.

[0206] It should be noted that when the fuse recovery time threshold is long, such as longer than the commonly used fault recovery time, the execution unit is very likely to recover normally during the waiting time until the recovery time threshold is reached. In this case, when the overload protection device reaches the fuse recovery time threshold, it changes the fuse state of the execution unit to fuse half-open, which can effectively reduce jitter. However, this method will undoubtedly increase the fault recovery time.

[0207] Conversely, when the fuse recovery time threshold is short, such as the fault recovery time commonly used in phrases, the execution unit may not have fully recovered to normal. In this case, when the overload protection device reaches the fuse recovery time threshold, it will change the fuse state of the execution unit from fuse open to fuse half open, which will greatly reduce the fault recovery time, but may increase the possibility of jitter.

[0208] S111. When the number of circuit breaker requests reaches the circuit breaker recovery request threshold, the overload protection device counts the request processing indicators of the execution unit within each circuit breaker granularity.

[0209] The circuit breaker request count represents the number of requests that the execution unit responds to when the state of allowing a single request is enabled.

[0210] When the overload protection device starts operating in a single-request-allowed state, it monitors whether the device can handle individual requests normally to determine if it has fully recovered. When the overload protection device detects that the number of requests processed by the device in the single-request-allowed state reaches the circuit breaker recovery request threshold, it indicates that the device has responded to and processed a sufficient number of requests in the half-open circuit breaker state. At this point, the overload protection device analyzes the request processing metrics for each circuit breaker-level device to clarify the overall processing status of these requests and determine whether the device has fully recovered.

[0211] In some embodiments of this application, the request processing indicator can be the request processing failure rate. In this case, the overload protection device will first count the total number of requests processed by the execution unit when the circuit breaker is in a half-open state, and then count the number of requests that failed to be processed by the execution unit when the circuit breaker is in a half-open state. The number of failed requests is then compared with the total number of requests processed, and the ratio is used as the request processing indicator.

[0212] In some other embodiments of this application, the request processing metric can be the request timeout failure rate. In this case, the overload protection device will first count the total number of requests processed by the execution unit when the circuit breaker is in a half-open state, and then count the number of requests that timed out when the execution unit is in a half-open state. The number of requests that timed out is compared with the total number of requests processed, and the ratio is used as the request processing metric.

[0213] S112. When the request processing index is less than the processing index threshold specified by the circuit breaker rule corresponding to each circuit breaker granularity, the overload protection device restores the execution unit of each circuit breaker granularity from the state that allows a single request to the normal state.

[0214] The overload protection device parses the specified processing indicator threshold from the circuit breaker rules corresponding to each circuit breaker granularity. It then compares the request processing indicator with the threshold value to obtain a comparison result representing the relationship between the two. When the comparison result indicates that the request processing indicator is less than the specified threshold value, the overload protection device considers the execution unit at each circuit breaker granularity to have fully recovered. At this point, the overload protection device restores the execution unit from the state allowing only a single request (i.e., the circuit breaker half-open state) to the normal state, enabling the execution unit to respond to and process requests normally. In this way, the overload protection device can judge the execution unit's response to requests to determine whether the execution unit should be restored to the normal state, avoiding the situation where the circuit breaker is closed based on only one request.

[0215] In this embodiment, the overload protection device restores the execution unit from the circuit breaker open state to the circuit breaker half-open state when the circuit breaker open time reaches the circuit breaker recovery time threshold. Then, when the requests responded to and processed during the circuit breaker half-open state reach the circuit breaker recovery request threshold, the device calculates the request processing indicators of the execution unit. Only when the request processing indicators meet the requirements is the execution unit within each circuit breaker granularity restored to the normal state. This avoids the situation of closing the circuit breaker based on only one request, increases control over the circuit breaker state recovery, and further improves the quality of microservices.

[0216] In some embodiments of this application, the overload protection device determines the fusing state of the execution unit based on the statistical indicators corresponding to the execution unit and the fusing rules corresponding to each fusing granularity in at least one fusing rule. That is, the specific implementation of S107 may include: S1073-S1076, as follows:

[0217] S1073. The overload protection device extracts the maximum range of the circuit breaking granularity from at least one circuit breaking granularity; the at least one circuit breaking granularity includes at least one of microservice granularity, interface granularity, and instance granularity.

[0218] S1074. The overload protection device determines the melting status of the largest actuator within the maximum range of melting granularity based on the maximum statistical index corresponding to the largest actuator within the maximum range of melting granularity and the maximum range melting rule corresponding to the maximum range of melting granularity.

[0219] In this embodiment, the overload protection device can also determine the order of fusing judgment for each fusing particle based on its effective range. First, the overload protection device analyzes at least one fusing particle and extracts the fusing particle with the largest effective range to obtain the maximum range fusing particle. Then, based on the execution unit within the maximum range fusing particle (i.e., the maximum statistical index corresponding to the maximum execution unit) and the maximum range fusing rule corresponding to the maximum fusing particle, the overload protection device determines the fusing state of the maximum execution unit, thus enabling it to prioritize the fusing state judgment for each execution unit within the fusing particle with the largest effective range.

[0220] S1075. Overload protection device extracts the range of fusing particles other than the maximum range of fusing particles from at least one fusing particle size.

[0221] S1076. The overload protection device repeatedly extracts a new maximum range of fusing granularity from other ranges and determines the fusing status of the new maximum execution unit within the new maximum range of fusing granularity until the other ranges of fusing granularity are empty, thus obtaining the fusing status of the execution unit.

[0222] Next, the overload protection device extracts the remaining fusing granularities (excluding the maximum fusing granularity) from at least one fusing granularity. It then finds the fusing granularity with the largest effective range among these remaining granularities and designates it as the new maximum effective range fusing granularity. The device then determines the fusing status of each actuator within this new maximum effective range fusing granularity, thus obtaining the fusing status of the new maximum actuator. The overload protection device repeats this process until all other fusing granularities are empty. At this point, the fusing status of the actuators within each fusing granularity can be obtained in order of increasing effective range.

[0223] For example, when at least one circuit breaker granularity includes microservice granularity, interface granularity, and instance granularity simultaneously, the overload protection device first determines the circuit breaker status of each execution unit within the microservice granularity. That is, it first uses the circuit breaker rules corresponding to the microservice granularity and the statistical indicators of each microservice within that granularity to determine the circuit breaker status of each microservice. Only after determining the execution units within the microservice granularity will the overload protection device begin determining the circuit breaker status of each execution unit within the interface granularity. This involves using the statistical indicators of each interface within the interface granularity and the circuit breaker rules corresponding to that granularity to determine the circuit breaker status of each interface. Finally, the overload protection device determines the circuit breaker status of each execution scope within the instance granularity to obtain the circuit breaker status of each instance within that granularity.

[0224] In some other embodiments of this application, if the overload protection device determines that the actuator with a large effective range of the melting granularity is about to be melted, it may not need to continue to determine whether other actuators with a small effective range of the melting granularity are about to be melted; if the overload protection device determines that the actuator with a large effective range of the melting granularity is not about to be melted, it is necessary to continue to determine whether other actuators with a small effective range of the melting granularity are about to be melted.

[0225] In this embodiment, the overload protection device can first determine the circuit breaking status of the execution unit within the circuit breaking granularity with a large effective range, and then determine the circuit breaking status of the execution unit within the circuit breaking granularity with a small effective range. In this way, it can make a circuit breaking judgment for each execution unit within the circuit breaking granularity in descending order of effective range, thus protecting the entire microservice system from avalanche.

[0226] In some embodiments of this application, the rule configuration device sends at least one circuit breaker rule to the overload protection device, i.e., the specific implementation process of S105 may include: S1051-S1052, as follows:

[0227] S1051. When the rule configuration device receives the interface jump instruction, it responds to the interface jump instruction by jumping from the circuit breaker configuration interface to the rule control interface.

[0228] After generating at least one circuit breaker rule corresponding to at least one circuit breaker granularity, the rule configuration device will first save the at least one circuit breaker rule, and then issue it when it receives the corresponding instruction. At this time, the rule configuration device will listen for whether an interface jump instruction is triggered. When the interface jump instruction is triggered, the rule configuration device will respond to the interface jump instruction, generate a rule control interface, and then exit the circuit breaker configuration interface and enter the rule control interface.

[0229] It should be noted that the rule control interface is used to control at least one circuit breaker rule. That is, the rule configuration device enters the interface for controlling the circuit breaker rule from the interface for configuring and generating the circuit breaker rule through the interface jump command. This control can include operations such as deletion, sending, and modification.

[0230] It is understandable that interface redirection commands can be triggered manually. For example, microservice administrators can trigger the redirection command via the "Next" button set in the circuit breaker configuration interface, or via the voice command "Enter Control Interface." Interface redirection commands can also be triggered autonomously by the rule configuration device. For example, the rule configuration device can automatically trigger the redirection command when it detects no operation from a microservice administrator within a certain period, or automatically trigger the redirection command when it determines that all windows in the circuit breaker configuration interface have selected configuration parameters.

[0231] S1052. When the rule configuration device receives a rule distribution instruction on the distribution operation control of the rule control interface, it sends at least one circuit breaker rule to the overload protection device in response to the rule distribution instruction.

[0232] After entering the rule control interface, when the rule configuration device listens for the rule issuance command on the issuance operation control set in the rule control interface, it will respond to the rule issuance command by sending at least one circuit breaker rule to the overload protection device through the network, so that the overload protection device can use at least one circuit breaker rule to protect the target microservice from overload.

[0233] It is understandable that rule issuance commands can be triggered manually or by machines. For example, when a microservice administrator clicks the issuance operation control set in the rule control interface, the rule issuance command is triggered. Alternatively, the rule configuration device can automatically trigger the rule issuance command when the time it enters the rule control interface reaches a threshold.

[0234] It should be noted that the operation control can be set in the fourth preset area of ​​the rule control interface. The size and position of the fourth preset area can be set according to actual needs. For example, the fourth preset area can be set in the upper half of the rule control interface with a size of 20×20, or in the right half of the rule control interface with a size of 30×25. This application does not limit this.

[0235] In some embodiments of this application, the rule control interface may also include other types of operation controls, such as view control and delete control, to facilitate viewing and deleting at least one circuit breaker rule. In other embodiments, the rule control interface also displays basic information about at least one circuit breaker rule, such as the circuit breaker granularity, the microservice system to which it belongs, and the corresponding downstream microservice.

[0236] For example, this application provides an example diagram of a rule control interface, such as... Figure 7 As shown, in the rule control interface 7-1, the downstream microservice of the target microservice 7-11 consumer-demo is displayed, the microservice system to which the target microservice belongs 7-12 lq-test-vm_default, the circuit breaker granularity of the target microservice 7-13: microservice granularity, the update time of the circuit breaker rule 7-14: 2020-01-15, the issued operation control 7-15, viewing the operation control, and viewing the text information "View Rule 7-16" on the operation control, deleting the operation control, and deleting the text information "Delete 7-17" on the operation control.

[0237] In this embodiment of the application, when the rule configuration device receives the interface jump instruction, it can jump from the circuit breaker configuration interface to the rule control interface. Then, when it receives the rule sending instruction on the sending operation control of the rule control interface, it can send at least one circuit breaker rule to the overload protection device, thereby realizing the sending of at least one circuit breaker rule according to the instruction.

[0238] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0239] The embodiments in this application are implemented in a scenario where different isolation levels of circuit breaker control are applied to the microservice configuration specified by the user.

[0240] In this embodiment, isolation levels (circuit breaker granularity) are divided into three categories: service (microservice granularity), instance (instance granularity), and API (interface granularity). Service level refers to the downstream microservice that an upstream microservice wants to access. When the downstream microservice is unavailable, the service level will circuit breaker the entire downstream microservice (the execution unit within the microservice granularity), refusing access. Instance level refers to each microservice having one or more instances providing services. When an instance (the execution unit within the instance granularity) fails, the instance level can isolate that instance individually. API level refers to each microservice exposing several APIs for other microservices to call. When an API (the execution unit within the interface granularity) has a problem, the API level can circuit breaker the service of that API individually.

[0241] Users (microservice administrators) can specify different combinations of circuit breaker isolation levels for a specific microservice. For example, the microservice to be protected (target microservice) is consumer-demo, and the downstream microservice to be accessed is provider-demo. provider-demo provides two methods, echo1 and echo2, and there are two instances of provider-demo providing services, ins-1 and ins-2. Users can configure three rules for consumer-demo: service-level circuit breaker for provider-demo as a whole, API-level circuit breaker for provider-demo, and instance-level circuit breaker for provider-demo. All three rules apply simultaneously, with the rule meeting the pre-defined threshold conditions taking effect first. The broader the scope, the earlier the rule takes effect. In this case, the order of priority for the levels is: service level > API level > instance level (when including microservice granularity, interface granularity, and instance granularity, the execution unit within the microservice granularity is judged first, then the execution unit within the interface granularity, and finally the execution unit within the instance granularity). For example, when a user accesses the `echo2` method of the `ins-2` instance of `provider-demo`, the system first checks if `provider-demo` is under circuit breaking. If not, it checks if `echo2` is under circuit breaking. If `echo2` meets the circuit breaking condition (the request processing threshold specified by the circuit breaking rule corresponding to the circuit breaking granularity), further access is not allowed. If the condition is not met, it checks if the `ins-2` instance meets the circuit breaking condition. Isolation levels can coexist, which improves the flexibility of microservice circuit breaking.

[0242] A fuse consists of two dimensions: fusing granularity and fusing rules. Fusing granularity is divided into three levels, while fusing rules are more flexible, allowing users to set fusing rules based on any tags.

[0243] Circuit breaker rules are divided into two parts: the calculation scope of the rule and the statistical indicators used to determine the rule's effectiveness. The calculation scope includes: sliding window time (statistical period), minimum number of requests (request threshold), the interval between circuit breaker opening and half-opening (circuit breaker recovery time threshold), and the minimum number of requests from circuit breaker half-opening to closing (circuit breaker recovery request threshold). The following explains each component of the calculation scope.

[0244] Sliding window time: The range of statistical indicators in the circuit breaker rule is determined by a fixed time window. Assuming the user sets the window size to 10 seconds, the statistical indicators of all requests within the previous 10 seconds will be counted for each request.

[0245] Minimum number of requests: The minimum number of requests refers to the minimum number of requests received within the statistical window before the statistical metric is calculated. Assuming the sliding window time is 10 seconds and the minimum number of requests is set to 10, if the number of requests within the current sliding window time is less than 10, the circuit breaker threshold will not be checked. The advantage of this is that it will not cause too much noise due to too few samples.

[0246] Fuse open to half-open interval: The fuse has three states. The time from open (fuse open) to half-open (allowing a single request) can be set freely. A longer time can reduce bounce but will affect the fault recovery time. A shorter time can reduce the fault recovery time but will increase the probability of bounce. You can decide freely according to the actual situation.

[0247] Minimum number of requests from half-open to closed: The circuit will receive requests in the half-open state. The minimum number of requests from half-open to closed (normal state) refers to the minimum number of requests that need to be met before the circuit breaker is judged whether to close. In this case, the sliding window time is not counted.

[0248] The statistical metrics used to determine the effectiveness of a rule can be request failure rate and slow request rate (request timeout rate). Request failure rate marks a request as normal or erroneous based on the success or failure of the response. A circuit breaker threshold is determined based on the request failure rate; if the threshold (the threshold specified in the circuit breaker rule) is exceeded, the request is triggered. Slow request rate determines whether a request is a slow request (timeout request) based on its response time. The percentage of slow requests is statistically analyzed, and if it exceeds a set threshold (the threshold specified in the circuit breaker rule), the request is triggered. Users can also automatically perform statistics based on tagged metrics, such as needing to implement circuit breaker protection for requests from users who are particularly concerned about response time (response duration).

[0249] See Figure 8 , Figure 8This is an example diagram of the interface for configuring rules for a specified microservice, provided in an embodiment of this application. In the service window 8-11 (microservice selection window) of interface 8-1 (circuit breaker configuration interface), select the namespace lq-test-vm_default 8-111 (microservice system) and consumer-demo 8-112 (target microservice); in the isolation level window 8-12 (circuit breaker granularity selection window), select the service 8-121 (microservice granularity); in the sliding time window 8-13 (a rule configuration window), select 10s 8-131; in the minimum request count window 8-14 (a rule configuration window), select 10 times 8-141; in the failure request rate window 8-15 (a rule configuration window), select 50% 8-151, thus triggering the circuit breaker when 50% is reached; in the slow request rate window 8-16 (a rule configuration window), select 6000ms 8-161, and 50%... 8-162, thus determining that when the proportion of requests with a response time exceeding 6000ms reaches 50%, the circuit breaker is triggered; in the half-open interval window 8-17 (a rule configuration window), select 60s 8-171. From this, you can obtain the various parameters (configuration parameters) for the specified microservice.

[0250] To give users greater control over microservices, the ability to apply and deploy changes in real time allows users to interact with the service through a simple interface, such as via... Figure 7 The interface shown allows users to update and disable time rules without modifying code or restarting the application, enabling them to start and stop the circuit breaker function with a single click in emergencies.

[0251] Below is an explanation of instance-level circuit breaker control. Users can first select instance-level circuit breaker (circuit breaker granularity) on the interface and configure the circuit breaker rules, such as setting the maximum number of instances to be broken to 50% (this ensures a minimum number of instances are not broken to prevent a cascading failure), setting the sliding window time to 10 seconds, and the minimum number of requests to 10. After the user completes the settings and submits, the rules will be deployed to the application microservices in real time (overload protection device). If a few instances experience problems, these problematic instances will be circuit-broken after 10 requests. Subsequent requests will not load traffic onto these problematic instances, ensuring stable traffic flow.

[0252] By employing the above methods, we can increase the granularity of circuit breaking, enabling finer-grained circuit breaking control. At the same time, we can increase the detection of circuit breaker closure, enhance the robustness of microservice availability, and help the microservice system as a whole improve service quality.

[0253] The following continues to describe the exemplary structure of the overload protection device 255 provided in the embodiments of this application as a software module. In some embodiments, as shown in FIG2(a), the software module stored in the overload protection device 255 in the first memory 250 may include:

[0254] Rule receiving module 2551 is used to receive at least one circuit breaker rule sent by rule configuration device, corresponding to at least one circuit breaker granularity of target microservice; the at least one circuit breaker granularity indicates the scope level of circuit breaker;

[0255] The indicator statistics module 2552 is used to calculate the statistical indicators corresponding to the execution units within each circuit breaker granularity based on each circuit breaker rule in the at least one circuit breaker rule; the statistical indicators are used to characterize the response status of the execution units within each circuit breaker granularity to the request;

[0256] The circuit breaker determination module 2553 is used to determine the circuit breaker status of the execution unit based on the statistical indicators corresponding to the execution unit and the circuit breaker rule corresponding to each circuit breaker granularity in the at least one circuit breaker rule; the circuit breaker status indicates whether the circuit breaker is activated.

[0257] The circuit breaker control module 2554 is used to perform circuit breaker control on the execution unit within each circuit breaker granularity according to the circuit breaker state, so as to realize overload protection for the target microservice.

[0258] In some embodiments of this application, the circuit breaker rule corresponding to each circuit breaker granularity includes an indicator threshold; the circuit breaker judgment module 2553 is further configured to determine that the circuit breaker state of the execution unit is enabled when the statistical indicator corresponding to the execution unit is greater than or equal to the indicator threshold; the indicator threshold is specified by the rule configuration device, and the execution unit is a microservice, interface, or instance; when the statistical indicator corresponding to the execution unit is less than the indicator threshold, the circuit breaker state of the execution unit is disabled.

[0259] In some embodiments of this application, the indicator statistics module 2552 is further configured to parse a statistical period and a request threshold from each circuit breaker rule; the request threshold is used to determine whether to start acquiring the statistical indicators; according to the statistical period, the number of requests of the execution unit within each circuit breaker granularity is acquired; when the number of requests is greater than or equal to the request threshold, the statistical indicators of the execution unit within each circuit breaker granularity within the statistical period are calculated.

[0260] In some embodiments of this application, the statistical metric includes: request failure rate;

[0261] The indicator statistics module 2552 is also used to count the total number of requests made by the execution unit within the statistical period; count the number of failed requests made by the execution unit within the statistical period; the failed request represents a request that was not successfully responded to; and calculate the request failure rate of the execution unit within each circuit breaker granularity within the statistical period using the number of failed requests and the total number of requests.

[0262] In some embodiments of this application, the statistical metrics include: request timeout rate;

[0263] The indicator statistics module 2552 is also used to count the total number of requests made by the execution unit within the statistical period; count the number of timeout requests made by the execution unit within the statistical period; the timeout request represents the request that timed out; and calculate the timeout request rate of the execution unit within each circuit breaker granularity within the statistical period using the number of timeout requests and the total number of requests.

[0264] In some embodiments of this application, the overload protection device 255 further includes: a circuit breaker recovery module 2555; when the circuit breaker state indicates that the circuit breaker is activated, the circuit breaker recovery module 2555 is further configured to parse a circuit breaker recovery time threshold and a circuit breaker recovery request threshold from the circuit breaker rules of each circuit breaker granularity; wherein, the circuit breaker recovery time threshold indicates the time required to recover from the circuit breaker activated state to the state allowing a single request, and the circuit breaker recovery request threshold indicates the number of requests required to recover from the state allowing a single request to the normal state; when the circuit breaker duration reaches the circuit breaker recovery time threshold, the circuit breaker recovery module 2555 controls the circuit breaker recovery time threshold within each circuit breaker granularity. The execution unit recovers from the circuit breaker enabled state to the state where a single request is allowed; the circuit breaker duration represents the time the circuit breaker has been enabled; when the number of circuit breaker requests reaches the circuit breaker recovery request threshold, the request processing index of the execution unit within each circuit breaker granularity is calculated; the number of circuit breaker requests represents the number of requests responded to by the execution unit when the state where a single request is allowed is in effect; when the request processing index is less than the processing index threshold specified by the circuit breaker rule corresponding to each circuit breaker granularity, the execution unit within each circuit breaker granularity is restored from the state where a single request is allowed to the normal state.

[0265] In some embodiments of this application, the circuit breaker determination module 2553 is further configured to extract the maximum range circuit breaker granularity with the largest effective range from the at least one circuit breaker granularity; the at least one circuit breaker granularity includes at least one of microservice granularity, interface granularity, and instance granularity; determine the circuit breaker status of the maximum execution unit within the maximum range circuit breaker granularity based on the maximum statistical index corresponding to the maximum execution unit within the maximum range circuit breaker granularity and the maximum range circuit breaker rule corresponding to the maximum range circuit breaker granularity; extract other range circuit breaker granularities other than the maximum range circuit breaker granularity from the at least one circuit breaker granularity; repeat the process of extracting new maximum range circuit breaker granularities from the other range circuit breaker granularities and determining the circuit breaker status of the new maximum execution unit within the new maximum range circuit breaker granularity until the other range circuit breaker granularities are empty, thereby obtaining the circuit breaker status of the execution unit.

[0266] The following description continues to illustrate the exemplary structure of the rule configuration device 455 provided in the embodiments of this application as a software module. In some embodiments, as shown in FIG2(b), the software module stored in the rule configuration device 455 in the second memory 450 may include:

[0267] Instruction receiving module 4551 is used to receive circuit breaker rule configuration instructions;

[0268] The interface jump module 4552 is used to jump from the current display interface to the circuit breaker configuration interface in response to the circuit breaker rule configuration command; the current display interface can be any display interface;

[0269] The extraction module 4553 is used to obtain the target microservice for rule configuration in the microservice selection window displayed on the circuit breaker configuration interface, and to extract at least one circuit breaker granularity of the target microservice in the circuit breaker granularity selection window displayed on the circuit breaker configuration interface.

[0270] The parameter acquisition module 4554 is used to acquire the configuration parameters for each of the at least one circuit breaker granularities in the rule configuration window displayed in the rule configuration area of ​​the circuit breaker configuration interface.

[0271] The rule generation module 4555 is used to generate a circuit breaking rule corresponding to each circuit breaking granularity using the configuration parameters of each circuit breaking granularity. When corresponding circuit breaking rules are generated for each of the at least one circuit breaking granularity, at least one circuit breaking rule corresponding to the at least one circuit breaking granularity is obtained.

[0272] The rule sending module 4556 is used to send the at least one circuit breaker rule to the overload protection device, so that the overload protection device can use the at least one circuit breaker rule to perform overload protection on the target microservice.

[0273] In some embodiments of this application, the rule sending module 4556 is further configured to, upon receiving an interface jump instruction, jump from the circuit breaker configuration interface to the rule control interface in response to the interface jump instruction; the rule control interface is configured to control the at least one circuit breaker rule; and upon receiving a rule sending instruction acting on the sending operation control of the rule control interface, in response to the rule sending instruction, send the at least one circuit breaker rule to the overload protection device.

[0274] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the overload protection method described above in this application.

[0275] This application provides a computer-readable storage medium storing executable instructions, including executable overload protection instructions. When the executable overload protection instructions are executed by a first processor, the first processor will execute the overload protection method provided by the overload protection device side of this application embodiment. When the executable overload protection instructions are executed by a second processor, the second processor will execute the overload protection method provided by the rule configuration device side of this application embodiment.

[0276] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0277] In some embodiments, executable overload protection instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0278] As an example, executable overload protection instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0279] As an example, executable overload protection instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0280] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. An overload protection method, characterized in that, Applications include overload protection devices, including: The system receives at least one circuit breaker rule corresponding to at least one circuit breaker granularity of the target microservice from a rule configuration device; wherein the target microservice, the at least one circuit breaker granularity, and the circuit breaker rule are obtained from the circuit breaker configuration interface of the rule configuration device; the at least one circuit breaker granularity specifies the scope level of the circuit breaker; the at least one circuit breaker granularity includes at least one of microservice granularity, interface granularity, and instance granularity. The request threshold is parsed from each circuit breaker rule, and when the number of requests from the execution unit is greater than or equal to the request threshold, the statistical indicators corresponding to the execution unit within each circuit breaker granularity are calculated; wherein, the statistical indicators are used to characterize the response of the execution unit to the request within each circuit breaker granularity; the execution unit is a microservice, interface, or instance; Based on the statistical indicators corresponding to the execution unit and the circuit breaker rules corresponding to each circuit breaker granularity in the at least one circuit breaker rule, the circuit breaker status of the execution unit is determined; the circuit breaker status indicates whether the circuit breaker is activated. Based on the circuit breaker status, circuit breaker control is performed on the execution unit within each circuit breaker granularity to achieve overload protection for the target microservice; When the circuit breaker duration reaches the circuit breaker recovery time threshold, the execution unit within each circuit breaker granularity will be restored from the circuit breaker open state to the state that allows a single request. When the number of circuit breaker requests by the execution unit in the single-request-allowed state reaches the circuit breaker recovery request threshold, and the request processing index of the execution unit within each circuit breaker granularity is less than the processing index threshold, the execution unit of each circuit breaker granularity is restored to the normal state.

2. The method according to claim 1, characterized in that, The circuit breaker rule corresponding to each circuit breaker granularity includes an indicator threshold; determining the circuit breaker status of the execution unit based on the statistical indicator corresponding to the execution unit and the circuit breaker rule corresponding to each circuit breaker granularity in at least one circuit breaker rule includes: When the statistical indicator corresponding to the execution unit is greater than or equal to the indicator threshold, the circuit breaker status of the execution unit is determined to be activated; the indicator threshold is specified by the rule configuration device. When the statistical indicator corresponding to the execution unit is less than the indicator threshold, the circuit breaker status of the execution unit is determined to be closed.

3. The method according to claim 1 or 2, characterized in that, The step of calculating statistical indicators corresponding to the execution unit within each circuit breaker granularity based on each of the at least one circuit breaker rule includes: The statistical period and request threshold are parsed from each circuit breaker rule; the request threshold is used to determine whether to start acquiring the statistical indicators. Based on the statistical period, obtain the number of requests of the execution unit within each circuit breaker granularity; When the number of requests is greater than or equal to the request threshold, the statistical indicators of the execution unit within each circuit breaker granularity within the statistical period are calculated.

4. The method according to claim 1 or 2, characterized in that, When the circuit breaker duration reaches the circuit breaker recovery time threshold, restoring the execution unit within each circuit breaker granularity from the circuit breaker enabled state to a state allowing a single request includes: From the circuit breaker rules at each circuit breaker granularity, the circuit breaker recovery time threshold and the circuit breaker recovery request threshold are parsed out; Wherein, the circuit breaker recovery time threshold represents the time required to recover from the circuit breaker enabled state to the state where a single request is allowed, and the circuit breaker recovery request threshold represents the number of requests required to recover from the state where a single request is allowed to the normal state; When the circuit breaker duration reaches the circuit breaker recovery time threshold, the execution unit within each circuit breaker granularity is controlled to recover from the circuit breaker enabled state to the state that allows a single request; the circuit breaker duration represents the time during which the circuit breaker state has been enabled. When the number of circuit breaker requests by the execution unit in the allowed single request state reaches the circuit breaker recovery request threshold and the request processing index of the execution unit within each circuit breaker granularity is less than the processing index threshold, the execution unit of each circuit breaker granularity returns to the normal state, including: When the number of circuit breaker requests reaches the circuit breaker recovery request threshold, the request processing metrics of the execution unit within each circuit breaker granularity are statistically analyzed; the number of circuit breaker requests represents the number of requests responded to by the execution unit when the state of allowing a single request is reached. When the request processing index is less than the processing index threshold specified by the circuit breaker rule corresponding to each circuit breaker granularity, the execution unit within each circuit breaker granularity is restored from the state of allowing a single request to the normal state.

5. The method according to claim 1 or 2, characterized in that, The step of determining the circuit breaker status of the execution unit based on the statistical indicators corresponding to the execution unit and the circuit breaker rules corresponding to each circuit breaker granularity in the at least one circuit breaker rule includes: From the at least one fusing particle size, extract the fusing particle size with the largest effective range; Based on the maximum statistical index corresponding to the maximum execution unit within the maximum range of ... Extract the range of fusing particle sizes other than the maximum range of fusing particle size from the at least one fusing particle size; The process of extracting a new maximum range of melting granularity from the other ranges of melting granularity and determining the melting state of the new maximum execution unit within the new maximum range of melting granularity is repeated until the other ranges of melting granularity are empty, thus obtaining the melting state of the execution unit.

6. An overload protection method, characterized in that, Applied to rule configuration devices, including: When a circuit breaker rule configuration instruction is received, the system will switch from the current display interface to the circuit breaker configuration interface in response to the instruction; the current display interface can be any display interface. In the microservice selection window displayed on the circuit breaker configuration interface, obtain the target microservice for rule configuration, and in the circuit breaker granularity selection window displayed on the circuit breaker configuration interface, extract at least one circuit breaker granularity of the target microservice. In the rule configuration window displayed in the rule configuration area of ​​the circuit breaker configuration interface, the configuration parameters for each of the at least one circuit breaker granularity are obtained; Using the configuration parameters of each circuit breaker granularity, a circuit breaker rule corresponding to each circuit breaker granularity is generated. When a corresponding circuit breaker rule is generated for each of the at least one circuit breaker granularity, at least one circuit breaker rule corresponding to the at least one circuit breaker granularity is obtained. The at least one circuit breaker rule is sent to the overload protection device as described in any one of claims 1 to 5, so that the overload protection device uses the at least one circuit breaker rule to perform overload protection on the target microservice.

7. An overload protection device, characterized in that, Applications include overload protection devices, including: The rule receiving module is used to receive at least one circuit breaker rule sent by the rule configuration device, which corresponds to at least one circuit breaker granularity of the target microservice; wherein, the target microservice, the at least one circuit breaker granularity, and the circuit breaker rule are obtained from the circuit breaker configuration interface of the rule configuration device; the at least one circuit breaker granularity specifies the scope level of the circuit breaker; the at least one circuit breaker granularity includes at least one of microservice granularity, interface granularity, and instance granularity; The metrics statistics module is used to parse the request threshold from each circuit breaker rule, and when the number of requests of the execution unit is greater than or equal to the request threshold, to calculate the statistical metrics corresponding to the execution unit within each circuit breaker granularity; wherein, the statistical metrics are used to characterize the response of the execution unit to the request within each circuit breaker granularity; the execution unit is a microservice, interface, or instance; The circuit breaker determination module is used to determine the circuit breaker status of the execution unit based on the statistical indicators corresponding to the execution unit and the circuit breaker rules corresponding to each circuit breaker granularity in the at least one circuit breaker rule; the circuit breaker status indicates whether the circuit breaker is activated. The circuit breaker control module is used to perform circuit breaker control on the execution unit within each circuit breaker granularity according to the circuit breaker state, so as to realize overload protection for the target microservice; The circuit breaker recovery module is used to restore the execution unit within each circuit breaker granularity from the circuit breaker enabled state to the state that allows a single request when the circuit breaker duration reaches the circuit breaker recovery time threshold; and to restore the execution unit within each circuit breaker granularity to the normal state when the number of circuit breaker requests of the execution unit in the state that allows a single request reaches the circuit breaker recovery request threshold, and the request processing index of the execution unit within each circuit breaker granularity is less than the processing index threshold.

8. An overload protection device, characterized in that, include: The first memory is used to store executable overload protection instructions; A first processor, when executing executable overload protection instructions stored in the first memory, implements the method according to any one of claims 1 to 5.

9. A rule configuration device, characterized in that, include: The second memory is used to store executable overload protection instructions; The second processor, when executing executable overload protection instructions stored in the second memory, implements the method of claim 6.

10. A computer-readable storage medium, characterized in that, The device stores executable overload protection instructions, which, when executed by a first processor, implement the method described in any one of claims 1 to 5; or, when executed by a second processor, implement the method described in claim 6.

11. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a first processor, they implement the method of any one of claims 1 to 5; or when the computer-executable instructions or computer program are executed by a second processor, they implement the method of claim 6.

Images