一种适应传统应用云化的配置系统及方法与流程

本发明涉及云平台技术领域，具体涉及一种适应传统应用云化的配置系统及方法。

背景技术：

近年来，随着devops模式的兴起，以及云平台的推广，越来越多的应用程序迁移上云。带来了负载均衡、自动扩缩容、平滑升级、冗余容灾、服务网格等功能，应用的稳定性、吞吐量、易用性都有了很大的提升。但是一般来说，应用的生命周期中，涉及很多配置，对应用配置管理提出了巨大的挑战。

在运行环境方面，有开发环境、测试环境、准生产环境、生产环境、用户验证环境等；在版本方面，有演示版本、测试版本、验证版本、1.0版本、2.0版本，甚至是某个特性的专有版本；在运行数量方面，一般会有1～3个副本，不同环境根据实际情况可能会有几个到上百个甚至更多的副本数量；在发版方面，得益于cicd系统，发版的频次也越来越快，可以达到每天几次甚至几十次发版；综上，应用程序不同的版本在不同的运行环境中，需要不同的配置文件；每次发版都需要进行配置；每一个副本都需要进行配置；当发生弹性扩缩容的时候需要马上进行配置。这样就导致了应用程序的配置组合繁杂且数量众多，传统的手工变更方式容易出现错误，并且无法做到及时全量的同步，阻碍了应用系统的快速部署。

现有云平台配置中心方案主要有springclouodconfig以及apollo。springcloud官方自身提供了springcloudconfig分布式配置中心，由它来提供集中化的外部配置支持，它分为客户端和服务端两个部分。其中服务端称作配置中心，是一个独立的微服务应用，用来连接仓库(如git、svn)并为客户端提供获取配置的接口；而客户端是各微服务应用，通过指定配置中心地址从远端获取配置内容，启动时加载配置信息到应用上下文中。因springcloudconfig实现的配置中心默认采用了git来存储配置信息，所以版本控制管理也是基于git仓库本身的特性来支持的。但是springclouodconfig只能用于java语言spring架构的应用程序，无法直接兼容其他语言、其他架构的应用程序。

apollo(阿波罗)是携程框架部门研发的分布式配置中心，集中化管理应用不同环境、不同集群的配置，可于微服务配置管理场景。apollo支持有限的开发语言和框架java，.net。apollo配置管理方式侵入性强，应用需要进行代码级别改造。

本发明要解决的技术问题是：传统应用在向云平台迁移时配置往往是制约迁移的一个关键点。传统的配置管理方式难以适应云上应用配置多副本、多版本、多环境、高频次发版的需求。现有云平台配置管理往往是针对特定框架、特定语言的，难以适应多语言、多框架各类应用。而且传统应用配置改造为云平台配置管理的成本较大，往往需要进行代码级别改造。

技术实现要素：

为了解决以上技术问题，本发明提出了一种适应传统应用云化的配置方法，包括如下步骤：

步骤1、配置中心进行初始化；

步骤2、应用开发者编写和设置应用程序使用的配置模板；

步骤3、部署配置中心客户端；

步骤4、部署应用程序并启动。

进一步的，所述步骤1具体包括：

步骤1.1采集环境基础信息，包括生产环境/测试环境/研发环境；

步骤1.2采集环境中基础中间件配置信息；环境中部署的基础中间件，包括负载均衡器信息、数据库信息、缓存服务信息、存储服务信息、消息队列服务信息；

步骤1.3创建配置规则，设置标记符、前缀、后缀；根据配置规则生成配置项，配置中心客户端将配置项根据应用程序的配置模板生成配置，配置是应用程序使用的；

步骤1.4启动配置中心；

步骤1.5查看可用配置规则、配置项；

步骤1.6将配置中心的服务信息写入到配置中心客户端运行的环境中。

进一步的，所述步骤2具体包括：

步骤2.1、应用开发者设置默认配置文件；

步骤2.2、按配置规则将默认配置文件变为配置模板。

进一步的，所述步骤3具体包括：

配置中心客户端基于编码实现，或者基于kubernetesconfigmap实现的。

进一步的，所述步骤4具体包括：

步骤4.1云平台自动编排，并自动将配置中心客户端以边车的形式注入绑定；

步骤4.2边车的方式将配置中心客户端和应用程序部署在一台机器上，云平台中边车注入的配置中心客户端和应用程序共享网络命名空间；

