为什么需要配置中心？
在单体服务架构的场景下，一般是将配置信息视为代码的一部分，开发人员会像编辑代码一样，编辑好配置，然后通过发布系统，将配置发布到服务程序所在的机器上，接下来，程序会通过加载本地存储的配置文件，使配置生效。在单体架构下，这种配置及代码的方法可以运行的很好，但是在分布式架构下，会产生以下问题：
- 这种方法缺乏整体的配置管理平台，会使配置管理的效率变得很低。
- 这种方法会导致实例之间的配置出现不一致的情况。
- 配置即代码的方法会使配置修改的操作，变得非常冗余和低效。
在分布式系统中，如果一个问题的影响半径超出单一服务的范围，就可以考虑通过引入一个中间层的方法来解决，即“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决”。
为了解决分布式系统中配置即代码的方式带来的问题，我们引入一个称为“配置中心”的中间层。
配置中心需要具备哪些功能？
在分布式系统的架构下，一个理想的配置中心要具备下面的特点：
- 配置中心能够统一管理分布式系统所有服务的配置信息。
- 配置中心中同一个服务实例之间的配置应该保持一致。
- 配置中心应该可以高效地修改配置。
从上面的讨论中，我们可以得出配置中心需要解决的两个关键问题：
- 统一的配置存储。一个带版本管理的存储系统，按服务的维度，存储和管理整个分布式系统的配置信息，这样可以很方便地对服务的配置信息进行搜索、查询和修改。
- 同步配置信息。所有的实例，本地都不存储配置信息，实例能够从配置中心获得服务的配置信息，在配置修改后，能够及时将最新的配置，同步给服务的每一个实例。
怎么实现配置中心？
从配置中心要解决的两个关键问题来看，我们需要选择合适的存储系统，并及时同步配置信息。
选择合适的存储系统
配置中心使用的存储系统，需要满足以下几点要求：
- 可用性要求非常高。
- 性能要求中等。
- 数据容量要求低。
- API友好程度。
同步配置信息
首先，实例刚启动的时候，主动去配置中心获取完整的配置信息，即首次同步。
然后再实例运行过程中，如果服务的配置有修改，配置中心需要及时同步到实例，即变更同步。服务的配置信息有变更后，配置中心监听到服务的配置修改了，需要及时通知到服务的所有实例。这里可以采用“发布/订阅”的模式，也可以采用轮询模式，例如每30秒去配置中心查询一下，配置是否有变更。
如何保证配置的强一致性
配置中心需要使用类似两阶段提交的方式来同步配置信息。
首先，从配置中心的存储节点中选择一个实例作为协调者A。
在投票阶段，协调者A向所有的Proxy节点发送Prepare消息，即数据迁移的配置信息，Proxy节点在收到数据迁移配置后，确认自己当前的状态是否可以执行数据迁移工作。如果可以，那么就阻塞当前节点所有的读写操作，进入Prepare状态，并回复协调者A同意执行数据迁移，否则回复不同意执行数据迁移。
在执行阶段，协调者A收集所有的Proxy节点的反馈，如果所有的Proxy都同意执行数据迁移，那么协调者A向所有的Proxy节点发送Commit消息，Proxy节点收到 Commit 消息后，就应用数据迁移的配置信息，按最新的配置信息，接受读写请求，进行数据迁移。上文的例子，就是对于数据集 2 的读写请求，都路由到节点 2 来处理，否则就发送 Rollback 消息，Proxy 节点收到后，回滚状态，重新接受读写请求。
此文章为极客时间4月份Day06学习笔记，内容来自《深入浅出分布式技术原理》课程。
