Service registration cluster traffic switching method, traffic switching device and storage medium

Abstract

This invention discloses a service registration cluster traffic switching method, a traffic switching device, and a storage medium. The service registration cluster traffic switching method includes the following steps: after the target service registration cluster corresponding to the source service registration cluster to be upgraded passes the readiness check, a target service instance is registered for the target service registration cluster based on the service instance snapshot of the source service registration cluster; when the number of registered services and the number of registered instances corresponding to the target service registration cluster are the same as those corresponding to the source service registration cluster, the internal routing address associated with the external route of the source service registration cluster is modified to the service node corresponding to the target service registration cluster; upon receiving a traffic request from a service registration client, the traffic request is routed to the target service registration cluster. This invention solves the problem of business continuity interruption caused by traffic switching based on domain names.

Description

Technical Field

[0001] This invention relates to the field of cluster upgrades, and more particularly to a method, device and storage medium for switching traffic in a service registration cluster. Background Technology

[0002] In production environments, service registration and discovery centers typically operate in clusters. To improve business processing capabilities, it's often necessary to upgrade these service registration clusters. Upgrading a service registration cluster requires switching traffic between the service nodes.

[0003] During service registration cluster traffic upgrades, the service registration cluster domain name is typically used to switch traffic and complete the upgrade. However, in scenarios involving large-scale service registration clusters, client-side DNS (Domain Name System) limitations at the underlying level can lead to outdated domain name resolution addresses. For example, if device C switches from cluster A to cluster B, its domain name cache may not be cleared, causing it to continue accessing cluster A after the upgrade. In this case, client configuration modifications or restarts are required to update the domain name resolution addresses, resulting in continuity interruptions for business systems using the service registration cluster.

[0004] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this invention is to provide a service registration cluster traffic switching method, traffic switching device, and storage medium to solve the problem of business continuity interruption caused by traffic switching based on domain names in the prior art.

[0006] To achieve the above objectives, the present invention provides a service registration cluster traffic switching method, which includes the following steps:

[0007] After the corresponding target service registration cluster passes the readiness check in the source service registration cluster to be upgraded, the target service instance is registered for the target service registration cluster based on the service instance snapshot of the source service registration cluster.

[0008] When the number of registered services and the number of registered instances corresponding to the target service registration cluster are the same as the data corresponding to the source service registration cluster, the internal route address associated with the external route of the source service registration cluster is modified to the service node corresponding to the target service registration cluster.

[0009] Upon receiving a traffic request from a service registration client, the traffic request is routed to the target service registration cluster.

[0010] Optionally, before the step of registering the target service instance for the target service registration cluster based on the service instance snapshot of the source service registration cluster after the ready check of the corresponding target service registration cluster in the source service registration cluster to be upgraded has passed, the method further includes:

[0011] After the source service registration cluster passes the pre-check, the target service registration cluster corresponding to the source service registration cluster is automatically deployed based on the container application management platform.

[0012] The target service registration cluster is considered ready when each node in the target service registration cluster is in the UP state, each node's DS Replicas are complete and consistent, and each node's interface returns normally.

[0013] Optionally, before the step of automatically deploying the target service registration cluster corresponding to the source service registration cluster based on the container application management platform after the source service registration cluster passes the pre-check, the method further includes:

[0014] Upon receiving the upgrade instruction from the source service registration cluster, determine the domain name distribution strategy for the source service registration cluster;

[0015] If the domain name distribution strategy is balanced distribution, and the service registration client registers using an IP address in the source service registration cluster, the pre-check of the source service registration cluster is deemed to have failed, and the upgrade operation of the source service registration cluster is terminated; or

[0016] After determining the domain name distribution strategy of the source service registration cluster, when it is detected that the service registration client is communicating with the source service registration cluster using internal routing, it is determined that the source service registration cluster's pre-check has failed, and the upgrade action of the source service registration cluster is terminated; otherwise...

[0017] The pre-check of the source service registration cluster has been passed.

[0018] Optionally, after the step of registering the target service instance for the target service registration cluster based on the service instance snapshot of the source service registration cluster, following the step of passing the readiness check of the corresponding target service registration cluster in the source service registration cluster to be upgraded, the method further includes:

[0019] Adjust the self-protection renewal percentage threshold factor of the service registration cluster. When the heartbeat request feedback time of the source service registration cluster is detected to be greater than a preset time, control the source service registration cluster to enter self-protection mode, increase the response waiting time of the heartbeat request, and prevent the service instance of the service registration client from being removed; or

[0020] Heartbeat requests are sent to the target service registration cluster at preset time intervals until the source service registration cluster no longer receives the heartbeat requests, so that the service registration client's request is sent to the target service registration cluster.

