CN112069265B - 配置数据的同步方法、业务数据系统、计算机系统和介质 - Google Patents

Abstract

本公开提供了一种配置数据的同步方法，应用于业务数据系统。业务数据系统包括：上游系统、配置管理系统、消息中间件和下游系统。该配置数据的同步方法方法包括：配置管理系统在上游系统发生配置项数据变化的情况下，生成针对该配置项变化的配置更新消息；配置管理系统将配置更新消息发送至消息中间件，以由消息中间件将配置更新消息存入分布式消息队列；以及，下游系统从所述分布式消息队列中获取配置更新消息，并基于配置更新消息进行配置项数据更新。本公开还提供了一种业务数据系统、计算机系统和介质。本公开提供的配置数据的同步方法和业务数据系统可以应用于金融领域以及其他相关领域的上下游系统的及时性和一致性更新场景。

Description

配置数据的同步方法、业务数据系统、计算机系统和介质

技术领域

本公开涉及计算机技术领域，更具体地，涉及一种配置数据的同步方法、业务数据系统、计算机系统和介质。

背景技术

业务数据系统在进行配置数据管理的过程中，存在子系统众多，上下游系统对配置数据同步时效性、一致性要求高等特点。在现有系统日益复杂、下游系统日益增多的情况下，针对配置数据的以下需求更为显著：1、数据的高时效性，即上游系统的数据需要及时至下游系统；2、数据的一致性，由于每个下游系统需要的数据不同，要保障各个下游系统获取到自身所需数据，并保持各子系统数据的一致和准确。

目前配置数据一般由如下方式产生并传递：配置管理系统调用上游系统的接口获取基础信息并录入到配置管理系统中，环境搭建系统在基础信息基础上将配置数据维护至配置管理系统，配置管理系统将配置数据每天以批量接口方式下发给各下游系统，下游系统导入配置数据并使用。该方式无法满足数据的高时效性同步，并且在配置管理系统的批量接口出现异常的情况下，数据一致性也会受到影响。

发明内容

本公开的一个方面提供了一种配置数据的同步方法，应用于业务数据系统。业务数据系统包括：上游系统、配置管理系统、消息中间件和下游系统。该配置数据的同步方法方法包括：配置管理系统在上游系统发生配置项数据变化的情况下，生成针对该配置项变化的配置更新消息；配置管理系统将配置更新消息发送至消息中间件，以由消息中间件将配置更新消息存入分布式消息队列；以及，下游系统从所述分布式消息队列中获取配置更新消息，并基于配置更新消息进行配置项数据更新。

可选地，上述方法还包括：上游系统在发生配置项数据变化的情况下，生成变更信息，并将该变更信息发送至配置管理系统；以及，配置管理系统基于该变更信息进行配置项数据变更操作。上述生成针对配置项变化的配置更新消息包括：基于配置项数据变更操作，生成配置更新消息。其中，配置更新消息包括：配置项标识信息、变更操作类型、变更前配置项数据和变更后配置项数据。

可选地，上述将所述变更信息发送至所述配置管理系统包括：上游系统将变更信息通过消息中间件发送至分布式消息队列，以由配置管理系统从分布式消息队列获取变更信息。

可选地，上述配置管理系统将所述配置更新消息发送至消息中间件，以由消息中间件将配置更新消息存入分布式消息队列包括：配置管理系统将配置更新消息和针对配置更新消息的主题发送至消息中间件；以及，消息中间件基于该主题将配置更新消息存入分布式消息队列。

可选地，上述下游系统从所述分布式消息队列中获取所述配置更新消息包括：下游系统通过订阅所述主题的方式从分布式消息队列中获取配置更新消息。

可选地，下游系统存储有预置配置项标识信息。上述下游系统通过订阅所述主题的方式从分布式消息队列中获取配置更新消息包括：下游系统通过订阅所述主题的方式从分布式消息队列中筛选与预置配置项标识信息相匹配的配置更新消息。

可选地，消息中间件为卡夫卡集群。

本公开的另一方面提供了一种业务数据系统，包括：上游系统、配置管理系统、消息中间件和下游系统。上游系统，用于在发生配置项数据变化的情况下发送变更信息；配置管理系统，用于基于所述变更信息生成针对所述配置项变化的配置更新消息，并发送所述配置更新消息；消息中间件，用于将所述配置更新消息存入分布式消息队列；以及下游系统，用于从所述分布式消息队列中获取所述配置更新消息，并基于所述配置更新消息进行配置项数据更新。

