配置中心的原理和解决的痛点

一、解决的问题

1. 如上图，站点应用会调用服务，上游服务调用底层服务，依赖关系会变得非常复杂。 调用方如何维护下游服务集群配置？ 当服务集群增减节点时，调用方是否有感知？

二、初期 “配置私藏”架构

1. 每个上下游都有一份配置文件，记录被调用下游的每个节点配置信息 该方案的缺陷 问题一：调用方很痛，容量变化的是你，凭啥修改配置重启的是我？这是一个典型的“反向依赖”架构设计，上下游通过配置耦合，不合理。 问题二：服务方很痛，ta不知道有多少个上游调用了自己，往往只能通过以下方式来定位上游：
   1. 群里吼
   2. 发邮件询问
   3. 通过连接找到ip，通过ip问运维，找到机器负责人，再通过机器负责人找到对应调用服务

三、中期：“全局配置”架构

（1）运维层面制定规范，新建全局配置文件，例如/opt/global.conf； （2）对于服务方，如果是通用的服务，集群信息配置在global.conf里； （3）对于调用方，调用方禁止配置私藏，必须从global.conf里读取通用下游配置；
好处：
（1）如果下游容量变化，只需要修改一处配置global.conf，而不需要各个上游修改；
（2）调用方下一次重启的时候，自动迁移到扩容后的集群上来了；
（3）修改成本非常小，读取配置文件目录变了而已；
全局配置有什么不足呢？
如果调用方一直不重启，就没有办法将流量迁移到新集群上去了。

四、终版：“配置中心”架构

1. 对比“全局配置”与“配置中心”的架构图，会发现配置由静态的文件升级为动态的服务：
   （1）整个配置中心子系统由zk、conf-center服务，DB配置存储与，conf-web配置后台组成；
   （2）所有下游服务的配置，通过后台设置在配置中心里；
   （3）所有上游需要拉取配置，需要去配置中心注册，拉取下游服务配置信息（ip1/ip2/ip3）；
   （4）conf-web配置后台进行设置，新增ip4/ip5，减少ip1；
   （5）conf-center服务将变更的配置推送给已经注册关注相关配置的调用方；
   （6）结合动态连接池组件，完成自动的扩容与缩容；
   “配置中心”架构有什么好处呢？
   （1）调用方不需要再重启；
   （2）服务方从配置中心中很清楚的知道上游依赖关系，从而实施按照调用方限流；
   （3）很容易从配置中心得到全局架构依赖关系；
   “配置中心”架构有什么不足呢？
   一来，系统复杂度相对较高；
   二来，对配置中心的可靠性要求较高，一处挂全局挂。

究竟要解决什么痛点？
上游痛：扩容的是下游，改配置重启的是上游；
下游痛：不知道谁依赖于自己；
总之，难以实施服务治理。

究竟如何解决上述痛点？
一、“配置私藏”架构；
二、“全局配置文件”架构；
三、“配置中心”架构；