Container platform available area fault flow switching method, device and equipment based on micro service and storage medium

Abstract

The invention discloses a micro-service-based container platform available area fault flow switching method, device and equipment and a storage medium, relates to the technical field of micro-service flow control, and discloses a micro-service-based container platform available area fault flow switching method which comprises the following steps: when it is detected that flow isolation of a target available area is triggered, switching the flow isolation of the target available area to the target available area; obtaining identification information of the target available area; modifying the load balancing configuration of the micro-service container application and the micro-service registration discovery center according to the identification information to obtain forbidden instance forwarding configuration; cutting off a single-side data route according to the identification information to obtain a target forwarding forbidding route; and performing flow isolation according to the forbidden instance forwarding configuration and the target forbidden forwarding route, and completing the fault flow switching of the available area of the container platform based on the micro-service. When the available area has a fault, the service instance flow of the target available area can be quickly and accurately isolated, so that the high availability and service continuity of the micro-service container platform are ensured.

Description

Technical Field

[0001] The present application relates to the field of microservice traffic control technology, and in particular to a method, apparatus, device, and storage medium for traffic switching in an availability zone of a microservice-based container platform. Background Art

[0002] In modern cloud computing environments, microservices have become a mainstream architecture. To achieve high-availability deployment of services, microservice applications are typically deployed across multiple Availability Zones (AZs) and rely on a service registry and discovery center (such as Nacos) to maintain the address information of each service instance, enabling dynamic communication between services. The service registry and discovery center plays a critical role in this process, ensuring data consistency and real-time communication. To support this multi-AZ deployment, the service registry and discovery center itself is deployed in multiple AZs and relies on inter-AZ communication to synchronize service registration information. This architecture requires the service registry to possess extremely high stability and fault tolerance. In particular, in the event of an AZ-level failure, failure to promptly isolate services and switch traffic can paralyze the entire service call chain, impacting business continuity.

[0003] Traditional solutions for AZ-level failures faced by service registry and discovery centers in multi-AZ deployments typically employ a synchronously controlled traffic switching mechanism. Specifically, when a failure occurs, the domain name registry first deletes the DNS resolution records for the faulty AZ in the Layer 4 load balancing layer one by one, then disables the backend forwarding entry of the Layer 7 load balancer to achieve isolation. However, this step-by-step synchronous processing approach, which relies on Layer 4 load balancing, is susceptible to performance bottlenecks, resulting in inefficient isolation and failing to meet the requirements for fast and stable failover in AZ failure scenarios.

[0004] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method, device, equipment and storage medium for traffic switching in the availability zone failure of a microservice-based container platform, aiming to solve the technical problem that in a multi-availability zone deployment environment, the service registration and discovery center cannot achieve efficient and stable traffic isolation and switching when an availability zone-level failure occurs.

[0006] To achieve the above objectives, this application proposes a method for traffic switching in a microservice-based container platform availability zone failure, the method comprising:

[0007] When traffic isolation of a target availability zone is detected to be triggered, obtaining identification information of the target availability zone;

[0008] Modify the load balancing configuration of the microservice container application and the microservice registration discovery center according to the identification information to obtain a disabled instance forwarding configuration;

[0009] Cut off the unilateral data route according to the identification information to obtain the target prohibited forwarding route;

[0010] Traffic isolation is performed according to the disabled instance forwarding configuration and the target prohibited forwarding route, thereby completing traffic switching for the available zone failure of the microservice-based container platform.

[0011] In one embodiment, the step of modifying the load balancing configuration of the microservice container application and the microservice registration and discovery center according to the identification information to obtain a disabled instance forwarding configuration includes:

[0012] Modify the backend instance configuration of the microservice container application and the microservice registration discovery center according to the identification information to obtain a configuration that prohibits external routing access;

[0013] Modify the container instance configuration of the microservice registration and discovery center according to the identification information to obtain a configuration for prohibiting container instance port access;

[0014] According to the external routing access prohibition configuration and the container instance port access prohibition configuration, a disabling instance forwarding configuration is obtained.

[0015] In one embodiment, the step of modifying the backend instance configuration of the microservice container application and the microservice registration discovery center according to the identification information to obtain a configuration for prohibiting external routing access includes:

[0016] Deleting the address resolution record of the service domain name of the target availability zone in the four-layer load balancing of the microservice container application and the microservice registration discovery center according to the identification information, to obtain the unbinding address availability zone;

[0017] Obtaining a service instance binding relationship of the unbinding address availability zone according to the identification information;

[0018] Call the four-layer load balancer interface of the microservice registration and discovery center according to the service instance binding relationship to obtain the current backend service instance status;

[0019] The current backend service instance state is set to a forwarding-disabled state, and the available zone mapping in the forwarding control table is updated to obtain a disabled external routing configuration.

[0020] In one embodiment, the step of modifying the container instance configuration of the microservice registration and discovery center according to the identification information to obtain a configuration for disabling container instance port access includes:

[0021] Extracting a container cluster list of the target availability zone in the container orchestration platform according to the identification information;

[0022] Call the message receiving interface of the microservice registration and discovery center according to the container cluster list to obtain the faulty container cluster;

[0023] Obtain the fault IP and fault port of the faulty container instance according to the faulty container cluster;

[0024] The access status of the faulty IP and the faulty port is modified to stop forwarding access, thereby obtaining a configuration for prohibiting container instance port access.

[0025] In one embodiment, the step of cutting off the unilateral data route according to the identification information to obtain a target forwarding-prohibited route includes:

[0026] Identify the fault range and the fault domain name according to the identification information, and obtain the fault external route according to the fault range and the fault domain name;

[0027] Deleting the faulty routing configuration in the seven-layer load balancer according to the faulty external routing to obtain a communication-isolated seven-layer load balancer;

[0028] Deleting the address resolution record of the target availability zone in the layer-4 load balancing according to the faulty external route, to obtain a communication-isolated layer-4 load balancer;

[0029] According to the communication isolation seven-layer load balancer and the communication isolation four-layer load balancer, a target prohibited forwarding route is obtained.

[0030] In one embodiment, when traffic isolation of the target availability zone is detected to be triggered, the step of obtaining identification information of the target availability zone includes:

[0031] When traffic isolation of a target availability zone is detected to be triggered, obtaining the number information of the target availability zone;

[0032] Obtain a list of container orchestration platform clusters deployed in the target availability zone according to the numbering information;

[0033] Obtain the running microservice container application list and the service instance configuration of the microservice registration and discovery center according to the container orchestration platform cluster list;

[0034] The identification information of the target availability zone is generated according to the microservice container application list and the service instance configuration, where the identification information includes the cluster number, service domain name, load balancing instance identifier, and backend IP list.

[0035] In one embodiment, after the step of performing traffic isolation according to the disabled instance forwarding configuration and the target prohibited forwarding route and completing the microservice-based container platform availability zone failure traffic switching, the method further includes:

[0036] When detecting that traffic isolation of the target availability zone ends, reading instance information of the disabled instance forwarding configuration;

[0037] Restore the address resolution record of the target availability zone service domain name in the four-layer load balancer according to the instance information to obtain the resolved communication address;

[0038] Setting the service instance state of the target availability zone in the seven-layer load balancer to a forwardable state according to the instance information to obtain a forwardable instance;

[0039] According to the target, forwarding routing is prohibited to restore the unilateral communication link, and a microservice registration instance is obtained;

[0040] The request reception state of the target availability zone is restored to allowing reception according to the resolved communication address, the forwardable instance, and the microservice registration instance.

[0041] In addition, to achieve the above-mentioned purpose, the present application also proposes a microservice-based container platform availability zone failure traffic switching device, which includes: an identification acquisition module, configured to acquire identification information of a target availability zone when detecting that traffic isolation of the target availability zone is triggered;

[0042] An instance configuration module is used to modify the load balancing configuration of the microservice container application and the microservice registration and discovery center according to the identification information to obtain a disabled instance forwarding configuration;

[0043] A routing prohibition module, configured to cut off the unilateral data route according to the identification information and obtain a target prohibited forwarding route;

[0044] The traffic switching module is used to isolate traffic based on the disabled instance forwarding configuration and the target prohibited forwarding route, and complete traffic switching for the available zone failure of the microservice-based container platform.

[0045] In addition, to achieve the above-mentioned purpose, the present application also proposes a microservice-based container platform availability zone fault traffic switching device, the device including: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the microservice-based container platform availability zone fault traffic switching method as described above.

[0046] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the microservice-based container platform availability zone failure traffic switching method as described above are implemented.

[0047] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the microservice-based container platform availability zone failure traffic switching method as described above.

[0048] One or more technical solutions proposed in this application have at least the following technical effects:

[0049] By adopting multi-dimensional control based on the target availability zone identification information, combined with dynamic adjustment of the load balancing configuration of the microservice container application and the registration discovery center, and precise cutting off of unilateral data routing, two-way traffic isolation control is achieved at the service call link layer and the registration layer, thereby effectively blocking the reception of external traffic and the internal data synchronization link of the availability zone failure instance. Through the above means, when an availability zone failure or planned maintenance occurs, a complete traffic switching process covering the ingress domain name resolution, intermediate routing path and registration information output can be quickly executed. Compared with the existing technology of deleting the address records of the domain name that can be used for the failure on the four-layer load balancing one by one, so that the failure availability zone stops receiving traffic, the automation level and execution accuracy of the switching process are greatly improved, achieving a response in seconds and avoiding the performance bottleneck of the four-layer load balancer affecting the fault isolation efficiency of the microservice registration discovery center server. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0051] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0052] Figure 1 This is a flow chart of the first embodiment of the method for traffic switching based on the availability zone failure of a microservices-based container platform of this application;

[0053] Figure 2A schematic diagram of a mutual access mechanism between microservices deployed in multi-availability zones using a service registration and discovery center, provided in Example 1 of the method for traffic switching over availability zones of a container platform based on microservices in this application;

[0054] Figure 3 This is a schematic diagram of the operation process of the availability zone traffic isolation scenario provided in Example 1 of the microservice-based container platform availability zone failure traffic switching method of this application;

[0055] Figure 4 A schematic diagram of the availability zone traffic isolation effect provided in Example 1 of the method for traffic switching over availability zone failures on a microservice-based container platform of this application;

[0056] Figure 5 This is a flow chart of the second embodiment of the method for traffic switching based on the availability zone failure of a microservice-based container platform in this application;

[0057] Figure 6 A schematic diagram of the flow of traffic recovery in an availability zone provided in Example 2 of the method for traffic switching in an availability zone of a microservice-based container platform;

[0058] Figure 7 This is a schematic diagram of the module structure of a microservice-based container platform availability zone failure traffic switching device according to an embodiment of the present application;

[0059] Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the method for traffic switching during an availability zone failure of a microservice-based container platform in an embodiment of the present application.

[0060] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0061] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0062] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0063] The main solution of the embodiment of the present application is: when detecting that traffic isolation of the target availability zone is triggered, obtaining the identification information of the target availability zone; modifying the load balancing configuration of the microservice container application and the microservice registration and discovery center according to the identification information to obtain a disabled instance forwarding configuration; cutting off the unilateral data route according to the identification information to obtain a target prohibited forwarding route; performing traffic isolation according to the disabled instance forwarding configuration and the target prohibited forwarding route to complete traffic switching based on the availability zone failure of the microservice-based container platform.

[0064] In this embodiment, for ease of description, the following description is based on the identification of a microservice-based container platform availability zone failure traffic switching device as the execution subject.

[0065] Since the existing technology cannot achieve efficient and stable traffic isolation and switching when the service registration and discovery center fails at the availability zone level in a multi-availability zone deployment environment, the present application provides a solution. Due to the use of multi-dimensional control based on the target availability zone identification information, combined with the dynamic adjustment of the load balancing configuration of the microservice container application and the registration and discovery center, and the precise cutting off of the unilateral data routing, it achieves two-way traffic isolation control at the service call link layer and the registration layer, thereby effectively blocking the reception of external traffic and the internal data synchronization link of the availability zone failure instance. Through the above means, it is possible to quickly execute a complete traffic switching process covering the ingress domain name resolution, intermediate routing path and registration information output when an availability zone failure or planned maintenance occurs. Compared with the existing technology of deleting the address records of the resolved domain name on the four-layer load balancing that can be used for the failure one by one, so that the failure availability zone stops receiving traffic, the automation level and execution accuracy of the switching process are greatly improved, and a response level of seconds is achieved, avoiding the performance bottleneck of the four-layer load balancer affecting the fault isolation efficiency of the microservice registration and discovery center server.

[0066] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device capable of implementing the above functions, a microservices-based container platform availability zone failure traffic switching device, etc. The following uses the microservices-based container platform availability zone failure traffic switching device as an example to illustrate this embodiment and the following embodiments.

[0067] Based on this, the embodiment of the present application provides a method for switching traffic in a container platform availability zone failure based on microservices, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the method for traffic switching during availability zone failure of a microservice-based container platform in this application.

[0068] In this embodiment, the method for traffic switching during an availability zone failure of a microservice-based container platform includes steps S10 to S40:

[0069] Step S10: When traffic isolation of a target availability zone is detected to be triggered, obtaining identification information of the target availability zone;

[0070] It's important to note that triggering traffic isolation in a target availability zone means proactively initiating traffic isolation for that zone when the platform detects a failure or maintenance in that zone. This trigger can be initiated manually or automatically by the fault monitoring module. Its primary purpose is to prevent the continued acceptance and processing of new service requests when an availability zone is experiencing an anomaly, thereby ensuring high availability and stability for the overall service.

[0071] Additionally, the target availability zone is the specific availability zone selected for traffic isolation in the event of a failure or maintenance. An availability zone (AZ) typically refers to a relatively independent physical area within a cloud computing infrastructure, with independent network, power, and resource scheduling capabilities. When a service in one AZ experiences an anomaly, it may affect other communicating zones, requiring separate handling.

[0072] Furthermore, identification information refers to a collection of data that uniquely represents the target availability zone range. This information includes, but is not limited to, the container cluster ID deployed on the container orchestration platform, the service domain name, the load balancer instance ID, and the IP address list of the backend service instances. This identification information is used in subsequent steps to identify specific configuration items that need to be modified, disabled, or isolated.

[0073] It's understood that when the platform detects a failure or maintenance condition in an Availability Zone, triggering a traffic isolation operation, it first extracts basic information related to the target Availability Zone from the configuration center or alarm input. Based on pre-set alarm policies or manual commands, the platform obtains the target Availability Zone ID. It then queries the container orchestration platform for the corresponding container cluster, service registration configuration, and load balancer association information. Ultimately, by aggregating this information, it generates complete identification information for the target Availability Zone. This information serves as a unified input for subsequent configuration modifications, route disconnections, and traffic isolation operations.

[0074] Reference Figure 2 , Figure 2 This is a schematic diagram of the mutual access mechanism between microservices deployed in multi-availability zones containerized using the service registration and discovery center in the first embodiment of the microservice-based container platform availability zone failure traffic switching method of this application.

[0075] like Figure 2As shown, in the client part, there are two cases: In case 1, the client directly accesses services A (AZ1) and B (AZ1) through the container instance IP, and the communication between service A (AZ1) and service A (AZ2) and between service B (AZ1) and B (AZ2) is achieved through internal routing; In case 2, the client accesses services C (AZ1) and C (AZ2) through external routing, and the communication between services C (AZ1) and C (AZ2) is achieved through four-layer-seven load balancing. Services A (AZ1) and AZ2 obtain the access address of service C through four-layer-seven load balancing, and return the access address of service B and the container instance IP and application port of service B in the nearest AZ through external routing. On the server side, the microservice registration service discovery center is divided into two areas, AZ1 and AZ2. Each area has a microservice registration service discovery center entry gateway and multiple container instances, such as container instance 1 and container instance 2 in AZ1, and container instance 1 and container instance 2 in AZ2. These container instances communicate through internal routing to achieve service registration and discovery. At the same time, the container instances between AZ1 and AZ2 are synchronized through unilateral external routing instance information to ensure the consistency of service information between different areas. It shows how clients in the microservice architecture access services through different routing methods, and how the server achieves service registration and discovery through internal and external routing, ensuring high availability and reliability of the service.

[0076] In a feasible implementation, step S10 may include steps S11 to S14:

[0077] Step S11: when traffic isolation of a target availability zone is detected, obtaining the number information of the target availability zone;

[0078] It's important to note that the ID uniquely identifies the target availability zone and marks the administrative domain of that availability zone. IDs are typically predefined by the platform and correspond to the cluster configuration of the container orchestration platform and service registry. They serve as the basis for subsequent resource retrieval in the target zone.

[0079] As you can understand, after receiving an event that triggers traffic isolation, the platform retrieves the target availability zone's ID. The platform retrieves the unique ID associated with the target availability zone by querying the contextual information carried by the triggering event or receiving command parameters passed by the administrator. This ID is used in subsequent steps to look up the container cluster manifest, service deployment relationships, and load balancer configuration, and serves as the starting input for the isolation process.

[0080] In a feasible implementation, when multiple container clusters or service nodes trigger abnormal events simultaneously but have not yet crossed the threshold, the platform can use network topology, call chain analysis, and load trend forecasting to predict the scope of possible spread of availability zone failures before the service fails completely, and perform pre-isolation operations in advance, thereby building proactive defensive traffic switching logic with predictive capabilities.

[0081] Step S12: Obtain a list of container orchestration platform clusters deployed in the target availability zone according to the numbering information;

