详细解读消息队列解耦 _依赖

一个典型的依赖关系
这里的通知通过 RPC 来进行，下游系统需要的数据可以在这次 RPC 里携带上，也可以在请求的时候让下游系统自己去查。
下游系统增加的时候，核心业务的代码也需要修改，比如新做了一个积分系统，现在订单状态流转积分系统也想知道。
下游增加新系统时
【详细解读消息队列解耦】核心系统需要不停地增加调用关系来迎合下游新增的业务方需求。这些边边角角的计算逻辑和订单系统本身没啥关系，但是因为下游需要拿到这些数据linux消息队列使用场景，我们就需要自己用 RPC 去调用下游的接口。这确实不太合理。
当下游系统发生事故时，很容易让核心系统也跟着一起躺了：
下游炸了上游也得炸
这种情况下，核心系统对下游系统的依赖主要是因为 core，和单系统内的耦合是一样的。
解决这种耦合的最简单的方法，在单模块的情况是用依赖反转，在分布式场景下，就是引入消息队列：
用消息队列解除上游对下游的依赖
在修改之后，每次订单流转只要将event 发送到消息队列就可以了。下游系统有计算需求，自己去订阅相关的 topic 即可。
有了消息队列时下游增加新系统
讲到这里就结束，那就是童话故事了。在一开始的图中，我们存在的依赖是双向的：
双向依赖
核心系统依赖下游系统是因为调用关系，下游系统依赖核心系统是因为下游系统要使用核心系统的数据。
我们使用 MQ 只是解开了单个方向上的依赖，核心系统没有对下游系统的调用了。
这样下游系统在崩溃的时候，也就不太容易影响到核心系统的稳定性。
隐式依赖导致事故
但下游系统对核心系统的数据依赖是不可能解除的，如果核心系统修改了产生event 的代码，还是会导致下游系统出故障，很多情况下出故障都是一死死一片：
大点的互联网公司经常是核心服务一做重构，下游服务哀鸿遍野。
数据依赖对于核心系统来说并不是一个可以显式看到的依赖，所以对于核心系统来说，这是外部对我的隐式依赖。
看不见的依赖是很可怕的，所有人都会慢慢地逐渐忽视它，直到事故发生的那一天。
核心系统对下游系统重新建立依赖
虽然梦做的很好，但核心系统在服务用户的过程中，往往也是要给用户返回一些实时计算的数据的，这部分数据从哪里来?
很多就是从下游计算系统来，比如说，我的订单流转系统，现在要在用户积分达到某个条件的时候linux消息队列使用场景，做一些特殊逻辑。
随着业务的发展，我们最初解除掉的依赖，又重新被建立了。
环形依赖回来了!这下两个系统可能又会变成你挂我也挂的情况了。兜兜转转，我们重新回到了原点。
本文到此结束，希望对大家有所帮助。