共计 1084 个字符，预计需要花费 3 分钟才能阅读完成。
有一个观点曾经被说烂了：应用 MQ 能够帮忙业务零碎解耦。
想法很简略，在业务状态流转时，如果没有 MQ，那么其它零碎想要晓得状态变了，那就须要外围流程零碎去被动做告诉。
比方电商零碎里订单从创立到解决中状态切换了，客服零碎须要晓得，风控系统须要晓得，用户零碎也须要晓得。
这里的告诉通过 RPC 来进行，上游零碎须要的数据能够在这次 RPC 里携带上，也能够在申请的时候让上游零碎本人去查。
上游零碎减少的时候，外围业务的代码也须要批改，比方新做了一个积分零碎，当初订单状态流转积分零碎也想晓得。
外围零碎须要不停地减少调用关系来投合上游新增的业务方需要。这些边边角角的计算逻辑和订单零碎自身没啥关系，然而因为上游须要拿到这些数据，咱们就须要本人用 RPC 去调用上游的接口。这的确不太正当。
当上游零碎产生事变时，很容易让外围零碎也跟着一起躺了：
这种状况下，外围系统对上游零碎的依赖次要是因为 core system mentions downstream system，和单零碎内的耦合是一样的。
解决这种耦合的最简略的办法，在单模块的状况是用依赖反转，在分布式场景下，就是引入音讯队列：
在批改之后，每次订单流转只有将 domain event 发送到音讯队列就能够了。上游零碎有计算需要，本人去订阅相干的 topic 即可。
讲到这里就完结，那就是童话故事了。在一开始的图中，咱们存在的依赖是双向的：
外围零碎依赖上游零碎是因为调用关系，上游零碎依赖外围零碎是因为上游零碎要应用外围零碎的数据。
咱们应用 MQ 只是解开了单个方向上的依赖，外围零碎没有对上游零碎的调用了。
这样上游零碎在解体的时候，也就不太容易影响到外围零碎的稳定性。
隐式依赖导致事变
但上游系统对外围零碎的数据依赖是不可能解除的，如果外围零碎批改了产生 domain event 的代码，还是会导致上游零碎出故障，很多状况下出故障都是一死死一片：
大点的互联网公司常常是外围服务一做重构，上游服务哀鸿遍野。
数据依赖对于外围零碎来说并不是一个能够显式看到的依赖，所以对于外围零碎来说，这是内部对我的隐式依赖。
看不见的依赖是很可怕的，所有人都会缓缓地逐步漠视它，直到事变产生的那一天。
外围系统对上游零碎从新建设依赖
尽管梦做的很好，但外围零碎在服务用户的过程中，往往也是要给用户返回一些实时计算的数据的，这部分数据从哪里来？
很多就是从上游计算零碎来，比如说，我的订单流转零碎，当初要在用户积分达到某个条件的时候，做一些非凡逻辑。
随着业务的倒退，咱们最后解除掉的依赖，又从新被建设了。
环形依赖回来了！这下两个零碎可能又会变成你挂我也挂的状况了。兜兜转转，咱们又回到了原点。