[0082] It's important to note that a container orchestration platform, in this example, refers to a management platform used to centrally schedule and manage large numbers of container resources. This platform, in this example, refers to Kubernetes. It provides services such as deployment, resource isolation, load scheduling, and instance scaling, and serves as the fundamental operating environment for microservice container applications.

[0083] In addition, the cluster list is the collection of information about all container orchestration platform clusters associated with a particular availability zone, including each cluster's identifier, namespace, network configuration, and service deployment scope. This list can be used to determine the specific cluster target scope for operation.

[0084] As can be understood, the target availability zone ID is used as a query condition to query and list the container orchestration platform clusters registered in that availability zone from the resource management module. The platform collects metadata information for all clusters corresponding to that ID to form a container orchestration platform cluster list, providing a boundary range for subsequent identification of service deployment structure and instance information.

[0085] Step S13: Obtain the running microservice container application list and the service instance configuration of the microservice registration and discovery center according to the container orchestration platform cluster list;

[0086] It's important to note that the microservice container application manifest refers to the collection of information about all microservice instances deployed and running on the target container cluster. This includes the service name, number of deployed replicas, namespace, bound service domain name, and current running status. It is the direct target of platform traffic control and configuration operations.

[0087] Furthermore, service instance configuration refers to the configuration information of each microservice instance deployed in the cluster, including attributes such as the service instance ID, container IP, port, whether it is registered, and the registration and discovery center to which it belongs. This configuration data is maintained by the registration and discovery center and is the basis for implementing service discovery and access control.

[0088] As can be understood, each identified container cluster is traversed to extract the deployed microservice container applications and their service instance configurations from the registry discovery center. The platform connects to the registry discovery center through an interface, pulls service registration records by cluster, and compiles a complete list based on the actual deployment of the orchestration platform. The generated application list and service configuration are used to construct the complete identification information of the target availability zone.

[0089] Step S14: Generate identification information of the target availability zone based on the microservice container application list and the service instance configuration, where the identification information includes a cluster number, a service domain name, a load balancing instance identifier, and a backend IP list.

[0090] As you can understand, the microservice container application manifest and service instance configuration are structured to extract and summarize the required identification dimension information. The platform encapsulates each cluster ID, service domain name, load balancer ID, and service instance IP address to form the identification information of the target availability zone. This information is used as a unified parameter at each stage of the traffic switching process to achieve precise positioning of the operation target.

[0091] It should be noted that the cluster ID uniquely identifies a container orchestration platform cluster within the platform. It is typically generated based on region, environment, or business function coding rules. This ID is used to identify cluster ownership during configuration changes and service management.

[0092] Furthermore, the service domain name is the network name exposed to external access by the microservice deployed in the container. It is usually generated by the service registration center or load balancer and is used to uniformly resolve and route requests and shield the physical address changes of the backend instance.

[0093] The load balancing instance ID is the unique number or name of the load balancer component involved in traffic forwarding. This ID is used to mark the binding between the current service domain name and the specific forwarding path, and is used as a positioning reference during configuration operations.

[0094] In addition, the backend IP list refers to the IP address collection of all backend service instances bound to the service domain name. It is used for request scheduling and forwarding by the seven-layer or four-layer load balancer and is the basic data for implementing service access.

[0095] Step S20, modifying the load balancing configuration of the microservice container application and the microservice registration and discovery center according to the identification information to obtain a disabled instance forwarding configuration;

[0096] It's important to note that microservice container applications refer to business service modules deployed in a container environment and built using a microservices architecture. Each microservice runs in a lightweight container and discovers and communicates within the platform through a service registry, allowing for independent deployment, scaling, and updates.

[0097] In addition, the microservice registration and discovery center refers to the basic component for managing the registration, discovery, and state synchronization of all microservice instances in the platform. In this embodiment, the microservice registration and discovery center is Nacos, which is used to maintain a list of service instances and respond to instance query requests from service callers.

[0098] Furthermore, load balancing configuration refers to the traffic distribution strategy configured in a Layer 7 or Layer 4 load balancer, including service domain name resolution, routing forwarding rules, health checks, and instance binding information. By modifying these configurations, you can control whether requests can reach the target availability zone.

[0099] In addition, the disabled instance forwarding configuration is a set of configurations generated based on identification information that prevents service instances in the target availability zone from providing external services. This includes marking the disabled instance in the load balancer, deleting the resolution record for the service domain name, and blocking the instance's visibility in the registry discovery center.

[0100] It can be understood that, based on the obtained target availability zone identification information, the microservice container application and the configuration items in the registration discovery center that need to be modified are located in turn. The platform first calls the load balancer management interface to delete the four-layer address resolution record of the service domain name in the target availability zone to prevent subsequent traffic from entering through external domain names. The platform identifies the service instance binding relationship in the target availability zone based on the identification information, marks the corresponding backend instance as unavailable, and updates the forwarding control table. The platform calls the interface provided by the registration discovery center, passes in the container cluster information of the target availability zone, and stops returning the ip+port information of the service instance in the region to the caller. The platform encapsulates the above modifications as a configuration to disable instance forwarding for subsequent traffic isolation operations.

[0101] Reference Figure 3 , Figure 3 This is a schematic diagram of the operation flow of the availability zone traffic isolation scenario of the first embodiment of the availability zone failure traffic switching method of the microservice-based container platform of this application.

[0102] like Figure 3As shown in the figure, traffic isolation is initiated when an AZ-level failure occurs or planned maintenance requires isolating an AZ. This process is divided into three main modules. Modules 1 and 3 begin. Module 1 isolates traffic between the client microservice container application and the server container application gateway. Module 3 notifies the Nacos microservice registration and discovery center of a failure or maintenance. The entire flow chart clearly demonstrates how traffic isolation is achieved through the collaboration of different modules during AZ-level failures or planned maintenance, ensuring system stability and availability. Module 2 involves isolating one-way communication between container instances in the Nacos microservice registration and discovery center.

[0103] In one feasible implementation, after extracting identification information, the platform can automatically filter and disable forwarding and disconnect communication links for only critical business service instances based on service tags, service priorities, or service scopes in the microservice container application manifest, while maintaining normal traffic access paths for low-risk services. This strategy can be used to maintain service availability with degraded performance when parts of a container cluster are unstable, achieving hierarchical degradation of fault zones and minimizing the impact.

[0104] In a feasible implementation, step S20 may include steps S21 to S23:

[0105] Step S21, modifying the backend instance configuration of the microservice container application and the microservice registration and discovery center according to the identification information to obtain a configuration prohibiting external routing access;

[0106] It's important to note that backend instance configuration refers to the set of service instance parameters recorded in the load balancer and registry discovery center for identifying and forwarding traffic. This includes the instance's IP address, port, service, load balancing status, and health check results, and is a key parameter for controlling traffic entry.

[0107] It is understandable that, based on the identification information, the service instance in the target availability zone is located, and its related load balancer configuration and registration information are modified. By calling the four-layer load balancer interface, the DNS address resolution record corresponding to the service domain name is deleted, preventing new requests from entering the target availability zone through the domain name. Based on the service instance binding relationship, the backend interface is called to set the instance status to non-forwardable, and the forwarding identifier of the availability zone in the forwarding control table is updated. After completing the above operations, all blocked instances and their configurations are encapsulated as a configuration that prohibits external routing access to isolate external ingress traffic.

[0108] In this embodiment, the Nacos microservice registration and discovery center (server) and other container applications (clients) on the cloud are deployed in a multi-AZ high-availability architecture, in which the load balancer serves as the unified request entrance for the application between multiple AZs, and the seven-layer (application layer) load balancer and the four-layer (transport layer) load balancer forward traffic equally to multiple AZs in the back end. When the container application is published, the external route of the container application is published to the seven-layer load balancer corresponding to the AZ, and the domain name registration center records the mapping relationship between the external route and the front-end public entry IP (the public entry IP of the multi-AZ container application). When accessing this container application through the external route, the external route domain name will be resolved to the public entry IP, and then the four-layer load balancer and the seven-layer load balancer will process the transport layer and application layer messages of the network data packet respectively, and forward the traffic equally to multiple AZs of the container application.

[0109] When one of the AZs fails, the domain name registry will first delete the DNS resolution A record of the domain name of the failed AZ on the four-layer load balancing (such as GTM), so that the failed AZ stops receiving new requests, and then call the four-layer load balancer interface to disable the corresponding failed AZ backend.

[0110] In a feasible implementation, step S21 may include steps S211 to S214:

[0111] Step S211, deleting the address resolution record of the service domain name of the target availability zone in the four-layer load balancing of the microservice container application and the microservice registration discovery center according to the identification information, to obtain the unbinding address availability zone;

[0112] It's important to note that a service domain name is a standardized network name used to access microservice container applications. It's typically mapped to multiple service instance IP addresses through a unified DNS resolution mechanism. The service domain name masks the specific deployment location of the service instance and serves as the core entry point for request routing and load balancing.

