集群迁移方法、相关装置及存储介质

技术领域

本申请实施例涉及云服务技术领域，更具体地涉及一种集群迁移方法、相关装置及存储介质。

背景技术

容器技术的出现让应用和中间件的交付及部署，相比于传统的基于虚拟机或物理机环境的交付与部署更加方便快捷，也更容易被整合到基于容器环境的开发运维一体化(Development and Operations，DevOps)生态。

Kafka是一种被广泛使用的高吞吐量、高可靠性的消息中间件，如今随着云原生理念的普及，越来越多的用户将Kafka部署在容器环境。但对于企业中的原有业务系统，如何在业务基本不中断的前提下，将Kafka集群从虚拟机或物理机环境迁移到容器环境，却没有合适的方案。

发明内容

本申请实施例提供一种集群迁移方法、相关装置及存储介质,可以在不中断业务的前提下，将集群服务程序由虚拟机或物理机环境迁移到容器环境。

第一方面，本申请实施例提供一种集群迁移方法，应用于集群迁移系统中的迁移控制节点，该集群迁移系统还包括分离部署的源集群和目标容器环境，所述目标容器环境中包括多个第一节点，所述源集群中包括多个第二节点，第一节点与第二节点的数量相同；该方法包括：

将各个第一节点加入所述源集群，得到过渡集群；所述过渡集群中包括全部第一节点和全部第二节点；

在所述过渡集群中，将各个第二节点中的全部分区的数据，分别迁移至各个第一节点中；其中，第一节点与第二节点一一对应，每个第二节点均存储多个分区数据；

更新所述过渡集群中全部节点的配置信息，得到目标集群，所述目标集群中仅包括第一节点。

第二方面，本申请实施例提供一种控制节点，应用于集群迁移系统中，具有实现对应于上述第一方面提供的集群迁移方法的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。

在一个实施方式中，该节点应用于集群迁移系统，该集群迁移系统还包括分离部署的源集群和目标容器环境，所述目标容器环境中包括多个第一节点，所述源集群中包括多个第二节点，第一节点与第二节点的数量相同；该节点包括；

收发模块，被配置为向各个第一节点发送加入所述源集群的指令，以得到过渡集群；所述过渡集群中包括全部第一节点和全部第二节点；

处理模块，被配置为在所述过渡集群中，将各个第二节点中的全部分区的数据，分别迁移至各个第一节点中；其中，第一节点与第二节点一一对应，每个第二节点均存储多个分区数据；

所述处理模块，还被配置为更新所述过渡集群中全部节点的配置信息，得到目标集群，所述目标集群中仅包括第一节点。

第三方面，本申请实施例提供一种计算机可读存储介质，其包括指令，当其在计算机上运行时，使得计算机执行如第一方面所述的集群迁移方法。

第四方面，本申请实施例提供一种计算设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现第一方面所述的集群迁移方法。

相较于现有技术，本申请实施例中，迁移控制节点通过将目标容器环境中新建的第一节点加入虚拟机或物理机环境中的源集群，得到一个完整的过渡集群，然后在该过渡集群中完成源集群的全部第二节点中的分区数据到第一节点的迁移，最后关停源集群。由于本申请实施例中的数据迁移操作是在同一个集群中完成的，而不是现有技术中的不同集群间完成，相当于避免了数据的跨域传输，提高了数据的传输效率，节省了网络资源和时间。另外，由于本申请实施例中是通过迁移控制节点更新新旧集群节点的网络配置信息，实现数据迁移后的数据传输目的地址的转换，相当于通过一个固定的中转站中转了业务方(消费者、生产者)与集群的数据传输，而不是现有技术中业务方与集群直接连接的方式，从而使得在集群迁移开始前到结束后，业务方可以通过所述中转站分别连接旧节点或新节点，避免了集群迁移过程中可能发生的抖动，实现了集群的热迁移，不会发生业务中断的情况。

附图说明

通过参考附图阅读本申请实施例的详细描述，本申请实施例的目的、特征和优点将变得易于理解。其中：

图1为本申请实施例中集群迁移方法的一种集群迁移系统示意图；

图2为本申请实施例中集群迁移方法的一种流程示意图；

图3为本申请实施例中集群迁移方法的一种集群迁移的节点变化过程示意图；

图4为本申请实施例中集群迁移方法的一种将第二节点的数据迁移至第一节点的流程示意图；

图5为本申请实施例中集群迁移方法的一种将第二分区的数据迁移至第一节点的流程示意图；

图6为本申请实施例中集群迁移方法的一种数据迁移的分区变化过程示意图；

图7为本申请实施例中集群迁移方法的一种信令交互图；

图8为本申请实施例中控制节点的一种结构示意图；

图9为本申请实施例中计算设备的一种结构示意图；

图10为本申请实施例中服务器的一种结构示意图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

本申请实施例的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象(例如第一节点和第二节点分别表示为不同的节点，其他类似)，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块，本申请实施例中所出现的模块的划分，仅仅是一种逻辑上的划分，实际应用中实现时可以有另外的划分方式，例如多个模块可以结合成或集成在另一个系统中，或一些特征可以忽略，或不执行。另外，所显示的或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，模块之间的间接耦合，通信连接可以是电性或其他类似的形式，本申请实施例中均不作限定。并且，作为分离部件说明的模块或子模块可以是也可以不是物理上的分离，可以是也可以不是物理模块，或者可以分布到多个电路模块中，可以根据实际的需要选择其中的部分或全部模块来实现本申请实施例方案的目的。

本申请实施例提供一种集群迁移方法、相关装置及存储介质，可应用于集群迁移系统，该集群迁移系统可包括作为迁移目的节点的第一节点、源集群和迁移控制节点。该迁移控制节点至少用于将各个第一节点加入所述源集群，得到过渡集群，并在该过渡集群中将各个第二节点中的全部分区数据，分别迁移至各个第一节点。该源集群部署于虚拟机或物理机环境，其包括各个第一节点，各个第一节点部署了集群服务程序和数据。其中，迁移控制节点可为将各个第二节点中所有分区数据，分别迁移至各个第一节点的应用程序，或为安装了将各个第二节点中所有分区数据，分别迁移至各个第一节点的应用程序的服务器。

本申请实施例的方案可基于云技术实现，具体来说涉及云技术中的云计算、云存储和数据库等技术领域，下面将分别进行介绍：

云技术(Cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术(Cloudtechnology)基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。本申请实施例可通过云技术对目标迁移数据进行保存。

云存储(cloud storage)是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。在本申请实施例中，可将网络配置等信息均保存在该存储系统中，便于服务器调取。

目前，存储系统的存储方法为：创建逻辑卷，在创建逻辑卷时，就为每个逻辑卷分配物理存储空间，该物理存储空间可能是某个存储设备或者某几个存储设备的磁盘组成。客户端在某一逻辑卷上存储数据，也就是将数据存储在文件系统上，文件系统将数据分成许多部分，每一部分是一个对象，对象不仅包含数据而且还包含数据标识(ID，ID entity)等额外的信息，文件系统将每个对象分别写入该逻辑卷的物理存储空间，且文件系统会记录每个对象的存储位置信息，从而当客户端请求访问数据时，文件系统能够根据每个对象的存储位置信息让客户端对数据进行访问。

存储系统为逻辑卷分配物理存储空间的过程，具体为：按照对存储于逻辑卷的对象的容量估量(该估量往往相对于实际要存储的对象的容量有很大余量)和独立冗余磁盘阵列(RAID，Redundant Array of Independent Disk)的组别，预先将物理存储空间划分成分条，一个逻辑卷可以理解为一个分条，从而为逻辑卷分配了物理存储空间。

数据库(Database)，简而言之可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

数据库管理系统(英语：Database Management System，简称DBMS)

是为管理数据库而设计的电脑软件系统，一般具有存储、截取、安全保障、5备份等基础功能。数据库管理系统可以依据它所支持的数据库模型来作分

类，例如关系式、XML(Extensible MarkupLanguage,即可扩展标记语言)；或依据所支持的计算机类型来作分类，例如服务器群集、移动电话；或依据所用查询语言来作分类，例如SQL(结构化查询语言(StructuredQueryLanguage)、XQuery；或依据性能冲量重点来作分类，例如最大规模、0最高运行速度；亦或其他的分类方式。不论使用哪种分类方式，一些DBMS能够跨类别，例如，同时支持多种查询语言。在本申请实施例中，可目标迁移数据存储在该数据库管理系统中，便于服务器调取。

现有技术中，Kafka集群节点往往通过真实网络地址与业务方(生产

者节点或消费者节点)绑定，在需要将Kafka集群由原来的部署环境迁移5至新的部署环境(例如由物理机环境迁移至容器环境)时，由于集群节点的真实网络地址不可变更，往往会在迁移过程中中断对业务方的服务，造成业务方的系统停机，给用户带来极大不便；而且，由于现有技术中在进行集群迁移时，往往是将旧集群的数据跨域迁移至新集群中，数据传输流程较长，需要消耗较多传输资源。

0相比于现有技术，本申请实施例可以将目标容器环境中新建的第一节

点加入源集群，得到一个过渡集群，然后在该过渡集群中完成源集群的全部第二节点中的分区数据到第一节点的迁移，最后关停源集群。由于本申请实施例中的数据迁移操作是在同一个集群中完成的，而不是现有技术中

的不同集群间完成，相当于避免了数据的跨域传输，提高了数据的传输效5率，节省了网络资源和时间。另外，由于本申请实施例中是通过迁移控制

节点更新新旧集群节点的网络配置信息，实现数据迁移后的数据传输目的地址的转换，相当于通过一个固定的中转站中转了业务方(消费者、生产者)与集群的数据传输，而不是现有技术中业务方与集群直接连接的方式，从而使得在集群迁移开始前到结束后，业务方可以通过所述中转站分别连接旧节点或新节点，避免了集群迁移过程中可能发生的抖动，实现了集群的热迁移，不会发生业务中断的情况。

一些实施方式中，本申请实施例提供的集群迁移方法可基于图1所示的一种集群迁移系统实现。该集群迁移系统可以包括迁移控制节点01、第一节点02和第二节点03。

该迁移控制节点01用于将第一节点02和第二节点03组合，得到过渡集群，并在过渡集群中将第二节点03中的分区数据迁移至第一节点02，以及在分区数据迁移后，更新过渡集群中的第一节点02和第二节点03的配置信息，关停第二节点03，得到仅包括第一节点02的目标集群。

需要说明的是，本申请实施例涉及的服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

参照图2，图2为本申请实施例中集群迁移方法的一种流程示意图。该方法可应用于集群迁移系统，由迁移控制节点执行，在不中断业务的前提下，将集群服务程序由源集群(例如虚拟机或物理机环境)迁移到目标集群(例如容器环境)。该集群迁移系统还包括分离部署的源集群和目标容器环境，所述目标容器环境中包括多个第一节点，所述源集群中包括多个第二节点，第一节点与第二节点的数量相同；该集群迁移方法包括步骤101-103：

步骤101，将各个第一节点加入所述源集群，得到过渡集群。

其中，所述过渡集群中包括全部第一节点和全部第二节点。在本申请实施例中，源集群可以是物理服务器集群或虚拟服务器集群，其中可以部署有集群服务程序，该集群服务程序可以为业务系统运行提供服务支持；例如可以是ActiveMQ、RabbitMQ、RocketMQ和Kafka等消息中间件，用于协调数据生产者(例如服务端)和数据消费者(例如客户端)之间的数据传输工作。在一些应用场景下，可能出于提升服务程序部署环境的性能等原因，需要将源集群中的集群服务程序迁移至新集群中，以使得集群服务程序部署在具有更高性能的机器环境中。

在进行集群迁移时，需要明确迁移工作的目的地(例如相对于源集群中原有节点的新节点)，即集群服务程序和数据将被迁移至何处。由此，本申请实施例中可以获取目标容器环境中创建的各个第一节点(即目的集群中的节点)，该第一节点可以用于承接源集群中的集群服务程序的部分数据；例如，一个第一节点可以承接源(Kafka)集群中的一个第二节点(即Kafka中的broker)的全部数据。可以理解的是，本申请实施例中，源集群中的每一个第二节点的全部数据可能均需要迁移至新节点，由此，可以在目标容器环境中创建与第二节点的数量相同的多个第一节点，以便能够承接源集群的全部数据。

需要说明的是，本申请实施例中的目标容器环境可以是在进行集群迁移之前，由第三方(或者集群维护方)事先建立的，也可以是由迁移控制节点建立的，本申请实施例对此不做限定。该目标容器环境可以是采用Docker技术构建的一个用于为程序服务提供运行环境支持的单元。在一些可选实施例中，迁移控制节点还可以创建目标容器环境，以及在目标容器环境中创建预设数量的第一节点。

在明确集群迁移涉及到的源集群和目的地(即各个第一节点)之后，可以将各个第一节点与各个第二节点置入一个集群中，得到一个过渡集群，以便在该过渡集群中完成数据迁移工作。由于本申请实施例中的数据迁移操作是在同一个集群中完成的，而不是现有技术中的不同集群间完成，相当于避免了数据的跨域传输，提高了数据的传输效率，节省了网络资源和时间。

在本申请实施例中，例如，参照图3，可以将第一节点加入到源集群中，得到过渡集群；或者也可以将将各个第二节点从源集群中分离，并与各个第一节点组建一个区别于源集群的过渡集群，本领域的技术人员可以根据实际需要进行设置，此处不做限定。

在一些可选实施例中，将各个第一节点加入所述源集群，得到所述过渡集群的具体方式可以是：将各个第一节点在源集群的控制节点中注册，从而各个第一节点可以受到源集群中的控制节点的控制，即得到所述过渡集群。

考虑到，源集群中的控制节点实质上是从各个第二节点中选举出来的(即由一个第二节点预先注册得到)，即控制节点本身也是源集群中的某一个节点(例如可以是物理服务器或虚拟服务器)，属于集群迁移工作完成后需要关停的对象。因此，在集群迁移工作进行到某个进度时，需要更换控制节点，以便关停源集群后，维持新集群(即目标集群)的正常运转。由此，在本申请实施例中，可以从各个第一节点中获取一个作为候选控制节点，以便该候选控制节点在预设时刻接替源集群中原有的控制节点，即候选集群中将包括一个主控制节点(即源集群中原有的控制节点)和一个候选控制节点(基于一个第一节点得到)。

在现有技术中，Kafka集群中各个Broker节点将在Zookeeper节点共同注册，并从各个Broker节点中产生一个临时节点，即只有一个Broker节点会注册成功(成为源集群的主控制节点)，其它节点的注册行为都会失败。因此，该成功在Zookeeper节点上注册的临时节点会成为Kafka集群的控制节点(Controller)，其可以在Zookeeper节点注册监听Watch服务，即Controller可以监听其他的Broker节点的所有信息。若该Controller对应的Broker节点宕机，在Zookeeper节点上面注册的临时节点就会消失，此时所有的Broker节点又会一起去Zookeeper节点上注册，因为只有一个Broker节点会注册成功，其他的都会失败，所以成功在Zookeeper节点上注册成为临时节点的Broker会成为Kafka集群的新Controller。

具体来说，一旦原有Controller对应的Broker节点宕机，新Controller对应的Broker节点会读取该宕机Broker节点上所有的分区Partition在Zookeeper节点上的状态，并选取Isr列表中的一个副本Replica作为主分区Partition Leader(如果Isr列表中的Replica全部不可用，则选一个Isr列表外可用的Replica作为Partition Leader；如果该Partition的所有的Replica都宕机了，则将新的Partition Leader设置为-1，等待Isr中的任一个Replica恢复过来，并且选它作为Partition Leader；或选择第一个恢复过来的Replica作为Partition Leader)。另外原有Controller会通知Zookeeper节点其对应的Broker节点宕机的消息，Zookeeper节点会通知其他的Broker节点，以便注册选取出新的Controller。

可见，现有技术中，源集群只在主控制节点出现故障时，才从各个第二节点中选举出新的主控制节点。而本申请实施例中，集群迁移工作需要在确保业务不中断的前提下进行，且在集群迁移工作完成时，主动关停源集群的各个第二节点；由此，在本申请实施例中，采用现有技术的控制节点交接方式，可能会产生控制节点频繁更替的问题，例如在源集群的历史主控制节点关停之后，新的主控制节点依然在第二节点中产生，从而使得该新的控制节点依然需要主动关停，进而进入又一轮的主控制节点选取步骤。

为了实现集群迁移工作中，主控制节点的有序交接，保证集群迁移不影响正常的业务系统运行。在本申请实施例中，可以在各个第一节点加入源集群，得到过渡集群之后，从过渡集群的各个第一节点中，选举一个候选控制节点(即由一个一个第一节点注册得到)，该候选控制节点可以同步所述主控制节点中的配置信息，并在接收到预设指令时，接替所述主控制节点。可以理解的是，候选控制节点的产生方式，可以与现有技术中类似，即可以由各个第一节点在Zookeeper节点上注册得到；或者，也可以由迁移控制节点随机从各个第一节点中选取，此处不作限定。

可以理解的是，本申请实施例中的候选控制节点在产生后，可以实时获取主控制节点的控制信息，例如过渡集群中的各个节点的运行信息，以便随时接替主控制节点。在一些可选实施例中，若主控制节点出现故障，可以由候选控制节点立即接替主控制节点，成为新的主控制节点，并同时(从各个第一节点中)产生新的候选控制节点，以便保证直至各个第二节点关停之前，控制节点均在各个第一节点中产生，不会因为源集群的第二节点关停，带来额外的工作量。

考虑到，在新旧控制节点的交接过程中，可能会由于新控制节点(即过渡集群的候选控制节点)与旧控制节点(即过渡集群的主控制节点)的来源不同，造成一些控制配置信息无法完整迁移，产生错误，使得新控制节点无法正确实施控制。为了提早发现上述迁移错误，尽量避免迁移错误后持续的错误工作带来的重复操作，在一些可选实施例中，可以监控集群迁移进度，并在进行到预设进度时，由迁移控制节点发送预设指令至候选控制节点，使得该候选控制节点可以主动接替主控制节点，对过渡集群中的各个节点进行控制。因此，可以提前发现新的控制节点是否存在问题，无法如旧控制节点一般提供服务，从而可以在问题发生时尽量提早回溯，提高了迁移系统的可用性。

以上介绍了集群迁移工作中更换控制节点的一种可能方式，下面继续介绍如何将第二节点中的数据迁移至第一节点。

步骤102，在所述过渡集群中，将各个第二节点中的全部分区数据，分别迁移至各个第一节点中。

其中，第一节点与第二节点一一对应，每个第二节点均包括多个分区数据。

在本申请实施例中，源集群可以是Kafka集群，各个第二节点可以是Broker节点，由此，每个第二节点中可以包括多个主题Topic，每个主题可以包括多个分区Partition。考虑到，为了将各个第二节点的数据完整迁移至新节点中，在步骤101中，于目标容器环境中创建了预设数量的第一节点。因此，第一节点可以与第二节点一一对应，从而使得每个第二节点均具有对应的数据迁移目的节点(即第一节点)，保证数据迁移工作的有序进行。

在需要将一个第二节点中的数据迁移至其对应的第一节点时，为了保证不中断业务系统的运行，即该第二节点可以持续提供数据支持服务，可以根据该第二节点中的数据活跃状态，采用不同的数据迁移策略；例如，针对活跃数据，可以迁移其副本，避免数据占用影响正常的业务运行。参照图4，迁移一个第二节点中的全部数据至该第二节点对应的第一节点，可以包括步骤201-202：

步骤201，根据各个消费者节点的历史消费记录，从该第二节点的全部分区中获取第一分区和第二分区。

其中，第一分区的历史消费次数不大于预设值，第二分区的历史消费次数大于所述预设值。

在本申请实施例中，为了确定待迁移数据的活跃状态，可以利用Kafka集群中，每个分区的数据只能被一个消费者节点消费的特性，通过统计消费者节点的历史消费记录，获取活跃的数据分区与不活跃的数据分区。

具体来说，在需要对将一个第二节点的数据迁移时，可以获取全部消费者节点的历史消费记录，然后分析出其中消费该第二节点的记录数据，并确定该第二节点中各个分区被消费的次数；若一个分区被消费的次数不大于所述预设值(例如是10)，则可以认为该分区的数据不经常被访问，其是不活跃的，即可以将其确定为第一分区(不活跃分区)；类似地，若一个分区被消费的次数大于所述预设值，则可以认为该分区的数据经常被访问，其是活跃的，即可以将其确定为第二分区(活跃分区)。

可以理解的是，为了保证根据历史消费记录确定的数据活跃状态与当前情况(即数据迁移时的情况)贴合，从而可以准确区分数据迁移时的活跃数据与不活跃数据。在一些可选实施例中，可以获取距离当前时刻最近的一段历史时段内的消费记录为历史消费记录，例如可以获取数据迁移前7日内的消费者节点的消费记录为历史消费记录。

步骤202，根据第一迁移策略，将各个第一分区的数据，迁移至所述第一节点；并根据第二迁移策略，将各个第二分区的数据，迁移至所述第一节点。

在本申请实施例中，确定待迁移的第二节点中各个分区的活跃状态之后，即可根据预先设置的迁移策略，将各个分区中的数据迁移至该第二节点对应的第一节点中。具体来说，针对不活跃的第一分区，可以采用第一迁移策略，将其中的数据无差别地迁移至对应的第一节点中；针对活跃的第二分区，可以采用第二迁移策略，将其中的数据有差别地迁移至对应的第一节点中。

需要说明的是，即使是不活跃的第一分区，其中的数据被消费的状态也不完全一致。具体来说，在Kafka集群中，每个Broker节点包括多个分区，这些分区中并不仅仅包括一个数据，而是相同主题的一个数据序列，由生产者节点产生的时序在后的数据可以以队列的形式追加存储在在先数据后面，形成所述数据序列。

例如，在Kafka集群中，每个分区可以以文件夹的形式存在，在每个分区文件夹中可以包括多组segment文件，每组segement文件包含.index、.log文件和.timeindex文件，其中，log文件是实际存储消息的位置，index和timeindex文件为索引文件，用于检索消息。在接收到生产者节点生成的消息之后，该消息顺序写入segement中，只有最后一个segement才能执行写入操作。

可见，一个分区中包括多个数据(即segment文件)，而该分区中的多个数据被消费者消费的次数也不会完全相同，即各个数据也有活跃度的区分。然而，虽然第一分区中的各个数据的活跃度不同，但大体上还是没有被频繁的消费，都可以归属于不活跃数据，由此，可以采用统一的第一迁移策略，完整无差别地将第一分区的数据迁移至第一分区中。

步骤101中提及：在集群迁移中，不仅仅需要迁移源集群中各个第二节点上存储的数据，还需要将源集群中的控制节点变更，即由第一节点中得到的候选控制节点接替基于第二节点得到的主控制节点。

考虑到，各个第一分区均为不活跃的分区，可以直接整体迁移至对应的第一节点中，而不是像第二分区的迁移操作需要区分不同的数据，并分别采用不同的方式处理；即第一分区的数据迁移速度可能更快，可以更早完成，若在各个第二节点中的第一分区均完成迁移时，由候选控制节点接替主控制节点，可能可以及早发现集群迁移中可能出现的问题，及时回溯。

由此，在一些可选的实施例中，可以(实时或定时)获取各个第二节点的全部第一分区的迁移进度，若全部第一分区的迁移进度符合预设条件(例如迁移进度指示各个第一分区的数据均已经迁移至第一节点中)，则向所述候选控制节点发送所述预设指令，使得该候选控制节点可以接替主控制节点，以测试其是否能够正确控制过渡集群中的各个节点，正常地完成整个集群的数据支持服务。

与第一分区的情况类似，第二分区中也包括多个数据，这些数据的活跃度也不会完全相同。例如，在一些第二分区中，可能存在活跃数据和不活跃的数据，活跃数据可能会被消费者节点频繁消费，例如一些数据在历史时段内被消费者节点访问的次数超过所述预设值，而不活跃数据可能很少被消费者消费，例如在历史时段内被消费者节点消费的次数未超过所述预设值。由此，可以针对第二分区中活跃数据与不活跃数据，采用第二迁移策略，进行有差别地迁移，既不影响数据迁移时活跃数据被消费者节点访问，又使得不活跃数据可以更快地完成迁移。

参照图5，在一些可选实施例中，所述根据所述第二迁移策略，将一个第二分区的数据，有差别地迁移至所述第一节点时，可以将该第二分区中的活跃数据与不活跃数据区别处理，具体包括步骤2021-2024：

步骤2021，获取所述第二分区中的活跃数据。

在本申请实施例中，第二分区中的活跃数据是也可以是依据历史消费记录确定，即根据第二分区中各个数据在历史时段内被消费者节点消费的次数确定。若某个数据被消费的次数超过所述预设值，则可以将其确定为活跃数据。

步骤2022，将所述活跃数据的副本与第一增量数据存入缓存区。

其中，所述缓存区用于为生产者节点和消费者节点提供数据服务，所述第一增量数据由生产者节点在第一时段产生。

在本申请实施例中，考虑到活跃数据被消费者消费频繁，即其可能在数据迁移时依然需要被消费者消费。为了不影响活跃数据被迁移时，继续为消费者节点提供数据服务，可以获取活跃数据的副本，然后将该副本存入缓存区，通过缓存区为消费者提供数据服务，既不会中断业务系统的运行，又可以使的第二分区中的各个数据被完整迁移至第一节点中。

可以理解的是，在Kafka集群中，每个分区均可以包括多个副本，以便在某个(主)分区故障时，上位成为新的(主)分区。由此，在本申请实施例中，在迁移一个第二节点中的一个第二分区中的活跃数据时，可以获取该第二分区的副本，并基于该第二分区的副本获取活跃数据的副本，将该活跃数据的副本存入缓存区，以在数据迁移时提供数据服务。

考虑到，在Kafka集群中，为了保证数据的安全，使得某个节点出现故障时，该节点中的各个分区依然保有完整数据备份，可以代替故障的(主)分区，继续承担数据服务，一个分区及其副本是存储在不同节点上的。例如，Kafka集群中包括3个节点，那么A节点中的分区A1可以包括2个副本，这两个副本可以分别存储在节点B和节点C中。由此，若根据第二分区的副本获取其中活跃数据的副本，则涉及到跨节点数据传输，可能较为不便；因此，在一些可选实施例中，可以直接将待迁移的第二分区中的活跃数据复制，得到其副本，存入缓存区中，以便更加快捷高效地实现数据处理。

为了保证在集群迁移过程中继续为业务系统提供数据服务支持，本申请实施例中还需要考虑到生产者节点的消息生产需求。在本申请实施例中，在一个第二节点开始进行数据迁移工作之后的一段时间(例如开始迁移到得到该第二节点对应的目标分区之间的一段时间，即第一时段)，可以将需要存入该第二节点中的由生产者节点新生成的消息，称为第一增量数据，该第一增量数据也可以存入缓存区中，以便继续为生产者节点和消费者节点提供数据服务，且不影响正常的数据迁移。

在本申请实施例中，数据迁移时，是以分区为单位进行的。由此，为了保证各个分区均能够在进行数据迁移时，及时提供数据服务，在一些可选实施例中，可以对应每个分区均设置一个缓存区。即每个第二节点可以设置于其中的第二分区数量相同的缓存区，以便一对一地为各个第二分区提供数据缓存服务，使得各个第二分区均可以无障碍地在数据迁移时，继续支持消费者节点和生产者节点的数据服务。

步骤2023，迁移所述第二分区中的全部数据至所述第一节点，得到目标分区。

其中，所述全部数据在所述第二分区中的存储顺序，与在所述目标分区中相同。

由于设置了缓存区，因此，可以在迁移第二分区的数据时，将该第二分区的数据进行整体迁移，而不必考虑活跃数据如何为消费者节点提供数据消费支持，且可以继续承接生产者节点产生的新消息。

参照图6，本申请实施例中，在迁移第二分区中的数据时，可以按照该分区中各个数据的存储位置，进行数据迁移，以保证其中的数据迁移至第一节点之后，可以得到与该第二分区完全一致的目标分区；即目标分区中的数据、数据存储位置和存储顺序，与对应的第二分区相同。

步骤2024，将所述缓存区中的所述第一增量数据迁移至所述目标分区。

在本申请实施例中，一个待迁移的第二分区中全部数据迁移至第一节点之后，可以得到目标分区，然而此时目标分区中的数据并不完整，还需要将开始数据迁移操作之后，由生产者节点产生的消息(即缓存区中的第一增量数量)存储至目标分区中。具体来说，由于Kafka集群中一个broker节点的下各个分区的数据是按照时序追加存储的，因此，在将一个第二分区中的全部数据迁移至第一节点，得到对应的目标分区之后，可以直接在该目标分区中最末端数据之后，直接追加存储该第二分区对应的缓存区中的第一增量数据。

考虑到，生产者节点生产消息的动作可能在持续进行，即在将缓存区中的旧增量数据(即第一增量数据)存储至其对应的目标分区中时，新的增量数据还在不断产生，即缓存区中的增量数据是在不断增加的。为了避免缓存区中的数据冲突，在一些可选实施例中，还可以在将缓存区中的第一增量数据存储至其对应的目标分区中的同时，停止将此时段(即第二时段，该第二时段可以与第一时段在时序上相连，以便数据迁移工作的持续进行)生产者节点产生的第二增量数据存入所述缓存区，并将该第二增量数据存入所述目标分区的预设位置；其中，所述预设位置基于缓存区中的第一增量数据确定。

例如，一个第二分区包括3个数据段：a1、a2和a3，在t1时刻，开始将该第二分区中的3个数据段迁移至对应的第一节点；在t2时刻，生产者节点产生2个新消息：a4和a5，由此，该第二分区的缓存区中存储了第一增量数据a4和a5；在t3时刻(即第一时段包括t1-t3时刻)，a1、a2和a3完全迁移成功，得到了该第二分区的目标分区，该目标分区中存储有a1、a2和a3；在t4时刻(即第二时段)，开始将缓存区中的第一增量数据a4和a5迁移至目标分区中，此时，生产者节点又新生了一个消息a6(即第二增量数据)，由此，可以根据缓存区中包括的两个第一增量数据，确定a6应该存储在目标分区中的第6个数据位置，并开始将a6存储至目标分区中的对应位置。即，本申请实施例中，在得到目标分区之后，生产者节点新生的消息就不再存入缓存区，而是存入对应的目标分区中。

步骤103，更新所述过渡集群中全部节点的配置信息，得到目标集群。

其中，所述目标集群中仅包括第一节点。

在本申请实施例中，在将各个第二节点中的全部分区的数据迁移至对应的第一节点之后，第二节点就可以不再继续提供数据服务，即可以将各个第二节点关停。例如，可以将生产者节点和消费者节点对应的集群节点地址，由第二节点的地址变为第一节点的地址。

考虑到，在一些场景下，集群中各个节点的真实网络地址(例如真实IP地址)不可变更，若将该真实网络地址直接与生产者节点或消费者节点对接，则无法在不中断业务的前提下，实现集群迁移。因此，在本申请实施例中，可以通过地址映射的方式，将一个中间地址与集群节点的真实网络地址映射，然后以该中间地址与生产者节点或消费者节点建立连接。

具体来说，在本申请实施例中，各个第二节点通过预设网络地址映射与消费者节点和生产者节点建立通讯连接；所述预设网络地址映射包括各个第二节点的真实网络地址与预设网络地址的映射，所述预设网络地址包括以下项之一：域名、虚拟网络地址或转发节点地址。基于此，可以通过将所述预设网络地址映射中的各个第二节点的真实网络地址更新为各个第一节点的真实网络地址，以实现过渡集群中各个节点的配置信息的更新，从而关停该过渡集群中的各个第二节点，得到目标集群。

例如，若业务方(消费者节点和生产者节点)通过域名接入源集群，则将目标容器环境的第一节点的真实网络地址加入域名映射；若业务方采用虚拟网络地址接入源集群，则需调整虚拟网络地址代理的后端主机地址(即由源集群中各个第二节点的真实网络地址调整为各个第一节点的真实网络地址)；若业务方采用流量转发，则需要调整IPTables规则，此次不再一一赘述。

由此，在集群迁移的最后阶段，将旧集群节点的真实网络地址与中间地址解绑，然后与新集群节点的真实网络地址绑定，即可实现消费者节点和生产者节点对应的集群节点的切换。在本申请实施例中，由于消费者节点和生产者节点是与中间地址建立的通讯连接，由此，即使改变中间地址绑定的集群节点，消费者节点和生产者节点也是无感的，不会造成业务的中断。

虽然本申请图2所示的实施例中以迁移控制节点为执行主体介绍了一种可以在不中断业务的前提下，实现的集群迁移方法，但是不限于此。在一些可选实施例中，也可以由迁移控制节点向源集群中的各个第二节点，以及目标容器环境中新建的各个第一节点发送指令，由第一节点、第二节点以及迁移控制节点之间交互，完成整个集群服务程序的迁移。参照图7，在一些可选实施例中，可以通过以下步骤301-305将一个第二节点中的数据迁移至一个第一节点：

步骤301，迁移控制节点向第一节点发送第一指令。

其中，所述第一指令可以用于指示第一节点加入源集群。

步骤302，第一节点接收所述第一指令，并基于该第一指令加入源集群。

步骤303，所述迁移控制节点向第二节点发送第二指令。

其中，所述第二指令可以用于指示第二节点开始进行数据迁移。

步骤304，第二节点接收所述第二指令，并基于该第二指令将数据迁移至第一节点中。

步骤305，第二节点向所述迁移控制节点发送消息。

其中，所述消息可以用于表示第二节点中的数据已经全部迁移至第一节点。

步骤306，所述迁移控制节点接收所述消息，并基于该消息更新过渡集群中全部节点的配置信息，以得到目标集群。

本申请实施例中，通过将目标容器环境中新建的第一节点加入虚拟机或物理机环境中的源集群，得到一个完整的过渡集群，然后在该过渡集群中完成源集群的全部第二节点中的分区数据到第一节点的迁移，最后关停源集群。由于本申请实施例中的数据迁移操作是在同一个集群中完成的，而不是现有技术中的不同集群间完成，相当于避免了数据的跨域传输，提高了数据的传输效率，节省了网络资源和时间。另外，由于本申请实施例中是通过迁移控制节点更新新旧集群节点的网络配置信息，实现数据迁移后的数据传输目的地址的转换，相当于通过一个固定的中转站中转了业务方(消费者、生产者)与集群的数据传输，而不是现有技术中业务方与集群直接连接的方式，从而使得在集群迁移开始前到结束后，业务方可以通过所述中转站分别连接旧节点或新节点，避免了集群迁移过程中可能发生的抖动，实现了集群的热迁移，不会发生业务中断的情况。

以上对本申请实施例中一种集群迁移方法进行说明，以下对执行上述集群迁移方法的集群迁移系统(例如服务器集群)进行介绍。

参阅图8，如图8所示的一种控制节点的结构示意图，其可应用于服务器集群中，用于在不中断业务的前提下，将集群服务程序由源集群(例如虚拟机或物理机环境)迁移到目标集群(例如容器环境)。在本申请实施例中的控制节点能够实现对应于上述图2中所对应的实施例中所执行的集群迁移方法的步骤。集群迁移系统实现的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。所述控制节点可包括收发模块601及处理模块602，所述节点还可以包括显示模块(图5中未标识出)，所述处理模块602、所述收发模块601的功能实现可参考图2所对应的实施例中所执行的操作，此处不作赘述。例如，所述处理模块602可用于控制所述收发模块601的收发、获取等操作。

在一些实施方式中，控制节点60应用于集群迁移系统，该集群迁移系统还包括分离部署的源集群和目标容器环境，所述目标容器环境中包括多个第一节点，所述源集群中包括多个第二节点，第一节点与第二节点的数量相同；

所述收发模块601，被配置为向各个第一节点发送加入所述源集群的指令，以得到过渡集群；所述过渡集群中包括全部第一节点和全部第二节点；

所述处理模块602，还被配置为在所述过渡集群中，将各个第二节点中的全部分区的数据，分别迁移至各个第一节点中；其中，第一节点与第二节点一一对应，每个第二节点均存储多个分区数据；

所述处理模块602，还被配置为更新所述过渡集群中全部节点的配置信息，得到目标集群，所述目标集群中仅包括第一节点。

在一些实施方式中，所述过渡集群包括主控制节点和候选控制节点，所述主控制节点由一个第二节点预先注册得到，所述候选控制节点由一个第一节点注册得到；

所述候选控制节点用于同步所述主控制节点中的配置信息，并在接收到预设指令时，接替所述主控制节点。

在一些实施方式中，各个第二节点通过预设网络地址映射与消费者节点和生产者节点建立通讯连接；

所述预设网络地址映射包括各个第二节点的真实网络地址与预设网络地址的映射，所述预设网络地址包括以下项之一：域名、虚拟网络地址和转发节点地址；

所述处理模块602，还被配置为将所述预设网络地址映射中的各个第二节点的真实网络地址更新为各个第一节点的真实网络地址。

在一些实施方式中，所述处理模块602，还被配置为根据各个消费者节点的历史消费记录，从该第二节点的全部分区中获取第一分区和第二分区，第一分区的历史消费次数不大于预设值，第二分区的历史消费次数大于所述预设值；以及根据第一迁移策略，将各个第一分区的数据，迁移至所述第一节点；并根据第二迁移策略，将各个第二分区的数据，迁移至所述第一节点。

在一些实施方式中，所述处理模块602，还被配置为获取所述第二分区中的全部活跃数据，各个活跃数据在历史时段内被消费者节点消费的次数超过所述预设值；以及将各个活跃数据的副本与第一增量数据存入缓存区，其中，所述缓存区用于为生产者节点和消费者节点提供数据服务，所述第一增量数据由生产者节点在第一时段产生；

所述处理模块602，还被配置为迁移所述第二分区中的全部数据至所述第一节点，得到目标分区；其中，所述全部数据在所述第二分区中的存储顺序，与在所述目标分区中相同；并将所述缓存区中的所述第一增量数据迁移至所述目标分区。

在一些实施方式中，所述处理模块602，还被配置为所述迁移所述第二分区中的全部数据至所述第一节点，得到目标分区之后，将第二增量数据存入所述目标分区的预设位置；

其中，所述第二增量数据由生产者节点在第二时段产生，所述第二时段与所述第一时段时序相邻，且不早于所述第一时段；所述预设位置基于所述缓存区中的所述第一增量数据确定。

在一些实施方式中，所述处理模块602，还被配置为在所述更新所述过渡集群中全部节点的配置信息，得到目标集群之前，获取各个第二节点的全部第一分区的迁移进度；以及若全部第一分区的迁移进度符合预设条件，则向所述候选控制节点发送所述预设指令。

本申请实施例中，在处理模块控制下，控制节点通过将容器环境中新建的第一节点加入虚拟机或物理机环境中的源集群，得到一个完整的过渡集群，然后在该过渡集群中完成源集群的全部第二节点中的分区数据到第一节点的迁移，最后关停源集群。由于本申请实施例中的数据迁移操作是在同一个集群中完成的，而不是现有技术中的不同集群间完成，相当于避免了数据的跨域传输，提高了数据的传输效率，节省了网络资源和时间。另外，由于本申请实施例中是通过控制节点更新新旧集群节点的网络配置信息，实现数据迁移后的数据传输目的地址的转换，相当于通过一个固定的中转站中转了业务方(消费者、生产者)与集群的数据传输，而不是现有技术中业务方与集群直接连接的方式，从而使得在集群迁移开始前到结束后，业务方可以通过所述中转站分别连接旧节点或新节点，避免了集群迁移过程中可能发生的抖动，实现了集群的热迁移，不会发生业务中断的情况。

上面从模块化功能实体的角度对本申请实施例中的控制节点60进行了描述，下面从硬件处理的角度分别对本申请实施例中的执行集群迁移方法的服务器进行描述。

需要说明的是，在本申请控制节点实施例的图8所示的收发模块601对应的实体设备可以为输入/输出单元、收发器、射频电路、通信模块和输入/输出(I/O)接口等，处理模块602对应的实体设备可以为处理器。图8所示的控制节点60可以具有如图9所示的结构，当图8所示的控制节点60具有如图9所示的结构时，图9中的处理器和收发器能够实现前述对应该节点的节点实施例提供的处理模块602和收发模块601相同或相似的功能，图9中的存储器存储处理器执行上述集群迁移方法时需要调用的计算机程序。

本申请实施例还提供了一种服务器，请参阅图10，图10是本申请实施例提供的一种服务器结构示意图，该服务器1100可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(英文全称：central processing units，英文简称：CPU)1122(例如，一个或一个以上处理器)和存储器1132，一个或一个以上存储应用程序1142或数据1144的存储介质1130(例如一个或一个以上海量存储设备)。其中，存储器1132和存储介质1130可以是短暂存储或持久存储。存储在存储介质1130的程序可以包括一个或一个以上模块(图中未示出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1122可以设置为与存储介质1130通信，在服务器1100上执行存储介质1130中的一系列指令操作。

服务器1100还可以包括一个或一个以上电源1126，一个或一个以上有线或无线网络接口1150，一个或一个以上输入输出接口1158，和/或，一个或一个以上操作系统1141，例如Windows Server，Mac OS X，Unix,Linux，FreeBSD等等。

上述实施例中由服务器所执行的步骤可以基于该图10所示的服务器1100的结构。例如，例如上述实施例中由图10所示的控制节点60所执行的步骤可以基于该图10所示的服务器结构。例如，所述中央处理器1122通过调用存储器1132中的指令，执行以下操作：

通过输入输出接口1158向各个第一节点发送指令，以使各个第一节点加入源集群，得到过渡集群；其中，各个第一节点部署于目标容器环境，各个第二节点部署于源集群，第一节点与第二节点的数量相同；

将各个第二节点中的全部分区的数据，分别迁移至各个第一节点中，其中，第一节点与第二节点一一对应，每个第二节点均包括多个分区；

更新所述过渡集群中全部节点的配置信息，得到目标集群，所述目标集群中仅包括第一节点。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请实施例所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本申请实施例各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机计算机程序时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

以上对本申请实施例所提供的技术方案进行了详细介绍，本申请实施例中应用了具体个例对本申请实施例的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请实施例的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请实施例的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请实施例的限制。