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

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

小小的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站点相关的配置,例如:

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

web1调用了user-service,所以web1.conf里肯定也记录了user-service的相关配置:

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

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

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

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

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

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

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

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

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

答:配置中心。

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

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

物理依赖,指物理上要建立连接,产生依赖:

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

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

配置中心的一些要点:

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

五、总结

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

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

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

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

【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2017-12-26 15:52:31

MQ互联网耦合

2021-08-27 08:44:52

MQ架构耦合

2019-12-26 07:39:36

互联网架构ip

2015-08-24 10:34:21

云数据中心互联网架构安全

2022-06-09 08:01:43

秒杀系统互联网架构

2017-01-11 21:40:03

互联网架构高并发

2016-09-22 15:01:59

微服务互联网架构

2019-11-28 16:09:29

架构模板存储

2019-04-10 14:10:02

高并发分布式系统架构

2019-03-18 07:08:53

高可用互联网架构分布式

2019-05-13 10:30:34

互联网架构容量

2016-12-06 11:56:13

互联网架构高可用

2016-09-22 15:55:39

互联网架构容量设计

2018-11-07 06:35:50

互联网服务化高可用架构

2012-09-19 15:43:21

云时代

2024-05-13 11:43:26

开发层服务层ActiveMQ

2019-06-13 14:24:40

互联网

2019-07-30 09:08:04

2019-12-31 10:08:35

架构模式软件

2017-05-19 10:01:53

互联网
点赞
收藏

51CTO技术栈公众号