Intelligent switching method and system for service availability guarantee in multi-operator environment

Abstract

The invention discloses an intelligent switching method and system for service availability guarantee in a multi-operator environment, and the method comprises the steps: obtaining and carrying out the structural storage of operator service interface call logs, and constructing a configuration library containing service configuration parameters; analyzing a service calling record through a sliding window model in combination with the historical calling data and the health examination sample size, and generating a comprehensive health degree score; executing a decision based on the score and a fusing threshold value to determine a service health state, initiating simulation call detection on the fusing service, and terminating and recording a result if a failure rate exceeds a limit; then, available services are screened, a routing decision is generated by means of a multi-objective optimization algorithm, and notification is broadcasted through a message queue when the service state is changed. According to the invention, data support is provided for intelligent routing decision, and service continuity and user experience are guaranteed.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an intelligent switching method and system for ensuring service availability in a multi-carrier environment, applicable to information system architectures that require the integration of multiple external service providers. Background Technology

[0002] In modern information system architectures, to ensure high availability and stability, systems typically need to access the service interfaces of multiple operators simultaneously. With increasing business complexity and service dependencies, implementing an efficient and reliable service switching mechanism in a multi-operator environment has become a significant technical challenge in the industry.

[0003] Currently, common service availability assurance technologies in the industry mainly include static priority scheduling and simple failure counting. The static priority scheduling mechanism calls the service interfaces of different operators in a pre-configured fixed priority order. When a high-priority channel fails, the system automatically switches to a low-priority channel. The simple failure counting mechanism, on the other hand, triggers the service switching decision based on the number of consecutive failures (such as 3 or 5 times).

[0004] In addition, some more advanced technical solutions employ time-window-based anomaly detection mechanisms, which determine the health status of a service by statistically analyzing the failure rate or response time of service interfaces within a fixed time window. However, such solutions typically suffer from insufficient accuracy—fixed windows are difficult to adapt to the traffic fluctuation characteristics under different business scenarios, are prone to misjudgments triggered by occasional anomalies, and have relatively long response times for systemic failures, usually requiring tens of minutes to complete anomaly detection and service switching.

[0005] The main shortcomings of existing technical solutions are: a lack of real-time dynamic perception of service health status, poor fault tolerance of fault judgment mechanisms based on simple thresholds, inefficient recovery processes relying on manual intervention, and insufficient coordination between detection and recovery mechanisms. These problems result in slow system response, high false positive rates, and low resource utilization efficiency when facing complex and ever-changing network environments, failing to meet the accuracy and real-time requirements of modern high-availability systems for service switching. Summary of the Invention

[0006] To address the shortcomings of the existing technologies, the present invention aims to provide an intelligent switching method and system for ensuring service availability in a multi-carrier environment. By constructing a dual-module core service infrastructure, implementing a high-frequency health detection mechanism, implementing a low-frequency detection and recovery mechanism, and establishing a service routing and status notification system, the present invention solves the problems of lack of real-time perception of service health status, poor fault tolerance in fault determination, low efficiency of recovery process, and insufficient coordination between detection and recovery mechanisms in the existing technologies.

[0007] To achieve the above objectives, the present invention provides an intelligent handover method for ensuring service availability in a multi-carrier environment, comprising: This invention provides an intelligent handover method for ensuring service availability in a multi-carrier environment, comprising: The system acquires call log data from multiple operator service interfaces, stores the call log data in a structured manner to obtain a service call log recording system, and simultaneously constructs a service configuration library containing operator service configuration parameters. Based on the historical call data in the service call log system and the health check sample size in the service configuration library, a sliding window statistical model is used to obtain the most recent N call records of the target operator's service. Anomaly identification and performance analysis are performed on the most recent N call records to generate a comprehensive health score. Based on the comprehensive health score and the abnormal circuit breaker threshold in the service configuration library, a circuit breaker decision is executed to output the health status of the operator's service. Based on the health status of the operator services, select operator services that are in a circuit breaker state, initiate multiple simulated call requests to the operator services in the circuit breaker state, maintain a sliding window to record the detection results during the detection process, calculate the failure rate within the sliding window, terminate the remaining detection when the failure rate exceeds a preset termination threshold, and write the detection results into the service call log recording system. Based on the health status of the operator services, a list of available operator services is obtained and those in a circuit breaker state are filtered out. A target operator service is selected according to a multi-objective optimization algorithm, and a routing decision result is generated. When the health status of the operator services changes, a status change event is broadcast through a message queue to generate a status change notification.

[0008] Preferably, the step of structuring and storing the call log data to obtain a service call log recording system includes: Based on the call log data, extract the call timestamp, service provider unique identifier, HTTP response status code, business response status code, response time, calling customer account ID, request interface type, and exception information to construct data record fields; A composite index is established for the data record fields based on the service provider's unique identifier and the call timestamp. The data record fields are then persistently stored to obtain the service call log recording system. The call timestamp stored in the service call log recording system is used to retrieve the most recent N call records in reverse chronological order. The HTTP response status code and the business response status code are used for subsequent network layer anomaly identification and business layer anomaly identification. The response time is used for subsequent performance layer anomaly identification.

[0009] Preferably, the simultaneous construction of a service configuration library containing operator service configuration parameters includes: The key-value storage structure is used to store basic information about the storage provider, circuit breaker policy parameters, performance monitoring indicators, automated management identifiers, and detection configurations. Implement the data synchronization interface between the service configuration library and the service call log recording system to obtain the service configuration library.

[0010] Preferably, the step of obtaining the most recent N call records of the target operator's service using a sliding window statistical model based on historical call data in the service call log recording system and the health check sample size in the service configuration library includes: Based on a distributed task scheduling framework, a distributed lock is used to ensure the single-instance execution of the detection task in the cluster environment, and a health check task is automatically triggered every minute; For each operator service marked as allowing automatic management in the service configuration library, the most recent N call records are obtained from the service call log system in reverse order of the call timestamp, where N is equal to the health check sample size in the service configuration library. A dynamic sliding window is constructed to obtain the most recent N call records. The most recent N call records include HTTP response status code, business response status code, and response time field.

[0011] Preferably, the anomaly identification and performance analysis of the most recent N call records includes: For each call record in the most recent N call records, identify records with HTTP response status codes of 4xx or 5xx and mark them as network layer abnormal records; Based on the HTTP response status codes and business response status codes stored in the service call log system, records with an HTTP response status code of 200 but a business response status code indicating failure are identified and marked as business layer abnormal records. Based on the response time stored in the service call log system, calculate the average, median, and percentile of the response time of the most recent N call records, and mark records whose response time exceeds the upper limit of the average response time or the percentile time warning threshold in the service configuration library as performance layer abnormal records. Based on the network layer anomaly records, the service layer anomaly records, and the performance layer anomaly records, the anomaly identification results are obtained; Based on the anomaly identification results, the overall failure rate and the performance anomaly ratio are calculated to obtain the performance analysis results.

[0012] Preferably, the step of generating a comprehensive health score; performing a circuit breaker decision based on the comprehensive health score and the abnormal circuit breaker threshold in the service configuration library, and outputting the operator service health status includes: Based on the most recent N call records, the response time in the service call log recording system is extracted and standardized to obtain a standardized response time value; the HTTP response status code is extracted and numerically mapped; the business response status code is extracted and semantically encoded; the call timestamp is extracted to calculate periodic features; the sliding statistics of the historical failure rate are calculated based on historical call records; and the time interval features are calculated based on the call timestamps of adjacent call records to construct a multi-dimensional feature vector. The Kolmogorov-Arnold transform is applied to the projective transformation of the multidimensional feature vectors. A projective matrix is ​​constructed using orthogonal basis functions, and the multidimensional feature vectors are projected onto a low-dimensional representation space to obtain projective feature vectors. Based on the projective feature vectors of historical normal call records in the service call log system, the probability distribution of each region in the feature space is calculated to obtain the entropy distribution benchmark of the normal mode; based on the projective feature vectors within the current sliding window, the probability distribution of the current feature space is calculated to obtain the current entropy distribution; the relative entropy between the current entropy distribution and the entropy distribution benchmark of the normal mode is calculated, and when the relative entropy exceeds a preset entropy threshold, it is marked as an entropy-driven anomaly. Based on the projective feature vector, a function mapping relationship of operator service behavior is constructed. The gradient change of service quality index is calculated through automatic differentiation technology to identify key factors that cause service anomalies and their corresponding weights. Combining the network layer anomaly record, the service layer anomaly record, the performance layer anomaly record, and the entropy-driven anomaly, the anomaly detection results are mapped to a unified health score space. The complexity index of service behavior is calculated using Kolmogorov complexity theory to obtain the comprehensive health score. The overall health score is compared with the abnormal circuit breaker threshold in the service configuration library. When the overall health score is lower than the abnormal circuit breaker threshold and the "Allow automatic circuit breaker" flag in the service configuration library is true, the operator service health status is set to circuit breaker status. When the overall health score is higher than the abnormal circuit breaker threshold, the operator service health status is set to healthy status, and the operator service health status is output.

[0013] Preferably, the step of calculating the probability distribution of each region in the feature space based on the projective feature vector of historical normal call records in the service call log recording system to obtain the entropy distribution benchmark of the normal mode further includes: Based on the entropy distribution trend of historical service call data in the service call log system, the preset entropy threshold is dynamically adjusted for operator services with unique identifiers for different service providers to adapt to the service characteristics of different operators, thus obtaining an adaptive entropy threshold for each operator service; wherein, the adaptive entropy threshold is used for subsequent anomaly determination of relative entropy.

[0014] Preferably, based on the health status of the operator services, operator services in a circuit breaker state are selected, and multiple simulated call requests are initiated to the operator services in the circuit breaker state, including: Based on the distributed task scheduling framework, a probe task is automatically triggered every five minutes according to the circuit breaker simulation probe frequency in the service configuration library. The operator service health status is used to identify and filter the operator services that are currently in the circuit breaker state, and a list of circuit breaker service providers is obtained. For each operator service in the circuit breaker service provider list, standardized simulated request parameters are generated using the request address, interface version, and key information of the corresponding service provider ID in the service configuration library. The probe counter is initialized, the request timeout is configured, and M simulated call requests are initiated based on the number of single probe requests M in the service configuration library.

[0015] Preferably, the step of maintaining a sliding window to record the detection results during the detection process, calculating the failure rate within the sliding window, terminating the remaining detection when the failure rate exceeds a preset termination threshold, and writing the detection results into the service call log recording system includes: Based on the historical call data of the operator's services under the circuit breaker status, the call timestamp and response time are extracted to construct a time series feature to obtain a time view; the HTTP response status code and business response status code are extracted to analyze error types and distribution to construct an error view; the request interface type and calling customer account ID are analyzed to construct a dependency view; and the regional performance mode is identified based on the regional attributes in the service provider's basic information to construct a regional view, thus obtaining a multi-dimensional service status view. For each view in the multidimensional service status view, a dedicated evolutionary subpopulation is constructed. Within the evolutionary subpopulation, a genetic programming method is used to generate a detection program. The detection strategy exchange between subpopulations is realized through a knowledge sharing protocol to obtain a co-evolving detection strategy set. Based on the co-evolutionary detection strategy set, a lightweight, rapid detection is performed to verify the network connectivity and basic response capabilities of the service, yielding rapid detection results. When the rapid detection results indicate that the service is basically available, a medium-level in-depth detection is performed to verify the functional integrity and performance indicators of the service, yielding medium-level detection results. When the medium-level detection results indicate that key functions are normal and performance indicators meet the average response time upper limit in the service configuration library, a comprehensive in-depth detection is performed to evaluate the stability and reliability of the service, yielding comprehensive detection results. During the detection process, a sliding window of size K is maintained to record the K most recent detection results, and the failure rate within the sliding window is calculated based on the HTTP response status code and business response status code in the detection results. By comprehensively analyzing the real-time detection results of the corresponding subpopulations in the time view, error view, dependency view, and regional view, a unified decision to continue or terminate the detection is generated using majority voting or weighted average methods. When the failure rate within the sliding window exceeds the detection termination threshold in the service configuration library, the remaining detection is terminated, and the detection results, including the detection timestamp, service provider unique identifier, HTTP response status code, business response status code, and response time, are written to the service call log recording system.

[0016] Preferably, the step of performing lightweight, rapid detection and verification of network connectivity and basic response capabilities of the service based on the co-evolutionary detection strategy set to obtain rapid detection results includes: Based on the lightweight detection strategy in the aforementioned co-evolutionary detection strategy set, a low-cost detection request is initiated according to the request address corresponding to the service provider ID in the service configuration library. The network connectivity of the service is verified by sending a basic connectivity test message, and the basic response capability of the service is verified by calling the service's health check interface. The HTTP response status code and response time of the detection response are recorded to obtain the fast detection result. The fast detection result is used to determine whether to perform a medium-depth detection.

[0017] Preferably, the step of obtaining a list of available operator services based on the operator service health status and filtering operator services in a circuit breaker state, selecting a target operator service according to a multi-objective optimization algorithm, and generating a routing decision result includes: The optimization objectives are defined as minimizing service response time, maximizing service success rate, optimizing cost-effectiveness ratio, and balancing load distribution. The constraints are established as service quality baseline requirements, operator call quota limits, specific business scenario requirements, and system resource usage limits, resulting in a multi-objective decision-making framework. The system constructs a performance-priority population to minimize service response time, a stability-priority population to maximize service success rate, and a balanced population to balance all optimization objectives. This enables elite individual migration strategies, cross-population crossover operations, and shared fitness evaluation results, resulting in a multi-population population architecture. Based on the multi-objective decision-making framework and the multi-population architecture, weight coefficients are set for each optimization objective, and a weighted summation fitness function is constructed. For each decision-making individual in the multi-population architecture, its performance value on the service response time target is calculated based on the historical response time recorded in the service call log system; its performance value on the service success rate target is calculated based on the success rate in the historical call records; its performance value on the cost-effectiveness target is calculated based on the cost information in the service configuration library; and its performance value on the load distribution target is calculated based on the current call frequency of each operator's services. The weighted summation fitness function is used to calculate the comprehensive fitness value. It is then checked whether the decision-making individual violates the constraints, and the constraint violation degree is calculated and added as a penalty to the comprehensive fitness value. Based on the actual response time, success rate, cost, and load distribution data of the decision-making individual recorded in the service call log system during the historical execution process, the mean and variance of the historical performance are calculated to obtain long-term stability indicators and reliability indicators. The long-term stability indicators and the reliability indicators are then integrated into the comprehensive fitness value to obtain the fitness evaluation result. Based on the fitness assessment results, the mutation rate is dynamically adjusted according to the current population diversity. Individual selection is carried out using tournament selection or roulette wheel selection methods to retain the best individual. Evolutionary iteration is then performed to obtain the optimal routing decision individual. The optimal routing decision individual is converted into a weighted list of operator call priorities. Based on the operator service health status, operator services in circuit breaker state are filtered out. The target operator service is selected according to the operator call priority list to obtain the routing decision result. The routing decision result includes the selected service provider ID and the corresponding call weight.

[0018] Preferably, the step of setting weight coefficients for each optimization objective and constructing a weighted summation fitness function based on the multi-objective decision-making framework and the multi-population architecture further includes: Based on the execution results of historical routing decisions in the service call log system, the deviation data between the predicted response time and the actual response time, the deviation data between the predicted success rate and the actual success rate are collected during decision execution, and the deviation data between the predicted performance and the actual performance are calculated. The weight coefficients in the weighted summation fitness function are adjusted based on the deviation data to obtain the updated weighted summation fitness function.

[0019] Preferably, the step of obtaining a list of available operator services based on the operator service health status and filtering operator services in a circuit breaker state, selecting a target operator service according to a multi-objective optimization algorithm, and generating a routing decision result further includes: When the health status of the operator services shows that all operator services are in a circuit breaker state, query the local cache to obtain historical response data or return a preset default value, and generate a downgrade response result. The degradation event is recorded, including the degradation trigger time, degradation reason, and impact scope. A degradation notification is sent through a high-priority alarm channel to obtain the degradation policy execution record. The degradation policy execution record is written to the service call log recording system for subsequent analysis and alarms.

[0020] Preferably, the step of broadcasting a status change event and generating a status change notification via a message queue when the health status of the operator's service changes includes: When the operator's service health status changes from healthy to circuit breaker status or from circuit breaker status to healthy status, a status change event is constructed, which includes the service provider identifier, the status before the change, the status after the change, the change time, and the reason for the change based on the comprehensive health score or the detection result. The status change event is published to a message queue, and a status change notification is sent via email, SMS or instant messaging tools. Based on the importance level of the operator's service in the service configuration library and the current time, determine whether to trigger a telephone alarm, generate a detailed status change report including the reason for the change, the time of the change, and the scope of impact, and obtain the status change notification.

[0021] This invention also provides an intelligent handover system for ensuring service availability in a multi-carrier environment, comprising: The log storage module is used to acquire call log data from multiple operator service interfaces, perform structured storage on the call log data to obtain a service call log recording system; at the same time, it constructs a service configuration library containing operator service configuration parameters. The health detection module is used to obtain the most recent N call records of the target operator's service based on historical call data in the service call log system and the health check sample size in the service configuration library, using a sliding window statistical model; perform anomaly identification and performance analysis on the most recent N call records to generate a comprehensive health score; and execute a circuit breaker decision based on the comprehensive health score and the abnormal circuit breaker threshold in the service configuration library to output the health status of the operator's service. The service detection module is used to filter operator services in circuit breaker state according to the operator service health status, initiate multiple simulated call requests to the operator services in circuit breaker state, maintain a sliding window to record the detection results during the detection process, calculate the failure rate within the sliding window, terminate the remaining detection when the failure rate exceeds a preset termination threshold, and write the detection results to the service call log recording system. The routing decision module is used to obtain a list of available operator services based on the health status of the operator services and filter operator services that are in a circuit breaker state, select a target operator service according to a multi-objective optimization algorithm, and generate a routing decision result; when the health status of the operator services changes, it broadcasts a status change event through a message queue and generates a status change notification.

[0022] Compared with the prior art, the present invention has the following significant advantages: By constructing a dual-module core service infrastructure, implementing a high-frequency health detection mechanism, implementing a low-frequency detection and recovery mechanism, and establishing a service routing and status notification system, the problems of lack of real-time dynamic perception of service health status, poor fault tolerance in fault judgment, low efficiency of recovery process, and insufficient coordination between detection and recovery mechanisms in existing technologies are solved, thus realizing a more accurate, real-time, and automated service availability assurance mechanism. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 A flowchart illustrating an intelligent handover method for ensuring service availability in a multi-carrier environment, provided by an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of an intelligent handover system for ensuring service availability in a multi-carrier environment, provided as an embodiment of the present invention. Detailed Implementation

[0025] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0026] Example 1 like Figure 1 As shown, this embodiment provides an intelligent handover method for ensuring service availability in a multi-carrier environment, including: Step S1: Obtain call log data from multiple operator service interfaces, store the call log data in a structured manner to obtain a service call log recording system; at the same time, construct a service configuration library containing operator service configuration parameters.

[0027] Step S2: Based on the historical call data in the service call log system and the health check sample size in the service configuration library, a sliding window statistical model is used to obtain the most recent N call records of the target operator's service. Anomaly identification and performance analysis are performed on the most recent N call records to generate a comprehensive health score. Based on the comprehensive health score and the abnormal circuit breaker threshold in the service configuration library, a circuit breaker decision is executed to output the operator's service health status.

[0028] Step S3: Based on the health status of the operator services, filter the operator services that are in the circuit breaker state, initiate multiple simulated call requests to the operator services in the circuit breaker state, maintain a sliding window to record the detection results during the detection process, calculate the failure rate within the sliding window, terminate the remaining detection when the failure rate exceeds the preset termination threshold, and write the detection results into the service call log recording system.

[0029] Step S4: Based on the health status of the operator services, obtain a list of available operator services and filter operator services that are in a circuit breaker state. Select the target operator service according to the multi-objective optimization algorithm and generate a routing decision result. When the health status of the operator services changes, broadcast the status change event through the message queue and generate a status change notification.

[0030] In this embodiment, the step of structuring and storing the call log data to obtain a service call log recording system includes: Based on the call log data, extract the call timestamp, service provider unique identifier, HTTP response status code, business response status code, response time, calling customer account ID, request interface type, and exception information to construct data record fields.

[0031] A composite index is established for the data record fields based on the service provider's unique identifier and the call timestamp. The data record fields are then persistently stored to obtain the service call log recording system. The call timestamp stored in the service call log recording system is used to retrieve the most recent N call records in reverse chronological order. The HTTP response status code and the business response status code are used for subsequent network layer anomaly identification and business layer anomaly identification. The response time is used for subsequent performance layer anomaly identification.

