Spring Cloud Nacos

原来所有配置文件都在工程中集成，（spring.properties文件）

解决痛点

1. 水平扩容，多个实例原始配置相同。如果需要修改某一个配置，则会需要登陆到每一个实例节点去修改配置。修改复杂

2. 修改配置之后，需要重启服务，才能使配置修改生效

解决方法

配置统一维护在某个微服务节点上。当水平扩容时，所有实例节点均从配置节点上获取配置（配置统一管理）

有前台界面对配置进行管理（配置修改），配置修改后，实例节点需要从配置中心进行拉去最新配置，并使得配置生效（热配置）

服务启动过程

1. 服务启动时，从远程同步配置

2. 配置中心有配置修改

3. 配置中心将配置同步到服务上（长轮询获取配置更新）

配置中心的需求

1. 可视化的配置维护

2. 高可用集群

3. 数据的存储（持久化机制）

4. 配置中心本身的安全性 （鉴权）-

5. 配置变更的动态同步（push或者pull）

---

常用配置中心

1. Zookeeper

2. Etcd

3. Disconf

4. Nacos

5. Apollo

6. Consul

7. Spring Cloud Config

设计组件的两大目标

1. 本身就是为了某个特定功能设计的中间件（例如：Eureka专门为了服务注册而设计）（为了某种能力而设计中间件）

2. 其他的中间件，具备可以实现当前特定需求的能力（例如Zookeeper，分布式协调中心，但也可以作为注册中心，和注册中心）（某种中间键具有某种功能）

Nacos --> 前身是Diamond

1. 服务注册与发现

2. 配置管理