《服务通过缓存传递数据,是否可行》一文引发一个服务之间“通过缓存传递数据”设计合理性的讨论。
如上图:
这种架构设计好还是不好,网友进行了激烈的讨论,感兴趣的同学可以看下《服务通过缓存传递数据,是否可行》的评论,看到这么多互联网技术人对一个技术方案问题进行思考与探讨,很是开心。这里,分享下个人的观点。
先说结论
楼主旗帜鲜明的反对“服务之间通过缓存传递数据”。
核心理由
一、数据管道场景,MQ比cache更加适合
如果只是单纯的将cache作为两个服务数据通讯的管道,service-A生产数据,service-B(当然,可能有service-C/service-D等)订阅数据,MQ比cache更加合适:
画外音:详见《MQ,互联网架构解耦神器》
综上,数据管道场景,MQ比cache更加适合。
二、数据共管场景,两个(多个)service同时读写一个cache实例会导致耦合
如果不是数据管道,是两个(多个)service对一个cache进行数据共管,同时读写,也是不推荐的,这些service会因为这个cache耦合在一起:
综上,数据共管场景,多个service耦合在一个cache实例里,也是不推荐的,需要垂直拆分,实例解耦。
三、数据访问场景,两个(多个)service有读写一份数据的需求
根据服务化的原则,数据是私有的(本质也是解耦):
假设有其他service要有数据获取的需求,应该通过service提供的RPC接口来访问,而不是直接读写后端的数据,无论是cache还是db。
综上
希望逻辑是清晰的,供大伙参考,欢迎不同的声音共同探讨。