[0113] Furthermore, Layer 4 load balancing is a traffic distribution mechanism based on transport layer protocols, such as TCP or UDP, which forwards data by identifying IP addresses and ports. Compared to Layer 7 load balancing, it operates at a lower network layer and has higher forwarding efficiency, making it suitable for scenarios such as DNS resolution and ingress proxy.

[0114] In addition, address resolution records refer to the mapping entries between domain names and IP addresses maintained by DNS servers or layer-4 load balancers. When users access services through service domain names, the platform forwards the requests to the corresponding backend service instances based on these records.

[0115] Furthermore, the unbound address availability zone refers to the target availability zone where the service domain name is unbound in the load balancer, that is, the IP address of the zone is no longer used as the resolution target of the service domain name, thereby achieving decoupling between the domain name and the fault availability zone.

[0116] It is understandable that, based on the correspondence between the service domain name provided in the identification information and the target availability zone, the microservice container application and the registration discovery center related interfaces are called to delete the address resolution record of the service domain name in the four-layer load balancing. The portion of all IP addresses resolved by the service domain name that belongs to the target availability zone is identified, and then these records are cleared from the load balancer DNS table. Through this operation, the service domain name will no longer point to the target availability zone, thereby realizing the unbinding operation of the zone and forming an unbound address availability zone.

[0117] Step S212: obtaining the service instance binding relationship of the unbinding address availability zone according to the identification information;

[0118] It should be noted that a service instance binding relationship refers to the connection mapping between a service domain name and a backend service instance, including the service name, instance IP address, port number, availability zone, service protocol, etc. This relationship determines how the load balancer distributes traffic to specific instances.

[0119] As can be understood, based on the identification information, the binding relationship between the service domain name and the service instance in the unbinding address's availability zone is queried. The platform retrieves information about all instances previously bound to the service domain name through an interface, selects instances belonging to the target availability zone, and establishes a corresponding binding relationship table. This binding relationship serves as input for subsequent updates to the instance forwarding status, ensuring that control operations are precisely targeted to service instances within the unbinding zone.

[0120] Step S213, calling the four-layer load balancer interface of the microservice registration and discovery center according to the service instance binding relationship to obtain the current backend service instance status;

[0121] It's important to note that the current backend service instance status refers to the forwarding status of a specific service instance in the load balancer. It may include labels such as healthy, forwarding, unavailable, and maintenance. This status is updated in real time by the load balancer and is an important basis for determining whether isolation is necessary.

[0122] As you can see, based on the service instance bindings, the Layer 4 load balancer management API is called one by one to retrieve the current status of each bound service instance. The results include information such as whether the instance is healthy, whether forwarding is allowed, and the forwarding policy. This status allows you to determine which instances are still receiving traffic and prepare for setting a policy that prohibits forwarding in the next step.

[0123] Step S214: setting the current backend service instance state to a forwarding-disabled state, and updating the available zone mapping in the forwarding control table to obtain a disabled external routing configuration.

[0124] It should be noted that disabling forwarding means removing the service instance from the load balancer's forwarding targets, preventing it from receiving and responding to requests. A service instance in the disabling forwarding state remains in the platform, but its ingress path is blocked and it cannot provide external services.

[0125] In addition, the forwarding control table is a data structure used by the Layer 4 load balancer to record the forwarding rules for service instances. This table determines the destination of traffic, including instance binding relationships, forwarding weights, availability zone mappings, and other factors, and is the basis for executing load balancing policies.

[0126] Furthermore, prohibiting external routing configuration refers to a control configuration set formed according to the above operations, indicating that all bound service instances in the target availability zone have been isolated from the load balancing path, preventing them from receiving access requests from the service domain name.

[0127] Understandably, the state of the queried backend service instances is modified, setting their forwarding status to prohibited, thereby preventing them from receiving new traffic. Simultaneously, the platform updates the availability zone entries for these instances in the forwarding control table, marking them as unavailable or blocked, ensuring that no future domain names or policy matches will be dispatched to that zone. The prohibited forwarding status modification is aggregated into a prohibited external routing configuration, providing instance-specific ingress control data for subsequent traffic isolation.

[0128] Step S22: modify the container instance configuration of the microservice registration and discovery center according to the identification information to obtain a configuration for prohibiting container instance port access;

[0129] It should be noted that container instance configuration refers to the container operating parameters recorded in the microservice registration and discovery center for service discovery, including the cluster to which the instance belongs, IP address, open ports, service status, registration tags, etc. This configuration determines whether the service instance can be queried and connected to by other services.

[0130] It is understood that the target availability zone container cluster list provided in the identification information is used to call the message receiving interface provided by the microservice registration and discovery center, notifying the registration center of the cluster range of the target container instance. After receiving this message, the registration center automatically identifies all container instances within this range, sets their corresponding registration records to an unavailable state, and stops returning the IP addresses and ports of these instances to the service caller. These excluded instance ports are recorded as a prohibited container instance port access configuration, which serves as an important basis for subsequent traffic control.

[0131] In this embodiment, when a fault occurs, the administrator uses the tool to call the domain name registry and enter the fault scope. After the domain name registry obtains the external routes involved in the fault scope, it batch deletes the configuration of these external routes in the seven-layer load balancer. At this time, if the client requests these isolated external routes, the seven-layer load balancer will reply with a return code 500, thereby cutting off the communication between the normal AZ of the Nacos microservice registration and discovery center and the faulty AZ, thus achieving fault isolation. Then, the A record of the faulty AZ corresponding to these external routes is deleted in the four-layer load balancer, stopping the resolution of traffic to the faulty AZ.

[0132] In a feasible implementation, step S22 may include steps S221 to S224:

[0133] Step S221: extracting a container cluster list of the target availability zone in the container orchestration platform according to the identification information;

[0134] It's important to note that the container cluster manifest is a collection of manifest data for all container clusters deployed in the target availability zone. This manifest includes information such as each cluster's unique ID, deployment location, associated namespace, and resource quota. It serves as essential data for microservice operations and instance discovery.

[0135] As you can understand, based on the identification information, the container orchestration platform extracts all container clusters belonging to the target availability zone. The platform first queries the deployment structure table and cluster registry based on the cluster ID included in the identification information, listing all container cluster entries related to the availability zone. The extracted result is the container cluster list, which is used in subsequent steps to perform registry operations on a cluster-by-cluster basis.

[0136] Step S222: Call the message receiving interface of the microservice registration and discovery center according to the container cluster list to obtain the faulty container cluster;

[0137] It's important to note that the message receiving interface is the callable entry point provided by the microservices registry discovery center for receiving availability zone status change information. When the platform detects that an availability zone has entered a faulty state, it notifies the registry center by calling this interface, allowing the registry to update instance visibility and access status.

[0138] Furthermore, faulty container clusters are defined as those in a faulty state. After the platform notifies the registry to complete the marking, the registry will internally identify and isolate the relevant services. The service instances in these clusters will be included in the fault handling scope and their network information will no longer be exposed externally.

[0139] As you can see, the microservice registry discovery center's message receiving interface is called one by one using the container cluster list as input, reporting the target container cluster to the registry center as a fault notification. Upon receiving the notification, the registry center automatically identifies the fault for each cluster and generates a list of faulty container clusters. This list contains all container clusters in the current availability zone that have been marked as faulty and need to be removed from service, serving as the basis for subsequent fault instance screening.

[0140] Step S223: Obtain the faulty IP and faulty port of the faulty container instance according to the faulty container cluster;

[0141] It should be noted that the faulty IP refers to the network address recorded in the registry by the above-mentioned container instance for service communication. It is usually a private address inside the container or virtual machine and is one of the targets of platform traffic forwarding.

[0142] Additionally, the fault port refers to the service port exposed by the container instance, used to receive external requests. The port and IP address together determine the access path to the service and are the key fields returned by the registration and discovery center to the caller.

[0143] As you can understand, based on the list of failed container clusters, the service instance query interface of the registration discovery center is called to retrieve information about all container instances within each cluster, filtering out those in a failed state. For each failed instance, the platform extracts the IP address and port number from its registration information to create a list of failed IP addresses and ports. This list serves as prerequisite data for port-level blocking control and is an important foundation for traffic isolation.

[0144] Step S224 : Modify the access status of the faulty IP and the faulty port to stop forwarding access, and obtain a configuration for disabling container instance port access.

[0145] It should be noted that the access status of stopped forwarding access means that the platform sets the IP and port of the faulty container instance to an uncallable state. Even if the service instance still exists in the platform, its network connection path has been blocked and cannot receive or respond to any requests.

[0146] Understandably, all identified faulty container instance IP addresses and port numbers are uniformly set to "stop forwarding access" in the registry discovery center. This status means these service instances are no longer accessible and are not included in the call candidate list of other services. The platform aggregates these status changes into a "disable container instance port access" configuration, indicating that access to the IP+port path for container instances in the current availability zone has been completely blocked.

