1、系统解耦
假设你有个系统A,这个系统A会产出一个核心数据,现在下游有系统B和系统C需要这个数据。
那简单,系统A就是直接调用系统B和系统C的接口发送数据给他们就好了。整个过程,如下图所示:
但是现在要是来了系统D、系统E、系统F、系统G,等等,十来个其他系统慢慢的都需要这份核心数据呢?如下图所示:
大家可别以为这是开玩笑,一个大规模系统,往往会拆分为几十个甚至上百个子系统,每个子系统又对应N多个服务,这些系统与系统之间有着错综复杂的关系网络。
如果某个系统产出一份核心数据,可能下游无数的其他系统都需要这份数据来实现各种业务逻辑。
此时如果你要是采取上面那种模式来设计系统架构,那么绝对你负责系统A的同学要被烦死了。
先是来一个人找他要求发送数据给一个新的系统H,系统A的同学要修改代码然后在那个代码里加入调用新系统H的流程。
一会那个系统B是个陈旧老系统要下线了,告诉系统A的同学:别给我发送数据了,接着系统A再次修改代码不再给这个系统B。
然后如果要是某个下游系统突然宕机了呢?
系统A的调用代码里是不是会抛异常?那系统A的同学会收到报警说异常了,结果他还要去care是下游哪个系统宕机了。
所以在实际的系统架构设计中,如果全部采取这种系统耦合的方式,在某些场景下绝