CN114895943A - 一种应用配置增量分发与自动升级的实现方法与装置 - Google Patents

Abstract

本发明特别涉及一种应用配置增量分发与自动升级的实现方法与装置。该应用配置增量分发与自动升级的实现方法与装置，从底层向上划分为存储层，业务层与接入层；存储层负责数据的存储与访问，业务层负责核心业务逻辑处理，接入层负责系统与用户的接入；利用配置分组管理模型与权限控制机制对应用配置按照层级、模块与版本进行分组管理，并且以标准CCM配置包为载体进行配置补丁的分发与升级；该应用配置增量分发与自动升级的实现方法与装置，能够根据层级、模块与版本等不同的维度进行配置信息的可视化管理操作，并提供统一的标准CCM配置包来进行配置补丁的分发传递与自动升级，有效的解决了配置变更升级过程中存在的各种问题。

Description

一种应用配置增量分发与自动升级的实现方法与装置

技术领域

本发明涉及企业应用中间件技术领域，特别涉及一种应用配置增量分发与自动升级的实现方法与装置。

背景技术

配置作为应用程序的代码，贯穿于应用的整个生命周期。应用程序在启动时通过读取配置来完成系统初始化，在运行时根据配置来动态的调整执行逻辑，因此配置对应用程序的作用至关重要。单体应用场景中，一部分配置以变量的形式与代码耦合在一起，一部分配置存放在本地文件中，通过修改代码或配置文件来完成配置信息的变更升级。随着微服务与云原生技术的发展与普及，越来越多的应用将配置从代码中剥离出来，使用配置中心服务对配置信息进行统一的管理，通过在配置中心中修改配置信息来完成配置的变更升级。

现有的技术方案中，无论是单体应用场景，还是基于微服务与云原生架构的分布式应用场景，从开发环境到生产环境的配置变更总体流程都是研发人员变更配置，将变更的配置信息以文本结构的形式在测试单中提交给测试人员，测试人员手工修改测试环境的配置信息进行测试验证。测试通过后，再将测试通过后的配置变更信息以文本结构的形式在发布单中传递给实施或运维或开发人员，然后手工修改生产环境的配置信息进行发布上线，最终配置生效。

综上，在传统的应用系统中，配置信息通常是以文本为载体以邮件，文档，网页等形式进行传递，不同的角色在不同的环境中进行手工编辑修改，然后保存，发布生效。这种模式会带来如下问题：

(1)手工修改配置容易出现遗漏，重复配置，配置相互覆盖，删除错误，字符编码与拼写错误，结构错位，环境与部署间错配，忘记保存发布等人为错误，进而引发生产事故；

(2)以文本为载体的配置变更信息在研发，测试，实施与运维的整个交付生命周期的传递过程中容易被篡改，而且不容易追溯，进而带来生产事故且找不到责任人；

(3)手工修改配置，还给整个交付生命周期中的各个岗位上的工作人员带来很大的配置编辑与核对的工作量，极大的降低了工作效率，增加了不必要的研发成本；

(4)缺乏对配置信息进行细粒度的权限控制，一经授权，整个应用的所有配置信息都可以查看与编辑修改，容易出现越权操作与访问，造成安全隐患；

(5)缺乏对配置的统一的可视化管理，无法追溯配置的变更历史，升级补丁，与发布记录。

为了解决上述问题，本发明提出了一种应用配置增量分发与自动升级的实现方法与装置。

发明内容

本发明为了弥补现有技术的缺陷，提供了一种简单高效的应用配置增量分发与自动升级的实现方法与装置。

本发明是通过如下技术方案实现的：

一种应用配置增量分发与自动升级的实现方法与装置，其特征在于：利用配置分组管理模型与权限控制机制对应用配置按照层级、模块与版本进行分组管理，并且以标准CCM(Cloud Config Mudule)配置包为载体进行配置补丁的分发与升级。

所述配置分组管理模型按照层级、模块与版本维度进行配置信息的增量升级，过程如下：

步骤S1、将配置信息按照业务范畴划分为不同的配置模块，并为每个配置模块设置唯一标识；

步骤S2、通过依赖组合不同的配置模块及不同的配置版本生成部署单元的配置，具体的应用部署配置则根据部署单元的配置、环境变量以及项目定制化的配置来共同动态合并产生；