[0147] Step S23: Obtain a disabled instance forwarding configuration according to the disabled external routing access configuration and the disabled container instance port access configuration.

[0148] It's understandable that the configuration for disabling external routing access and disabling container instance port access has been combined to form a unified structure for disabling instance forwarding. This configuration completely removes all service instances in the target availability zone from the platform's request path, registration directory, and load balancer, effectively preventing them from receiving any form of access. This configuration will serve as one of the primary control parameters for subsequent traffic isolation and switching, ensuring consistent isolation across all service paths.

[0149] In this embodiment, when an AZ-level failure occurs or a planned maintenance requires isolating an AZ, the container platform administrator can select the target AZ area and click to trigger traffic isolation for the AZ. Figure 3 Module 1 will modify the seven-layer and four-layer load balancing forwarding backend AZ in front of the microservice container application (client) and the Nacos microservice registration and discovery center (server) ingress gateway, disable the backend instance forwarding of the faulty (or maintained) AZ, and stop the faulty AZ from accepting new traffic requests accessed using external routing; at the same time, Figure 3 Module three will synchronously notify the service registration and discovery center of the name of the AZ range where the failure (or maintenance) occurs, so that the service registration and discovery center can conditionally use this information to shield the IP address of the microservice container instance within the faulty AZ range from the client, so that the container instance IP+port of the faulty AZ will no longer accept new traffic requests.

[0150] Step S30, cutting off the unilateral data route according to the identification information to obtain a target prohibited forwarding route;

[0151] It's important to note that unilateral data routing refers to a one-way communication link between registration and discovery center instances, synchronizing service instance information from one availability zone to the other. For example, if data is synchronized from the registration and discovery center in availability zone A to availability zone B, but B doesn't synchronize back to A, this creates a unilateral path. In this embodiment, the unilateral synchronization link from the faulty availability zone to other availability zones must be severed to prevent the propagation of erroneous data.

[0152] In addition, the target forwarding prohibition route is a set of non-forwardable route information formed after the unilateral data route is cut off. The target forwarding prohibition route records the disabled communication link, the path identifier of the access denied path, and the path mapping relationship used for restoration.

[0153] It is understandable that, based on the identification information, the unilateral synchronization routes between the service registration and discovery center instance in the target availability zone and other normal availability zones are identified. The platform obtains the seven-layer load balancer routing configuration involving these unilateral communication paths by calling the domain name registration center interface and sets it to a rejection state. The platform configures a response strategy in the registration and discovery center of the target availability zone so that it returns a status code 500 to requests from other availability zones. When a return code of 500 is encountered, data synchronization is stopped, achieving fault isolation features and ensuring that communication on the link is interrupted. After completing the above configuration, the platform records the disabled path information as a target prohibited forwarding route and uses it as one of the input parameters for traffic isolation.

[0154] In this embodiment, when a fault occurs, the administrator passes the fault scope (which can be a specific container cluster or the entire AZ range) to the traffic switching program. The program then passes the list of Kubernetes container clusters involved to the message receiving interface provided by the Nacos microservice registration and discovery center through an API call. When the message interface of the Nacos microservice registration and discovery center is called, the Kubernetes container clusters involved in the fault scope can be obtained, allowing the Nacos microservice registration and discovery center to stop forwarding the container application instance IPs within the fault scope, thereby preventing the container instances in the faulty AZ from being accessed.

[0155] In a feasible implementation, step S30 may include steps S31 to S34:

[0156] Step S31, identifying the fault range and the fault domain name according to the identification information, and obtaining the fault external route according to the fault range and the fault domain name;

[0157] It should be noted that the fault scope refers to the resource area currently experiencing an abnormal state, as determined by identification information. This includes the container clusters, services, service instances, and their external exposure paths deployed in the faulty availability zone. This scope is used to clarify which resources will be included in traffic isolation control.

[0158] Additionally, the fault domain name refers to the service access name associated with the service instances within the fault scope. The fault domain name is used by the load balancer for traffic forwarding. It resolves to the backend service instances within the fault scope and must be blocked in the event of a fault.

[0159] Furthermore, a fault external route is a traffic forwarding path that matches the fault scope and domain name and currently exists in the load balancing configuration. This route directs requests from external clients to the faulty availability zone. Failure to remove this route promptly can result in misdirected traffic and access failures.

[0160] As can be understood, based on the identification information, the container cluster ID, service domain name, and service instance address of the target availability zone are extracted, and all possible service exposure paths within that zone are analyzed accordingly. The platform then cross-references the service registry and load balancer configuration to identify the service domain name currently pointing to the faulty resource, known as the faulty domain name. Based on this domain name and its associated availability zone range, the platform determines all Layer 7 and Layer 4 external access paths that need to be deleted, summarizing them as the faulty external route.

[0161] Step S32, deleting the faulty routing configuration in the seven-layer load balancer according to the faulty external routing, to obtain a communication-isolated seven-layer load balancer;

[0162] It's important to note that a Layer 7 load balancer is a network forwarding component that distributes requests based on application-layer protocols, such as HTTP or HTTPS. It can identify URLs, headers, paths, methods, and other content for flexible routing. It supports traffic policy configuration based on service names or domain names, and serves as a crucial middleware for dynamic microservice scheduling.

[0163] Additionally, fault routing configuration refers to the configuration items in the Layer 7 load balancer that direct traffic to the target availability zone. This includes domain name forwarding rules, path matching rules, and backend instance bindings. If this configuration is not cleared promptly, the faulty instance will still be scheduled for service.

[0164] Furthermore, a communication-isolated Layer 7 load balancer refers to a Layer 7 load balancer instance whose configuration no longer includes access paths to failed resources after the failed routing configuration has been deleted. In this state, clients cannot access services in the failed region through the Layer 7 protocol.

[0165] As you can understand, the platform calls the Layer 7 load balancer management interface based on the faulty external routing, locates and deletes any domain name or path configuration items pointing to the faulty availability zone. The platform deletes configuration records, including service domain name resolution rules, path forwarding relationships, and associated backend instances. After deletion, the platform records the load balancer status and marks it as a communication isolated Layer 7 load balancer.

[0166] Step S33: deleting the address resolution record of the target availability zone in the Layer 4 load balancing according to the faulty external route, to obtain a communication isolated Layer 4 load balancer;

[0167] It's important to note that a Layer 4 load balancer is a data forwarding device based on transport layer protocols, such as TCP or UDP. It forwards requests based on IP address and port combinations, without involving application layer protocols. In microservices architectures, it's typically used for DNS resolution, service discovery, and basic network proxy functions.

[0168] Additionally, address resolution records are used in the Layer 4 load balancer to map service domain names to service instance IP addresses. They are the basis for binding service names to instances. If an address resolution record is deleted, the service domain name becomes invalid or points only to instances in other availability zones.

[0169] Furthermore, a communication-isolated layer-4 load balancer means that all service instance IP information pointing to the target availability zone has been removed from its address resolution record, so that domain name requests can no longer be routed to the layer-4 load balancer instance in the fault area.

[0170] As you can understand, the Layer 4 load balancer's configuration interface is called based on the fault's external routing data to delete all IP address resolution records for the service domain name in the target availability zone. The platform then matches each domain name, filtering out all address entries belonging to the target availability zone to ensure that the service domain name is no longer forwarded to the faulty region. After completing the configuration cleanup, the platform records the current Layer 4 load balancer status and marks it as a communication isolated Layer 4 load balancer.

[0171] Step S34: obtaining a target prohibited forwarding route according to the communication isolation layer-7 load balancer and the communication isolation layer-4 load balancer.

[0172] It can be understood that the Layer 7 load balancer and the communication isolation Layer 4 load balancer are used as input parameters, and the cleared domain name, path, IP address, port, and other routing information are integrated to form a set of routing paths that are prohibited from forwarding. This set of routes serves as the target prohibited forwarding routes and serves as the basis for subsequent traffic isolation actions. The platform can use this set to confirm which communication links have been completely disconnected and can also perform reverse operations to restore the connection after the failure is recovered.

[0173] In this embodiment, when an AZ-level failure occurs, if the container instances in the normal AZ of the Nacos microservice registration and discovery center do not promptly disconnect from data synchronization with the faulty AZ, the unstable Nacos microservice registration and discovery center container instances in the faulty AZ will maintain intermittent connections with the container instances in other normal AZs. This will cause inconsistencies in the data stored between the container instances in different AZs within the Nacos microservice registration and discovery center, and thus the entire service registration and discovery center will be unable to provide services normally as a whole. Therefore, when an AZ-level failure occurs and the ingress traffic to the faulty AZ is blocked (i.e., after module one is completed), communication with the faulty AZ must be promptly disconnected, i.e., module two is executed. After module one is executed, no new service registration or discovery requests will enter the faulty AZ of the Nacos microservice registration and discovery center (server side), while the Nacos microservice registration and discovery center in the normal AZ will operate normally and maintain the latest microservice access address data. At this point, module two is executed again, so that the microservice registration center in the normal AZ no longer synchronizes data with the Nacos microservice registration and discovery center in the faulty AZ, which has lagged behind, and the latest data of the container instances in the normal AZ is stored.

