CN117539687A - 基于Nacos的异地容灾方法、装置、设备及介质 - Google Patents

基于Nacos的异地容灾方法、装置、设备及介质 Download PDF

Info

Publication number
CN117539687A
CN117539687A CN202311515413.9A CN202311515413A CN117539687A CN 117539687 A CN117539687 A CN 117539687A CN 202311515413 A CN202311515413 A CN 202311515413A CN 117539687 A CN117539687 A CN 117539687A
Authority
CN
China
Prior art keywords
cluster
kafka cluster
kafka
state
database
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311515413.9A
Other languages
English (en)
Inventor
聂万祥
赵傅艳
颜培鑫
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China United Network Communications Group Co Ltd
Original Assignee
China United Network Communications Group Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China United Network Communications Group Co Ltd filed Critical China United Network Communications Group Co Ltd
Priority to CN202311515413.9A priority Critical patent/CN117539687A/zh
Publication of CN117539687A publication Critical patent/CN117539687A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Hardware Redundancy (AREA)

Abstract

本申请提供一种基于Nacos的异地容灾方法、装置、设备及介质。该方法包括：当第一数据中心的第一Kafka集群的状态信息为异常状态时，第一Nacos Server集群将第一Kafka集群的异常状态存储至第一数据库，第一Kafka集群为正在进行业务处理的集群；第二数据中心从第二数据库中获取第一数据库中的第一Kafka集群的异常状态，其中，第二数据库和第一数据库具有数据同步关系；第二数据中心的第二Nacos Server集群根据第一Kafka集群异常状态，获取第二Kafka集群的状态信息；若第二Kafka集群的状态信息为可用状态，则使用第二Kafka集群进行业务处理。本申请的方法，提高了异地容灾的时效性和准确性。

Description