合并时，相同配置项的配置值按照配置模块所属的层级关系从上往下逐层进行覆盖，应用的部署配置在审核发布后生效，每次发布都将前一次的配置进行历史归档，以便能够随时将配置回滚到之前的任何版本。

当需要进行配置变更时，如果是已经存在的配置模块，则直接在该配置模块下新建配置版本，在新版本中提交变更内容，然后修改对应部署单元对该配置模块的依赖版本，最后再针对不同的环境进行部署配置的发布即可完成配置的变更；

如果是新的配置模块，则先创建配置模块，然后新建配置版本，在新版本中提交变更内容，并增加对应部署单元对新模块新版本的依赖，最后再针对不同的环境进行部署配置的发布即可完成配置的变更。

所述权限控制机制以配置模块作为应用配置的最小单位，以配置模块为单位进行权限控制，以实现最小化安全原则；遵循谁创建谁负责的原则，配置模块的创建人即是该配置模块的权限总负责人，拥有读、写、删与授权他人的权限；配置模块权限总负责人具有将配置模块的权限授予其他人的权限，没有权限的人则无法查看、修改或删除该配置模块的任何配置信息。

所述步骤S1中，各配置模块的唯一标识由命名空间与配置模块标识名称来确定，即根据每个配置模块隶属于的层级，及其所属的版本对应的唯一的版本号来命名；每当配置信息发生变更都将产生一个新的配置版本。

所述版本号由大版本，小版本，补丁版本三个数字以圆点符分隔组成。

所述标准CCM配置包是将配置信息抽象封装成具有统一格式与统一结构的配置包；配置补丁统一以标准CCM配置包的形式在不同的角色不同的环境之间传递。

以标准CCM配置包为基础对所有配置模块的全量版本进行出盘，在不同的角色与场景之间进行不可变的分发，在不同的环境中进行还原，实现配置信息的自动初始化。

在进行配置信息升级时，对变更的配置模块的增量版本进行备份，在需要升级的环境中，通过标准CCM配置包自动增加对应的配置模块与版本，自动修改对应部署单元对新增配置模块新版本的依赖，自动针对不同的环境进行部署配置的发布即可完成配置的自动升级变更。

通过所述标准CCM配置包实现一次配置变更，制作一次配置补丁，即可完成所有环境的配置升级；

所述标准CCM配置包中包括命名空间、模块名称、application.yaml文件和packages.yml文件，所述命名空间为配置模块所属的命名空间，同一命名空间下的配置模块放在同一个目录下，不同命名空间的配置模块放到不同的目录下；所述模块名称为配置模块的标识名称；所述application.yaml文件用于存放该配置模块对应版本的配置内容信息；所述packages.yml文件用于存放该标准CCM配置包中所有相关的配置模块，版本的基本信息及其相互依赖关系。

本发明应用配置增量分发与自动升级的实现方法，提供不同环境不同部署间配置信息的隔离机制；

将环境与部署单元配置进行单独的抽象，环境与部署单元配置进行组合生成对应应用的部署配置；不同的部署单元与不同的环境结合生成针对不同环境的不同配置，同一个部署单元与开发环境结合生成开发环境配置，与测试环境结合生成测试环境的配置，与生产环境结合生成生成环境的配置；部署单元依赖的新配置模块新配置版本，在成功发布部署配置后才对应用生效；

在通过标准CCM配置包进行新配置模块新配置版本升级时，在需要升级的环境中，自动针对不同的环境进行部署配置的发布，不同环境的发布只影响该环境对应的配置，没有发布的环境仍然使用原来的配置信息，从而实现了不同环境及不同部署单元之间的配置信息相互隔离，互不影响。

本发明应用配置增量分发与自动升级的实现方法，其部署场景支持单机部署模式、私有云部署模式和公有云部署模式；

S1、单机部署模式

在单机模式下，应用都是单体部署的，配置信息存放在本地磁盘文件中，将标准CCM配置包中的配置信息与本地文件中的配置信息进行合并即可；

所述单机模式下实现步骤如下：

S11、开发人员通过配置管理平台的新增配置模块配置版本功能来变更配置信息，并通过备份功能来生成配置变更信息的标准CCM配置包，通过补丁工具将标准CCM配置包制作成配置补丁，并发布到补丁库；

