大家好，我是砸锅。一个摸鱼八年的后端开发。熟悉 Go、Lua。今天和大家一起学习分布式技术😊
开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 17 天，点击查看活动详情
配置中心
配置中心的背景
随着单体服务拆分为更多的服务，管理系统配置的效率越来越低，而且容易出现配置问题导致的故障。因为在单体服务的时候，配置信息会视为代码的一部分，然后通过发布系统将配置发布到程序所在的机器上，程序再加载本地存储的配置文件，但是这种方式在分布式系统里会存在问题：
- 缺乏整体的配置管理平台，使配置管理的效率变得很低。在分布式系统里，配置文件会出现在不同的代码仓库，当我们需要检索和查看多个服务的配置时，需要在一个个代码仓库里查找，效率会很低
- 实例之间的配置容易出现不一致。例如多个实例需要改某一个配置，用单体服务那种手工编辑发布的方式，每次只能一个个改，容易造成实例之间的行为不一致性的情况，出现各种问题
- 配置即代码的方式使配置修改的操作，变得非常冗余和低效。每次都需要重复寻找-编辑-发布-加载的过程，除了改配置文件和发布配置文件是必须的，其他流程和配置修改都无关
配置中心需要具备的功能
- 统一的配置存储：一个带版本管理的存储系统，按服务的维度，存储和管理整个分布式系统的配置信息，这样可以很方便地对服务的配置信息，进行搜索、查询和修改。
- 配置信息的同步：所有的实例，本地都不存储配置信息，实例能够从配置中心获得服务的配置信息，在配置修改后，能够及时将最新的配置，同步给服务的每一个实例
如何实现配置中心
合适的存储系统
- 可用性要求非常高。一旦配置中心出现问题，整个分布式系统都将出现严重问题
- 性能要求中等。随着分布式系统的实例数量增多，性能要求也会提高
- 数据容量要求低。配置中心只存储服务的配置信息，不需要太大存储空间
- API 友好。能够很好地支持配置中心场景的 “发布 / 订阅” 模式，将服务的配置信息及时同步到服务的实例
配置信息的同步
首次同步是实例刚启动的时候，主动去配置中心获取完整的配置信息。后续服务的配置有修改，配置中心需要及时同步到实例
确保配置的强一致性
配置中心和服务实例之间的配置同步是最终一致性，如果有一些业务场景需要同一个服务的多个实例之间的配置信息同时生效，这时候需要确保配置信息的强一致性。其实这个是一个共识问题，需要所有实例都对配置达成共识之后，才可以工作
所以配置信息不能直接通过网络同步，而是需要通过类似两阶段提交的方式来解决这个问题。在配置中心的存储节点里选择一个实例作为协调者，协调者会向所有实例节点发送 Prepare 信息，如果实例收到信息之后确认可以执行，就会阻塞当前节点所有读写操作，进入 Prepare 状态并回复协调者同意，否则回复不同意。如果所有的实例都同意了，则协调者会向所有实例节点发送 Commit 消息，实例节点收到之后就会应用配置信息，开始工作
此文章为2月Day12学习笔记，内容来源于极客时间《深入浅出分布式技术原理》
