文章目录
为什么需要
一般应用的配置管理非常简单，和应用一同部署的有一份配置文件，例如SpringBoot项目resources文件夹下的yml文件
name:xiaowang
age:18
- java:100
- python:60
如果想要修改配置内容，就需要修改配置文件后重启项目，一旦服务器个数增加，这种方式将变得很低效，所以配置中心的一个重要功能就是属性分发
如果有一个业务开关，需要控制业务功能的开启或关闭，与其使用静态文件做配置，不如使用一个配置中心来实现属性变更的实时推送
比如可以给某个服务器开启业务开关来验证业务——金丝雀测试，同时还可以对一些特定服务器，把属性变更推送过去——蓝绿测试
比如有一个订单服务，从开始编写需求到最后上线，通常会经过很多个环境的验证（日常、预发、线上），需要对每个环境指定一个配置文件，resource文件夹下就会列出各个资源文件，实际上并没有实现一个很好的隔离，因为配置文件和业务逻辑是紧密联系在一起的，如果能将他们部署在一个相对集中化的中心区域里，统一管理这些配置文件，就可以做到职责隔离
如果还有另一个商品服务，就需要从服务层面做隔离，需要明确哪些配置文件属于订单服务，哪些属于商品服务，因此配置中心一共有三个需求点：
- 配置业务隔离：将配置业务从代码里隔离出来
- 环境隔离：业务代码层并不需要关心自己当前部署的环境，通过配置中心对不同配置项做隔离
- 服务隔离：配置中心需要识别哪些配置属于哪些服务
配置中心高可用实现方案
何为高可用？
假定在业务中的任何一环都不可靠，然后通过增加一些中间环节来提高总体可用性
避免单点
假设有一个服务，它的配置项从一个配置中心获取并保存在本地，如果这个配置中心发生故障，服务的配置文件就无法获取。
- 做backup最简单的方式就是集群化，集群化方案有：多副本、主从、集群等，所以配置中心首先要看是否支持集群扩展的能力
- 配置中心需要提供故障转移能力，服务治理方案会更天然地趋向于微服务的价值观
配置中心里的服务治理：
可以使用注册中心的能力，将配置中心作为一种服务来管理起来。即配置中心将自己当做一种服务注册到注册中心里，下游应用从注册中心里获取配置中心的可用服务器节点，之后再从配置中心里拉取数据
多数据副本
配置中心通常不保存配置数据，而是保存在其他介质里（外部文件系统、github、数据库），配置中心可以在本地保存一个文件备份，防止存储介质无法访问时带来的问题。
本地文件保存上次从存储介质里获取到的内容
使用类似思想设计的还有全局id发号器，为了保证可用性，全局发号器每次都是一次申请一段区间的id，之后把它们缓存在本地，慢慢分发，有以下几个优点：
- 不需要频繁从数据源中申请号段
- 可以在数据源失效时仍保持正常工作