本篇内容介绍了“MQ能不能帮消息队列解耦”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
有一个观点已经被说烂了：使用 MQ 可以帮助业务系统解耦。
想法很简单，在业务状态流转时，如果没有 MQ，那么其它系统想要知道状态变了，那就需要核心流程系统去主动做通知。
比如电商系统里订单从创建到处理中状态切换了，客服系统需要知道，风控系统需要知道，用户系统也需要知道。
这里的通知通过 RPC 来进行，下游系统需要的数据可以在这次 RPC 里携带上，也可以在请求的时候让下游系统自己去查。
下游系统增加的时候，核心业务的代码也需要修改，比如新做了一个积分系统，现在订单状态流转积分系统也想知道。
核心系统需要不停地增加调用关系来迎合下游新增的业务方需求。这些边边角角的计算逻辑和订单系统本身没啥关系，但是因为下游需要拿到这些数据，我们就需要自己用 RPC 去调用下游的接口。这确实不太合理。
当下游系统发生事故时，很容易让核心系统也跟着一起躺了：
这种情况下，核心系统对下游系统的依赖主要是因为 core system mentions downstream system，和单系统内的耦合是一样的。
解决这种耦合的最简单的方法，在单模块的情况是用依赖反转，在分布式场景下，就是引入消息队列：
在修改之后，每次订单流转只要将 domain event 发送到消息队列就可以了。下游系统有计算需求，自己去订阅相关的 topic 即可。
讲到这里就结束，那就是童话故事了。在一开始的图中，我们存在的依赖是双向的：
核心系统依赖下游系统是因为调用关系，下游系统依赖核心系统是因为下游系统要使用核心系统的数据。
我们使用 MQ 只是解开了单个方向上的依赖，核心系统没有对下游系统的调用了。
这样下游系统在崩溃的时候，也就不太容易影响到核心系统的稳定性。
但下游系统对核心系统的数据依赖是不可能解除的，如果核心系统修改了产生 domain event 的代码，还是会导致下游系统出故障，很多情况下出故障都是一死死一片：
大点的互联网公司经常是核心服务一做重构，下游服务哀鸿遍野。
数据依赖对于核心系统来说并不是一个可以显式看到的依赖，所以对于核心系统来说，这是外部对我的隐式依赖。
看不见的依赖是很可怕的，所有人都会慢慢地逐渐忽视它，直到事故发生的那一天。
虽然梦做的很好，但核心系统在服务用户的过程中，往往也是要给用户返回一些实时计算的数据的，这部分数据从哪里来?
很多就是从下游计算系统来，比如说，我的订单流转系统，现在要在用户积分达到某个条件的时候，做一些特殊逻辑。
随着业务的发展，我们最初解除掉的依赖，又重新被建立了。
环形依赖回来了!这下两个系统可能又会变成你挂我也挂的情况了。兜兜转转，我们重新回到了原点。
“MQ能不能帮消息队列解耦”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