步骤4.3配置中心客户端读取所在运行环境的基本信息，发现配置中心，配置中心客户端通过环境信息获取配置中心的地址进而可以连接配置中心，向配置中心进行注册；

步骤4.4配置中心向配置中心客户端下发配置规则、配置项；

步骤4.5配置中心客户端读取应用程序提供的配置模板，并生成配置文件；

步骤4.6配置中心客户端将配置项注入环境变量；配置中心向配置中心客户端下发的配置项；

步骤4.7配置中心客户端启动多种服务模式，提供rest、文件形式的配置服务；应用程序通过配置中心客户端提供的rest接口，配置文件以及步骤4.6中的环境变量获取所需配置信息；

步骤4.8应用程序启动；

步骤4.9配置中心客户端监听配置中心变更，发送变更时，重复执行步骤4.4、4.5；配置中心会定期下发，当配置中心的配置规则或者配置项变化时也会下发。

本发明还提出一种适应传统应用云化的配置系统，包括：

配置中心、配置中心客户端，所述的配置中心客户端用于和配置中心通信并生成配置给应用程序。

配置中心位于云平台服务器上，包括：

环境信息管理模块：用于管理不同环境的基础设施信息；包括环境编号、所属区域、网络分区等信息；

基础中间件信息管理模块，用于管理不同环境中的基础中间件信息；环境中部署的基础中间件，包括负载均衡器信息、数据库信息、缓存服务信息、存储服务信息、消息队列服务信息；

配置规则管理模块，用于管理配置规则，将基础设施信息、基础中间件信息自动转换为配置项；制定配置规则，采用标记符、前缀、配置项名称、后缀的形式标记，将环境的基础信息、环境内部署的中间件信息，按规则，以特定的标记符号，转换为配置项；

配置变更事件管理模块，管理配置变更事件，当环境信息发生变化或者基础中间件信息发生变化，或者管理员更改配置项时，通过查询已注册的客户端列表，将配置信息增量变化部分推送给客户端；

管理客户端注册管理模块，用于管理客户端注册；

配置项的管理界面提供模块，用于提供界面，供管理员对配置项进行增加、修改、删除等功能；对配置项进行重新下发、批量下发、批量导出、批量导入等功能；对环境信息进行重新识别导入等功能。

进一步的，管理客户端注册管理模块，用于管理客户端注册；依次执行以下步骤：

接收客户端启动后，自动向管理中心进行注册；

接收客户端所在应用程序的应用标识、版本、运行环境等基础信息；

配置中心向客户端下发配置规则；

配置中心向客户端下发客户端需要的全量的环境配置信息；

配置中心的配置项发生变更时，向客户端推送增量配置；

配置中心定期向客户端发送全量的配置、全量的配置规则；

进一步的，配置中心客户端包括：

注册模块：用于读取云平台的环境信息，自动识别所处的运行环境，并向配置中心进行注册；读取应用程序的应用标识、版本、运行环境等信息，并向配置中心进行注册；

部署模块：用于将客户端以边车的模式与应用程序部署在一起；

配置文件生成模块，用于接收配置中心的配置规则、配置项，读取应用程序的配置文件模板，按照规则，生成配置文件；

监听模块：用于监听配置中心变化，收到配置中心配置变更事件时自动刷新应用程序的配置文件；

配置文件内容注入模块：用于将配置文件内容注入到应用程序运行的环境变量中；

访问接口提供模块：用于提供rest访问接口，供应用程序调用查询配置文件内容。

有益效果：

本发明提供了一种范语言、范框架的云平台配置系统及方法，既可以兼容传统应用配置，使得传统应用以较小的代价实现云平台配置的迁移；也可以兼容云原生应用的配置管理。本发明所提配置系统及方法通过多种配置手段实现应用配置自动化，解决了应用程序在云平台中多副本、多版本、多环境、高频次发版情况下配置难以管理的问题。

现有云平台的配置中心受限于特定的语言和框架，例如springclouodconfig只能用于java语言spring架构的应用程序，无法直接兼容其他语言、其他架构的应用程序。apollo支持有限的开发语言和框架java，.net，其他语言需要有配套的客户端才可使用。本发明所提配置中心方案可以支持支持范语言、范框架的应用配置管理。