[0174] Step S40: Traffic isolation is performed according to the disabled instance forwarding configuration and the target prohibited forwarding route, thereby completing traffic switching for the available zone failure of the microservice-based container platform.

[0175] It should be noted that traffic isolation refers to separating the availability zone in a faulty or maintenance state from the overall traffic path of the microservice platform, so that it no longer receives new external access requests and no longer participates in the synchronization of registration information, thereby preventing abnormal data or failed responses from affecting other areas.

[0176] In addition, fault traffic switching means migrating the traffic originally assigned to the target availability zone to other availability zones when a failure occurs, while cutting off its external communication and data synchronization paths to ensure the overall continuous availability of the service.

[0177] Reference Figure 4 , Figure 4 This is a schematic diagram of the availability zone traffic isolation effect of the first embodiment of the availability zone failure traffic switching method of the microservice-based container platform of this application.

[0178] like Figure 4As shown in the figure, a failure in AZ1 affects the applications in red, severing the corresponding traffic forwarding path and isolating the communication state. The figure is divided into two parts: the client access process for microservices and the server-side process for microservice registration with the service discovery center. The client portion on the left shows service C (AZ1 and AZ2) obtaining the access address of service A (AZ2) through Layer 4 to Layer 7 load balancing. Service A (AZ2) then requests the external route for service B, while the communication path between services A (AZ1) and B (AZ1) is severed. After failover, service A (AZ2) directly requests the container instance IP and application port of service B (AZ2), bypassing services A (AZ1) and B (AZ1). The server portion on the right shows the state of the microservice registration service discovery center after the failure of AZ1. The communication path between the ingress gateway of the microservice registration service discovery center in AZ1 and the internal routing is severed, resulting in the inability of container instances 1 and 2 in AZ1 to communicate via the internal routing. However, container instances 1 and 2 in the microservice registration service discovery center in AZ2 maintain communication, ensuring service information consistency within AZ2. Compared to Figure 2 and Figure 4 , Figure 4 It mainly demonstrates how to achieve traffic isolation by cutting off specific paths after traffic switching due to an availability zone failure, thereby completing traffic switching due to an availability zone failure on a microservice-based container platform.

[0179] As you can understand, using the disabled instance forwarding configuration and the target disabled forwarding route as input, traffic isolation is performed jointly at the service instance and registry levels. The platform removes instances in the target availability zone from the available forwarding list in the load balancer and blocks the ability of instances in that zone to return IP addresses and ports through the registry. Combined with unilateral data synchronization between registries, this ensures that the failed availability zone can neither receive requests nor transmit data to other zones. After these actions are complete, the target availability zone is completely removed from the platform, traffic failover is complete, and the platform maintains high availability. Layer 7 load balancing proxies 500 requests for unilateral domain name requests to the service discovery registry in the failed AZ, preventing the Nacos microservices registry in the failed AZ from communicating with those in the functioning AZ. This prevents the Nacos microservices registry from being affected by state fluctuations in the AZ's failure and prevents isolated packets from being reintegrated into communication after a configuration refresh occurs after the Nacos microservices registry restart, as is the case with non-unilateral domain name isolation.

[0180] This embodiment provides a method for traffic switching in the event of an availability zone failure on a microservice-based container platform. When a failure or maintenance is detected in the target availability zone, the identification information of the availability zone is obtained, and the load balancing configuration of the microservice container application and the microservice registration and discovery center is modified based on this information. The technical means of cutting off unilateral data routing solves the technical problem of how to quickly and effectively isolate the faulty availability zone in the microservice container platform to avoid affecting the overall service stability. This achieves the beneficial effect of quickly isolating the faulty area without affecting services in other availability zones, ensuring the high availability and stability of the platform's overall services.

[0181] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 5 After step S40, the method for switching traffic in an available zone of a microservice-based container platform further includes steps S50 to S90:

[0182] Step S50: upon detecting that traffic isolation of the target availability zone is completed, reading instance information of the disabled instance forwarding configuration;

[0183] It's important to note that the end of traffic isolation means the target availability zone has recovered from a failure or maintenance state and is now available and able to receive external traffic again. This state can be detected by the monitoring module or manually lifted by the administrator, marking the start of the recovery phase of the traffic switching process.

[0184] Furthermore, the instance information refers to the service instance identifier, IP address, port, service domain name, availability zone, and other contents stored in the disabled instance forwarding configuration.

[0185] As you can understand, once the target availability zone is detected to have recovered, the traffic restoration process begins, first reading the information about the blocked service instances from the previously saved forwarding configuration for the disabled instances. The platform extracts information about these instances, including their original service domain name, registered IP address, port number, and forwarding status, from configuration snapshots or isolated task records. This provides complete data support for the subsequent restoration of Layer 4 and Layer 7 load balancer configurations.

[0186] Step S60: Restore the address resolution record of the target availability zone service domain name in the four-layer load balancer according to the instance information to obtain the resolved communication address;

[0187] It should be noted that an address resolution record is a mapping entry between a service domain name and a backend IP address. Through this record, client requests can be routed to a specific instance address. Deleting the record means blocking the service, while restoring the record means reconnecting the service path.

[0188] Furthermore, the resolved communication address refers to the re-established resolution path from the domain name to the IP address during the restoration of the Layer 4 load balancer, which is used to restore the basic network connectivity between the client and the target availability zone.

[0189] Understandably, the platform calls the Layer 4 load balancer management interface based on the instance information to re-register the previously deleted service domain name address resolution record. The platform rebinds the instance IP address to the service domain name, enabling clients to access these instances again via the domain name. After the recovery operation is complete, the platform records all successfully resolved address paths and defines this collection as the resolved communication address.

[0190] Step S70: Setting the service instance state of the target availability zone in the seven-layer load balancer to a forwardable state according to the instance information to obtain a forwardable instance;

[0191] It should be noted that the forwardable state means that the service instance is marked as being able to participate in request scheduling in the seven-layer load balancer. In the forwardable state, the instance can normally receive request traffic and return responses.

[0192] Furthermore, a forwardable instance refers to a service instance that has been restored to the seven-layer load balancer, and its service status is set to available, indicating that the instance has returned to normal and is participating in traffic forwarding again.

[0193] As you can understand, based on the instance information, the Layer 7 load balancer configuration API is called to update the service instance status in all target availability zones from non-forwardable to forwardable. The platform also restores the instance-path bindings and re-enables routing for the relevant service domain names. After the operation is complete, the platform encapsulates all successfully restored instances as forwardable instances, which serve as the basis for subsequent service discovery.

[0194] Step S80, restoring the unilateral communication link by prohibiting forwarding routing according to the target, and obtaining a microservice registration instance;

[0195] It should be noted that a unilateral communication link refers to a synchronization data path in a certain direction in the microservice registration and discovery center, such as the route of a synchronization service instance from a normal availability zone to a target availability zone.

[0196] Furthermore, a microservice registration instance refers to a service instance that has been re-enabled in the service registration discovery center and can participate in the service discovery process normally and be queried by other services.

[0197] As can be understood, the target prohibited forwarding route is used to reversely restore the disconnected service registration path. The platform calls the registry center interface to reestablish the unilateral communication link, enabling the target availability zone to re-initiate service synchronization data from other availability zones. Once restored, the service instances in the target availability zone are reintegrated into the service registration discovery process, becoming available microservice registration instances.

[0198] Step S90: Restoring the request receiving state of the target available zone to allowing reception according to the resolved communication address, the forwardable instance, and the microservice registration instance.

[0199] It's important to note that the request acceptance status refers to the platform's flag indicating whether a particular availability zone is allowed to process client requests. If it is marked as allowed, it means all ingress paths have been restored and the availability zone can provide full service capabilities again.

[0200] It's understood that the platform uses the restored resolved communication address, the re-started forwarding instance, and the registered service instance as input to verify the target availability zone's ability to receive requests. After confirming that all paths, routes, and registration status have returned to normal, the platform updates the request reception status for that availability zone from prohibited to allowed, and synchronizes this information with the load balancer and registry, completing traffic restoration.

[0201] Reference Figure 6 , Figure 6 This is a flow chart of the availability zone traffic recovery scenario in the first embodiment of the microservice-based container platform availability zone failure traffic switching method of this application.

[0202] like Figure 6 As shown in the figure, Module 1 is responsible for isolating traffic between the client microservice container application and the server container application gateway. Module 2 is concerned with isolating unilateral communication between the Nacos microservice registry and discovery center container instances. Module 3 is responsible for notifying the Nacos microservice registry and discovery center of failures or maintenance.