[0032] Specifically, the first step is to extract key information fields from the raw call log data. Call log data refers to the raw records generated when the system interacts with external operator services, containing various information about the call process. These raw logs are typically in semi-structured or unstructured form, and may be text files, JSON objects, or other formats. The system extracts eight core fields from these raw logs: call timestamp, service provider unique identifier, HTTP response status code, business response status code, response time, calling client account ID, request interface type, and exception information.

[0033] A call timestamp is a record of the exact time a service call occurred, accurate to the millisecond. It is stored in the standard ISO 8601 format (e.g., "2023-06-01T14:30:15.235Z") to ensure the accuracy and consistency of time records. Call timestamps play a crucial role in subsequent analysis, especially when constructing time-based sliding windows, where the system retrieves the N most recent call records in reverse chronological order of timestamps. Furthermore, timestamps are used to calculate the temporal distribution characteristics of service calls, helping the system identify time-related anomalies, such as periodic failures within specific time periods.

[0034] The service provider's unique identifier is a key field that distinguishes services from different operators. It is usually an alphanumeric string (e.g., "SP_CMCC_SMS" represents China Mobile's SMS service). Each external service provider is assigned a unique identifier for internal system differentiation and referencing. This identifier plays a central role in routing decisions and health status management. The system uses the service provider's unique identifier to track the health status of each operator's service and selects the appropriate target service during service invocation.

[0035] HTTP response status codes refer to the standard HTTP status codes returned by external servers, such as 200 (success), 404 (not found), and 500 (server error). These status codes reflect the result of the network-layer call and are direct evidence of whether the call was successful at the network layer. In exception detection mechanisms, records with HTTP response status codes of 4xx or 5xx are marked as network-layer exceptions. These exceptions typically indicate accessibility problems with the external service or server-side errors.

[0036] Business response status codes are status codes returned by the business logic layer of an external service upon successful HTTP request. Unlike HTTP status codes, business response status codes are typically defined by each service provider to represent different business processing results. This field is crucial for identifying business layer anomalies; analyzing business response status codes helps identify cases where HTTP calls succeeded but business processing failed—anomalies often overlooked in traditional monitoring.

[0037] Response time refers to the time elapsed from when the system initiates a request to when a complete response is received, typically measured in milliseconds. This metric directly reflects the performance status of external services and is a core basis for identifying performance anomalies. It combines historical data and configured thresholds to identify calls with abnormally long response times, even if these calls are functionally successful. The calling client account ID is a unique identifier for the client or user initiating the service call. In multi-tenant systems, this field helps distinguish the calling patterns and demand characteristics of different clients. The request interface type identifies the specific function or operation type of the call, such as "send SMS," "check balance," or "pay order." The exception information field records the details of specific exceptions captured during the call, including exception type, exception information, and stack trace. This information is invaluable for fault diagnosis and root cause analysis.

[0038] After extracting these key fields, a composite index is created on the data records to optimize subsequent query performance. A composite index is a database index structure that contains multiple fields, significantly improving query efficiency for combinations of these fields. In this system, the composite index is primarily built based on the service provider's unique identifier and the call timestamp. This index structure choice is based on the system's core query pattern: the system frequently needs to filter by service provider ID and retrieve the most recent N records in reverse chronological order by timestamp.

[0039] Composite indexes work by concatenating the column values ​​of the index to form index entries, and then building a B+ tree or similar efficient data retrieval structure based on these index entries. When the query conditions include the leading column of the index (in this case, the service provider's unique identifier), the database can quickly locate the relevant records; if the query also includes sorting or filtering conditions on the second column (retrieving timestamps), the composite index can directly provide the sorted results, avoiding additional sorting operations and significantly improving query efficiency.

[0040] In practice, composite indexes are typically created using standard database DDL statements. Taking MySQL as an example, a typical creation statement might look like this: `CREATE INDEX idx_provider_timestamp ON call_logs (service_provider_id, call_timestamp DESC)`. Here, the `DESC` keyword indicates that the timestamp is indexed in descending order, which perfectly meets the system's requirement to retrieve the most recent N call records.

[0041] After creating a composite index, all extracted data record fields are persistently stored in physical storage media, forming a complete service call log recording system. Persistent storage ensures that data remains recoverable and accessible after a system restart or crash, providing a reliable historical data foundation for system health checks and anomaly identification. When selecting storage technologies, systems typically consider data volume, query patterns, and performance requirements. For call logs and other data that accumulates over time and is primarily used for analysis, systems may choose time-series databases (such as InfluxDB and TimescaleDB) or NoSQL databases that support time-range queries (such as MongoDB and Cassandra) as storage engines.

[0042] Once the service call logging system is established, each stored field will play a crucial role in subsequent health checks and anomaly detection. Specifically, the call timestamp is used to retrieve the most recent N call records in reverse chronological order, building a dynamic sliding window; the HTTP response status code is used for network layer anomaly detection, identifying call failures caused by network problems or server errors; the business response status code is used for business layer anomaly detection, capturing cases where HTTP requests succeed but business processing fails; and the response time is used for performance layer anomaly detection, identifying calls that function correctly but fail to meet performance standards.

[0043] This multi-dimensional anomaly detection mechanism is a key feature of this system. Traditional service monitoring typically focuses only on service accessibility (i.e., HTTP layer success rate), neglecting issues such as business processing failures and performance degradation that also impact user experience. By simultaneously analyzing anomaly indicators at the network, business, and performance layers, this system can more comprehensively and accurately assess service health, identify potential problems early, and prevent system-level failures.

[0044] In practical applications, different weights and thresholds are assigned to different types of anomalies to reflect their varying degrees of impact on service availability. For example, an HTTP 500 error might be considered a serious anomaly and given a higher weight, while a response time slightly exceeding a threshold might be considered a minor anomaly and given a lower weight. This differentiated evaluation approach allows the system to more accurately determine the overall health of the service and avoid unnecessary service switching due to occasional minor anomalies.

[0045] In this embodiment, the simultaneous construction of a service configuration library containing operator service configuration parameters includes: The key-value storage structure stores the provider's basic information, circuit breaker policy parameters, performance monitoring indicators, automated management identifiers, and detection configurations.

[0046] Implement the data synchronization interface between the service configuration library and the service call log recording system to obtain the service configuration library.

[0047] Specifically, key-value pair storage is a fundamental and efficient data organization method that represents each piece of data as a mapping between a unique key and a corresponding value. This structure is characterized by high query efficiency and flexible expansion, making it ideal for storing and retrieving configuration data. In a service configuration repository, keys typically employ a multi-level namespace design, such as "service provider ID.configuration category.specific parameter name," ensuring that each configuration item has a clear and unique identifier. The value portion, depending on the parameter type, may be a simple scalar (such as an integer or string) or complex structured data (such as a JSON object or an XML document). The advantages of the key-value pair model lie in its support for high-concurrency reads, atomic update operations, and flexible data schema evolution, adapting to the practical needs of frequent configuration changes.

[0048] Service provider basic information is a core set of metadata about the operator's service providers, containing several key attributes. First, there is identification information, such as a unique service provider ID, official name, and internal code, used for accurate referencing and identification within the system. Second, there is contact information, including technical support email, emergency contact number, and service desk URL, facilitating rapid communication in case of service outages. Third, there is contract information, recording key terms of the Service Level Agreement (SLA), such as guaranteed availability, maximum response time, and billing methods. Finally, there is a service capability description, defining the scope of business functions, geographical coverage, and special features supported by the service provider. This information collectively constitutes the foundational knowledge base for the system to understand and manage various service providers, supporting full lifecycle management from configuration to operation and maintenance.

[0049] Circuit breaker policy parameters define the specific rules by which the system judges the health status of services and triggers circuit breaker protection. Error threshold parameters specify the error rate or absolute number of errors required to trigger circuit breaker, such as "error rate exceeding 20% ​​in 50 consecutive requests"; time window parameters determine the time range for statistical error counting, such as "within the last 60 seconds" or "300 sliding window requests"; cooldown parameters define the minimum time a service needs to remain in a circuit breaker state, such as "maintain at least 30 seconds after circuit breaker before attempting recovery"; recovery policy parameters describe the method for gradually recovering from a circuit breaker state, such as "allow 10% of requests to pass first, and fully reopen after the success rate reaches the target." Advanced circuit breaker configurations may also include error type weights (distinguishing the severity of different errors) and context-sensitive rules (applying different circuit breaker standards in different business scenarios). These parameters together constitute the precise control center of the system's self-protection mechanism.

[0050] Performance monitoring metrics serve as the quantitative basis for system evaluation of service health and routing decisions, typically encompassing multiple dimensions of measurement standards. Response time metrics record the time performance of a service in processing requests, including statistics such as averages, quantiles (e.g., P95, P99), and maximum values; success rate metrics quantify the reliability of request processing, distinguishing between different types of failures (e.g., timeouts, rejections, and error returns); throughput metrics measure a service's processing capacity, such as requests per second (RPS) or transactions per minute (TPM); resource utilization metrics reflect the usage of underlying service resources, such as CPU usage, memory consumption, and network bandwidth. Each metric is usually configured with multiple threshold levels to differentiate between normal, warning, and critical states. The system dynamically adjusts its service usage strategy based on these thresholds, achieving fine-grained traffic management.

[0051] Automation management identifiers are a set of switches and parameters that control the automatic operation of the system, defining the range of actions the system can take without human intervention. For example, the circuit breaker automation identifier ("auto_circuit_break: true") indicates that the system can automatically trigger circuit breakers or recovery; the routing adjustment automation identifier ("auto_traffic_shift: true") indicates that the system can automatically change traffic allocation; the alarm escalation automation identifier ("auto_alert_escalation: false") indicates that the system can automatically escalate alarm levels based on conditions, requiring manual confirmation for escalation; and the self-healing attempt identifier configures the system to proactively perform recovery operations, allowing the system to automatically attempt recovery measures three times after a failure ("auto_recovery_attempts: 3"). These identifiers, combined with access control mechanisms, ensure that the system's automated behavior has sufficient flexibility to handle common situations while also having necessary limitations to prevent risks caused by excessive autonomy.

[0052] The probe configuration defines the methods and parameters for the system to proactively check the health status of services. The probe endpoint configuration specifies the specific URL or interface used for health checks, such as " / health" or " / api / status"; the probe method configuration specifies the HTTP method used (e.g., GET, POST) and the request body content; the probe frequency configuration sets the check interval, such as "every 30 seconds"; the probe timeout configuration limits the maximum time to wait for a response, such as "2-second timeout is considered a failure"; the success condition configuration specifies the criteria for determining a successful probe, such as "HTTP status code 200 and response time less than 500 milliseconds"; and the authentication configuration provides the credentials required to access probe endpoints that require authentication. Advanced probe configurations may also include probe proxy settings (initiating probes from different network locations) and content verification rules (checking whether the response content meets expectations). These configurations collectively ensure that the system can accurately perceive the true availability status of services.

[0053] The data synchronization interface serves as a bridge connecting the service configuration repository and the service call log system, enabling bidirectional flow of configuration and runtime data. Outbound synchronization (from the configuration repository to the log system) ensures that each service call retrieves the latest configuration parameters, typically using a publish-subscribe pattern, automatically notifying relevant components when configuration changes occur. Inbound synchronization (from the log system to the configuration repository) feeds back performance data collected at runtime to configuration management, supporting data-driven optimization of configuration. The interface design follows several key principles: consistency guarantees use transactions or version control mechanisms to ensure the atomicity of configuration updates; change notifications enable real-time or near real-time configuration pushes, reducing configuration latency; conflict resolution uses clearly defined priority rules to handle simultaneous updates; and security controls restrict configuration modification permissions and record all change history.

[0054] Synchronization mechanisms typically employ a combination of technologies. Push mode uses WebHooks or message queues to proactively notify subscribers of configuration changes; polling mode allows the service to periodically check configuration versions and fetch the new configuration when changes are detected; incremental synchronization only transmits changed configuration items, reducing network load; and batch synchronization performs a complete configuration synchronization at specific points in time to ensure consistency. High availability design includes retries for synchronization failures, temporary caching, and degradation strategies to ensure reliable configuration synchronization even under unstable network conditions.

[0055] The actual implementation of the service configuration repository may be based on a dedicated configuration management system (such as Consul, etcd, or Apollo), providing enterprise-level features such as distributed consistency, version control, change auditing, and access control. For small deployments, a lightweight configuration store may be built using a relational database or document database. Regardless of the technology stack used, the configuration repository should provide standardized access APIs to support programmatic configuration reading, writing, and querying, facilitating integration with various system components and operational tools.

[0056] By building such a structured and synchronized service configuration repository, centralized management and distributed application of configurations can be achieved, ensuring that all components work collaboratively under consistent configurations. Configuration changes can be propagated rapidly, and runtime data can feed back into configuration optimization, forming a closed-loop configuration management ecosystem. This design not only improves the maintainability and observability of the system but also provides a flexible basis for dynamically adjusting operator service strategies, serving as a key support for the efficient operation of the entire service routing decision system.

[0057] In this embodiment, the step of obtaining the most recent N call records of the target operator's service using a sliding window statistical model based on historical call data in the service call log recording system and the health check sample size in the service configuration library includes: Based on a distributed task scheduling framework, a distributed lock is used to ensure that the detection task is executed in a single instance in a cluster environment, and a health check task is automatically triggered every minute.

[0058] For each operator service marked as allowing automatic management in the service configuration library, the most recent N call records are obtained from the service call log system in reverse order of the call timestamp, where N is equal to the health check sample size in the service configuration library. A dynamic sliding window is constructed to obtain the most recent N call records. The most recent N call records include HTTP response status code, business response status code, and response time field.

[0059] Specifically, a distributed task scheduling framework is a software infrastructure specifically designed to coordinate task execution in a distributed system environment. It can automatically allocate and execute tasks according to predefined scheduling policies in a multi-server, multi-instance cluster environment. These frameworks typically provide time-driven (such as Cron expressions) and event-driven scheduling mechanisms, supporting advanced features such as task priority, dependencies, and resource constraints. In health monitoring systems, the distributed task scheduling framework is responsible for triggering the monitoring process on time, ensuring that health monitoring tasks can be reliably executed even if some nodes fail. Well-known open-source implementations include Quartz, XXL-Job, and Apache Airflow, which provide rich scheduling policies, monitoring interfaces, and fault recovery mechanisms.

[0060] Distributed locks are a mechanism for solving concurrency control problems in distributed systems, used to coordinate access to shared resources among multiple processes or service instances. In health check scenarios, distributed locks ensure that only one service instance executes the check task at a time, avoiding resource waste and data inconsistency caused by duplicate execution. Distributed lock implementations are typically based on three technologies: database-based locks utilize the transaction characteristics and unique constraints of databases, such as row-level locks or unique indexes; cache-based locks use atomic operations (such as the SETNX command) in Redis or Memcached to create lock keys with expiration times; and coordination service-based locks rely on the ephemeral node mechanisms of distributed coordination systems such as ZooKeeper or etcd. Regardless of the technology used, robust distributed lock implementations need to consider key characteristics such as automatic lock release (preventing deadlocks), reentrancy, and high availability.

[0061] Single-instance execution refers to a mechanism in a distributed environment that ensures a task is executed by only one service instance at any given time. There are several key reasons why health check tasks adopt single-instance execution: First, it avoids increased system load and resource waste caused by duplicate checks; second, it ensures consistency in health status assessments, preventing conflicting conclusions from different instances; and finally, it simplifies result processing, eliminating the need to merge check results from multiple instances. Implementing single-instance execution typically involves three steps: acquiring the lock, executing the task, and releasing the lock, coupled with a lock timeout mechanism to ensure that even if the execution instance crashes, the system can resume normal scheduling within a reasonable timeframe.

[0062] Service call logging systems are dedicated data warehouses for storing and managing details of inter-service calls, recording complete context information for each call. These systems typically employ high-performance, high-capacity storage architectures capable of handling high-concurrency writes and complex queries. In health monitoring scenarios, logging systems store all historical call data for operator services, including request parameters, response results, performance metrics, and error messages. The system architecture typically includes a data collection layer (such as a log broker or SDK), a data transmission layer (such as a message queue), and a data storage layer (such as a distributed database or search engine). Advanced implementations also provide features such as data compression, sharding, indexing, and lifecycle management to balance storage costs and query performance.

[0063] The sliding window statistical model is a dynamic data analysis method that focuses on data from the most recent N samples or within a specific time window. As new data arrives, the window slides forward continuously, maintaining a fixed sample size. Compared to statistics over fixed time periods, the sliding window can more sensitively reflect changes in system status, making it particularly suitable for scenarios requiring timely responses, such as health monitoring. The core characteristics of the sliding window statistical model include: the window size defines the number of samples included in the statistics, directly affecting sensitivity and stability; the sliding strategy determines how the window moves, which can be one sample at a time (sample-level sliding) or a group of samples (batch sliding); and weight allocation can assign different weights to samples at different positions within the window, such as exponential decay weighting, giving more recent data a greater impact.

[0064] The health check sample size is a parameter defined in the service configuration library, specifying the number of recent service calls to be considered when performing a health status assessment. Setting the sample size requires balancing two considerations: a larger sample size provides more stable statistical results, reducing false positives from occasional anomalies, and is suitable for services with high volatility; a smaller sample size reflects service status changes more quickly, improving the system's response speed to sudden problems, and is suitable for scenarios with high real-time requirements. In actual configurations, services of different importance levels may have different sample sizes. For example, critical services may use a sample size of 50-100 to ensure accuracy, while non-critical services may use a smaller sample size of 20-30 to improve detection sensitivity.

[0065] A dynamic sliding window is a data analysis window that automatically adjusts based on the actual call frequency. Unlike a fixed-time window, a dynamic sliding window is defined based on the number of events (N calls in this example) rather than the duration of the event. This design is better suited to scenarios with unstable call frequencies. For services with high-frequency calls, the window may only cover a few minutes of data; while for services with low-frequency calls, the window may span several hours or even longer, ensuring that enough samples are collected for analysis. The window construction process includes three steps: determining the sample size N, querying the most recent N records, and sorting by timestamp. The resulting window dataset contains sufficient statistical significance and reflects the latest state of the service.

[0066] HTTP response status codes are standardized indicators of the results of web service calls, conforming to the HTTP protocol specifications. These status codes are divided into five categories: 1xx (informative responses), 2xx (successful responses, such as 200 OK), 3xx (redirection), 4xx (client errors, such as 404 Not Found), and 5xx (server errors, such as 503 Service Unavailable). In health checks, status codes are the primary basis for determining whether a call was successful. Generally, 2xx status codes are considered successful, while 4xx and 5xx are considered different types of failures. The system assigns different weights to different status codes according to configured rules; for example, 5xx errors may be considered more serious health problems than 4xx errors.

[0067] Business response status codes are application-level defined result identifiers, complementing HTTP status codes and providing more granular information about the call result. Unlike HTTP status codes, business status codes are defined by each service and are typically included in specific fields (such as code or status) in the response body. In health checks, business status codes help the system distinguish between technical successes and business failures, such as an HTTP 200 response but a business return indicating "insufficient balance." The health check system identifies business status codes (such as 0 or SUCCESS) indicating success and error codes indicating various failures based on service configuration, comprehensively assessing the service's health status.

[0068] Response time is the time elapsed from sending a request to receiving a complete response; it is a direct indicator of service performance. In health checks, response time is typically compared to preset thresholds to determine if the service meets performance requirements. Systems may define multiple threshold levels, such as a normal threshold (e.g., within 200ms) and a degradation threshold (e.g., within 500ms), and categorize statistics based on actual response time. Response time analysis also considers statistical distribution characteristics, such as the mean, median, and percentiles (especially P95 and P99), to comprehensively assess service performance stability. Some advanced implementations also incorporate historical data to build baseline models, detecting abnormal fluctuations in response time and identifying potential problems even within threshold ranges.

[0069] Through this historical call data collection mechanism based on distributed technology and statistical models, the system can efficiently obtain the latest call status of operator services, providing a reliable data foundation for subsequent health status assessment and ensuring that routing decisions are based on accurate service health perception.

[0070] In this embodiment, the anomaly identification and performance analysis of the most recent N call records includes: For each call record in the most recent N call records, identify records with HTTP response status codes of 4xx or 5xx and mark them as network layer abnormal records.

[0071] Based on the HTTP response status codes and business response status codes stored in the service call log system, records with an HTTP response status code of 200 but a business response status code indicating failure are identified and marked as business layer exception records.

[0072] Based on the response time stored in the service call log system, the average, median, and quantile values ​​of the response time of the most recent N call records are calculated. Records whose response time exceeds the upper limit of the average response time or the quantile time warning threshold in the service configuration library are marked as performance layer abnormal records.

[0073] Anomaly identification results are obtained based on the network layer anomaly records, the service layer anomaly records, and the performance layer anomaly records.

[0074] Based on the anomaly identification results, the overall failure rate and the performance anomaly ratio are calculated to obtain the performance analysis results.

[0075] Specifically, network layer anomaly identification is a fundamental step in assessing the reliability of service communication, primarily achieved through analyzing HTTP protocol layer response status codes. HTTP response status codes are standardized numerical representations of web service request processing results, with the 4xx series indicating client-side errors and the 5xx series indicating server-side errors. Common 4xx errors include 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), and 404 (Resource Not Found), which typically indicate a problem with the request itself. 5xx errors include 500 (Internal Server Error), 502 (Gateway Error), 503 (Service Unavailable), and 504 (Gateway Timeout), directly reflecting server-side failure states. During anomaly identification, the system iterates through the most recent N call records, checking the HTTP status code of each record and marking all calls returning 4xx or 5xx as network layer anomalies. These anomalies usually reflect issues with the service's basic reachability and processing capacity, serving as the most direct basis for determining whether the service is in a faulty state.

