Application service migration method, electronic equipment and storage medium

Abstract

The invention discloses an application service migration method, electronic equipment and a storage medium. The application service migration method is applied to a source cluster. The application service migration method comprises the following steps: establishing an encryption and decryption node and an agent node in the source cluster; the acquired to-be-migrated information of the application service is migrated to a target cluster through the proxy node in the source cluster and the encryption and decryption node in the source cluster, so that the target cluster processes the to-be-migrated information, and the source cluster and the target cluster establish communication connection through the encryption and decryption node in the source cluster and the encryption and decryption node in the target cluster. According to the scheme, the stability of application service migration can be improved.

Description

Technical Field

[0001] This application relates to the field of cluster technology, and in particular to an application service migration method, electronic device, and storage medium. Background Technology

[0002] As business scales and data center planning and construction evolve, application systems need to be migrated from currently resource-depleted data center rooms to newly built data centers with ample resources. Typically, this requires stopping service processes and shutting down virtual machines. However, after migrating virtual machines to the new data center and configuring them with new addresses to start application services, there may be application service interruptions, resulting in lower stability during the migration.

[0003] Therefore, there is an urgent need for an effective method for migrating application services. Summary of the Invention

[0004] This application provides at least one application service migration method, electronic device, and storage medium, which can improve the stability of application service migration.

[0005] To address the aforementioned technical problems, this application provides a method for migrating application services. This method is applied to a source cluster and includes: establishing encryption / decryption nodes and proxy nodes in the source cluster; migrating the acquired application service migration information to the target cluster via the proxy nodes and encryption / decryption nodes in the source cluster, so that the target cluster can process the migration information; and establishing a communication connection between the source cluster and the target cluster via the encryption / decryption nodes in the source and target clusters.

[0006] To address the aforementioned technical issues, another technical solution adopted in this application is: providing an application service migration method. This method is applied to a target cluster and includes: establishing encryption / decryption nodes and proxy nodes in the target cluster; receiving application service migration information sent by the source cluster through the proxy nodes and encryption / decryption nodes in the target cluster; processing the migration information to obtain the migrated target cluster; and establishing a communication connection between the source cluster and the target cluster through the encryption / decryption nodes in the source cluster and the target cluster.

[0007] To solve the above-mentioned technical problems, another technical solution adopted in this application is: This application provides an application service migration system, which includes a source cluster and a target cluster. The above-mentioned application service migration method is applied to the source cluster in the application service migration system. Specifically, the source cluster in the application service migration system is used to: build encryption / decryption nodes and proxy nodes in the source cluster; migrate the obtained application service migration information to the target cluster through the proxy nodes and encryption / decryption nodes in the source cluster, so that the target cluster can process the migration information; and establish a communication connection between the source cluster and the target cluster through the encryption / decryption nodes in the source cluster and the encryption / decryption nodes in the target cluster.

[0008] To solve the above-mentioned technical problems, another technical solution adopted in this application is: This application provides an application service migration system, which includes a source cluster and a target cluster. The above-mentioned application service migration method is applied to the target cluster in the application service migration system. Specifically, the target cluster in the application service migration system is used to: build encryption / decryption nodes and proxy nodes in the target cluster; receive the application service to be migrated information sent by the source cluster through the proxy nodes and encryption / decryption nodes in the target cluster, and process the to-be-migrated information to obtain the migrated target cluster; the source cluster and the target cluster establish a communication connection through the encryption / decryption nodes in the source cluster and the encryption / decryption nodes in the target cluster.

[0009] This application provides an electronic device, including a memory and a processor, wherein the memory stores program instructions, and the processor retrieves program instructions from the memory to implement the above-described application service migration method.

[0010] This application provides a computer-readable storage medium storing program instructions thereon, which, when executed by a processor, implement the above-described application service migration method.

[0011] The above-described solution involves setting up encryption / decryption nodes and proxy nodes in the source cluster. The application service migration information is then migrated to the target cluster via the proxy nodes and encryption / decryption nodes in the source cluster. This allows the target cluster to process the migration information. The source and target clusters establish a communication connection through the encryption / decryption nodes in the source and target clusters. As a result, the application service can be migrated from the source cluster to the target cluster without shutting down the application service, thus improving the overall migration stability.

[0012] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0014] Figure 1 This is a flowchart illustrating an embodiment of the application service migration method of this application; Figure 2 This is a first-stage framework diagram of an embodiment of the application service migration method of this application; Figure 3 yes Figure 1 A schematic diagram of the sub-process of step S12; Figure 4 This is a second-stage framework diagram in one embodiment of the application service migration method of this application; Figure 5 This is a schematic diagram of information interaction between the source cluster and the target cluster in one embodiment of the application service migration method of this application; Figure 6 This is a framework diagram of the third stage in one embodiment of the application service migration method of this application; Figure 7 This is a framework diagram of the fourth stage in one embodiment of the application service migration method of this application; Figure 8 This is a framework diagram of the fifth stage in one embodiment of the application service migration method of this application; Figure 9 This is another flowchart illustrating an embodiment of the application service migration method of this application; Figure 10 This is a schematic diagram of the structure of an embodiment of the migration system for the application services of this application; Figure 11 This is a schematic diagram of the structure of another embodiment of the migration system for the application services of this application; Figure 12 This is a schematic diagram of the structure of an embodiment of the electronic device of this application; Figure 13 This is a schematic diagram of the structure of an embodiment of the computer-readable storage medium of this application. Detailed Implementation

[0015] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0016] In the following description, specific details such as particular system architectures, interfaces, and technologies are presented for illustrative purposes rather than for limiting purposes, in order to provide a thorough understanding of this application.

[0017] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, "many" in this document means two or more. Moreover, the term "at least one" in this document means any combination of at least two of any one or more of a plurality of objects. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0018] This application provides several application service migration methods and systems. The application service migration methods can be applied to scenarios including, but are not limited to, migrating an application service's deployed cluster from a source cluster to a target cluster. The execution entity of the application service migration method can be an application service migration system. The application service migration system includes a source cluster and a target cluster. In some application scenarios, the execution entity of the application service migration method can be either the source cluster or the target cluster. In other application scenarios, the execution entity can be the application service migration system, specifically the source cluster and the target cluster. For example, the execution entity of the application service migration method can be located within a terminal device, server, or other processing device. The terminal device can be a device used for application service migration, a user equipment (UE), a mobile device, a user terminal, a terminal, a cellular phone, a cordless phone, a personal digital assistant (PDA), a handheld device, a computing device, an in-vehicle device, etc. In some possible implementations, the application service migration method can be implemented by a processor calling computer-readable instructions stored in memory.