[0021] Optionally, the step of modifying the internal route address associated with the external route of the source service registration cluster to the service node corresponding to the target service registration cluster when the number of registered services and the number of registered instances corresponding to the target service registration cluster are the same as those corresponding to the source service registration cluster includes:

[0022] When the number of registered services and the number of registered instances corresponding to the target service registration cluster are the same as the data corresponding to the source service registration cluster, the binding relationship between the external routes and the internal routes of the source service registration cluster is determined.

[0023] When the internal route address associated with the external route is the source service node of the source service registration cluster, the internal route address is modified to the service node of the target service registration cluster.

[0024] Optionally, after receiving the traffic request from the service registration client and routing the traffic request to the target service registration cluster, the method further includes:

[0025] If the number of messages in the source service registration cluster is empty after restarting the source service registration cluster, it is determined that the traffic switch of the source service registration cluster was successful.

[0026] Delete the relevant container resources of the source service registration cluster.

[0027] Optionally, the step of registering a target service instance for the target service registration cluster based on the service instance snapshot of the source service registration cluster after the target service registration cluster corresponding to the source service registration cluster passes the readiness check includes:

[0028] After the target service registration cluster corresponding to the source service registration cluster to be upgraded passes the readiness check, a snapshot of the service instance of the source service registration cluster is obtained and stored on the disk so that the source service registration cluster can perform a data rollback operation.

[0029] Based on the service instance snapshot, register the target service instance for the target service registration cluster.

[0030] Optionally, the method further includes:

[0031] Output the visual operation interface for upgrading the source service registration cluster;

[0032] Based on the operation instructions of the visual operation interface, the corresponding upgrade actions are executed, and the upgrade verification and traffic switching tasks of the source service registration cluster are automatically completed.

[0033] In addition, to achieve the above objectives, the present invention also provides a traffic switching device, which includes a memory, a processor, and a traffic switching program stored in the memory and executable on the processor. When the traffic switching program is executed by the processor, it implements the steps of the service registration cluster traffic switching method as described above.

[0034] In addition, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a traffic switching program, which, when executed by a processor, implements the steps of the service registration cluster traffic switching method described above.

[0035] This invention provides a service registration cluster traffic switching method, a traffic switching device, and a storage medium. After the target service registration cluster corresponding to the source service registration cluster to be upgraded passes the readiness check, the service instance snapshot of the source service registration cluster is used to register the same service instances as the target service registration cluster. When the number of registered services in the source service registration cluster is equal to the data in the target service registration cluster, the internal route address associated with the external route of the source service registration cluster is modified to the service node corresponding to the target service registration cluster. This ensures that traffic requests from service registration clients can be forwarded to the target service registration cluster. During this process, the domain name of the service registration cluster does not change, and the DNS resolution result does not change. Therefore, the service registration client can complete the traffic switching in a very short time, avoiding the problem of service continuity interruption caused by the service registration client's DNS cache not being updated for a long time. This improves the upgrade efficiency of the service registration cluster while ensuring business continuity. Attached Figure Description

[0036] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present invention and, together with the description, serve to explain the principles of the invention. To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0037] Figure 1 This is a flowchart illustrating the first embodiment of the service registration cluster traffic switching method of the present invention.

[0038] Figure 2 This is a schematic diagram of the source service registration cluster architecture upgrade for the service registration cluster traffic switching method of the present invention;

[0039] Figure 3 This is a schematic diagram of client traffic switching after cluster upgrade in the service registration cluster traffic switching method of the present invention;

[0040] Figure 4 This is a schematic diagram of a second embodiment of the service registration cluster traffic switching method of the present invention;

[0041] Figure 5 A flowchart illustrating the third embodiment of the service registration cluster traffic switching method of the present invention;

[0042] Figure 6 This is a schematic diagram illustrating the complete process of source service registration cluster traffic upgrade and switching in the service registration cluster traffic switching method of the present invention;

[0043] Figure 7 These are schematic diagrams of the terminal hardware structure of various embodiments of the service registration cluster traffic switching method of the present invention.

[0044] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0045] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0046] To better understand the above technical solutions, exemplary embodiments of this disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of this disclosure to those skilled in the art.

[0047] Please refer to Figure 1 , Figure 1 This is the first embodiment of the service registration cluster traffic switching method of the present invention.

[0048] In this embodiment, the service registration cluster traffic switching method includes the following steps:

[0049] Step S10: After the ready check of the corresponding target service registration cluster in the source service registration cluster to be upgraded passes, register the target service instance for the target service registration cluster according to the service instance snapshot of the source service registration cluster.

[0050] In this embodiment, the service registration cluster can be a Eureka (service registry) cluster. The source service registration cluster to be upgraded is the source Eureka cluster, and the target service registration cluster is the target Eureka cluster. It can be understood that the source service registration cluster is the Eureka cluster before the upgrade, and the target service registration cluster is the Eureka cluster after the upgrade.