[0076] Business layer anomaly identification focuses on cases where HTTP requests succeed but application logic fails, issues often overlooked in network layer detection. Business response status codes are service-defined result identifiers, typically contained in specific fields of the HTTP response body, used to fine-tune the business processing result. Unlike standardized HTTP status codes, business status codes vary by service and may be numeric codes (e.g., 0 for success, other values ​​for various errors) or string identifiers (e.g., "SUCCESS" or "ERROR"). The system identifies calls with an HTTP status of 200 (successful request) but a business status indicating failure, based on predefined business status code mapping rules in the service configuration library. This identification mechanism can capture business logic anomalies such as "payment failure," "account freeze," or "parameter validation error." While these anomalies do not cause HTTP-level errors, they still affect normal service usage. Business layer anomaly identification compensates for the limitations of relying solely on HTTP status codes, providing a health status assessment perspective closer to user experience.

[0077] Performance anomaly identification focuses on service response speed and stability, crucial indicators of user experience and system efficiency. Response time is the time interval from when a client initiates a request to when it receives a complete response, encompassing network transmission, service processing, and the return of the result. In performance analysis, the system first calculates a set of key statistics: the average reflects the overall response level but is susceptible to extreme values; the median (P50) indicates that half of the requests take less time than this value, better reflecting a typical user experience; quantiles (such as P95 and P99) reflect slower requests, with P95 indicating that 95% of requests take less time than this value, serving as an important indicator of performance stability. The system compares these statistics with preset thresholds in the service configuration library, such as the average response time cap and quantile time warning thresholds. Any call record exceeding the threshold is marked as a performance anomaly. This multi-dimensional performance anomaly identification can capture issues such as slow service processing, insufficient resources, or concurrency bottlenecks, which, even if they do not cause request failures, can severely impact user experience and system throughput.

[0078] The anomaly identification result is a comprehensive set of the three layers of anomaly tags mentioned above, containing complete anomaly information for each call record. The results are typically stored in structured data format. Each record, in addition to the original call information, includes three anomaly tag fields: network layer, business layer, and performance layer, with values ​​of Boolean type or anomaly code. This hierarchical tagging allows the system to perform fine-grained classification and statistics of anomalies, such as distinguishing between pure network failures, pure business logic errors, or complex problems involving multiple anomalies. The anomaly identification result also often includes timestamp information, facilitating the analysis of the temporal distribution characteristics of anomalies, such as whether they occur in clusters or exhibit periodic patterns. Complete anomaly identification results not only directly support health status assessment but also provide a rich data foundation for subsequent root cause analysis and trend prediction.

[0079] The overall failure rate is a core metric for measuring the overall reliability of a service, calculated as the proportion of abnormal calls to total calls. During the calculation, the system first determines which types of exceptions are considered "failures." Typically, network layer and business layer exceptions are included in the failure statistics, while performance layer exceptions may be selectively included based on configuration. The calculation formula is the number of failed calls divided by the total number of calls, and the result is usually expressed as a percentage. The overall failure rate may have multiple threshold levels, such as 5% as a warning threshold, 15% as a severe warning threshold, and 30% as a circuit breaker trigger threshold. Compared to a simple HTTP error rate, the overall failure rate considers multiple layers of exceptions, providing a more comprehensive assessment of service health. In advanced implementations, different types of failures may be assigned different weights; for example, network layer errors may be considered more severe than business layer errors, thus constructing a weighted failure rate to further improve the accuracy of the assessment.

[0080] The performance anomaly ratio is a health metric specifically targeting service response speed, calculating the proportion of calls exceeding a performance threshold out of the total. Unlike the overall failure rate, which focuses on call success or failure, the performance anomaly ratio focuses on service efficiency and user experience. In its calculation, the system uses the results of the aforementioned performance layer anomaly identification to calculate the proportion of records marked as performance anomalies out of the total number of records. The performance anomaly ratio often has multiple threshold levels, such as 10% as a performance degradation warning, 25% as a significant performance problem, and 50% as a severe performance crisis. This metric is particularly suitable for detecting services that haven't completely failed but have noticeably slowed down. Such performance degradation issues, if not addressed promptly, may evolve into complete failure as the load increases. In practical applications, the performance anomaly ratio is often considered in conjunction with absolute response time. A high-performance service may have stricter anomaly criteria, while a non-critical service that is inherently slower may use more lenient criteria.

[0081] Performance analysis results present a unified picture of multiple metrics, including overall failure rate and the proportion of performance anomalies. They typically include raw values, year-over-year changes, and threshold comparisons. The analysis results may use a scorecard format, mapping each metric to a unified scoring system (e.g., 0-100 points) to facilitate a comprehensive understanding of the service status. The results often include trend information, such as changes in metrics over recent monitoring periods, helping to identify situations of gradual deterioration or improvement. In advanced implementations, performance analysis results may be labeled with anomaly pattern recognition outputs, such as "sudden performance degradation," "increased stable error rate," or "intermittent failures," providing directional guidance for subsequent handling. These comprehensive performance analysis results are ultimately used for health status assessment and routing decisions, influencing the system's usage strategy for the service.

[0082] Through this multi-layered, multi-dimensional anomaly identification and performance analysis process, the system can comprehensively assess the health status of operator services, not only capturing obvious fault conditions but also identifying potential performance issues and progressive degradation. This detailed health status profile provides a reliable basis for subsequent intelligent routing decisions, helping the system maximize service quality and user experience while ensuring business continuity.

[0083] In this embodiment, the steps of generating a comprehensive health score, executing a circuit breaker decision based on the comprehensive health score and the abnormal circuit breaker threshold in the service configuration library, and outputting the operator service health status include: Based on the most recent N call records, the response time in the service call log recording system is extracted and standardized to obtain a standardized response time value; the HTTP response status code is extracted and numerically mapped; the business response status code is extracted and semantically encoded; the call timestamp is extracted to calculate periodic features; the sliding statistics of historical failure rate are calculated based on historical call records; and the time interval features are calculated based on the call timestamps of adjacent call records to construct a multi-dimensional feature vector.

[0084] The Kolmogorov-Arnold transform is applied to the multidimensional eigenvectors to perform a projective transformation. A projective matrix is ​​constructed using orthogonal basis functions, and the multidimensional eigenvectors are projected onto a low-dimensional representation space to obtain projective eigenvectors.

[0085] Based on the projective feature vectors of historical normal call records in the service call log system, the probability distribution of each region in the feature space is calculated to obtain the entropy distribution benchmark of the normal mode; based on the projective feature vectors in the current sliding window, the probability distribution of the current feature space is calculated to obtain the current entropy distribution; the relative entropy between the current entropy distribution and the entropy distribution benchmark of the normal mode is calculated, and when the relative entropy exceeds a preset entropy threshold, it is marked as an entropy-driven anomaly.

[0086] Based on the projective feature vector, a function mapping relationship of operator service behavior is constructed. The gradient change of service quality indicators is calculated through automatic differentiation technology to identify key factors leading to service anomalies and their corresponding weights. Combining the network layer anomaly records, the service layer anomaly records, the performance layer anomaly records, and the entropy-driven anomalies, the anomaly detection results are mapped to a unified health score space. The complexity index of service behavior is calculated using Kolmogorov complexity theory to obtain the comprehensive health score.

[0087] The overall health score is compared with the abnormal circuit breaker threshold in the service configuration library. When the overall health score is lower than the abnormal circuit breaker threshold and the "Allow automatic circuit breaker" flag in the service configuration library is true, the operator service health status is set to circuit breaker status. When the overall health score is higher than the abnormal circuit breaker threshold, the operator service health status is set to healthy status, and the operator service health status is output.

[0088] Specifically, the first step is to construct a multi-dimensional feature vector, which forms the basis for subsequent analysis. A feature vector is a multi-dimensional data structure describing the operational status of a service, with each dimension representing a specific observation metric or derived feature. By extracting and combining multiple features, the system can comprehensively capture the service's operational patterns and abnormal behaviors. In this embodiment, the system extracted six key features from the most recent N call records.

[0089] Standardized response time values ​​are the results of standardizing the original response time data. Standardization is a statistical technique used to eliminate the influence between different units of measurement, making the data comparable. Common standardization methods include Z-score standardization (subtracting the mean and dividing by the standard deviation) and min-max normalization (mapping the data to the [0,1] interval). In service monitoring scenarios, response times often exhibit a long-tailed distribution. The system may use a logarithmic transformation followed by standardization to better handle extreme values. For example, if the original response times are 50ms, 150ms, and 450ms, after logarithmic transformation (base 10) and min-max normalization, the standardized values ​​may be 0, 0.48, and 1. This processing allows response times of different magnitudes to be compared on the same scale, avoiding the excessive influence of extreme values ​​on subsequent analysis.

[0090] The numerical mapping of HTTP response status codes is the process of transforming discrete status codes into continuous numerical characteristics. Although HTTP status codes are numbers themselves, their semantic meaning does not directly correspond to numerical magnitude. Therefore, a mapping function is usually defined to convert status codes into continuous values ​​representing health levels. For example, 2xx status codes might map to 1 (fully healthy), 3xx to 0.8 (minor problem), 4xx to 0.3 (client error), and 5xx to 0 (server error). This mapping allows status codes to participate in mathematical calculations in a more meaningful way, and the relative "severity" of different status codes can be adjusted according to business needs.

[0091] Semantic encoding of business response status codes is the process of converting string-based or custom-formatted business status codes into numerical characteristics. Unlike HTTP status codes, the format and semantics of business status codes are typically defined by the service provider and may be strings (such as "SUCCESS", "ERROR"), numeric codes (such as "0000", "1001"), or JSON objects. To incorporate these heterogeneous status codes into a unified analysis framework, the system needs to perform semantic encoding, that is, assigning a numerical value based on the semantic meaning of the status code (success, partial success, failure, etc.). This is usually achieved through table lookup: the system maintains a mapping table that defines the semantic values ​​corresponding to various status codes. For example, a status code indicating complete success (such as "SUCCESS", "0000") might be encoded as 1, a status code indicating partial success (such as "PARTIAL_SUCCESS", "0001") as 0.5, and a status code indicating failure (such as "ERROR", "1001") as 0. In some advanced implementations, the system may also use natural language processing techniques to automatically extract the semantics of the status codes, especially for responses that contain detailed error descriptions.

[0092] The periodicity of timestamp calculations is used to capture the temporal regularity of service call patterns. Many services exhibit different performance characteristics at different times, such as weekdays and weekends, day and night, and the beginning and end of the month. These periodic patterns are crucial for anomaly detection because some behaviors that appear abnormal in absolute values ​​may be normal at specific times (e.g., a response time longer at 3 AM than during working hours is normal). Systems typically extract multiple periodic features from timestamps, such as hours (0-23), days of the week (0-6), and months and days (1-31), and convert them into cyclic features (e.g., using sine and cosine transforms) to preserve the cyclical nature of time. This transformation ensures that points that are close in time are also close in the feature space; for example, 23:59 and 00:01 should be very close in the feature space, even though their original values ​​differ significantly.

[0093] Historical failure rate sliding statistics are a set of metrics calculated over different time windows. Compared to failure rates over a single time window, sliding statistics provide a more comprehensive reflection of the temporal evolution of failure modes. Systems typically calculate failure rates for multiple time windows, such as the failure rates for the most recent 10, 50, and 100 calls. These statistics from different windows collectively form a "failure rate curve." This multi-window statistical approach allows the system to simultaneously capture both short-term fluctuations and long-term trends, maintaining sensitivity to transient anomalies without overreacting to temporary anomalies. For example, if the failure rate for the most recent 10 calls suddenly increases, but the failure rates for the most recent 50 and 100 calls remain stable, the system may determine that this is a short-term fluctuation rather than a persistent problem.

[0094] The time interval feature is calculated based on the call timestamps of adjacent call records, reflecting the frequency and regularity of service calls. This feature is particularly useful for identifying certain types of anomalies, such as sudden traffic surges (suddenly shorter time intervals) or service interruptions (suddenly longer time intervals). Typically, several statistics are calculated, such as the average interval between adjacent calls, the standard deviation of the interval, and the extreme values ​​(minimum / maximum) of the interval, to comprehensively capture changes in call patterns. In some advanced implementations, the system may also use time series analysis methods (such as autocorrelation functions and power spectral analysis) to further investigate the periodicity and trends of call intervals.

[0095] These six types of features together constitute a multidimensional feature vector describing the service's operational status. Each call record corresponds to a feature vector, and the N most recent call records form an N x m feature matrix (where m is the total number of features). This high-dimensional dataset provides rich information for subsequent analysis, but it also brings the challenge of the "curse of dimensionality"—data sparsity in high-dimensional space makes pattern recognition difficult. To address this issue, the system employs the Kolmogorov-Arnold transform for dimensionality reduction.

[0096] The Kolmogorov-Arnold transform is a powerful projective transformation technique derived from dynamical systems theory and differential geometry. It significantly reduces dimensionality while preserving the core information of the data. Compared to traditional dimensionality reduction methods such as Principal Component Analysis (PCA), the Kolmogorov-Arnold transform handles nonlinear relationships better and preserves multi-scale features, which is particularly valuable for capturing complex service behaviors. The core idea of ​​this transform is to project high-dimensional data onto a low-dimensional representation space using a set of orthogonal basis functions (such as Chebyshev polynomials, wavelet bases, or Fourier bases).

[0097] In practical implementation, the first step in projective transformation is constructing the projective matrix. First, a set of orthogonal basis functions is selected (these functions are mutually orthogonal, forming a complete function space). Then, the inner product of the original features and these basis functions is calculated to form the projective matrix. The choice of basis functions is crucial, determining which patterns will be preserved and which will be discarded. For service monitoring data, basis functions that can effectively capture multi-scale time patterns, such as wavelet basis functions, are typically chosen. Orthogonality ensures that different basis functions capture different aspects of the data, avoiding information redundancy.

[0098] The second step of the projective transformation is to multiply the original eigenvectors by the projective matrix to obtain projective eigenvectors. Essentially, this step maps points in the original high-dimensional space to a new low-dimensional space, where each dimension corresponds to a pattern captured by a basis function. The dimensionality of the projective eigenvectors is typically much smaller than that of the original vectors, but it contains most of the information from the data. This dimensionality reduction not only improves computational efficiency but also helps identify more fundamental patterns, filtering out noise and minor variations.

[0099] Based on projective feature vectors, information entropy theory is further employed for anomaly detection. Information entropy is an indicator that measures the degree of disorder or uncertainty in a system, originating from information theory. In service monitoring, entropy analysis can effectively identify pattern changes in service behavior—normal services typically exhibit relatively stable behavioral patterns (low entropy or predictable entropy distribution), while anomalies often manifest as sudden changes or irregularities in behavior (drastic changes or abnormal distributions of entropy).

[0100] First, an entropy distribution baseline for normal operation needs to be established. This is achieved by analyzing the projective feature vectors of historical normal call records. The system divides the feature space into multiple regions or grids, and then calculates the probability distribution of feature vectors falling into each region, thus obtaining the entropy distribution baseline. This baseline reflects the service's behavior pattern under normal conditions and serves as a reference for subsequent anomaly detection. In practical implementation, region partitioning can employ methods such as equally spaced grids, adaptive grids, or density clustering; the choice of method typically depends on the data's distribution characteristics and dimensionality.

[0101] Next, the entropy distribution within the current sliding window is calculated. This is obtained by performing the same region partitioning and probability calculation on the projective feature vectors of the most recent N call records. The current entropy distribution reflects the service's latest behavioral pattern and may differ from the baseline.

[0102] To quantify this difference, we calculate the relative entropy (also known as KL divergence) between the current entropy distribution and the baseline entropy distribution of the normal pattern. Relative entropy is a metric in information theory that measures the difference between two probability distributions; it measures the amount of additional information required to transform from one distribution to another. The larger the relative entropy, the more significant the difference between the two distributions; zero relative entropy indicates that the two distributions are identical. In service monitoring, high relative entropy typically indicates abnormal changes in service behavior.

[0103] When the relative entropy exceeds a preset entropy threshold, it is marked as an entropy-driven anomaly. This anomaly detection method based on information entropy has a unique advantage: it can capture complex or subtle anomalies that traditional threshold-based methods may miss, such as sudden changes in service behavior, pattern shifts, or irregular fluctuations. For example, even if all individual metrics (such as response time and failure rate) are within the normal range, entropy analysis can still detect them if their combined patterns or interrelationships change abnormally.

[0104] Based on projective feature vectors and various anomaly detection results, a function mapping relationship for service behavior is further constructed to gain a deeper understanding of the factors leading to anomalies and generate a final health score. This step utilizes automatic differentiation, a powerful tool from the field of deep learning capable of efficiently calculating the gradient of complex functions.

[0105] Automatic differentiation technology allows the system to calculate the gradient changes of service quality metrics relative to each input feature. The gradient reflects the degree of influence of changes in input features on the output metric; a positive gradient indicates a positive correlation, a negative gradient indicates a negative correlation, and the absolute value of the gradient represents the strength of the influence. By analyzing these gradients, the system can identify the key factors causing service anomalies and their relative importance (weights). For example, it might discover that an increase in response time is mainly due to a surge in request volume during a specific period, or that an increase in failure rate is highly correlated with a specific type of business operation. This understanding of causality not only contributes to more accurate health assessments but also provides direction for subsequent problem diagnosis and optimization.

[0106] After identifying the key factors and their weights, the various anomalies identified in the previous steps (network layer anomalies, business layer anomalies, performance layer anomalies, and entropy-driven anomalies) are mapped to a unified health score space. This mapping process considers the nature and severity of each anomaly and the system's sensitivity to them, ensuring that the final health score comprehensively reflects the overall health of the service.

[0107] Finally, Kolmogorov complexity theory is used to calculate the complexity index of service behavior, serving as an important component of the health score. Kolmogorov complexity, derived from algorithmic information theory, measures the length of the shortest computer program required to describe an object; it is a deep measure of information content and randomness. In service monitoring, abrupt changes in complexity are often associated with anomalies—whether it's an anomalous increase in complexity (e.g., service behavior becoming more unpredictable) or an anomalous decrease (e.g., the service becoming too monotonous, possibly due to the failure of certain functions).

[0108] Taking all these factors into account, the system generates a final comprehensive health score. This score is typically between 0 and 100, where 100 represents perfect health and 0 represents complete unhealthiness. The score calculation considers not only various explicit anomalies (such as failure rate and response delay), but also changes in behavioral patterns (entropy analysis) and system complexity (Kolmogorov complexity), thus providing a more comprehensive and sensitive health assessment than traditional methods.

[0109] With a comprehensive health score, circuit breaker decisions can be implemented. A circuit breaker is a protective mechanism that temporarily stops sending requests to a service when the system detects a continuous decline in the health of that service, in order to avoid consuming system resources and degrading the user experience. The core of circuit breaker decision-making is to compare the score with a threshold and combine this with configuration policies to make a decision.

[0110] First, the overall health score is compared with the abnormal circuit breaker threshold in the service configuration library. The circuit breaker threshold is a preset value, usually between 40 and 60, representing the minimum health score required to trigger a circuit breaker. Setting this threshold requires balancing two aspects: setting it too high can lead to excessive circuit breaking, potentially interrupting otherwise usable services; setting it too low may fail to promptly block problematic services, resulting in more failed requests and wasted resources. In practical applications, different types of services may have different circuit breaker thresholds set, reflecting differences in their importance and fault tolerance requirements.

[0111] If the overall health score is below the abnormal circuit breaker threshold, the "Allow automatic circuit breaker" flag in the service configuration repository also needs to be checked. This is a boolean configuration item set by the system administrator to specify whether the service is allowed to automatically perform circuit breaker operations. For some critical services, administrators may disable automatic circuit breaker and choose manual intervention to avoid unnecessary interruptions caused by misjudgments. Only when the health score is below the threshold and the "Allow automatic circuit breaker" flag is true will the system set the service health status to circuit breaker state.

[0112] When the overall health score exceeds the abnormal circuit breaker threshold, the service health status will be set to healthy. This indicates that the service is running normally and can receive requests. For services that were previously in a circuit breaker state, this means the circuit breaker will be lifted, and service calls will resume.

