导读 有一个观点已经被说烂了:使用 MQ 可以帮助业务系统解耦。想法很简单,在业务状态流转时,如果没有 MQ,那么其它系统想要知道状态变了,那就需要核心流程系统去主动做通知。

有一个观点已经被说烂了:使用 MQ 可以帮助业务系统解耦。
想法很简单,在业务状态流转时,如果没有 MQ,那么其它系统想要知道状态变了,那就需要核心流程系统去主动做通知。

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

一个典型的依赖关系

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

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

下游增加新系统时

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

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

下游炸了上游也得炸

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

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

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

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

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

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

双向依赖

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

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

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

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

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

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

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

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

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

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

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

原文来自:https://mp.weixin.qq.com/s/O0KGm3nVUSWMSKwHlPiJpg?utm_source=tuicool&utm_medium=referral

本文地址:https://www.linuxprobe.com/message-queuing.html编辑:姜 一 一,审核员:逄增宝

Linux命令大全:https://www.linuxcool.com/