配置中心的作用是什么?如何选型?¶
典型回答¶
配置中心,顾名思义,就是放配置的。他可以集中化帮我们做配置的管理,包括增删改查操作。
在一个web应用中,常见的配置有很多,包括:
- 应用元数据
- 应用名、版本号等基础信息
- 环境相关配置
- 如dev、prod等,用于区分是日常环境还是线上环境
- 中间件相关配置
- 数据库、Redis等的url、username、password等
- 业务开发/策略配置
- 比较常见的就是一些切流比例、灰度比例、业务功能开发、限流阈值等
- 安全敏感信息
- 一般是密钥相关的配置
- 第三方服务配置
- 要用到第三方服务的时候,比如短信服务、OSS存储服务,都需要做一些相关key、url、bucket等的配置。
- 运行时调优参数
- 一些需要在运行期动态调整的参数,比如线程池大小、重试次数、超时时间等。
- 日志与监控配置
- 通常是一些日志级别、采样率等信息
在有配置中心中之前,上面的这些配置信息我们都是放到代码中硬编码或者放到本地的配置文件中的。但是这样做有个缺点,那就是每一次需要修改配置的时候,都需要重新拉分支、改代码、走发布流程。太麻烦了。
所以,我们可以用一个集中化的存储来存放这些配置,这就是配置中心,他解决了用本地配置文件存在的在动态性、一致性、安全性、可维护性等方面的不足等问题。
配置中心有很多方案,他有几个基本功能是必备的,包括配置管理、动态变化感知、稳定性等。常见的方案有以下几个:
| 选型方案 | Nacos | Apollo | Spring Cloud Config | Consul | ZooKeeper |
|---|---|---|---|---|---|
| 配置管理 | 强 | 强 | 依赖 Git | 弱(KV 存储) | 弱(临时节点为主) |
| 动态刷新 | 长轮询/gRPC | HTTP 长轮询 | 需配合 Bus + RabbitMQ/Kafka | Watch 机制 | Watch机制 |
| 多环境支持 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| 权限控制 | 支持鉴权模式 | 完善 | 无 | 基于ACL | 基于ACL |
| 图形界面 | 有 | 有 | 无 | 有 | 无 |
一般推荐用Nacos或者Apollo来做配置中心,他们是专门做配置中心的,同时还提供了图形化界面可以直接做配置操作。而且背靠大厂,生态也会更好一些。
扩展知识¶
哪些配置适合放到配置中心¶
上面我们提了好多配置信息,但是并不是所有的都适合放到配置中心的。配置中心中建议放可能变化、需要动态生效、多服务共享的配置。
这里多提一句,很多人会说关于多环境的配置也适合放配置中心,包括AI也这么说。但是其实多环境的实现,spring的配置文件本身也支持了。
通过创建
application-{profile}.properties或application-{profile}.yml文件,并在主配置文件或启动时指定spring.profiles.active属性来激活,实现不同环境(开发、测试、生产)的配置分离与切换,支持命令行、环境变量或 IDE 方式指定。
所以,有些只是和环境不同的配置,比如数据库连接的URL、password这些,或者是OSS的地址,bucket这些, 个人认为他们基本不怎么需要改,完全可以放到配置文件中就够了。duck不必放到配置中心。
针对前面列的那些配置,我认为应该这么选择:
| 配置类型 | 放在哪? |
|---|---|
| 应用元信息 | 配置文件 |
| 环境相关配置 | 配置文件 |
| 中间件相关配置 | 配置文件 |
| 安全敏感信息 | 配置文件 |
| 第三方服务依赖 | 配置文件 |
| 业务开关/策略 | 配置中心 |
| 运行时调优参数 | 配置中心 |
| 日志/监控采样策略 | 配置中心 |
以上,这是一种最佳实践,就是把动态配置和静态配置区分开。但是实际操作中,很多公司会为了省事,所有配置都放到配置中心上,本地的配置文件啥都不放,我也见过的。。。怎么说呢,不理解,但尊重。