[0051] Specifically, after the source Eureka cluster performs the upgrade and passes the pre-check, a target Eureka cluster corresponding to the source Eureka cluster is automatically deployed based on Kubernetes (a container application management platform). After the target Eureka cluster passes the readiness check for the source Eureka cluster to be upgraded, a snapshot of the current service instances in the source Eureka cluster is obtained and stored on disk. This snapshot is then used by the source service registration cluster for data rollback. Subsequently, based on the service instance snapshot, target service instances are registered for the target Eureka cluster, ensuring that the number of registered services and instances in the source Eureka cluster corresponds consistently with the data in the target Eureka cluster before traffic switching. During this process, heartbeat requests can be continuously injected into the target Eureka cluster to maintain the heartbeat requests for each newly registered service instance.

[0052] It should be noted that the Eureka cluster is deployed on a federated cluster of three Kubernetes clusters, each located in a different Availability Zone (AZ). For example... Figure 2 As shown, the source Eureka cluster consists of three nodes, and each node synchronizes information with the others. The target Eureka cluster consists of six nodes, and each node synchronizes information with the others. Figure 2 (The text uses node A1 as an example to illustrate the communication relationship between nodes.) Figure 2 The target Eureka cluster shown has high availability and better performance than the source Eureka cluster. The upgrade of the source Eureka cluster was not a simple overwrite upgrade; instead, the target Eureka cluster was deployed in a federated cluster of three Kubernetes clusters, and the `spec.to.name` property of the `Route` (external route) resource object was modified to match the `Service` (internal route) resource of the target Eureka cluster. This allows Eureka client traffic requests to be sent to the target Eureka cluster.

[0053] Step S20: When the number of registered services and the number of registered instances corresponding to the target service registration cluster are the same as the data corresponding to the source service registration cluster, the internal route address associated with the external route of the source service registration cluster is modified to the service node corresponding to the target service registration cluster.

[0054] In this embodiment, during the traffic switching process of the Eureka cluster, it is necessary to ensure that the number of registered services and registered instances in the source Eureka cluster are consistent with the data corresponding to the target Eureka cluster. Traffic switching refers to the switching of the binding relationship between the external and internal routes of the Eureka cluster.

[0055] Specifically, when the number of registered services and registered instances corresponding to the target service registration cluster are the same as those corresponding to the source service registration cluster, the binding relationship between the external and internal routes of the source service registration cluster is determined. When the internal route address associated with the external route is the source service node of the source service registration cluster, the internal route address is modified to the service node corresponding to the target service registration cluster. The binding relationship between the external and internal routes of the Eureka cluster is determined by the Route resource object and the Service resource object; that is, the Route resource object is the external route, and the Service resource object is the internal route of the Eureka cluster. The target access address is specified by the spec.to.name attribute in the Route resource object.

[0056] In the Route resource object, the `spec.to.name` property describes the Service associated with it. In the Service resource object, `metadata.labels` selects the POD collection as its Endpoint object. Based on this, Eureka clients can use Route to access the POD instances (nodes in the Eureka cluster) associated with the Service. When the number of registered services and instances in the source Eureka cluster is the same as that in the target Eureka cluster, the system automatically modifies the `spec.to.name` property of the Route resource object to the name of the Service resource object in the target Eureka cluster, thus enabling Eureka client traffic requests to be forwarded to the target Eureka cluster.

[0057] Step S30: After receiving the traffic request from the service registration client, the traffic request is routed to the target service registration cluster.

[0058] In this embodiment, Eureka clients can access the Eureka cluster using a fixed domain name. The system can automatically modify the `spec.to.name` attribute of the route to associate it with the Service resource of the target Eureka cluster.

[0059] For further details, please refer to Figure 3 Before the source Eureka cluster was upgraded, Eureka clients could access the service resources of the source Eureka cluster based on a fixed domain name (as shown by the dashed arrow); however, after the source Eureka cluster was upgraded, the Eureka client's requests changed from the source Eureka cluster to the target Eureka cluster (as shown by the dashed arrow). Figure 3 (As shown by the solid arrow below), this enabled a lossless switching of traffic during the Eureka cluster upgrade process.

[0060] Optionally, after the source service registration cluster upgrade traffic switch is completed, the resources of the source service registration cluster need to be reclaimed to avoid wasting resource costs. At this time, the source service registration cluster needs to be restarted. If the number of services and service instances in the source service registration cluster is empty, it is determined that the traffic switch of the source service registration cluster was successful, and then the relevant container resources of the source service registration cluster are deleted. These relevant container resources include Kubernetes Deployment, ConfigMap, Service, and Route resource objects.

