Nacos学习笔记 （2）配置管理

1. 什么是配置中心

1.1 什么是配置

应用程序在启动和运行的时候往往需要读取一些配置信息，配置基本上伴随着应用程序的整个生命周期，比如：数据库连接参数、启动参数等。

配置主要有以下几个特点：

（1）配置是独立于程序的只读变量

配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置

（2）配置伴随应用的整个生命周期

配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。

比如：启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。

（3）配置可以有多种加载方式

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

（4）配置需要治理

同一份程序在不同的环境（开发，测试，生产）、不同的集群（如不同的数据中心）经常需要有不同的配置，所以需要有完善的环境、集群配置管理 。

1.2 什么是配置中心

在微服务架构中，当系统从一个单体应用，被拆分成分布式系统上一个个服务节点后，配置文件也必须跟着迁移（分割），这样配置就分散了，不仅如此，分散中还包含着冗余，如下图：

 下图显示了配置中心的功能，配置中心将配置从各应用中剥离出来，对配置进行统一管理，应用自身不需要自己去管理配置。

配置中心的服务流程如下：

1. 用户在配置中心更新配置信息。
2. 服务A和服务B及时得到配置更新通知，从配置中心获取配置。

总得来说，配置中心就是一种统一管理各种应用配置的基础服务组件。

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

总结一下，在传统巨型单体应用纷纷转向细粒度微服务架构的历史进程中，配置中心是微服务化不可缺少的一个系 统组件，在这种背景下中心化的配置服务即配置中心应运而生，一个合格的配置中心需要满足如下特性：

• 配置项容易读取和修改
• 分布式环境下应用配置的可管理性，即提供远程管理配置的能力
• 支持对配置的修改的检视以把控风险
• 可以查看配置修改的历史记录
• 不同部署环境下应用配置的隔离性

2. 主流配置中心对比

目前市面上用的比较多的配置中心有： Spring Cloud Confifig 、 Apollo 、 Nacos 和 Disconf 等。

由于 Disconf 不再维护，下面主要对比一下 Spring Cloud Confifig 、 Apollo 和 Nacos。

对比项目	Spring Cloud Confifig	Apollo	Nacos
配置实时推送	支持 (Spring Cloud Bus)	支持 (HTTP 长轮询 1s 内 )	支持 (HTTP 长轮询 1s 内 )
版本管理	支持 (Git)	支持	支持
配置回滚	支持 (Git)	支持	支持
灰度发布	支持	支持	不支持
权限管理	支持 ( 依赖 Git)	支持	不支持
多集群	支持	支持	支持
多环境	支持	支持	支持
监听查询	支持	支持	支持
多语言	只支持 Java	主流语言，提供了 Open API	主流语言，提供了 Open API
配置格式校验	不支持	支持	支持
单机读 (QPS)	7( 限流所致 )	9000	15000
单击写 (QPS)	5( 限流所致 )	1100	1800
3 节点读 (QPS)	21( 限流所致 )	27000	45000
3 节点写 (QPS)	5( 限流所致 )	3300	5600

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

综合来看， Nacos 的特点和优势还是比较明显的，下面我们一起进入 Nacos 的世界。