[0019] This application relates to cloud-native technologies, which are widely used in industries such as the internet, finance, and telecommunications, supporting high-concurrency and elastically scalable business scenarios. For example, e-commerce platforms use Kubernetes to achieve second-level scaling up and down to cope with peak traffic; financial institutions adopt microservice architectures to improve system modularity and fault tolerance; and 5G edge computing combined with cloud-native technologies enables low-latency services. Furthermore, innovative scenarios such as AI training and serverless computing also rely on cloud-native technologies to help enterprises achieve efficient and agile digital operations. The clusters (source or target clusters) involved in this application are service clusters. A service cluster refers to the integration of multiple independent servers or computing nodes into a logical whole through software and network technologies, jointly providing highly available and scalable services. Nodes in the cluster typically run the same applications or services (i.e., application services) and work collaboratively through load balancing, fault tolerance mechanisms, etc., to improve system performance and reliability. Each node in the cluster involved in this application is a regional node. A regional node refers to a computing node or data center deployed in a specific geographical region (such as a city, province, or country) in a distributed system or network architecture; it is used to process user requests locally, reduce latency, and meet data compliance requirements (such as local data storage). This application service migration can leverage container service technology. Container service is a cloud computing service based on containerization technologies (such as Docker and Kubernetes) used for rapid deployment, management, and scaling of applications. It encapsulates applications and their dependent environments in lightweight containers, enabling cross-platform operation and improving development and operation efficiency. This application involves data synchronization of information to be migrated between the source cluster and the target cluster. Data synchronization refers to the process of maintaining data consistency between different systems, databases, or storage nodes, ensuring that data on each end is updated to the same state in real time or periodically; it is commonly used in distributed architectures, multi-replica storage, or cross-platform business scenarios.

[0020] To address this, this application provides an application service migration method. This method involves setting up encryption / decryption nodes and proxy nodes in the source cluster; the application service migration information is then migrated to the target cluster via the proxy nodes and encryption / decryption nodes in the source cluster, allowing the target cluster to process the migration information. The source and target clusters establish a communication connection through the encryption / decryption nodes in the source and target clusters. This allows for application service migration from the source cluster to the target cluster without shutting down the application service, improving the overall migration stability.

[0021] Please see Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the application service migration method of this application. The application service migration method is applied to the source cluster. The application service migration method may include the following steps: Step S11: Set up encryption / decryption nodes and proxy nodes in the source cluster.

[0022] The source cluster is the cluster currently being used by the application service. The source cluster includes several nodes. Each node in the source cluster belongs to a region node. Before step S11 above, each node in the source cluster may include a load balancer node, several service nodes, cache nodes, read nodes, and write nodes. The load balancer node communicates with several service nodes. Several service nodes communicate with cache nodes, read nodes, and write nodes respectively. Read nodes and write nodes communicate with each other.

[0023] Executing step S11 above, the nodes in the source cluster include a load balancer node, several service nodes, cache nodes, read nodes, write nodes, and the configured encryption / decryption nodes and proxy nodes. The proxy node in the source cluster acts as the management node among the nodes. The proxy node changes the communication channels between several service nodes and the cache, read, and write nodes; several service nodes establish communication connections with the proxy node; and the proxy node establishes communication connections with the cache, read, and write nodes. That is, when service nodes transmit information, they must first send the information to be transmitted to the proxy node, and then the proxy node forwards the information to the cache, read, and write nodes. The encryption / decryption nodes in the source cluster communicate with the cache and write nodes respectively.

[0024] Understandably, the proxy nodes in the source cluster are used to facilitate information exchange between several service nodes, cache nodes, read nodes, and write nodes. Specifically, the proxy nodes in the source cluster forward the information to be transmitted received from several service nodes to the cache nodes, read nodes, and write nodes in the source cluster. The encryption / decryption nodes in the source cluster are used to facilitate information exchange between the source cluster and the target cluster. Specifically, the encryption / decryption nodes in the source cluster forward the information sent by the cache nodes and write nodes in the source cluster to the encryption / decryption nodes in the target cluster.

[0025] It is understandable that the target cluster and the source cluster have the same number of nodes, node types, and at least some of the node transmission channel settings.

[0026] Step S12: Migrate the obtained application service migration information to the target cluster through the proxy node in the source cluster and the encryption / decryption node in the source cluster.

[0027] The application service is the application or service currently running in the source cluster. The target cluster can be a cluster that has already been deployed with the same number of nodes, node types, and at least some of the node transmission channel settings as the source cluster, and is to be migrated. The target cluster must include at least encryption / decryption nodes. The encryption / decryption nodes in the target cluster communicate with the encryption / decryption nodes in the source cluster. The encryption / decryption nodes in the source cluster send migration information to the encryption / decryption nodes in the target cluster, and the encryption / decryption nodes in the target cluster receive the migration information sent by the encryption / decryption nodes in the source cluster. The migration information of the application service represents the stored data and business traffic in the source cluster corresponding to the application service during the migration process.

[0028] The application service migration information is obtained and migrated to the target cluster through the proxy node and encryption / decryption node in the source cluster, so that the target cluster can process the migration information. The source cluster and the target cluster establish a communication connection through the encryption / decryption node in the source cluster and the encryption / decryption node in the target cluster.

[0029] In some application scenarios, the information to be migrated for the application service includes historical data stored in the source cluster within a preset time period, the first data of the first business traffic in the application service, and the second business traffic. Step S12 above can be: migrating the historical data, the first data, and the second business traffic to the encryption / decryption node in the target cluster according to a preset migration order through the proxy node and encryption / decryption node in the source cluster. For example, the preset migration order could be to first synchronize the historical data to the target cluster, then synchronize the first data to the target cluster, and finally allocate the second business traffic to the target cluster. Alternatively, the preset migration order could be to synchronize the historical data and the first batch of data from the first data to the target cluster, then synchronize the other data from the first data (excluding the first batch) to the target cluster, and finally allocate the second business traffic to the target cluster.

[0030] The above-described solution involves setting up encryption / decryption nodes and proxy nodes in the source cluster. The application service migration information is then migrated to the target cluster via the proxy nodes and encryption / decryption nodes in the source cluster. This allows the target cluster to process the migration information. The source and target clusters establish a communication connection through the encryption / decryption nodes in the source and target clusters. As a result, the application service can be migrated from the source cluster to the target cluster without shutting down the application service, thus improving the overall migration stability.

[0031] Please see Figure 2 , Figure 2 This is a first-stage framework diagram of an embodiment of the application service migration method of this application.

[0032] like Figure 2As shown, after step S11 above, the nodes in the source cluster include a load balancer node, several business service nodes, cache nodes, read nodes, write nodes, and the configured encryption / decryption nodes and proxy nodes. The source cluster application services mainly include business services, data proxy services, business cache services (business Cache), business data storage services (supporting read / write separation), and load balancing services. Business services correspond to several business service nodes in the source cluster. Data proxy services correspond to data proxy nodes in the source cluster. Business cache services correspond to cache nodes in the source cluster. Business data storage services correspond to business DB Read and business DB Write, with data processing Sync between them. Business data storage services correspond to read nodes and write nodes in the source cluster. Load balancing services correspond to load balancing nodes in the source cluster. External business traffic generally enters through a unified entry domain name, therefore the domain name DNS resolves to the load balancing service, which then reverse proxies to the backend service nodes (such as several business service nodes).

