A microservice single-instance fault resilience traffic switching method

Abstract

The present application belongs to the technical field of micro-service governance, service routing control, fault isolation and traffic recovery control, and particularly relates to a micro-service single-instance fault resilience traffic switching method, wherein the registration metadata of the micro-service instance and the routing attempt time sequence record when the load balancing is selected are obtained; the risk evidence window aggregation operation according to the target instance dimension is performed to construct a risk feature vector facing a single instance; a risk state machine judgment model of a fusion state hysteresis mechanism is constructed to output the initial judgment result of the instance migration from a normal state to an observation state, a high-risk state and a recovery observation state; the rule version, the effective time and the expiration time multi-source constraint data are fused through the gateway local rule table to correct the execution deviation caused by rule disorder or replay, generate a standardized execution record and push it to the micro-service governance terminal. Thus, the problems of not realizing full-link unification and fault governance lag in the prior art are solved.

Description

Technical Field

[0001] This invention belongs to the technical fields of microservice governance, service routing control, fault isolation and traffic recovery control, and specifically relates to a method for fault-resistant traffic switching of a single microservice instance. Background Technology

[0002] In microservice production environments, existing mainstream governance technologies rely on health check probes, service-level circuit breakers, rate limiting, degradation, automatic removal of registry instances, service mesh traffic policies, manual routing control, and random proportional canary recovery to achieve service-level fault protection, traffic scheduling and control, basic isolation of abnormal instances, and large-scale instance recovery. These technologies can effectively address scenarios such as overall service unavailability, large-scale instance downtime, cluster-level traffic overload, and abnormal fluctuations at the interface level, ensuring the overall availability of the microservice system, supporting stable forwarding of regular business traffic, and ensuring the basic smoothness of service call links. They also meet the basic operation and maintenance, fault fallback, and business continuity assurance needs of large-scale service clusters.

[0003] Existing technologies struggle to accurately handle resilient traffic switching in the event of localized anomalies in single instances. Key shortcomings include: instance identification lacks integration of lifecycle information and end-to-end consistency; monitoring and identification objects cannot be accurately mapped to gateway routing execution objects; old rules may inadvertently harm new instances during instance reconstruction, container restarts, and IP reuse scenarios; routing attempt recording is delayed, failing to record immediately after instance selection in load balancing, making it impossible to attribute retry links sequentially, and abnormal instances are easily masked by subsequent successful results; risk assessment uses service-level coarse-grained aggregation statistics, not calculating with the target instance as the core dimension, making it susceptible to misjudgments due to network jitter and traffic skew; governance rules lack version and time boundary constraints, leading to rule disorder and execution errors due to replay; fault management actions are delayed, failing to remove high-risk instances in the pre-load balancing candidate set stage, causing business jitter as abnormal instances continue to receive traffic; and instance recovery uses a purely random release method, resulting in random drift in routing results and making stable observation of recovery effects difficult. Summary of the Invention

[0004] This application provides a method for fault-resistant traffic switching of a single microservice instance to solve the problems of lack of end-to-end uniformity and delayed fault management actions in the prior art.

[0005] The first aspect of this application provides a method for fault-resistant traffic switching of a single microservice instance, comprising the following steps: obtaining the registration metadata of the microservice instance and the routing attempt time sequence record when the load balancer is selected; performing a risk evidence window aggregation operation on the routing attempt time sequence record by the target instance dimension to extract the instance's timeout rate, anomaly rate, latency distribution, and consecutive timeout count, and constructing a risk feature vector for a single instance; constructing an instance risk state machine judgment model that integrates a state hysteresis mechanism, inputting the feature vector into the instance risk state machine judgment model, and outputting the initial judgment result of the instance migrating from the normal state to the observation state, the high-risk state, and the recovery observation state; performing execution layer optimization on the initial judgment result based on versioned rule semantics and time boundaries, integrating multi-source constraint data of rule version, effective time, and expiration time through the gateway's local rule table to correct execution deviations caused by rule disorder or replay, and quantitatively eliminating high-risk instances and diverting recovery observation instances in the pre-filtering stage of the load balancer candidate set according to the corrected rule data, and calculating the recovery release threshold based on deterministic hashing, generating standardized execution records and pushing them to the microservice governance terminal.

[0006] Preferably, obtaining the registration metadata of the microservice instance and the routing attempt sequence record when the load balancer is selected includes: obtaining the full lifecycle registration metadata of the microservice instance and the real-time call data of the load balancer node; based on the real-time call data, at the key time point when the load balancer completes instance selection but the business request has not yet been sent out, locking the unique identifier of the target instance corresponding to this call, and synchronously recording the request's globally unique identifier, call attempt sequence number, source service instance identifier, target service identifier, and instance selection timestamp of all basic routing information; according to the basic routing information, after the request completes a normal response, a call exception occurs, or a timeout is triggered, the response status code, business return code, end-to-end response latency, timeout flag, exception type, and request completion timestamp are successively filled in to generate a complete routing attempt sequence record that covers the entire retry link of a single request and can be traced and attributed step by step.

[0007] Preferably, the risk evidence window aggregation operation is performed on the routing attempt time-series records by the target instance dimension, including: constructing a sliding risk evidence statistical window with the target instance as the core; based on the statistical window, using the service identifier and the target instance identifier as the joint statistical dimension, performing multi-dimensional index aggregation calculations on the time-series records for call sample size, timeout count, anomaly count, latency quantile, and consecutive failure count, and simultaneously performing dual compliance checks on the minimum statistical sample threshold and the minimum source instance number threshold to obtain the check results; based on the check results, filtering out invalid noise data caused by occasional network jitter, single caller anomalies, and instantaneous traffic skew, and selecting core risk indicators that can truly reflect the instance's operating status, such as timeout rate, anomaly rate, high latency, and consecutive timeout, to generate a standardized, highly discriminative single-instance risk feature vector.

