why 配置： 工程师往往无法预知可能发生的全部情况，因此可能产生变更的地方免去直接的代码修改而进行配置预留。
3.1 本地配置
在集中式系统架构的单机应用时代，配置大多通过属性文件的形式存储，以key = value的形式出现。XML，yaml, applicationContext.xml,但是
这些配置其实也属于代码部分，真正可以动态修改的配置应该是简单的、易于理解的、易于修改的。
在单机时代，配置文件就够用了。运维工程师如果想修改配置，登录生产机器，用VIM本文编辑，然后重启应用，或者用定时任务从新加载配置文件就可以生效。
3.2 配置集中化
服务器增加导致运维工作量增加，分布式系统很难使用本地配置。采用集中化的方式，也就是散落在每台服务器上运维操作集中于一点统一处理，然后程序通过远程通信或异步消息分发到各个服务器。对系统配置进行修改是运维工程师的重要工作之一，所以对配置进行统一管理是大势所趋。
配置中心： 集中管理各个系统配置服务。
分布式系统中，很多集中式系统无需关注的配置项也浮出水面，如限流、降级、灰度开关,数据源容灾的准备切换，负载均衡的路由策略等，
线程池和连接池的容量配置。
限流： 是指需要限制并发/请求量的场景（如秒杀等）。
降级：是指当服务暂时不可用或者影响到核心流程时，需要待高峰或者问题解决后再打开，（比如用户评论）。
灰度/金丝雀：
集中式配置存在的问题：
- 配置工作量大；
- 配置修改遗漏，导致各个节点配置环境不一致；
- 各个节点配置不一致的时间差长（各个服务器操作时间不同）；
- 配置修改无法动态生效（定时重新加载或重启应用）；
- 直接修改配置文本信息产生错误难于校验；
配置中心能解决上述问题，还能提供额外的便利：
- 配置工作量少，单点修改，全局生效；
- 配置修改不容易遗漏；
- 各个节点配置不一致的时间差比较短；
- 配置信息可以像业务数据一样被持久化保存，方便恢复，方便搭建环境，方便最终修改历史；
- 多个系统上线时，配置检查、沟通协调容易；
- 配置信息放置于应用程序之外，更容易保持应用的无状态化，为容器化和微服务化部署方案提供了强有力的支持。
3.3 配置中心和注册中心
配置中心和注册中心不同。注册中心用于分布式系统的服务治理，多用于管理运行在当前集群中的服务的状态，随时动态更新。
3.4 读性能
缺点：远程调用导致性能下降；
配置中心的单点访问能力以及单点故障；
解决方案： 缓存。
集中式缓存：配置信息读远大于写。每次读取磁盘影响性能，缓存到内存。
优点是：能访问最新的数据，数据一致性好，提升访问效率；
缺点：没有缓解配置中心的访问压力。
本地缓存：客户端缓存，尽量访问本地，只有在配置发生变化的时候才读配置中心，更新缓存。
优点是： 减少远程调用，提升访问效率，缓解了配置中心压力。缺点是数据存在多份，可能不一致。
（补充：缓存击穿(缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导 致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞)，缓存还有可能降低效率；
缓存预热：
缓存基于一个事实，原则： 二-八原则。 ）
3.5 变更实时性
如果使用本地缓存，数据就会存在多个副本，配置中心数据发生变更时，如果将配置信息实时通知给应用客户端。
业内两种方式：监听和实时同步。
监听：配置中心的客户端都需要与配置中心建立长连接。配置变化时，配置变化了，主动推送各个客户端，客户端更新缓存。
优点是：实时性高；
缺点是： 长连接比较消耗系统资源。并且长连接一旦断了，还要从新连接，容错等。
保持长连接有效的方法是：心跳监听服务，一旦发现连接不可用则销毁连接建立新连接。为了保证应用客户端能正确接收到信息变更请求，也需要让客户端给予反馈，不反馈就一直发。客户端要实现幂等性（在应答式通信系统中，可能存存在多发请求的情况； 比如kafka重复消费数据）。
实时同步：客户端主动定时去询问配置中心。如果发现缓存和配置中心不一致，就更新缓存。这样使用短连接就可以。
优点：节省连接资源，降低服务中心的压力。
缺点是：间隔时间长，则配置更新不及时；间隔时间短，则配置中心压力过大，并且做很多无用功。
其他的方法还有设置缓存失效时间。
3.6 可用性
3.7 数据一致性