首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >为什么说,MQ,是互联网架构的解耦神器?

为什么说,MQ,是互联网架构的解耦神器?

作者头像
架构师之路
发布2021-09-07 15:09:09
4750
发布2021-09-07 15:09:09
举报
文章被收录于专栏:架构师之路架构师之路

什么是耦合?

耦合,是架构中,本来不相干的代码、模块、服务、系统因为某些原因联系在一起,各自独立性差,影响则相互影响,变动则相互变动的一种架构状态。

感官上,怎么发现系统中的耦合?

作为技术人,每每在心中骂上下游,骂兄弟部门,“这个东西跟我有什么关系?为什么需要我来配合做这个事情?”。明明不应该联动,却要被动配合,就可能有潜在的耦合。

今天一起来看一个,用错RPC的耦合场景。

一个架构常识:当调用方需要关心执行结果,通常使用RPC调用。

ret = PassportService::userAuth(name, pass);

switch(ret){

case(YES) : return YesHTML();

case(NO) : return NoHTML();

case(JUMP) : return 304HTML():

default : return 500HTML();

}

上一篇《明明服务化了,为啥耦合更加严重了?》提到,执行结果的处理和业务强相关,则switch case应该放在上游业务方,而不应该放到底层通用服务。

登录页面调用passport服务,会根据passport服务的返回结果,区别执行登录成功,登录失败,执行错误。调用方关注执行结果时,不宜使用MQ通讯。

如果强行使用MQ通讯,调用方不能直接告之用户登录成功又或失败,阻塞住等待MQ通知回调不但使得编码复杂,还会引入消息丢失的风险,中间多加入一层,多此一举,基本没有人这么玩。

但如果调用方不关心执行结果,却仍然使用RPC调用,会引发上下游极大的耦合与瓶颈。

场景还原

有一个通用的上游服务,例如“帖子发布”服务,负责公司通用的帖子发布业务。有一些个性化的业务关心“用户发布帖子”这个事件,例如:

(1)用户发布帖子后,大数据部门要更新用户的画像;

(2)用户发布帖子后,信息质量部门要异步检查帖子是否合规;

(3)招聘业务最近在做用户促活,如果用户发布的是招聘帖子,要增加积分;

(4)…

个性化下游关注这个事件,但下游对事件的执行结果,“帖子发布”服务却并不关心,如果“帖子发布”服务通过RPC的方式去通知下游,就会有很大的问题。

耦合为何存在?

帖子发布服务,这本来应该是一个非常基础的服务,上游upper通过RPC调用将事件同步给事件关注业务方biz1/biz2/biz3:

(1)一旦有新的业务需求要关注这个事件,修改代码的是通用上游upper,此时通用服务的owner就在心里骂娘了“为何有需求的是你,修改代码的却是我”;

(2)一旦业务侧出问题,会影响上游通用基础服务,此时通用服务的owner又在心里骂娘了“我ca,稳定性的KPI,全被兄弟部门毁了”;

(3)一旦业务侧接口升级,上游基础服务需要配合升级,此时通用服务的owner可能又会抱怨“为何被动升级的人总是我”;

架构不合理,简直痛不欲生。

如何解耦呢?

如果事件发出方不关心订阅方的执行结果,不能用RPC,应该用MQ。

MQ能够做到上下游物理上逻辑上都解耦:

(1)物理上解耦,增加MQ之后,上游互不知道彼此的存在,不会建立物理连接了,大家都只与MQ建立物理连接;

(2)逻辑上解耦,事件发布方甚至不用知道哪些下游订阅了这个消息,新增消息的订阅方只需要连接MQ就行了,不需要上游关注;

MQ是一个非常常见的物理上解耦、逻辑上也解耦的利器。

关注下游执行执行结果,用RPC。

不关注下游执行结果,用MQ,不用RPC。

这只是一个很小的优化点,但对于通知解耦却是非常有效。

希望每天收获一点点,架构就能美好一点点。

调研

你被迫实现过本不应该你来实现的需求么?

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-08-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 架构师之路 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档