Abnormal fusing mechanism enhancement method and device and related product
By monitoring API performance indicator data to calculate the abnormal rate indicator and dynamically adjust the circuit breaker status, the problem of increasing response time, false alarms and misjudgment in the existing API fuse mechanism is solved, and adaptive adjustments to the system load and back-end service status are achieved, improving system stability and continuous availability of API services.
Patent Information
- Application Number
- CN202411764945.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-04
- Publication Date
- 2025-03-25
AI Technical Summary
The existing API fuse mechanism has problems such as frequent health checks, increased system response time, false alarms and misjudgment, and the circuit breaker mode lacks the ability to adapt to the system load and back-end service status.
By monitoring the performance index data of the API during the set time period, the abnormality rate index is calculated, and compared with the preset abnormality threshold, the circuit breaker status is dynamically adjusted to achieve intelligent management of fuse and recovery.
It reduces the system response time brought by health checks, improves system performance, accurately judges service abnormalities, reduces false judgments and false alarms, realizes adaptive adjustments to system load and back-end service status, and improves system stability and continuous availability of API services.
Smart Images

Figure CN119690723A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the field of data processing, and in particular relates to a method and device for enhancing an abnormal fuse mechanism and related products. Background Art
[0002] With the deepening of enterprise digital transformation and the widespread implementation of API strategy, the team independently developed and built the API technology base of the industrial Internet platform, namely the capability exposure platform. As the core support for API management, security, monitoring and analysis, the platform effectively connects API producers, managers and consumers through the API gateway, greatly promoting the efficient release of API energy. After long-term R&D iterations and actual application verification, the capability exposure platform has demonstrated its efficient and secure underlying API technology support capabilities in multiple companies and hundreds of systems inside and outside the petrochemical industry, especially in key scenarios such as application system integration, business component reuse, data service publishing and cloud-edge service collaboration.
[0003] However, with the widespread application and in-depth promotion of API services, the importance of API circuit breakers has become increasingly prominent. As a key means of protecting the system from the impact of backend service failures, the circuit breaker mechanism effectively reduces the system load and prevents the occurrence of system avalanche effects by temporarily interrupting requests to backend services under certain conditions. Currently, the circuit breaker mechanism is mainly implemented in two core ways: health checks and circuit breakers.
[0004] Health checks send requests to the target service regularly through the gateway and determine the health status of the service based on the response status code. However, there are problems such as increased system response time, false positives caused by failure or delay of the health check request itself, and misjudgments caused by network problems or temporary busyness of the backend service. Although the circuit breaker mode can provide protection when the backend service has performance problems, it lacks the ability to adapt to the system load and the backend service status. Summary of the invention
[0005] Based on the above problems, the embodiments of the present application provide a method, device and related products for enhancing the abnormal fuse mechanism to solve the problems existing in the above-mentioned prior art.
[0006] The present application discloses a method for enhancing an abnormal fuse mechanism, which includes:
[0007] Monitor the performance indicator data of the API within a set time period, and calculate the corresponding abnormal rate indicator based on the monitored performance indicator data;
[0008] The abnormal rate indicator is compared with the preset abnormal threshold. If the abnormal rate indicator exceeds the preset abnormal threshold, it is determined that the circuit breaker needs to be turned on.
[0009] If the fuse needs to be opened, a circuit breaker opening control instruction is generated to open the circuit breaker and accordingly cause the API to enter the fuse state as follows;
[0010] Make all requests return a defined error status code;
[0011] Obtain the set fuse state adjustment condition to determine whether the circuit breaker state needs to be adjusted;
[0012] If adjustment is needed, the fuse state is changed from a mode that completely blocks requests to a mode that allows some requests to pass, so as to try to restore access to the backend service;
[0013] When the API is in a mode that allows some requests to pass, the performance indicator data of the request is monitored. If the performance indicator data does not reach the preset indicator threshold, the circuit breaker is closed to determine that the backend service has returned to normal; otherwise, the fuse continues to be opened.
[0014] The present application discloses a device for enhancing an abnormal fusing mechanism, which comprises:
[0015] The first program unit is used to monitor the performance indicator data of the API within a set time period, and calculate the corresponding abnormality rate indicator based on the monitored performance indicator data;
[0016] The second program unit is used to compare the abnormal rate indicator with a preset abnormal threshold, and if the abnormal rate indicator exceeds the preset abnormal threshold, it is determined that a fuse needs to be opened;
[0017] a third program unit, for generating a circuit breaker opening control instruction if the fuse needs to be opened, so as to open the circuit breaker and thereby cause the API to enter a fuse state in the following manner;
[0018] Make all requests return a defined error status code;
[0019] Obtain the set fuse state adjustment condition to determine whether the circuit breaker state needs to be adjusted;
[0020] If adjustment is needed, the fuse state is changed from a mode that completely blocks requests to a mode that allows some requests to pass, so as to try to restore access to the backend service;
[0021] When the API is in a mode that allows some requests to pass, the performance indicator data of the request is monitored. If the performance indicator data does not reach the preset indicator threshold, the circuit breaker is closed to determine that the backend service has returned to normal; otherwise, the fuse continues to be opened.
[0022] The present application discloses a method for monitoring abnormal fuse blowing, which comprises:
[0023] Monitor the performance indicator data of the API within a set time period, and calculate the corresponding abnormal rate indicator based on the monitored performance indicator data;
[0024] The abnormal rate indicator is compared with the preset abnormal threshold. If the abnormal rate indicator exceeds the preset abnormal threshold, it is determined that the circuit breaker needs to be turned on.
[0025] If the fuse needs to be opened, a circuit breaker opening control instruction is generated to open the circuit breaker and thereby put the API into a fuse state.
[0026] The present application discloses an integrated API management and service system, which includes: a client, an API gateway, and a back-end server. The client is used to generate an access request, and the access request is sent to the back-end server through the API gateway. The back-end server is used to respond to the service request and return a response result. During this process, the API gateway executes the enhancement method of the abnormal fuse mechanism described in any one of claims 1-8, or the abnormal fuse monitoring method described in any one of claims 12-14.
[0027] The present application discloses an API gateway, which is used to execute the enhancement method of the abnormal fuse mechanism described in any one of the embodiments of the present application, or the abnormal fuse monitoring method described in any one of the embodiments of the present application.
[0028] The present application discloses a computer storage medium having a computer executable program stored thereon. When the computer executable program is executed, the method for enhancing the abnormal fuse mechanism described in any one of the embodiments, or the method for monitoring the abnormal fuse described in any one of the embodiments of the present application is implemented.
[0029] The present application provides a method, device and related products for enhancing an abnormal fuse mechanism, which have the following technical benefits:
[0030] (1) This method monitors the performance indicator data of the API within a set time period instead of performing frequent health checks, thereby avoiding the system response time that may be increased by the health check itself. This method reduces unnecessary requests and improves the overall performance of the system.
[0031] (2) By calculating the anomaly rate index and comparing it with the preset anomaly threshold, this method can more accurately determine whether the service is abnormal. This method takes into account the overall performance within a time period, rather than relying on the response status code of a single health check, thereby effectively reducing misjudgments caused by network problems or temporary busyness of the backend service, as well as false positives caused by failure or delay of the health check request itself.
[0032] (3) This method achieves self-adaptation to system load and backend service status by monitoring API performance indicator data and dynamically adjusting the fuse status according to the abnormal rate indicator. When the backend service performance degrades, the abnormal rate indicator will increase, triggering the fuse mechanism; when the backend service performance recovers, the abnormal rate indicator will decrease, and the fuse mechanism will be closed accordingly or adjusted to a mode that allows some requests to pass, thereby achieving intelligent adjustment according to the actual situation of the system.
[0033] (4) By obtaining the set fuse state adjustment conditions, the method can determine whether the circuit breaker state needs to be adjusted. This mechanism allows operation and maintenance personnel to set the adjustment conditions of the fuse state according to actual needs, such as the degree of reduction and duration of the abnormal rate indicator, thereby improving the flexibility and controllability of the fuse mechanism.
[0034] (5) This method combines anomaly detection and circuit breaker mechanisms, and can intelligently determine the health status of backend services and enable circuit breakers to protect the system when necessary. At the same time, by allowing some requests to pass through to attempt to restore access to backend services, and monitoring the performance indicator data of requests to determine whether the backend services have returned to normal, intelligent management of circuit breakers and recovery is achieved. By reducing false alarms and delayed detection, adaptive system load and backend service status, and intelligent circuit breakers and recovery mechanisms, this method significantly improves the stability and reliability of the system and ensures the continuous availability and high-quality delivery of API services. BRIEF DESCRIPTION OF THE DRAWINGS
[0035] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.
[0036] Figure 1 This is a flow chart of a method for enhancing an abnormal fuse mechanism according to an embodiment of the present application.
[0037] Figure 2 This is a schematic diagram of the structure of an enhancement device for an abnormal fuse mechanism according to an embodiment of the present application.
[0038] Figure 3 This is a flow chart of an abnormal fuse monitoring method according to an embodiment of the present application.
[0039] Figure 4 This is a schematic diagram of the structure of an integrated API management and service system according to an embodiment of the present application. DETAILED DESCRIPTION
[0040] The implementation of any technical solution of the embodiments of the present application does not necessarily require achieving all of the above advantages at the same time.
[0041] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0042] Figure 1 This is a flow chart of a method for enhancing an abnormal fuse mechanism according to an embodiment of the present application. Figure 1 As shown, it includes:
[0043] Monitor the performance indicator data of the API within a set time period, and calculate the corresponding abnormal rate indicator based on the monitored performance indicator data;
[0044] The abnormal rate indicator is compared with the preset abnormal threshold. If the abnormal rate indicator exceeds the preset abnormal threshold, it is determined that the circuit breaker needs to be turned on.
[0045] If the fuse needs to be opened, a circuit breaker opening control instruction is generated to open the circuit breaker and accordingly cause the API to enter the fuse state as follows;
[0046] Make all requests return a defined error status code;
[0047] Obtain the set fuse state adjustment condition to determine whether the circuit breaker state needs to be adjusted;
[0048] If adjustment is needed, the fuse state is changed from a mode that completely blocks requests to a mode that allows some requests to pass, so as to try to restore access to the backend service;
[0049] When the API is in a mode that allows some requests to pass, the performance indicator data of the request is monitored. If the performance indicator data does not reach the preset indicator threshold, the circuit breaker is closed to determine that the backend service has returned to normal; otherwise, the fuse continues to be opened.
[0050] To this end, in this embodiment, by monitoring the performance indicator data of the API within a set time period, the increase in system response time caused by frequent health checks is avoided, and the system performance is improved. At the same time, by calculating the abnormality rate index and comparing it with the preset threshold, the service abnormality is accurately judged, reducing misjudgments and false alarms. In addition, the method can also adaptively adjust the fuse state according to the system load and the backend service status, and flexibly control the circuit breaker according to the fuse state adjustment conditions set by the operation and maintenance personnel, thereby realizing the intelligent management of fuse and recovery. These mechanisms jointly improve the stability, reliability and continuous availability of the API service of the system, and ensure high-quality service delivery.
[0051] Optionally, the method further comprises: calculating the total number of requests and the number of errors of the API within a set time period, so as to use the total number of requests and the number of errors as the performance indicator data;
[0052] The calculating of the corresponding abnormality rate index according to the monitored performance index data includes: calculating the error rate according to the total number of requests and the number of errors;
[0053] The abnormality threshold is an error rate threshold. Correspondingly, the abnormality rate index is compared with a preset abnormality threshold. If the abnormality rate index exceeds the preset abnormality threshold, it is determined that the fuse needs to be opened, including:
[0054] The error rate is compared with the error rate threshold to determine whether the error rate threshold exceeds the error rate threshold. If so, it is determined that the fuse needs to be opened.
[0055] To this end, the above solution has the following technical advantages:
[0056] 1. Accurately locate abnormal situations
[0057] By clearly taking the total number of requests and errors of the API within a set time period as performance indicator data, and calculating the error rate as the abnormality rate indicator, the evaluation of the API operation status is more focused on the actual proportion of errors. Compared with other performance indicator considerations that may be relatively broad, this measurement method centered on the error rate can more directly and accurately reflect the degree of abnormality in the API request processing process, thereby more accurately locating API services that may have problems, and providing a reliable basis for the subsequent timely adoption of protection measures such as fuses.
[0058] 2. Simplify judgment logic and improve efficiency
[0059] 1. Simplify the judgment logic: Set the abnormal threshold as the error rate threshold, and determine whether to open the circuit breaker by simply and directly comparing the calculated error rate with the error rate threshold, so that the logic of judging whether to start the circuit breaker mechanism becomes clear and easy to operate. This clear and single comparison method avoids the confusion and uncertainty that may be caused by complex multi-indicator comprehensive judgment, and operation and maintenance personnel or related systems can make accurate decisions more conveniently based on this clear logic.
[0060] 2. Improve efficiency: In actual operation, it is crucial to quickly and accurately determine whether to open the circuit breaker to protect the system. This simple judgment logic based on error rate can complete the evaluation in a short time without too many complex calculations or comprehensive consideration of the relationship between multiple other indicators, so that it can respond more quickly to abnormal situations that may occur in API services, open the circuit breaker in time to prevent the problem from further deteriorating, and effectively improve the efficiency of the entire system in responding to abnormalities.
[0061] 3. Enhance integration with existing systems
[0062] This method of calculating the error rate based on the total number of requests and the number of errors and making circuit breaker judgments based on this method is highly compatible with the conventional statistics and monitoring functions of request processing in many existing API management systems. Most systems usually record basic data such as the total number of requests and the number of errors. Therefore, using this method to implement relevant judgments on the circuit breaker mechanism can be easily integrated into the existing API monitoring and management architecture without the need for large-scale system modifications or the introduction of new complex data collection and analysis modules, reducing the cost and difficulty of system upgrades or optimizations.
[0063] 4. Improving the accuracy of circuit breaker decisions
[0064] The error rate threshold is used as the criterion for judging whether to open the circuit breaker, which fully considers the overall situation of request processing in the actual operation of the API. It is not based on the abnormal situation of a single request, but a combination of all requests within a set time period and the number of errors that occur in them. This can avoid the circuit breaker mechanism being triggered by accidental individual abnormal requests, and at the same time, it will not miss the opportunity to open the circuit breaker due to failure to fully consider the overall error situation, thereby significantly improving the accuracy of the circuit breaker decision, ensuring that the circuit breaker mechanism can be accurately activated when it is really needed, and effectively protecting the system from the impact of problems such as backend service failures.
[0065] Optionally, the method further comprises:
[0066] Obtaining a time window for calculating the performance indicator data, wherein the time window defines the time period;
[0067] Monitoring and recording the response status of all requests received by the API within the time window;
[0068] When the time window ends, the performance indicator data is calculated based on the recorded response status.
[0069] To this end, the above solution has the following technical advantages:
[0070] The following is an analysis of the technical benefits of the above options:
[0071] 1. Accurately define the scope of data statistics
[0072] 1. By obtaining the time window for calculating performance indicator data to define the time period, the statistics of API performance indicator data have a clear, specific and flexibly set time range. This helps operation and maintenance personnel or the system to reasonably determine the time to evaluate the performance of the API based on actual needs, such as the frequency of API use, business peak and trough periods, etc., so as to more accurately grasp the operation status of the API in different time periods.
[0073] 2. Different business scenarios and API application characteristics may require different time periods for effective analysis. For example, for some API services with extremely high real-time requirements, a shorter time window may be required to quickly capture possible performance issues; while for relatively stable, low-frequency APIs, a longer time window can be set to obtain more comprehensive performance data. This flexible way of defining time periods can meet diverse business needs and achieve more targeted performance analysis.
[0074] 2. Comprehensive and accurate record of response status
[0075] 1. The response status of all requests received by the API is monitored and recorded within the time window, ensuring that the response status of any request is not missed. This allows the subsequent calculation of performance indicator data to be based on a complete set of information, thereby obtaining more accurate performance indicator results that better reflect the actual operating status of the API. Compared with only sampling and monitoring the response status of some requests, this comprehensive monitoring method can avoid misjudgment of API performance due to sampling bias.
[0076] 2. Completely recording the response status also provides a detailed basis for tracing possible problems that may arise later. When abnormal API performance or other problems are found, you can refer to the recorded response status information to accurately locate the specific time point and specific request at which the abnormal situation occurred, which helps to quickly identify the root cause of the problem and improve the efficiency of troubleshooting.
[0077] 3. Accurately calculate performance indicators based on complete data
[0078] 1. When the time window ends, the performance indicator data is calculated based on the complete response status of the record, ensuring that the data used is fully collected within a complete and established time period. The performance indicator data calculated in this way is more reliable and can truly reflect the performance of the API during the time period, providing a solid data foundation for subsequent accurate judgment of whether the API is abnormal and whether it is necessary to open a circuit breaker.
[0079] 2. Accurate performance indicator data is the key to making scientific and reasonable decisions. For example, when judging whether to optimize the API, adjust the circuit breaker threshold, etc., based on the performance indicator data that is accurately calculated by fully recording the response status, the operation and maintenance personnel or the system can make decisions that are more in line with the actual situation, avoiding misjudgments and unreasonable operations caused by inaccurate data, thereby effectively ensuring the stable operation and high-quality delivery of API services.
[0080] Optionally, monitoring and recording the response status of all requests received by the API within the time window includes:
[0081] Within the time window, monitoring and recording the result of successful response and failed response of each request received by the API, wherein the response status includes at least one of successful response and failed response;
[0082] After the time window ends, the performance indicator data is calculated according to the recorded response status, including:
[0083] The number of successful responses and the number of failed responses within the time window are counted to calculate an error rate, and the error rate is used as the performance indicator data.
[0084] To this end, the above solution has the following technical advantages:
[0085] The following is an analysis of the technical benefits of the above optional content:
[0086] 1. Clear and unambiguous definition of response status
[0087] 1. The response status of each request received by the API is clearly defined as a successful response and a failed response, and the response status is monitored and recorded, making the division of the response status clear and understandable. This simple and clear classification method helps to quickly and accurately count and analyze different types of response situations in the subsequent data processing process, avoiding data confusion and analysis errors caused by vague definition of response status.
[0088] 2. Based on this clear classification, operation and maintenance personnel or systems can pay attention to the frequency and trend of different response states in a targeted manner. For example, they can focus on response failures to promptly identify possible problems with the API and take corresponding measures. At the same time, they can also compare the ratio of successful responses to response failures to gain a more comprehensive understanding of the overall operation status of the API.
[0089] 2. Advantages of performance indicator calculation based on error rate
[0090] 1. Calculate the error rate by counting the number of successful responses and the number of failed responses within the time window, and use it as performance indicator data, which can very intuitively reflect the degree of abnormality of the API during the time period. The higher the error rate, the greater the possibility that the API will have problems in the process of processing requests. This way of presenting the operation status of the API with a specific value (error rate) is easier to understand and grasp than other more complex or comprehensive performance indicators. It provides a simple and direct reference for both technical and non-technical personnel when evaluating API performance.
[0091] 2. Using error rate as performance indicator data makes it convenient to set reasonable thresholds to determine whether the API is in normal operation or whether specific measures need to be taken (such as turning on the fuse mechanism). For example, when the error rate exceeds a certain pre-set threshold, it can be clearly determined that the API has a more serious problem and needs to activate the corresponding protection mechanism or conduct further investigation. This method of setting thresholds and making decisions based on error rates makes the judgment process more standardized and operational, which helps to improve the efficiency of system operation and maintenance and the accuracy of decision-making.
[0092] 3. The performance indicator data of error rate is closely related to the actual operation of the business. Because it directly reflects the ratio of success and failure of the API in processing business requests, the business department can intuitively understand the support effect of the API on the business by paying attention to the error rate. If the error rate is too high, it may affect the normal development of the business. At this time, the business department can communicate with the technical department in time to urge the technical department to take measures to reduce the error rate, thereby ensuring the smooth operation of the business.
[0093] 3. Accurate analysis based on complete data
[0094] 1. The response status of each request is fully monitored and recorded within the time window, and then the error rate is calculated based on the fully recorded data, ensuring that the data used is comprehensive and complete. The error rate obtained in this way can truly reflect the actual operation of the API within the time period, avoiding the problem of inaccurate error rate calculation caused by sampling data or missing data, and providing a solid data foundation for subsequent accurate analysis of API performance.
[0095] 2. The error rate calculated based on this comprehensive and accurate data can not only be used to determine whether the API is abnormal, but also to further analyze the performance trend of the API. For example, by observing the changes in the error rate in different time windows, you can understand whether the performance of the API is gradually improving or deteriorating, thereby providing valuable reference information for optimizing the operation strategy of the API, adjusting resource allocation, etc., and helping to achieve continuous optimization of API performance.
[0096] Optionally, the counting of the number of successful responses and the number of failed responses within the time window to calculate an error rate, wherein the error rate is used as the performance indicator data, includes:
[0097] Calculate the total number of requests according to the number of successful responses and the number of failed responses within the time window;
[0098] The ratio of the number of response failures within the time window to the total number of requests is calculated, and the calculated ratio is used as the performance indicator data.
[0099] To this end, the above error rate calculation method has the following technical advantages:
[0100] 1. Comprehensively and accurately reflect the operation status of API
[0101] 1. The error rate is determined by first calculating the total number of requests based on the number of successful responses and the number of failed responses, and then calculating the ratio of failed responses to the total number of requests. This method comprehensively considers all requests received by the API within the time window. It not only focuses on the number of failed responses, but also associates it with the total number of requests, so that the error rate can more accurately reflect the actual operation effect of the API in the process of processing the entire batch of requests, avoiding the one-sidedness of API performance evaluation that may be caused by only considering the number of failures.
[0102] 2. The calculated error rate is presented as the actual proportion of the number of response failures in the total number of requests, which can intuitively and realistically show the relative degree of abnormality in the API within a specific time window. Whether it is the operation and maintenance team, development team or business department using the API service, this clear and definite error rate value can quickly understand what proportion of request processing problems occurred in the API during the period, so as to have a more accurate grasp of the overall health of the API.
[0103] 2. Easy to set reasonable thresholds and make accurate decisions
[0104] 1. Using the error rate calculated based on the total number of requests and the percentage of failures as performance indicator data provides a standardized basis for setting reasonable thresholds. Under different API application scenarios and business requirements, it is relatively easy to set appropriate thresholds for this error rate based on past experience, business tolerance, and other factors. For example, for some financial transaction APIs that require extremely high accuracy, a lower error rate threshold may be set; while for some information query APIs that have a certain tolerance for occasional failures, a relatively high error rate threshold can be set.
[0105] 2. With clear and standardized error rate indicators and corresponding thresholds, there is a more accurate basis for decision-making when judging whether the API needs to take specific measures (such as opening a fuse mechanism, optimizing and adjusting, etc.). If the calculated error rate exceeds the set threshold, it can be clearly determined that there is a problem with the operation status of the API, and corresponding actions need to be taken in a timely manner. This method of making decisions based on the comparison of accurately calculated error rates with reasonable thresholds can effectively avoid misjudgments caused by unclear or inaccurate decision-making basis, and improve the efficiency and accuracy of system operation and management.
[0106] 3. Conducive to performance trend analysis and continuous optimization
[0107] 1. By continuously calculating the error rate based on the total number of requests and the proportion of failures in different time windows, operation and maintenance personnel can easily observe the performance trend of the API. For example, if the error rate is found to be gradually decreasing in several consecutive time windows, it means that the performance of the API is constantly improving; on the contrary, if the error rate is on an upward trend, it indicates that there may be some factors affecting the performance of the API that need further investigation. This accurate insight into performance trends helps to timely discover potential problems in the operation of the API, and provides strong support for taking preventive measures or optimizing strategies in advance.
[0108] 2. Based on the API performance trend reflected by the error rate, the development team can continuously optimize the API in a targeted manner. If the error rate is high or shows an upward trend, the development team can deeply analyze the reasons for the increase in the error rate, such as code logic problems, insufficient resources, or the impact of external interfaces, and then take corresponding measures such as code optimization, resource allocation, interface adjustment, etc. to reduce the error rate, thereby achieving continuous optimization of API performance and ensuring high-quality delivery of API services.
[0109] Optionally, the obtaining of a set fuse state adjustment condition to determine whether the state of the circuit breaker needs to be adjusted;
[0110] Obtaining a set fuse silence time, wherein the fuse state adjustment condition includes the fuse silence time;
[0111] It is determined whether the time when the API is in the blown state reaches the data blown silent time. If so, the circuit breaker is switched from the fully open state to the half-open state to try to allow some requests to enter the backend service.
[0112] To this end, the above solution has the following technical advantages:
[0113] 1. Avoid frequent adjustments and misoperation
[0114] 1. By obtaining the set fuse silence time as part of the fuse state adjustment condition, a time buffer mechanism is set for the adjustment of the circuit breaker state. After the API enters the fuse state, the circuit breaker state will not be adjusted immediately due to some short-term fluctuations or accidental situations, but will wait until the specified fuse silence time is reached.
[0115] 2. This effectively avoids frequent switching of the circuit breaker between full-open and half-open states due to some temporary fluctuations in the system, such as short-term network jitter or small abnormalities in the backend service. Frequent switching may cause system instability and may also make it difficult for operation and maintenance personnel to accurately judge the actual operation status of the API. Setting the fuse silence time can greatly reduce the risk of such misoperation and ensure that the circuit breaker state adjustment is based on relatively stable and continuous conditions.
[0116] II. Orderly restoration of services and risk control
[0117] 1. When the API is in the circuit breaker state for the circuit breaker silence time, the circuit breaker is switched from the fully open state to the half-open state, and some requests are allowed to enter the backend service. This gradual and orderly recovery method can test whether the backend service has restored its normal operation to a certain extent, while not releasing a large number of requests at once, thus avoiding problems such as system failure or performance degradation caused by the backend service not being fully restored.
[0118] 2. By allowing some requests to enter the backend service first, the recovery of the backend service can be monitored more accurately. If the backend service can handle it normally and no new exceptions occur during the period when some requests pass through, then you can further consider gradually expanding the number of requests allowed to pass; conversely, if new exceptions occur, you can switch the circuit breaker back to the fully open state in time to continue to protect the backend service. This operation process makes the risk of the service recovery process controllable, which is conducive to the system gradually recovering to normal operation after a failure.
[0119] 3. Improve the controllability and predictability of operation and maintenance
[0120] 1. Operation and maintenance personnel can flexibly set the circuit breaker silence time according to the specific characteristics of the API, business requirements, and previous operation and maintenance experience. This allows them to better control the adjustment rhythm of the circuit breaker status and decide when to start trying to restore the service based on actual conditions, thereby improving the controllability of the entire API service operation and maintenance.
[0121] 2. For the entire system, since there is a clear circuit breaker silence time as the basis for adjusting the circuit breaker status, relevant personnel can more accurately predict when the service recovery attempt will be made after the API enters the circuit breaker state, as well as the possible subsequent operation process. This predictability helps to better plan the allocation of system resources, arrange subsequent monitoring and operation and maintenance work, etc., making system operation and maintenance more orderly and efficient.
[0122] Optionally, when the API is in a mode of allowing some requests to pass, the performance indicator data of the request is monitored, and if the performance indicator data does not reach a preset indicator threshold, the circuit breaker is closed to determine that the backend service has returned to normal; otherwise, the fuse is continued to be opened, including: in the half-open state, the performance indicator data of the request is monitored, and if the performance indicator data does not reach the abnormal threshold, the circuit breaker is closed to determine that the backend service has returned to normal; otherwise, the fuse is continued to be opened and the API is kept in the fused state.
[0123] To this end, the above solution has the following technical advantages:
[0124] 1. Accurately determine the recovery status of backend services
[0125] 1. When the API is in a half-open state (i.e., a mode that allows some requests to pass), by continuously monitoring the performance indicator data of the request and comparing it with the preset abnormal threshold, it can accurately determine whether the backend service has returned to normal based on quantitative data. This judgment method based on objective data is more scientific and accurate than relying solely on subjective guesswork or simple time interval waiting, and can effectively avoid misjudging the recovery status of the backend service.
[0126] 2. The monitored performance indicator data can fully reflect the actual operation of the backend service when processing some requests, including but not limited to response time, error rate and other aspects. By comprehensively considering the relationship between these performance indicator data and abnormal thresholds, we can more comprehensively understand the operating performance of the backend service in a half-open state, so as to more accurately determine whether it has truly returned to a normal state, providing a solid basis for the subsequent decision on whether to close the circuit breaker.
[0127] 2. Effectively protect system stability
[0128] 1. When the monitored performance indicator data does not reach the abnormal threshold, it means that the backend service is performing normally. At this time, closing the circuit breaker can quickly restore the system to normal operation mode, allowing the API to process all requests normally, ensuring the smooth progress of business processes, and avoiding the impact of unnecessary continuous circuit breaker status on the normal service capacity of the system.
[0129] 2. On the contrary, if the performance indicator data reaches or exceeds the abnormal threshold, it means that there may still be problems with the backend service. Continuing to turn on the circuit breaker and keeping the API in the circuit breaker state can effectively prevent the problematic backend service from receiving too many requests, avoid the further spread of the backend service failure and cause serious problems such as the avalanche effect in the system, and continuously protect the stability and reliability of the system.
[0130] 3. Realize intelligent dynamic adjustment
[0131] 1. The entire process dynamically adjusts the state of the circuit breaker according to the real-time monitoring performance indicator data, realizing an intelligent decision-making mechanism based on actual operation conditions. The system does not decide whether to restore the service according to a fixed time or simple rules, but makes flexible judgments based on the actual performance of the backend service in processing some requests. This intelligent dynamic adjustment method can better adapt to different business scenarios and complex changes in backend services.
[0132] 2. Through intelligent dynamic adjustment, on the one hand, it can avoid premature closing of the circuit breaker when the backend service has not been fully restored, resulting in system resources being wasted on processing requests that may fail; on the other hand, it can also close the circuit breaker in time after the backend service has indeed returned to normal, improving the overall operating efficiency of the system. At the same time, this also reduces the workload of operation and maintenance personnel. There is no need for frequent manual intervention to determine whether the backend service has returned to normal. Instead, the system automatically makes intelligent adjustments based on performance indicator data, improving operation and maintenance efficiency.
[0133] Optionally, the method further comprises:
[0134] Mark the status of the API in the circuit breaker state, and the marked status includes at least one of normal and abnormal;
[0135] Generate warning information for APIs marked as abnormal.
[0136] Optionally, the method further includes: obtaining an alarm address configured on the fuse plug-in to send the alarm information based on the alarm address.
[0137] To this end, the above solution has the following technical advantages:
[0138] 1. Clear status identification and quick problem location
[0139] 1. Mark the status of APIs in the circuit-breaking state, and clearly distinguish their status into normal, abnormal, etc., so that operation and maintenance personnel can see at a glance when checking the API status. This clear status identification helps to quickly locate the API with problems, especially in complex scenarios where many APIs are in the circuit-breaking state at the same time. It can quickly distinguish which APIs may need further attention and processing, improving the efficiency of troubleshooting.
[0140] 2. By marking abnormal APIs, operation and maintenance personnel can conduct in-depth investigation and processing of these APIs. Instead of spending the same amount of effort on troubleshooting all APIs in the fuse state, they can accurately focus on the APIs that may actually fail based on the markings, thereby solving problems more efficiently, reducing system downtime, and ensuring the normal operation of the business.
[0141] 2. Timely and effective warning mechanism
[0142] 1. Generate alarm information for APIs marked as abnormal, ensuring that relevant personnel can be informed of abnormal conditions in a timely manner. In a complex system environment, operation and maintenance personnel may not be able to pay attention to the status changes of each API at all times. The timely generation of alarm information can proactively remind them that there are abnormalities in the APIs, prompting them to take prompt action to avoid further deterioration of the problem due to failure to discover the problem in time, affecting the overall performance of the system and the normal development of the business.
[0143] 2. Regardless of the reason why the API is in a blown state and marked as abnormal, an alarm message can be generated, achieving comprehensive coverage of various abnormal situations that may occur. This ensures that operation and maintenance personnel will not miss any abnormal API that may affect the normal operation of the system, ensuring the reliability and stability of the system.
[0144] 3. Accurate warning information push
[0145] 1. By obtaining the alarm address configured on the fuse plug-in, the alarm information can be accurately sent to the designated receiving end, such as the mailbox of the operation and maintenance personnel, instant messaging tools, etc. This ensures that the alarm information can be accurately delivered to the relevant personnel, avoiding the relevant personnel not being able to receive the alarm in time due to poor information transmission or sending to the wrong place, thereby delaying the handling of abnormal APIs.
[0146] 2. Different operation and maintenance personnel or teams may have different preferences and needs for receiving alarm information. Configuring the alarm address can meet such personalized requirements. For example, some operation and maintenance personnel like to receive alarms via email, while others want to see alarm information immediately in instant messaging tools. By configuring the corresponding alarm address, accurate information push can be achieved according to the needs of different people, which improves the practicality and flexibility of the alarm mechanism.
[0147] Optionally, the method further includes: responding to the fuse query request, retrieving the abnormal API and obtaining the corresponding error log to generate an abnormality report.
[0148] To this end, the above solution has the following technical advantages:
[0149] 1. Quickly locate and troubleshoot problems
[0150] 1. When a fuse query request is received, the abnormal API can be specifically searched, which allows operation and maintenance personnel to focus on the API with the problem without having to search aimlessly among all APIs. This targeted search method can quickly locate the specific abnormal API, saving time and energy in troubleshooting.
[0151] 2. By obtaining the corresponding error log, the operation and maintenance personnel can deeply understand the detailed operation status of the API when an abnormality occurs, including the specific link and operation when the error occurs, as well as the relevant error prompt information, etc. The error log is like a "black box" record, which provides the most direct and detailed basis for accurately determining the root cause of the problem, and helps to further investigate and solve the API abnormality problem.
[0152] 2. Comprehensive presentation of abnormal situations
[0153] 1. Generate an exception report based on the retrieved abnormal API and its corresponding error log, which can comprehensively and systematically organize and present the relevant information of the API exception. The exception report can include the basic information of the API, the time when the exception occurred, the error type, and the analysis of the possible causes of the exception, so that operation and maintenance personnel, developers and other related personnel can have a complete and clear understanding of the abnormal situation of the API by reading a report.
[0154] 2. In a system development and operation and maintenance environment involving multiple personnel and departments, exception reports can serve as an effective communication tool. Developers can evaluate whether the code needs to be modified or optimized based on the information in the exception report; operation and maintenance personnel can further adjust the system configuration or take other maintenance measures based on the report. People from different departments can collaborate effectively based on this report to jointly solve API exception problems, thereby improving the overall work efficiency of the team.
[0155] 3. Support decision-making and optimization and improvement
[0156] 1. For managers, exception reports provide detailed data and analysis on API exceptions. Based on this information, they can decide whether to adjust related business processes or increase resources to improve API performance. For example, if the report shows that an API frequently has exceptions and affects the normal operation of the business, managers may decide to prioritize optimizing or replacing the API.
[0157] 2. In the long run, by analyzing and summarizing a large number of exception reports, we can find common problems and weak links in API design, development, operation and maintenance, etc. The development team can optimize and improve the overall architecture and code implementation of the API based on this, and the operation and maintenance team can also adjust the system monitoring and maintenance strategy, so as to continuously improve the stability and performance of the API and ensure the sustainable and healthy development of the business.
[0158] Figure 2 This is a schematic diagram of the structure of a device for enhancing the abnormal fuse mechanism according to an embodiment of the present application. Figure 2 As shown, it includes:
[0159] The first program unit is used to monitor the performance indicator data of the API within a set time period, and calculate the corresponding abnormality rate indicator based on the monitored performance indicator data;
[0160] The second program unit is used to compare the abnormal rate indicator with a preset abnormal threshold, and if the abnormal rate indicator exceeds the preset abnormal threshold, it is determined that a fuse needs to be opened;
[0161] The third program unit is used to generate a circuit breaker opening control instruction if the circuit breaker needs to be opened, so as to open the circuit breaker and thereby make the API enter the circuit breaker state as follows;
[0162] Make all requests return a defined error status code;
[0163] Obtain the set fuse state adjustment condition to determine whether the circuit breaker state needs to be adjusted;
[0164] If adjustment is needed, the fuse state is changed from a mode that completely blocks requests to a mode that allows some requests to pass, so as to try to restore access to the backend service;
[0165] When the API is in a mode that allows some requests to pass, the performance indicator data of the request is monitored. If the performance indicator data does not reach the preset indicator threshold, the circuit breaker is closed to determine that the backend service has returned to normal; otherwise, the fuse continues to be opened.
[0166] Figure 3 This is a flow chart of an abnormal fuse monitoring method according to an embodiment of the present application. Figure 3 As shown, it includes:
[0167] Monitor the performance indicator data of the API within a set time period, and calculate the corresponding abnormal rate indicator based on the monitored performance indicator data;
[0168] The abnormal rate indicator is compared with the preset abnormal threshold. If the abnormal rate indicator exceeds the preset abnormal threshold, it is determined that the circuit breaker needs to be turned on.
[0169] If the fuse needs to be opened, a circuit breaker opening control instruction is generated to open the circuit breaker and thereby put the API into a fuse state.
[0170] Optionally, when the API enters the circuit breaker state, all requests return a defined error status code; obtain the set circuit breaker state adjustment condition to determine whether the circuit breaker state needs to be adjusted; if adjustment is required, the circuit breaker state is changed from a mode that completely blocks requests to a mode that allows some requests to pass, so as to try to restore access to the backend service.
[0171] Optionally, the method further includes: when the API is in a mode that allows some requests to pass, monitoring the performance indicator data of the request, if the performance indicator data does not reach a preset indicator threshold, closing the circuit breaker to determine that the backend service has returned to normal; otherwise, continuing to open the fuse.
[0172] Figure 4 FIG. 1 is a schematic diagram of an integrated API management and service system structure according to an embodiment of the present application. Figure 4 As shown, it includes: a client, an API gateway, and a back-end server. The client is used to generate an access request, and the access request is sent to the back-end server through the API gateway. The back-end server is used to respond to the service request and return a response result. During this process, the API gateway executes the enhancement method of the abnormal fuse mechanism described in any one of the embodiments of the present application, or the abnormal fuse monitoring method described in any one of the embodiments of the present application.
[0173] An embodiment of the present application also provides an API gateway, which is used to execute the enhancement method of the abnormal fuse mechanism described in any one of the embodiments of the present application, or the abnormal fuse monitoring method described in any one of the embodiments of the present application.
[0174] An embodiment of the present application also provides a computer storage medium, on which a computer executable program is stored. When the computer executable program is executed, the method for enhancing the abnormal fuse mechanism described in any one of the embodiments of the present application, or the method for monitoring the abnormal fuse described in any one of the embodiments of the present application, is implemented.
[0175] The above-mentioned method according to the embodiment of the present application can be implemented in hardware, firmware, or implemented as software or computer code that can be stored in a recording medium (such as a CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or implemented as a computer code originally stored in a remote recording medium or a non-temporary machine-readable medium downloaded through a network and stored in a local recording medium, so that the method described herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor or programmable or dedicated hardware (such as an AS IC or FPGA). It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code, and when the software or computer code is accessed and executed by a computer, a processor or hardware, the verification code generation method described herein is implemented. In addition, when a general-purpose computer accesses the code for implementing the verification code generation method shown here, the execution of the code converts the general-purpose computer into a dedicated computer for executing the verification code generation method shown here.
[0176] It should be noted that the same and similar parts between the various embodiments in this specification can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments. The device and system embodiments described above are merely schematic, wherein the modules described as separate components may or may not be physically separated, and the components indicated as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. A person of ordinary skill in the art can understand and implement it without paying creative labor.
[0177] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
Claims
1. A method for enhancing an abnormal fuse mechanism, characterized in that: include: Monitor the performance indicator data of the API within a set time period, and calculate the corresponding abnormal rate indicator based on the monitored performance indicator data; The abnormal rate indicator is compared with the preset abnormal threshold. If the abnormal rate indicator exceeds the preset abnormal threshold, it is determined that the circuit breaker needs to be turned on. If the circuit breaker needs to be opened, a circuit breaker opening control instruction is generated to open the circuit breaker and accordingly make the API enter the circuit breaker state as follows; Make all requests return a defined error status code; Obtain the set fuse state adjustment condition to determine whether the circuit breaker state needs to be adjusted; If adjustment is needed, the fuse state is changed from a mode that completely blocks requests to a mode that allows some requests to pass, so as to try to restore access to the backend service; When the API is in a mode that allows some requests to pass, monitor the performance indicator data of the request. If the performance indicator data does not reach the preset indicator threshold, close the circuit breaker to make sure that the backend service has returned to normal; otherwise, continue to open the circuit breaker.
2. A method for enhancing an abnormal fuse mechanism according to claim 1, characterized in that: The method further includes: calculating the total number of requests and the number of errors of the API within a set time period, so as to use the total number of requests and the number of errors as the performance indicator data; The calculating of the corresponding abnormality rate index according to the monitored performance index data includes: calculating the error rate according to the total number of requests and the number of errors; The abnormality threshold is an error rate threshold. Correspondingly, the abnormality rate index is compared with a preset abnormality threshold. If the abnormality rate index exceeds the preset abnormality threshold, it is determined that the fuse needs to be opened, including: The error rate is compared with the error rate threshold to determine whether the error rate threshold exceeds the error rate threshold. If so, it is determined that the fuse needs to be opened.
3. The method for enhancing the abnormal fuse mechanism according to claim 1, characterized in that: The method further comprises: Obtaining a time window for calculating the performance indicator data, wherein the time window defines the time period; Monitoring and recording the response status of all requests received by the API within the time window; When the time window ends, the performance indicator data is calculated based on the recorded response status.
4. The method for enhancing the abnormal fuse mechanism according to claim 3, characterized in that: The monitoring and recording of the response status of all requests received by the API within the time window includes: Within the time window, monitoring and recording the result of successful response and failed response of each request received by the API, wherein the response status includes at least one of successful response and failed response; After the time window ends, the performance indicator data is calculated according to the recorded response status, including: The number of successful responses and the number of failed responses within the time window are counted to calculate an error rate, and the error rate is used as the performance indicator data.
5. A method for enhancing an abnormal fuse mechanism according to claim 4, characterized in that: The counting of the number of successful responses and the number of failed responses within the time window to calculate the error rate, wherein the error rate is used as the performance indicator data, includes: Calculate the total number of requests according to the number of successful responses and the number of failed responses within the time window; The ratio of the number of response failures within the time window to the total number of requests is calculated, and the calculated ratio is used as the performance indicator data.
6. A device for enhancing abnormal fuse mechanism, characterized in that: include: The first program unit is used to monitor the performance indicator data of the API within a set time period, and calculate the corresponding abnormality rate indicator based on the monitored performance indicator data; The second program unit is used to compare the abnormal rate indicator with a preset abnormal threshold, and if the abnormal rate indicator exceeds the preset abnormal threshold, it is determined that a fuse needs to be opened; The third program unit is used to generate a circuit breaker opening control instruction if the circuit breaker needs to be opened, so as to open the circuit breaker and thereby make the API enter the circuit breaker state as follows; Make all requests return a defined error status code; Obtain the set fuse state adjustment condition to determine whether the circuit breaker state needs to be adjusted; If adjustment is needed, the fuse state is changed from a mode that completely blocks requests to a mode that allows some requests to pass, so as to try to restore access to the backend service; When the API is in a mode that allows some requests to pass, monitor the performance indicator data of the request. If the performance indicator data does not reach the preset indicator threshold, close the circuit breaker to make sure that the backend service has returned to normal; otherwise, continue to open the circuit breaker.
7. A method for monitoring abnormal fuse, characterized in that: include: Monitor the performance indicator data of the API within a set time period, and calculate the corresponding abnormal rate indicator based on the monitored performance indicator data; The abnormal rate indicator is compared with the preset abnormal threshold. If the abnormal rate indicator exceeds the preset abnormal threshold, it is determined that the circuit breaker needs to be turned on. If the circuit breaker needs to be opened, a circuit breaker opening control instruction is generated to open the circuit breaker and thereby put the API into the circuit breaker state.
8. An integrated API management and service system, characterized in that: include: A client, an API gateway, and a backend server, wherein the client is used to generate an access request, and the access request is sent to the backend server through the API gateway. The backend server is used to respond to the service request and return a response result. During this process, the API gateway executes the enhancement method of the abnormal fuse mechanism described in any one of claims 1 to 5, or the abnormal fuse monitoring method described in claim 7.
9. An API gateway, characterized in that: A method for implementing the enhanced abnormal fuse mechanism described in any one of claims 1 to 5, or a method for monitoring abnormal fuses described in claim 7.
10. A computer storage medium, characterized in that: The computer storage medium stores a computer executable program, and when the computer executable program is executed, the method for enhancing the abnormal fuse mechanism described in any one of claims 1 to 5, or the method for monitoring the abnormal fuse described in claim 7 is implemented.
Citation Information
Cited By
Method and system for monitoring fusing and quick recovery of intelligent transaction based on automation
CN120743612A