[0061] Optionally, the service registration cluster traffic switching method further includes: outputting a visual operation interface for upgrading the source service registration cluster, executing corresponding upgrade actions according to the operation instructions on the visual operation interface, and automatically completing the upgrade verification and traffic switching tasks of the source service registration cluster. That is, traffic upgrade switching of the source Eureka cluster can be achieved through a visual interface. The entire upgrade process can also be viewed through the current visual interface.

[0062] In the technical solution disclosed in this embodiment, after the target service registration cluster corresponding to the service registration cluster to be upgraded passes the readiness check, the same number of target service instances are registered for the target service registration cluster based on the obtained service instance snapshot of the source service registration cluster. After registration, the spec.to.name attribute of the external route (Route resource object) of the source service registration cluster is modified to the name of the Service resource object of the target service registration cluster, thereby completing the upgrade of the source service registration cluster and enabling the traffic requests of the service registration client to be forwarded to the target service registration cluster. During this process, the domain name of the service registration cluster does not change, and therefore the DNS resolution result does not change (i.e., lossless traffic switching is completed). Therefore, the service registration client can complete the traffic switching in a very short time, and there is no problem of business continuity interruption caused by the service registration client's DNS cache not being updated for a long time, which improves the efficiency of traffic switching and ensures business continuity.

[0063] Reference Figure 4 In the second embodiment, based on the first embodiment, before step S10, the following steps are further included:

[0064] Step S40: After the source service registration cluster passes the pre-check, the target service registration cluster corresponding to the source service registration cluster is automatically deployed based on the container application management platform.

[0065] In this embodiment, if the Eureka cluster passes the pre-check, it means that the Eureka cluster meets the upgrade requirements. Kubernetes can automate the deployment of the Eureka cluster.

[0066] Specifically, after the Eureka cluster pre-check passes, based on the preset FTL (FreeMarker Template Language) template and user requirements, the FreeMarker template engine generates YAML files for Kubernetes Deployment, ConfigMap, Service, and Route resources. Then, the Kubernetes client calls the API Server interface to create the resource objects required by the target Eureka cluster. By default, the newly deployed Eureka cluster (target Eureka cluster) has the same name, security authentication information, container resource specifications, JVM memory parameters, and external routing distribution strategy as the source Eureka cluster. This enables automated deployment of the target service registration cluster.

[0067] Optionally, the pre-check can be performed by checking the domain name distribution strategy of the source service registration cluster and the communication strategy of the service registration client. That is, before step S40, it also includes:

[0068] Upon receiving the upgrade instruction from the source service registration cluster, the domain name distribution strategy of the source service registration cluster is determined. If the domain name distribution strategy is balanced distribution, and the service registration client registers with the source service registration cluster using an IP (Internet Protocol Address) address, the pre-check of the source service registration cluster is determined to have failed, and the upgrade action of the source service registration cluster is terminated. Alternatively, after determining the domain name distribution strategy of the source service registration cluster, if it is detected that the service registration client is communicating with the source service registration cluster using an internal route, the pre-check of the source service registration cluster is determined to have failed, and the upgrade action of the source service registration cluster is terminated. Otherwise, the pre-check of the source service registration cluster is determined to have passed, that is, if neither of the above two situations exists, the pre-check of the source service registration cluster is determined to have passed.

[0069] It should be noted that Eureka clusters have three domain name distribution strategies: source address distribution, balanced distribution, and weighted distribution.

[0070] For example, when the domain name distribution strategy of the Eureka cluster is source address distribution, if a service provider registers using a POD IP (Node Internet Protocol Address), the POD IP of service provider A instance can register with A's Eureka cluster node, the POD IP of service provider B instance can register with B's Eureka cluster node, and the POD IP of service provider C instance can register with C's Eureka cluster node. That is, when registering based on the source address distribution strategy, the POD IP can be registered with the corresponding Eureka cluster node of the service provider. When the service caller discovers a service provider instance with the same Availability Zone (AZ) as its own, the service caller can perform the service call normally.

[0071] When using a balanced distribution strategy, if the upgraded Eureka cluster is deployed in a federated cluster of three Kubernetes clusters, both Eureka client services A and B will register their respective POD IPs in K1, K2, and K3 (a characteristic of the balanced distribution strategy). In this case, if service A in high availability zone K1 wants to call service B, it needs to obtain service B's POD IP in K1. However, since service B is registered with POD IPs in both K2 and K3, if service A in K1 obtains service B's POD IP from K2 or K3, service A cannot access service B, leading to communication problems between services. Therefore, if the domain name distribution strategy of the source service registration cluster is a balanced distribution strategy, this source service registration cluster does not conform to the Kubernetes multi-AZ Eureka upgrade strategy and its upgrade needs to be blocked. Therefore, under a balanced distribution strategy, before upgrading the Eureka cluster, it is necessary to check whether the client has used a POD IP for registration. If a POD IP has been used for registration, the Eureka cluster upgrade should be blocked.

[0072] When the service registration client communicates with the source service registration cluster using internal routing, the internal routing changes after the migration and upgrade of the solution in this invention. This causes the Eureka client to be unable to complete registration in the target Eureka cluster. Therefore, when the Eureka client uses internal routing to communicate with the source Eureka cluster, it is necessary to block the upgrade of the source Eureka cluster.

[0073] If the source Eureka cluster does not meet all of the above conditions, it means that the pre-check has passed, that is, the source Eureka cluster pre-check has passed.

[0074] Step S50: When the status of each node in the target service registration cluster is UP, the DSReplicas of each node are complete and consistent, and the interface of each node returns normally, it is determined that the target service registration cluster has passed the readiness test.

[0075] In this embodiment, the FTL template deployed in the Eureka cluster is configured with liveness probes and ready probes, and detection is performed based on these liveness probes and ready probes. To further ensure the availability of the Eureka cluster after deployment, a secondary detection is required on the newly deployed Eureka cluster (i.e., the target Eureka cluster). The detection includes: determining whether the status of each node in the target Eureka cluster is UP, whether the DS Replicas of each node are complete and consistent, and whether the / eureka / apps (Application Service) interface of each node returns normally.

[0076] In the technical solution disclosed in this embodiment, a pre-check is performed on the source service registration cluster to filter out service registration clusters that do not meet the upgrade requirements, thereby avoiding a decrease in the availability of the target service registration cluster after the upgrade. After the source service registration cluster passes the pre-check, the corresponding target service registration cluster can be automatically deployed based on Kubernetes, thereby improving the availability of the upgraded service registration cluster.

[0077] Reference Figure 5 In the third embodiment, based on the first embodiment, after step S10, the method further includes:

[0078] Step S60: Adjust the self-protection renewal percentage threshold factor of the service registration cluster. When the heartbeat request feedback time of the source service registration cluster is detected to be greater than a preset time, control the source service registration cluster to enter the self-protection mode, increase the corresponding waiting time of the heartbeat request, and prevent the service instance of the service registration client from being removed.

[0079] In this embodiment, even after the binding relationship between the external and internal routes of the Eureka cluster is switched, there is still a certain time lag between the update of the BACKEND (POD IP) information associated with the external route and the change of the binding relationship. This can cause some Eureka client requests to enter the target Eureka cluster first, while others remain in the source Eureka cluster, resulting in a loss of business traffic for Eureka clients. Therefore, in this extreme scenario, a self-protection mechanism can be set up, such as adjusting the self-protection renewal percentage threshold factor (eureka.server.renewal-percent-threshold) to 0.49, thereby increasing the protection duration of the service instance.

[0080] If the heartbeat request response time is longer than the preset time, it indicates that there are Eureka client requests that have not been sent to the target Eureka cluster. In this case, it is necessary to control the source Eureka cluster to enter self-protection mode, increase the waiting time, and prevent the Eureka client service instance from being removed due to exceeding the preset time.

[0081] For example, if the current service instance protection duration is 90 seconds, by setting the self-protection renewal percentage threshold factor to 0.49, the heartbeat judgment duration of the service instance is increased, and then when the heartbeat of the source Eureka cluster drops rapidly, it enters the self-protection mode to prevent the service instance of the source Eureka cluster from being removed.

[0082] It should be noted that the above data is for illustrative purposes only and is not intended to limit the scope of this invention.

[0083] Optionally, in addition to this, heartbeat requests can be sent to the target service registration cluster at preset time intervals until the source service registration cluster no longer receives the heartbeat requests, thus ensuring that requests from the service registration client are sent to the target service registration cluster. That is, by sending simulated heartbeat requests, the target Eureka cluster is prevented from missing requests from the current Eureka client. When the source Eureka cluster no longer receives heartbeat requests, it indicates that all requests from the Eureka client have been sent to the target Eureka cluster.

[0084] In the technical solution disclosed in this embodiment, to avoid the failure of Eureka client messages to be sent to the source Eureka cluster in extreme scenarios, the self-protection renewal percentage threshold factor can be adjusted to improve the heartbeat request response time. Based on this, the service instance of the Eureka client is prevented from being removed prematurely. At the same time, the current heartbeat request can be simulated to periodically send heartbeat requests to the target Eureka cluster until the source Eureka cluster no longer receives heartbeat requests. This ensures that all requests from the Eureka client are sent to the target Eureka cluster, so that even if there is still traffic from the Eureka client remaining in the source Eureka cluster, service discovery can still be performed normally, thereby ensuring business continuity.

[0085] In the fourth embodiment, the specific process of the service registration cluster traffic switching method is as follows: Figure 6 As shown.

[0086] For example, in this embodiment, all source Eureka clusters are in a pending state by default. When a user can initiate a pre-check phase through a visual interface or code input, the upgrade action of a source Eureka cluster with a balanced domain distribution strategy and registered using a POD IP is blocked, or the upgrade action of the source Eureka cluster is blocked when the Eureka client communicates with the source Eureka cluster using internal routing (a prompt indicating that the current Eureka cluster cannot be upgraded can be output). Subsequently, it is determined that the pre-check of source Eureka clusters that do not meet the above conditions has passed, and a prompt is output asking whether to proceed to the next step. When the user confirms to proceed to the next stage, namely the high availability instance deployment stage, the corresponding target Eureka cluster is deployed based on Kubernetes for the source Eureka clusters that meet the upgrade conditions. After the deployment is completed, based on the received confirmation command, the status of each node of the target Eureka cluster is checked to see if it is UP, whether the DS Replicas of each node are complete and consistent, and whether the / eureka / apps interface of each node returns normally, etc. Based on the detection results, it is determined whether the readiness check has passed.

[0087] Please continue to refer to Figure 6 After the target Eureka cluster passes the readiness check, based on the obtained execution instructions, a snapshot of the service instances of the source Eureka cluster to be upgraded is retrieved. Service instances with the same data are then registered for the target Eureka cluster according to the service instance snapshot, thus synchronizing instances between the source and target Eureka clusters. The synchronization results are then checked. If the number of registered services and registered instances are the same, traffic switching is performed. This involves modifying the `spec.to.name` property of the `Route` resource object to the name of the `Service` resource object corresponding to the target Eureka cluster, ensuring that traffic requests from Eureka clients can be sent to the target Eureka cluster. During instance synchronization startup, appropriate protection mechanisms need to be set for the target Eureka cluster. These mechanisms can be used to verify traffic requests sent by Eureka clients. Once verification is successful, the instance synchronization task is stopped, and the registration information of the target Eureka cluster is checked. After successful verification, metadata is updated. This completes the upgrade process from the source Eureka cluster to the target Eureka cluster.

[0088] In the technical solution disclosed in this embodiment, during the upgrade of the source Eureka cluster, it is necessary to perform upgrade verification of the source Eureka cluster, deployment of the corresponding target Eureka cluster, and post-deployment checks of the target Eureka cluster. Subsequently, upon receiving a user's corresponding instruction, an instance information synchronization task is executed. After the instance information synchronization is completed, traffic switching, verification after traffic switching, and cessation of the instance synchronization task after successful verification are performed based on user instructions. Finally, registration information checks are performed on the target Eureka cluster, and metadata updates are completed after successful checks. During the complete traffic upgrade and switching process of the source Eureka cluster, the user can view the upgrade process in real time and execute the next stage of traffic upgrade and switching based on the user's confirmation instructions at each stage. This allows the source Eureka cluster upgrade process to be displayed visually and enables real-time control over whether to continue the upgrade action, thereby improving the operability of the source Eureka cluster upgrade and its usability after the upgrade, while also avoiding interruptions to Eureka client services.

[0089] Reference Figure 7 , Figure 7 This is a schematic diagram of the terminal structure of the hardware operating environment involved in the embodiments of the present invention.

[0090] like Figure 7 As shown, the terminal may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a network interface 1003, and a memory 1004. The communication bus 1002 is used to enable communication between these components. The network interface 1003 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1004 may be high-speed random access memory (RAM) or stable non-volatile memory (NVM), such as a disk drive. Alternatively, the memory 1004 may be a storage device independent of the aforementioned processor 1001.

[0091] Those skilled in the art will understand that Figure 7 The terminal structure shown does not constitute a limitation on the terminal and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0092] like Figure 7 As shown, the memory 1004, which serves as a computer storage medium, may include an operating system, a data storage module, a network communication module, and a traffic switching program.

[0093] exist Figure 7 In the terminal shown, network interface 1003 is mainly used to connect to the backend server and communicate with it; processor 1001 can call the traffic switching program stored in memory 1004 and perform the following operations:

[0094] After the corresponding target service registration cluster passes the readiness check in the source service registration cluster to be upgraded, the target service instance is registered for the target service registration cluster based on the service instance snapshot of the source service registration cluster.

[0095] When the number of registered services and the number of registered instances corresponding to the target service registration cluster are the same as the data corresponding to the source service registration cluster, the internal route address associated with the external route of the source service registration cluster is modified to the service node corresponding to the target service registration cluster.

[0096] Upon receiving a traffic request from a service registration client, the traffic request is routed to the target service registration cluster.

[0097] Furthermore, the processor 1001 can call the flow switching program stored in the memory 1004 and also perform the following operations:

[0098] After the source service registration cluster passes the pre-check, the target service registration cluster corresponding to the source service registration cluster is automatically deployed based on the container application management platform.

[0099] The target service registration cluster is considered ready when each node in the target service registration cluster is in the UP state, each node's DS Replicas are complete and consistent, and each node's interface returns normally.

[0100] Furthermore, the processor 1001 can call the flow switching program stored in the memory 1004 and also perform the following operations:

[0101] Upon receiving the upgrade instruction from the source service registration cluster, determine the domain name distribution strategy for the source service registration cluster;

[0102] If the domain name distribution strategy is balanced distribution, and the service registration client registers using an IP address in the source service registration cluster, the pre-check of the source service registration cluster is deemed to have failed, and the upgrade operation of the source service registration cluster is terminated; or

[0103] After determining the domain name distribution strategy of the source service registration cluster, when it is detected that the service registration client is communicating with the source service registration cluster using internal routing, it is determined that the source service registration cluster's pre-check has failed, and the upgrade action of the source service registration cluster is terminated; otherwise...

[0104] The pre-check of the source service registration cluster has been passed.

[0105] Furthermore, the processor 1001 can call the flow switching program stored in the memory 1004 and also perform the following operations:

[0106] Adjust the self-protection renewal percentage threshold factor of the service registration cluster. When the heartbeat request feedback time of the source service registration cluster is detected to be greater than a preset time, control the source service registration cluster to enter self-protection mode, increase the response waiting time of the heartbeat request, and prevent the service instance of the service registration client from being removed; or

[0107] Heartbeat requests are sent to the target service registration cluster at preset time intervals until the source service registration cluster no longer receives the heartbeat requests, so that the service registration client's request is sent to the target service registration cluster.

[0108] Furthermore, the processor 1001 can call the flow switching program stored in the memory 1004 and also perform the following operations:

[0109] When the number of registered services and the number of registered instances corresponding to the target service registration cluster are the same as the data corresponding to the source service registration cluster, the binding relationship between the external routes and the internal routes of the source service registration cluster is determined.

[0110] When the internal route address associated with the external route is the source service node of the source service registration cluster, the internal route address is modified to the service node of the target service registration cluster.

[0111] Furthermore, the processor 1001 can call the flow switching program stored in the memory 1004 and also perform the following operations:

[0112] If the number of messages in the source service registration cluster is empty after restarting the source service registration cluster, it is determined that the traffic switch of the source service registration cluster was successful.

[0113] Delete the relevant container resources of the source service registration cluster.

[0114] Furthermore, the processor 1001 can call the flow switching program stored in the memory 1004 and also perform the following operations:

[0115] After the target service registration cluster corresponding to the source service registration cluster to be upgraded passes the readiness check, a snapshot of the service instance of the source service registration cluster is obtained and stored on the disk so that the source service registration cluster can perform a data rollback operation.

[0116] Based on the service instance snapshot, register the target service instance for the target service registration cluster.

[0117] Furthermore, the processor 1001 can call the flow switching program stored in the memory 1004 and also perform the following operations:

[0118] Output the visual operation interface for upgrading the source service registration cluster;

[0119] Based on the operation instructions of the visual operation interface, the corresponding upgrade actions are executed, and the upgrade verification and traffic switching tasks of the source service registration cluster are automatically completed.

[0120] Furthermore, those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the control terminal to implement the process steps of the embodiments of the above methods.

[0121] Therefore, the present invention also provides a computer-readable storage medium storing a traffic switching program, which, when executed by a processor, implements the various steps of the service registration cluster traffic switching method as described in the above embodiments.

[0122] It should be noted that, since the storage medium provided in the embodiments of this application is the storage medium used to implement the methods of the embodiments of this application, those skilled in the art can understand the specific structure and variations of the storage medium based on the methods described in the embodiments of this application, and therefore will not be repeated here. All storage media used in the methods of the embodiments of this application fall within the scope of protection of this application.

[0123] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0124] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0125] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0126] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0127] It should be noted that any reference signs placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0128] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0129] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

[0130] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for switching traffic in a service registration cluster, characterized in that, The service registration cluster traffic switching method includes: After the source service registration cluster passes the pre-check, the target service registration cluster corresponding to the source service registration cluster is automatically deployed based on the container application management platform. The pre-check method is to check the domain name distribution strategy of the source service registration cluster and the communication strategy of the service registration client. The domain name distribution strategy includes source address distribution, balanced distribution and weighted distribution. The target service registration cluster is considered ready when each node in the target service registration cluster is in the UP state, each node's DS Replicas are complete and consistent, and each node's interface returns normally. After the corresponding target service registration cluster passes the readiness check in the source service registration cluster to be upgraded, the target service instance is registered for the target service registration cluster based on the service instance snapshot of the source service registration cluster. The source service registration cluster is the Eureka cluster before the upgrade, and the target service registration cluster is the Eureka cluster after the upgrade. When the number of registered services and the number of registered instances corresponding to the target service registration cluster are the same as the data corresponding to the source service registration cluster, the internal route address associated with the external route of the source service registration cluster is modified to the service node corresponding to the target service registration cluster. Here, the traffic switching refers to the switching of the binding relationship between the external route and the internal route of the Eureka cluster. Upon receiving a traffic request from a service registration client, the traffic request is routed to the target service registration cluster.

2. The service registration cluster traffic switching method as described in claim 1, characterized in that, Before the step of automatically deploying the target service registration cluster corresponding to the source service registration cluster based on the container application management platform after the source service registration cluster passes the pre-check, the following steps are also included: Upon receiving the upgrade instruction from the source service registration cluster, determine the domain name distribution strategy for the source service registration cluster; If the domain name distribution strategy is balanced distribution, and the service registration client registers using an IP address in the source service registration cluster, the pre-check of the source service registration cluster is deemed to have failed, and the upgrade operation of the source service registration cluster is terminated; or After determining the domain name distribution strategy of the source service registration cluster, when it is detected that the service registration client is communicating with the source service registration cluster using internal routing, it is determined that the source service registration cluster's pre-check has failed, and the upgrade action of the source service registration cluster is terminated; otherwise... The pre-check of the source service registration cluster has been passed.

3. The service registration cluster traffic switching method as described in claim 1, characterized in that, After the ready check of the target service registration cluster corresponding to the source service registration cluster to be upgraded passes, and the step of registering the target service instance for the target service registration cluster based on the service instance snapshot of the source service registration cluster is followed by: Adjust the self-protection renewal percentage threshold factor of the service registration cluster. When the heartbeat request feedback time of the source service registration cluster is detected to be greater than a preset time, control the source service registration cluster to enter self-protection mode, increase the response waiting time of the heartbeat request, and prevent the service instance of the service registration client from being removed; or Heartbeat requests are sent to the target service registration cluster at preset time intervals until the source service registration cluster no longer receives the heartbeat requests, so that the service registration client's request is sent to the target service registration cluster.

4. The service registration cluster traffic switching method as described in claim 1, characterized in that, The step of modifying the internal route address associated with the external route of the source service registration cluster to the service node corresponding to the target service registration cluster when the number of registered services and registered instances corresponding to the target service registration cluster are the same as those corresponding to the source service registration cluster includes: When the number of registered services and the number of registered instances corresponding to the target service registration cluster are the same as the data corresponding to the source service registration cluster, the binding relationship between the external routes and the internal routes of the source service registration cluster is determined. When the internal route address associated with the external route is the source service node of the source service registration cluster, the internal route address is modified to the service node of the target service registration cluster.

5. The service registration cluster traffic switching method as described in claim 1, characterized in that, After receiving the traffic request from the service registration client and routing the traffic request to the target service registration cluster, the method further includes: If the number of business registration instances in the source service registration cluster is empty after restarting the source service registration cluster, it is determined that the traffic switch of the source service registration cluster was successful. Delete the relevant container resources of the source service registration cluster.

6. The service registration cluster traffic switching method as described in claim 1, characterized in that, After the target service registration cluster corresponding to the source service registration cluster to be upgraded passes the readiness check, the step of registering the target service instance for the target service registration cluster based on the service instance snapshot of the source service registration cluster includes: After the target service registration cluster corresponding to the source service registration cluster to be upgraded passes the readiness check, a snapshot of the service instance of the source service registration cluster is obtained and stored on the disk so that the source service registration cluster can perform a data rollback operation. Based on the service instance snapshot, register the target service instance for the target service registration cluster.

7. The service registration cluster traffic switching method as described in claim 1, characterized in that, The method further includes: Output the visual operation interface for upgrading the source service registration cluster; Based on the operation instructions of the visual operation interface, the corresponding upgrade actions are executed, and the upgrade verification and traffic switching tasks of the source service registration cluster are automatically completed.

8. A flow switching device, characterized in that, The traffic switching device includes: a memory, a processor, and a traffic switching program stored in the memory and executable on the processor. When the traffic switching program is executed by the processor, it implements the steps of the service registration cluster traffic switching method as claimed in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a traffic switching program, which, when executed by a processor, implements the steps of the service registration cluster traffic switching method as described in any one of claims 1 to 7.

Images