[0113] Finally, the system outputs the operator's service health status. This status information will be used by other modules (such as the routing decision module) to guide subsequent service calls and load balancing. The health status typically includes: current status (healthy / circuit-breaker), health score, main anomaly types (such as network errors, service errors, or performance issues), and appropriate actions (such as continued monitoring, increasing capacity, or contacting the service provider). This detailed information is not only used for automated decision-making but also provides valuable diagnostic references for system administrators.

[0114] In practical deployments, circuit breaking also incorporates gradual and recoverable features. Gradualism means that circuit breaking isn't necessarily all-or-nothing; the system may implement partial breaking, such as breaking only a specific percentage of requests or only specific types of operations. Recoverability refers to the automatic recovery mechanism after a circuit breaker is triggered. For example, the system might periodically attempt a small number of requests to test if the service has recovered. If the success rate reaches a certain level, traffic is gradually increased until full recovery. These advanced mechanisms make circuit breaking systems more flexible and intelligent, maximizing service availability while protecting the system.

[0115] Through the detailed health scoring and circuit breaker decision-making mechanisms described above, the service availability assurance system in a multi-carrier environment can intelligently monitor and manage the health status of each service provider, achieving high service availability and business continuity in complex and ever-changing environments. This method, based on advanced mathematical models and information theory, can not only accurately identify traditional anomalies but also capture more subtle changes in service behavior, providing a comprehensive and in-depth health assessment and offering strong assurance for the stable operation of the system.

[0116] The following feasible technical solution is adopted for the specific implementation of the Kolmogorov-Arnold transform. This transform is a projective transform method based on orthogonal basis functions, used to reduce high-dimensional feature vectors to a low-dimensional representation space while preserving the key topological structure of the data. The specific implementation steps are as follows: First, Chebyshev polynomials are selected as orthogonal basis functions, and the first D basis functions are selected (D is usually 8 to 16, adaptively adjusted according to the original feature dimension; the higher the original dimension, the larger the value of D). For each basis function T... i and the j-th dimension feature x j Calculate the projective coefficient c ijThe coefficients are obtained through numerical integration, with the integration interval representing the range of values ​​for that feature in historical data. All projective coefficients form a projective matrix of dimension D×m (where m is the original feature dimension). Multiplying the original feature vector by this projective matrix yields a projective feature vector of dimension D. This dimensionality reduction process reduces computational complexity while preserving the main variation patterns of the data through the properties of orthogonal basis functions.

[0117] Regarding the calculation of entropy distribution, the histogram method is used for probability density estimation. Each dimension of the projective feature vector is divided into B equal-width intervals (B is typically 20 to 50). The frequency of the feature vectors of historical normal call records falling into each interval is counted, and the frequency is divided by the total number of samples to obtain the probability distribution P(b). The information entropy H is calculated as the negative sum of the products of the probabilities of each interval and their natural logarithms. Relative entropy (i.e., KL divergence) is used to measure the difference between the current window distribution Q and the baseline distribution P. It is calculated as the sum of the natural logarithms of Q(b) multiplied by the ratio of Q(b) to P(b) for each interval. When this relative entropy value exceeds a preset threshold (typically 0.5 to 2.0, set according to the service provider's historical fluctuation characteristics; a higher threshold is used for service providers with large fluctuations), it is determined to be an entropy-driven anomaly.

[0118] The application of Kolmogorov complexity theory employs an approximate calculation method based on data compression. Kolmogorov complexity is defined as the shortest computer program length required to describe an object, and in practical applications, it is approximated using a general compression algorithm. Specifically, the service behavior sequence (a string consisting of response time, status codes, etc.) is compressed using the Lempel-Ziv-Welch compression algorithm. The ratio of the compressed length to the original length is the approximate complexity value. A ratio closer to 1 indicates a more complex behavior pattern (higher randomness), while a ratio closer to 0 indicates a simpler behavior pattern (stronger regularity). When establishing the mapping relationship between complexity and health score, samples from normal and abnormal periods in historical data are first collected, and their complexity values ​​are calculated separately. The normal complexity range (e.g., 0.3 to 0.6) and the abnormal complexity range (e.g., greater than 0.8 or less than 0.2) are determined. Then, linear interpolation maps the complexity values ​​to health score components ranging from 0 to 100. This component is weighted and integrated with the scores of the network layer, business layer, performance layer, and entropy-driven anomalies to form the final comprehensive health score. The weight of each component is dynamically adjusted according to the historical prediction accuracy. The weight of components with high accuracy is increased, and the weight of components with low accuracy is decreased.

[0119] In this embodiment, the step of calculating the probability distribution of each region in the feature space based on the projective feature vector of historical normal call records in the service call log recording system to obtain the entropy distribution benchmark of the normal mode further includes: Based on the entropy distribution trend of historical service call data in the service call log system, the preset entropy threshold is dynamically adjusted for operator services with unique identifiers for different service providers to adapt to the service characteristics of different operators, thus obtaining an adaptive entropy threshold for each operator service; wherein, the adaptive entropy threshold is used for subsequent anomaly determination of relative entropy.

[0120] Specifically, the entropy distribution trend refers to the regularity of service call patterns evolving over time, reflecting the dynamic characteristics and inherent complexity of service behavior. In information theory, entropy is a measure of uncertainty or randomness, while the entropy distribution describes the distribution of this uncertainty in different feature spaces. By analyzing how the entropy distribution changes over time, the system can understand the "normal fluctuation range" and "abnormal change patterns" of the service, which is the basis for dynamically adjusting the entropy threshold.

[0121] First, a time-series database of entropy distribution needs to be established. This database records the entropy distribution of each operator's service at different points in time, typically covering a long time span (such as weeks or months) to capture long-term patterns and periodic changes in service behavior. For each operator's service, the entropy distribution is calculated periodically (such as hourly or daily), and the results are stored in the database. Each record contains at least: a unique service provider identifier, a timestamp, an entropy distribution vector (describing the probability of each region in the feature space), and a global entropy value (the overall entropy of the entire distribution).

[0122] Based on this time-series database, the system further analyzes the changing characteristics of entropy distribution. This analysis involves multiple dimensions: short-term fluctuations (such as intraday variations), medium-term trends (such as weekly patterns), and long-term evolution (such as monthly variations). The system employs time-series analysis techniques, such as moving averages, exponential smoothing, seasonal decomposition, and trend detection, to quantify these changing characteristics. For example, the system might discover that a telecom operator's SMS service exhibits significantly different entropy distribution patterns on weekdays and weekends, or that a payment service shows significant differences in entropy values ​​at the beginning and end of the month. These findings provide important basis for subsequent threshold adjustments.

[0123] Entropy distribution trend analysis also includes the study of anomalous events. Known anomalous events in historical data (such as service outages, performance degradation, etc.) are flagged, and the patterns of entropy distribution changes before and after these events are analyzed. This analysis helps identify "precursor patterns" or "signature characteristics" of anomalies, improving the accuracy of future anomaly detection. For example, the system may find that before a certain type of failure occurs, the entropy distribution typically exhibits a specific pattern of change, such as a sharp increase or decrease in the probability of certain areas.

[0124] Based on a comprehensive analysis of entropy distribution trends, a "normal behavior model" for entropy distribution was constructed for each operator's service. This model describes the expected range and variation pattern of entropy distribution under various normal conditions, considering time factors (such as different times of day and different days of week) and business factors (such as promotional activities and holidays). The model may take various forms, such as statistical distributions (e.g., Gaussian mixture models), time series models (e.g., ARIMA or LSTM networks), or state-space models. The choice of form typically depends on the complexity of the data and the system's computational resources.

[0125] Next, based on the normal behavior model of entropy distribution, the entropy threshold is dynamically adjusted for each operator's service. Dynamic adjustment is an ongoing process; as new data accumulates and the model is updated periodically, the threshold is adjusted accordingly. This dynamic adjustment ensures that the threshold always reflects the latest behavioral characteristics of the service, adapting to the evolution of the service itself (such as version upgrades and feature expansions) and changes in the external environment (such as changes in user behavior and network conditions).

[0126] There are various methods for dynamically adjusting the entropy threshold, which may involve a combination of multiple techniques: The statistical percentile method is a commonly used threshold setting method based on the statistical distribution of historical data. First, the distribution of historical relative entropy values ​​is calculated, and then a specific percentile (such as 95% or 99%) is selected as the threshold. The advantage of this method is its intuitiveness and ease of understanding—for example, a 99% threshold means that only 1% of historical observations will be flagged as anomalies. Different percentiles may be chosen for different operator services, reflecting differences in their risk tolerance and false alarm tolerance. For example, a higher percentile (such as 99.9%) might be chosen for critical services to reduce false alarms, while a lower percentile (such as 95%) might be chosen for non-critical services to increase sensitivity.

[0127] Time-aware adjustment refers to dynamically adjusting thresholds based on time factors (such as time of day, day of the week, month, etc.). This approach recognizes that service behavior is often time-dependent—for example, the normal entropy distribution of a service may differ significantly between peak and off-peak periods. It maintains separate thresholds for each time period or uses the time factor as input to the threshold calculation function. For example, for a service whose performance differs significantly between working and non-working hours, the system might set a lower entropy threshold during working hours (corresponding to more stable expected behavior) and a higher threshold during non-working hours (allowing for greater fluctuations).

[0128] Context-aware thresholding considers contextual factors beyond time, such as request volume, user type, or operation type. This approach recognizes that service behavior can be influenced by multiple factors, making a single threshold unsuitable for all situations. It analyzes the relationship between these contextual factors and entropy distribution, building a more complex multivariate threshold model. For example, it might find significant differences in entropy distribution for a payment service under high and low load conditions, thus dynamically adjusting the threshold based on the current load level.

[0129] Incremental learning is a method for continuously updating threshold models based on the long-term evolution of service behavior. Over time, services may change for various reasons (such as upgrades, optimizations, or expansions), and their normal entropy distribution will adjust accordingly. Incremental learning ensures that anomaly detection is always based on the latest behavioral characteristics of the service by periodically updating the entropy distribution model and the corresponding threshold calculation function. This learning may employ various machine learning techniques, such as online learning, incremental learning, or transfer learning, effectively integrating new observational data without losing historical knowledge.

[0130] Seasonal adjustments specifically address periodic patterns in service behavior, such as daily, weekly, or monthly cycles. This approach first uses time-series decomposition techniques (such as STL decomposition or wavelet analysis) to identify seasonal components in the service entropy distribution, and then considers these seasonal factors in threshold calculations. For example, if the system detects that the entropy of a certain service is consistently high on Monday mornings (possibly due to routine system maintenance or data synchronization), the entropy threshold will be increased accordingly during this period to avoid false alarms.

[0131] Anomaly pattern reinforcement is a method that improves threshold settings through feedback loops. It records each triggered entropy-driven anomaly and its subsequent confirmation (whether it's a genuine anomaly or a false alarm), and uses this feedback information to adjust the threshold calculation model. This reinforcement learning mechanism allows the system to learn from its own judgment errors, continuously improving the accuracy of anomaly detection. For example, if the system finds that a certain type of entropy distribution change frequently leads to false alarms, it will adjust the threshold calculation method to reduce sensitivity to such changes; conversely, if it finds that a certain type of entropy distribution change usually indicates a real problem, it will increase the sensitivity.

[0132] Multi-objective optimization considers the balance between multiple performance metrics in anomaly detection, such as precision (reducing false positives) and recall (reducing false negatives). It may allow administrators to set different priorities for different services—for example, recall might be prioritized for critical services to ensure that as many anomalies as possible are caught, while precision might be prioritized for non-critical services to reduce interference from false positives. Based on these priorities and historical performance data, an optimal entropy threshold is customized for each service.

[0133] By comprehensively utilizing these technologies, adaptive entropy thresholds were determined for each operator's service. These thresholds are not statically fixed, but rather dynamically adjusted functions over time and context, adapting to the service characteristics and change patterns of different operators. For example, a lower entropy threshold might be set for a service with historically stable performance and minimal fluctuations, making it more sensitive to minor changes; while a higher entropy threshold might be set for a service that is inherently more volatile, to avoid excessive alerts.

[0134] A key characteristic of adaptive entropy thresholds is their "self-regulating" capability. When service behavior undergoes long-term changes (such as service upgrades or architectural adjustments), the threshold gradually adjusts with the accumulation of new data, without manual intervention. This self-regulation ensures the system can operate effectively over the long term, maintaining accurate anomaly detection even in the face of constantly changing service environments.

[0135] These adaptive entropy thresholds are ultimately used for subsequent relative entropy anomaly detection. In each health check, the relative entropy between the current entropy distribution and the baseline of the normal mode entropy distribution is calculated, and then this relative entropy is compared with the corresponding service's adaptive entropy threshold. If the relative entropy exceeds the threshold, it is marked as an entropy-driven anomaly, which serves as an important input for health score calculation and circuit breaker decisions. Because the thresholds are adaptive, taking into account service characteristics and historical patterns, this detection is more accurate and better able to distinguish between genuine anomalies and normal fluctuations.

[0136] In practical deployments, adaptive entropy threshold mechanisms typically also include security mechanisms and manual intervention interfaces. Security mechanisms ensure that the threshold is not adjusted to extreme values, such as setting upper and lower limits to prevent the threshold from being too high (leading to the inability to detect obvious anomalies) or too low (leading to continuous false alarms). Manual intervention interfaces allow administrators to manually adjust the threshold or parameters when necessary, especially when facing new situations or special requirements. These additional mechanisms enhance the system's stability and controllability, enabling it to adapt to special situations and management needs while maintaining automation.

[0137] Through this dynamic threshold adjustment mechanism based on entropy distribution trends, the service availability assurance system in a multi-carrier environment achieves more accurate and personalized anomaly detection. Compared to static fixed thresholds, this adaptive mechanism can better adapt to the differences in characteristics and evolution of different services, significantly improving the accuracy of anomaly detection and the overall reliability of the system. It is this advanced adaptive capability that enables the system to provide the most suitable health monitoring and protection strategies for each service in a complex and ever-changing multi-carrier environment, ultimately achieving high service availability and business continuity.

[0138] In this embodiment, the step of filtering operator services in a circuit breaker state based on the operator service health status and initiating multiple simulated call requests to the operator services in the circuit breaker state includes: Based on the distributed task scheduling framework, a probe task is automatically triggered every five minutes according to the circuit breaker simulation probe frequency in the service configuration library. The operator service health status is used to identify and filter the operator services that are currently in the circuit breaker state, and a list of circuit breaker service providers is obtained.

[0139] For each operator service in the circuit breaker service provider list, standardized simulated request parameters are generated using the request address, interface version, and key information of the corresponding service provider ID in the service configuration library. The probe counter is initialized, the request timeout is configured, and M simulated call requests are initiated based on the number of single probe requests M in the service configuration library.

[0140] Specifically, a distributed task scheduling framework is a software architecture used to coordinate and execute periodic or scheduled tasks in a distributed system. In service monitoring scenarios, the distributed task scheduling framework is responsible for managing and triggering various monitoring tasks, ensuring they are executed at a predetermined frequency and order, and providing retry and failover mechanisms when tasks fail. Compared to simple timers or single-machine scheduling systems, distributed task scheduling frameworks offer higher reliability, scalability, and fault tolerance, and can operate seamlessly in multi-server environments.

[0141] A distributed task scheduling framework typically consists of three core components: a scheduler, an executor, and a storage system. The scheduler is responsible for deciding when to execute tasks and distributing them to available executors; the executor is responsible for actually running the task code and collecting the results; and the storage system stores task definitions, execution history, and state information, providing persistent support for the entire framework. This architecture ensures that the task scheduling system can continue to run even if a node or component fails, avoiding the risks associated with single points of failure.

[0142] In practical implementation, the distributed task scheduling framework also possesses several advanced features: task priority management (ensuring that important tasks are executed first), resource isolation (preventing interference between tasks), monitoring and alerting (timely detection of task anomalies), and dynamic configuration (adjusting task parameters without restarting). These features enable the framework to adapt to complex and ever-changing business needs and maintain stable operation under high load conditions.

[0143] The post-circuit breaker simulation probe frequency is a critical configuration parameter that defines the time interval for performing health probes on the circuit-breaker service. This parameter directly affects the recovery speed of the circuit-breaker service and the consumption of system resources—too high a frequency will increase system overhead and pressure on the target service, while too low a frequency may cause the service to remain in an unnecessary circuit-breaker state even after actual recovery, prolonging the business impact time. In this embodiment, the post-circuit breaker simulation probe frequency is set to once every five minutes, which is a balance between response speed and system overhead.

[0144] The five-minute interval is reasonable: it's short enough to ensure the service won't remain in a circuit breaker state for an extended period after recovery (maximum delay of five minutes); yet long enough not to place an excessive burden on the system and the target service. In actual deployment, this frequency may be adjusted based on specific business needs and service characteristics—critical services may be configured with more frequent probes (e.g., every minute), while non-critical services may be configured with longer intervals (e.g., every ten minutes or longer).

[0145] The automatic triggering of the probe task is achieved through the timed scheduling function of the distributed task scheduling framework. The system registers a periodic task in the framework, setting its execution cycle to five minutes. The task triggering may be based on various time expression formats, such as CRON expressions or similar expressions. Once the scheduled time arrives, the framework automatically starts the task instance and invokes the probe logic to begin execution.

[0146] To ensure the reliable execution of probing tasks, distributed task scheduling frameworks typically implement several safeguards: task locking (preventing the same task from being executed simultaneously by multiple nodes), execution timeout monitoring (detecting and interrupting abnormally long-running tasks), failure retry (automatically retrying failed task execution), and execution history (saving detailed logs of task execution for troubleshooting). These mechanisms work together to ensure that probing tasks can run as expected, maintaining functionality even in the event of partial system failure.

[0147] Once the detection task is triggered, the system first needs to identify the carrier services currently in a circuit breaker state. This is achieved by accessing the carrier service health status data. Health status data is typically stored in a distributed cache or database and includes information such as the current status (healthy, circuit breaker, or other), the time of the last status change, and the current health score for each carrier service. The system iterates through all monitored carrier services, filters out services marked as "circuit breaker," and generates a list of circuit breaker service providers.

[0148] The circuit breaker service provider list is a data structure containing information on all operator services currently under circuit breaker restrictions. Each list item typically includes basic information such as service provider ID, service type, reason for circuit breaker, and circuit breaker duration, as well as configuration parameters required for probing. This list serves as both the input for the probing task and the basis for subsequent decisions to lift the circuit breaker. In practice, the list may be implemented as a priority queue, giving priority to critical services or services with prolonged circuit breaker suspensions.

[0149] Once the list of service providers subject to circuit breaker restrictions is determined, the system generates standardized mock request parameters for each operator's service on the list. These mock request parameters are a set of configuration information used to construct the mock call, including the request address, interface version, authentication credentials, and request data. Standardization means organizing these parameters in a uniform format, allowing different types of services to be probed through the same processing flow. Standardization not only simplifies system design but also improves code reusability and maintainability.

[0150] The request address (URL) is the target location for a service call, typically including the protocol (such as HTTP / HTTPS), domain name or IP address, port number, and path. The request address format may differ between different ISPs. The system needs to retrieve the correct URL template for a specific service from the service configuration repository and replace the variable parts (such as account information, region code, etc.) as needed. In some cases, a service may have multiple available addresses (such as primary / backup addresses or load balancing clusters), and the system will select the appropriate address to probe based on the configuration.

[0151] An API version is a version identifier for a service API and is crucial for ensuring compatibility. As a service evolves, multiple versions of the API may run concurrently, with differences in request formats and processing logic. The system needs to retrieve the currently used API version from the configuration repository and include the corresponding version information when constructing requests, typically as a request header (e.g., "API-Version: v2") or a URL parameter (e.g., " / api / v2 / service"). Using the correct API version can prevent request failures due to version mismatches and ensure the accuracy of the detection results.

[0152] Key information serves as credentials for service authentication and authorization, typically including API keys, access tokens, and account passwords. This information is crucial for secure service access—without the correct key, requests will be rejected by the service provider, leading to probe failure. The system retrieves key information associated with a specific service provider ID from the service configuration repository and includes this information in the format required by the service when constructing requests, such as in request headers, request bodies, or as URL parameters. Given the sensitivity of keys, the system usually encrypts and stores key information during transmission and performs anonymization processing in logs to prevent information leakage.

[0153] In addition to these basic parameters, probe counters will also be initialized. Probe counters are a set of counting variables used to track probe progress and results, typically including: total number of requests, number of successful requests, number of failed requests, number of timeout requests, etc. These counters are not only used to record probe results but also to determine in real time whether the conditions for lifting the circuit breaker have been met. For example, it might be stipulated that "the circuit breaker will only be considered for lifting when the success rate reaches 80% and at least 5 requests are completed," which requires tracking and evaluation through counters.

[0154] Request timeout is another key configuration parameter that defines the maximum time the system waits for a response. If a request does not receive a complete response within this time, it will be marked as timed out and failed. The timeout setting needs to consider both normal service response time and tolerance for abnormal conditions—too short might cause a normal but slightly slow response to be incorrectly marked as failed, while too long might cause probing tasks to be blocked for an extended period on clearly problematic services. In practice, the timeout is typically set to 2-3 times the normal response time; for example, if the normal service response time is 200ms, the timeout might be set to 500ms or 600ms.

[0155] The number of probe requests per session, M, refers to the number of simulated requests initiated against the same service in each probe task. This parameter directly affects the statistical significance of the probe results—the larger the number, the more accurately the results reflect the true state of the service, but it also means greater system resource consumption and pressure on the target service. Determining an appropriate value for M requires a balance between accuracy and efficiency, typically set based on the importance of the service, the desired detection precision, and system resource constraints. For critical services, M may be set higher (e.g., 10 or 20) to ensure accurate decision-making; for non-critical services, M may be lower (e.g., 3 or 5) to reduce resource consumption.

[0156] Based on the above preparations, initiate M simulated service call requests. A simulated service call is a lightweight service call designed to test service availability rather than perform actual business operations. To ensure these requests do not cause unexpected side effects to the target service (such as creating an order or sending an SMS), read-only operations (such as query interfaces) or special health check interfaces are typically chosen as the targets for the simulated calls. If the service does not provide such secure interfaces, the system may add special flags (such as test mode flags) to the requests, enabling the service to recognize and appropriately handle these simulated requests.

[0157] The execution of simulated calls, whether in parallel or serial mode, depends on the system design and the characteristics of the target service. Parallel calls can complete the probing process faster but may introduce sudden loads to the service; serial calls, while slower, distribute the pressure more evenly. In practical implementations, a limited parallel approach may be used—executing multiple requests simultaneously, but controlling the concurrency to not exceed a specific limit (such as 3 or 5) to balance speed and load.

[0158] To ensure the authenticity and validity of probe requests, necessary business parameters are included in the requests. These parameters may come from predefined test datasets or be dynamically generated by a parameter generator according to service rules. For example, for SMS services, the system may use preset test phone numbers and message templates; for payment query services, it may generate random order numbers that meet the format requirements. These parameters should both conform to the service's business rules (to avoid failures due to incorrect parameters) and cover common use cases (to ensure the representativeness of the probe).

[0159] During the execution of simulated calls, the status and result of each request are closely monitored, and the probe counters are updated in real time. For each completed request, the system updates the corresponding counters based on its result (success, network error, business error, timeout, etc.). Simultaneously, the system records detailed request logs, including request time, request parameters, response content, and response time. These logs are not only used for result analysis but also aid in subsequent problem diagnosis and service optimization.

[0160] It's worth noting that the simulated call process also includes exception handling mechanisms to handle various possible error situations. These include network exception handling (such as connection resets and DNS resolution failures), timeout handling (requests failing to respond within a predetermined time), and protocol error handling (such as HTTP 400 / 500 series errors). This exception handling ensures that even if some requests fail, the entire probing task can still continue to execute and collect useful diagnostic information.

[0161] During the simulated call execution, dynamic adjustment strategies may be implemented to optimize subsequent probes based on initial results. For example, if the first few requests fail quickly, the system may extend the interval between subsequent requests or reduce the number of remaining requests to alleviate pressure on services that are clearly still experiencing problems; conversely, if the first few requests succeed, the system may increase the diversity of test scenarios to more comprehensively evaluate the service status. This dynamic adjustment makes the probe process more intelligent and efficient, enabling it to make the most appropriate decisions based on real-time conditions.

[0162] A key design consideration in simulated calls is "probe isolation," which ensures that probe activities do not impact normal business traffic. In implementation, this might manifest as a dedicated probe thread pool (separate from the business thread pool), independent network connection limits, or specific request flags (allowing the server to distinguish between probe and business traffic). This isolation ensures that even if problems arise during probe activities (such as resource exhaustion or deadlocks), the system's ability to process normal business requests will not be affected, guaranteeing business continuity.

[0163] Another key design feature is "progressive probing," especially for services that may still be in the recovery process. The system might first send a small number of requests, and if the success rate is high, gradually increase the number and complexity of the requests. This approach avoids the risk of a newly recovered service crashing again due to a large number of sudden requests, giving the service sufficient time to stabilize and warm up. For example, the system might first send two basic query requests, and if successful, send three more complex requests, before finally performing the full M simulated calls.

[0164] For services with multiple instances or nodes (such as distributed services or regionally deployed services), the system may also implement "wide-area probing," which involves sending requests to different instances or nodes to ensure the overall availability of the service. This wide-area probing is particularly suitable for services that may experience partial regional failures, such as a telecommunications operator experiencing service interruptions in a specific region while other regions remain operational. By sending requests to nodes in different regions, the system can more accurately assess the overall status of the service and may implement more granular circuit breaker strategies (such as suspending service only in a specific region rather than all regions).

[0165] The data collected during simulated calls is not only used for current circuit breaker recovery decisions but also provides valuable information for long-term service quality analysis. This data will be stored in a service quality data warehouse for trend analysis, pattern recognition, and anomaly prediction. For example, by analyzing multiple circuit breaker and recovery patterns, it may be discovered that a certain service frequently experiences brief outages followed by automatic recovery during specific time periods (such as 2 AM every day). This insight can guide the operations team to make targeted optimizations or adjust monitoring strategies.

[0166] Through the detailed circuit breaker status detection mechanism described above, the service availability assurance system in a multi-carrier environment can intelligently and efficiently monitor the recovery status of circuit-broken services, promptly resolve unnecessary circuit breaker states, and maximize service availability and business continuity. This method, based on distributed task scheduling and precise simulated calls, not only considers the efficiency and reliability of technical implementation but also fully takes into account business needs and service characteristics, making it an important component of modern service availability assurance systems.

[0167] In this embodiment, the steps of maintaining a sliding window to record the detection results during the detection process, calculating the failure rate within the sliding window, terminating the remaining detection when the failure rate exceeds a preset termination threshold, and writing the detection results into the service call log recording system include: Based on the historical call data of the operator's services under the circuit breaker status, the call timestamp and response time are extracted to construct a time series feature to obtain a time view; the HTTP response status code and business response status code are extracted to analyze error types and distribution to construct an error view; the request interface type and calling customer account ID are analyzed to construct a dependency view; and the regional performance mode is identified based on the regional attributes in the service provider's basic information to construct a regional view, thus obtaining a multi-dimensional service status view.

[0168] For each view in the multidimensional service state view, a dedicated evolutionary subpopulation is constructed. Within the evolutionary subpopulation, a detection program is generated using a genetic programming method. The detection strategies between subpopulations are exchanged through a knowledge-sharing protocol to obtain a co-evolving set of detection strategies.

[0169] Based on the co-evolutionary detection strategy set, a lightweight, rapid detection is performed to verify the network connectivity and basic response capabilities of the service, yielding rapid detection results. When the rapid detection results indicate that the service is basically available, a medium-level in-depth detection is performed to verify the functional integrity and performance indicators of the service, yielding medium-level detection results. When the medium-level detection results indicate that key functions are normal and performance indicators meet the upper limit of the average response time in the service configuration library, a comprehensive in-depth detection is performed to evaluate the stability and reliability of the service, yielding comprehensive detection results. During the detection process, a sliding window of size K is maintained to record the K most recent detection results, and the failure rate within the sliding window is calculated based on the HTTP response status codes and business response status codes in the detection results.

[0170] By comprehensively analyzing the real-time detection results of the corresponding subpopulations in the time view, error view, dependency view, and regional view, a unified decision to continue or terminate the detection is generated using majority voting or weighted average methods. When the failure rate within the sliding window exceeds the detection termination threshold in the service configuration library, the remaining detection is terminated, and the detection results, including the detection timestamp, service provider unique identifier, HTTP response status code, business response status code, and response time, are written to the service call log recording system.

[0171] Specifically, multidimensional analysis of service status is key to understanding service behavior. Unlike traditional single-metric monitoring, multidimensional analysis observes services from multiple perspectives, capturing their complex operational characteristics and anomaly patterns. The system first needs to extract various features from the historical call data of the circuit breaker service to construct four core views: a time view, an error view, a dependency view, and a geographic view. These views together constitute a panoramic view of the service status, enabling the system to comprehensively assess the health of the service.

[0172] The time view is built based on the time-series characteristics of service calls, reflecting the pattern of service performance changes over time. The system extracts two key elements from historical call data: call timestamps and response timestamps. Call timestamps record the precise time point when each service call occurred, typically accurate to the millisecond level; response timestamps measure the time required from issuing a request to receiving a complete response, and are a direct indicator of service performance.

[0173] By analyzing this time data, various time-related patterns can be identified: periodic patterns (such as daily, weekly, or monthly fluctuations), trend patterns (such as continuously increasing or decreasing response times), and anomalous events (such as sudden performance degradation). For example, the system might find that a certain operator's SMS service generally has longer response times between 2 PM and 4 PM every day, or that it gradually deteriorates within the first three days of the month before returning to normal.

[0174] The construction of time-series views typically employs time series analysis techniques, such as moving averages, exponential smoothing, seasonal decomposition, or wavelet analysis. These techniques extract meaningful patterns from raw data and filter out random noise. A well-constructed time-series view not only displays historical patterns but also helps the system predict future performance changes, providing crucial information for developing detection strategies. For example, if historical data shows that service performance is poor at night, the system may adopt more lenient standards during nighttime detection; if service typically takes some time to fully recover after a failure, the system may extend the detection period accordingly.

[0175] The error view focuses on various errors that occur during service calls, identifying error types, distributions, and patterns by analyzing HTTP response status codes and business response status codes. HTTP response status codes are basic communication-level error indicators, such as 404 (Resource Not Found), 500 (Internal Server Error), or 503 (Service Unavailable). Business response status codes reflect application-level errors, such as "Insufficient Balance," "Invalid Parameter," or "Operation Timed Out." These status codes are typically defined by the service provider and require parsing according to the specific service documentation.

[0176] Building an error view involves several key steps: error classification (categorizing errors by nature into network errors, server errors, client errors, etc.), error frequency analysis (calculating the frequency and time distribution of each type of error), and error correlation analysis (identifying the relationships and chain reactions between different errors). Through these analyses, the system can understand the error patterns of the service. For example, some errors may be intermittent (indicating service instability), some errors may always occur in pairs (indicating dependencies), and some errors may occur frequently under specific conditions (indicating triggering factors).

[0177] Error views are crucial for service recovery assessment because service recovery involves more than just being "responsive"; it also includes being "responsive correctly." By analyzing recent error patterns and comparing them with those before the circuit breaker was triggered, the system can determine whether the service has truly recovered to a healthy state or is merely superficially available while still harboring problems.

[0178] A dependency view is built by analyzing request API types and calling client account IDs, revealing service usage patterns and dependencies. The request API type refers to the specific API endpoint or operation type called, such as "send SMS," "check balance," or "pay order." The calling client account ID identifies the client or system initiating the request, reflecting the degree of dependency different users have on the service.

[0179] The construction of dependency views involves several analyses: interface usage frequency analysis (which interfaces are called frequently and which are used infrequently), customer distribution analysis (which customers are the main users and what are their calling patterns), and interface dependency analysis (the order and relationship of calls between different interfaces). Through these analyses, the system can identify the core functions of the service and key users, as well as the complex dependency network between them.

[0180] Dependency views are crucial for developing probing strategies. They help the system identify which interfaces are core functionalities that must be tested and which user scenarios are critical processes that must be covered. For example, if analysis shows that the "payment confirmation" interface is the most critical operation, the system will prioritize testing this interface; if a large customer's call pattern is found to be particularly unique, the system may design test cases specifically for this pattern.

[0181] A geographic view is built upon the geographic attributes in the service provider's basic information, reflecting the performance differences of the service in different geographical locations. Geographic attributes may include information such as the server's location, network access point location, or service coverage area. This information typically comes from the service configuration repository or basic profiles provided by the operator.

[0182] The construction of the regional view includes cross-regional performance comparison (comparison of response time and success rate across different regions), regional failure mode analysis (error types and frequencies in specific regions), and regional time correlation analysis (patterns of regional performance changes over time). Through these analyses, the system can identify regional performance patterns. For example, a certain operator's service in South China may generally be faster but unstable, while in Northwest China it may be slower but more reliable.

[0183] Geographic views are particularly important for large-scale distributed systems because many service failures are geographically specific—they may only affect users in a particular region, while other regions continue to operate normally. With a geographic view, the system can distinguish between global and local failures and adopt appropriate detection and recovery strategies for different situations. For example, if a failure is found to be limited to a specific region, the detection density in that region may be increased, while allowing services in other regions to continue operating.

[0184] These four views together constitute a multi-dimensional service status view, providing a comprehensive information foundation for the formulation and execution of subsequent probing strategies. The advantage of a multi-dimensional view lies in its ability to capture the complexity and diversity of service status, avoiding the one-sided judgments that may result from single-dimensional analysis. For example, looking only at response time might indicate that the service has recovered, but the error view might reveal that there are still a high proportion of business errors; or overall performance might seem normal, but the geographic view might show that users in certain regions are completely unable to access the service.

[0185] Based on a multidimensional service state view, a dedicated evolutionary subpopulation was further constructed to design the most suitable detection strategy for each view. The evolutionary subpopulation is an optimization method based on genetic algorithms. It improves the solution step by step until it reaches the optimal or near-optimal state by simulating natural selection and genetic mechanisms. In the service detection scenario, each subpopulation is responsible for generating the optimal detection program for a specific view (time, error, dependency, or region).

[0186] Genetic programming is an extension of genetic algorithms that not only optimizes parameters but also generates complete programs or strategies. In traditional genetic algorithms, the algorithm searches for optimal parameters for a fixed-structure problem; while in genetic programming, the algorithm searches for programs or decision trees with variable structures. This flexibility makes genetic programming particularly suitable for generating complex probing strategies, as these strategies typically require different operations based on different conditions and are difficult to represent with simple parameters.

[0187] The genetic programming method for generating probe programs involves several key steps: initialization (randomly generating an initial set of probe programs), evaluation (testing the effectiveness of each program, such as detection accuracy and resource consumption), selection (retaining programs with better performance), crossover (combining the best parts of different programs), and mutation (randomly modifying some programs to increase diversity). Through multiple generations of iteration, the system gradually improves the quality of the probe programs, ultimately forming an efficient and accurate detection strategy.

[0188] For example, the evolutionary subpopulation of the time view may generate probes that focus on performance changes over different time periods, such as increasing the probe frequency during historical peak periods; the subpopulation of the error view may generate probes that target common error patterns, such as paying special attention to error types that occur frequently before circuit breakers; the subpopulation of the dependency view may generate test cases that cover core interfaces and key user scenarios; and the subpopulation of the geographic view may generate probe tasks distributed across different geographical locations, with a focus on areas with historical problems.

[0189] Knowledge-sharing protocols are mechanisms for exchanging detection strategies among subpopulations, allowing evolutionary subpopulations from different views to learn from and draw upon each other. The core idea behind this protocol is that while each view focuses on different aspects, there are potential connections and complementarities between them—patterns discovered by a temporal view may inspire flawed views, and discoveries from a geographical view may provide guidance for dependent views. Through knowledge sharing, the system can integrate the strengths of each view to generate more comprehensive and powerful detection strategies.

[0190] Knowledge sharing is typically achieved through several methods: best-individual migration (copying the best-performing probes from one subpopulation to other subpopulations), policy fragment exchange (sharing effective policy components between subpopulations), and metadata sharing (exchanging high-level knowledge about service characteristics, such as sensitive parameters or critical time points). This exchange is not a simple copy but needs to be adapted to the characteristics and needs of the target subpopulation. For example, a "performance degradation at 2 PM every day" pattern found in the time view might translate into a strategy of "focusing on detecting specific types of errors around 2 PM" in the error view.

[0191] Through evolution within subpopulations and knowledge sharing among subpopulations, the system ultimately forms a co-evolving set of detection strategies. This set is not a simple accumulation of strategies, but an organic whole in which different strategies cooperate and complement each other, jointly forming a comprehensive and accurate service detection framework. Co-evolution ensures that detection strategies not only perform well in their respective domains, but also work collaboratively as a whole, avoiding the limitations that may arise from a single perspective.

[0192] Based on a co-evolutionary detection strategy set, a three-stage detection process was implemented, progressing from lightweight, rapid detection to comprehensive, in-depth detection. This progressive detection approach can quickly filter out services that are clearly still problematic (avoiding unnecessary in-depth testing) while comprehensively evaluating those services that initially appear normal (ensuring true health).

[0193] Lightweight, rapid probing is the first phase, primarily verifying the service's network connectivity and basic responsiveness. This phase of probing is simple and quick, typically including only basic connectivity tests (such as whether a TCP connection is successful) and simple requests (such as HTTP HEAD requests or simple GET requests). The purpose of probing is to quickly confirm whether the service is "online" and capable of receiving and responding to requests, rather than to conduct a detailed evaluation of functionality or performance.

[0194] Lightweight probes are characterized by low overhead, fast execution, and minimal impact. Each probe consumes very few resources, typically completing within a few hundred milliseconds, with negligible impact on service load. This allows the system to perform these probes frequently (e.g., multiple times per minute) without worrying about stressing the service. If a lightweight probe fails, the system can quickly confirm that the service has not yet recovered, avoiding wasting resources on more in-depth testing; if successful, it proceeds to the next stage.

[0195] The second phase, moderate-to-deep probing, verifies the service's functional integrity and performance metrics. This phase is more complex, including testing multiple key functions (such as calls to commonly used APIs) and basic performance testing (such as response time measurement). The goal of the probing is to confirm that the service not only responds but also correctly executes core business functions and meets basic performance requirements.

[0196] Medium-level probing involves performing several representative business operations, typically core interfaces and key processes identified from the dependency view. For example, for the payment service, core functions such as "balance inquiry," "payment request," and "transaction inquiry" might be tested; for the SMS service, basic operations such as "sending SMS" and "checking delivery status" might be tested. The system verifies the correctness of these operations' responses (business status codes meet expectations) and performance metrics (response time does not exceed the configured average response time limit).

[0197] The average response time cap is a performance threshold defined in the service configuration library. It represents the maximum expected response time of the service under normal conditions. This value is typically set based on historical data and business requirements. For example, if the historical average response time of a service is 200ms, the cap might be set to 400ms or 500ms, allowing for some fluctuation but preventing excessive latency. A service is considered to have passed the medium-level probe only when all tested functions respond correctly and the response times are all within the cap.

[0198] Comprehensive deep probing is the third phase, assessing the stability and reliability of the service. This is the most comprehensive and resource-intensive probing phase, including extensive functional testing (covering most or all APIs), continuous performance monitoring (such as performance stability under multiple consecutive requests), and edge case testing (such as large data volumes, high concurrency, or special inputs). The purpose of probing is to confirm that the service has fully recovered to a healthy state and can reliably handle various business scenarios.

[0199] Comprehensive probing not only tests the correctness of functionality and basic performance, but also pays special attention to service stability metrics: performance volatility (standard deviation or coefficient of variation of response time), continuous availability (success rate of consecutive requests), and resource utilization efficiency (such as CPU, memory, or network bandwidth consumption). These stability metrics are crucial for predicting service performance under real business loads—a functional but unstable service may quickly fail again under real traffic.

[0200] Throughout the probing process, a sliding window of size K is maintained, recording the K most recent probing results. The sliding window is a dynamic data structure; as new results are added, the oldest results are removed, maintaining a fixed size. This mechanism allows the system to focus on the latest state of the service while considering a sufficient number of samples to ensure statistical significance. The size K of the sliding window is an important parameter, requiring a balance between response speed and stability—a smaller K allows the system to react faster to changes, while a larger K provides a more stable assessment but a slower response.

[0201] Each probe result recorded in the sliding window typically includes several data points: probe timestamp (probe execution time accurate to milliseconds), HTTP response status code (such as 200, 404, or 500), service-specific response status code (service-specific status code), response time (time from sending the request to receiving the complete response), and other relevant metrics (such as response data size, server information, etc.). These detailed records enable the system to perform in-depth failure analysis, rather than simply counting successes and failures.

[0202] Based on the records in the sliding window, the failure rate within the window is calculated. The failure rate is a key metric for measuring service health; it represents the proportion of probe requests that fail. Failure is typically defined in several ways: HTTP errors (non-2xx status codes), business errors (non-successful business status codes), timeouts (response time exceeding a threshold), or content errors (response content not conforming to the expected format or value). These failure scenarios are calculated uniformly to obtain a failure rate value between 0 and 1, where 0 represents complete success and 1 represents complete failure.

[0203] Multiple subpopulations (corresponding to different views) work simultaneously during the detection process, generating their own detection results and evaluations. These results may differ—for example, the subpopulation in the time view might consider the service to be performing normally, while the subpopulation in the error view might detect abnormal error patterns. To generate a unified decision, the system needs to synthesize these results, integrating the perspectives from different viewpoints using methods such as majority voting or weighted averaging.

[0204] Majority voting is a simple and direct method for integrating decisions, where each subpopulation votes on whether to "continue probing" or "stop probing," with the final decision made by the majority. This method is simple and practical, but it may overlook the relative importance of different views—for example, in some scenarios, discovering an erroneous view might be more critical than discovering a temporal view. Weighted averaging, on the other hand, takes this difference into account, assigning different weights to different subpopulations and making decisions based on the weighted results. The allocation of weights is typically based on historical accuracy, current scenario characteristics, or administrator configuration.

[0205] The probe abort threshold is a key parameter defined in the service configuration library. It indicates at what failure rate the remaining probes should be terminated. Setting this threshold requires a balance between efficiency and comprehensiveness—too low a threshold may lead to premature termination, missing a complete assessment of the service status; too high a threshold may waste resources on clearly problematic services. The threshold is typically set between 0.3 and 0.5, representing a failure rate of 30% to 50%, with the specific value depending on the service's criticality and resource constraints.

[0206] When the failure rate within the sliding window exceeds the probe abort threshold, the remaining probe activity is terminated. This early termination mechanism has multiple benefits: conserving system resources (avoiding wasting computing and network resources on obviously faulty services), reducing the burden on the target service (avoiding additional pressure on services that may be recovering), and accelerating the decision-making process (more quickly confirming that the service is not yet ready to unblock the circuit breaker). For example, if 6 out of the first 10 probes fail (a failure rate of 60%), and the abort threshold is 50%, the remaining probes will be terminated immediately, and the service will be marked as "unrecovered".

[0207] Regardless of whether the probe is completed or terminated early, the probe results will be written to the service call logging system. These records contain a wealth of information: probe timestamp (precisely recording the time the probe was executed), service provider unique identifier (clearly indicating the target service of the probe), HTTP response status code (reflecting the result at the communication layer), business response status code (reflecting the result at the application layer), and response time (measuring performance). These detailed records are not only used for current circuit breaker management but also provide valuable data for subsequent analysis and optimization.

[0208] A service call logging system is a persistent storage system that stores all service call information. It records not only normal business calls but also detailed information about probe calls. Log systems typically employ a high-performance distributed architecture, supporting high-throughput writes and complex queries, while also implementing redundant data storage and disaster recovery mechanisms. These logs are crucial for a variety of purposes: fault analysis (understanding the specific reasons for service failures), performance optimization (identifying slow-responding components), trend prediction (discovering long-term performance changes), and compliance auditing (proving that system behavior complies with regulations).

[0209] The writing of probe results is typically asynchronous. The results are first placed in a buffer queue, and then a dedicated write thread submits them in batches to the log system. This asynchronous mechanism ensures that the probe process is not blocked by log write latency, improving overall efficiency. Simultaneously, a write confirmation mechanism is implemented to ensure that important data is successfully stored, preventing data loss due to system crashes or network interruptions.

[0210] In summary, this sophisticated detection mechanism achieves a comprehensive and accurate assessment of the recovery status of circuit breaker services through a multi-dimensional service status view, a co-evolving detection strategy, and a three-stage detection process. The system not only considers multiple metrics (functional correctness, performance, and stability) but also employs intelligent resource allocation strategies (such as early termination mechanisms) to optimize resource utilization efficiency while ensuring assessment accuracy. This advanced detection mechanism is a core component of service availability assurance systems in multi-carrier environments, providing reliable support for circuit breaker management and business continuity.

[0211] Regarding the construction of the evolutionary subpopulations and the specific implementation of the genetic programming method, this embodiment adopts the following technical solution. An evolutionary subpopulation is a concept in genetic algorithms, referring to an independent evolutionary population maintained for a specific problem dimension. In this embodiment, four evolutionary subpopulations are constructed for each of the four dimensions: time view, error view, dependency view, and geographic view. The size of each subpopulation is N (N is typically between 50 and 200, adjusted according to the problem complexity), and each individual in the population represents a probe.

[0212] Genetic programming is an evolutionary computation method. Unlike traditional genetic algorithms that optimize parameters with a fixed structure, genetic programming evolves programs or decision trees with variable structures. In its implementation, each individual is encoded using a tree structure: the internal nodes of the tree are function operators, including conditional statements (such as IF-THEN-ELSE), loop control (such as FOR, WHILE), and logical operations (AND, OR, NOT); the leaf nodes of the tree are terminal symbols, including specific probing actions (such as sending HTTP requests, checking response status codes), numerical parameters (such as setting the timeout to 500 milliseconds, setting the number of retries to 3), and variables read from the service configuration library (such as service provider ID, request address). The depth of each individual is limited to 5 to 10 levels; excessively deep trees are pruned to prevent overly complex probing programs.

[0213] Genetic programming operations include three basic operators. The selection operation uses a tournament selection method: each time, 3 to 5 individuals are randomly selected from the population, their fitness values ​​are compared, and the individual with the highest fitness is selected for the next generation. The fitness function is defined as the detection accuracy minus the detection cost penalty, where detection accuracy is the proportion of successful service anomalies identified out of the total number of detections, and detection cost includes the normalized values ​​of execution time and resource consumption. The crossover operation swaps subtrees at random nodes of two parent individuals, generating two new individuals. The crossover probability is set to 0.8 to 0.9 to ensure that most individuals participate in gene recombination. The mutation operation randomly changes a node of an individual with a probability of 0.05 to 0.2. Mutation types include: function replacement (e.g., replacing IF with SWITCH), terminal value perturbation (e.g., changing the timeout from 500 milliseconds to 600 milliseconds), and subtree regeneration (randomly generating a new subtree to replace the original subtree). Through multiple generations of iteration (typically 100 to 500 generations), the quality of the detection program is gradually improved.

[0214] The implementation of the knowledge-sharing protocol is a key mechanism for achieving co-evolution among subpopulations. After every G generations of evolution (G is typically 5 to 10), each subpopulation replicates its E individuals with the highest fitness (E is typically 2 to 5) to a shared pool. Other subpopulations randomly select individuals from the shared pool to replace their lowest-fitting individuals with a certain probability (typically 0.3 to 0.5). This migration facilitates the fusion of different view detection strategies. For example, the "performance degradation at 2 PM every day" pattern discovered in the time view can be transformed into a strategy of "focusing on detecting timeout errors around 2 PM" in the error view through migration. The termination conditions for co-evolution include: reaching the preset maximum number of generations, no significant improvement in the optimal fitness of the population for 20 consecutive generations, or obtaining a detection program that meets the accuracy requirements (e.g., detection accuracy exceeding 95%). The final output detection strategy set contains the optimal individuals of each subpopulation, sorted by fitness for use in subsequent detection execution phases.

[0215] In this embodiment, the step of performing lightweight and rapid detection and verification of the network connectivity and basic response capabilities of the service based on the co-evolutionary detection strategy set to obtain rapid detection results includes: Based on the lightweight detection strategy in the aforementioned co-evolutionary detection strategy set, a low-cost detection request is initiated according to the request address corresponding to the service provider ID in the service configuration library. The network connectivity of the service is verified by sending a basic connectivity test message, and the basic response capability of the service is verified by calling the service's health check interface. The HTTP response status code and response time of the detection response are recorded to obtain the fast detection result. The fast detection result is used to determine whether to perform a medium-depth detection.

[0216] Specifically, the co-evolutionary probe strategy set is a collection of probe schemes adaptively generated by the system through analysis of historical probe data, service characteristics, and failure modes. This strategy set is continuously optimized using evolutionary algorithms, enabling it to identify the most effective combinations of probe parameters, such as probe frequency, timeout settings, and retry strategies. Lightweight probe strategies, a subset of this set, focus on quickly and cost-effectively verifying the basic availability of services, adhering to the "fail-fast" principle, and can immediately identify and terminate subsequent probe steps when the service is completely unavailable.

[0217] The service configuration repository is a centralized information warehouse maintained by the system, storing key configuration information for all monitored services. For each service provider ID, the configuration repository contains the request address (the URL or endpoint for service access), authentication information, service type, interface specification, and normal response baseline, etc. Before performing a probe, the system first retrieves the complete configuration information of the target service from the configuration repository to ensure that the probe request accurately reaches the correct service node.

[0218] Low-cost probe requests refer to lightweight service calls that consume minimal resources and do not produce business side effects. Compared to full business requests, these requests typically have characteristics such as small request size, simple processing logic, and no actual business operations. For example, a HEAD request might be used instead of a GET request for an HTTP service, or only a single record might be queried instead of batch data. This design ensures that probe activities do not impose additional burden on a newly recovered service, while effectively verifying the service status.

[0219] Basic connectivity testing is the first step in verifying network-layer connectivity. It involves sending dedicated test packets to check if the network path between the system and the target service is intact. This typically includes the following progressive steps: first, a DNS resolution test is performed to check if the service domain name can be correctly resolved to an IP address; then, an ICMP Echo request (ping test) may be executed to verify IP-layer connectivity; next, a TCP SYN probe is performed to attempt to establish a TCP connection with a specific port of the service; for HTTPS services, a TLS handshake verification is also performed to confirm that a secure connection can be established. These tests progressively verify network connectivity from the bottom layer to the top layer. If any step fails, the system can immediately determine that the service has not yet been restored.

[0220] Health check interfaces are lightweight API endpoints specifically designed by service providers for monitoring and probing. Unlike interfaces that execute actual business logic, health check interfaces focus on quickly verifying the basic availability of a service and typically do not perform complex business processing. A typical health check interface uses the GET method to access paths such as " / health" or " / status," returning the current status of the service and health information of key components. The system parses these responses to determine whether the service is functioning correctly. For services without dedicated health check interfaces, the system uses alternatives, such as accessing static resources or performing simple read-only operations.

[0221] HTTP response status codes are three-digit codes returned by the server, indicating the result of request processing. The system logs and analyzes these status codes, treating 2xx (success) as normal responses, 5xx (server error) as generally indicating ongoing service problems, and 3xx (redirection) and 4xx (client error) requiring further analysis. For example, for health check interfaces, 200 OK usually indicates normal service operation, while 500 Internal Server Error almost always indicates a serious service problem. The system considers the specific meaning of the status code and the probing context to make an accurate judgment.

[0222] Response time is the time elapsed from sending a request to receiving a complete response, typically measured in milliseconds. The system records the response time for each probe and compares it to a baseline value in the configuration library to determine if service performance is within acceptable limits. Even if the status code is normal, an abnormally long response time (e.g., exceeding three times the baseline) may indicate a performance degradation. Response time analysis usually considers statistical significance, using the average or median of multiple probe results for a more reliable judgment.

[0223] The quick probe results are a comprehensive output of the lightweight probe phase, including connectivity test results, health check response status, status code analysis, and response time assessment. The system evaluates whether the service has regained basic availability based on predefined criteria (such as "connectivity test successful and health check returns 2xx status codes"). If the quick probe indicates that the service is still unavailable, the system will maintain the circuit breaker status and schedule subsequent retries; if the service demonstrates basic availability, the system will enter a medium-deep probe phase to further verify the service's functional integrity and performance metrics.

[0224] Medium-depth probing is the second phase of service availability verification, more comprehensive than lightweight probing but more efficient than full functional testing. This phase focuses on verifying whether core business functions are working correctly, typically including executing simplified versions of critical business processes, verifying the responses of major interfaces, and testing key functionalities. Only services that pass rapid probing will enter this phase. This layered strategy ensures that system resources are concentrated on services with recovery potential, significantly improving overall probing efficiency.

[0225] The lightweight and rapid detection process described above can quickly and accurately determine whether the circuit breaker service has regained basic availability with minimal resource consumption, providing a reliable foundation for subsequent in-depth detection and routing decisions. This efficient detection mechanism is a key component of service availability assurance systems in multi-carrier environments, ensuring that the system can promptly detect changes in service status and optimize resource allocation and request routing.

[0226] In this embodiment, the step of obtaining a list of available operator services based on the operator service health status and filtering operator services in a circuit breaker state, selecting a target operator service according to a multi-objective optimization algorithm, and generating a routing decision result includes: The optimization objectives are defined as minimizing service response time, maximizing service success rate, optimizing cost-effectiveness ratio, and balancing load distribution. The constraints are established as service quality baseline requirements, operator call quota limits, specific business scenario requirements, and system resource usage limits, resulting in a multi-objective decision-making framework.

[0227] The system constructs a performance-priority population to minimize service response time, a stability-priority population to maximize service success rate, and a balanced population to balance all optimization objectives. This enables elite individual migration strategies, cross-population hybridization operations, and shared fitness evaluation results, resulting in a multi-population population architecture.

[0228] Based on the multi-objective decision-making framework and the multi-population architecture, weight coefficients are set for each optimization objective, and a weighted summation fitness function is constructed.

[0229] For each decision-making individual in the multi-group population architecture, its performance value on the service response time target is calculated based on the historical response time recorded in the service call log system; its performance value on the service success rate target is calculated based on the success rate in the historical call records; its performance value on the cost-effectiveness target is calculated based on the cost information in the service configuration library; and its performance value on the load distribution target is calculated based on the current call frequency of each operator's services. The weighted summation fitness function is used to calculate the comprehensive fitness value. The decision-making individual is checked for violations of the constraints, and the constraint violation degree is calculated and added as a penalty to the comprehensive fitness value. Based on the actual response time, success rate, cost, and load distribution data of the decision-making individual in the historical execution process recorded in the service call log system, the mean and variance of historical performance are calculated to obtain long-term stability indicators and reliability indicators. The long-term stability indicators and reliability indicators are integrated into the comprehensive fitness value to obtain the fitness evaluation result.

[0230] Based on the fitness assessment results, the mutation rate is dynamically adjusted according to the current population diversity. Individual selection is performed using either tournament selection or roulette wheel selection. The optimal individual is retained, and evolutionary iteration is performed to obtain the optimal routing decision individual.

[0231] The optimal routing decision individual is converted into a weighted list of operator call priorities. Based on the operator service health status, operator services in circuit breaker state are filtered out. The target operator service is selected according to the operator call priority list to obtain the routing decision result. The routing decision result includes the selected service provider ID and the corresponding call weight.

[0232] Specifically, multi-objective optimization algorithms are effective methods for solving complex decision-making problems with multiple conflicting objectives. They can simultaneously optimize decision outcomes across multiple dimensions. In service routing scenarios, systems need to balance multiple objectives such as response time, success rate, cost, and load. These objectives often cannot be simultaneously optimized, requiring the search for the best compromise solution. Multi-objective optimization, by considering multiple objective functions simultaneously, searches for a set of optimal or near-optimal decision solutions, providing decision-makers with diverse choices.

[0233] The system first defines four core optimization objectives: minimizing service response time, maximizing service success rate, optimizing cost-effectiveness ratio, and balancing load distribution. Service response time refers to the time required from sending a request to receiving a complete response, directly affecting user experience; service success rate represents the proportion of requests that are successfully processed, reflecting service reliability; cost-effectiveness ratio measures the service quality obtained per unit cost, which is related to operational efficiency; and load distribution ensures that the system uses the resources of various operators in a balanced manner, avoiding single-point overload or resource waste.

[0234] Meanwhile, the system establishes four types of constraints: Service Quality Baseline Requirements specify the minimum acceptable thresholds for each indicator, such as a maximum response time of no more than 500 milliseconds and a minimum success rate of no less than 99.5%; Carrier Call Quota Limits take into account the usage restrictions of each carrier's services, such as the maximum number of calls per day or peak call frequency; Business Scenario Specific Requirements reflect the special requirements of different business types, such as the high success rate requirements of transaction services and the low sensitivity of notification services to latency; System Resource Usage Limits take into account the capabilities of the local system, such as the number of concurrent connections or the request queue depth limit.

[0235] These optimization objectives and constraints together constitute a multi-objective decision-making framework, providing clear evaluation criteria and boundary conditions for subsequent optimization algorithms. The decision-making framework employs a formal mathematical description, quantifying each objective function and constraint into computable expressions, thus giving the decision-making process a rigorous mathematical foundation.

[0236] To improve optimization efficiency and decision-making quality, the system employs an innovative multi-population architecture. This architecture comprises three populations with different focuses: a performance-first population primarily optimizes response time, suitable for latency-sensitive scenarios; a stability-first population prioritizes maximizing service success rate, suitable for businesses with high reliability requirements; and a balanced population considers all objectives in a balanced manner, providing a comprehensive optimal solution. This population strategy enables simultaneous exploration of different regions of the search space, significantly increasing the probability of finding diverse, high-quality solutions.

[0237] The multi-population architecture implements three population interaction mechanisms: the elite individual migration strategy allows the best individuals in each population to migrate to other populations periodically, promoting the spread of superior genes; cross-population hybridization allows individuals from different populations to exchange genetic information, producing offspring with mixed characteristics; and sharing fitness evaluation results reduces redundant computation and improves algorithm efficiency. These mechanisms enable each population to maintain its own characteristics while sharing each other's advantages, resulting in a co-evolutionary effect.

[0238] Based on a multi-objective decision-making framework and a multi-population architecture, the system constructs a weighted summation fitness function. This function simplifies the computational complexity by assigning different weight coefficients to each optimization objective, transforming the multi-objective problem into a single-objective problem. The weight coefficients reflect the relative importance of each objective and can be dynamically adjusted according to business needs. For example, during peak transaction periods, a weight might be allocated to increase the success rate, while during nighttime batch task processing, a weight might be allocated to increase the cost-effectiveness ratio.

[0239] For each decision-making individual in the population (i.e., a possible routing strategy), the system needs to evaluate its performance on each objective. Service response time performance is calculated based on historical response times recorded in the service call log, typically using the average or a specific percentile (such as P95 or P99); service success rate performance is based on the ratio of historical successful calls to the total number of calls; cost-effectiveness performance is calculated based on the ratio of price information in the service configuration library to service quality indicators; and load distribution performance is measured by indicators such as the variance of the current call frequency of each operator's services or the Gini coefficient.

[0240] These raw performance values ​​are standardized to a comparable scale, and then substituted into a weighted summation fitness function to calculate the overall fitness value. Simultaneously, the system checks whether individual decision-makers violate constraints, calculating the constraint violation degree as a penalty term added to the overall fitness value. For example, if a strategy causes an operator to exceed its call quota, a corresponding penalty value will be generated, reducing its fitness.

[0241] A long-term stability and reliability assessment mechanism was also introduced. By analyzing historical performance data recorded in service call logs, the mean and variance of each indicator were calculated to obtain long-term stability indicators (reflecting the continuity of performance) and reliability indicators (reflecting the consistency of performance). These indicators were incorporated into a comprehensive fitness value to ensure that the selected strategy not only performs well in the short term but also has long-term stability.

[0242] Based on the complete fitness assessment results, an evolutionary iterative process is executed. First, the mutation rate is dynamically adjusted according to the current population diversity. When population diversity decreases, the mutation rate is increased to promote the exploration of new solution spaces; conversely, the mutation rate is decreased to strengthen the development of currently dominant regions. For individual selection, either tournament selection (randomly selecting several individuals and choosing the one with the highest fitness) or roulette wheel selection (allocating selection probabilities according to fitness ratios) can be used. Both methods ensure that individuals with high fitness have a greater chance of survival and reproduction, while preserving a certain degree of diversity.

[0243] To prevent the loss of excellent individuals during the iteration process, an elite preservation strategy is adopted, directly retaining the best individuals from each generation to the next. After multiple iterations (usually tens to hundreds of generations), the population gradually converges to the optimal or near-optimal solution, from which the individual with the highest overall fitness is selected as the final routing decision.

[0244] Finally, the optimal routing decision is transformed into an executable routing strategy. This transformation process generates a weighted list of carrier call priorities, where the weights reflect the probability of each carrier's service being selected. The system filters out services in a circuit breaker state based on the latest carrier service health status, ensuring that routes are only routed to healthy service nodes. The final routing decision includes the selected service provider ID and its corresponding call weight, such as "Carrier A: 70%, Carrier B: 30%", guiding the system to allocate actual requests proportionally.

[0245] This multi-objective optimization-based routing decision-making method can find the optimal solution that satisfies multiple objectives and constraints in complex and ever-changing environments, significantly improving the overall quality and efficiency of service calls. The system can adaptively adjust its decision-making strategy according to business needs and environmental changes, achieving intelligent service routing management.

[0246] Regarding the specific implementation of the multi-objective optimization algorithm and the evolutionary algorithm, this embodiment adopts the following technical solution. The multi-objective optimization algorithm is used to solve decision problems with multiple conflicting objectives. In this embodiment, the four optimization objectives (minimizing response time, maximizing success rate, optimizing cost-benefit ratio, and balancing load distribution) cannot be simultaneously optimized. Therefore, the evolutionary algorithm is used to search for the Pareto optimal solution set.

[0247] Evolutionary algorithms simulate the biological evolution process, including steps such as population initialization, selection, crossover, mutation, and fitness evaluation. This embodiment employs a multi-population architecture, with three subpopulations using differentiated evolutionary strategies: the performance-priority population's fitness function has a response time target weight of 0.6 to 0.8, a success rate weight of 0.1 to 0.2, and cost-effectiveness and load balancing weights both below 0.1; the stability-priority population has a success rate weight of 0.6 to 0.8, a response time weight of 0.1 to 0.2, and other targets with lower weights; the equilibrium population uses equal weights, with each primary target weight between 0.2 and 0.3. Each subpopulation consists of 30 to 100 individuals, using real-number encoding. Each individual is represented as a weight coefficient vector, the length of which equals the number of available operator services, with each component value between 0 and 1. After normalization, this represents the call ratio of each operator.

[0248] Population initialization uses uniformly distributed random generation to ensure search space coverage. The elite individual migration strategy is implemented as follows: after every M generations (M is typically 5 to 15), each subpopulation marks its top K best individuals (K is typically 10% to 20% of the population size, i.e., 3 to 20) as elites. These elite individuals are introduced into other subpopulations with a probability of 0.3 to 0.5, replacing random individuals in those subpopulations. Cross-population hybridization occurs between elite individuals, exchanging partial gene segments (i.e., exchanging partial operator weight coefficients) with a probability of 0.6 to 0.8, producing offspring with different optimization tendencies.

[0249] The specific calculation process for fitness evaluation is as follows: For a given decision individual (a set of operator call weights), the constraints are first checked. Service quality baseline requirements include: weighted average response time lower than the configuration limit (e.g., 500 milliseconds) and weighted success rate higher than the configuration lower limit (e.g., 99.5%). Failure to meet any of these conditions is marked as a constraint violation. Operator call quota limits are determined by comparing weight allocation with the quota limit, and system resource usage limits are assessed by simulating resource consumption under the current load. For individuals that violate constraints, the degree of violation (normalized sum of squared violations) is calculated, multiplied by a penalty coefficient (usually between 10 and 1000), and added to the fitness function as a penalty term. For individuals that meet the constraints, the performance values ​​for each objective are calculated: response time performance is the reciprocal of the weighted average of the historical average response times of each operator (taking the reciprocal transforms the minimization problem into a maximization problem); success rate performance is the weighted average success rate; cost-effectiveness ratio performance is the service quality score divided by the unit call cost; and load distribution performance is the reciprocal of the variance between each operator's weight and the ideal equilibrium weight (i.e., 1 / number of operators). The weighted summation fitness function is F = w1×T + w2×S + w3×C + w4×L, where w1 to w4 are weight coefficients that sum to 1, and T, S, C, and L are the normalized performance values ​​of each objective.

[0250] Selection can employ either tournament selection (randomly selecting 3 to 5 individuals, choosing the one with the highest fitness) or roulette wheel selection (allocating selection probabilities according to fitness ratios). Crossover uses simulated binary crossover or uniform crossover, while mutation uses polynomial mutation or Gaussian mutation. The mutation rate is dynamically adjusted based on population diversity: diversity is measured by individual fitness variance or genotype distance. When diversity is below a threshold, the mutation rate is increased by 20% to 50% to promote exploration; when it is above the threshold, the mutation rate is decreased to enhance development. Iteration termination conditions include: reaching the maximum number of iterations (100 to 500 generations), no improvement in optimal fitness for 30 to 50 consecutive generations, or population convergence (individual similarity exceeds 90%). Finally, the individual with the highest fitness from the three subpopulations is selected as the optimal route decision.

[0251] In this embodiment, the step of setting weight coefficients for each optimization objective and constructing a weighted summation fitness function based on the multi-objective decision-making framework and the multi-population architecture further includes: Based on the execution results of historical routing decisions in the service call log system, the deviation data between the predicted response time and the actual response time, the deviation data between the predicted success rate and the actual success rate are collected during decision execution, and the deviation data between the predicted performance and the actual performance are calculated.

[0252] The weight coefficients in the weighted summation fitness function are adjusted based on the deviation data to obtain the updated weighted summation fitness function.

[0253] Specifically, the weighted summation fitness function is a commonly used objective aggregation method in multi-objective optimization. By assigning weight coefficients to different optimization objectives, it uses the weighted sum of multiple objective functions as a single evaluation criterion. In service routing scenarios, this function comprehensively considers multiple objectives such as response time, success rate, cost-effectiveness, and load balancing, forming a comprehensive evaluation of each possible decision. The general form of the function is the sum of the products of each objective function value and its corresponding weight. The weight coefficients reflect the relative importance of each objective and are typically set to a non-negative value of 1 or 100% sum.

[0254] The weighting coefficients have a decisive impact on the decision-making outcome. For example, if the response time weight is set to 0.5, the success rate weight to 0.3, the cost-effectiveness weight to 0.1, and the load balancing weight to 0.1, the system will prioritize the solution with the shortest response time, followed by the solution with the highest success rate. This weighting configuration is suitable for latency-sensitive interactive applications, but may not be suitable for financial transaction scenarios that require high reliability. Traditionally, weighting coefficients are set by domain experts based on experience or determined through extensive experimental tuning; this method lacks dynamic adaptability.

[0255] Service call logging systems are a crucial component of routing decision-making systems. They meticulously record complete information for each service call, including call time, target service, request parameters, routing decision basis, expected performance metrics, and actual execution results. This log data forms a valuable historical decision database, providing a foundation for system self-optimization. Modern logging systems typically employ distributed architectures and efficient storage formats, supporting rapid retrieval and complex analysis, and capable of handling massive amounts of log data in large-scale service environments.

[0256] Bias data refers to the difference between the performance metrics predicted by the system and the actual observed results during decision execution. The deviation between predicted response time and actual response time reflects the accuracy of the system's estimation of service performance; the deviation between predicted success rate and actual success rate shows the accuracy of the system's judgment on service reliability. These deviations may stem from various factors, such as dynamic changes in service behavior, network fluctuations, system load fluctuations, or limitations of the prediction model itself. Analyzing these deviations helps identify weaknesses in the prediction model and shortcomings in the decision function, providing direction for optimization.

[0257] To collect deviation data, historical routing decision records are first extracted from the service call logs. Each record contains the predicted metrics at the time of the decision (e.g., expected response time 50ms, expected success rate 99.8%) and the observed metrics after actual execution (e.g., actual response time 63ms, actual success rate 99.5%). The system calculates the difference between the predicted and actual values ​​for each decision, generating the raw deviation dataset.

[0258] After collecting the raw deviation data, statistical analysis is required to identify deviation patterns and trends. Common analytical methods include calculating the mean deviation, standard deviation, deviation distribution characteristics, and time trends. For example, the system might find that response time predictions for a specific service are consistently 15% lower, indicating that the prediction model may systematically underestimate the latency of that service; or it might find that success rate predictions are higher during peak periods, indicating that the system has not adequately considered the impact of load factors on reliability.

[0259] In-depth attribution analysis of deviations will also be conducted, linking deviations to various possible influencing factors, such as service type, call time period, load level, and network conditions. This analysis helps to understand the root causes of deviations and provides a basis for targeted optimization. For example, the system may find that response time predictions are more inaccurate for data-intensive services but relatively accurate for compute-intensive services, indicating that differentiated prediction models may be needed for different service types.

[0260] Based on the results of bias data analysis, an adaptive weight adjustment algorithm is used to optimize the fitness function. If the prediction of a certain optimization objective deviates significantly from the actual situation, the weight of that objective will be reduced to decrease the impact of unreliable predictions on decision-making; conversely, objectives with accurate predictions will receive higher weights, enhancing the decision-making contribution of reliable information. This adjustment follows the "trust weighting" principle, allocating more decision-making power to aspects with more accurate predictions.

[0261] Specifically, for the response time objective, if historical data shows that the predicted time is underestimated by an average of 20%, its weight may be reduced and a correction factor added to the predicted value. For the success rate objective, if the prediction is largely consistent with the actual value, the system will maintain or slightly increase its weight, reflecting a high level of confidence in the prediction. The adjustment magnitude is generally positively correlated with the severity and consistency of the deviation; persistently large deviations lead to more significant weight adjustments.

[0262] The weighting adjustment also considers the relative importance of different objectives and business tolerance. Even if an objective's prediction is inaccurate, its weight reduction will be limited if it is crucial to the business (such as success rate in financial transactions). The system sets upper and lower limits for each weight to ensure that the adjusted weight allocation still reflects the basic business priority.

[0263] A gradual adjustment strategy is employed to avoid drastic fluctuations in weights. Each adjustment is typically limited to a small range (e.g., 5%-15% of the original weight), with multiple consecutive deviations leading to a larger cumulative adjustment. This gradual strategy ensures that the system can adapt to changes in service behavior while avoiding overreaction to temporary fluctuations.

[0264] In addition to weight adjustments, the prediction model itself is optimized based on bias analysis. For example, if biases in a specific pattern are discovered, new variables or more complex computational logic can be introduced into the prediction algorithm to improve the accuracy of the original prediction. This "two-pronged" optimization strategy—simultaneously improving the prediction model and the fitness function—can significantly enhance the overall decision-making quality.

[0265] The updated weighted fitness function will be immediately applied to subsequent routing decisions. The system will continuously monitor the performance of the new function, evaluating whether the bias has decreased and whether the decision quality has improved, forming a closed-loop optimization mechanism. If the adjustment is ineffective, the system may roll back to the previous configuration and try other adjustment strategies.

[0266] Comprehensive weight optimization analyses are also performed regularly to identify long-term trends and cyclical patterns. For example, it might reveal that different weight configurations are needed for weekdays and weekends, or that the predictive accuracy of certain services improves as service uptime increases. These insights are used to develop more sophisticated time-varying or context-sensitive weight adjustment strategies, further enhancing the system's adaptability.

[0267] Through this adaptive weight adjustment mechanism based on historical deviation data, the service routing decision system can continuously learn and evolve, overcoming the limitations of the initial configuration and adapting to changes in service behavior and environmental complexity. This self-optimization capability is key to the long-term effective operation of the system, ensuring that routing decisions become increasingly accurate and service quality continuously improves over time.

[0268] Regarding the specific implementation of the adaptive weight adjustment algorithm and the prediction algorithm, this embodiment adopts the following technical solution. The prediction algorithm is used to estimate the performance of each operator's service in terms of response time and success rate. This embodiment uses a sliding window average method based on historical data: for response time prediction, the average response time of the operator's most recent H calls (H is usually 20 to 50) is taken as the predicted value; for success rate prediction, the ratio of the number of successful calls to the total number of calls in the most recent H calls is calculated. More accurate prediction can use an exponentially weighted moving average, that is, recent data is given higher weights, and the weights decay exponentially.

[0269] The adaptive weight adjustment algorithm dynamically optimizes the weight coefficients in the fitness function based on prediction bias. The bias data collection mechanism is as follows: after each routing decision, the predicted value (predicted response time and prediction success rate) at the decision time and the observed value after actual execution are recorded. The absolute bias (the absolute value of the difference between the predicted value and the observed value) and the relative bias (absolute bias divided by the observed value) are calculated. This data is stored according to operator service and time period, forming a historical bias database. Statistical analysis is performed periodically (hourly or daily) to calculate the average relative bias of each optimization objective within the most recent time window (the most recent 100 decisions or the most recent 24 hours). If the average relative bias of an objective exceeds a preset threshold (usually 10% to 30%), the prediction model for that objective is deemed unreliable.

[0270] The weight adjustment uses exponential smoothing, and the formula is w. new = α×w old + (1-α)×w adjusted , where α is a smoothing coefficient (usually taken as 0.7 to 0.9) to ensure the gradual adjustment of weights. adjusted Adjusted weights based on bias calculation: for targets with below-average prediction accuracy, w adjusted = w old × (1 - β×relative error ), where β is the adjusted intensity coefficient (usually taken as 0.5 to 2.0), relative error The average relative deviation of the target is represented by w; the larger the deviation, the greater the reduction in weight. For targets with prediction accuracy above average, w... adjusted = w old× (1 + γ × relative_accuracy_improvement), where γ is the reward coefficient (usually between 0.1 and 0.5), and relative_accuracy_improvement is the percentage improvement in accuracy relative to the average level for this objective. To prevent excessive fluctuations in weights, each adjustment should not exceed 30% to 50% of the original weight, and each weight should be kept between 0.05 and 0.95. For business-critical objectives (such as success rate), a lower limit protection for weights should be set (usually not lower than 0.2).

[0271] The optimization of the prediction algorithm and the adjustment of weights are carried out in parallel. If the prediction deviation of a certain target remains large, the prediction model parameters are adjusted: for the sliding window averaging method, the window size H is adjusted (increasing H makes the prediction more stable, decreasing H makes the prediction more sensitive); for the exponentially weighted moving average, the decay factor is adjusted. If the prediction deviation of a certain target does not improve after multiple (3 to 5) weight adjustments, the prediction model is switched, such as from simple averaging to linear regression or time series models. After the weight adjustment, the updated fitness function is used for a new round of routing decisions, and new deviation data is continuously monitored to form a closed-loop optimization mechanism. The system also performs comprehensive weight optimization analysis periodically (weekly or monthly) to identify long-term trends (such as different weight configuration requirements for weekdays and weekends) and periodic patterns, and establishes time-varying or context-sensitive weight adjustment strategies to further improve the system's adaptability.

[0272] In this embodiment, the step of obtaining a list of available operator services based on the operator service health status, filtering operator services in a circuit breaker state, selecting a target operator service according to a multi-objective optimization algorithm, and generating a routing decision result further includes: When the health status of the operator services shows that all operator services are in a circuit breaker state, query the local cache to obtain historical response data or return the preset default value, and generate a degradation response result.

[0273] The degradation event is recorded, including the degradation trigger time, degradation reason, and impact scope. A degradation notification is sent through a high-priority alarm channel to obtain the degradation policy execution record. The degradation policy execution record is written to the service call log recording system for subsequent analysis and alarms.

[0274] Specifically, the circuit breaker state is a protective state in service availability management mechanisms. It is triggered when a service experiences a persistently high error rate, timeout, or other failure indicators exceeding a preset threshold. A service in the circuit breaker state temporarily rejects new requests, preventing continuous requests from being sent to unstable downstream services. This protects downstream services from overload and also prevents the system's resources from being consumed by a large number of failed requests. Circuit breaker mechanisms typically follow a state machine model, including three states: Closed, Open, and Half-Open. The system transitions between these states based on request success rate and error patterns.

[0275] When the monitoring system detects that all carrier services are in a circuit breaker state, traditional routing strategies can no longer function properly, and the system must initiate a degradation process. Degradation is a fault tolerance strategy that refers to the technical means of maintaining the availability of core functions by reducing functional complexity or service quality when some components of the system are unavailable. Graceful degradation strategies can be divided into multiple levels based on business importance and technical feasibility, ranging from minor functional restrictions to retaining only the most basic operations.

[0276] Local caching is a copy of data maintained by the system in memory or local storage media for fast access to frequently used information and reducing reliance on remote services. In service routing systems, local caches typically store recent service call results, frequently used data, and configuration information. Caching strategies include expiration mechanisms (limiting the maximum data retention time), capacity control (limiting cache resource consumption), and consistency maintenance (ensuring cached data is synchronized with source data). Advanced caching implementations may employ a layered architecture, combining memory caching, local disk caching, and distributed caching to balance performance and reliability.

[0277] Historical response data consists of records of past service calls, including request parameters, response content, status codes, and timestamps. This data serves as a backup data source when all services are unavailable, allowing the system to retrieve the most matching response from the historical records based on request similarity. The retrieval process may involve multi-dimensional similarity calculations, considering factors such as exact matching of request parameters, semantic similarity, and temporal relevance. After obtaining a matching record, the system evaluates its timeliness and applicability to determine whether it can be used for the current request.

[0278] Preset default values ​​are alternative responses used by the system when real-time or historical data cannot be obtained. These default values ​​are typically predefined by business experts and meet basic functional requirements or provide the minimum acceptable service. Default values ​​may be static constants, dynamically generated template content, or calculation results based on business rules. Different business scenarios may require different default value strategies, and the system will select appropriate default content based on request type, parameter characteristics, and business context.

[0279] A degraded response is an alternative response generated by the system in degraded mode. Compared to a normal response, it may have simplified functionality or reduced accuracy. A degraded response typically includes a standard-formatted content section and metadata, the latter indicating the response source (cached or default value), generation time, and reliability score. The system also adds special markers to the response, enabling the caller to identify it as a degraded response and decide how to handle it based on its own strategy. Certain critical business requirements may necessitate that degraded responses explicitly distinguish between "deterministic historical data" and "estimated default values" to support accurate decision-making in downstream systems.

[0280] A degradation event log is a detailed document of the system's degradation process, containing three core elements: the degradation trigger time, which records the precise timestamp of the event for event sequence reconstruction and root cause analysis; the degradation cause, which describes the specific conditions leading to the full circuit breaker, such as the detected error type, error rate, and duration; and the scope of impact, which defines the business domains, functional modules, and user groups affected by the degradation, assessing the degree of business impact of the event. A complete degradation event log may also include a snapshot of the system state before the degradation and the basis for the decision, facilitating post-event auditing and improvement.

[0281] High-priority alert channels are dedicated communication channels for emergency notifications, offering higher resource priority, shorter transmission latency, and more reliable delivery guarantees. Unlike regular monitoring alerts, high-priority alerts typically utilize multiple parallel notification mechanisms, such as internal system messages, email, SMS, and telephone, ensuring key personnel are promptly informed. Alert content is specially formatted to highlight severity, scope of impact, and necessary response measures, supporting rapid decision-making and action. In large-scale organizations, alerts are also automatically routed to the appropriate handling team based on responsibilities and escalation mechanisms.

[0282] The degradation strategy execution log is a detailed record of the complete execution of the degradation process, including information such as strategy selection logic, parameter configuration, execution timeline, and effect evaluation. After being written to the service call logging system, these records are used for three main purposes: post-event analysis to identify degradation triggering patterns and root causes, improving circuit breaker and degradation mechanisms; performance evaluation to measure the effectiveness of degradation strategies, such as changes in response time, error rate impact, and business continuity metrics; and alarm optimization to adjust alarm thresholds and notification processes, reducing false alarms and missed alarms, and improving alarm effectiveness.

[0283] Service call logging systems are infrastructures specifically designed to capture, store, and analyze data throughout the entire lifecycle of service calls. Modern logging systems typically employ a distributed architecture, supporting high-throughput writes and complex query capabilities, and can handle structured and semi-structured data. The system applies special retention policies to degradation-related logs, ensuring longer storage periods and higher integrity guarantees for this type of critical data. Log data is usually analyzed through batch or stream processing pipelines to generate trend reports, anomaly detection results, and optimization directions, supporting continuous system improvement.

[0284] Through the comprehensive degradation mechanism described above, even in the extreme case where all operator services are simultaneously unavailable, the system can still provide basic functions, maintain business continuity, and ensure that faults are handled promptly and systemically improved. This multi-layered degradation architecture is a key line of defense for highly available distributed systems, embodying the engineering principle of "designing for the worst-case scenario."

[0285] In this embodiment, the step of broadcasting a status change event and generating a status change notification via a message queue when the health status of the operator's service changes includes: When the operator's service health status changes from healthy to circuit breaker status or from circuit breaker status to healthy status, a status change event is constructed, which includes the service provider identifier, the status before the change, the status after the change, the change time, and the reason for the change based on the comprehensive health score or the detection result.

[0286] The status change event is published to a message queue, and a status change notification is sent via email, SMS, or instant messaging.

[0287] Based on the importance level of the operator's service in the service configuration library and the current time, determine whether to trigger a telephone alarm, generate a detailed status change report including the reason for the change, the time of the change, and the scope of impact, and obtain the status change notification.

[0288] Specifically, the health status of a carrier's service is a comprehensive indicator describing the current availability and performance level of the service, typically categorized into several levels such as healthy, sub-healthy, and circuit breaker. A healthy state indicates that the service is operating normally, with all indicators within ideal ranges; a sub-healthy state indicates that the service can respond to requests but has potential risks, such as prolonged response times or an increase in occasional errors; a circuit breaker state indicates that the service is unreliable or completely unavailable, and the system will proactively block requests to that service to prevent cascading failures. Status determination is based on multi-dimensional monitoring indicators, such as success rate, response time, error type, and system resource utilization, combined with preset thresholds and statistical models for comprehensive evaluation.

[0289] Message queues are a distributed communication mechanism used to deliver asynchronous messages between system components. As a decoupled middleware, message queues support a producer-consumer model, allowing message senders and receivers to be separated in time and space. In service health management, message queues provide a reliable event delivery channel with high throughput, low latency, and message persistence capabilities, ensuring that state change events are accurately delivered to all interested parties. Modern message queue systems such as Kafka and RabbitMQ support publish-subscribe patterns, allowing multiple consumers to receive the same event simultaneously, making them ideal for broadcasting state change notifications.

[0290] State change events are standardized data structures generated by the system, encapsulating complete contextual information about service health status changes. Each event contains five core data items: Service Provider Identifier, a unique code or name identifying the operator, used to clearly indicate which service has changed; Pre-Change State and Post-Change State, recording the direction of the health status transition, such as from healthy to circuit breaker or from circuit breaker back to healthy; Change Time, a timestamp accurate to milliseconds, used for event sorting and time-series analysis; and Change Reason, based on a comprehensive health score or specific detection results, detailing the specific indicators and threshold violations that triggered the state change.

[0291] The construction process for state change events follows a standardized format, typically using structured data formats such as JSON or Protocol Buffers to ensure information integrity and cross-platform compatibility. The system makes judgments based on raw data provided by the monitoring subsystem, and immediately triggers the event construction process when it detects a service transitioning from healthy to circuit breaker or recovering from circuit breaker to healthy. In addition to basic fields, advanced implementations may include additional contextual information, such as impact assessment, the status of other related services, and corresponding handling measures.

[0292] Message queue publishing is the process of delivering constructed state change events to a designated message queue. Typically, a dedicated "Service State Change" topic is maintained, and all components concerned with service health subscribe to this topic. The publishing process includes message serialization, transport protocol processing, and reliability guarantees. The system uses the client API provided by the message queue middleware to ensure successful message delivery and broker acknowledgment. In high-availability configurations, the publishing mechanism also includes failure retry logic and message idempotency handling to prevent message loss or duplication.

[0293] Multi-channel notifications are a mechanism where the system sends alerts to relevant personnel through different communication channels based on the severity and urgency of status changes. Email notifications are suitable for sending detailed technical information and change context, typically including complete event data and links to relevant historical records; SMS notifications, due to their high delivery rate and immediacy, are suitable for sending concise status reminders, ensuring key personnel are informed of changes even when not at their computers; instant messaging tools (such as WeChat Work, Slack, etc.) provide an interactive notification experience, supporting message confirmation, team discussions, and automated operations, making them suitable for complex changes requiring team collaboration. Notification content is adapted to the characteristics of the receiving channel, maintaining consistency in core information while optimizing presentation.

[0294] Importance level is a categorization attribute defined in the service configuration library, used to quantify the importance of different operator services to the business. Common classification methods include Critical, Important, Normal, and Minor levels. The classification is based on multiple considerations, such as the business value supported by the service, substitutability, scope of user impact, and compliance requirements. Changes in the status of high-importance services typically trigger broader notifications and faster response processes, while lower-importance services adopt a more lenient handling strategy. This differentiated mechanism helps optimize alarm resource allocation and avoid alarm fatigue.

[0295] Telephone alerts are the highest level of notification, designed to ensure critical changes are addressed promptly. The system determines whether to activate a telephone alert based on two conditions: first, it checks the service's importance level; typically, only "critical" or "important" services are considered for telephone alerts; second, it assesses whether the current time is during a sensitive period (such as peak business hours or off-peak hours), as changes during these times may require more urgent handling. Telephone alert systems are usually integrated with automated call platforms, capable of calling responsible parties level by level according to a preset escalation sequence until a confirmation response is received, ensuring that emergencies are not overlooked.

[0296] A detailed status change report is a comprehensive document generated by the system, providing the complete background and technical details of the change to facilitate in-depth analysis and decision-making. The report is organized into three main parts: the "Cause of Change" section analyzes in detail the specific anomalies that triggered the status transition, including the degree, duration, and trend of threshold violations; the "Change Time" section provides not only the precise time of occurrence but also relevant temporal context, such as the interval since the last similar change and whether it occurred within a known system maintenance window; and the "Scope of Impact" section assesses the business functions, user groups, and related services that may be affected by this change, providing both quantitative and qualitative impact assessments. Advanced reports may also include automatically generated remedial measures and references to the handling of similar historical events.

[0297] Status change notifications are a collective term for all the aforementioned notification channels and content, representing a complete mechanism for externally conveying information about changes in health status. After a notification is generated, in addition to being sent directly to personnel, it is also logged in a dedicated log system for post-event auditing and analysis. The system tracks the delivery status and processing progress of notifications to ensure that every critical change receives an appropriate response, and continuously optimizes the notification strategy based on actual processing results, such as adjusting notification frequency, content detail, and recipient scope.

[0298] Through this multi-layered, multi-channel state change notification mechanism, the system ensures that service health status changes are promptly and accurately communicated to all relevant parties, providing a solid foundation for rapid fault response and system self-healing. This design reflects the high requirements of modern distributed systems for observability and fault management, and is a key component in achieving high availability and resilience.

[0299] Example 2 like Figure 2 As shown, this embodiment provides an intelligent handover system for ensuring service availability in a multi-carrier environment, including: The log storage module 10 is used to acquire call log data of multiple operator service interfaces, perform structured storage on the call log data to obtain a service call log recording system; at the same time, it constructs a service configuration library containing operator service configuration parameters.

[0300] The health detection module 20 is used to obtain the most recent N call records of the target operator's service based on the historical call data in the service call log recording system and the health check sample size in the service configuration library, using a sliding window statistical model, to perform anomaly identification and performance analysis on the most recent N call records, and generate a comprehensive health score; based on the comprehensive health score and the abnormal circuit breaker threshold in the service configuration library, it executes a circuit breaker decision and outputs the health status of the operator's service.

[0301] The service detection module 30 is used to filter operator services in circuit breaker state according to the health status of the operator services, initiate multiple simulated call requests to the operator services in circuit breaker state, maintain a sliding window to record the detection results during the detection process, calculate the failure rate within the sliding window, terminate the remaining detection when the failure rate exceeds a preset termination threshold, and write the detection results into the service call log recording system.

[0302] The routing decision module 40 is used to obtain a list of available operator services based on the health status of the operator services and filter operator services that are in a circuit breaker state, select a target operator service according to a multi-objective optimization algorithm, and generate a routing decision result; when the health status of the operator services changes, it broadcasts a status change event through a message queue and generates a status change notification.

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

Claims

1. A smart handover method for ensuring service availability in a multi-carrier environment, characterized in that, include: The system obtains call log data from multiple operator service interfaces, performs structured storage on the call log data, and obtains a service call log recording system. Simultaneously, a service configuration library containing operator service configuration parameters is constructed. Based on the historical call data in the service call log system and the health check sample size in the service configuration library, a sliding window statistical model is used to obtain the most recent N call records of the target operator's service. Anomaly identification and performance analysis are performed on the most recent N call records to generate a comprehensive health score. Based on the comprehensive health score and the abnormal circuit breaker threshold in the service configuration library, a circuit breaker decision is executed, and the operator's service health status is output. Based on the health status of the operator services, select operator services that are in a circuit breaker state, initiate multiple simulated call requests to the operator services in the circuit breaker state, maintain a sliding window to record the detection results during the detection process, calculate the failure rate within the sliding window, terminate the remaining detection when the failure rate exceeds a preset termination threshold, and write the detection results into the service call log recording system. Based on the health status of the operator services, a list of available operator services is obtained and those in a circuit breaker state are filtered out. A target operator service is selected according to a multi-objective optimization algorithm, and a routing decision result is generated. When the health status of the operator services changes, a status change event is broadcast through a message queue to generate a status change notification.

2. The method according to claim 1, characterized in that, The process of structuring and storing the call log data to obtain a service call log recording system includes: Based on the call log data, extract the call timestamp, service provider unique identifier, HTTP response status code, business response status code, response time, calling customer account ID, request interface type, and exception information to construct data record fields; A composite index is established for the data record fields based on the service provider's unique identifier and the call timestamp. The data record fields are then persistently stored to obtain the service call log recording system. The call timestamp stored in the service call log recording system is used to retrieve the most recent N call records in reverse chronological order. The HTTP response status code and the business response status code are used for subsequent network layer anomaly identification and business layer anomaly identification. The response time is used for subsequent performance layer anomaly identification.

3. The method according to claim 1, characterized in that, The simultaneous construction of a service configuration library containing operator service configuration parameters includes: The key-value storage structure is used to store basic information about the storage provider, circuit breaker policy parameters, performance monitoring indicators, automated management identifiers, and detection configurations. Implement the data synchronization interface between the service configuration library and the service call log recording system to obtain the service configuration library.

4. The method according to claim 1, characterized in that, The method of obtaining the most recent N call records of the target operator's service using a sliding window statistical model based on historical call data in the service call log recording system and the health check sample size in the service configuration library includes: Based on a distributed task scheduling framework, a distributed lock is used to ensure the single-instance execution of the detection task in the cluster environment, and a health check task is automatically triggered every minute; For each operator service marked as allowing automatic management in the service configuration library, the most recent N call records are obtained from the service call log system in reverse order of the call timestamp, where N is equal to the health check sample size in the service configuration library. A dynamic sliding window is constructed to obtain the most recent N call records. The most recent N call records include HTTP response status code, business response status code, and response time field.

5. The method according to claim 1, characterized in that, The anomaly identification and performance analysis of the most recent N call records includes: For each call record in the most recent N call records, identify records with HTTP response status codes of 4xx or 5xx and mark them as network layer abnormal records; Based on the HTTP response status codes and business response status codes stored in the service call log system, records with an HTTP response status code of 200 but a business response status code indicating failure are identified and marked as business layer abnormal records. Based on the response time stored in the service call log system, calculate the average, median, and percentile of the response time of the most recent N call records, and mark records whose response time exceeds the upper limit of the average response time or the percentile time warning threshold in the service configuration library as performance layer abnormal records. Based on the network layer anomaly records, the service layer anomaly records, and the performance layer anomaly records, the anomaly identification results are obtained; Based on the anomaly identification results, the overall failure rate and the performance anomaly ratio are calculated to obtain the performance analysis results.

6. The method according to claim 5, characterized in that, The generation of a comprehensive health score; Based on the comprehensive health score and the abnormal circuit breaker threshold in the service configuration library, a circuit breaker decision is executed, and the operator's service health status is output, including: Based on the most recent N call records, the response time in the service call log recording system is extracted and standardized to obtain a standardized response time value; the HTTP response status code is extracted and numerically mapped; the business response status code is extracted and semantically encoded; the call timestamp is extracted to calculate periodic features; the sliding statistics of the historical failure rate are calculated based on historical call records; and the time interval features are calculated based on the call timestamps of adjacent call records to construct a multi-dimensional feature vector. The Kolmogorov-Arnold transform is applied to the projective transformation of the multidimensional feature vectors. A projective matrix is ​​constructed using orthogonal basis functions, and the multidimensional feature vectors are projected onto a low-dimensional representation space to obtain projective feature vectors. Based on the projective feature vectors of historical normal call records in the service call log system, the probability distribution of each region in the feature space is calculated to obtain the entropy distribution benchmark of the normal mode; based on the projective feature vectors within the current sliding window, the probability distribution of the current feature space is calculated to obtain the current entropy distribution; the relative entropy between the current entropy distribution and the entropy distribution benchmark of the normal mode is calculated, and when the relative entropy exceeds a preset entropy threshold, it is marked as an entropy-driven anomaly. Based on the projective feature vector, a function mapping relationship of operator service behavior is constructed. The gradient change of service quality index is calculated through automatic differentiation technology to identify key factors that cause service anomalies and their corresponding weights. Combining the network layer anomaly record, the service layer anomaly record, the performance layer anomaly record, and the entropy-driven anomaly, the anomaly detection results are mapped to a unified health score space. The complexity index of service behavior is calculated using Kolmogorov complexity theory to obtain the comprehensive health score. The overall health score is compared with the abnormal circuit breaker threshold in the service configuration library. When the overall health score is lower than the abnormal circuit breaker threshold and the "Allow automatic circuit breaker" flag in the service configuration library is true, the operator service health status is set to circuit breaker status. When the overall health score is higher than the abnormal circuit breaker threshold, the operator service health status is set to healthy status, and the operator service health status is output.

7. The method according to claim 6, characterized in that, The step of calculating the probability distribution of each region in the feature space based on the projective feature vector of historical normal call records in the service call log recording system to obtain the entropy distribution benchmark of the normal mode also includes: Based on the entropy distribution trend of historical service call data in the service call log system, the preset entropy threshold is dynamically adjusted for operator services with unique identifiers for different service providers to adapt to the service characteristics of different operators, thus obtaining an adaptive entropy threshold for each operator service; wherein, the adaptive entropy threshold is used for subsequent anomaly determination of relative entropy.

8. The method according to claim 1, characterized in that, Based on the health status of the operator services, select operator services that are in a circuit breaker state, and initiate multiple simulated call requests to the operator services in the circuit breaker state, including: Based on the distributed task scheduling framework, a probe task is automatically triggered every five minutes according to the circuit breaker simulation probe frequency in the service configuration library. The operator service health status is used to identify and filter the operator services that are currently in the circuit breaker state, and a list of circuit breaker service providers is obtained. For each operator service in the circuit breaker service provider list, standardized simulated request parameters are generated using the request address, interface version, and key information of the corresponding service provider ID in the service configuration library. The probe counter is initialized, the request timeout is configured, and M simulated call requests are initiated based on the number of single probe requests M in the service configuration library.

9. The method according to claim 1, characterized in that, The process of maintaining a sliding window to record detection results during the detection process, calculating the failure rate within the sliding window, terminating the remaining detection when the failure rate exceeds a preset termination threshold, and writing the detection results into the service call log recording system includes: Based on the historical call data of the operator's services under the circuit breaker status, the call timestamp and response time are extracted to construct a time series feature to obtain a time view; the HTTP response status code and business response status code are extracted to analyze error types and distribution to construct an error view; the request interface type and calling customer account ID are analyzed to construct a dependency view; and the regional performance mode is identified based on the regional attributes in the service provider's basic information to construct a regional view, thus obtaining a multi-dimensional service status view. For each view in the multidimensional service status view, a dedicated evolutionary subpopulation is constructed. Within the evolutionary subpopulation, a genetic programming method is used to generate a detection program. The detection strategy exchange between subpopulations is realized through a knowledge sharing protocol to obtain a co-evolving detection strategy set. Based on the co-evolutionary detection strategy set, a lightweight, rapid detection is performed to verify the network connectivity and basic response capabilities of the service, yielding rapid detection results. When the rapid detection results indicate that the service is basically available, a medium-level in-depth detection is performed to verify the functional integrity and performance indicators of the service, yielding medium-level detection results. When the medium-level detection results indicate that key functions are normal and performance indicators meet the average response time upper limit in the service configuration library, a comprehensive in-depth detection is performed to evaluate the stability and reliability of the service, yielding comprehensive detection results. During the detection process, a sliding window of size K is maintained to record the K most recent detection results, and the failure rate within the sliding window is calculated based on the HTTP response status code and business response status code in the detection results. By comprehensively analyzing the real-time detection results of the corresponding subpopulations in the time view, error view, dependency view, and regional view, a unified decision to continue or terminate the detection is generated using majority voting or weighted average methods. When the failure rate within the sliding window exceeds the detection termination threshold in the service configuration library, the remaining detection is terminated, and the detection results, including the detection timestamp, service provider unique identifier, HTTP response status code, business response status code, and response time, are written to the service call log recording system.

10. The method according to claim 9, characterized in that, The step of performing lightweight, rapid detection and verification of network connectivity and basic response capabilities of the service based on the co-evolutionary detection strategy set, and obtaining rapid detection results, includes: Based on the lightweight detection strategy in the aforementioned co-evolutionary detection strategy set, a low-cost detection request is initiated according to the request address corresponding to the service provider ID in the service configuration library. The network connectivity of the service is verified by sending a basic connectivity test message, and the basic response capability of the service is verified by calling the service's health check interface. The HTTP response status code and response time of the detection response are recorded to obtain the fast detection result. The fast detection result is used to determine whether to perform a medium-depth detection.

11. The method according to claim 1, characterized in that, The process of obtaining a list of available operator services based on the operator service health status, filtering operator services in a circuit breaker state, selecting a target operator service according to a multi-objective optimization algorithm, and generating a routing decision result includes: The optimization objectives are defined as minimizing service response time, maximizing service success rate, optimizing cost-effectiveness ratio, and balancing load distribution. The constraints are established as service quality baseline requirements, operator call quota limits, specific business scenario requirements, and system resource usage limits, resulting in a multi-objective decision-making framework. The system constructs a performance-priority population to minimize service response time, a stability-priority population to maximize service success rate, and a balanced population to balance all optimization objectives. This enables elite individual migration strategies, cross-population crossover operations, and shared fitness evaluation results, resulting in a multi-population population architecture. Based on the multi-objective decision-making framework and the multi-population architecture, weight coefficients are set for each optimization objective, and a weighted summation fitness function is constructed. For each decision-making individual in the multi-population architecture, its performance value on the service response time target is calculated based on the historical response time recorded in the service call log system; its performance value on the service success rate target is calculated based on the success rate in the historical call records; its performance value on the cost-effectiveness target is calculated based on the cost information in the service configuration library; and its performance value on the load distribution target is calculated based on the current call frequency of each operator's services. The weighted summation fitness function is used to calculate the comprehensive fitness value. It is then checked whether the decision-making individual violates the constraints, and the constraint violation degree is calculated and added as a penalty to the comprehensive fitness value. Based on the actual response time, success rate, cost, and load distribution data of the decision-making individual recorded in the service call log system during the historical execution process, the mean and variance of the historical performance are calculated to obtain long-term stability indicators and reliability indicators. The long-term stability indicators and the reliability indicators are then integrated into the comprehensive fitness value to obtain the fitness evaluation result. Based on the fitness assessment results, the mutation rate is dynamically adjusted according to the current population diversity. Individual selection is carried out using tournament selection or roulette wheel selection methods to retain the best individual. Evolutionary iteration is then performed to obtain the optimal routing decision individual. The optimal routing decision individual is converted into a weighted list of operator call priorities. Based on the operator service health status, operator services in circuit breaker state are filtered out. The target operator service is selected according to the operator call priority list to obtain the routing decision result. The routing decision result includes the selected service provider ID and the corresponding call weight.

12. The method according to claim 11, characterized in that, The step of setting weight coefficients for each optimization objective and constructing a weighted summation fitness function based on the multi-objective decision-making framework and the multi-population architecture further includes: Based on the execution results of historical routing decisions in the service call log system, the deviation data between the predicted response time and the actual response time, the deviation data between the predicted success rate and the actual success rate are collected during decision execution, and the deviation data between the predicted performance and the actual performance are calculated. The weight coefficients in the weighted summation fitness function are adjusted based on the deviation data to obtain the updated weighted summation fitness function.

13. The method according to claim 1, characterized in that, The step of obtaining a list of available operator services based on the operator service health status, filtering operator services in a circuit breaker state, selecting a target operator service according to a multi-objective optimization algorithm, and generating a routing decision result further includes: When the health status of the operator services shows that all operator services are in a circuit breaker state, query the local cache to obtain historical response data or return a preset default value, and generate a downgrade response result. The degradation event is recorded, including the degradation trigger time, degradation reason, and impact scope. A degradation notification is sent through a high-priority alarm channel to obtain the degradation policy execution record. The degradation policy execution record is written to the service call log recording system for subsequent analysis and alarms.

14. The method according to claim 1, characterized in that, When the health status of the operator's service changes, the status change event is broadcast through a message queue, and a status change notification is generated, including: When the operator's service health status changes from healthy to circuit breaker status or from circuit breaker status to healthy status, a status change event is constructed, which includes the service provider identifier, the status before the change, the status after the change, the change time, and the reason for the change based on the comprehensive health score or the detection result. The status change event is published to a message queue, and a status change notification is sent via email, SMS or instant messaging tools. Based on the importance level of the operator's service in the service configuration library and the current time, determine whether to trigger a telephone alarm, generate a detailed status change report including the reason for the change, the time of the change, and the scope of impact, and obtain the status change notification.

15. An intelligent handover system for ensuring service availability in a multi-carrier environment, characterized in that, include: The log storage module is used to acquire call log data from multiple operator service interfaces, and to perform structured storage on the call log data to obtain a service call log recording system. Simultaneously, a service configuration library containing operator service configuration parameters is constructed. The health detection module is used to obtain the most recent N call records of the target operator's service based on the historical call data in the service call log system and the health check sample size in the service configuration library, using a sliding window statistical model, and to perform anomaly identification and performance analysis on the most recent N call records to generate a comprehensive health score. Based on the comprehensive health score and the abnormal circuit breaker threshold in the service configuration library, a circuit breaker decision is executed, and the operator's service health status is output. The service detection module is used to filter operator services in circuit breaker state according to the operator service health status, initiate multiple simulated call requests to the operator services in circuit breaker state, maintain a sliding window to record the detection results during the detection process, calculate the failure rate within the sliding window, terminate the remaining detection when the failure rate exceeds a preset termination threshold, and write the detection results to the service call log recording system. The routing decision module is used to obtain a list of available operator services based on the health status of the operator services and filter operator services that are in a circuit breaker state, select a target operator service according to a multi-objective optimization algorithm, and generate a routing decision result; when the health status of the operator services changes, it broadcasts a status change event through a message queue and generates a status change notification.

Images