[0033] In this context, the data proxy node is an intermediary server located between the client and the target service, responsible for forwarding requests, filtering traffic, or providing additional functions (such as caching, load balancing, and security protection). As a communication intermediary, it optimizes network performance and enhances system security. Load balancing is a technology that rationally distributes network traffic or computing tasks across multiple servers (or nodes), aiming to optimize resource utilization, improve system throughput, and avoid service interruptions caused by single points of overload or failure.

[0034] Please see Figure 3 , Figure 3 yes Figure 1 A schematic diagram of the sub-process of step S12.

[0035] In some embodiments, the information to be migrated includes historical data stored in the source cluster, first data of the first service traffic in the application service, and second service traffic, wherein the reception time of the first service traffic in the application service is earlier than the reception time of the second service traffic; step S12 above may include the following steps: Step S31: In response to the source cluster performing synchronization configuration, migrate the historical data to the target cluster through the encryption / decryption nodes in the source cluster. Step S32: In response to the source cluster performing synchronization switching configuration, migrate the first data to the first migrated target cluster through the proxy node and the encryption / decryption node in the source cluster. Step S33: In response to the source cluster performing traffic allocation configuration, migrate the processing data of the target service traffic in the second service traffic to the second migrated target cluster through the proxy node and the encryption / decryption node in the source cluster.

[0036] Historical data stored in the source cluster represents data stored in the source cluster before receiving the migration instruction from the application service. Business traffic represents business requests received by the application service in response to user operations on the client side. Business traffic consists of business requests entering the application service within a preset time period after receiving the migration instruction. Within this preset time period, the reception time of the first business traffic in the application service is earlier than the reception time of the second business traffic. The first data in the first business traffic represents data stored in the source cluster after receiving the migration instruction from the application service. The second business traffic is business traffic received by the application service after the reception time of the first business traffic.

[0037] In response to the source cluster's synchronization configuration, historical data is migrated to the target cluster through the encryption / decryption nodes in the source cluster. This allows the target cluster to receive the historical data through its encryption / decryption nodes and perform storage processing to obtain the first migrated target cluster.

[0038] Synchronization configuration represents the configuration information for migrating stored data from the source cluster to the target cluster, specifically setting the configuration information for full and / or incremental synchronization of stored data at different stages in the source cluster.

[0039] In some application scenarios, the steps described above for migrating historical data to the target cluster via encryption / decryption nodes in the source cluster include: determining the target node where the historical data is located from the cache nodes and / or write nodes in the source cluster; the encryption / decryption node in the source cluster receiving the historical data sent by the target node in the source cluster and forwarding the historical data to the encryption / decryption node in the target cluster. For example, the synchronization method for migrating historical data from the source cluster to the target cluster can be full synchronization.

[0040] In some embodiments, the synchronization configuration includes forward synchronization configuration and reverse synchronization configuration. Step S31 above may include the following steps: In response to forward synchronization configuration of the source cluster, historical data is migrated to the target cluster through the encryption / decryption node in the source cluster, so that the target cluster receives the historical data through the encryption / decryption node in the target cluster and performs storage processing on the historical data to obtain a first migrated target cluster. In response to reverse synchronization configuration of the source cluster, a read-only node is set up in the source cluster. The storage data sent by the first migrated target cluster is received through the encryption / decryption node in the source cluster and forwarded to the read-only node in the source cluster for storage processing.

[0041] Forward synchronization configuration represents the synchronization configuration process of migrating data from the source cluster to the target cluster. Reverse synchronization configuration represents the synchronization configuration process of backing up data from the target cluster back to the source cluster. Read-only nodes in the source cluster communicate with both the proxy nodes and encryption / decryption nodes in the source cluster. If business traffic requires reading data from the target cluster, this can be achieved by reading data from the read-only nodes in the source cluster.

[0042] In response to the synchronous switching configuration of the source cluster, the first data is migrated to the first migrated target cluster through the proxy node and the encryption / decryption node in the source cluster, so that the first migrated target cluster receives the first data through the encryption / decryption node in the first migrated target cluster and processes the first data to obtain the second migrated target cluster.

[0043] The synchronization switching configuration is used to set the synchronization method for synchronizing the first data to the target cluster.

[0044] In some application scenarios, the steps described above for migrating the first data to the first target cluster via proxy nodes and encryption / decryption nodes in the source cluster include: determining the target node where the first data is located from the cache nodes and / or write nodes in the source cluster; the encryption / decryption node in the source cluster receiving the first data sent by the target node in the source cluster and forwarding historical data to the encryption / decryption node in the target cluster. For example, the synchronization method for migrating the first data from the source cluster to the target cluster can be incremental synchronization.

[0045] In some embodiments, the source cluster further includes write nodes and cache nodes; step S32 above may include the following steps: the write nodes and / or cache nodes in the source cluster receive processing data of the first service traffic sent by the proxy nodes in the source cluster to obtain first data. The encryption / decryption nodes in the source cluster receive the first data sent by the write nodes and / or cache nodes in the source cluster and forward it to the encryption / decryption nodes in the target cluster.

[0046] In some application scenarios, step S32 above may include: a write node in the source cluster receiving processing data of the first service traffic sent by a proxy node in the source cluster to obtain first data; an encryption / decryption node in the source cluster receiving the first data sent by the write node in the source cluster and forwarding it to an encryption / decryption node in the target cluster. Alternatively, a cache node in the source cluster receiving processing data of the first service traffic sent by a proxy node in the source cluster to obtain first data; an encryption / decryption node in the source cluster receiving the first data sent by a cache node in the source cluster and forwarding it to an encryption / decryption node in the target cluster. Alternatively, a write node and a cache node in the source cluster receiving processing data of the first service traffic sent by a proxy node in the source cluster to obtain first data; an encryption / decryption node in the source cluster receiving the first data sent by the write node and the cache node in the source cluster and forwarding it to an encryption / decryption node in the target cluster.

[0047] The load balancing node in the source cluster receives the first service traffic and forwards it to at least one service node in the source cluster to obtain the processed data of the first service traffic. Each service node forwards the processed data of the first service traffic to the data proxy node in the source cluster. The data proxy node in the source cluster sends the processed data of the first service traffic to the write node and / or cache node in the source cluster for storage processing to obtain the first data already stored in the write node and / or cache node in the source cluster. The encryption / decryption node in the source cluster receives the first data sent by the write node and / or cache node in the source cluster and forwards it to the encryption / decryption node in the target cluster.

[0048] Please see Figure 4 , Figure 4 This is a second-stage framework diagram in one embodiment of the application service migration method of this application.

[0049] In some application scenarios, before the source cluster receives the migration instruction for the application service, the source cluster is first evaluated and the environment is configured. Specifically, this includes: evaluating the source cluster's technical architecture (containers / K8s / physical machines) and service list, preparing the target cluster infrastructure (homogeneous cloud vendor or cross-cloud / cross-region), and configuring the firewall policies and port permissions required for network interconnection between the source cluster and the cluster to be migrated.

[0050] In other application scenarios, a target cluster with a consistent architecture is deployed between the source cluster and the cluster to be migrated. Two deployment options are available for the target cluster: containerized deployment and physical machine deployment. The containerized deployment option involves: exporting the source cluster's container image and orchestration template (Docker Compose / K8s YAML), rebuilding the image repository on the target cluster and pushing the image, and deploying the target cluster using the same configuration template. The physical machine deployment option involves: obtaining the source cluster's deployment package and configuration manual, installing the same version of middleware / database on the target server, and restoring the architecture to the source cluster topology 1:1 to obtain the target cluster.

