当前位置：首页 > news >正文

主流配置中心对比

news 2025/8/28 13:39:46

一、为什么需要配置中心：

在没有配置中心之前，传统应用配置的存在以下痛点：

（1）采用本地静态配置，无法保证实时性：修改配置不灵活且需要经过较长的测试发布周期，无法尽快通知到客户端，还有些配置对实时性要求很高，比方说主备切换配置或者碰上故障需要修改配置，这时通过传统的静态配置或者重新发布的方式去配置，那么响应速度是非常慢的，业务风险非常大
（2）易引发生产事故：比如在发布的时候，容易将测试环境的配置带到生产上，引发生产事故。
（3）配置散乱且格式不标准：有的用properties格式，有的用xml格式，还有的存DB，团队倾向自造轮子，做法五花八门。
（4）配置缺乏安全审计、版本控制、配置权限控制功能：谁？在什么时间？修改了什么配置？无从追溯，出了问题也无法及时回滚到上一个版本；无法对配置的变更发布进行认证授权，所有人都能修改和发布配置。

而配置中心区别于传统的配置信息分散到系统各个角落的方式，对系统中的配置文件进行集中统一管理，而不需要逐一对单个的服务器进行管理。那这样做有什么好处呢？

（1）通过配置中心，可以使得配置标准化、格式统一化
（2）当配置信息发生变动时，修改实时生效，无需要重新重启服务器，就能够自动感知相应的变化，并将新的变化统一发送到相应程序上，快速响应变化。比方说某个功能只是针对某个地区用户，还有某个功能只在大促的时段开放，使用配置中心后只需要相关人员在配置中心动态去调整参数，就基本上可以实时或准实时去调整相关对应的业务。
（3）通过审计功能还可以追溯问题

二、统一配置管理的基本介绍

在单体应用中，配置管理可能不是什么大的事情，通常会以配置文件的方式。常见的方法比如将配置通过打包脚本打入应用包中，或者直接放到运行应用的服务器的特定目录下，或者存储到数据库中。这种方式在传统的单体应用中简单有效，但是也会有些比较棘手的问题，比如：

配置变化频繁时，需要频繁的打包部署应用。
不同环境的配置需要分开管理（比如测试环境与生产环境）。
而在分布式微服务架构中，服务数量剧增，如果还是手动去实现配置信息的修改或数据的迁移等，效率是很低的，而且手动操作配置也极有可能出现错误的情况

复杂的业务对应大量的配置项，对集群部署的应用配置进行修改时需要修改每个节点上的应用配置，在这种背景下，中心化的配置服务即配置中心应运而生。配置中心就是一种统一管理各种应用配置的基础服务组件，配置中心可以把业务开发者从复杂以及繁琐的配置中解脱出来，只需专注于业务代码本身，从而能够显著提升开发以及运维效率。同时将配置和发布包解藕也进一步提升发布的成功率，并为运维的细力度管控、应急处理等提供强有力的支持。

在微服务架构中，微服务的统一配置管理一般有以下需求：

集中管理配置：一个使用微服务架构的应用系统可能会包括成千上万个微服务，因此集中管理配置是非常有必要的。
不同环境不同配置：例如，数据源配置在不同的环境（开发、测试、预发布、生产等）中是不同的。
运行期间可动态调整：例如，可根据各个微服务的负载情况，动态调整数据源连接池大小或熔断阈值，并且在调整配置时不重启微服务。
配置修改后自动更新：如配置内容发生变化，微服务能够自动更新配置。

综上所述，对于微服务架构而言，一个通用的配置管理机制必不可少，常见做法是使用配置服务器管理配置。

三、常见配置中心对比

目前市面上用的比较多的配置中心有：Spring Cloud Config、Apollo、Nacos和Disconf等，下面主要对比一下Spring Cloud Config、Apollo和Nacos。

Spring Cloud Config: https://github.com/spring-cloud/spring-cloud-config
Apollo: https://github.com/ctripcorp/apollo
Nacos: https://github.com/alibaba/nacos

对比项目/配置中心	spring cloud config	apollo	nacos(重点)
开源时间	2014.9	2016.5	2018.6
配置实时推送	弱支持（Spring Cloud Bus）	支持（HTTP长轮询1s内）	支持（HTTP长轮询1s内）
版本管理	支持（Git）	自动管理	自动管理
配置回滚	弱支持（Git+Bus）	支持	支持
配置的灰度发布	理念上支持，可操作性不强	支持	1.1.0开始支持
权限管理	不支持（没有区分用户、角色、权限的概念）	支持	1.2.0开始支持
多集群多环境	对集群概念支持较弱	支持	支持
多语言	只支持Java	Go,C++,Python,Java,.net,OpenAPI	Python,Java,Nodejs,OpenAPI
分布式高可用最小集群数量	Config-Server2+Git+MQ	Config2+Admin3+Portal*2+Mysql=8	Nacos*3+MySql=4
配置格式校验	不支持	支持	支持
通信协议	HTTP和AMQP	HTTP	HTTP
数据一致性	Git保证数据一致性，Config-Server从Git读取数据	数据库模拟消息队列，Apollo定时读消息	HTTP异步通知

从配置中心角度来看，性能方面Nacos的读写性能最高，Apollo次之，Spring Cloud Config依赖Git场景不适合开放的大规模自动化运维API。功能方面Apollo最为完善，nacos具有Apollo大部分配置管理功能，而Spring Cloud Config不带运维管理界面，需要自行开发。Nacos的一大优势是整合了注册中心、配置中心功能，部署和操作相比Apollo都要直观简单，因此它简化了架构复杂度，并减轻运维及部署工作。

综合来看，Nacos的特点和优势还是比较明显的。

选择哪一个配置中心呢?

如果希望利用Nacos提供的服务注册中心功能，可以考虑Nacos
看公司技术选型

四、Apollo总体设计

　　官方文档：https://github.com/ctripcorp/apollo/wiki/Apollo配置中心设计

上图简要描述了 Apollo 的总体设计，我们可以从下往上看：

Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端（我们自己的微服务应用）
Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口
Client通过域名访问Meta Server获取Config Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Client侧会做load balance、错误重试
Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重试
为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中