本公开的另一方面提供了一种计算机系统，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

根据本公开实施例的技术方案，在业务数据系统中增加消息中间件，由配置管理系统针对上游系统所发生的配置项数据变化生成配置更新消息，并将该配置更新消息通过消息中间件存入分布式消息队列，并由下游系统从分布式消息队列中获取配置更新消息以进行消息更新。实现了一种基于分布式流处理平台及时更新配置数据感知通知的方案，该方案有效解决了目前配置更新的急速增长导致的配置管理信息不能及时更新到下游应用的问题。该方案既提高了配置信息更新效率，电减少了下游系统大量访问配置管理系统接口的频率，减小了配置管理系统的性能压力。为各运维工具间保持配置信息更新的及时性和准确性提供了保障，满足下游应用对数据使用和维护的要求。

附图说明

为了更完整地理解本公开及其优势，现在将参考结合附图的以下描述，其中：

图1示意性示出了一种方式下应用配置数据的同步方法的业务数据系统的示例性系统架构；

图2示意性示出了根据本公开实施例的业务数据系统的架构图；

图3示意性示出了根据本公开实施例的配置数据的同步方法的流程图；

图4A示意性示出了根据本公开实施例的消息中间件的示例工作原理图；

图4B示意性示出了根据本公开实施例的配置更新消息的示例图；

图5示意性示出了根据本公开实施例的配置数据同步过程的示例流程图；

图6示意性示出了根据本公开另一实施例的配置数据同步过程的示例流程图；

图7示意性示出了根据本公开实施例的配置管理系统的框图；

图8示意性示出了根据本公开实施例的下游系统的框图；以及

图9示意性示出了根据本公开实施例的计算机系统的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

本公开的实施例提供了一种配置数据的同步方法以及实施该方法的业务数据系统。可应用于金融领域或者其它领域的上下游系统配置数据同步更新的场景。业务数据系统可以包括：上游系统、配置管理系统、消息中间件和下游系统。在实施该配置数据的同步方法的过程中，配置管理系统在上游系统发生配置项数据变化的情况下，生成针对该配置项变化的配置更新消息，并将配置更新消息发送至消息中间件，以由消息中间件将配置更新消息存入分布式消息队列。下游系统从分布式消息队列中获取配置更新消息，并基于配置更新消息进行配置项数据更新。

业务数据系统，例如银行系统，在配置管理数据的过程中，存在子系统众多，上下游系统对配置数据同步时效性、一致性要求高等特点。在现有系统日益复杂、下游系统日益增多的情况下，银行配置数据的如下需求更为显著：1、数据的高时效性，即上游系统的数据需要及时更新至下游系统；2、数据的一致性，由于每个下游所需要的数据不同，要保障各个下游系统获取到自身所需数据，并保持各子系统数据的一致和准确。

目前配置数据一般由如下方式产生并传递：配置管理系统调用上游系统的接口，每日获取基础信息每日并录入到配置管理系统中。环境搭建系统在基础信息的基础上将配置数据维护至配置管理系统，配置管理系统将配置数据每天以批量接口方式下发给各下游系统，下游系统导入当天的配置数据并使用。请参阅图1。

图1示意性示出了一种方式下可以应用配置数据的同步方法的业务数据系统的示例性系统架构100。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，一种方式下的业务数据系统可以包括多个上游系统110、配置管理系统120和多个下游系统130。示例性地，上游系统的配置数据每天发送至配置管理系统120，配置管理系统120在一定时段(例如1天)后录入该配置数据，再经过一定时段(例如1天)配置管理系统120通过批量接口将数据导出发送给下游系统130，以使下游系统130获取到数据。该过程会导致上下游配置信息同步具有长达2天的延迟，并且一旦配置管理系统120批量接口异常，数据一致性也会受到影响。

综上所述，需要有一种配置数据的同步方式，解决以上配置管理数据上下游应用更新及时性和一致性问题，满足下游应用对配置信息更新及时性和一致性的要求。

根据本公开的实施例，提供了一种优化的业务数据系统和该业务数据系统的配置数据的同步方法，用以实现业务数据系统中上游系统和下游系统之间的数据同步。下面结合附图对根据本公开实施例的业务数据系统及配置数据的同步方法进行示例性说明。

图2示意性示出了根据本公开实施例的业务数据系统的架构图。