[0008] Preferably, an instance risk state machine determination model with a fusion state hysteresis mechanism is constructed. The feature vector is input into the instance risk state machine determination model, and the initial determination results of instance migration from normal state to observation state, high-risk state, and recovery observation state are output. This includes: constructing an instance risk state machine determination model with a fusion state hysteresis mechanism; based on the instance risk state machine determination model and the single instance risk feature vector, performing multi-round continuous sliding statistical window index comparison, hysteresis threshold verification, and risk level progressive determination to avoid frequent jittering of instance state in critical intervals, generating instance state migration verification analysis data; and matching preset instance state switching governance rules according to the instance state migration verification analysis data, outputting initial determination results of ordered migration of multiple instance states that conform to cluster fault governance standards and can directly drive rule generation.

[0009] Preferably, the initial judgment result is optimized at the execution layer based on versioned rule semantics and time boundaries, including: constructing an instance governance rule dataset with version and time boundaries; performing a dual check on the gateway side for the monotonically increasing rule version and the legality of the effective time on the instance governance rule dataset, identifying out-of-order, expired, and replay invalid rules, and generating a rule time validity verification conclusion; filtering abnormal invalid rules and correcting time execution deviations according to the rule time validity verification conclusion, and generating high-precision executable rule data that is adapted to gateway deployment and has accurate time.

[0010] Preferably, the pre-filtering stage of the load balancing candidate set involves quantitatively eliminating high-risk instances and traffic diversion recovery observation instances, including: constructing a hierarchical classification filtering framework for load balancing candidate instances; based on the hierarchical classification filtering framework, performing unified identifier matching, governance rule mapping, and operational status determination on candidate instances to distinguish between normal, high-risk, and recovery observation instances, generating candidate instance status classification results; and, based on the candidate instance status classification results, completely eliminating high-risk instances and isolating traffic diversion recovery observation instances, retaining only normal instances to participate in regular traffic scheduling, thus completing the precise pre-filtering of the candidate set.

[0011] A second aspect of this application provides a microservice single-instance fault-resistant traffic switching system, comprising: time-series data acquisition, used to acquire registration metadata of the microservice instance and routing attempt time-series records when load balancing is selected; risk feature extraction, used to perform risk evidence window aggregation operations on the routing attempt time-series records at the target instance level, extracting the instance's timeout rate, anomaly rate, latency distribution, and consecutive timeout count, and constructing a risk feature vector oriented towards a single instance; and risk state determination, used to construct an instance risk state machine determination model that integrates a state hysteresis mechanism, and input the feature vector into the instance risk state machine determination. The model outputs initial judgment results of instance migration from normal state to observation state, high-risk state, and recovery observation state; resilient traffic switching is used to optimize the initial judgment results at the execution layer based on versioned rule semantics and time boundaries. It integrates multi-source constraint data such as rule version, effective time, and expiration time through the gateway's local rule table to correct execution deviations caused by rule disorder or replay. Based on the corrected rule data, it quantitatively removes high-risk instances and diverts recovery observation instances during the pre-filtering stage of the load balancing candidate set. It also calculates the recovery release threshold based on deterministic hashing, generates standardized execution records, and pushes them to the microservice governance terminal.

[0012] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement a microservice single-instance fault-resistant traffic switching method as described in the above embodiments.

[0013] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement a microservice single-instance fault-resistant traffic switching method as described in the above embodiments.

[0014] The fifth aspect of this application provides a computer program product, including a computer program or instructions, for implementing a microservice single-instance fault-resistant traffic switching method as described in the above embodiments.

[0015] Therefore, this application includes the following beneficial effects: It accurately quantifies the timeout, anomaly, latency, and continuous failure characteristics of a single instance by aggregating risk evidence windows at the instance level; it achieves smooth transition judgment across multiple states (normal, observation, high-risk, and recovery observation) using a risk state machine with a state hysteresis mechanism; it optimizes the judgment results through versioned rule semantics and time boundary constraints; it effectively solves the execution deviation problems caused by rule disorder and replay by relying on the gateway's local rule table; it proactively removes high-risk failure instances during the pre-filtering stage of the load balancing candidate set and performs controllable traffic distribution for recovery observation instances; and it achieves gradual and smooth recovery by calculating the recovery volume threshold value through a deterministic hash algorithm. Finally, it forms standardized execution records for visualized governance reporting, accurately identifying hidden faults in microservice single instances, achieving resilient traffic switching without jitter, effectively preventing the avalanche propagation of failure instances, improving traffic switching stability, rule execution consistency, and instance recovery controllability, and comprehensively enhancing the resilience of microservice operation and the traceability of fault governance. Thus, it solves the problems of lack of end-to-end unification and delayed fault governance actions in existing technologies.

[0016] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0017] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating a microservice single-instance fault-resistant traffic switching method according to an embodiment of this application. Figure 2 This is a system architecture diagram provided according to one embodiment of the present application; Figure 3 To generate and write a path graph for a unified instance identifier provided in one embodiment of this application; Figure 4 This is a successive attribution timing diagram of multiple routing attempts provided according to an embodiment of this application; Figure 5 This is a schematic diagram of an example rule structure provided according to an embodiment of this application; Figure 6 This is a diagram illustrating the candidate instance pre-filtering and pooling process provided according to one embodiment of this application; Figure 7 This is a recovery period deterministic volume increase determination chart according to one embodiment of this application; Figure 8 This is a schematic diagram of the structure of a microservice single-instance fault-resistant traffic switching system according to an embodiment of this application; Figure 9This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0018] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0019] The following describes a microservice single-instance fault-resistant traffic switching method according to an embodiment of this application, with reference to the accompanying drawings. Addressing the issue of delayed fault management actions mentioned in the background art, this application provides a microservice single-instance fault-resistant traffic switching method. In this method, risk evidence windows aggregated at the instance level accurately quantify the characteristics of single-instance timeouts, anomalies, latency, and continuous faults. A risk state machine with a state hysteresis mechanism is used to smoothly determine the transition between multiple states of the instance: normal, observation, high-risk, and recovery observation. Simultaneously, versioned rule semantics and time boundary constraints optimize the determination results. The gateway's local rule table effectively solves the execution deviation problems caused by rule disorder and replay. High-risk fault instances are proactively removed during the pre-filtering stage of the load balancing candidate set, and recovery observation instances are controllably distributed. A deterministic hash algorithm is used to calculate the recovery volume threshold to achieve gradual and smooth recovery. Finally, standardized execution records are generated for visualized governance reporting. This method can accurately identify hidden faults in microservice single instances, achieve jitter-free resilient traffic switching, effectively prevent the avalanche propagation of fault instances, improve traffic switching stability, rule execution consistency, and instance recovery controllability, and comprehensively enhance the resilience of microservice operation and the traceability of fault management. This solves the problems of lack of end-to-end unification and delayed fault management in existing technologies.

[0020] Specifically, Figure 1 This application provides a method for fault-resistant traffic switching of a single microservice instance.

[0021] like Figure 1 As shown, this method for fault-tolerant traffic switching of a single microservice instance includes the following steps: In step S101, the registration metadata of the microservice instance and the timing record of the route attempt when the load balancer is selected are obtained.

[0022] It is understood that the registered metadata in this application embodiment can clearly define the basic information of the entire lifecycle of the microservice instance. The routing attempt time sequence record forms a complete record covering the entire retry link of a single request by locking the target instance identifier, recording all basic routing information and backfilling request and response data. This can not only filter out invalid noise data such as occasional network jitter, but also provide real and traceable original data for subsequent risk feature vector construction, instance risk status determination and execution layer rule optimization, ensuring accurate identification of faulty instances and scientific and reasonable traffic switching, and laying a solid data foundation for the fault resilience governance of microservice single instances.

[0023] In this embodiment, obtaining the registration metadata of a microservice instance and the routing attempt sequence record when the load balancer is selected includes: obtaining the full lifecycle registration metadata of the microservice instance and the real-time call data of the load balancer node; based on the real-time call data, at key time points when the load balancer completes instance selection but the business request has not yet been sent out, locking the unique identifier of the target instance corresponding to this call, and synchronously recording the request's globally unique identifier, call attempt sequence number, source service instance identifier, target service identifier, and instance selection timestamp of all basic routing information; based on the basic routing information, after the request completes a normal response, a call exception occurs, or a timeout is triggered, sequentially backfilling the response status code, business return code, end-to-end response latency, timeout flag, exception type, and request completion timestamp, generating a complete routing attempt sequence record that covers the entire retry chain of a single request and can be traced and attributed sequentially.

[0024] Among them, the route attempt time sequence record refers to the log information of each attempt of network data packets in the route selection process, including the path, result, and corresponding time point, recorded in chronological order.

[0025] It is understood that the embodiments of this application provide accurate and traceable raw data support for microservice single-instance fault identification and traffic switching. At the critical time point when the load balancer has completed instance selection and the business request has not yet been sent out, it locks the unique identifier of the target instance and synchronously records the global unique identifier of the request, the call attempt sequence number, the source service instance identifier, the target service identifier, and the instance selection timestamp of all basic routing information. It also synchronously collects key data such as response status code, business return code, end-to-end response latency, timeout flag, exception type, and request completion timestamp, forming a complete record covering the entire retry link of a single request. This can effectively filter invalid noise data caused by occasional network jitter, single caller anomalies, and instantaneous traffic skew, ensuring the accuracy of subsequent risk indicator aggregation. It can also provide real and traceable data basis for risk feature vector construction, instance risk state machine determination, and execution layer rule optimization, helping to accurately identify high-risk instances, scientifically formulate traffic diversion and recovery strategies, and ensure traffic resilience and stable system operation when a microservice single instance fails.

[0026] In step S102, a risk evidence window aggregation operation is performed on the routing attempt time sequence record by the target instance dimension to extract the instance's timeout rate, anomaly rate, latency distribution, and number of consecutive timeouts, and to construct a risk feature vector for a single instance.

[0027] Risk evidence window aggregation refers to the process of systematically integrating and overlaying multiple scattered risk evidence fragments within a specific time or space range to form a more complete risk identification and assessment conclusion.

[0028] It is understood that the risk evidence window aggregation in this application embodiment can construct a sliding statistical window with the target instance as the statistical core, and perform multi-dimensional operation index aggregation calculation on the routing attempt time sequence record in combination with dual compliance verification. It can eliminate invalid noise data caused by occasional network jitter, single caller anomaly, and instantaneous traffic skew, accurately extract the instance's real timeout rate, anomaly rate, high latency, and number of consecutive timeouts, and generate a standardized and highly distinguishable single instance risk feature vector. This provides reliable quantitative data support for subsequent instance risk state machine migration judgment, effectively reduces the probability of fault misidentification and omission, and ensures accurate and stable single instance risk state judgment.

[0029] In this embodiment, risk evidence window aggregation operations are performed on the routing attempt time-series records by target instance dimension, including: constructing a sliding risk evidence statistical window with the target instance as the core; based on the statistical window, using service identifier and target instance identifier as joint statistical dimensions, performing multi-dimensional index aggregation calculations on the time-series records for call sample size, timeout count, anomaly count, latency quantile, and consecutive failure count, and simultaneously performing dual compliance checks on the minimum statistical sample threshold and the minimum source instance number threshold to obtain the check results; based on the check results, filtering out invalid noise data caused by occasional network jitter, single caller anomalies, and instantaneous traffic skew, and selecting core risk indicators that can truly reflect the instance's operating status, such as timeout rate, anomaly rate, high latency, and consecutive timeout, to generate a standardized, highly discriminative single-instance risk feature vector.

[0030] Among them, sporadic network jitter refers to infrequent, short-term fluctuations in delay or packet loss during network transmission. It usually does not affect overall connectivity but will momentarily reduce communication quality.

[0031] It is understood that the filtering of occasional network jitter in this application embodiment can eliminate false abnormal data generated by instantaneous temporary network fluctuations, avoid temporary fluctuations that are not due to instance faults interfering with the statistical results of risk indicators, and ensure that timeout rate, anomaly rate, high latency, and consecutive timeout counts all accurately reflect the true operational health status of the instance, improve the authenticity and distinguishability of the single instance risk feature vector, prevent the instance risk state machine from being falsely triggered or falsely migrated, and ensure the accurate and stable execution of subsequent instance risk level determination and traffic switching strategies.

[0032] In step S103, an instance risk state machine determination model with a fusion state hysteresis mechanism is constructed. The feature vector is input into the instance risk state machine determination model, and the initial determination results of the instance's migration from the normal state to the observation state, the high-risk state, and the recovery observation state are output.

[0033] Among them, the instance risk state machine determination model is a computational model that dynamically assesses and transforms the real-time risk level of a specific business instance by defining different risk states and transition rules between states.

