MQ,互联网架构解耦神器
来源:互联网 发布:淘宝店铺授权怎么弄 编辑:程序博客网 时间:2024/06/06 00:55
一个架构常识:当调用方需要关心执行结果,通常使用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调用,会引发上下游极大的耦合与瓶颈。
场景还原
有一个通用的上游服务,例如“帖子发布”服务,负责公司通用的帖子发布业务。有一些个性化的业务关心“用户发布帖子”这个事件,例如:
用户发布帖子后,大数据部门要更新用户的画像
用户发布帖子后,信息质量部门要异步检查帖子是否合规
招聘业务最近在做用户促活,如果用户发布的是招聘帖子,要增加积分
…
个性化下游关注这个事件,但下游对事件的执行结果,“帖子发布”服务却并不关心,如果“帖子发布”服务通过RPC的方式去通知下游,就会有很大的问题。
耦合为何存在?
帖子发布服务,这本来应该是一个非常基础的服务,上游upper通过RPC调用将事件同步给事件关注业务方biz1/biz2/biz3:
一旦有新的业务需求要关注这个事件,修改代码的是通用上游upper,此时通用服务的owner就在心里骂娘了“为何有需求的是你,修改代码的却是我”
一旦业务侧出问题,会影响上游通用基础服务,此时通用服务的owner又在心里骂娘了“我ca,稳定性的KPI,全被兄弟部门毁了”
一旦业务侧接口升级,上游基础服务需要配合升级,此时通用服务的owner可能又会抱怨“为何被动升级的人总是我”
架构不合理,简直痛不欲生。
如何解耦呢?
如果事件发出方不关心订阅方的执行结果,不能用RPC,应该用MQ。
MQ能够做到上下游物理上和逻辑上都解耦:
物理上解耦,增加MQ之后,上游互不知道彼此的存在,不会建立物理连接了,大家都只与MQ建立物理连接
逻辑上解耦,事件发布方甚至不用知道哪些下游订阅了这个消息,新增消息的订阅方只需要连接MQ就行了,不需要上游关注
MQ是一个非常常见的物理上解耦、逻辑上也解耦的利器。
关注下游执行执行结果,用RPC;
不关注下游执行结果,用MQ,不用RPC;
这只是一个很小的优化点,但对于通知解耦却是非常有效。
希望每天收获一点点,架构就能美好一点点。
你痛过吗,你被迫实现过本不应该你来实现的需求么?那帮转下。
- MQ,互联网架构解耦神器
- Java互联网架构-深入理解MQ实现分布式事务
- 配置中心,互联网架构解耦利器
- MQ架构设计说明
- 互联网架构
- 互联网架构
- 互联网架构
- 互联网架构
- MQ消息架构设计一(到底什么时候该使用MQ?)
- MQ > 大型网站架构分布式消息队列
- 互联网架构演变模型
- 互联网架构集结号
- 大型互联网网站架构
- 互联网基本架构
- Restful 互联网软件架构
- 大型互联网网站架构
- 大型互联网架构概述
- 大型互联网架构概述
- [leetode] 122. Best Time to Buy and Sell Stock II
- dubbo参数调优说明
- Jsp总结
- 一 冒泡排序
- py的基本数据类型 12.13
- MQ,互联网架构解耦神器
- 不浮躁,专心搞架构,写技术
- 淘淘商城笔记
- 如何让你的visual studio自动编译typescript
- elasticsearh请求体查询
- Android平台下创建与识别二维码
- macOS 安装 Consolas 字体
- SDUT-3399 数据结构实验之排序二:交换排序(冒泡+快排)
- 仿百度搜索