如图2所示，该业务数据系统可以包括多个上游系统210、配置管理系统220、多个下游系统230和消息中间件240。相比于图1所示的业务数据系统，引入了消息中间件240，该消息中间件240为一个分布式流处理平台，可以将接收到的消息存入分布式消息队列，以进行消息流的处理。多个上游系统210可以与配置管理系统220进行交互，配置管理系统220可以与消息中间件240进行交互，消息中间件240可以与多个下游系统230进行交互。上游系统、配置管理系统、下游系统和消息中间件中的任一项均可通过计算机系统实现。示例性地，任一上游系统可以是单一计算机设备或计算机集群，任一下游系统可以是单一计算机设备或计算机集群。在一具体实施例中，上游系统即为消息生产者，下游系统即为消息消费者。配置管理系统可以是单一计算机设备或计算机集群，消息中间件可以是单一计算机设备或计算机集群。

下面参考图3示例性地说明各部分之间的交互过程。应注意，以下方法中各个操作的序号仅作为该操作的表示以便描述，而不应被看作表示该各个操作的执行顺序。除非明确指出，否则该方法不需要完全按照所示顺序来执行。

图3示意性示出了根据本公开实施例的配置数据的同步方法的流程图，该方法例如可以由如图2所示的业务数据系统200执行。

如图3所示，该配置数据的同步方法可以包括操作S301～S303。

在操作S301，配置管理系统在上游系统发生配置项数据变化的情况下，生成针对该配置项变化的配置更新消息。

示例性地，上游系统发生配置项数据变化可以包括：上游系统中的一个或多个配置项的内容数据发生变化、一个或多个配置项被删除、新增一个或多个配置项等。配置更新消息能够指示发生变化的配置项，并且能够反映该配置项的具体变化信息。

在操作S302，配置管理系统将配置更新消息发送至消息中间件，以由消息中间件将配置更新消息存入分布式消息队列。

示例性地，消息中间件可以是由多个服务器组成的集群，多个服务器可以划分出具有一定顺序关系的存储区域序列，这些存储区域序列用于形成上述分布式消息队列。例如，每个服务器划分成多个存储区域，不同服务器的存储区域按照一定顺序排序以使得配置更新消息可以以消息队列的形式依序存储于分布式环境中。

在操作S303，下游系统从所述分布式消息队列中获取配置更新消息，并基于配置更新消息进行配置项数据更新。

本领域技术人员可以理解，本公开实施例在业务数据系统中增加消息中间件，由配置管理系统针对上游系统所发生的配置项数据变化生成配置更新消息，并将该配置更新消息通过消息中间件存入分布式消息队列，并由下游系统从分布式消息队列中获取配置更新消息以进行消息更新。实现了一种基于分布式流处理平台及时更新配置数据感知通知的方案，该方案有效解决了目前配置更新的急速增长导致的配置管理信息不能及时更新到下游应用的问题。该方案既提高了配置信息更新效率，也减少了下游系统大量访问配置管理系统接口的频率，减小了配置管理系统的性能压力。为各运维工具间保持配置信息更新的及时性和准确性提供了保障，满足下游应用对数据使用和维护的要求。可以应用于金融领域及其他领域的上下游数据同步场景。

根据本公开的实施例，上游系统在发生配置项数据变化的情况下，可以生成变更信息，并将该变更信息发送至配置管理系统，配置管理系统基于该变更信息对配置数据库进行配置项数据变更操作。也就是说，上述生成针对配置项变化的配置更新消息的过程可以包括：基于配置项数据变更操作，生成配置更新消息。其中，配置更新消息例如可以包括：配置项标识信息、变更操作类型、变更前配置项数据和变更后配置项数据，配置项标识信息用于全局唯一地指示发生变更的配置项，变更操作类型用于指示针对该配置项所发生的具体变更操作，例如包括新增、修改、删除等，变更前配置项数据和变更后配置项数据可以表征变更前后同一配置项数据的变化。在其他实施例中，配置更新消息也可以仅包括配置项标识信息和变更后的配置项数据，或者仅包括配置项标识信息和具体变更操作信息等，原则上只要保证后续系统通过配置更新消息能够获知具体哪个配置项发生何种变更即可。

可以理解，本公开实施例提供了针对配置数据库的操作进行记录的机制，记录数据和数据库操作，用于将发生变动的配置项数据的相关信息发送到分布式消息队列中。