基于Nacos的异地容灾方法、装置、设备及介质
技术领域
本申请涉及计算机技术领域，尤其涉及一种基于Nacos的异地容灾方法、装置、设备及介质。
背景技术
随着容器化、云计算等技术的高速发展，要求系统的具备高可用性，系统故障、网络故障或数据丢失将直接影响数据的及时性和准确性，造成不可估量的损失。
现有技术中，通常使用异地容灾的方式保证业务的连续性，在进行异地容灾时，均是在故障发生时通过手工修改异地数据中心连接配置，重新启动应用的方式实现。
然而，当容器数量巨大时，手工修改数据中心连接指向会导致应用重新启动，加载最新连接参数，造成业务系统在很长一段时间内无法使用，影响业务系统的恢复时限，因此，无法快速、准确地进行容灾切换，影响了用户感知，无法满足企业的业务需求。
发明内容
本申请提供一种基于Nacos的异地容灾方法、装置、设备及介质，用以解决无法快速、准确地进行容灾切换，影响了用户感知，无法满足企业的业务需求的问题。
第一方面，本申请提供一种基于Nacos的异地容灾方法，包括：
当第一数据中心的第一Kafka集群的状态信息为异常状态时，第一Nacos Server集群将第一Kafka集群的异常状态存储至第一数据库，第一Kafka集群为正在进行业务处理的集群；
第二数据中心从第二数据库中获取第一数据库中的第一Kafka集群的异常状态，其中，第二数据库和第一数据库具有数据同步关系；
第二数据中心的第二Nacos Server集群根据第一Kafka集群异常状态，获取第二Kafka集群的状态信息；
若第二Kafka集群的状态信息为可用状态，则使用第二Kafka集群进行业务处理。
在本申请实施例中，当第一数据中心的第一Kafka集群的状态信息为异常状态时，第一Nacos Server集群将第一Kafka集群的异常状态存储至第一数据库，第一Kafka集群为正在进行业务处理的集群，包括：
第一数据中心的第一组件侦测模块对第一Kafka集群进行健康检测，得到第一健康检测结果；
当第一健康检测结果表征检测到第一Kafka集群的异常状态时，第一组件侦测模块将第一健康检测结果发送至第一Nacos Server集群；
第一Nacos Server集群根据第一健康检测结果将第一Kafka集群标识为异常状态；
第一Nacos Server集群将第一Kafka集群的异常状态发送至第一数据库进行存储。
在本申请实施例中，第一数据中心的第一组件侦测模块对第一Kafka集群进行健康检测，得到第一健康检测结果，包括：
第一组件侦测模块向第一Kafka集群发送访问请求；
第一组件侦测模块获取第一Kafka集群根据访问请求生成的反馈信息；
第一组件侦测模块根据反馈信息，对第一Kafka集群进行健康检测，得到第一健康检测结果。
在本申请实施例中，第一数据中心的第一组件侦测模块对第一Kafka集群进行健康检测，得到第一健康检测结果，包括：
第一组件侦测模块获取第一Kafka集群的日志信息，日志信息至少包括组件日志和应用日志中至少一种日志；
第一组件侦测模块根据第一Kafka集群的日志信息，对第一Kafka集群进行健康检测，得到第一健康检测结果。
在本申请实施例中，在第二数据中心从第二数据库中获取第一数据库中的第一Kafka集群的异常状态之前，方法还包括：
第一数据中心的第一数据库和第二数据中心的第二数据库通过binlog方式进行参数信息和组件状态信息同步。
在本申请实施例中，第二数据中心的第二Nacos Server集群根据第一Kafka集群异常状态，获取第二Kafka集群的状态信息，包括：
第二数据中心的第二组件侦测模块对第二Kafka集群进行健康检测，得到第二健康检测结果；
根据第二健康检测结果，第二组件侦测模块获取第二Kafka集群的状态信息。
在本申请实施例中，若第二Kafka集群的状态信息为可用状态，则使用第二Kafka集群进行业务处理，包括：
若第二Kafka集群的状态信息为可用状态，则将第二Kafka集群作为当前进行业务处理的集群；
第二Nacos Server集群将变更信息发送至消息采集模块；
消息采集模块根据变更信息，将消息传输路线从第一Kafka集群修改为第二Kafka集群。
在本申请实施例中，方法还包括：
当第一Kafka集群由异常状态变为可用状态时，将第二Kafka集群由可用状态调整为备用状态，并使用第一Kafka集群进行业务处理。
在本申请实施例中，方法还包括：
当第二Kafka集群由可用状态变为异常状态、且第一Kafka集群为备用状态时，第二Nacos Server集群将第二Kafka集群的异常状态存储至第二数据库，第二Kafka集群为正在进行业务处理的集群；
第一数据中心从第一数据库中获取第二数据库中的第二Kafka集群的异常状态；
第一数据中心的第一Nacos Server集群根据第二Kafka集群异常状态，获取第一Kafka集群的状态信息；
若第一Kafka集群的状态信息为可用状态，则使用第一Kafka集群进行业务处理。
在本申请实施例中，方法还包括：
当第一Kafka集群需要进行维护时，将第一Kafka集群的状态信息由可用状态调整为下线状态，将第二Kafka集群由备用状态调整为使用状态，并使用第二Kafka集群进行业务处理。
第二方面，本申请提供一种基于Nacos的异地容灾装置，包括：
存储模块，用于当第一数据中心的第一Kafka集群的状态信息为异常状态时，第一Nacos Server集群将第一Kafka集群的异常状态存储至第一数据库，第一Kafka集群为正在进行业务处理的集群；
第一获取模块，用于第二数据中心从第二数据库中获取第一数据库中的第一Kafka集群的异常状态，其中，第二数据库和第一数据库具有数据同步关系；
第二获取模块，用于第二数据中心的第二Nacos Server集群根据第一Kafka集群异常状态，获取第二Kafka集群的状态信息；
业务处理模块，用于若第二Kafka集群的状态信息为可用状态，则使用第二Kafka集群进行业务处理。
第三方面，本申请提供一种电子设备，包括：处理器，以及与处理器通信连接的存储器；
存储器存储计算机执行指令；
处理器执行存储器存储的计算机执行指令，以实现本申请实施例的基于Nacos的异地容灾方法。
第四方面，本申请提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现本申请实施例的基于Nacos的异地容灾方法。
本申请提供的基于Nacos的异地容灾方法、装置、设备及介质，通过当第一数据中心的第一Kafka集群的状态信息为异常状态时，第一Nacos Server集群将第一Kafka集群的异常状态存储至第一数据库，第一Kafka集群为正在进行业务处理的集群；第二数据中心从第二数据库中获取第一数据库中的第一Kafka集群的异常状态，其中，第二数据库和第一数据库具有数据同步关系；第二数据中心的第二Nacos Server集群根据第一Kafka集群异常状态，获取第二Kafka集群的状态信息；若第二Kafka集群的状态信息为可用状态，则使用第二Kafka集群进行业务处理的手段，通过将两个数据中心的数据库组成双主同步模式，同时Nacos Server集群可以将相关信息持久化存储至对应的数据中心的数据库，由此可以实现两个数据中心之间的信息同步，并且实时记录Kafka集群的状态信息，可以及时发现其异常状态，再根据第二数据中心的Kafka集群的状态信息启动组件，根据组件变更信息更新连接信息迅速切换使用备用路线进行业务处理，从而达到组件异常后快速且自动恢复业务的效果。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。
图1为本申请实施例提供的基于Nacos的异地容灾方法的流程示意图；
图2为本申请实施例提供的另一种基于Nacos的异地容灾方法的流程示意图；
图3为本申请实施例提供的基于Nacos的异地容灾装置的结构示意图；
图4为本申请实施例提供的电子设备的结构示意图。
通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
现有技术中，在使用异地容灾的方式保证业务的连续性时，通常是在故障发生时通过手工修改异地数据中心连接配置，重新启动应用的方式实现，在准确性上难以保证；而且，当容器数量巨大时，手工修改数据中心连接指向会导致应用重新启动，加载最新连接参数，造成业务系统在很长一段时间内无法使用，影响业务系统的恢复时限，因此，无法快速、准确地进行容灾切换，影响了用户感知，无法满足企业的业务需求。
为了解决上述问题，本申请提供的基于Nacos的异地容灾方法，可以在第一数据中心的第一Kafka集群为异常状态时，第一Nacos Server集群及时记录其异常状态，并存储至第一数据库，由于两个数据中心的数据库组成双主同步模式，由此可以实现两个数据中心之间的信息同步，则第二数据库可以获取到第一Kafka集群异常的信息，于是第二NacosServer集群根据第一Kafka集群异常状态信息，获取第二Kafka集群的状态信息，如果集群状态为可用状态，则修改应用使用组件的连接信息，指向第二数据中心的第二Kafka集群，由此使用第二Kafka集群继续进行业务处理，因此，可以快速且准确地实现异地容灾切换，不会影响业务处理的效率。
下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。
本申请实施例提供的基于Nacos的异地容灾方法的执行主体可以是服务器。其中，服务器可以为电脑、平板、手机，或者其他设备。本实施例对执行主体的实现方式不做特别限制，只要该执行主体能够当第一数据中心的第一Kafka集群的状态信息为异常状态时，第一Nacos Server集群将第一Kafka集群的异常状态存储至第一数据库，第一Kafka集群为正在进行业务处理的集群；第二数据中心从第二数据库中获取第一数据库中的第一Kafka集群的异常状态，其中，第二数据库和第一数据库具有数据同步关系；第二数据中心的第二Nacos Server集群根据第一Kafka集群异常状态，获取第二Kafka集群的状态信息；若第二Kafka集群的状态信息为可用状态，则使用第二Kafka集群进行业务处理即可。
其中，Nacos(Dynamic Naming and Configuration Service)可以指易于构建云原生应用的动态服务发现、配置管理和服务管理平台，构建以服务(Service)为中心的现代应用架构的服务基础设施。
图1为本申请实施例提供的基于Nacos的异地容灾方法的流程示意图。该方法的执行主体可以为服务器，本实施例此处不做特别限制，如图1所示，该方法可以包括：
S101、当第一数据中心的第一Kafka集群的状态信息为异常状态时，第一NacosServer集群将第一Kafka集群的异常状态存储至第一数据库，第一Kafka集群为正在进行业务处理的集群。
其中，第一数据中心可以指设置在某一区域内承担主要业务的话单管理中心，比如，第一数据中心可以设置在A地。
第一Kafka集群可以指第一数据中心内设置的分布式、支持分区的(partition)、多副本的(replica)，基于zookeeper协调的分布式消息系统，可以实时处理大量数据以满足各种需求场景，用于在线消息使用的组件，该组件为主集群，可以与应用相连，以完成对数据的处理。在本申请实施例中，在线消息可以指5G在线消息，应用可以包括消息采集应用和消息转发应用。
状态信息可以包括组件的可用状态和不可用状态，可用状态可以指组件当前已通过健康检测，可以正常进行业务处理过程，不可用状态可以指组件当前未通过健康检测，检测结果为组件异常，则为异常状态，检测结果为组件正常，但需要进行停服维护，则为下线状态，不可以进行业务处理。
异常状态可以指第一数据中心的Kafka主集群宕机，处于无法正常进行业务处理的状态。
第一Nacos Server集群可以指第一数据中心内设置的用于连接消费者(consumer)和生产者(provider)的集群，包括多个Nacos Server，该集群的持久化存储均指向本地数据中心的数据库，比如，第一Nacos Server集群的持久化存储指向第一数据中心的第一数据库，第二Nacos Server集群的持久化存储指向第二数据中心的第二数据库。
第一Nacos Server集群可以管理第一数据中心的全部组件，比如第一Kafka集群，并将组件的变更信息存储至数据库中，其中，变更信息可以包括组件的实时状态信息和参数信息，参数信息可以指各异地数据中心组件的集群基础信息、实时状态、健康信息、密码信息等信息。
第一Nacos Server集群可以与多个应用相连，当某个Nacos Server宕机后，应用可以重连其他Nacos Server节点信息，保证所有应用能够获取最新的变更信息，并且应用可以通过Nacos Server接口长轮询方式取回信息变更后的参数，以使应用做相应的变更处理，其中，长轮询方式可以指由客户端向服务端发出一个设置较长网络超时时间的HTTP请求，并在HTTP连接超时前，不主动断开连接，待客户端超时或者直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的HTTP请求，并重复以上过程的轮询方式。
第一数据库可以指能够与第一Nacos Server集群进行读或写操作的持久化数据库，在一些实施例中，Nacos默认有自带嵌入式数据库Derby，但在本申请实施例中，在两个数据中心均部署着多个Mysql从节点进行数据同步备份，因此需要使用集群模式，保证每个节点的数据一致，则需要使用外部数据库MySQL，该数据库可以记录Nacos Server集群所传递的变更信息，自动进行两个数据中心的数据同步。
其中，在本申请实施例中，当第一数据中心的第一Kafka集群的状态信息为异常状态时，第一Nacos Server集群将第一Kafka集群的异常状态存储至第一数据库，第一Kafka集群为正在进行业务处理的集群的方法可以包括：
第一数据中心的第一组件侦测模块对第一Kafka集群进行健康检测，得到第一健康检测结果；
当第一健康检测结果表征检测到第一Kafka集群的异常状态时，第一组件侦测模块将第一健康检测结果发送至第一Nacos Server集群；
第一Nacos Server集群根据第一健康检测结果将第一Kafka集群标识为异常状态；
第一Nacos Server集群将第一Kafka集群的异常状态发送至第一数据库进行存储。
其中，第一组件侦测模块可以指第一数据中心内对第一Nacos Server集群所管理的全部组件进行健康侦测的应用模块，确定组件的健康程度，分别连接第一Nacos Server集群和第一Kafka集群，并将所获取的健康检测结果上报给第一Nacos Server集群，以使第一Nacos Server集群进行组件状态更新。
健康检测可以指通过组件提供的健康检测命令、组件日志、应用日志、模拟使用等手段对组件进行检测，得到组件的健康检测结果，模拟使用可以指第一组件侦测模块向组件插入某一数据，若插入成功，则说明该组件为可用状态，可以完成业务，若插入失败，则说明该组件为异常状态。
第一健康检测结果可以指第一组件侦测模块对第一Kafka集群进行健康状态检测所得到的结果，该结果表征为第一Kafka集群的状态信息，在本申请实施例中，第一健康检测结果可以指第一Kafka集群为异常状态。
其中，在本申请实施例中，第一数据中心的第一组件侦测模块对第一Kafka集群进行健康检测，得到第一健康检测结果的方法可以包括：
第一组件侦测模块向第一Kafka集群发送访问请求；
第一组件侦测模块获取第一Kafka集群根据访问请求生成的反馈信息；
第一组件侦测模块根据反馈信息，对第一Kafka集群进行健康检测，得到第一健康检测结果。
其中，访问请求可以指第一组件侦测模块向第一Kafka集群发送的健康检测命令，比如：Are you OK？
反馈信息可以指第一Kafka集群接收第一组件侦测模块的检测命令后，根据自身情况所反馈的信息，比如，若第一Kafka集群为可用状态，则反馈信息为I’m OK！
其中，在本申请实施例中，第一数据中心的第一组件侦测模块对第一Kafka集群进行健康检测，得到第一健康检测结果的方法可以包括：
第一组件侦测模块获取第一Kafka集群的日志信息，日志信息至少包括组件日志和应用日志中至少一种日志；
第一组件侦测模块根据第一Kafka集群的日志信息，对第一Kafka集群进行健康检测，得到第一健康检测结果。
其中，日志信息可以指组件集群在进行业务处理时产生的事件记录，可以包括日期、时间、使用者及动作等相关操作的描述信息，在本申请实施例中，日志信息可以包括组件日志和应用日志中至少一种日志。
组件日志可以指记录组件集群运行过程中各种信息所生成的文件，包括运行过程中的关键事件和系统故障。
应用日志可以指记录组件集群对应用进行业务访问过程中所产生的各种信息所生成的文件，包括业务访问过程中的关键事件和系统故障。
S102、第二数据中心从第二数据库中获取第一数据库中的第一Kafka集群的异常状态，其中，第二数据库和第一数据库具有数据同步关系。
其中，第二数据中心可以指设置在与第一数据中心所在地异地区域内的承担少数业务的话单管理中心，第二数据中心可以作为备用数据中心，只承担轻量级生产任务，比如，第二数据中心可以设置在B地。
第二数据库可以指与第一数据库相似的，能够与第二Nacos Server集群进行读或写操作的持久化数据库MySQL。
数据同步关系可以指第一数据库和第二数据库这两个MySQL数据库为双主集群模式，其中，双主集群模式可以指两台服务器互为主从，任何一台服务器数据变更，都会通过复制应用到另外一方的数据库中。
其中，在本申请实施例中，在第二数据中心从第二数据库中获取第一数据库中的第一Kafka集群的异常状态之前，方法还可以包括：
第一数据中心的第一数据库和第二数据中心的第二数据库通过binlog方式进行参数信息和组件状态信息同步。
其中，binlog方式可以指两个MySQL数据库均开启binlog同步功能，使用二进制文件记录了MySQL所有数据的变更，并以二进制的形式存储在磁盘上，以进行实时数据同步备份。
S103、第二数据中心的第二Nacos Server集群根据第一Kafka集群异常状态，获取第二Kafka集群的状态信息。
其中，第二Nacos Server集群可以指与第一Nacos Server集群相似的，设置在第二数据中心内，包括多个Nacos Server的集群。
第二Kafka集群可以指与第一Kafka集群相似的，用于在线消息使用的组件，该组件为备用集群，可以与应用相连，以完成对数据的处理，一般在第一Kafka集群异常时进行使用。
其中，在本申请实施例中，第二数据中心的第二Nacos Server集群根据第一Kafka集群异常状态，获取第二Kafka集群的状态信息的方法可以包括：
第二数据中心的第二组件侦测模块对第二Kafka集群进行健康检测，得到第二健康检测结果；
根据第二健康检测结果，第二组件侦测模块获取第二Kafka集群的状态信息。
其中，第二组件侦测模块可以指与第一组件侦测模块完全相同的，对第二NacosServer集群所管理的全部组件进行健康侦测的应用组件，确定组件的健康程度，分别连接第二Nacos Server集群和第二Kafka集群，并将所获取的健康检测结果上报给第二NacosServer集群，以使第二Nacos Server集群进行组件状态更新。
第二健康检测结果可以指第二组件侦测模块对第二Kafka集群进行健康状态检测所得到的结果，该结果表征为第二Kafka集群的状态信息，在本申请实施例中，第二健康检测结果可以指第二Kafka集群为可用状态，但目前未进行业务处理。
S104、若第二Kafka集群的状态信息为可用状态，则使用第二Kafka集群进行业务处理。
其中，可用状态可以指对两个数据中心的Nacos Server集群所管理的所有组件，比如Kafka集群，进行健康检测所得到的组件可以正常使用的结果状态。
业务处理可以指利用Kafka集群实时处理大量数据，完成话单处理业务的过程。
其中，在本申请实施例中，若第二Kafka集群的状态信息为可用状态，则使用第二Kafka集群进行业务处理的方法可以包括：
若第二Kafka集群的状态信息为可用状态，则将第二Kafka集群作为当前进行业务处理的集群；
第二Nacos Server集群将变更信息发送至消息采集模块；
消息采集模块根据变更信息，将消息传输路线从第一Kafka集群修改为第二Kafka集群。
其中，变更信息可以指进行业务处理的组件进行变更，消息传输路线也进行变更，将业务的处理工作从第一数据中心过渡到第二数据中心，需要由组件侦测模块通过NacosServer接口，向数据库写入变更数据，由此将该变更信息主动通知并传达到所有应用。
消息采集模块可以指消息采集应用，是5G大区消息网元侧的采集前置，负责对话单信息进行采集，并输送至Kafka集群进行消费。
消息传输路线可以指消息采集模块将消息传输至数据中心内的Kafka集群组件中，再由消息转发应用在Kafka集群中进行消费，并将数据传送至后端计费系统的路线。
其中，在本申请实施例中，方法还可以包括：
当第一Kafka集群由异常状态变为可用状态时，将第二Kafka集群由可用状态调整为备用状态，并使用第一Kafka集群进行业务处理。
其中，备用状态可以指将业务处理工作切换至另一组件进行处理，而第二Kafka集群作为备份组件。在本申请实施例中，将第二Kafka集群由可用状态调整为备用状态，并使用第一Kafka集群进行业务处理可以指在第二Kafka集群处于正常状态时，由于第一Kafka集群健康检测结果为已通过，则可以进行业务处理，将业务处理过程恢复至故障发生前状态，第二Kafka集群不再承担全部业务处理工作。
其中，在本申请实施例中，方法还可以包括：
当第二Kafka集群由可用状态变为异常状态、且第一Kafka集群为备用状态时，第二Nacos Server集群将第二Kafka集群的异常状态存储至第二数据库，第二Kafka集群为正在进行业务处理的集群；
第一数据中心从第一数据库中获取第二数据库中的第二Kafka集群的异常状态；
第一数据中心的第一Nacos Server集群根据第二Kafka集群异常状态，获取第一Kafka集群的状态信息；
若第一Kafka集群的状态信息为可用状态，则使用第一Kafka集群进行业务处理。
其中，在本申请实施例中，方法还可以包括：
当第一Kafka集群需要进行维护时，将第一Kafka集群的状态信息由可用状态调整为下线状态，将第二Kafka集群由备用状态调整为使用状态，并使用第二Kafka集群进行业务处理。
其中，维护可以包括组件集群需要进行停服维护、组件需要进行连接密码更新、或者集群需要进行动态扩缩容，在这些情况下，组件虽然未处于异常状态，但无法进行业务处理，需要手动切换组件，其中，组件集群停服维护可以指将组件集群进行停维护，将组件集群在生产下线；组件连接密码更新可以指组件集群更新密码时需要注入密码的密文信息；集群的动态扩缩容可以指组件扩缩容节点IP变化时需要配置新集群信息。
下线状态可以指管理员通过Nacos控制台或WEB应用，调整待维护和更新集群的使用状态为下线状态，不再进行业务处理，而是切换至备用组件。在本申请实施例中，待组件集群维护完毕，具体上线条件时，再通过Nacos控制台或WEB应用将组件的状态信息更新为使用状态，应用通过长轮询方式从Nacos Server获取到最新变更信息，并及时做相应的处理。
本申请实施例提供的基于Nacos的异地容灾方法，可以通过将两个数据中心的数据库采用双主集群模式设置，并且使用binlog方式进行实时数据同步，由此可以迅速获知数据中心的组件健康状况，一旦第一数据中心内的第一Kafka集群处于异常状态，第一Nacos Server能立刻将该状态上报至第一数据库进行存储，并将该信息实时同步给第二数据库，向数据库写入变更信息，再根据第二数据中心的Kafka集群的状态信息启动组件，根据组件变更信息更新连接信息迅速切换使用备用路线进行业务处理，从而达到组件异常后快速且自动恢复业务的效果，解决了手动修改异地数据中心连接指向无法保证时效性和准确性的问题。
图2为本申请实施例提供的另一种基于Nacos的异地容灾方法的流程示意图，该方法的执行主体可以为服务器，本实施例此处不做特别限制，如图2所示，该方法可以包括：
S201、当第一数据中心的Kafka主集群宕机不可用时，由组件侦测模块变更异常状态，启动预先设置好的第二数据中心的Kafka备用集群来接管业务。
其中，组件侦测模块可以指组件健康侦测装置通过健康检测命令、组件日志、应用日志、模拟使用等获取多因子因素进行综合判断，确定组件是否通过健康检测。
S202、组件侦测模块通过Nacos Server获取备用集群状态信息。
S203、如果集群状态为可用状态，则修改应用使用组件的连接信息，指向第二数据中心的Kafka备用集群。
其中，修改修改应用使用组件的连接信息可以指采用参数分发装置，将异地数据中心连接指向采用事前预置方式，变更信息采用主动通知方式快速传达到每个应用，无需人工干涉，可以自动将准确信息传达到每个应用。
S204、5G消息采集模块获取到最新变更数据，更新组织连接信息指向Kafka备用集群，切换后使用备用路线。
其中，切换可以指采用组件切换装置进行切换，在应用收到变更信息后，动态加载连接信息，重启应用，快速切换至异地数据中心组件，实现秒级切换。在本申请实施例中，数据持久化存储在本地缓存文件和数据库中，当服务端重启后，可从数据库中恢复数据，继续进行业务处理。
本申请实施例提供的另一种基于Nacos的异地容灾方法，可以通过组件侦测模块获取集群状态，确定其异常状态或可用状态，自动修改应用使用组件的连接信息，参数分发装置将应用连接指向准确并迅速地传达到所有应用，使组件切换装置完成业务处理路线切换，可以立刻恢复业务，完成容灾切换过程，不会影响业务处理效率。
图3为本申请实施例提供的基于Nacos的异地容灾装置的结构示意图。如图3所示，该基于Nacos的异地容灾装置30包括：存储模块301、第一获取模块302、第二获取模块303、业务处理模块304。其中：
存储模块301，用于当第一数据中心的第一Kafka集群的状态信息为异常状态时，第一Nacos Server集群将第一Kafka集群的异常状态存储至第一数据库，第一Kafka集群为正在进行业务处理的集群；
第一获取模块302，用于第二数据中心从第二数据库中获取第一数据库中的第一Kafka集群的异常状态，其中，第二数据库和第一数据库具有数据同步关系；
第二获取模块303，用于第二数据中心的第二Nacos Server集群根据第一Kafka集群异常状态，获取第二Kafka集群的状态信息；
业务处理模块304，用于若第二Kafka集群的状态信息为可用状态，则使用第二Kafka集群进行业务处理。
在本申请实施例中，存储模块301还可以具体用于：
第一数据中心的第一组件侦测模块对第一Kafka集群进行健康检测，得到第一健康检测结果；
当第一健康检测结果表征检测到第一Kafka集群的异常状态时，第一组件侦测模块将第一健康检测结果发送至第一Nacos Server集群；
第一Nacos Server集群根据第一健康检测结果将第一Kafka集群标识为异常状态；
第一Nacos Server集群将第一Kafka集群的异常状态发送至第一数据库进行存储。
在本申请实施例中，存储模块301还可以具体用于：
第一组件侦测模块向第一Kafka集群发送访问请求；
第一组件侦测模块获取第一Kafka集群根据访问请求生成的反馈信息；
第一组件侦测模块根据反馈信息，对第一Kafka集群进行健康检测，得到第一健康检测结果。
在本申请实施例中，存储模块301还可以具体用于：
第一组件侦测模块获取第一Kafka集群的日志信息，日志信息至少包括组件日志和应用日志中至少一种日志；
第一组件侦测模块根据第一Kafka集群的日志信息，对第一Kafka集群进行健康检测，得到第一健康检测结果。
在本申请实施例中，存储模块301还可以具体用于：
第一数据中心的第一数据库和第二数据中心的第二数据库通过binlog方式进行参数信息和组件状态信息同步。
在本申请实施例中，第二获取模块303还可以具体用于：
第二数据中心的第二组件侦测模块对第二Kafka集群进行健康检测，得到第二健康检测结果；
根据第二健康检测结果，第二组件侦测模块获取第二Kafka集群的状态信息。
在本申请实施例中，业务处理模块304还可以具体用于：
若第二Kafka集群的状态信息为可用状态，则将第二Kafka集群作为当前进行业务处理的集群；
第二Nacos Server集群将变更信息发送至消息采集模块；
消息采集模块根据变更信息，将消息传输路线从第一Kafka集群修改为第二Kafka集群。
在本申请实施例中，业务处理模块304还可以用于：
当第一Kafka集群由异常状态变为可用状态时，将第二Kafka集群由可用状态调整为备用状态，并使用第一Kafka集群进行业务处理。
在本申请实施例中，业务处理模块304还可以具体用于：
当第二Kafka集群由可用状态变为异常状态、且第一Kafka集群为备用状态时，第二Nacos Server集群将第二Kafka集群的异常状态存储至第二数据库，第二Kafka集群为正在进行业务处理的集群；
第一数据中心从第一数据库中获取第二数据库中的第二Kafka集群的异常状态；
第一数据中心的第一Nacos Server集群根据第二Kafka集群异常状态，获取第一Kafka集群的状态信息；
若第一Kafka集群的状态信息为可用状态，则使用第一Kafka集群进行业务处理。
在本申请实施例中，业务处理模块304还可以用于：
当第一Kafka集群需要进行维护时，将第一Kafka集群的状态信息由可用状态调整为下线状态，将第二Kafka集群由备用状态调整为使用状态，并使用第二Kafka集群进行业务处理。
由上可知，本申请实施例的基于Nacos的异地容灾装置30由存储模块301，用于当第一数据中心的第一Kafka集群的状态信息为异常状态时，第一Nacos Server集群将第一Kafka集群的异常状态存储至第一数据库，第一Kafka集群为正在进行业务处理的集群；由第一获取模块302，用于第二数据中心从第二数据库中获取第一数据库中的第一Kafka集群的异常状态，其中，第二数据库和第一数据库具有数据同步关系；由第二获取模块303，用于第二数据中心的第二Nacos Server集群根据第一Kafka集群异常状态，获取第二Kafka集群的状态信息；由业务处理模块304，用于若第二Kafka集群的状态信息为可用状态，则使用第二Kafka集群进行业务处理。由此，通过将两个数据中心的数据库组成双主同步模式，同时Nacos Server集群可以将相关信息持久化存储至对应的数据中心的数据库，由此可以实现两个数据中心之间的信息同步，并且实时记录Kafka集群的状态信息，可以及时发现其异常状态，再根据第二数据中心的Kafka集群的状态信息启动组件，根据组件变更信息更新连接信息迅速切换使用备用路线进行业务处理，从而达到组件异常后快速且自动恢复业务的效果。
图4为本申请实施例提供的电子设备的结构示意图。如图4所示，该电子设备40包括：
该电子设备40可以包括一个或者一个以上处理核心的处理器401、一个或一个以上计算机可读存储介质的存储器402、通信部件403等部件。其中，处理器401、存储器402以及通信部件403通过总线404连接。
在具体实现过程中，至少一个处理器401执行存储器402存储的计算机执行指令，使得至少一个处理器401执行如上的基于Nacos的异地容灾方法。
处理器401的具体实现过程可参见上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。
在上述的图4所示的实施例中，应理解，处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application SpecificIntegrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
存储器可能包含高速存储器(Random Access Memory，RAM)，也可能还包括非易失性存储器(Non-volatile Memory，NVM)，例如至少一个磁盘存储器。
总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。
在一些实施例中，还提出一种计算机程序产品，包括计算机程序或指令，该计算机程序或指令被处理器执行时实现上述任一种基于Nacos的异地容灾方法中的步骤。
以上各个操作的具体实施可参见前面的实施例，在此不再赘述。
本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。
为此，本申请实施例提供一种计算机可读存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本申请实施例所提供的任一种基于Nacos的异地容灾方法中的步骤。
其中，该存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、磁盘或光盘等。
根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。
由于该存储介质中所存储的指令，可以执行本申请实施例所提供的任一种基于Nacos的异地容灾方法中的步骤，因此，可以实现本申请实施例所提供的任一种基于Nacos的异地容灾方法所能实现的有益效果，详见前面的实施例，在此不再赘述。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (13)