[0203] When traffic restoration is necessary, Modules 2 and 3 execute in parallel with Module 1. Module 1 first restores traffic forwarding for the client microservice container application in the previously maintained / failed AZ. Simultaneously, Module 2 restores unilateral routing communication within the Nacos Microservice Registry and Discovery Center. Through the domain name registry, the Layer 7 load balancing system restores the forwarding configuration for unilateral routes within the previously failed AZ. The Layer 4 load balancing system then simultaneously restores address resolution for these unilateral routes within the failed AZ. Upon completion, the container instances within the Nacos Microservice Registry and Discovery Center will be able to communicate with the container instances in the failed AZ, enabling data synchronization. Simultaneously, Module 3 notifies the microservice registry of the restored AZ range, enabling it to conditionally restore forwarding for container IP instances in the previously isolated AZ. After Module 2 executes, the program waits for data synchronization with the Nacos Microservice Registry and Discovery Center. Once service is restored, Module 1 is executed again for the container cluster containing the Nacos Microservice Registry and Discovery Center server application, restoring traffic to the application gateway in the previously isolated AZ on the Nacos Microservice Registry and Discovery Center server.

[0204] In a feasible implementation, after re-registering the instance and restoring the load balancing configuration, the platform does not immediately open the request receiving permission to all instances. Instead, it implements batch recovery and gradual access of service instances in the target availability zone through configurable time windows and instance health detection cycles, avoiding recovery failure or cascading failure caused by instantaneous large traffic backflow.

[0205] In this embodiment, when the fault ends or maintenance is completed, after the administrator performs AZ traffic restoration, the domain name registration center will reintegrate the previously isolated AZ into the available backend of the seven-layer load balancer so that the AZ can carry traffic normally. Then the four-layer load balancer will restore the DNS resolution of the AZ domain name, thereby restoring the traffic forwarding of the previously isolated traffic AZ. When the fault is restored, the administrator calls the domain name registration center through the tool and passes in the AZ or container cluster range to be restored. After the domain name registration center obtains the AZ range, it will reintegrate the AZ backend to be restored into the backend of the seven-layer load balancer so that it can carry traffic normally. Then, the A records of these external routes will be restored in the four-layer load balancer so that it can be resolved normally to the AZ of the previously isolated traffic, thereby restoring the communication between the normal AZ and the faulty AZ of the Nacos microservice registration and discovery center. At this time, if the client requests these isolated external routes, the seven-layer load balancer will forward the request normally.

[0206] This embodiment provides a method for switching traffic in the availability zone of a microservice-based container platform. When the target availability zone is restored to an available state, the method reads and restores the previously disabled instance forwarding configuration, re-establishes the service domain name resolution records and instance forwarding status in the four-layer and seven-layer load balancers, and restores the unilateral communication link of the microservice registration and discovery center. This method solves the technical problem of how to effectively restore the traffic in the availability zone after a failure or maintenance in the microservice container platform and ensure service continuity and data consistency, thereby achieving the beneficial effects of quickly restoring service capabilities after failure recovery, reducing service interruption time, and improving platform reliability and user satisfaction.

[0207] It should be noted that the above examples are only used to understand this application and do not constitute a limitation on the method of traffic switching in the availability zone of a microservice-based container platform in this application. More simple transformations based on this technical concept are all within the scope of protection of this application.

[0208] This application also provides a microservice-based container platform available zone failure flow switching device, please refer to Figure 7 The microservice-based container platform available zone failure traffic switching device includes:

[0209] The identification acquisition module 10 is used to acquire identification information of the target availability zone when detecting that traffic isolation of the target availability zone is triggered;

[0210] An instance configuration module 20 is configured to modify the load balancing configuration of the microservice container application and the microservice registration discovery center according to the identification information to obtain a disabled instance forwarding configuration;

[0211] A routing prohibition module 30 is configured to cut off the unilateral data route according to the identification information and obtain a target prohibited forwarding route;

[0212] The traffic switching module 40 is used to isolate traffic based on the disabled instance forwarding configuration and the target prohibited forwarding route, and complete traffic switching for the available zone failure of the microservice-based container platform.

[0213] The microservice-based container platform availability zone fault traffic switching device provided in this application adopts the microservice-based container platform availability zone fault traffic switching method in the above-mentioned embodiment, which can solve the technical problem that in a multi-availability zone deployment environment, the service registration and discovery center cannot achieve efficient and stable traffic isolation and switching when an availability zone-level failure occurs. Compared with the existing technology, the beneficial effects of the microservice-based container platform availability zone fault traffic switching device provided in this application are the same as the beneficial effects of the microservice-based container platform availability zone fault traffic switching method provided in the above-mentioned embodiment, and the other technical features of the microservice-based container platform availability zone fault traffic switching device are the same as the features disclosed in the above-mentioned embodiment method, and are not repeated here.

[0214] In one embodiment, the instance configuration module 20 is further used to modify the backend instance configuration of the microservice container application and the microservice registration and discovery center according to the identification information to obtain a configuration for disabling external routing access; modify the container instance configuration of the microservice registration and discovery center according to the identification information to obtain a configuration for disabling container instance port access; and obtain a configuration for disabling instance forwarding based on the configuration for disabling external routing access and the configuration for disabling container instance port access.

[0215] In one embodiment, the instance configuration module 20 is also used to delete the address resolution record of the service domain name of the target availability zone in the four-layer load balancing of the microservice container application and the microservice registration discovery center according to the identification information, and obtain the unbound address availability zone; obtain the service instance binding relationship of the unbound address availability zone according to the identification information; call the four-layer load balancer interface of the microservice registration discovery center according to the service instance binding relationship to obtain the current backend service instance status; set the current backend service instance status to a prohibited forwarding state, and update the availability zone mapping in the forwarding control table to obtain a prohibited external routing configuration.

[0216] In one embodiment, the instance configuration module 20 is further used to extract a container cluster list of the target availability zone in the container orchestration platform based on the identification information; call the message receiving interface of the microservice registration and discovery center based on the container cluster list to obtain the faulty container cluster; obtain the faulty IP and faulty port of the faulty container instance based on the faulty container cluster; modify the access status of the faulty IP and the faulty port to stop forwarding access, and obtain a configuration for disabling container instance port access.

[0217] In one embodiment, the routing prohibition module 30 is further used to identify the fault range and the fault domain name based on the identification information, and obtain the fault external route based on the fault range and the fault domain name; delete the fault routing configuration in the seven-layer load balancer based on the fault external route to obtain a communication isolation seven-layer load balancer; delete the address resolution record of the target availability zone in the four-layer load balancer based on the fault external route to obtain a communication isolation four-layer load balancer; obtain the target prohibited forwarding route based on the communication isolation seven-layer load balancer and the communication isolation four-layer load balancer.

[0218] In one embodiment, the identification acquisition module 10 is further used to obtain the numbering information of the target availability zone when detecting that traffic isolation of the target availability zone is triggered; obtain the container orchestration platform cluster list deployed in the target availability zone based on the numbering information; obtain the running microservice container application list and the service instance configuration of the microservice registration and discovery center based on the container orchestration platform cluster list; generate the identification information of the target availability zone based on the microservice container application list and the service instance configuration, and the identification information includes the cluster number, service domain name, load balancing instance identifier and backend IP list.

[0219] In one embodiment, the traffic switching module 40 is further used to read the instance information of the disabled instance forwarding configuration when it is detected that the traffic isolation of the target availability zone has ended; restore the address resolution record of the target availability zone service domain name in the four-layer load balancer according to the instance information to obtain the resolved communication address; set the service instance status of the target availability zone in the seven-layer load balancer to a forwarding state according to the instance information to obtain a forwarding instance; restore the unilateral communication link according to the target prohibited forwarding route to obtain a microservice registration instance; and restore the request reception status of the target availability zone to allow reception according to the resolved communication address, the forwarding instance, and the microservice registration instance.

[0220] The present application provides a microservice-based container platform availability zone fault traffic switching device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the microservice-based container platform availability zone fault traffic switching method in the above-mentioned embodiment 1.