使用现有云平台配置中心时，传统应用程序往往需要进行源码级的改动，改造成本高；并且程序改造后依赖特定配置中心，降低了应用程序部署形式的灵活性。这样的改造对于传统应用往往是不可接受的。传统应用使用本发明所提配置中心方案上云时可以不需要进行代码级别的改造，降低了改造成本。传统应用于本发明所提配置中心适配完成后，可以不依赖于本发明所提配置中心进行其他形式的部署。

附图说明

图1：本发明的自动化配置管理框架结构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅为本发明的一部分实施例，而不是全部的实施例，基于本发明中的实施例，本领域的普通技术人员在不付出创造性劳动的前提下所获得的所有其他实施例，都属于本发明的保护范围。

如附图1，本发明的配置系统包括配置中心、配置中心客户端(配置中心客户端与应用程序部署在一起)，所述的配置中心客户端用于和配置中心(配置中心可以根据需要支持的应用规模部署在服务器或者pc机等设备上)通信并生成配置给应用程序(应用程序可位于服务器也可位于客户端)，参见附图1配置中心客户端c1-c4。

配置中心位于云平台服务器上，其功能包括：

管理不同环境的基础设施信息；包括环境编号、所属区域、网络分区等信息。

管理不同环境中的基础中间件信息；环境中部署的基础中间件，如负载均衡器信息、数据库信息、缓存服务信息、存储服务信息、消息队列服务信息等。

管理配置规则，将基础设施信息、基础中间件信息自动转换为配置项；

制定配置规则，采用标记符、前缀、配置项名称、后缀的形式标记，将环境的基础信息、环境内部署的中间件信息，按规则，以特定的标记符号，转换为配置项。例如可以约定采用@$server_ip$的形式进行标记，其中标记符为@，前缀为$,后缀为$。

将环境的基础信息、环境内部署的中间件信息，按上述规则，以特定的标记符号，转换为配置项。

假设环境内的redis服务ip为1.2.3.4，端口为5678，转换成2条配置项，

形如：@$env_redis_ip$＝1.2.3.4

@$env_reids_port$＝5678

管理配置变更事件，当发生配置变更时推送给客户端；

当环境信息发生变化或者基础中间件信息发生变化，或者管理员更改配置项时，通过查询已注册的客户端列表，将配置信息增量变化部分推送给客户端。

管理客户端注册，依次执行以下步骤：

接收客户端启动后，自动向管理中心进行注册；

接收客户端所在应用程序的应用标识、版本、运行环境等基础信息；

配置中心向客户端下发配置规则；

配置中心向客户端下发客户端需要的全量的环境配置信息；

配置中心的配置项发生变更时，向客户端推送增量配置；

配置中心定期向客户端发送全量的配置、全量的配置规则；

提供配置项的管理界面

提供界面，供管理员对配置项进行增加、修改、删除等功能；对配置项进行重新下发、批量下发、批量导出、批量导入等功能；对环境信息进行重新识别导入等功能。

根据本发明的一个实施例，继续参见图1，其中，配置中心客户端的功能包括：

读取云平台的环境信息，自动识别所处的运行环境，并向配置中心进行注册；

读取应用程序的应用标识、版本、运行环境等信息，并向配置中心进行注册；

客户端可以以边车的模式与应用程序部署在一起。

客户端接收配置中心的配置规则、配置项，读取应用程序的配置文件模板，按照规则，生成配置文件。可选的，配置文件模板首行用于描述存放路径，如/a/b/c/x.json，代表将生成的配置文件存放到/a/b/c/x.json。

监听配置中心变化，收到配置中心配置变更事件时自动刷新应用程序的配置文件。

客户端可以将配置文件内容注入到应用程序运行的环境变量中。

客户端可以提供rest访问接口，供应用程序调用查询配置文件内容。

客户端可以提供文件访问接口，以json、xml、ini的方式保存查询配置文件内容。

根据本发明的一个实施例，该方法的云平台配置中心的配置运行步骤是：

步骤1、配置中心初始化：

步骤1.1采集环境基础信息，包括生产环境/测试环境/研发环境；

步骤1.2采集环境中基础中间件配置信息；环境中部署的基础中间件，如负载均衡器信息、数据库信息、缓存服务信息、存储服务信息、消息队列服务信息等；

步骤1.3创建配置规则，设置标记符、前缀、后缀；根据配置规则生成配置项，配置中心客户端将配置项根据应用程序的配置模板生成配置。配置是应用程序使用的；

