一、为什么需要配置中心

随着程序功能的日益复杂，程序的配置日益增多（各种功能的开关、参数的配置、服务器的地址……），对程序配置的期望值也越来越高（配置修改后实时生效，灰度发布，分环境、分集群管理配置，完善的权限、审核机制……），在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求

1、传统应用配置的问题

• 配置散乱，格式不标准

当前应用到底有哪些配置？配置在哪里？配置格式有哪些？

• 配置修改麻烦，周期长

当部署的服务器很多时，修改配置费时费力。

• 配置修改不实时

本地静态配置导致在运行时无法动态修改。

• 容易引发生产事故

发布的时候容易将非生产的配置带到生产上，引发事故。

• 配置信息缺少安全审计和版本控制功能

事后无法追溯，谁改的？改了什么？什么时候改的？当出现问题时无法及时回滚。

2、现代交付需求

现代研发进入了一个新的时代-云原生（Cloud Native），云原生主要包含两个方面新的趋势，一个是微服务，另一个是容器化技术。
容器化有个特点叫不可变基础设施，就是说镜像打出来后就是一份，不管是部署到测试还是生产都是一份镜像，不像原来的打包方式为不同的环境打不同的包。这个时候现代的交付又提出了一些新的要求。

现代配置核心需求

现代交付-配置核心需求

• 交付件和配置分离：现代大部分都会采用容器的方式交付，容器是不可变的，不能为每个环境都制作一个容器镜像，那容器和配置就要分开；
• 抽象标准化：配置的格式用户不用关心，配置中心统一管理，配置的接口和客户端由配置中心统一提供，用户只需要对接就可以；
• 集中式：集中式的统一配置中心，不是每个业务团队都去搞一套；
• 高可用：配置中心要求高可用，不能随便挂掉，所以的微服务都依赖配置中心；
• 实时性：我们希望配置在修改后能够实时通知到客户端；
• 治理：配置需要治理，主要包括权限的审计，权限控制，谁在什么时间点修改了什么配置，支持回退，还要支持灰度发布的能力；

二、什么是配置中心

1、什么是配置

1.1、配置的定义

• 独立于程序的只读变量

DB Connection Str、Thread Pool Size、Buffer Size、Request Timeout、Feature Switch、Server Urls等。

• 可以有多种加载方式

程序内部hard code，配置文件，环境变量，启动参数，基于数据库等。

• 伴随应用的整个生命周期

启动时读取配置，运行时根据配置调整行为 。

• 需要治理

权限控制、发布审核；不同环境、集群配置管理。

1.2、配置的分类

静态配置：

• 环境相关：数据库/中间件/其它服务的连接字符串；
• 安全配置：用户名，密码，令牌，许可证书等；

动态配置：

• 应用配置：请求超时，线程池，队列，缓存，数据库连接池的容量，日志级别，限流熔断阈值，黑白名单；
• 业务配置：促销规则，贷款额度，利率等业务参数，A/B测试；
• 功能开关：蓝绿发布，灰度开关，降级开关，HA高可用开关，DB迁移；

2、什么是配置中心

有治理能力的配置统一管理平台

• 统一管理不同环境、不同集群的配置
• 配置修改实时生效（热发布）
• 版本发布管理
• 灰度发布
• 权限管理、发布审核、操作审计

3、常见应用场景

3.1、应用配置

3.2、服务治理

3.3、特性开关

3.4、安全审核