配置中心，互联网架构解耦利器

《小小的ip，大大的耦合》提到，由于"变动ip，致使上游重启一大片"的不合理架构，可使用“内网域名代替内网ip”的方式解耦。

这一次，随着流量的愈来愈大，一个服务集群由3个节点增长到5个节点，扩容增长了两个ip，竟然也要调用方修改配置，重启一大片？

由于调用服务集群配置关联在一块儿，致使下游服务扩容时上游须要配合重启，是一个耦合的典型案例。

1、场景还原

user-service是一个下游底层通用服务，原集群有3个节点：ip1, ip2, ip3。
上游service一、service二、web1等三个上游要调用user-service。

随着业务、数据量、并发的增加，user-service慢慢扛不住了，扩容新增ip4和ip5两个节点。

此时user-service的维护者，要通知全部的上游s1/s2/web1，让其协助增长两个ip节点(经过《小小的ip，大大的耦合》的描述，实际上是增长两个内网域名)，而后重启，以便于将流量导入到新的节点上去。

历史老是惊人的类似，明明是下游扩容，为什么须要上游修改配置，重启呢？

2、耦合如何产生的？

上游web1站点，通常有个独有的配置文件，假设叫web1.conf，它里面会记录web1站点相关的配置，例如：

web1.log.path : /opt/logs/web1/
web1.connection.timeout : 2000ms
web1.thread.num : 200
…

web1调用了user-service，因此web1.conf里确定也记录了user-service的相关配置：

web1.user-service.ip : ip1/ip2/ip3
web1.user-service.port : 5858

在创业初期，此类配置比比皆是，无可厚非，人称“配置私藏”。

service1和service2也都调用了这个底层的公共服务，service1.conf 和service2.conf 里也有相似的配置：

serviceX.user-service.ip : ip1/ip2/ip3
serviceX.user-service.port : 5858

3、“配置私藏”为什么致使耦合？

配置私藏，它的本质是“配置数据的扩散”。

原本下游user-service配置数据只应该存在一份，但这个配置数据扩散到不一样的上游，所私藏的配置文件里，人手一份。

这就致使，当这个配置数据发生变化时，因此私藏这份配置的上游，都须要修改配置，以保证数据一致性。

4、如何解除“配置私藏”，由于上下游调用而产生的耦合？

答：配置中心。

如上图，配置中心通常由若干个组件组成，其细节不是本文的重点，故不在此展开。

配置中心是一个典型的逻辑上解耦、物理上不解耦的一个架构优化工具（若是你们还有印象《MQ，互联网架构解耦神器》提到，MQ是一个逻辑上解耦，物理上也解耦的一个架构优化工具）。

物理依赖，指物理上要创建链接，产生依赖：

• MQ解耦，上游和下游不会创建物理链接
• 配置中心解耦，上游和下游依然会创建物理链接
  但不少时候，当关注下游处理结果的时候，上下游不能使用MQ通信，而必须使用RPC（详见《MQ，互联网架构解耦神器》）。

配置中心的一些要点：

• 全部通用配置，基础配置将由配置中心统一维护，数据只存储一份，再也不有“配置私藏”
• 全部上游经过配置中心来订阅下游配置
• 全部下游的配置变动，例如扩容时，经过配置中心统一修改
• • 配置中心将变动后的配置通知全部上游订阅方
    订阅方得知下游服务扩容或者缩容后，经过动态链接池，自动新增或者销毁链接，实现自动扩容与缩容，大部分服务发现都是这么作的

5、总结

A、“配置私藏”致使的耦合，本质是由一份配置数据的冗余引发的。
B、配置中心对于“配置私藏”的上下游解耦很是有效。
C、MQ和ConfCenter是常见的互联网架构解耦利器：

• 前者，逻辑解耦，物理解耦
• 后者，逻辑解耦，物理不解耦

你们天天收获一点点，架构就能美好一点点。
你痛过吗，下游扩容你被迫重启过吗？那帮转下。

相关文章：MQ，互联网架构解耦神器一分钟实现链接池小小的IP，大大的耦合