首先明确配置的概念
在讨论为什么需要一个配置中心以及如何搭建一个配置中心之前，我们需要明确配置的概念：
- 配置是独立于程序的：同一个程序会因配置的改变而改变
- 配置对于程序是只读的，程序本身无法改变自己的配置。只能依据读取到的配置来决定自己的行为
一个经典的对配置的使用便是在生产、测试环境使用不同的配置，比如不同环境会使用不同的数据库，不同的下游环境等。
背景
那么，为什么需要一个配置中心呢？
我们通常会使用配置文件、数据库的方式来存储配置，然而这些传统的方式有以下缺点：
- 不能实时更新配置
- 无法灰度发布
- 权限管理与审核机制的不完善等。
我们希望配置在之前介绍的两个概念的基础上，可以增加新的特性：
- 可以实时更新，提高研发效率
- 支持灰度发布，帮助验证配置效果
- 完善的权限管理机制，防止因改动配置而产生线上事故
基础功能实现
大多数时候，直接驱动研发选择使用配置中心的痛点便是希望可以通过实时更新配置，提高研发效率（这块的实践经验后续会单独整理一篇文章）。
实现实时更新，大概流程如下：
- 用户提交新的配置
- 配置中心通知相关机器配置更新
相关机器如何获取更新后的配置
这个问题其实就是讨论究竟应该是 配置中心 将信息推送至机器，还是机器从配置中心拉取新的配置
如果使用推模式：
- 优点：
- 实时性高：配置中心可以在配置更新后立即推送新配置到相关机器，确保所有机器几乎同时获得最新配置。
- 一致性好：在网络环境良好的情况下，推模式可以确保所有机器在同一时间点获得相同的配置，减少不一致的风险。
- 缺点：
- 复杂度高：需要维持一个连接通道，资源消耗也大。
如果使用拉模式（其实就是和推反过来）：
- 优点：
- 简单易实现：机器主动拉取配置的实现相对简单，不需要维持复杂的连接状态。
- 缺点：
- 实时性差：因为拉本质上是定时拉取，为了资源考虑，不可能每秒拉一次，所以不可避免的会有
- 一致性差：没法保证所有机器在同一时间点获得相同的配置
综上，有两种解决思路：
- 思路1：可以结合推拉两种模式。例如，配置中心推送一个更新通知，机器接收到通知后主动拉取新配置；或者，使用推模式确保关键配置的实时更新，拉模式用于定期检查其他配置。
- 思路2：在推的基础上，通过维护机器列表并用http发送请求，降低推的复杂度以及资源成本。