步骤1.4启动配置中心；

步骤1.5查看可用配置规则、配置项；

步骤1.6将配置中心的服务信息(如配置中心的ip，端口或者域名等可以使得配置中心客户端连接配置中心)写入到配置中心客户端运行的环境中。一般云平台在编排应用时，能够将一些基础信息开放给应用程序，也会将应用的基础信息开放给云平台。配置中心客户端就是利用这些开放的信息，识别所在的运行环境，识别应用程序版本等信息，以及发现配置中心；应用程序是运行在云平台上。

步骤2、编写配置模板：

步骤2.1应用开发者默认配置文件；

步骤2.2按配置规则将默认配置文件变为配置模板；

步骤3、部署配置中心客户端：

配置中心客户端实现技术可以有多种，可以是编码实现的程序或应用。可以是基于kubernetesconfigmap实现的。

步骤4、部署应用程序：

步骤4.1云平台自动编排，并自动将客户端以边车的形式注入绑定；

步骤4.2边车的方式将配置中心客户端和应用程序部署在一台机器上，云平台中边车注入的配置中心客户端和应用程序往往共享网络命名空间；

步骤4.3客户端读取所在运行环境的基本信息，发现配置中心，向配置中心进行注册；配置中心客户端可以通过环境信息获取配置中心的地址进而可以连接配置中心；

步骤4.4配置中心向配置中心客户端下发配置规则、配置项；

步骤4.5配置中心客户端读取应用程序提供的配置模板，并生成配置文件；

步骤4.6客户端将配置项注入环境变量；配置中心向配置中心客户端下发配置项；

步骤4.7客户端启动多种服务模式，提供rest、文件等形式的配置服务；应用程序可以通过配置中心客户端提供的rest接口，配置文件以及步骤6中的环境变量获取所需配置信息；

步骤4.8应用程序启动；参见图1中的应用程序p1-p4；

步骤4.9配置中心客户端监听配置中心变更，发送变更时，重复执行4、5；配置中心会定期下发，当配置中心的配置规则或者配置项变化时也会下发；

本发明所提配置中心方案支持范语言、范框架的软件配置管理；

传统应用使用本发明所提配置中心方案上云时可以不需要进行代码级别的改造，降低了改造成本。传统应用于本发明所提配置中心适配完成后，可以不依赖于本发明所提配置中心进行其他形式的部署。

本发明所提配置中心方案支持多种配置方式，支持全类型配置文件方式，支持环境变量方式，支持启动参数方式，支持数据库方式。

配置中心客户端能够自动识别运行环境及应用程序信息，配置中心据此推送相关配置给客户端；

配置中心无需维护多版本、多环境下的配置组合矩阵，只需维护单一配置项；

配置中心按客户端需求将配置规则、配置数据推送给客户端，客户端按照配置模板为应用程序生成配置。

综上，可以看出，本发明提出的技术方案具体有如下优势：

1)本发明实现了一套配置规则，使得应用程序在配置时，可以不关心具体的配置内容，只需按规则进行配置的声明；

2)本发明对应用程序编程语言没有要求，可以不对应用程序进行代码级改造；

3)本发明能够自动识别云平台所处环境，进而自动配置，做到一次描述，随时可用；

4)本发明能够做到配置的自动更新，传统模型下，更改了某一配置项，需要将所有使用此项的配置文件重写，客户端可以自动更新配置文件，避免漏更、错更；

5)本发明能够覆盖多副本、多版本、多环境、高频次发版的需求场景；

6)本发明与现有技术相比，易用性、准确性、及时性等方面优于同类技术方案；

7)本发明采用客户端按需与配置中心交互的方式，应用程序可以从本地获得数据，避免了应用程序直接访问配置中心带来的访问压力。发生变更时配置中心可以精确推送增量配置给客户端；

8)在大规模分布式部署情况下，传统的配置中心压力较大，可能会成为瓶颈，本发明所提方案可以支撑大规模部署情况下的应用配置服务。

尽管上面对本发明说明性的具体实施方式进行了描述，以便于本技术领域的技术人员理解本发明，且应该清楚，本发明不限于具体实施方式的范围，对本技术领域的普通技术人员来讲，只要各种变化在所附的权利要求限定和确定的本发明的精神和范围内，这些变化是显而易见的，一切利用本发明构思的发明创造均在保护之列。