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

《小小的ip，大大的耦合》提到，因为'变更ip，导致上游重启一大片'的不合理架构，可以使用“内网域名代替内网ip”的方式解耦。

 

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

 

因为调用服务集群配置关联在一起，导致下游服务扩容时上游需要配合重启，是一个耦合的典型案例。

 

一、场景还原

user-service是一个下游底层通用服务，原集群有3个节点：ip1, ip2, ip3。

上游service1、service2、web1等三个上游要调用user-service。

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

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

 

历史总是惊人的相似，明明是下游扩容，为何需要上游修改配置，重启呢？

 

二、耦合如何产生的？

上游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

 

三、“配置私藏”为何导致耦合？

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

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

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

 

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

答：配置中心。

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

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

物理依赖，指物理上要建立连接，产生依赖：

• MQ解耦，上游和下游不会建立物理连接

• 配置中心解耦，上游和下游依然会建立物理连接

但很多时候，当关注下游处理结果的时候，上下游不能使用MQ通讯，而必须使用RPC（详见《MQ，互联网架构解耦神器》）。

配置中心的一些要点：

• 所有通用配置，基础配置将由配置中心统一维护，数据只存储一份，不再有“配置私藏”

• 所有上游通过配置中心来订阅下游配置

• 所有下游的配置变更，例如扩容时，通过配置中心统一修改

• 配置中心将变更后的配置通知所有上游订阅方

• 订阅方得知下游服务扩容或者缩容后，通过动态连接池，自动新增或者销毁连接，实现自动扩容与缩容，大部分服务发现都是这么做的

五、总结

A、“配置私藏”导致的耦合，本质是由一份配置数据的冗余引起的。

B、配置中心对于“配置私藏”的上下游解耦非常有效。

C、MQ和ConfCenter是常见的互联网架构解耦利器：

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

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

 

大家每天收获一点点，架构就能美好一点点。

你痛过吗，下游扩容你被迫重启过吗？那帮转下。

相关文章：

MQ，互联网架构解耦神器

一分钟实现连接池

小小的IP，大大的耦合