关于配置中心，左耳朵耗子同学写了一整篇完整的博客：https://time.geekbang.org/column/article/5819
个人觉得这个博客写得并不完整，很多地方没有交代清楚，主要背景，问题和解决方案，和自己的博客质量差的有点远。他的博客是酷壳：https://coolshell.cn/
这个博客对于解决方案介绍的很多，但是忽略了很多背景介绍，所以很遗憾，如果读者没有经历过类似的事情，是没办法去顺利阅读的，而且最重要的是这个系列文章太全面了，以至于没办法单独拆解。
所以他对自己的著书是有所怀疑的。包括最近质量下降略大的，吴军的书，态度，在整体性和连贯性上远远不如之前的《浪潮之巅》，《文明之光》，《数学之美》。
整体的判断这个时代是快餐时代，质量是有很明显的下降的。
我们来认真理解下，陈皓前辈对这个配置中心的理解。
这里我的理解是：
先介绍下我对配置的理解，再说下陈皓前辈说的配置的理解。
按照陈皓的介绍，配置的数据结构大概如下：
A，系统配置：硬件类型，os类型，配置key，配置值，系统环境类型（线上/测试）【核心点：配置就是key-value结构，其它都是辅助信息】
B，平台配置（基础docker镜像）：docker-基础镜像id，docker镜像名称，docker配置key，docker配置value【这里指的是基础的docker镜像，不涉及具体的项目信息；并且配置结构也是key-value】
C，项目docker配置（项目docker镜像）：docker-镜像-名称，docker-镜像-Version，docker配置key，docker配置value
【这里指的是项目docker镜像，docker-镜像-名称每次升级保持不变，docker-镜像-version和业务镜像相关，每次升级会修改，docker配置结构也是key-value】
D，项目静态配置：项目名称，项目版本，项目配置key，项目配置value
【这里指的是项目本身，项目名称每次升级保持不变，项目版本每次升级都会有变动，项目配置是key-value结构】
E，项目动态态配置：项目名称，项目版本，项目配置key，项目配置value
【这里指的是项目本身，项目名称每次升级保持不变，项目版本每次升级都会有变动，项目配置是key-value结构】
静态配置和动态配置的区别是：比如对于java项目而言，java程序启动时注入的参数是静态参数，java运行期间，会依时间或者环境不同而有所不同的属于动态配置（活动开关，动能开关，日志开关-这里的日志级别有可能会有调整）。
A，B，C，D，E这个是有层次的，不是所有的项目都需要关心这么多，可以依自己的项目和背景来忽略某些维度的点，这样便于我们来理解配置中心的核心（太多了有点不方便我们去理解）。
比如我的系统没有依赖docker，则可以忽略BC层，比如我的项目是运行在PHP，而不是JAVA上，就不用区分D和E了。
那我们忽略掉docker，忽略掉java之后，还剩什么？只剩A，E项了
再来看以上的内容，会发现少很多了。以上内容对于开发人员都已经很熟悉了，所以以上内容可以精简为一个细节：关注自己项目的内部依赖和外部依赖。
内部依赖是和项目紧密相关的，外部依赖的资源项是需要和特定资源相关的。这些特定资源需要整理成模板（因为其他项目很可能有用到，没办法只和某一个项目相关。这个时候模板就是一个很关键的概念，通过模板ID，可以让多个项目和该模板关联起来，通过修改一处即可下达到所有相关的项目）。
原文内容：
我们来理解下这上面的内容，看到理解的就直接过掉就好，这个系列通病就是语义不是独立的，是一句话会有多次多处表达，很不条理。
这个章节我重点关注到：
A，需要有个版本管理，来记录每次的配置修改；
原文内容：部署架构
这里有个重点：
A，配置中心仅管通知，后续的流程由 《配置变更控制器》来负责调度和处理，包括load最新配置，run环境，reload相关服务。解耦要做好；
B，配置中心必须要实现推拉模式，pull-push，方便客户端使用，及其服务端控制；
原文内容：应用的配置更新如何完成？
这里解释下，应用服务的配置如何更新，要考虑到不同的语言下如何完成？而不是单一的语言。
给出来的方案有：
1，通过一个统一的client来处理（或者统一框架，或者提供sdk），这里需要讨论是有些配置我可以滞后，有些配置我必须实时更新，对于可允许滞后的配置，关系不大；对于必须实时更新的配置，需要client设置下自己配置的更新API，方便实时通知；
2，应用方提供配置更新时，要执行的脚本，当配置更新时要执行一段应用相关的脚本，这个依赖于脚本的实现，会考验到开发工程师的水平；
3，为每个应用提供agent，这个agent是一个服务，配置更新时会通知到该agent（因为是配置中心提供的agent，相对而言稳定性好很多），该agent仅负责处理自己的部分（配置更新），而不关心应用的其它部分，agent来保证应用层能够拿到实时更新的配置；
原文内容：设计重点
这里我没学到更多，仅了解到一个点，需要考虑到版本回退（在应用软件升级失败时，在应用回滚的同时，要同时触发配置的回滚，这块是有要特别注意的）。