服务之间通过缓存传递数据,我坚决反对!
数据的移动,需要载体,DB和cache是常见的数据存储载体。
如上图:
- service-A将数据放入cache;
- service-B从cache里读取数据;
cache作为数据存储载体的好处是:
- cache的读取和写入都非常快;
- service-A和service-B物理上解耦;
那么问题来了:
- 你遇到过这种“服务之间通过缓存传递数据”的架构设计么?
- 这种架构设计好还是不好,为什么?
关于这种架构设计方案,分享下个人的观点。
楼主支持这种架构设计么?
先说结论,楼主旗帜鲜明的反对“服务之间通过缓存传递数据”。
为什么反对呢?
核心理由有3点。
第一点:数据管道场景,MQ比cache更加适合。
如果只是单纯的将cache作为两个服务数据通讯的管道,service-A生产数据,service-B(当然,可能有service-C/service-D等)订阅数据,MQ比cache更加合适:
(1)MQ是互联网常见的逻辑解耦,物理解耦组件,支持1对1,1对多各种模式,非常成熟的数据通道;
(2)而cache反而会将service-A/B/C/D耦合在一起,大家要彼此协同约定key的格式,ip地址等;
(3)MQ能够支持push,而cache只能拉取,不实时,有时延;
(4)MQ天然支持集群,支持高可用,而cache未必;
(5)MQ能支持数据落地,cache具备将数据存在内存里,具有“易失”性,当然,有些cache支持落地,但互联网技术选型的原则是,让专业的软件干专业的事情:nginx做反向代理,db做固化,cache做缓存,mq做通道;
综上,数据管道场景,MQ比cache更加适合。
第二点:数据共管场景,两个(多个)service同时读写一个cache实例会导致耦合。
如果不是数据管道,是两个(多个)service对一个cache进行数据共管,同时读写,也是不推荐的,这些service会因为这个cache耦合在一起:
(1)大家要彼此协同约定key的格式,ip地址等,耦合;
(2)约定好同一个key,可能会产生数据覆盖,导致数据不一致;
(3)不同服务业务模式,数据量,并发量不一样,会因为一个cache相互影响,例如service-A数据量大,占用了cache的绝大部分内存,会导致service-B的热数据全部被挤出cache,导致cache失效;又例如service-A并发量高,占用了cache的绝大部分连接,会导致service-B拿不到cache的连接,从而服务异常;
综上,数据共管场景,多个service耦合在一个cache实例里,也是不推荐的,需要垂直拆分,实例解耦。
第三点:数据访问场景,两个(多个)service有读写一份数据的需求。
根据服务化的原则,数据是私有的(本质也是解耦):
(1)service层会向数据的需求方屏蔽下层存储引擎,分库,chace的复杂性;
(2)任何需求方不能绕过service读写其后端的数据;
假设有其他service要有数据获取的需求,应该通过service提供的RPC接口来访问,而不是直接读写后端的数据,无论是cache还是db。
综上所述
- 数据管道场景,MQ比cache更合适;
- 多个服务不应该公用一个cache实例,应该垂直拆分解耦;
- 服务化架构,不应该绕过service读取其后端的cache/db,而应该通过RPC接口访问;
【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】
相关文章
- 【技术种草】cdn+轻量服务器+hugo=让博客“云原生”一下
- CLB运维&运营最佳实践 ---访问日志大洞察
- vnc方式登陆服务器
- 轻松学排序算法:眼睛直观感受几种常用排序算法
- 十二个经典的大数据项目
- 为什么使用 CDN 内容分发网络?
- 大数据——大数据默认端口号列表
- Weld 1.1.5.Final,JSR-299 的框架
- JavaFX 2012:彻底开源
- 提升as3程序性能的十大要点
- 通过凸面几何学进行独立于边际的在线多类学习
- 利用行动影响的规律性和部分已知的模型进行离线强化学习
- ModelLight:基于模型的交通信号控制的元强化学习
- 浅谈Visual Source Safe项目分支
- 基于先验知识的递归卡尔曼滤波的代理人联合状态和输入估计
- 结合网络结构和非线性恢复来提高声誉评估的性能
- 最佳实践丨云开发CloudBase多环境管理实践
- TimeVAE:用于生成多变量时间序列的变异自动编码器
- 具有线性阈值激活的神经网络:结构和算法
- 内网渗透之横向移动 -- 从域外向域内进行密码喷洒攻击