具体实施方式

为使本发明的目的、技术方案及优点更加清楚、明确，以下参照附图并举实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

微服务架构是一项在云中部署应用和服务的新技术，大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

微服务架构(Microservice Architecture)是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦，可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。微服务架构是把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。微服务架构围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。微服务架构用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

微服务(Microservice)这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年，越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。

与微服务架构相对应的传统开发模式一般被称为Monolithic(单体式开发)，它是所有的功能打包在一个WAR包里，基本没有外部依赖(除了容器)，部署在一个JEE容器(Tomcat，JBoss，WebLogic)里，包含了DO/DAO，Service，UI等所有逻辑。传统开发模式具有开发简单，集中式管理，基本不会重复开发，且功能都在本地，没有分布式的管理和调用消耗的优点，但是传统开发模式开发由于都在同一个项目改代码，相互等待，冲突不断，从而导致传统开发模式的效率较低，且代码功功能耦合在一起，对于使用的新人来说在维护的过程中不知道从何下手。其次，因为传统开发模式构建时间长，任何小修改都要重构整个项目，耗时较长，导致使用不够灵活，以及传统开发模式的稳定性和扩展性较差。

微服务架构的优点在于复杂度可控，可以实现独立按需扩展，技术选型灵活，容错性能好以及可用性高。具体地，微服务架构解决了复杂性的问题，它会将一种怪异的整体应用程序分解成一组服务，虽然功能总量不变，但应用程序已分解为可管理的块或服务，每个服务都以RPC或消息驱动的API的形式定义了一个明确的边界，微服务架构模式实现了一个模块化水平，这种架构使每个服务都能够由专注于该服务的团队独立开发，开发人员可以自由选择任何有用的技术，只要该服务符合API合同。此外，由于服务相对较小，因此使用当前技术重写旧服务变得可行，微服务架构模式使每个微服务都能独立部署，开发人员不需要协调部署本地服务的变更，这些变化可以在测试后尽快部署，例如，UI团队可以执行A|B测试，并快速迭代UI更改，微服务架构模式使连续部署成为可能。微服务架构模式使每个服务都可以独立调整，可以仅部署满足其容量和可用性限制的每个服务的实例数，使用者可以使用最符合服务资源要求的硬件。

企业和服务提供商正在寻找更好的方法将应用程序部署在云环境中，微服务被认为是未来的方向，通过将应用和服务分解成更小的、松散耦合的组件，它们可以更加容易升级和扩展。

经研究发现，目前微服务架构越来越流行，程序粒度日趋小型化，配置文件的数量倍增，采用传统的本地文件方式管理应用，暴露的问题会越来越多，很难适应于快速发展的微服务架构。

为了解决现有技术的问题，本实施例提供一种配置数据管理方法，所述方法包括获取待更新配置数据，并将所述待更新配置数据推送到数据库中，由于本申请需要对待更新配置数据进行配置管理，因此需要先将待更新配置数据都集中到同一个位置，便于进行管理，然后监测数据库中配置数据的变化，并将配置数据同步到内存缓存与本地文件中，最后读取配置数据至客户端，从而便于在待更新配置数据数量倍增的情况下，能够对更新的配置进行同步管理。

示例性方法

本实施例中的一种配置数据管理方法可应用于终端设备中，比如智能手机、平板电脑、笔记本电脑，所述终端设备在中均设置有微服务架构。具体实施时，如图1中所示，本实施例中的一种配置数据管理方法包括如下步骤：

步骤S100、获取待更新配置数据，并将所述待更新配置数据推送到数据库中。

具体实施时，由于本实施例需要对待更新配置数据进行配置管理，因此需要先获取待更新配置数据，为了便于更好的监测待更新配置数据的变化情况，在获取到待更新配置数据后，将待更新配置数据推送到数据库中，从而一方面便于后面对待更新配置数据进行管理，另一方面便于监测待更新配置数据的变化情况进行监测。具体地，通过预设的发布修改功能获取待更新配置数据，然后通过代理服务器将获取到的待更新配置数据推送到数据库中，本申请实施例中的数据库可以为ETCD集群。比如，配置中心预先提供了配置数据的发布修改功能，通过发布修改功能对配置数据进行修改和发布，从而得到待更新配置数据，然后配置中心通过proxy将待更新配置数据推送到ETCD集群中，从而实现将待更新配置数据统一存储和管理。较佳的，在获取待更新配置数据的同时，通过将待更新配置数据持久到数据块中，从而对待更新配置数据进行记录，便于记录数据更新情况，使操作者清楚了解到进行更新的内容，提高操作的便捷性。

步骤S200、监测所述数据库的数据变化情况，基于所述数据变化情况获取更新后的配置数据。

本实施例在将获取到的待更新配置数据推送至数据库后，通过对数据库内的数据情况变化，确定更新后的配置数据，便于根据更新后的配置数据进行配置的更新。具体地，通过预设的代理软件对数据库的数据变化情况进行监测，当数据变化情况为数据库的数据发生变化时，获取数据库内所有配置数据，从而得到更新后的配置数据，其中，更新后的配置数据包括数据库中原本存在的配置数据与通过代理服务器推送至数据库中的待更新配置数据。较佳的，服务器上预先设置有agent，agent通过watch etcd获取到数据库中的数据变化情况，当数据变化情况为数据库的数据增加或者减少时，获取数据库内的所有配置数据，从而得到更新后的配置数据。

步骤S300、根据所述更新后的配置数据进行配置更新。

本实施例中可以根据获取到的更新后的配置数据进行配置更新，由于更新后的配置数据中包括了待更新配置数据，因此可以根据更新后的配置数据进行配置更新，从而在配置文件的数量倍增的情况下，便于对大量的配置数据进行管理，提高操作的简便性。

在根据更新后的配置数据进行配置更新之前，先将更新后的配置数据发送至预设的代理软件中，同时将更新后的配置数据同步到内存缓存与本地文件中，从而便于后续对更新后的配置数据进行读取。

在一种实现方式中，如图2所示，所述步骤S300包括如下步骤：

S301、将所述更新后的配置数据发送至预设的应用程序中；

S302、控制所述预设的应用程序根据所述更新后的配置数据进行配置更新。

具体实施时，本实施例在获取到更新后的配置数据后，将更新后的配置数据发送至预设的应用程序中。具体地，在将更新后的配置数据发送至应用程序的过程中，先对内存缓存进行监测，当监测到内存缓存中存在更新后的配置数据时，对内存缓存中的更新后的配置数据进行读取，并将读取到的更新后的配置数据发送至应用程序中。当内存缓存中不存在更新后的配置数据时，对本地文件进行监测，当监测到本地文件中存在更新后的配置数据时，对本地文件中的更新后的配置数据进行读取，并将读取到的更新后的配置数据发送至应用程序中。当本地文件中不存在更新后的配置数据时，读取数据库中的更新后的配置数据，并将读取到的更新后的配置数据发送至应用程序中，同时将读取到的更新后的配置数据保存到本地文件中进行缓存。在将更新后的配置数据发送至应用程序的过程中，对更新后的配置数据的获取通过依次从内存缓存、本地文件与数据库进行读取，直至读取到更新后的配置数据后，即可将更新后的配置数据发送至应用程序中。较佳的，在对内存缓存、本地文件与数据库中的更新后的配置数据进行读取的时候，可以通过直接读取的方式，也可以通过数据接口拉取数据的方式。

综上，本实施例首先获取待更新配置数据，通过代理服务器将待更新配置数据推送到数据库中，通过对数据库中的数据变化情况进行监测，当监测到数据库中的数据发生变化时，则获取数据库中的所有配置数据，得到更新后的配置数据，然后将更新后的配置数据发送至预设的应用程序中，根据更新后的配置数据进行配置更新。通过将待更新配置数据都集中到同一个位置，便于进行管理，然后根据更新后的配置数据进行更新，提高对配置进行管理和更新的便捷性。比如，在需要对某个配置文件进行更新的时候，先通过配置中心预设的发布修改功能对配置数据进行修改和发布，得到待更新配置数据，然后通过proxy将待更新配置数据推送至ETCD集群中，服务器上设置的agent对ETCD集群中的数据变化情况进行监测，当监测到ETCD集群中的数据增加或减少时，获取ETCD集群中的所有配置数据，得到更新后的配置数据，最后通过将更新后的配置数据发送至预设的应用程序中，并控制应用程序根据更新后的配置数据进行更新。由此可见，本实施例通过将待更新配置数据推送至数据库中，再从数据库中获取更新后的配置数据，当配置数据的数量较大的时候，能够便于对配置数据进行管理，从而适应快速发展的微服务架构。

示例性装置

如图3中所示，本实施例还提供一种配置数据管理装置，该装置包括：待更新配置数据获取模块10、监测模块20、执行模块30。具体地，所述待更新配置数据获取模块10，获取待更新配置数据，并将所述待更新配置数据推送到数据库中。所述监测模块20，用于监测所述数据库的数据变化情况，基于所述数据变化情况获取更新后的配置数据。所述执行模块30，用于用于根据所述更新后的配置数据进行配置更新。

在一种实现方式中，所述待更新配置数据获取模块包括：

获取单元，用于通过预设的发布修改功能获取所述待更新配置数据；

记录单元，用于在获取所述待更新配置数据的同时，将所述待更新配置数据进行记录；

推送单元，用于通过代理服务器将所述待更新配置数据推送到所述数据库。

在一种实现方式中，所述监测模块包括：

监测单元，用于通过预设的代理软件对所述数据库的数据变化情况进行监测；

更新后的配置数据获取单元，用于当所述数据变化情况为所述数据库的数据发生变化时，获取所述数据库内的所有配置数据得到更新后的配置数据。

在一种实现方式中，所述执行模块包括：

配置数据发送单元，用于将所述更新后的配置数据发送至预设的应用程序中；

控制单元，用于控制所述预设的应用程序根据所述更新后的配置数据进行配置更新。

在一种实现方式中，所述配置数据发送单元包括：

第一监测子单元，用于对所述内存缓存进行监测；

第一读取子单元，用于当监测到所述内存缓存中存在所述更新后的配置数据时，从所述内存缓存中读取所述更新后的配置数据，并发送至预设的应用程序中；

第二监测子单元，用于当所述内存缓存中不存在所述更新后的配置数据时，对所述本地文件进行监测；

第二读取子单元，用于当监测到所述本地文件中存在所述更新后的配置数据时，从所述本地文件中获取所述更新后的配置数据，并发送至预设的应用程序中；

第三监测子单元，用于当所述本地文件中不存在所述更新后的配置数据时；读取所述数据库中的所述更新后的配置数据，并发送至预设的应用程序中，同时将读取到的所述更新后的配置数据保存到本地文件。

基于上述实施例，本发明还提供一种终端设备，其原理框图可以如图4所示。该终端设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏、温度传感器。其中，该终端设备的处理器用于提供计算和控制能力。该终端设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该终端设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种配置数据管理方法。该终端设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该终端设备的温度传感器是预先在终端设备内部设置，用于监测内部设备的运行温度。

本领域技术人员可以理解，图4中示出的原理框图，仅仅是与本发明方案相关的部分结构的框图，并不构成对本发明方案所应用于其上的终端设备的限定，具体的终端设备以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种终端设备，终端设备包括存储器、处理器及存储在存储器中并可在处理器上运行的配置数据管理程序，处理器执行配置数据管理程序时，实现如下操作指令：

获取待更新配置数据，并将所述待更新配置数据推送到数据库中；

监测所述数据库的数据变化情况，基于所述数据变化情况获取更新后的配置数据；

根据所述更新后的配置数据进行配置更新。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本发明所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

综上，本发明提供了一种配置数据管理方法，所述方法首先获取待更新配置数据，通过代理服务器将待更新配置数据推送到数据库中，通过对数据库中的数据变化情况进行监测，当监测到数据库中的数据发生变化时，则获取数据库中的所有配置数据，得到更新后的配置数据，然后将更新后的配置数据发送至预设的应用程序中，根据更新后的配置数据进行配置更新。通过将待更新配置数据都集中到同一个位置，便于进行管理，然后根据更新后的配置数据进行更新，提高对配置进行管理和更新的便捷性。本实施例通过将待更新配置数据推送至数据库中，再从数据库中获取更新后的配置数据，当配置数据的数量较大的时候，从而便于在待更新配置数据数量倍增的情况下，能够对更新的配置进行同步管理，从而适应快速发展的微服务架构。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。