在 前文 中，我们已经大概了解了分布式架构的产生。也提到了在分布式架构的演进中，发生的一些问题及解决方案。这里我们主要探讨其中分布式配置一块的内容。
什么是分布式配置中心
分布式配置产生的背景
在 前文 中我们了解到，分布式架构慢慢的发展，最终会发展为如下这样的架构。
这样的架构会带来什么问题呢？
- 多个用户服务的节点，都会存在一份本地配置 (application.yaml/application.properties)。这样的情况导致如果节点越来越多的话，会需要维护与节点数相同甚至更多的配置文件。
- 用户服务与商品服务可能会有一些相同的配置，如关系型数据库配置信息，非关系型数据库配置信息。但是这部分配置不能共享，只能各个服务做配置冗余。
- 如果配置需要更新，无法保证同服务的多个节点全部更新，也无法保证不同服务间冗余的配置同步更新。带来了一定的不确定性。
- 配置更新还需要重新服务，无法满足高可用的需求。
- 多环境需要维护不同的配置，但无法做到配置的隔离。
为什么需要分布式配置中心
分布式配置中心的引入，其实就是为了解决上述架构带来的分布式配置问题。
主要的优点:
- 中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
- 消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。
- 配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。
- 实现配置隔离，多环境配置也可统一管理。
- 减少开发和运维很大的工作量。
配置中心原理及实现方式
其实根据上述问题的解决我们大概知道这个分布式配置中心需要哪些要素：
- 同服务的多个节点仅需要维护一份配置 —— 配置内容中心化存储
- 服务动态扩缩 —— 持久化存储
- 应用需要从中心化配置中心获取配置 —— 提供对外 API
- 配置变更无需重新部署应用 —— 数据变化通知给客户端
- 配置中心异常时保证可用 —— 配置高可用及本地缓存
根据这些要素，我们来看看目前大多数配置中心的实现
上图中，使用 git/zookepper/mysql 等存储作为配置内容的持久化存储。通过本地缓存及配置服务器集群实现配置中心的高可用。通过定时监听服务端配置，完成数据变化的通知。这样的架构就可以完成大多分布式配置中心需要提供的功能。
总结
在本节中，主要说明了在分布式架构演进中，分布式配置中心的产生以及原理。后续会选择 alibaba nacos 作为配置中心时的使用及原理。