S12、测试人员对配置补丁进行测试验证，并对补丁的测试结果进行标记；

S13、如果单机部署环境的网络是私有封闭的，实施运维人员对测试通过的补丁进行下载刻盘，将下载刻盘的补丁导入到单机环境的补丁升级客户端中；否则通过补丁升级客户端直接远程连接补丁库，直接从补丁库下载测试通过的补丁到本地环境；

S14、补丁升级客户端通过调用内嵌在单机应用系统中的配置中心服务来完成本地yaml配置文件的合并变更；

S15、重启应用服务来加载最新的配置信息。

S2、私有云部署模式

在私有云模式下，应用采用分布式集群部署，配置信息存放于配置中心，将标准CCM配置包中的配置信息与配置中心中的配置信息进行合并即可；

所述私有云部署模式下实现步骤如下：

S21、开发人员通过配置管理平台的新增配置模块配置版本功能来变更配置信息，并通过备份功能来生成配置变更信息的CCM配置包，通过补丁工具将标准CCM配置包制作成配置补丁，并发布到补丁库；

S22、测试人员对配置补丁进行测试验证，并对补丁的测试结果进行标记；

S23、如果私有云环境不允许直接连接外网，则将补丁升级客户端部署在前置机上，补丁升级客户端远程连接补丁库，从补丁库下载测试通过的补丁到私有云环境；

S24、补丁升级客户端通过调用私有云环境中的配置中心服务来完成配置信息的合并变更；

S25、配置中心通过发布配置，以及结合配置中心SDK的远程推送能力使应用加载最新的配置

S3、公有云部署模式

公有云模式与私有云模式类似，应用都是分布式集群部署的，配置信息都是存放于配置中心，将标准CCM配置包中的配置信息与配置中心中的配置信息进行合并即可。

所述公有云部署模式下实现步骤如下：

S31、开发人员通过配置管理平台的新增配置模块配置版本功能来变更配置信息，并通过备份功能来生成配置变更信息的CCM配置包，通过补丁工具将标准CCM配置包制作成配置补丁，并发布到补丁库；

S32、测试人员对配置补丁进行测试验证，并对补丁的测试结果进行标记；

S33、补丁升级客户端远程连接补丁库，从补丁库中下载测试通过的补丁到公有云环境；

S34、补丁升级客户端通过调用公有云环境中的配置中心服务来完成配置信息的变更；

S35、配置中心通过发布配置，以及结合配置中心SDK的远程推送能力使应用加载最新的配置。

基于本发明应用配置增量分发与自动升级的实现方法的装置，其特征在于：从底层向上划分为存储层，业务层与接入层；所述存储层负责数据的存储与访问，其组件包括数据库PostgreSQL与缓存Redis；所述业务层负责核心业务逻辑处理，其组件包括配置模块，配置版本，部署单元，依赖关系，环境，部署配置与权限控制；所述接入层负责系统与用户的接入，其组件包括Restful API，客户端SDK以及Web可视化界面与配置补丁管理及升级工具；

通过配置管理平台提供统一的配置服务、可视化管理界面、统一Restful API接口与客户端SDK(Software Development Kit，软件开发包)及相关工具；

所述可视化管理界面支持配置模块与配置版本的管理、环境管理、部署单元管理和部署配置管理；

在配置模块与版本管理中对配置模块进行增、删、改、查、授权、备份、出盘和/或还原操作；对配置版本进行增、删、改、查和/或下载分层结构操作；通过依赖组合不同配置模块的不同配置版本来产生新的配置模块新的配置版本；

所述环境管理对开发、测试、演练、预发、UAT(User Acceptance Test，用户验收测试)、灰度及生产的环境类型进行增、删、改和/或查操作；

所述部署单元管理对应用的部署单元以及所依赖的配置模块与配置版本进行增、删、改和/或查操作；

所述部署配置管理通过组合环境与部署单元来产生，用于针对特定环境的部署配置进行创建、提交、审核合并、发布、历史归档和/或回滚操作；

所述客户端SDK及相关工具负责实现基于标准CCM配置包的配置补丁管理以及配置补丁升级。

本发明的有益效果是：该应用配置增量分发与自动升级的实现方法与装置，能够根据层级、模块与版本等不同的维度进行配置信息的可视化管理操作，并提供统一的标准CCM配置包来进行配置补丁的分发传递与自动升级，有效的解决了配置变更升级过程中存在的各种问题。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

附图1为本发明应用配置增量分发与自动升级的实现装置架构示意图。

附图2为本发明标准CCM配置包结构示意图。

附图3为本发明配置管理平台核心功能示意图。

附图4为本发明单机模式下应用配置增量分发与自动升级的实现方法示意图。

附图5为本发明私有云/公有云部署模式下应用配置增量分发与自动升级的实现方法示意图。

具体实施方式

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

该应用配置增量分发与自动升级的实现方法，利用配置分组管理模型与权限控制机制对应用配置按照层级、模块与版本进行分组管理，并且以标准CCM(Cloud ConfigMudule)配置包为载体进行配置补丁的分发与升级。

所述配置分组管理模型按照层级、模块与版本维度进行配置信息的增量升级，过程如下：

步骤S1、将配置信息按照业务范畴划分为不同的配置模块，并为每个配置模块设置唯一标识；

步骤S2、通过依赖组合不同的配置模块及不同的配置版本生成部署单元的配置，具体的应用部署配置则根据部署单元的配置、环境变量以及项目定制化的配置来共同动态合并产生；

合并时，相同配置项的配置值按照配置模块所属的层级关系从上往下逐层进行覆盖，如项目定制级可覆盖二开级，二开级可覆盖产品级，产品级可覆盖平台级。应用的部署配置在审核发布后生效，每次发布都将前一次的配置进行历史归档，以便能够随时将配置回滚到之前的任何版本。

当需要进行配置变更时，如果是已经存在的配置模块，则直接在该配置模块下新建配置版本，在新版本中提交变更内容，然后修改对应部署单元对该配置模块的依赖版本，最后再针对不同的环境进行部署配置的发布即可完成配置的变更；

如果是新的配置模块，则先创建配置模块，然后新建配置版本，在新版本中提交变更内容，并增加对应部署单元对新模块新版本的依赖，最后再针对不同的环境进行部署配置的发布即可完成配置的变更。

所述权限控制机制以配置模块作为应用配置的最小单位，以配置模块为单位进行权限控制，以实现最小化安全原则；遵循谁创建谁负责的原则，配置模块的创建人即是该配置模块的权限总负责人，拥有读、写、删与授权他人的权限；配置模块权限总负责人具有将配置模块的权限授予其他人的权限，没有权限的人则无法查看、修改或删除该配置模块的任何配置信息。如此即可对配置信息进行以配置模块为粒度的安全管控。详细模型如附图3所示。

所述步骤S1中，各配置模块的唯一标识由命名空间与配置模块标识名称来确定，即根据每个配置模块隶属于的层级，如平台级，产品级，二开级，项目定制级等，及其所属的版本对应的唯一的版本号来命名；每当配置信息发生变更都将产生一个新的配置版本。

所述版本号由大版本，小版本，补丁版本三个数字以圆点符分隔组成，如1.0.0。

所述标准CCM配置包是将配置信息抽象封装成具有统一格式与统一结构的配置包；配置补丁统一以标准CCM配置包的形式在不同的角色不同的环境之间传递。

以标准CCM配置包为基础对所有配置模块的全量版本进行出盘，在不同的角色与场景之间进行不可变的分发，在不同的环境中进行还原，实现配置信息的自动初始化。

在进行配置信息升级时，对变更的配置模块的增量版本进行备份，在需要升级的环境中，通过标准CCM配置包自动增加对应的配置模块与版本，自动修改对应部署单元对新增配置模块新版本的依赖，自动针对不同的环境进行部署配置的发布即可完成配置的自动升级变更。

通过所述标准CCM配置包实现一次配置变更，制作一次配置补丁，即可完成所有环境的配置升级；

所述标准CCM配置包中包括命名空间、模块名称、application.yaml文件和packages.yml文件，所述命名空间为配置模块所属的命名空间，同一命名空间下的配置模块放在同一个目录下，不同命名空间的配置模块放到不同的目录下；所述模块名称为配置模块的标识名称；所述application.yaml文件用于存放该配置模块对应版本的配置内容信息；所述packages.yml文件用于存放该标准CCM配置包中所有相关的配置模块，版本的基本信息及其相互依赖关系。