示例性地，在上游系统将变更信息传递至配置管理系统的过程中，也可以借助消息中间件的数据处理功能，以使得配置管理系统能够及时地获知上游系统发生配置项数据变更。例如，上述将变更信息发送至所述配置管理系统的过程可以包括：上游系统将变更信息通过消息中间件发送至分布式消息队列，以由配置管理系统从分布式消息队列获取变更信息。

根据本公开的实施例，业务数据系统中所使用的消息中间件例如为卡夫卡(Kafka)集群。Kafka集群可以用于发布和订阅数据流，可以以容错的方式存储数据流，并具有实时处理数据流的功能。基于Kafka集群的以上特征，能够进一步满足业务数据系统中上下游配置数据的时效性和一致性要求。

图4A示意性示出了根据本公开实施例的消息中间件的示例工作原理图。

如图4A所示，消息中间件440为Kafka集群，是一个分布式集群，其中的每一台服务器可称为一个消息处理中心(Broker)，负责消息的存储、确认、重试等。消息生产者(Producer)420用于产生数据并发送数据至Broker。根据本公开的实施例，配置管理系统承担了消息生产者的角色，当配置信息中的任意一个配置项数据发生变化时，可以基于配置项标识信息、数据字段变化情况生成配置更新消息，并将配置更新消息发送至消息处理中心。消息消费者(Consumer)430用于拉取或接收Broker的消息，并进行相应处理。根据本公开的实施例，下游系统承担了消息消费者的角色，从分布式消息队列中获取配置更新消息，并基于该配置更新消息进行相应配置项数据的更新。每条发布到消息处理中心的配置更新消息都有一个类别，该类别可被称为消息主题(Topic)。

例如，配置管理系统基于更新信息对系统节点进行了变更操作，就会生成一条Topic为“sysnode”的配置更新消息。图4B示意性示出了根据本公开实施例的配置更新消息的示例图。如图4B所示，例如该配置更新消息可以表征如下信息：主题“sysnode”、配置项(configuration item，CI)的标识信息、操作系统ID、集群名称、运行环境信息、是否加入活动目录(Active Directory，AD)域、是否为网络文件系统(Network File System，NFS)节点、是否为多网卡聚合、是否为指定服务器例如oracle服务器(oracle server)、高可用参数等。

消息中间件440将所有配置更新消息组织成多个主题的形式存储，每个主题又可以拆分成多个分区(partition)，每个分区又由一个个消息组成。每个消息都被标记了一个递增序列号以代表其进来的先后顺序，并按顺序存储在分区中。配置管理系统可以选择一个主题，生产配置更新消息，消息通过分配策略附加到该主题的某个分区的末尾。下游系统可以选择一个主题，通过消息的序列号来指定从哪个位置开始消费消息，消费完成之后保留该序列号，下次可以从这个位置继续消费，也可以从其他任意位置开始消费。该序列号可以被称为偏移量。

根据本公开的实施例，上述配置管理系统将配置更新消息发送至消息中间件，以由消息中间件将配置更新消息存入分布式消息队列的过程可以包括：配置管理系统将配置更新消息和针对配置更新消息的主题发送至消息中间件；以及，消息中间件基于该主题将配置更新消息存入分布式消息队列。在此基础上，下游系统通过订阅所述主题的方式从分布式消息队列中获取配置更新消息。

示例性地，下游系统存储有预置配置项标识信息。上述下游系统通过订阅所述主题的方式从分布式消息队列中获取配置更新消息的过程可以包括：下游系统通过订阅主题的方式从分布式消息队列中筛选与预置配置项标识信息相匹配的配置更新消息。

可以理解，根据本公开的实施例，在业务数据系统开始运行后，先将上游系统的基础数据同步到配置管理系统。接着，上游系统在发生配置项数据变动时可以按照配置管理系统提供的数据格式生产变更信息并发送至配置管理系统。例如变更信息可以是Kafka消息并放入Kafka分布式消息队列。在其他实施例中变更信息也可以通过其他方式发送至配置管理系统。配置管理系统基于该变更信息记录配置项数据的修改时间及修改后数据，再通过消息中间件将相应的配置更新消息放入分布式消息队列，各下游系统通过订阅消息及时获取配置项数据的变动，从而进行数据同步更新。这样既可不依赖于配置管理系统每天的数据批量任务，还可以确保下游应用及时获取配置管理系统数据的更新，保障数据的及时性和一致性。

下面结合具体实施例对根据本公开实施例的配置数据同步过程进行示例性说明，以配置管理系统中的系统节点发生配置项数据变化为例。