1.一种基于Nacos的异地容灾方法，其特征在于，所述方法包括：
当第一数据中心的第一Kafka集群的状态信息为异常状态时，第一Nacos Server集群将所述第一Kafka集群的异常状态存储至第一数据库，所述第一Kafka集群为正在进行业务处理的集群；
第二数据中心从第二数据库中获取所述第一数据库中的第一Kafka集群的异常状态，其中，所述第二数据库和所述第一数据库具有数据同步关系；
所述第二数据中心的第二Nacos Server集群根据所述第一Kafka集群异常状态，获取第二Kafka集群的状态信息；
若所述第二Kafka集群的状态信息为可用状态，则使用所述第二Kafka集群进行业务处理。
2.根据权利要求1所述的方法，其特征在于，所述当第一数据中心的第一Kafka集群的状态信息为异常状态时，第一Nacos Server集群将所述第一Kafka集群的异常状态存储至第一数据库，所述第一Kafka集群为正在进行业务处理的集群，包括：
所述第一数据中心的第一组件侦测模块对所述第一Kafka集群进行健康检测，得到第一健康检测结果；
当所述第一健康检测结果表征检测到所述第一Kafka集群的异常状态时，所述第一组件侦测模块将所述第一健康检测结果发送至所述第一Nacos Server集群；
所述第一Nacos Server集群根据所述第一健康检测结果将所述第一Kafka集群标识为异常状态；
所述第一Nacos Server集群将所述第一Kafka集群的异常状态发送至所述第一数据库进行存储。
3.根据权利要求2所述的方法，其特征在于，所述第一数据中心的第一组件侦测模块对所述第一Kafka集群进行健康检测，得到第一健康检测结果，包括：
所述第一组件侦测模块向所述第一Kafka集群发送访问请求；
所述第一组件侦测模块获取所述第一Kafka集群根据所述访问请求生成的反馈信息；
所述第一组件侦测模块根据所述反馈信息，对所述第一Kafka集群进行健康检测，得到第一健康检测结果。
4.根据权利要求2所述的方法，其特征在于，所述第一数据中心的第一组件侦测模块对所述第一Kafka集群进行健康检测，得到第一健康检测结果，包括：
所述第一组件侦测模块获取所述第一Kafka集群的日志信息，所述日志信息至少包括组件日志和应用日志中至少一种日志；
所述第一组件侦测模块根据所述第一Kafka集群的日志信息，对所述第一Kafka集群进行健康检测，得到第一健康检测结果。
5.根据权利要求1所述的方法，其特征在于，在所述第二数据中心从第二数据库中获取所述第一数据库中的第一Kafka集群的异常状态之前，所述方法还包括：
所述第一数据中心的第一数据库和所述第二数据中心的第二数据库通过binlog方式进行参数信息和组件状态信息同步。
6.根据权利要求1所述的方法，其特征在于，所述第二数据中心的第二Nacos Server集群根据所述第一Kafka集群异常状态，获取第二Kafka集群的状态信息，包括：
所述第二数据中心的第二组件侦测模块对所述第二Kafka集群进行健康检测，得到第二健康检测结果；
根据所述第二健康检测结果，所述第二组件侦测模块获取第二Kafka集群的状态信息。
7.根据权利要求1所述的方法，其特征在于，若所述第二Kafka集群的状态信息为可用状态，则使用所述第二Kafka集群进行业务处理，包括：
若所述第二Kafka集群的状态信息为可用状态，则将所述第二Kafka集群作为当前进行业务处理的集群；
所述第二Nacos Server集群将变更信息发送至消息采集模块；
所述消息采集模块根据所述变更信息，将消息传输路线从所述第一Kafka集群修改为所述第二Kafka集群。
8.根据权利要求1所述的方法，其特征在于，所述方法还包括：
当所述第一Kafka集群由异常状态变为可用状态时，将所述第二Kafka集群由可用状态调整为备用状态，并使用所述第一Kafka集群进行业务处理。
9.根据权利要求1所述的方法，其特征在于，所述方法还包括：
当所述第二Kafka集群由可用状态变为异常状态、且所述第一Kafka集群为备用状态时，第二Nacos Server集群将所述第二Kafka集群的异常状态存储至第二数据库，所述第二Kafka集群为正在进行业务处理的集群；
第一数据中心从第一数据库中获取所述第二数据库中的第二Kafka集群的异常状态；
所述第一数据中心的第一Nacos Server集群根据所述第二Kafka集群异常状态，获取第一Kafka集群的状态信息；
若所述第一Kafka集群的状态信息为可用状态，则使用所述第一Kafka集群进行业务处理。
10.根据权利要求1所述的方法，其特征在于，所述方法还包括：
当所述第一Kafka集群需要进行维护时，将所述第一Kafka集群的状态信息由可用状态调整为下线状态，将所述第二Kafka集群由备用状态调整为使用状态，并使用所述第二Kafka集群进行业务处理。
11.一种基于Nacos的异地容灾装置，其特征在于，包括：
存储模块，用于当第一数据中心的第一Kafka集群的状态信息为异常状态时，第一Nacos Server集群将所述第一Kafka集群的异常状态存储至第一数据库，所述第一Kafka集群为正在进行业务处理的集群；
第一获取模块，用于第二数据中心从第二数据库中获取所述第一数据库中的第一Kafka集群的异常状态，其中，所述第二数据库和所述第一数据库具有数据同步关系；
第二获取模块，用于所述第二数据中心的第二Nacos Server集群根据所述第一Kafka集群异常状态，获取第二Kafka集群的状态信息；
业务处理模块，用于若所述第二Kafka集群的状态信息为可用状态，则使用所述第二Kafka集群进行业务处理。
12.一种电子设备，其特征在于，包括：处理器，以及与所述处理器通信连接的存储器；
所述存储器存储计算机执行指令；
所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1至10中任一项所述的方法。
13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至10任一项所述的基于Nacos的异地容灾方法。
CN202311515413.9A 2023-11-14 2023-11-14 基于Nacos的异地容灾方法、装置、设备及介质 Pending CN117539687A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311515413.9A CN117539687A (zh) 2023-11-14 2023-11-14 基于Nacos的异地容灾方法、装置、设备及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311515413.9A CN117539687A (zh) 2023-11-14 2023-11-14 基于Nacos的异地容灾方法、装置、设备及介质