一般情况下，在整个产品的研发交付生命周期中，往往存在多个不同的部署环境，以及多个不同的部署单元，同一个部署单元在不同的部署环境中很多配置信息会不一样，如测试环境与生产环境的数据库连接配置信息肯定不同，不同的部署单元在同一个部署环境中很多配置也不一样，如同一环境中财务部署单元与供应链部署单元的服务名称，端口信息，上下文信息，缓存信息，数据库信息，安全信息等都可能不一样。如果不加隔离，则会出现应用无法启动，数据错乱，业务错误，资金损失等生产事故。

该应用配置增量分发与自动升级的实现方法，提供不同环境不同部署间配置信息的隔离机制；

将环境与部署单元配置进行单独的抽象，环境与部署单元配置进行组合生成对应应用的部署配置；不同的部署单元与不同的环境结合生成针对不同环境的不同配置，同一个部署单元与开发环境结合生成开发环境配置，与测试环境结合生成测试环境的配置，与生产环境结合生成生成环境的配置；部署单元依赖的新配置模块新配置版本，在成功发布部署配置后才对应用生效；

在通过标准CCM配置包进行新配置模块新配置版本升级时，在需要升级的环境中，自动针对不同的环境进行部署配置的发布，不同环境的发布只影响该环境对应的配置，没有发布的环境仍然使用原来的配置信息，从而实现了不同环境及不同部署单元之间的配置信息相互隔离，互不影响。

该应用配置增量分发与自动升级的实现方法，其部署场景支持单机部署模式、私有云部署模式和公有云部署模式；

S1、单机部署模式

在单机模式下，应用都是单体部署的，配置信息存放在本地磁盘文件中，将标准CCM配置包中的配置信息与本地文件中的配置信息进行合并即可；

所述单机模式下，配置信息合并步骤如下：

S11、开发人员通过配置管理平台的新增配置模块配置版本功能来变更配置信息，并通过备份功能来生成配置变更信息的标准CCM配置包，通过补丁工具将标准CCM配置包制作成配置补丁，并发布到补丁库；

S12、测试人员对配置补丁进行测试验证，并对补丁的测试结果进行标记；

S13、如果单机部署环境的网络是私有封闭的，实施运维人员对测试通过的补丁进行下载刻盘，将下载刻盘的补丁导入到单机环境的补丁升级客户端中；否则通过补丁升级客户端直接远程连接补丁库，直接从补丁库下载测试通过的补丁到本地环境；

S14、补丁升级客户端通过调用内嵌在单机应用系统中的配置中心服务来完成本地yaml配置文件的合并变更；

S15、重启应用服务来加载最新的配置信息。

S2、私有云部署模式

在私有云模式下，应用采用分布式集群部署，配置信息存放于配置中心，将标准CCM配置包中的配置信息与配置中心中的配置信息进行合并即可；

所述私有云部署模式下，配置信息合并步骤如下：

S21、开发人员通过配置管理平台的新增配置模块配置版本功能来变更配置信息，并通过备份功能来生成配置变更信息的CCM配置包，通过补丁工具将标准CCM配置包制作成配置补丁，并发布到补丁库；

S22、测试人员对配置补丁进行测试验证，并对补丁的测试结果进行标记；

S23、如果私有云环境不允许直接连接外网，则将补丁升级客户端部署在前置机上，补丁升级客户端远程连接补丁库，从补丁库下载测试通过的补丁到私有云环境；

S24、补丁升级客户端通过调用私有云环境中的配置中心服务来完成配置信息的合并变更；

S25、配置中心通过发布配置，以及结合配置中心SDK的远程推送能力使应用加载最新的配置

S3、公有云部署模式

公有云模式与私有云模式类似，应用都是分布式集群部署的，配置信息都是存放于配置中心，将标准CCM配置包中的配置信息与配置中心中的配置信息进行合并即可。

所述公有云部署模式下，配置信息合并步骤如下：

S31、开发人员通过配置管理平台的新增配置模块配置版本功能来变更配置信息，并通过备份功能来生成配置变更信息的CCM配置包，通过补丁工具将标准CCM配置包制作成配置补丁，并发布到补丁库；

S32、测试人员对配置补丁进行测试验证，并对补丁的测试结果进行标记；

S33、补丁升级客户端远程连接补丁库，从补丁库中下载测试通过的补丁到公有云环境；

S34、补丁升级客户端通过调用公有云环境中的配置中心服务来完成配置信息的变更；

S35、配置中心通过发布配置，以及结合配置中心SDK的远程推送能力使应用加载最新的配置。

基于该应用配置增量分发与自动升级的实现方法的装置，从底层向上划分为存储层，业务层与接入层；所述存储层负责数据的存储与访问，其组件包括数据库PostgreSQL与缓存Redis；所述业务层负责核心业务逻辑处理，其组件包括配置模块，配置版本，部署单元，依赖关系，环境，部署配置与权限控制；所述接入层负责系统与用户的接入，其组件包括Restful API，客户端SDK以及Web可视化界面与配置补丁管理及升级工具；

通过配置管理平台提供统一的配置服务、可视化管理界面、统一Restful API接口与客户端SDK(Software Development Kit，软件开发包)及相关工具；

所述可视化管理界面支持配置模块与配置版本的管理、环境管理、部署单元管理和部署配置管理；

在配置模块与版本管理中对配置模块进行增、删、改、查、授权、备份、出盘和/或还原操作；对配置版本进行增、删、改、查和/或下载分层结构操作；通过依赖组合不同配置模块的不同配置版本来产生新的配置模块新的配置版本；

所述环境管理对开发、测试、演练、预发、UAT(User Acceptance Test，用户验收测试)、灰度及生产的环境类型进行增、删、改和/或查操作；

所述部署单元管理对应用的部署单元以及所依赖的配置模块与配置版本进行增、删、改和/或查操作；

所述部署配置管理通过组合环境与部署单元来产生，用于针对特定环境的部署配置进行创建、提交、审核合并、发布、历史归档和/或回滚操作；

所述客户端SDK及相关工具负责实现基于标准CCM配置包的配置补丁管理以及配置补丁升级。

通过在不同场景下的应用情况来看，本发明实施后操作简单，极大的降低了配置出错的概率，减少了生产事故，同时提高了研发效率，缩短了研发周期，从而降低了研发成本。下面以一个实际产品研发交付的案例来说明实施本发明后的收益。

与现有技术相比，该应用配置增量分发与自动升级的实现方法，具有以下特点：

(1)提供了一种将配置信息按照层级，模块，版本及其依赖关系来进行组织管理的模型以及按配置模块进行权限控制的机制；(2)提供了一种配置信息的统一封装体CCM(Cloud Config Mudule)配置包，该CCM配置包可用于在不同环境中对程序配置信息进行标准化的增量分发与升级；(3)实现了不同环境不同应用部署单元之间配置信息的隔离，彼此之间的升级变更互不影响；(4)提供统一的配置服务，配置可视化管理界面，统一Rest API接口，客户端SDK与配置升级工具。

以上所述的实施例，只是本发明具体实施方式的一种，本领域的技术人员在本发明技术方案范围内进行的通常变化和替换都应包含在本发明的保护范围内。

Claims (10)

1.一种应用配置增量分发与自动升级的实现方法，其特征在于：利用配置分组管理模型与权限控制机制对应用配置按照层级、模块与版本进行分组管理，并且以标准CCM配置包为载体进行配置补丁的分发与升级；

所述配置分组管理模型按照层级、模块与版本维度进行配置信息的增量升级，过程如下：

步骤S1、将配置信息按照业务范畴划分为不同的配置模块，并为每个配置模块设置唯一标识；

步骤S2、通过依赖组合不同的配置模块及不同的配置版本生成部署单元的配置，具体的应用部署配置则根据部署单元的配置、环境变量以及项目定制化的配置来共同动态合并产生；

合并时，相同配置项的配置值按照配置模块所属的层级关系从上往下逐层进行覆盖，应用的部署配置在审核发布后生效，每次发布都将前一次的配置进行历史归档，以便能够随时将配置回滚到之前的任何版本；

当需要进行配置变更时，如果是已经存在的配置模块，则直接在该配置模块下新建配置版本，在新版本中提交变更内容，然后修改对应部署单元对该配置模块的依赖版本，最后再针对不同的环境进行部署配置的发布即可完成配置的变更；

如果是新的配置模块，则先创建配置模块，然后新建配置版本，在新版本中提交变更内容，并增加对应部署单元对新模块新版本的依赖，最后再针对不同的环境进行部署配置的发布即可完成配置的变更。

2.根据权利要求1所述的应用配置增量分发与自动升级的实现方法，其特征在于：所述权限控制机制以配置模块作为应用配置的最小单位，以配置模块为单位进行权限控制，以实现最小化安全原则；遵循谁创建谁负责的原则，配置模块的创建人即是该配置模块的权限总负责人，拥有读、写、删与授权他人的权限；配置模块权限总负责人具有将配置模块的权限授予其他人的权限，没有权限的人则无法查看、修改或删除该配置模块的任何配置信息。

3.根据权利要求1所述的应用配置增量分发与自动升级的实现方法，其特征在于：所述步骤S1中，各配置模块的唯一标识由命名空间与配置模块标识名称来确定，即根据每个配置模块隶属于的层级，及其所属的版本对应的唯一的版本号来命名；每当配置信息发生变更都将产生一个新的配置版本；

所述版本号由大版本，小版本，补丁版本三个数字以圆点符分隔组成。

4.根据权利要求1所述的应用配置增量分发与自动升级的实现方法，其特征在于：所述标准CCM配置包是将配置信息抽象封装成具有统一格式与统一结构的配置包；配置补丁统一以标准CCM配置包的形式在不同的角色不同的环境之间传递；

以标准CCM配置包为基础对所有配置模块的全量版本进行出盘，在不同的角色与场景之间进行不可变的分发，在不同的环境中进行还原，实现配置信息的自动初始化；

在进行配置信息升级时，对变更的配置模块的增量版本进行备份，在需要升级的环境中，通过标准CCM配置包自动增加对应的配置模块与版本，自动修改对应部署单元对新增配置模块新版本的依赖，自动针对不同的环境进行部署配置的发布即可完成配置的自动升级变更；

通过所述标准CCM配置包实现一次配置变更，制作一次配置补丁，即可完成所有环境的配置升级；

所述标准CCM配置包中包括命名空间、模块名称、application.yaml文件和packages.yml文件，所述命名空间为配置模块所属的命名空间，同一命名空间下的配置模块放在同一个目录下，不同命名空间的配置模块放到不同的目录下；所述模块名称为配置模块的标识名称；所述application.yaml文件用于存放该配置模块对应版本的配置内容信息；所述packages.yml文件用于存放该标准CCM配置包中所有相关的配置模块，版本的基本信息及其相互依赖关系。

5.根据权利要求4所述的应用配置增量分发与自动升级的实现方法，其特征在于：提供不同环境不同部署间配置信息的隔离机制；

将环境与部署单元配置进行单独的抽象，环境与部署单元配置进行组合生成对应应用的部署配置；不同的部署单元与不同的环境结合生成针对不同环境的不同配置，同一个部署单元与开发环境结合生成开发环境配置，与测试环境结合生成测试环境的配置，与生产环境结合生成生成环境的配置；部署单元依赖的新配置模块新配置版本，在成功发布部署配置后才对应用生效；

在通过标准CCM配置包进行新配置模块新配置版本升级时，在需要升级的环境中，自动针对不同的环境进行部署配置的发布，不同环境的发布只影响该环境对应的配置，没有发布的环境仍然使用原来的配置信息，从而实现了不同环境及不同部署单元之间的配置信息相互隔离，互不影响。

6.根据权利要求5所述的应用配置增量分发与自动升级的实现方法，其特征在于：其部署场景支持单机部署模式、私有云部署模式和公有云部署模式；

S1、单机部署模式

在单机模式下，应用都是单体部署的，配置信息存放在本地磁盘文件中，将标准CCM配置包中的配置信息与本地文件中的配置信息进行合并即可；

S2、私有云部署模式

在私有云模式下，应用采用分布式集群部署，配置信息存放于配置中心，将标准CCM配置包中的配置信息与配置中心中的配置信息进行合并即可；

S3、公有云部署模式

公有云模式与私有云模式类似，应用都是分布式集群部署的，配置信息都是存放于配置中心，将标准CCM配置包中的配置信息与配置中心中的配置信息进行合并即可。

7.根据权利要求6所述的应用配置增量分发与自动升级的实现方法，其特征在于：所述单机模式实现步骤如下：

S11、开发人员通过配置管理平台的新增配置模块配置版本功能来变更配置信息，并通过备份功能来生成配置变更信息的标准CCM配置包，通过补丁工具将标准CCM配置包制作成配置补丁，并发布到补丁库；

S12、测试人员对配置补丁进行测试验证，并对补丁的测试结果进行标记；

S13、如果单机部署环境的网络是私有封闭的，实施运维人员对测试通过的补丁进行下载刻盘，将下载刻盘的补丁导入到单机环境的补丁升级客户端中；否则通过补丁升级客户端直接远程连接补丁库，直接从补丁库下载测试通过的补丁到本地环境；

S14、补丁升级客户端通过调用内嵌在单机应用系统中的配置中心服务来完成本地yaml配置文件的合并变更；

S15、重启应用服务来加载最新的配置信息。

8.根据权利要求6所述的应用配置增量分发与自动升级的实现方法，其特征在于：

所述私有云部署模式实现骤如下：

S21、开发人员通过配置管理平台的新增配置模块配置版本功能来变更配置信息，并通过备份功能来生成配置变更信息的CCM配置包，通过补丁工具将标准CCM配置包制作成配置补丁，并发布到补丁库；

S22、测试人员对配置补丁进行测试验证，并对补丁的测试结果进行标记；

S23、如果私有云环境不允许直接连接外网，则将补丁升级客户端部署在前置机上，补丁升级客户端远程连接补丁库，从补丁库下载测试通过的补丁到私有云环境；

S24、补丁升级客户端通过调用私有云环境中的配置中心服务来完成配置信息的合并变更；

S25、配置中心通过发布配置，以及结合配置中心SDK的远程推送能力使应用加载最新的配置。

9.根据权利要求6所述的应用配置增量分发与自动升级的实现方法，其特征在于：

所述公有云部署模式下，配置信息合并步骤如下：

S31、开发人员通过配置管理平台的新增配置模块配置版本功能来变更配置信息，并通过备份功能来生成配置变更信息的CCM配置包，通过补丁工具将标准CCM配置包制作成配置补丁，并发布到补丁库；

S32、测试人员对配置补丁进行测试验证，并对补丁的测试结果进行标记；

S33、补丁升级客户端远程连接补丁库，从补丁库中下载测试通过的补丁到公有云环境；

S34、补丁升级客户端通过调用公有云环境中的配置中心服务来完成配置信息的变更；

S35、配置中心通过发布配置，以及结合配置中心SDK的远程推送能力使应用加载最新的配置。

10.一种基于权利要求1～9所述的应用配置增量分发与自动升级的实现方法的装置，其特征在于：从底层向上划分为存储层，业务层与接入层；所述存储层负责数据的存储与访问，其组件包括数据库PostgreSQL与缓存Redis；所述业务层负责核心业务逻辑处理，其组件包括配置模块，配置版本，部署单元，依赖关系，环境，部署配置与权限控制；所述接入层负责系统与用户的接入，其组件包括Restful API，客户端SDK以及Web可视化界面与配置补丁管理及升级工具；

通过配置管理平台提供统一的配置服务、可视化管理界面、统一Restful API接口与客户端SDK及相关工具；

所述可视化管理界面支持配置模块与配置版本的管理、环境管理、部署单元管理和部署配置管理；

在配置模块与版本管理中对配置模块进行增、删、改、查、授权、备份、出盘和/或还原操作；对配置版本进行增、删、改、查和/或下载分层结构操作；通过依赖组合不同配置模块的不同配置版本来产生新的配置模块新的配置版本；

所述环境管理对开发、测试、演练、预发、UAT、灰度及生产的环境类型进行增、删、改和/或查操作；

所述部署单元管理对应用的部署单元以及所依赖的配置模块与配置版本进行增、删、改和/或查操作；

所述部署配置管理通过组合环境与部署单元来产生，用于针对特定环境的部署配置进行创建、提交、审核合并、发布、历史归档和/或回滚操作；

所述客户端SDK及相关工具负责实现基于标准CCM配置包的配置补丁管理以及配置补丁升级。

Images