[0051] In other application scenarios, step S11 is executed, along with setting up proxy nodes and encryption / decryption nodes in the target cluster. Encryption / decryption proxy nodes are deployed bidirectionally; a VPN gateway / dedicated encrypted proxy service is deployed on the source cluster side, and a peer access point is configured on the target cluster side. Channel performance is tested (latency and bandwidth must meet data synchronization requirements). For example, the forward synchronization configuration in step S31 above includes configuring different synchronization methods based on the type of database in the source cluster. Specifically, a synchronization scheme is selected, with different schemes chosen for relational and non-relational databases. For example, for relational databases: a cloud service provider solution can be used, configuring DTS tasks (such as AWS DMS / Aliyun DTS) and selecting a full synchronization + incremental synchronization mode; or other solutions can be used: developing a synchronization service based on binlog / redolog. For non-relational databases: MongoDB uses Change Stream to capture changes, and Elasticsearch uses snapshot + _reindex API. When performing data synchronization in step S12, it is divided into a full synchronization phase and an incremental synchronization phase. For historical data, perform full synchronization, configure filtering rules during synchronization configuration, enable compressed transmission, and monitor synchronization progress. For the first data, perform incremental synchronization, perform synchronization switch configuration between historical data and the first data, so that when performing incremental synchronization switch configuration for the first data, a globally consistent snapshot is created in the source cluster, and the data volume of the target cluster (e.g., checksum) is verified to detect whether the historical data has been fully synchronized, unlocking and starting incremental synchronization for the first data. After step S31 above, verify the data synchronization result, establish a data verification task, and configure alarm rules to confirm whether the historical data has been fully synchronized. After step S32 above, verify the data synchronization result, establish a data verification task, and configure alarm rules to confirm whether the first data has been incrementally synchronized.

[0052] like Figure 4As shown, in other application scenarios, in response to the reverse synchronization configuration of the source cluster, the source cluster is expanded to obtain read-only nodes, new read-only nodes are added, a MySQL slave database is deployed and configured with GTID replication, a Redis replica node is added, and the same monitoring / alarm system as the source cluster is mounted. A reverse data synchronization channel is configured for the read-only nodes in the source cluster, reusing the existing encrypted channel in the source cluster or creating a new independent channel. Reverse routing rules are configured to achieve the data interaction channel from the target cluster to the encryption / decryption nodes in the source cluster, and then to the read-only nodes in the source cluster.

[0053] In other application scenarios, the process of receiving storage data sent by the first migrated target cluster through encryption / decryption nodes in the source cluster and forwarding it to read-only nodes in the source cluster for storage processing may include the following: the source cluster performs reverse data synchronization, using the same technical solution as forward synchronization, setting write protection to prevent data from the target cluster from being written back to the source cluster's master database (i.e., storage data sent by the target cluster is only written back to read-only nodes in the source cluster, not write nodes), and configuring circular replication detection (to prevent data loops). It can be considered that through the above process, the initial deployment and construction of the target cluster service has been completed, and the source and target clusters have completed historical and initial data synchronization, ensuring eventual data consistency during subsequent cluster migration.

[0054] Please see Figure 5 , Figure 5 This is a schematic diagram of information interaction between the source cluster and the target cluster in one embodiment of the application service migration method of this application.

[0055] For example, such as Figure 5 As shown here, the execution of step S11 and the establishment of an encryption / decryption channel in the target cluster to achieve cross-region traffic interaction are explained. The encryption / decryption nodes in the source cluster include encryption proxy nodes and decryption proxy nodes. The encryption / decryption nodes in the target cluster also include encryption proxy nodes and decryption proxy nodes. The encryption proxy nodes in the source cluster and the decryption proxy nodes in the target cluster establish a communication connection, using HTTPS + custom content encryption. The encryption / decryption nodes in the target cluster and the decryption proxy nodes in the source cluster establish a communication connection, using HTTPS + custom content encryption. At least one of the following is configured on both the encryption / decryption nodes in the source and target clusters: TLS certificate, private certificate, encryption algorithm, decryption algorithm, key, and IP whitelist.

[0056] In step S11, the encryption / decryption proxy nodes are deployed and configured for routing. Suitable proxy nodes are selected to deploy encryption / decryption nodes in the source cluster; open-source components such as Nginx, OpenResty, and HAProxy can be chosen. A high-availability architecture (dual-node + Keepalived) is adopted, deploying data encryption and decryption proxy nodes in both the source and target clusters. The same routing rules are configured for both the encryption / decryption nodes in the source and target clusters, adding the following routing links and configuring load balancing. Business traffic is differentiated based on service name identifiers or custom headers. Specifically, the encryption proxy node (egress) of the source cluster is configured to connect to the decryption proxy node (ingress) of the target cluster; the encryption proxy node (egress) of the target cluster is configured to connect to the decryption proxy node (ingress) of the source cluster.

[0057] Configure security certificates and encryption / decryption settings on the encryption / decryption nodes in the source and target clusters. Security certificate configuration includes: using TLS mutual authentication, issuing CA certificates for both the source and target clusters, configuring server certificates and private keys on the proxy nodes, and selecting automatic renewal or periodic manual renewal for certificate security. Encryption / decryption algorithm configuration includes: the data encryption and decryption proxy nodes encrypt the original data with AES before transmission, and then encrypt the transmission channel using TLS. The encryption key can also be rotated periodically to improve key security. Access control configuration includes: allowing only the source cluster IP to access the target cluster decryption proxy node, allowing only the target cluster IP to access the source cluster decryption proxy node, opening only dedicated ports for the proxy nodes, and closing unnecessary ports.

[0058] It can be considered that the above encryption and decryption configurations effectively ensure the security of data communication between the source cluster and the target cluster, prevent abnormal situations such as data asset leakage and data tampering during the cluster migration process, and further ensure the stable implementation of the overall migration plan.

[0059] In some embodiments, the source cluster further includes read-only nodes that communicate with the encryption / decryption nodes in the source cluster. Before the step of migrating the processing data of the target service traffic in the second service traffic to the second migrated target cluster via the proxy node and the encryption / decryption node in the source cluster in response to the traffic allocation configuration of the source cluster, the application service migration method further includes the following steps: configuring write traffic for the source cluster and establishing a communication connection between the proxy node and the encryption / decryption node in the source cluster regarding write traffic; configuring read traffic for the source cluster and establishing a communication connection between the proxy node and the read-only node in the source cluster regarding read traffic.

[0060] The write traffic configuration characterizes the switching of application service write traffic from the source cluster to the target cluster. A communication connection regarding write traffic is established between the proxy node and the encryption / decryption node in the source cluster, so that write traffic in the second service traffic can be transmitted to the encryption / decryption node in the target cluster via the proxy node and encryption / decryption node in the source cluster.