[0221] Reference below Figure 8, which shows a schematic diagram of the structure of a microservice-based container platform availability zone fault traffic switching device suitable for implementing an embodiment of the present application. The microservice-based container platform availability zone fault traffic switching device in the embodiment of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (such as in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The illustrated microservice-based container platform availability zone fault traffic switching device is merely an example and should not limit the functionality and scope of use of the embodiments of the present application.

[0222] like Figure 8 As shown, the microservice-based container platform availability zone fault traffic switching device may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in ROM (Read Only Memory) 1002 or the program loaded from the storage device 1003 to RAM (Random Access Memory) 1004. Various programs and data required for the operation of the microservice-based container platform availability zone fault traffic switching device are also stored in RAM 1004. The processing device 1001, ROM 1002 and RAM 1004 are connected to each other via a bus 1005. The input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, hard disk, etc.; and communication devices 1009. The communication devices 1009 can allow the microservices-based container platform availability zone fault traffic switching device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a microservices-based container platform availability zone fault traffic switching device with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented or have instead.

[0223] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0224] The microservice-based container platform availability zone fault traffic switching device provided in this application adopts the microservice-based container platform availability zone fault traffic switching method in the above-mentioned embodiment, which can solve the technical problem that in a multi-availability zone deployment environment, the service registration and discovery center cannot achieve efficient and stable traffic isolation and switching when an availability zone-level failure occurs. Compared with the existing technology, the beneficial effects of the microservice-based container platform availability zone fault traffic switching device provided in this application are the same as the beneficial effects of the microservice-based container platform availability zone fault traffic switching method provided in the above-mentioned embodiment, and the other technical features of the microservice-based container platform availability zone fault traffic switching device are the same as the features disclosed in the previous embodiment method, which will not be repeated here.

[0225] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0226] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0227] The present application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, and the computer-readable program instructions are used to execute the microservice-based container platform availability zone fault traffic switching method in the above-mentioned embodiment.

[0228] The computer-readable storage medium provided in this application can be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination thereof. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, RAM (Random Access Memory), ROM (Read Only Memory), Erasable Programmable Read Only Memory (Erasable Programmable Read Only Memory or flash memory, EPROM), optical fiber, CD-ROM (CD-Read Only Memory, portable compact disk read-only memory), optical storage device, magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium can be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0229] The above-mentioned computer-readable storage medium can be included in the microservice-based container platform availability zone fault traffic switching device; or it can exist independently without being assembled into the microservice-based container platform availability zone fault traffic switching device.

[0230] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the microservice-based container platform availability zone fault traffic switching device, the microservice-based container platform availability zone fault traffic switching device: when detecting the traffic isolation that triggers the target availability zone, obtains the identification information of the target availability zone; modifies the load balancing configuration of the microservice container application and the microservice registration discovery center according to the identification information to obtain a disabled instance forwarding configuration; cuts off the unilateral data route according to the identification information to obtain a target prohibited forwarding route; performs traffic isolation according to the disabled instance forwarding configuration and the target prohibited forwarding route, and completes the microservice-based container platform availability zone fault traffic switching.

[0231] The computer program code for performing the operations of the present application can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a LAN (Local Area Network) or a WAN (Wide Area Network), or can be connected to an external computer (e.g., using an Internet service provider to connect via the Internet).

[0232] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0233] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0234] The readable storage medium provided by this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., a computer program) for executing the above-mentioned microservice-based container platform availability zone failure traffic switching method, which can solve the technical problem that the service registration and discovery center cannot achieve efficient and stable traffic isolation and switching when an availability zone-level failure occurs in a multi-availability zone deployment environment. Compared with the existing technology, the beneficial effects of the computer-readable storage medium provided by this application are the same as the beneficial effects of the microservice-based container platform availability zone failure traffic switching method provided by the above-mentioned embodiment, and will not be repeated here.

[0235] The present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the above-mentioned microservice-based container platform availability zone failure traffic switching method.

[0236] The computer program product provided in this application can resolve the technical issue of a service registration and discovery center being unable to achieve efficient and stable traffic isolation and switching in the event of an availability zone-level failure in a multi-availability zone deployment environment. Compared to the prior art, the beneficial effects of the computer program product provided in this application are similar to those of the microservices-based container platform availability zone failure traffic switching method provided in the aforementioned embodiment, and are not further elaborated here.

[0237] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for traffic switching in available zone failure of a microservice-based container platform, characterized in that: The method comprises: When traffic isolation of a target availability zone is detected to be triggered, obtaining identification information of the target availability zone; Modify the load balancing configuration of the microservice container application and the microservice registration discovery center according to the identification information to obtain a disabled instance forwarding configuration; Cut off the unilateral data route according to the identification information to obtain the target prohibited forwarding route; Traffic isolation is performed according to the disabled instance forwarding configuration and the target prohibited forwarding route, thereby completing traffic switching for the available zone failure of the microservice-based container platform.

2. The method according to claim 1, wherein The step of modifying the load balancing configuration of the microservice container application and the microservice registration discovery center according to the identification information to obtain the disabled instance forwarding configuration includes: Modify the backend instance configuration of the microservice container application and the microservice registration discovery center according to the identification information to obtain a configuration that prohibits external routing access; Modify the container instance configuration of the microservice registration and discovery center according to the identification information to obtain a configuration for prohibiting container instance port access; According to the external routing access prohibition configuration and the container instance port access prohibition configuration, a disabling instance forwarding configuration is obtained.

3. The method according to claim 2, wherein The step of modifying the backend instance configuration of the microservice container application and the microservice registration discovery center according to the identification information to obtain a configuration for prohibiting external routing access includes: Deleting the address resolution record of the service domain name of the target availability zone in the four-layer load balancing of the microservice container application and the microservice registration discovery center according to the identification information, to obtain the unbinding address availability zone; Obtaining a service instance binding relationship of the unbinding address availability zone according to the identification information; Call the four-layer load balancer interface of the microservice registration and discovery center according to the service instance binding relationship to obtain the current backend service instance status; The current backend service instance state is set to a forwarding-disabled state, and the available zone mapping in the forwarding control table is updated to obtain a disabled external routing configuration.

4. The method according to claim 2, wherein The step of modifying the container instance configuration of the microservice registration and discovery center according to the identification information to obtain a configuration for prohibiting container instance port access includes: Extracting a container cluster list of the target availability zone in the container orchestration platform according to the identification information; Call the message receiving interface of the microservice registration and discovery center according to the container cluster list to obtain the faulty container cluster; Obtain the fault IP and fault port of the faulty container instance according to the faulty container cluster; The access status of the faulty IP and the faulty port is modified to stop forwarding access, thereby obtaining a configuration for prohibiting container instance port access.

5. The method according to claim 1, wherein The step of cutting off the unilateral data route according to the identification information to obtain a target forwarding-prohibited route includes: Identify the fault range and the fault domain name according to the identification information, and obtain the fault external route according to the fault range and the fault domain name; Deleting the faulty routing configuration in the seven-layer load balancer according to the faulty external routing to obtain a communication-isolated seven-layer load balancer; Deleting the address resolution record of the target availability zone in the layer-4 load balancing according to the faulty external route, to obtain a communication-isolated layer-4 load balancer; According to the communication isolation seven-layer load balancer and the communication isolation four-layer load balancer, a target prohibited forwarding route is obtained.

6. The method according to claim 1, wherein When traffic isolation of the target availability zone is detected to be triggered, the step of obtaining identification information of the target availability zone includes: When traffic isolation of a target availability zone is detected to be triggered, obtaining the number information of the target availability zone; Obtain a list of container orchestration platform clusters deployed in the target availability zone according to the numbering information; Obtain the running microservice container application list and the service instance configuration of the microservice registration and discovery center according to the container orchestration platform cluster list; The identification information of the target availability zone is generated according to the microservice container application list and the service instance configuration, where the identification information includes the cluster number, service domain name, load balancing instance identifier, and backend IP list.

7. The method according to any one of claims 1 to 6, characterized in that After the step of isolating traffic based on the disabled instance forwarding configuration and the target prohibited forwarding route and completing the microservice-based container platform availability zone failure traffic switching, the method further includes: When detecting that traffic isolation of the target availability zone ends, reading instance information of the disabled instance forwarding configuration; Restore the address resolution record of the target availability zone service domain name in the four-layer load balancer according to the instance information to obtain the resolved communication address; Setting the service instance state of the target availability zone in the seven-layer load balancer to a forwardable state according to the instance information to obtain a forwardable instance; According to the target, forwarding routing is prohibited to restore the unilateral communication link, and a microservice registration instance is obtained; The request reception state of the target availability zone is restored to allowing reception according to the resolved communication address, the forwardable instance, and the microservice registration instance.

8. A microservice-based container platform available zone failure flow switching device, characterized in that: The device comprises: An identification acquisition module, configured to acquire identification information of a target availability zone when traffic isolation of the target availability zone is detected to be triggered; An instance configuration module is used to modify the load balancing configuration of the microservice container application and the microservice registration and discovery center according to the identification information to obtain a disabled instance forwarding configuration; A routing prohibition module, configured to cut off the unilateral data route according to the identification information and obtain a target prohibited forwarding route; The traffic switching module is used to isolate traffic based on the disabled instance forwarding configuration and the target prohibited forwarding route, and complete traffic switching for the available zone failure of the microservice-based container platform.

9. A microservice-based container platform availability zone failure traffic switching device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the method for traffic switching of a microservice-based container platform availability zone failure as described in any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the microservice-based container platform availability zone failure traffic switching method according to any one of claims 1 to 7 are implemented.

Images