Publications (1)

Publication Number Publication Date
CN117539687A true CN117539687A (zh) 2024-02-09

Family

ID=89793290

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311515413.9A Pending CN117539687A (zh) 2023-11-14 2023-11-14 基于Nacos的异地容灾方法、装置、设备及介质

Country Status (1)

Country Link
CN (1) CN117539687A (zh)

Similar Documents

Publication Publication Date Title
EP3617886B1 (en) Hot backup system, hot backup method, and computer device
WO2017177941A1 (zh) 主备数据库切换方法和装置
EP3210367B1 (en) System and method for disaster recovery of cloud applications
CN111427728B (zh) 状态管理方法、主备切换方法及电子设备
US20080288812A1 (en) Cluster system and an error recovery method thereof
CN112118130A (zh) 自适应的分布式缓存主备状态信息切换方法及装置
CN110635941A (zh) 一种数据库节点集群故障迁移方法与装置
CN106533751B (zh) 一种sdn控制器集群合并方法及装置
CN114764380A (zh) 一种基于etcd的分布式集群控制方法和装置
CN113438111A (zh) 基于Raft分布式恢复RabbitMQ网络分区的方法及应用
CN109189854B (zh) 提供持续业务的方法及节点设备
CN114328033A (zh) 保持高可用设备组业务配置一致性的方法及装置
CN113986450A (zh) 一种虚拟机备份方法及装置
CN118018463A (zh) 一种故障处理方法、装置、设备及可读存储介质
CN105323271B (zh) 一种云计算系统以及云计算系统的处理方法和装置
CN116185697B (zh) 容器集群管理方法、装置、系统、电子设备及存储介质
CN107404511B (zh) 集群中服务器的替换方法及设备
CN113596195B (zh) 公共ip地址管理方法、装置、主节点及存储介质
CN117539687A (zh) 基于Nacos的异地容灾方法、装置、设备及介质
CN112491633B (zh) 一种多节点集群的故障恢复方法、系统及相关组件
JP2013161266A (ja) 呼処理情報の冗長化制御システムおよびこれに利用する予備保守サーバ
CN114422567B (zh) 数据请求的处理方法、装置、系统、计算机设备及介质
JP2014137798A (ja) データベースシステム及びデータベースシステムの制御方法
CN115499296B (zh) 一种云桌面热备管理方法、装置及系统
CN118175019A (zh) 一种元数据服务切换方法、系统、电子设备及介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination