一种配置文件的管理应用系统的制作方法

1.本技术涉及软件开发技术领域，更具体地说，涉及一种配置文件的管理应用系统。


背景技术：

2.不同编程语言对配置文件的管理都有自己独立的框架和体系。以java语系springcloudconfig框架为例，当配置文件发生变化时会将最新配置推送到mq(消息队列)，而应用程序需要监听该mq才可以完成配置文件的更新。软件包需要添加spring-cloud-starter-config、spring-cloud-starter-eureka、spring-cloud-starter-bus-amqp、spring-boot-starter-actuator等一系列依赖工具。当一个单位或者组织需要用到多种开发语言工作时，运维团队需要付出巨大的工作量处理这个问题，在一定程度上提高了开发成本。


技术实现要素：

3.有鉴于此，本技术提供一种配置文件的管理应用系统，用于降低运维团队的工作量，以降低开发成本。
4.为了实现上述目的，现提出的方案如下：
5.一种配置文件的管理应用系统，包括数据中心和至少一个客户端，其中：
6.所述数据中心基于一个存储平台存储配置文件，所述存储平台用于根据同步请求向客户端提供配置文件的访问服务；
7.所述客户端基于预设条件向所述数据中心发出所述同步请求，拉取所述配置文件至所述客户端。
8.可选的，所述数据中心基于云平台存储所述配置文件，并且配置有至少一个缓存空间，其中：
9.所述缓存空间用于响应所述同步请求，并与所述云平台定期同步所述配置文件。
10.可选的，所述缓存空间的数量与运行实例的数量相匹配并一一对应，所述配置缓存空间用于通过云平台的sdk获取所述运行实例的信息，或者通过消息队列的sdk获取所述运行实例的信息。
11.可选的，所述缓存空间包括ip粒度缓存和集群粒度缓存，所述ip粒度缓存优先于所述集群粒度缓存。
12.可选的，所述数据中心在执行灰度发布时只修改所述ip粒度缓存并执行灰度发布。
13.可选的，所述客户端与所述数据中心通过消息队列实现通信，并通过所述消息队列实现所述配置文件的拉取。
14.可选的，所述客户端用于在本地的配置文件与对应缓存空间内配置文件不一致时执行拉取配置文件操作。
15.可选的，所述客户端在每次完成拉取配置文件操作后，计算当前配置文件的哈希
值，并通过与数据中心的配置文件的哈希值的对比判断两地的配置文件是否一致。
16.从上述的技术方案可以看出，本技术公开了一种配置文件的管理应用系统，该系统包括数据中心和至少一个客户端，数据中心基于一个存储平台存储配置文件，存储平台用于根据同步请求向客户端提供配置文件访问服务；客户端基于预设条件向数据中心发出同步请求，拉取配置文件至客户端。本技术通过将配置文件从业务代码中抽离出来，由一个独立的边车进程来管理并嵌入到业务镜像中，当运行实例运行时通过边车即可实现配置文件的更新。上层业务应用只需要以最简单的本地文件方式来加载配置文件即可，达到与开发语言的松耦合和零侵入，从而降低了运维团队的工作量，并在一定程度上降低了开发成本。
附图说明
17.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
18.图1为本技术实施例的一种配置文件的管理应用系统的示意图。
具体实施方式
19.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
20.实施例一
21.图1为本技术实施例的一种配置文件的管理应用系统的示意图。
22.如图1所示，本实施例提供的配置文件的管理应用系统应用于软件开发系统，包括数据中心10和至少一个与该数据中心连接的客户端20。
23.数据中心基于相应的存储平台实现配置文件的存储，该存储平台能够基于与该数据中心建立数据通道的客户端对其进行访问，并基于特定客户端的访问请求对其提供配置文件的访问服务。具体来说，该访问服务是指供客户端拉取相应的配置文件。
24.做为本技术技术方案核心的数据中心，配置文件的存储最好具备高可用、多副本、可迁移的特点，因此，本技术中的数据中心基于云平台100实现配置文件的存储，云平台对配置文件的存储具有免运维、自带鉴权、http直接访问等优势，从而方便配置文件的配置、发布和修改。
25.为了提高访问速度，减少与云平台的交互次数，本技术在基于云平台实现配置文件的存储的基础上，在数据中心配置有相应的缓存空间，缓存空间定期与云平台进行同步，本技术中的客户端在对数据中心进行访问时，仅通过该缓存空间实现配置文件的拉取，从而提高了查询效率。
26.当数据中心所服务的客户端为多个时，为每个客户端维护一个缓存空间，此时，数据中心需要知道有哪些客户端的应用实例对接了自己。本技术采用如下两种方案实现。一
种为直接通过云平台的sdk获取某业务负载均衡或弹性伸缩组内的运行实例的信息；第二种为通过消息队列的sdk查询有哪些客户端正在等待消费，从而获取到相应运行实例的信息。
27.本技术中的每个客户端与数据中心建立有访问通道，访问通道两端的server端是数据中心的web应用，另一端的客户端(client端)是业务实例上负责配置部分的边车服务。客户端与数据中心通过消息队列实现通信。边车服务只做数据拉取的动作，数据中心不主动做推送动作。
28.考虑到配置文件大小不可控、数据不同步属于小概率事件这两个因素，客户端侧的边车服务并不需要每次同步都拉取全量文件，为避免资源的浪费。在数据中心与客户端每次同步完后都各计算一次当前版本全文本的哈希值并予以缓存，在每次同步前将数据中心与客户端两侧的哈希值进行比对，只有在两侧的哈希值不一致时才拉取配置文件进行同步，如果相同则不进行同步，从而起到节约资源的作用。即该客户端基于两侧哈希值不同这一预设条件才向数据中心发出同步请求。
29.从上述技术方案可以看出，本实施例提供了一种配置文件的管理应用系统，该系统包括数据中心和至少一个客户端，数据中心基于一个存储平台存储配置文件，存储平台用于根据同步请求向客户端提供配置文件访问服务；客户端基于预设条件向数据中心发出同步请求，拉取配置文件至客户端。本技术通过将配置文件从业务代码中抽离出来，由一个独立的边车进程来管理并嵌入到业务镜像中，当运行实例运行时通过边车即可实现配置文件的更新。上层业务应用只需要以最简单的本地文件方式来加载配置文件即可，达到与开发语言的松耦合和零侵入，从而降低了运维团队的工作量，并在一定程度上降低了开发成本。
30.另外，在本实施例的一个具体实施方式中，数据中心提供ip粒度缓存和集群粒度缓存两个维度的配置缓存，边车进行数据同步时优先加载ip粒度缓存，当无法加载ip粒度缓存时再加载集群粒度配置。进行灰度发布时只需要修改数据中心的ip粒度缓存的配置文件即可，灰度结束需要全量发布时，修改集群粒度配置即可实现灰度发布。
31.基本本技术的技术方案，可以通过如下具体手段实施配置文件的调配：
32.配置文件存储在亚马逊s3中，数据中心用java的concurrenthashmap来维护缓存。数据同步的消息队列使用rabbitmq，边车用go语言开发可以更方便的植入业务镜像中。
33.借用云平台自己的发现机制直接调用api(application programming interface，应用程序接口)进行查询，利用弹性伸缩组作为集群粒度。
34.假如某弹性伸缩组有10台运行实例，修改数据中1台运行实例的ip的映射关系到新配置文件，进行10％比例的灰度发布，验证通过后可选择继续增大灰度比例直到全量更新。假如某弹性伸缩组有10台实例，修改数据中集群的映射关系到新配置文件，则直接进行全量更新。
35.本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
36.本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可
用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
37.本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
38.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
39.这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
40.尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。
41.最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
42.以上对本发明所提供的技术方案进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。