图5示意性示出了根据本公开实施例的配置数据同步过程的示例流程图。

如图5所示，展示了一个实施例下验证数据库修改后，将数据变化情况通过消息发送到消息处理中心的详细过程。

在操作S501：上游系统修改配置项数据，通知配置管理系统。例如，提变更信息到Kafka消息队列，配置管理系统消费此信息。

在操作S502：配置管理系统进行相应的配置项数据修改。

在操作S503：记录此次配置项数据变化的配置更新信息，例如包括配置项英文简称、操作类型(例如包括新增、修改、删除等)、配置项数据以及修改后的配置项数据。

在操作S504：交易基类创建Kafka消息生产者(Producer)。

在操作S505：发送配置更新消息，例如通过参数“send(Topic，message)”将消息发送到消息处理中心，其中消息主题Topic以配置项英文简称命名，该消息为以“sysnode”为消息主题，内容为“insert\update\delete”操作动作的数据。

可以理解，本公开实施例提供的一种通过消息队列解决配置数据下游应用使用及时性和一致性的方法，提供Kafka Topic，上游系统发生配置数据变动时按照配置管理提供的数据格式生产变更信息，配置管理通过消费该变更信息将配置变动入库，同时触发生产者发送新增\修改\删除信息(即配置更新消息)到消息队列，各下游应用消费者消费队列消息，筛选所需配置项标签的消息，将消息体内的数据同步到各自的系统中。

图6示意性示出了根据本公开另一实施例的配置数据同步过程的示例流程图。

如图6所示，展示了一个实施例下下游应用的消费程序，通过消费消息中心的消息，将配置数据库的配置更新消息，有筛选地同步到子应用中，完成从配置管理系统同步的过程。

在操作S601：各下游应用消费程序创建消息消费者(Consumer)。

在操作S602：通过参数“Subscribe(Topic)”订阅主题，可以被订阅的主题和配置管理系统发送的消息主题一一对应，本例中消息主题为“sysnode”。

在操作S603：下游应用将需要同步到当前应用的配置更新消息拉取解析入库。

在操作S604：通过参数“commit()”提交偏移量，表示已经消费完这条消息。

在操作S605：基于该配置更新消息进行配置项数据更新。接着，读取下一条消息，重复上述数据同步步骤。

可以理解，根据本公开实施例的技术方案实现了一种基于分布式流处理平台及时更新配置数据感知通知的方案，该方案有效解决了目前配置更新的急速增长导致的配置管理信息不能及时更新到下游应用的问题。配置管理系统作为数据生产者将配置更新信息写入Kafka，下游应用如集中监控等系统作为数据消费者从Kafka中获取配置信息。这个方法既提高了配置信息更新效率，也减少了下游系统大量访问配置管理系统接口频率，减小了配置管理系统的性能压力。为各运维工具间保持配置信息更新的及时性和准确性提供了保障。可以解决以下技术问题：1、数据上下游每天同步一次导致的延迟问题；2、下游应用依赖于配置管理批量任务的一致性问题。

图7示意性示出了根据本公开实施例的配置管理系统的框图，可以应用于如图2所示的业务数据系统中，或者其他需要进行上下游数据同步的计算机系统中。

如图7所示，该配置管理系统700可以包括：接收模块710、消息生成模块720和消息发送模块730。

接收模块710用于在上游系统发生配置项数据变化的情况下接收来自上游系统的变更信息。

消息生成模块720用于基于所述变更信息生成针对所述配置项变化的配置更新消息。

消息发送模块730用于将配置更新消息发送至消息中间件，以由消息中间件将所述配置更新消息存入分布式消息队列，使得下游系统可以从分布式消息队列中获取配置更新消息，并基于该配置更新消息进行配置项数据更新。

图8示意性示出了根据本公开实施例的下游系统的框图。

如图8所示，该下游系统800可以包括消息消费模块810和配置更新模块820。

消息消费模块810用于从分布式消息队列中获取配置更新消息。

配置更新模块820用于基于该配置更新消息进行配置项数据更新。

需要说明的是，装置部分实施例中各模块/单元/子单元等的实施方式、解决的技术问题、实现的功能、以及达到的技术效果分别与方法部分实施例中各对应的步骤的实施方式、解决的技术问题、实现的功能、以及达到的技术效果相同或类似，在此不再赘述。

根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图9示意性示出了根据本公开实施例的适于实现上文描述的方法的计算机系统的框图。图9示出的计算机系统仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。该计算机系统可以用于实现上文所述的配置管理系统、上游系统、下游系统和消息中间件中的任意一个或多个。