[0034] It is understood that the instance risk state machine judgment model that integrates the state hysteresis mechanism in the embodiments of this application can complete multiple rounds of continuous sliding window index comparison, hysteresis threshold verification and risk level progressive judgment based on the single instance risk feature vector. This effectively avoids frequent jittering and jumping of instance running state in critical intervals, standardizes the orderly state migration of instances in normal state, observation state, high-risk state and recovery observation state, and outputs stable judgment conclusions that adapt to the requirements of cluster fault governance. This provides reliable and unified decision support for subsequent execution layer rule optimization, high-risk instance removal and recovery observation instance diversion scheduling, and ensures that the traffic switching strategy is stable, controllable and not blindly triggered.

[0035] In this embodiment, an instance risk state machine determination model with a fusion state hysteresis mechanism is constructed. Feature vectors are input into the instance risk state machine determination model, and initial determination results of instance migration from normal state to observation state, high-risk state, and recovered observation state are output. This includes: constructing an instance risk state machine determination model with a fusion state hysteresis mechanism; performing multi-round continuous sliding statistical window index comparison, hysteresis threshold verification, and progressive risk level determination based on the instance risk state machine determination model and single-instance risk feature vectors to avoid frequent instance state fluctuations in the critical interval, generating instance state migration verification analysis data; and matching preset instance state switching governance rules with the instance state migration verification analysis data to output initial determination results of ordered multi-state migration of instances that conform to cluster fault governance standards and can directly drive rule generation.

[0036] Among them, the cluster fault management standard refers to a standardized process and technical measurement system established to ensure the high availability and stability of distributed cluster systems, covering aspects such as fault prevention, detection, isolation, recovery, and review.

[0037] It is understood that the implementation of this application follows the cluster fault management standard, which can unify and standardize the judgment boundary, handling logic and execution requirements of the orderly migration of multi-state instances, unify the governance behavior of high-risk instance isolation, observation instance control and recovery instance release, avoid the cluster governance behavior caused by each gateway node making independent and arbitrary judgments and switches, ensure the overall fault handling strategy of the microservice cluster is coordinated and consistent, effectively prevent the abnormal spread of local instances from causing cluster avalanche failure, and make the overall traffic resilience switching governance orderly and controllable, in line with the requirements of global stable operation.

[0038] In step S104, the initial judgment result is optimized at the execution layer based on the semantics and time boundaries of the versioned rules. The rule version, effective time and expiration time of the rule are integrated into the local rule table of the gateway to correct the execution deviation caused by rule disorder or replay. Based on the corrected rule data, high-risk instances are quantitatively removed and observation instances are distributed and restored in the pre-filtering stage of the load balancing candidate set. The recovery release threshold is calculated based on deterministic hashing, and standardized execution records are generated and pushed to the microservice governance terminal.

[0039] The gateway local rule table is a set of custom policies stored in the gateway device, used to control local processing behaviors such as packet filtering, forwarding, address translation, or access permissions.

[0040] It is understood that the gateway local rule table in this application embodiment can integrate multi-source constraint data such as rule version, effective time, and expiration time to correct execution deviations caused by rule disorder or replay on the spot. In the pre-filtering stage of the load balancing candidate set, it can quickly complete the quantitative elimination of high-risk instances and the traffic diversion scheduling of observation instances locally. Simultaneously, it calculates the recovery release threshold based on deterministic hashing and generates standardized execution records to be pushed to the microservice governance terminal. It can ensure the uniformity of execution logic of each gateway node without relying on remote rule synchronization, effectively improve the real-time response speed of traffic switching, avoid scheduling errors caused by asynchronous delays of remote rules, and ensure efficient, accurate, and stable execution of fault-resistant traffic switching.

[0041] In this embodiment, the initial judgment result is optimized at the execution layer based on versioned rule semantics and time boundaries, including: constructing an instance governance rule dataset with version and time boundaries; performing a dual check on the gateway side for the monotonically increasing rule version and the legality of the effective time on the instance governance rule dataset, identifying out-of-order, expired, and replay invalid rules, and generating a rule time validity verification conclusion; filtering abnormal invalid rules and correcting time execution deviations according to the rule time validity verification conclusion, and generating high-precision executable rule data that is adapted to gateway deployment and has accurate time.

[0042] Among them, the instance governance rule dataset refers to the collection of governance rules defined for instances in a specific system or platform.

[0043] It is understood that the instance governance rule dataset in this application embodiment comes with rule version and time-series boundary attributes, which can provide a unified data basis for the monotonically increasing verification of the rule version on the gateway side and the dual verification of the validity of the effective time. It can accurately identify invalid rules such as out-of-order, expired, and replay, filter abnormal invalid rules and correct time-series execution deviations, and output high-precision executable rules with accurate time-series and adapted to the actual operation of the gateway. It can uniformly standardize the execution logic of instance isolation, traffic splitting, and recovery of traffic on the gateway side, avoid the problem of inconsistent rule execution on multiple nodes, and ensure that the traffic resilience switching time-series is compliant and the scheduling is accurate and controllable.

[0044] In this embodiment, the quantitative elimination of high-risk instances and traffic recovery observation instances during the pre-filtering stage of the load balancing candidate set includes: constructing a hierarchical classification filtering framework for load balancing candidate instances; based on the hierarchical classification filtering framework, performing unified identifier matching, governance rule mapping, and operational status determination on candidate instances to distinguish between normal, high-risk, and recovery observation instances, generating candidate instance status classification results; and based on the candidate instance status classification results, completely eliminating high-risk instances and isolating traffic recovery observation instances, retaining only normal instances to participate in regular traffic scheduling, thus completing the precise pre-filtering of the candidate set.

[0045] Among them, governance rule mapping refers to establishing a clear correspondence between abstract governance principles, regulations or policy requirements and specific management objects, operating procedures or technical control measures.

[0046] It is understood that the governance rule mapping in this application embodiment can accurately match and bind the real-time running status of instances with preset hierarchical handling strategies, realize the automatic matching and association of the three types of instance statuses (normal, high-risk, and recovery observation) with instance removal, isolation and diversion, and routine scheduling governance actions, unify the execution logic of the pre-filtering stage of the load balancing candidate set, avoid the problems of mismatch and inconsistent execution of handling strategies of different gateway nodes, and automatically complete the hierarchical handling of instances without manual intervention, ensuring that high-risk instances are completely isolated, recovery observation instances are reasonably diverted, and normal instances are stably scheduled, thereby improving the standardization, automation and accuracy of traffic pre-filtering.

[0047] The following will illustrate a method for fault-tolerant traffic switching of a single microservice instance through a specific embodiment, including: In a distributed microservice cluster architecture, a core business service is deployed in a multi-instance mode on a containerized scheduling platform. This service provides high-concurrency online transaction processing capabilities. Twelve peer service instances run stably within the cluster, typically handling a peak of 3500 business requests per second. Requests are processed through a unified access gateway for service discovery, load balancing, and traffic forwarding. The overall system architecture is as follows: Figure 2 As shown.

[0048] Service requests initiated by consumers first enter the gateway client load balancer. The gateway obtains full candidate instance metadata for the target service from the registry center through service discovery. After selecting an instance, it forwards the request to the target service instance cluster. Simultaneously, the routing record module collects end-to-end routing attempt information. The risk assessment module determines the risk status of a single instance based on the instance metadata from the registry center and the successive attribution results from the routing record module. Finally, the rule distribution module pushes versioned governance rules to the gateway's local rule table, providing an execution basis for the gateway's candidate instance filtering. To address the issues of inconsistent governance objects across modules and rule mismatches caused by instance lifecycle changes, all service instances in the cluster generate a unified instance ID (instanceId) with full lifecycle information through the instance ID generation module during startup and before completing registration with the registry center. The generation logic is as follows: Figure 3 As shown.

[0049] The instance identifier generation module extracts seven core fields corresponding to the instance: namespace, service identifier (serviceId), workload identifier (workloadId), pod unique identifier (UID), container name, container startup timestamp, and container restart sequence number. These fields are concatenated in a globally unified, fixed order within the system to generate the original instance string. A fixed-length hash transformation then generates a 32-bit unique instanceId. This instanceId not only uniquely distinguishes different running instances under the same service but also differentiates running entities of the same workload generated under different scheduling cycles and restart counts through built-in lifecycle fields. This avoids conflicts between old and new instance identifiers caused by pod rebuilds, container restarts, and IP address reuse. The generated instanceId is synchronously written to the instance metadata field in the registry center. a.instanceId is simultaneously written to the instance's local process context, call context, and log context. This ensures that the candidate instance objects returned by the registry center, the target instances recorded in the call chain, the statistical objects of the risk assessment module, and the execution objects of the gateway rules can all be accurately associated across the entire chain through this unique instanceId. This achieves seamless coverage of the entire process of instance identification, recording, assessment, and execution using the same instanceId. During daily business operations, every time the gateway receives a business request, it first retrieves all 12 candidate instances of the target service from the registry center and executes the load balancing instance selection logic. At the critical time point where instance selection is completed but the business request has not yet been actually sent to the target instance, the routing recording module immediately generates a complete route attempt record (routeAttempt). The timing logic of this recording process is as follows: Figure 4As shown, for each business request carrying a globally unique requestId, the routing record module immediately locks the targetInstanceId that was hit in this attempt after the initial instance selection is completed. It synchronously records core basic information such as requestId, attemptIndex (marking this as the first attempt), serviceId, sourceInstanceId, and selectTime. After the request completes, triggers an exception, or times out, it backfills the response status code, business return code, end-to-end latency, timeout flag, completion timestamp, and other result fields into the same routeAttempt record. If the first request triggers a timeout or an exception, the system automatically initiates a retry. Each retry generates a new attemptIndex, corresponding to an independent routeAttempt record, which is bound to the targetInstanceId that was hit in the retry. This ensures that every routing attempt in the entire chain of a single request can be accurately attributed to the corresponding target instance, and there will be no problem of the successful retry masking the first abnormal instance.

[0050] During operation, one instance of this core service experienced disk I / O jitter on the underlying host machine, causing a continuous increase in the queue length of the business processing thread pool within the instance. This resulted in a significant increase in single-request processing latency and a large number of timeout requests. However, the instance's TCP and HTTP health probes continued to respond normally and were not automatically removed by the registry center, remaining in the gateway's candidate instance set. In the first 10-second sliding statistics window after the failure, this instance handled a total of 2890 business requests, of which 1177 timed out, resulting in a timeout rate of 40.73%. The P99 response latency reached 1850ms, far exceeding the overall service's P99 latency baseline of 120ms, and the anomaly rate reached 38.14%. The remaining 11 healthy instances of the service had an average timeout rate of only 0.23% and an average P99 latency of 112ms. During this process, a large number of requests that initially hit the abnormal instance triggered a 1500ms timeout and were automatically retried to other healthy instances, successfully completing the response. According to traditional service-level statistics, such requests would only be recorded as a single successful call, and the failure behavior of the abnormal instance would be masked by the high success rate of the overall service. However, under the routing recording mechanism of this method, each timed-out request that initially hit the abnormal instance is independently recorded in the corresponding `targetInstanceId`'s `routeAttempt`, and will not be overwritten by subsequent successful retry results, ensuring that the abnormal behavior of the faulty instance is not obscured. Complete and accurate data collection is achieved through a risk assessment module that uses serviceId and targetInstanceId as a joint dimension to maintain an independent sliding risk evidence window for each instance. This window continuously tracks key metrics such as the number of call samples, timeout rate, anomaly rate, P99 latency, consecutive timeouts, and the number of duplicate source instances. A dual verification rule is implemented: a minimum sample threshold M=200 and a minimum source instance threshold Q=5. Instance status progression is only allowed when both the number of samples and the number of source instances in the statistical window meet the threshold requirements. This prevents misjudgments caused by occasional fluctuations or single-caller anomalies. For such an abnormal instance, the initial statistical window must contain at least 2890 samples. 200, the number of duplicate instances from the source is 18≥5, meeting the threshold verification requirements. The instance state switches from NORMAL to OBSERVE. Within the subsequent three consecutive 10-second sliding windows, the instance's timeout rate remains above 35%, and the P99 latency consistently exceeds 1500ms, continuously meeting the high-risk judgment threshold. After the risk state machine completes the hysteresis verification, the instance state switches from OBSERVE to HIGH_RISK, generating the initial judgment result for the instance state transition. When an instance is judged to be in the HIGH_RISK state, the system does not only generate monitoring alarms but also directly generates versioned exclusion rules for that instance based on the instance state transition result. The rule structure is as follows: Figure 5 As shown.

[0051] A single rule contains eight core fields: serviceId, instanceId, state, version, issueTime, expireAt, recoverPercent, and evidenceDigest. The state field is marked as EXCLUDE, version is set to 1, issueTime is the timestamp of rule generation, expireAt is the timestamp 10 minutes after rule generation, recoverPercent is set to 0, and the evidenceDigest field stores a summary of core risk indicators for four consecutive statistical windows of this instance, used for subsequent auditing and backtracking. The generated rule is pushed to all gateway nodes via the rule distribution module. Upon receiving the rule, the gateway will not directly send it without further information. Instead of overwriting local rules, the gateway first retrieves existing rules from the local rule table based on the serviceId and instanceId, performing dual verification of rule version and time semantics. Only if the new rule's version is greater than an existing local rule, or if the version is the same but the issueTime is later, is it allowed to overwrite the local rule. If the rule has exceeded expireAt, has a lower version, or an earlier issueTime, it is discarded. This verification mechanism effectively avoids execution errors caused by network jitter, message out-of-order delivery, and rule replay, ensuring that the gateway's local rule table always retains governance rules with correct time sequence and valid versions. After completing the rule update, the gateway performs pre-filtering and pooling of the candidate instance set before load balancing for each request. The processing logic is as follows: Figure 6 As shown, for each business request entering the gateway, the system first obtains all 12 candidate instances of the target service from the registry center based on the serviceId. Then, it reads the metadata.instanceId from the metadata of each candidate instance and matches valid rules in the local rule table using the serviceId and instanceId as keys. After matching, 11 healthy instances do not match valid rules and all enter the normal candidate pool. One abnormal instance matches a valid rule in the EXCLUDE state and is directly and completely removed from the candidate instance set and will not enter any candidate pool.

[0052] After completing the pooling process, the system prioritizes executing the original weighted round-robin load balancing strategy on the 11 healthy instances in the normal candidate pool to complete instance selection and request forwarding. This ensures that subsequent business requests will not hit the identified abnormal instances, fundamentally reducing the problems of request timeouts, retries, and increased business latency caused by abnormal instances. In the first statistical window after the abnormal instance was removed, the overall service timeout rate dropped from 3.36% at the time of the failure to 0.25%, the P99 response latency dropped from 287ms to 118ms, and the business success rate recovered to 99.95%. The fault isolation effect was significant. Within 6 minutes after the abnormal instance was isolated, the underlying host disk I / O jitter problem was resolved, the thread pool queue length of the instance returned to normal levels, and the risk assessment module's four consecutive sliding statistical windows showed that the simulated probe requests of the instance exceeded the limit. When the latency drops to 0 and the P99 latency stabilizes at around 105ms, meeting the recovery judgment threshold, the risk state machine switches the instance state from HIGH_RISK to RECOVER_OBSERVE. Simultaneously, a recovery observation rule with version=2 is generated, the state is marked as RECOVER, recoverPercent is set to 20%, and expireAt is set to the timestamp 5 minutes after rule generation. This rule is then pushed to the gateway to update the local rule table. Upon receiving the recovery rule, the gateway, during the candidate instance pre-filtering stage, adjusts the instance from the excluded instance to the recovery candidate pool, completely isolating it from the normal candidate pool. It will not directly participate in the load balancing of full traffic and will only be allowed to participate in the candidate selection for the current request when the recovery release conditions are met. The recovery release judgment logic is as follows: Figure 7 As shown, for each business request, the system first extracts the request fingerprint (requestFingerprint), prioritizing stable business identifiers such as the business order number, requestId, and userId. Then, it combines the target instance's instanceId and rule version number (version) to calculate the recovery release threshold value (gateValue) using a fixed hash algorithm. After taking the gateValue modulo 100, if the result is less than the recoverPercent=20% set in the rule, the recovery instance is allowed to participate in the candidate selection for this request. Otherwise, the instance is still considered unselectable for this request. Since the same requestFingerprint, instanceId, and version will generate completely identical gateValues, the result of whether the same type of business request hits the recovery instance within the same recovery phase is completely stable, repeatable, and traceable. There will be no business jitter problem caused by purely random releases where the same type of request sometimes hits and sometimes misses, which makes it easier for R&D and operations personnel to continuously observe the recovery status of the instance.

[0053] In the first phase of recovery observation, the instance handled 582 business requests that met the scaling criteria, with a 100% success rate and a P99 latency of 112ms, fully meeting the health baseline. The risk assessment module then generated progressive recovery rules with version=3, recoverPercent=50%, version=4, and recoverPercent=100% to gradually increase the scaling ratio. After the instance ran stably for three recovery phases, a release rule with version=5 was generated, switching the instance status back to normal and reintegrating it into the normal candidate pool, completing the full traffic recovery. Throughout the recovery process, there was no perceptible fluctuation on the business side, and the overall service success rate remained above 99.95%. During the daily elastic scaling of this service, one of the running instances was rebuilt due to platform scheduling. The newly generated Pod had a completely new PodUID, container startup timestamp, and restart sequence number. According to the unified instance identifier generation rules, the new instance would generate an instanceId completely different from the old instance, even though the service identifier, workload identifier, and IP address of the new instance were completely identical to those of the old instance. In this way, the old instanceId will not be reused. Governance rules are always bound to the instanceId, rather than to volatile identifiers such as Pod name or IP address. Therefore, even if the gateway's local rule table still retains historical rules corresponding to the old instanceId, they will not hit newly generated instances, completely avoiding the problem of old rules accidentally affecting new instances. This ensures the accuracy and security of governance rules during instance lifecycle changes. Throughout the entire process of fault identification, isolation, and recovery, the system completely retains all core data, including the generation basis of the instanceId, full routeAttempt routing attempt records, full-link records of instance risk state migration, rule issuance and gateway effectiveness records, and details of traffic surges during the recovery phase. In subsequent fault review, the system can completely trace the routing attempt path of each request, the complete evidence chain of the instance being judged as high-risk, the full lifecycle sequence of the rules, and the traffic surge situation during the recovery phase. This completely solves the core pain points of traditional microservice governance systems, such as difficulty in identifying, isolating, and recovering single-instance faults, easy misjudgment, and easy jitter, and achieves automated, accurate, and highly resilient full lifecycle governance of microservice single-instance faults.

[0054] In summary, this invention completely solves the problems of inconsistent governance objects across modules and mismatched rules causing new instances due to Pod reconstruction / IP reuse by generating a globally unified and unique instance identifier (instanceId) that carries full lifecycle information and is independent of IP. Based on independent attribution records of successive routing attempts, it overcomes the shortcomings of traditional service-level statistics in masking hidden soft faults of single instances. Combined with dual-sample thresholds and a hysteresis state machine, it accurately identifies abnormal instances with normal health probes but degraded performance. Furthermore, through versioned time-series verification of governance rules, precise isolation of gateway-fronted instances, and a deterministic hash-based gradual gray-scale recovery mechanism, it achieves automated identification, secure isolation, and smooth, lossless recovery of single-instance faults. At the same time, it retains a complete chain of evidence throughout the entire process that is auditable and traceable, effectively reducing business timeout retries, improving the overall latency stability and business success rate of the cluster, and comprehensively solving the core pain points of traditional microservice governance such as difficulty in discovering and isolating single-instance faults, easy misjudgment, easy jitter, and lack of traceability, significantly enhancing the resilience of distributed cluster services.

[0055] Figure 8 This is a block diagram of a microservice single-instance fault-resistant traffic switching system according to an embodiment of this application.

[0056] like Figure 8 As shown, the microservice single-instance fault-resistant traffic switching system 10 includes: time-series data acquisition 100, risk feature extraction 200, risk status determination 300, and resilient traffic switching 400.

[0057] Among them, time-series data acquisition 100 is used to obtain the registration metadata of microservice instances and the time-series records of routing attempts when load balancing is selected; risk feature extraction 200 is used to perform risk evidence window aggregation operations on the routing attempt time-series records by the target instance dimension, extract the instance's timeout rate, anomaly rate, latency distribution, and number of consecutive timeouts, and construct a risk feature vector for a single instance; risk state judgment 300 is used to construct an instance risk state machine judgment model with integrated state hysteresis mechanism, input the feature vector into the instance risk state machine judgment model, and output the initial judgment results of the instance's migration from normal state to observation state, high-risk state, and recovery observation state; resilient traffic switching 400 is used to optimize the initial judgment results at the execution layer based on versioned rule semantics and time boundaries, integrate multi-source constraint data of rule version, effective time, and expiration time through the gateway's local rule table, correct the execution deviation caused by rule disorder or replay, and quantitatively remove high-risk instances and divert recovery observation instances in the pre-filtering stage of the load balancing candidate set according to the corrected rule data, and calculate the recovery release threshold based on deterministic hashing, generate standardized execution records, and push them to the microservice governance terminal.

[0058] It should be noted that the foregoing explanation of an embodiment of a microservice single-instance fault-resistant traffic switching method also applies to the microservice single-instance fault-resistant traffic switching system of this embodiment, and will not be repeated here.

[0059] This application proposes a microservice single-instance fault-resistant traffic switching system. It precisely quantifies single-instance timeout, anomaly, latency, and continuous failure characteristics through risk evidence window aggregation at the instance level. Combined with a risk state machine with state hysteresis, it achieves smooth migration determination across multiple instance states: normal, observation, high-risk, and recovery observation. Simultaneously, it optimizes the determination results through versioned rule semantics and time boundary constraints. Relying on the gateway's local rule table, it effectively solves execution deviation problems caused by rule disorder and replay. During the pre-filtering stage of the load balancing candidate set, it proactively removes high-risk fault instances and performs controllable traffic distribution for recovery observation instances. It also calculates the recovery volume threshold using a deterministic hash algorithm to achieve gradual and smooth recovery. Finally, it generates standardized execution records for visualized governance reporting. This system can accurately identify hidden faults in microservice single instances, achieve jitter-free resilient traffic switching, effectively prevent the avalanche propagation of fault instances, improve traffic switching stability, rule execution consistency, and instance recovery controllability, and comprehensively enhance the resilience of microservice operation and the traceability of fault governance. Therefore, it solves the problems of lack of end-to-end unification and delayed fault governance actions in existing technologies.

[0060] Figure 9 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include: The memory 901, the processor 902, and the computer program stored on the memory 901 and capable of running on the processor 902.

[0061] When processor 902 executes the program, it implements a microservice single-instance fault-resistant traffic switching method provided in the above embodiments.

[0062] Furthermore, electronic devices also include: Communication interface 903 is used for communication between memory 901 and processor 902.

[0063] The memory 901 is used to store computer programs that can run on the processor 902.

[0064] The memory 901 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0065] If the memory 901, processor 902, and communication interface 903 are implemented independently, then the communication interface 903, memory 901, and processor 902 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0066] Optionally, in a specific implementation, if the memory 901, processor 902, and communication interface 903 are integrated on a single chip, then the memory 901, processor 902, and communication interface 903 can communicate with each other through an internal interface.

[0067] The processor 902 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0068] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described microservice single-instance fault-resistant traffic switching method.

[0069] Furthermore, this application also provides a computer program product, including a computer program or instructions, which, when executed, implement the above-described microservice single-instance fault-resistant traffic switching method.

[0070] In the description of this specification, the references to the terms "an embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0071] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0072] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0073] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by suitable instructions. For example, if implemented in hardware as in another embodiment, it can be implemented using any of the following techniques known in the art, or a combination thereof: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0074] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0075] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for fault-tolerant traffic switching of a single microservice instance, characterized in that, include: Obtain the registration metadata of the microservice instance and the timing record of the route attempt when the load balancer is selected; Perform risk evidence window aggregation operation on the target instance dimension on the route attempt time sequence record, extract the timeout rate, anomaly rate, latency distribution and consecutive timeout number of instances, and construct a risk feature vector for a single instance; Construct an instance risk state machine determination model with a fusion state hysteresis mechanism, input the feature vector into the instance risk state machine determination model, and output the initial determination results of instance migration from normal state to observation state, high-risk state, and recovery observation state; The initial judgment result is optimized at the execution layer based on versioned rule semantics and time boundaries. By integrating multi-source constraint data such as rule version, effective time and expiration time through the gateway's local rule table, execution deviations caused by rule disorder or replay are corrected. Based on the corrected rule data, high-risk instances are quantitatively removed and observation instances are distributed and restored during the pre-filtering stage of the load balancing candidate set. The recovery and release threshold is calculated based on deterministic hashing, and standardized execution records are generated and pushed to the microservice governance terminal.

2. The microservice single-instance fault-resistant traffic switching method according to claim 1, characterized in that, Retrieve the registration metadata of the microservice instance and the route attempt sequence record when the load balancer is selected, including: Obtain the full lifecycle registration metadata of microservice instances and real-time call data of load balancer nodes; Based on the real-time call data, at the critical time point when the load balancer has completed instance selection and the business request has not yet been sent out, the unique identifier of the target instance corresponding to this call is locked, and the global unique identifier of the request, the call attempt sequence number, the source service instance identifier, the target service identifier, and the instance selection timestamp of all basic routing information are recorded synchronously. Based on the basic routing information, after a request completes with a normal response, a call exception occurs, or a timeout is triggered, the response status code, business return code, end-to-end response latency, timeout flag, exception type, and request completion timestamp are successively filled in to generate a complete routing attempt sequence record that covers the entire retry link of a single request and can be traced and attributed sequentially.

3. The microservice single-instance fault-resistant traffic switching method according to claim 1, characterized in that, Perform risk evidence window aggregation operations on the route attempt time-series records by target instance dimension, including: Construct a sliding risk evidence statistics window centered on the target instance; Based on the aforementioned statistical window, using service identifier and target instance identifier as joint statistical dimensions, the time-series records are aggregated and calculated with multiple dimensions of indicators, including call sample size, number of timeouts, number of anomalies, latency quantile, and number of consecutive failures. Simultaneously, dual compliance checks are performed on the minimum statistical sample threshold and the minimum source instance number threshold to obtain the check results. Based on the verification results, invalid noise data caused by occasional network jitter, single caller anomalies, and instantaneous traffic skew are filtered out, and core risk indicators that can truly reflect the instance's operating status, such as timeout rate, anomaly rate, high latency, and continuous timeout, are selected to generate standardized and highly discriminative single-instance risk feature vectors.

4. The microservice single-instance fault-resistant traffic switching method according to claim 1, characterized in that, A state machine judgment model for instance risk is constructed using a fusion state hysteresis mechanism. The feature vector is input into the instance risk state machine judgment model, and the initial judgment results of instance migration from normal state to observation state, high-risk state, and recovered observation state are output, including: Construct an instance risk state machine determination model for a fusion state hysteresis mechanism; Based on the instance risk state machine judgment model and the single instance risk feature vector, multiple rounds of continuous sliding statistical window index comparison, hysteresis threshold verification and risk level progressive judgment are performed to avoid frequent jittering of instance state in critical interval and generate instance state migration verification analysis data. Based on the instance state migration verification and analysis data, the preset instance state switching governance rules are matched, and the initial judgment result of the orderly migration of multiple instance states that conforms to the cluster fault governance standard and can directly drive the rule generation is output.

5. A microservice single-instance fault-resistant traffic switching method according to claim 1, characterized in that, The initial determination result is optimized at the execution layer based on versioned rule semantics and time boundaries, including: Construct an instance governance rules dataset with version and time-series boundaries; Based on the instance governance rule dataset, the gateway side performs a dual check of rule version monotonically increasing verification and validity of effective time, identifies out-of-order, expired, and replay invalid rules, and generates a rule time sequence validity verification conclusion. Based on the validity verification results of the rule sequence, abnormal and invalid rules are filtered out and the timing execution deviation is corrected to generate high-precision executable rule data that is adapted to the gateway and has accurate timing.

6. The microservice single-instance fault-resistant traffic switching method according to claim 1, characterized in that, In the pre-filtering stage of the load balancing candidate set, high-risk instances are quantitatively removed and instances under observation for traffic splitting and recovery are observed, including: Construct a hierarchical classification and filtering framework for load balancing candidate instances; Based on the hierarchical classification and filtering framework, unified identifier matching, governance rule mapping and operation status determination are performed on candidate instances to distinguish three types of instances: normal, high-risk and recovery observation, and generate candidate instance status classification results. Based on the candidate instance status classification results, high-risk instances are completely eliminated, isolated and diverted for observation, and only normal instances are retained to participate in regular traffic scheduling, thus completing the precise filtering of the candidate set in advance.

7. A microservice single-instance fault-resistant traffic switching system, characterized in that, include: Time-series data collection is used to obtain the registration metadata of microservice instances and the time-series records of routing attempts when load balancer is selected; Risk feature extraction is used to perform risk evidence window aggregation operation on the target instance dimension of the routing attempt time sequence record, extract the timeout rate, anomaly rate, latency distribution and consecutive timeout number of instances, and construct a risk feature vector for a single instance; Risk state determination is used to construct an instance risk state machine determination model with a fusion state hysteresis mechanism. The feature vector is input into the instance risk state machine determination model, and the initial determination results of the instance's migration from the normal state to the observation state, the high-risk state, and the recovered observation state are output. Resilient traffic switching is used to optimize the initial judgment result at the execution layer based on versioned rule semantics and time boundaries. It integrates multi-source constraint data such as rule version, effective time and expiration time through the gateway's local rule table to correct execution deviations caused by rule disorder or replay. Based on the corrected rule data, it quantitatively removes high-risk instances and restores observed instances in the pre-filtering stage of the load balancing candidate set. It also calculates the recovery volume threshold based on deterministic hashing, generates standardized execution records and pushes them to the microservice governance terminal.

8. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the microservice single-instance fault-resistant traffic switching method as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When a computer program or instruction is executed, it implements a microservice single-instance fault-resistant traffic switching method as described in any one of claims 1-6.

10. A computer program product, comprising a computer program or instructions, characterized in that, When a computer program or instruction is executed, it implements a microservice single-instance fault-resistant traffic switching method as described in any one of claims 1-6.

Images