MQ能不能帮消息队列解耦

本篇内容介绍了“MQ能不能帮消息队列解耦”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!

创新互联建站专业为企业提供来宾网站建设、来宾做网站、来宾网站设计、来宾网站制作等企业网站建设、网页设计与制作、来宾企业网站模板建站服务,十载来宾做网站经验,不只是建网站,更提供有价值的思路和整体网络服务。

有一个观点已经被说烂了:使用 MQ 可以帮助业务系统解耦。

想法很简单,在业务状态流转时,如果没有 MQ,那么其它系统想要知道状态变了,那就需要核心流程系统去主动做通知。

比如电商系统里订单从创建到处理中状态切换了,客服系统需要知道,风控系统需要知道,用户系统也需要知道。

MQ能不能帮消息队列解耦

一个典型的依赖关系

这里的通知通过 RPC 来进行,下游系统需要的数据可以在这次 RPC 里携带上,也可以在请求的时候让下游系统自己去查。

下游系统增加的时候,核心业务的代码也需要修改,比如新做了一个积分系统,现在订单状态流转积分系统也想知道。

MQ能不能帮消息队列解耦

下游增加新系统时

核心系统需要不停地增加调用关系来迎合下游新增的业务方需求。这些边边角角的计算逻辑和订单系统本身没啥关系,但是因为下游需要拿到这些数据,我们就需要自己用  RPC 去调用下游的接口。这确实不太合理。

当下游系统发生事故时,很容易让核心系统也跟着一起躺了:

MQ能不能帮消息队列解耦

下游炸了上游也得炸

这种情况下,核心系统对下游系统的依赖主要是因为 core system mentions downstream  system,和单系统内的耦合是一样的。

解决这种耦合的最简单的方法,在单模块的情况是用依赖反转,在分布式场景下,就是引入消息队列:

MQ能不能帮消息队列解耦

用消息队列解除上游对下游的依赖

在修改之后,每次订单流转只要将 domain event 发送到消息队列就可以了。下游系统有计算需求,自己去订阅相关的 topic 即可。

MQ能不能帮消息队列解耦

有了消息队列时下游增加新系统

讲到这里就结束,那就是童话故事了。在一开始的图中,我们存在的依赖是双向的:

MQ能不能帮消息队列解耦

双向依赖

核心系统依赖下游系统是因为调用关系,下游系统依赖核心系统是因为下游系统要使用核心系统的数据。

我们使用 MQ 只是解开了单个方向上的依赖,核心系统没有对下游系统的调用了。

这样下游系统在崩溃的时候,也就不太容易影响到核心系统的稳定性。

隐式依赖导致事故

但下游系统对核心系统的数据依赖是不可能解除的,如果核心系统修改了产生 domain event  的代码,还是会导致下游系统出故障,很多情况下出故障都是一死死一片:

大点的互联网公司经常是核心服务一做重构,下游服务哀鸿遍野。

数据依赖对于核心系统来说并不是一个可以显式看到的依赖,所以对于核心系统来说,这是外部对我的隐式依赖。

看不见的依赖是很可怕的,所有人都会慢慢地逐渐忽视它,直到事故发生的那一天。

核心系统对下游系统重新建立依赖

虽然梦做的很好,但核心系统在服务用户的过程中,往往也是要给用户返回一些实时计算的数据的,这部分数据从哪里来?

很多就是从下游计算系统来,比如说,我的订单流转系统,现在要在用户积分达到某个条件的时候,做一些特殊逻辑。

随着业务的发展,我们最初解除掉的依赖,又重新被建立了。

环形依赖回来了!这下两个系统可能又会变成你挂我也挂的情况了。兜兜转转,我们重新回到了原点。

“MQ能不能帮消息队列解耦”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!


标题名称:MQ能不能帮消息队列解耦
网页地址:http://myzitong.com/article/jjcigp.html