如图9所示，根据本公开实施例的计算机系统900包括处理器901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。处理器901例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器901还可以包括用于缓存用途的板载存储器。处理器901可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 903中，存储有系统900操作所需的各种程序和数据。处理器901、ROM 902以及RAM 903通过总线904彼此相连。处理器901通过执行ROM 902和/或RAM 903中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 902和RAM 903以外的一个或多个存储器中。处理器901也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，系统900还可以包括输入/输出(I/O)接口905，输入/输出(I/O)接口905也连接至总线904。系统900还可以包括连接至I/O接口905的以下部件中的一项或多项：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被处理器901执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，尽管已经参照本公开的特定示例性实施例示出并描述了本公开，但是本领域技术人员应该理解，在不背离所附权利要求及其等同物限定的本公开的精神和范围的情况下，可以对本公开进行形式和细节上的多种改变。因此，本公开的范围不应该限于上述实施例，而是应该不仅由所附权利要求来进行确定，还由所附权利要求的等同物来进行限定。

Claims (9)

1.一种配置数据的同步方法，应用于业务数据系统，所述业务数据系统包括：上游系统、配置管理系统、消息中间件和下游系统，所述方法包括：

所述配置管理系统在上游系统发生配置项数据变化的情况下，生成针对所述配置项变化的配置更新消息；

所述配置管理系统将所述配置更新消息发送至消息中间件，以由所述消息中间件将所述配置更新消息存入分布式消息队列；以及

所述下游系统从所述分布式消息队列中获取所述配置更新消息，并基于所述配置更新消息进行配置项数据更新；

所述上游系统在发生配置项数据变化的情况下，生成变更信息，并将所述变更信息发送至所述配置管理系统；以及

所述配置管理系统基于所述变更信息进行配置项数据变更操作；

所述生成针对所述配置项变化的配置更新消息包括：基于所述配置项数据变更操作，生成所述配置更新消息，其中，所述配置更新消息包括：配置项标识信息、变更操作类型、变更前配置项数据和变更后配置项数据。

2.根据权利要求1所述的方法，其中，所述将所述变更信息发送至所述配置管理系统包括：

所述上游系统将所述变更信息通过所述消息中间件发送至分布式消息队列，以由所述配置管理系统从所述分布式消息队列获取所述变更信息。

3.根据权利要求1所述的方法，其中，所述配置管理系统将所述配置更新消息发送至消息中间件，以由所述消息中间件将所述配置更新消息存入分布式消息队列包括：

所述配置管理系统将所述配置更新消息和针对所述配置更新消息的主题发送至消息中间件；以及

所述消息中间件基于所述主题将所述配置更新消息存入分布式消息队列。

4.根据权利要求3所述的方法，其中，所述下游系统从所述分布式消息队列中获取所述配置更新消息包括：

所述下游系统通过订阅所述主题的方式从所述分布式消息队列中获取所述配置更新消息。

5.根据权利要求4所述的方法，其中，所述下游系统存储有预置配置项标识信息；

所述下游系统通过订阅所述主题的方式从所述分布式消息队列中获取所述配置更新消息包括：所述下游系统通过订阅所述主题的方式从所述分布式消息队列中筛选与所述预置配置项标识信息相匹配的配置更新消息。

6.根据权利要求1所述的方法，其中，所述消息中间件为卡夫卡集群。

7.一种业务数据系统，包括：

上游系统，用于在发生配置项数据变化的情况下发送变更信息；

配置管理系统，用于基于所述变更信息生成针对所述配置项变化的配置更新消息，并发送所述配置更新消息；

消息中间件，用于将所述配置更新消息存入分布式消息队列；以及

下游系统，用于从所述分布式消息队列中获取所述配置更新消息，并基于所述配置更新消息进行配置项数据更新；

所述上游系统在发生配置项数据变化的情况下，生成变更信息，并将所述变更信息发送至所述配置管理系统；以及

所述配置管理系统基于所述变更信息进行配置项数据变更操作；

所述生成针对所述配置项变化的配置更新消息包括：基于所述配置项数据变更操作，生成所述配置更新消息，其中，所述配置更新消息包括：配置项标识信息、变更操作类型、变更前配置项数据和变更后配置项数据。

8.一种计算机系统，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时用于实现如权利要求1～6任一项所述的方法。

9.一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如权利要求1～6任一项所述的方法。