[0061] The read traffic configuration characterizes the switching of application service read traffic from the source cluster to the target cluster. It establishes a communication connection between the proxy node and the read-only node in the source cluster regarding read traffic, so that read traffic from the second service traffic can read stored data from the write node in the target cluster through the proxy node and read-only node in the source cluster.

[0062] Please see Figure 6 , Figure 6 This is a framework diagram of the third stage in one embodiment of the application service migration method of this application.

[0063] In some application scenarios, the data proxy of the source cluster modifies the write configuration (i.e., write traffic configuration), switches write traffic to the target cluster, identifies data write operations (such as MySQL's INSERT / UPDATE / DELETE, MongoDB's writeCommands), and configures write traffic routing rules at the source cluster proxy layer (such as Nginx / OpenResty / HAProxy) to uniformly proxy data write requests to the target cluster's data service. Combined with the aforementioned forward data synchronization mechanism and encryption / decryption proxy channel, the security and success rate of write operations can be guaranteed. The aforementioned write traffic configuration can involve obtaining and executing a write traffic configuration command to configure the write traffic for the source cluster. For example, the write traffic configuration command may include the following: # OpenResty Example: Intercepting Write Operations and Forwarding Them to the Encrypted Proxy Node location ~* ^ / (api / write|db / update) { Set $target_cluster_encrypt_proxy "Target cluster encryption proxy node IP:443"; proxy_pass https: / / $target_cluster_encrypt_proxy; proxy_ssl_verify on; # Enable TLS certificate verification } In other application scenarios, the data proxy of the source cluster modifies the read configuration (i.e., read traffic configuration), and the read traffic is retained in the source cluster: Modifying the proxy configuration redirects read requests (SELECT / GET, etc.) to read-only nodes in the source cluster. Combined with the aforementioned forward data synchronization mechanism and encryption / decryption proxy channel, this ensures that real-time data can still be read on the new read-only nodes in the source cluster, achieving data consistency between the source and target clusters. The aforementioned read traffic configuration can be achieved by obtaining and executing a read traffic configuration command to configure the read traffic of the source cluster. For example, the read traffic configuration command may include the following: location ~* ^ / (api / query|db / read) { Set $local_read_node "Source cluster read-only node IP:3306"; proxy_pass http: / / $local_read_node; } By configuring the write traffic and read traffic as described above, the write traffic in the second service traffic of the source cluster can be fully switched to the target cluster, while the read traffic of the service is retained in the read-only nodes of the source cluster. This can achieve data consistency between the source cluster and the target cluster, and also ensure the data reading speed of the source cluster.

[0064] Understandably, after the subsequent second service traffic enters the source cluster through the load balancing node in the source cluster, in response to the second service traffic being write traffic, the load balancing node in the source cluster receives the second service traffic and forwards it to at least one service node in the source cluster to obtain the processing data of the second service traffic. Each service node then forwards the processing data of the second service traffic to the data proxy node in the source cluster. The encryption / decryption node in the source cluster receives the processing data of the second service traffic sent by the data proxy node in the source cluster and forwards it to the encryption / decryption node in the target cluster.

[0065] Understandably, after the subsequent second service traffic enters the source cluster through the load balancing node in the source cluster, in response to the second service traffic being read traffic, the load balancing node in the source cluster receives the second service traffic and forwards it to at least one service node in the source cluster to obtain the processing data of the second service traffic. Each service node then forwards the processing data of the second service traffic to the data proxy node in the source cluster. The read-only node in the source cluster receives the processing data of the second service traffic sent by the data proxy node in the source cluster and performs the corresponding data reading processing.

[0066] In response to the traffic allocation configuration of the source cluster, the processing data of the target service traffic in the second service traffic is migrated to the second migrated target cluster through the proxy node and the encryption / decryption node in the source cluster. This allows the second migrated target cluster to receive the processing data through the encryption / decryption node in the second migrated target cluster and process the data to obtain the third migrated target cluster.

[0067] Traffic allocation configuration represents the configuration for canary rollout of the second service traffic. Different canary rollout configurations are configured according to the specific type of the second service traffic and the processing order of different types of service traffic. The processing data of the target service traffic within the second service traffic represents the portion of the second service traffic that needs to be processed in the source cluster. Other service traffic in the second service traffic, excluding the target service traffic, is processed directly in the target cluster according to the traffic allocation rules. That is, service traffic in the second service traffic, excluding the target service traffic, enters the source cluster through the load balancer node in the source cluster, and other service traffic in the second service traffic, excluding the target service traffic, enters the target cluster through the load balancer node in the target cluster.

[0068] Understandably, after the target service traffic enters the source cluster through the load balancing node in the source cluster, in response to the target service traffic being write traffic, the load balancing node in the source cluster receives the target service traffic and forwards it to at least one service node in the source cluster to obtain the processing data of the target service traffic. Each service node then forwards the processing data of the target service traffic to the data proxy node in the source cluster. The encryption / decryption node in the source cluster receives the processing data of the target service traffic sent by the data proxy node in the source cluster and forwards it to the encryption / decryption node in the target cluster.

[0069] Understandably, after the target service traffic enters the source cluster through the load balancing node, in response to the target service traffic being read traffic, the load balancing node in the source cluster receives the target service traffic and forwards it to at least one service node in the source cluster to obtain the processing data of the target service traffic. Each service node then forwards the processing data of the target service traffic to the data proxy node in the source cluster. The read-only node in the source cluster receives the processing data of the target service traffic sent by the data proxy node in the source cluster and performs the corresponding data reading processing.

[0070] In some embodiments, the second service traffic includes stateless service traffic, and the traffic allocation configuration includes a stateless traffic allocation configuration that matches the stateless service traffic; step S33 above may include the following steps: in response to the source cluster performing stateless traffic allocation configuration, the proxy node in the source cluster will receive the processing data of the target service traffic in the stateless service traffic; the proxy node in the source cluster will forward the processing data of the target service traffic in the stateless service traffic to the encryption / decryption node in the second migrated target cluster.

[0071] After the processing data of the target business traffic in the stateless service traffic is forwarded to the encryption / decryption node in the second migrated target cluster through the proxy node in the source cluster, the second migrated target cluster receives the processing data of the target business traffic in the stateless service traffic through the encryption / decryption node in the second migrated target cluster, and processes the processing data of the target business traffic in the stateless service traffic to obtain the third migrated target cluster.

[0072] Stateless service traffic represents user requests where the application service itself does not store user-related state. Stateless traffic allocation configuration represents the allocation configuration for traffic belonging to the stateless service type in the second service traffic.

[0073] Please see Figure 7 , Figure 7 This is a framework diagram of the fourth stage in one embodiment of the application service migration method of this application.

