服务配置中心概念及使用场景

# 一、为什么要进行统一配置管理

为了避免参数变化引起的频繁的程序改动，通常我们在应用程序中将常用的一些系统参数、启动参数、数据库参数等等写到配置文件或其他的存储介质里面。

传统应用程序的配置分散，导致了在进行部署、运维方面，需要极大的成本。那么传统的应用程序配置面临哪些问题？ 问题一：应用程序多实例集群部署，每个微小的配置的修改将导致每个实例都需要重新打包部署

问题二：每一套环境的配置不同，难于维护，增加了人工犯错的几率

问题三：没有严格的配置管理权限控制，导致公司的核心数据泄露 不知道大家有没有看过一条报道，国外某著名的公司，在开源代码的数据库连接配置中，携带了其"生产环境"的数据库配置信息，导致其核心的用户数据泄露。

除了上面的三点，还有很多传统的配置管理方式面临的问题，所以我们要进行集中的统一的配置管理。这点在微服务应用中体现的更为明显。

比起“分布式配置中心”这个词，我更喜欢集中的配置管理中心叫做“统一配置管理中心”。“分布式”修饰的是应用程序，而“统一”才是修饰配置管理中心的关键词。但是大家都叫分布式配置管理中心，我也就从了大家。但是在理解上要区分过来。

理想的配置管理中心应该是：

配置中心将配置从应用中剥离出来，统一管理，优雅的解决了配置的动态变更、持久化、运维成本等问题。应用自身既不需要去添加管理配置接口，也不需要自己去实现配置的持久化，更不需要引入“定时任务”以便降低运维成本。总得来说，配置中心就是一种统一管理各种应用配置的基础服务组件。

在系统架构中，配置中心是整个微服务基础架构体系中的一个组件，如下图，它的功能看上去并不起眼，无非就是配置的管理和存取，但它是整个微服务架构中不可或缺的一环。

目前市面上用的比较多的配置中心有：

2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。

2016年5月，携程开源的配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现。

如果你希望完成单纯的分布式配置集中管理，其实三者都能满足你的需求。
如果你考虑到已经用Nacos实现了服务注册中心，不想单独搞出来一个配置管理中心，合二为一的话，nacoos可能是你的最佳选择
携程的Apollo与nacos很多相似之处，有颇多的亮点。从笔者的使用感受而言，目前apollo从文档细节到方便度要好于nacos（截止2020年4月）。但是nacos毕竟开源时间较短，依托alibaba的支持，有很大的潜力和发展空间。
spring cloud config对比其他两者，在功能以及友好度方面都逊色。唯一的优点可能是它比较轻量级。

对比项目/配置中心	spring cloudconfig	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异步通知

上次更新: 2022/06/13, 18:30:58