大促的三大法宝是：弹性，限流，降级。系统的限流和降级本质是讲从日常的运行状态切换到大促态的一个动态调整，这个本身天然就是一个配置起到作用的一个相应场景。
配置中心的关键是SLA。配置中心的SLA讲究的是推送，如果修改了配置中心文件，那么推送到1000台机器上的延时一般在3秒以内是ok的。
配置中心技术决策的第三点是灰度：有些配置中心文件就像开关一样，按下去可能不会有别的特殊事情，但是有些开关对于公司可能是核武器，就像全局路由规则，全局的限流规则，也就是在发布时候在先把配置文件推到几台机器上看看，要给业务方这种能力，这种灰度能力应该要跟线上业务能力是解耦的，需要动态的修改系统行为能力，也就是配置中心在支持业务本身的灰度发布之外也要支持配置的单独发布能力。
配置中心集中管理，之前单体运用时代，一个配置中心在改变之后往往是有运维人员来进行操作，但是目前趋于微服务时代，配置中心可以有系统的开发人员集中管理。
docker给大家的一个承诺是镜像，到处运行，就像Java承诺一样，如果仔细审视应用程序，你会发现配置这个东西不行，它是一个强环境属性，就是每个环境都有自己的值。
服务配置的一致性原则，当基于微服务的架构起来之后，所有的业务系统都依赖配置中心，可能数据的所有机器都与配置中心的数据有关，如果只选一个存储，可能无法解决支持这么大量的读操作，所以还是配置中心需要设计一个可横向扩展的缓存集群设置，并且各个缓存节点上的快速的配置值达成一个一致的状态，然后把需要配置中心的服务开放成一个service。
客户端缓存，有一种模式是agent模式，他会在每个业务机器上都有一个自己的agent，业务的进程和agent之间要么通过进程间通信，要么通过一个标准的目录，通过本地文件来做配置变更的消费，配置中心看客户端和服务端之间，除了我们常见的拉取模式，配置中心一定要实现推的模式，可以用http2.0 ,long polling websocket 但是推的模型一定要有，因为配置有了变更之后，你是要推送到业务方的，一般的配置中心也是一个PUB-SUB系统 ，那他跟消息系统有什么区别的，消息系统是一个消息消费完了，会从消息服务器上删掉了，但是配置可能存在3 5年 配置变更消费完 配置还在。业界也是近年开始逐渐进行配置中心的实践，业界的现状也是在从配置文件逐渐转向中心化的管理配置，然后逐渐发展到不再是以文件的思路去管理配置。