[0074] For example, such as Figure 7 As shown, stateless traffic allocation configuration can include the following: switching stateless service traffic from the source cluster to the target cluster via canary deployment; configuring a load balancing strategy; configuring stateless traffic allocation rules on the source cluster load balancer (such as Nginx / HAProxy / F5); supporting configuration of a certain canary deployment ratio based on dimensions such as request ratio / user ID hash / region / country; and after observing the new cluster's business stability for a period of time, considering increasing the proportion of canary traffic. The above stateless traffic allocation configuration can involve obtaining a stateless traffic allocation command and executing the command to allocate stateless traffic to the source cluster. For example, the stateless traffic allocation command can include the following: # Example: Proportional traffic splitting (10% of traffic to the target cluster) upstream backend { server source cluster nodes: 80 weight=90; server target cluster nodes: 80 weight=10; } In other application scenarios, after executing the stateless traffic allocation command, observe the operating status of the target cluster's services. If the target cluster's service error rate is <0.1% within a continuously preset detection period (e.g., 4 hours), the core business interface passes manual testing, and the data consistency verification tool reports no discrepancies, then the target cluster's services can be considered normal, and it is advisable to switch all stateless service traffic from the source cluster to the target cluster.

[0075] In other application scenarios, when switching stateless service traffic to the target cluster, it is necessary to focus on monitoring core business metrics, such as the number of HTTP 500 errors, database master-slave latency, and the number of core service health check failures. Once the fault criteria are met, an emergency rollback operation is required to switch the stateless service traffic back to the source cluster. The stateless service traffic can only be migrated after the problem in the target cluster is fixed.

[0076] In some embodiments, the second service traffic also includes stateful service traffic, and the traffic allocation configuration includes a stateful traffic allocation configuration that matches the stateful service traffic; the above step S33 may include the following steps: in response to the source cluster performing stateful traffic allocation configuration, the proxy node in the source cluster will receive the processing data of the target service traffic in the stateful service traffic; the proxy node in the source cluster will forward the processing data of the target service traffic in the stateful service traffic to the encryption / decryption node in the second migrated target cluster.

[0077] After the proxy node in the source cluster forwards the processing data of the target business traffic in the stateful service traffic to the encryption / decryption node in the second migrated target cluster, the second migrated target cluster receives the processing data of the target business traffic in the stateful service traffic through the encryption / decryption node in the second migrated target cluster, and processes the processing data of the target business traffic in the stateful service traffic to obtain the third migrated target cluster.

[0078] Stateful service traffic represents user requests for long-lived connections within an application service. Stateful traffic allocation configuration represents the allocation configuration for traffic belonging to the stateful service type within the second service traffic.

[0079] Please see Figure 8 , Figure 8 This is a framework diagram of the fifth stage in one embodiment of the application service migration method of this application.

[0080] like Figure 8 As shown, this application uses a stateful service as an example of a long-connection session. A domain name resolution node can be represented as a DNS resolution node. For example... Figure 8The analysis service topology framework shown identifies all clients / devices relying on a unified domain name (such as IoT devices and WebSocket clients), records the current number of long-connection sessions (the recording command can be: netstat -anp |grep :443 | wc -l), and confirms the server-side session timeout (such as Nginx's proxy_read_timeout 3600s). Stateful traffic allocation configuration can include the following: confirming that the target cluster has service status; confirming that the target cluster deploys the same version of the long-connection service as the source cluster; configuring completely identical load balancing strategies (such as TCP long-connection persistence); and pre-installing monitoring probes to facilitate the statistics of new / active connections. During the specific implementation of stateful traffic allocation configuration, a DNS gray-scale switch is implemented. Seven days before the migration, the TTL is set to 86400, forcing clients to cache the old IP; one hour before the migration, the TTL is set to 60 to ensure the new DNS takes effect quickly. DNS resolution rules are modified on domain name resolution nodes to achieve batch DNS switching, supporting proportional mapping of domain names to the target cluster's load balancing nodes, with the load balancing nodes reverse-proximating to the target cluster's long-connection service.

[0081] In other application scenarios, when migrating stateful service traffic from the second business traffic, the connection status of the source cluster can be observed using the following source cluster stateful service observation command. For example, the source cluster stateful service observation command may include the following: # Decline curve of active connections in the source cluster (expected) while true; do echo "[$(date)] $(netstat -tn | grep ESTAB | wc -l)"; sleep 60 done For example, stateful traffic allocation configuration also includes source cluster keep-alive measures, keeping the source cluster service running until all regional DNS resolutions have been switched and the number of active connections in the source cluster is less than 5% of the total number of connections; and configuring automatic session transfer (such as clean_session=false in MQTT) to the target cluster.

[0082] For example, the stateful traffic allocation configuration also includes abnormal connection handling, sending a forced close command (such as a FIN signaling) to persistent connections (such as IoT devices that have not been closed after a timeout) to force the closure of idle long-lived connections. For example, the forced close command includes the following: server { listen 443; proxy_timeout 10m; # Send FIN packet after timeout } In some application scenarios, the target cluster after the third migration is directly used as the target cluster after the migration is complete. In other application scenarios, the last message ID of the source cluster and the last online time of the device are compared with those of the target cluster after the third migration (message queue scenario) to ensure that the traffic has been completely switched from the source cluster to the target cluster, triggering the setting of the target cluster after the third migration as the target cluster after the migration is complete.

[0083] In other application scenarios, a rollback operation is performed on the target cluster and / or source cluster in response to the target cluster and / or source cluster meeting the rollback conditions. When the target cluster triggers the rollback conditions (target cluster new connection failure rate >1%, loss of critical messages (such as financial order instructions)), a rapid DNS resolution rollback is required. For example, the rollback command when performing the rollback operation may include the following: # Emergency DNS Record Recovery (Batch Operations via All DNS Provider APIs) curl -X POST "https: / / api.dns.com / records" \ -H "Authorization: Bearer $TOKEN" \ -d '{"type":"A", "value":"source cluster IP"}' In some application scenarios, stateless service traffic can be migrated first, and then stateful service traffic can be migrated.

[0084] The above-described solution involves setting up encryption / decryption nodes and proxy nodes in the source cluster. The application service migration information is then migrated to the target cluster via the proxy nodes and encryption / decryption nodes in the source cluster. This allows the target cluster to process the migration information. The source and target clusters establish a communication connection through the encryption / decryption nodes in the source and target clusters. As a result, the application service can be migrated from the source cluster to the target cluster without shutting down the application service, thus improving the overall migration stability.

[0085] Please see Figure 9 , Figure 9 This is another flowchart illustrating an embodiment of the application service migration method of this application.

[0086] In some embodiments, the application service migration method is applied to a target cluster. The method includes: Step S91: Setting up encryption / decryption nodes and proxy nodes in the target cluster. Step S92: Receiving application service migration information sent by the source cluster through the proxy nodes and encryption / decryption nodes in the target cluster, and processing the migration information to obtain the migrated target cluster.

[0087] The source cluster and the target cluster establish a communication connection through the encryption / decryption nodes in the source cluster and the encryption / decryption nodes in the target cluster.

[0088] It is understandable that the target cluster and the source cluster have the same node deployment architecture. Please refer to the above content for details, which will not be repeated here.

[0089] In some application scenarios, before setting up encryption / decryption nodes and proxy nodes in the target cluster, the above application service migration method further includes: in response to receiving a migration instruction for the application service, obtaining the cluster to be migrated into; initializing the cluster to be migrated into to obtain the target cluster, including: setting up the same communication channels between nodes in the cluster to be migrated into as between nodes in the source cluster; and deploying the obtained application service installation package on each node in the cluster to be migrated into to obtain the target cluster. The cluster to be migrated into is a cluster with the same number and type of nodes as the source cluster. The application service installation package can be obtained by the master node in the application service migration system sending the application service installation package to the cluster to be migrated into.

[0090] In some embodiments, the information to be migrated includes historical data stored in the source cluster, first data of the first service traffic in the application service, and second service traffic, wherein the reception time of the first service traffic in the application service is earlier than the reception time of the second service traffic; the above-mentioned step of receiving the application service information to be migrated sent by the source cluster through the proxy node and the encryption / decryption node in the target cluster includes: the target cluster receiving historical data through the encryption / decryption node in the target cluster and storing the historical data to obtain a first migrated target cluster; the first migrated target cluster receiving the first data through the encryption / decryption node in the first migrated target cluster and processing the first data to obtain a second migrated target cluster; the second migrated target cluster receiving the processed data of the target service traffic in the second service traffic through the encryption / decryption node in the second migrated target cluster and processing the processed data to obtain a third migrated target cluster.

[0091] It is understandable that the target cluster, the target cluster after the first migration, and the target cluster after the second migration are the same cluster; the difference in name only indicates that the information they carry is different.

[0092] Specifically, the target cluster receives historical data through its encryption / decryption nodes and performs storage processing to obtain the first migrated target cluster. This includes: the encryption / decryption nodes in the target cluster receiving historical data sent by the encryption / decryption nodes in the source cluster; determining a matching node among the cache nodes and write nodes in the target cluster based on the type of the target node in the source cluster where the historical data is located, including: in response to the target node in the source cluster being a write node, using the write nodes in the target cluster as matching nodes; and / or in response to the target node in the source cluster being a cache node, using the cache nodes in the target cluster as matching nodes; and the encryption / decryption nodes in the target cluster sending the historical data to the matching nodes in the target cluster for storage processing to obtain the stored data in the target cluster. The target cluster that has completed the storage of historical data is then used as the first migrated target cluster.

[0093] In other application scenarios, in response to the forward synchronization configuration of the target cluster, the target cluster receives historical data through the encryption and decryption nodes in the target cluster, and stores and processes the historical data to obtain the first migrated target cluster.

[0094] In other application scenarios, in response to the reverse synchronization configuration of the target cluster, the encryption / decryption node in the target cluster receives the stored data in the target cluster and forwards the stored data to the encryption / decryption node in the source cluster, so that the encryption / decryption node in the source cluster forwards the stored data to the read-only node in the source cluster for storage processing.

[0095] Specifically, the process involves receiving first data through encryption / decryption nodes in the first migrated target cluster and processing the first data to obtain the second migrated target cluster. This includes: the encryption / decryption nodes in the target cluster receiving the first data sent by encryption / decryption nodes in the source cluster; determining a matching node among cache nodes and write nodes in the target cluster based on the type of the target node in the source cluster where the first data is located, including: in response to the target node in the source cluster being a write node, using write nodes in the target cluster as matching nodes; and / or in response to the target node in the source cluster being a cache node, using cache nodes in the target cluster as matching nodes; the encryption / decryption nodes in the target cluster sending the first data to the matching nodes in the target cluster for storage processing to obtain stored data in the target cluster; and using the target cluster that has completed the storage of the first data as the second migrated target cluster.

[0096] The above-described solution involves setting up encryption / decryption nodes and proxy nodes in the source cluster. The application service migration information is then migrated to the target cluster via the proxy nodes and encryption / decryption nodes in the source cluster. This allows the target cluster to process the migration information. The source and target clusters establish a communication connection through the encryption / decryption nodes in the source and target clusters. As a result, the application service can be migrated from the source cluster to the target cluster without shutting down the application service, thus improving the overall migration stability.

[0097] Please see Figure 10 , Figure 10 This is a schematic diagram of the structure of an embodiment of the application service migration system of this application. An application service migration system 100 includes a source cluster 101 and a target cluster 102. The application service migration method described above is applied to the source cluster 101 in the application service migration system. Specifically, the source cluster 101 in the application service migration system is used to: establish encryption / decryption nodes and proxy nodes in the source cluster 101; migrate the obtained application service information to be migrated to the target cluster 102 through the proxy nodes and encryption / decryption nodes in the source cluster 101, so that the target cluster 102 can process the information to be migrated; the source cluster 101 and the target cluster 102 establish a communication connection through the encryption / decryption nodes in the source cluster 101 and the encryption / decryption nodes in the target cluster 102.

[0098] The above-described solution involves setting up encryption / decryption nodes and proxy nodes in the source cluster. The application service migration information is then migrated to the target cluster via the proxy nodes and encryption / decryption nodes in the source cluster. This allows the target cluster to process the migration information. The source and target clusters establish a communication connection through the encryption / decryption nodes in the source and target clusters. As a result, the application service can be migrated from the source cluster to the target cluster without shutting down the application service, thus improving the overall migration stability.

[0099] Please see Figure 11 , Figure 11This is a schematic diagram of another embodiment of the application service migration system of this application. An application service migration system 110 includes a source cluster 111 and a target cluster 112. The above-described application service migration method is applied to the target cluster 112 in the application service migration system. Specifically, the target cluster 112 in the application service migration system is used to: establish encryption / decryption nodes and proxy nodes in the target cluster 112; receive application service migration information sent by the source cluster 111 through the proxy nodes and encryption / decryption nodes in the target cluster 112, and process the migration information to obtain the migrated target cluster 112. The source cluster 111 and the target cluster 112 establish a communication connection through the encryption / decryption nodes in the source cluster 111 and the encryption / decryption nodes in the target cluster 112.

[0100] The above-described solution involves setting up encryption / decryption nodes and proxy nodes in the source cluster. The application service migration information is then migrated to the target cluster via the proxy nodes and encryption / decryption nodes in the source cluster. This allows the target cluster to process the migration information. The source and target clusters establish a communication connection through the encryption / decryption nodes in the source and target clusters. As a result, the application service can be migrated from the source cluster to the target cluster without shutting down the application service, thus improving the overall migration stability.

[0101] Please see Figure 12 , Figure 12 This is a schematic diagram of the structure of an embodiment of the electronic device of this application. The electronic device 120 includes a memory 121 and a processor 122. The processor 122 is used to execute program instructions stored in the memory 121 to implement the steps in the above-described application service migration method embodiment. In a specific implementation scenario, the electronic device 120 may include, but is not limited to, a microcomputer or a server. In addition, the electronic device 120 may also include mobile devices such as laptops and tablets, which are not limited here.

[0102] Specifically, processor 122 controls itself and memory 121 to implement the steps in the above-described application service migration method embodiments. Processor 122 can also be referred to as a CPU (Central Processing Unit). Processor 122 may be an integrated circuit chip with signal processing capabilities. Processor 122 can also be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor. Furthermore, processor 122 can be implemented using integrated circuit chips.

[0103] The above-described solution involves setting up encryption / decryption nodes and proxy nodes in the source cluster. The application service migration information is then migrated to the target cluster via the proxy nodes and encryption / decryption nodes in the source cluster. This allows the target cluster to process the migration information. The source and target clusters establish a communication connection through the encryption / decryption nodes in the source and target clusters. As a result, the application service can be migrated from the source cluster to the target cluster without shutting down the application service, thus improving the overall migration stability.

[0104] Please see Figure 13 , Figure 13 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present application. The computer-readable storage medium 130 stores program instructions 1301 thereon. When executed by a processor, the program instructions 1301 implement the steps in any of the above-described application service migration method embodiments. The computer-readable storage medium 130 can be applied to one or more of the above-described data distribution nodes and application service migration nodes.

[0105] The above-described solution involves setting up encryption / decryption nodes and proxy nodes in the source cluster. The application service migration information is then migrated to the target cluster via the proxy nodes and encryption / decryption nodes in the source cluster. This allows the target cluster to process the migration information. The source and target clusters establish a communication connection through the encryption / decryption nodes in the source and target clusters. As a result, the application service can be migrated from the source cluster to the target cluster without shutting down the application service, thus improving the overall migration stability.

[0106] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0107] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0108] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0109] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0110] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0111] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

Claims

1. An application service migration method, characterized in that, The method is applied to the source cluster, and the method includes: Set up encryption / decryption nodes and proxy nodes in the source cluster; The application service migration information obtained is migrated to the target cluster through the proxy node and the encryption / decryption node in the source cluster, so that the target cluster can process the migration information. The source cluster and the target cluster establish a communication connection through the encryption / decryption node in the source cluster and the encryption / decryption node in the target cluster.

2. The method according to claim 1, characterized in that, The information to be migrated includes historical data already stored in the source cluster, first data of the first service traffic in the application service, and second service traffic. The reception time of the first service traffic in the application service is earlier than the reception time of the second service traffic. The step of migrating the obtained application service migration information to the target cluster through the proxy node in the source cluster and the encryption / decryption node in the source cluster includes: In response to the source cluster performing synchronization configuration, the historical data is migrated to the target cluster through the encryption / decryption node in the source cluster, so that the target cluster receives the historical data through the encryption / decryption node in the target cluster and performs storage processing on the historical data to obtain the first migrated target cluster; In response to the synchronous switching configuration of the source cluster, the first data is migrated to the first migrated target cluster through the proxy node and the encryption / decryption node in the source cluster, so that the first migrated target cluster receives the first data through the encryption / decryption node in the first migrated target cluster and processes the first data to obtain the second migrated target cluster. In response to the traffic allocation configuration of the source cluster, the processing data of the target service traffic in the second service traffic is migrated to the second migrated target cluster through the proxy node and the encryption / decryption node in the source cluster, so that the second migrated target cluster receives the processing data through the encryption / decryption node in the second migrated target cluster and processes the processing data to obtain the third migrated target cluster.

3. The method according to claim 2, characterized in that, The synchronization configuration includes forward synchronization configuration and reverse synchronization configuration; The step of migrating the historical data to the target cluster via the encryption / decryption nodes in the source cluster in response to the synchronization configuration of the source cluster includes: In response to the forward synchronization configuration of the source cluster, the historical data is migrated to the target cluster through the encryption / decryption node in the source cluster, so that the target cluster receives the historical data through the encryption / decryption node in the target cluster and performs storage processing on the historical data to obtain the first migrated target cluster; In response to the reverse synchronization configuration performed in the source cluster, a read-only node is set up in the source cluster; The encryption / decryption node in the source cluster receives the storage data sent by the first migrated target cluster and forwards it to the read-only node in the source cluster for storage processing.

4. The method according to claim 2, characterized in that, The source cluster also includes write nodes and cache nodes; The step of migrating the first data to the first migrated target cluster via the proxy node and the encryption / decryption node in the source cluster includes: The write node and / or cache node in the source cluster receive the processing data of the first service traffic sent by the proxy node in the source cluster to obtain the first data; The encryption / decryption node in the source cluster receives the first data sent by the write node and / or cache node in the source cluster and forwards it to the encryption / decryption node in the target cluster.

5. The method according to claim 2, characterized in that, The source cluster also includes read-only nodes that communicate with the encryption / decryption nodes in the source cluster. Before the step of migrating the processing data of the target service traffic in the second service traffic to the second migrated target cluster via the proxy node and the encryption / decryption node in the source cluster in response to the traffic allocation configuration of the source cluster, the method further includes: Configure write traffic for the source cluster and establish a communication connection between the proxy node and the encryption / decryption node in the source cluster regarding write traffic; Configure read traffic for the source cluster and establish a communication connection between the proxy node and the read-only node in the source cluster regarding read traffic.

6. The method according to claim 2, characterized in that, The second service traffic includes stateless service traffic, and the traffic allocation configuration includes a stateless traffic allocation configuration that matches the stateless service traffic; The step of migrating the processing data of the target service traffic in the second service traffic to the second migrated target cluster in response to the traffic allocation configuration of the source cluster includes: In response to the stateless traffic allocation configuration performed by the source cluster, the proxy node in the source cluster will receive the processing data of the target service traffic in the stateless service traffic; The proxy node in the source cluster forwards the processing data of the target business traffic in the stateless service traffic to the encryption / decryption node in the second migrated target cluster. This enables the second migrated target cluster to receive the processing data of the target service traffic in the stateless service traffic through the encryption / decryption node in the second migrated target cluster, and to process the processing data of the target service traffic in the stateless service traffic to obtain the third migrated target cluster.

7. The method according to claim 2, characterized in that, The second service traffic also includes stateful service traffic, and the traffic allocation configuration includes a stateful traffic allocation configuration that matches the stateful service traffic; The step of migrating the processing data of the target service traffic in the second service traffic to the second migrated target cluster in response to the traffic allocation configuration of the source cluster includes: In response to the stateful traffic allocation configuration performed by the source cluster, the proxy node in the source cluster will receive the processing data of the target service traffic in the stateful service traffic; The proxy node in the source cluster forwards the processing data of the target business traffic in the stateful service traffic to the encryption / decryption node in the second migrated target cluster; This enables the second migrated target cluster to receive the processing data of the target service traffic in the stateful service traffic through the encryption / decryption node in the second migrated target cluster, and to process the processing data of the target service traffic in the stateful service traffic to obtain the third migrated target cluster.

8. An application service migration method, characterized in that, The method is applied to a target cluster, and the method includes: Build encryption / decryption nodes and proxy nodes in the target cluster; The target cluster receives the application service migration information sent by the source cluster through the proxy node and the encryption / decryption node in the target cluster, and processes the migration information to obtain the migrated target cluster. The source cluster and the target cluster establish a communication connection through the encryption / decryption node in the source cluster and the encryption / decryption node in the target cluster.

9. An electronic device, characterized in that, include: A memory and a processor, wherein the memory stores program instructions, and the processor retrieves the program instructions from the memory to perform the method as claimed in any one of claims 1-7 and / or claim 8.

10. A computer-readable storage medium, characterized in that, include: The system contains a program file that, when executed by a processor, is used to implement the method as described in any one of claims 1-7 and / or claim 8.

Images