架构师带你搞明白微服务进阶场景实战:服务之间的数据依赖问题

简介: 数据同步上面讲解了数据一致性的解决方案,这一篇来讲讲服务之间的数据依赖问题,还是先来说说具体的业务场景。业务场景:如何解决微服务之间的数据依赖问题在某个供应链系统中,存在商品、订单、采购这3个服务,它们的主数据部分结构表如下。

数据同步

上面讲解了数据一致性的解决方案,这一篇来讲讲服务之间的数据依赖问题,还是先来说说具体的业务场景。

业务场景:如何解决微服务之间的数据依赖问题

在某个供应链系统中,存在商品、订单、采购这3个服务,它们的主数据部分结构表如下。

而在设计这个系统时,需要满足以下两点需求。

1)根据商品的型号、分类、生成年份、编码等查找订单。

2)根据商品的型号、分类、生成年份、编码等查找订单或采购单。

初期方案是这样设计的:首先,按照严格的微服务划分原则,把商品相关的职责放在商品服务中,所以在订单与采购单查询过程中,如果查询字段包含商品字段,就按照如下顺序进行查询。

1)先根据商品字段调用商品服务,然后返回匹配的商品信息。

2)在订单服务或采购服务中,通过IN语句匹配商品ID,再关联查询对应的单据。

订单的整个查询流程如图14-1所示。

• 图14-1 查询流程

初期方案设计完成后,很快就碰到了一系列问题。

1)随着商品数量的增多,匹配到的商品越来越多,于是订单和采购服务中包含IN语句的数据查询效率越来越低。

2)商品服务作为一个核心服务,依赖它的服务越来越多,同时随着商品数据量的增长,商品服务开始不堪重负,响应也变慢,还存在请求超时的情况。

3)因为商品服务超时,使得依赖它的服务处理请求也经常失败。

这就导致业务方查询订单或者采购单时,每次只要加上商品ID这个关键字,查询效率就会很低,而且经常失败,于是团队想出了一个新的方案——冗余。

数据冗余方案

数据冗余方案即在订单、采购单中保存一些商品的字段信息,具体如下。

通过这样的方案,每次查询订单或采购单时,就不需要依赖商品服务了,但是商品如果有更新,怎么同步冗余的数据呢?有两种处理办法。

1)每次更新商品时,先调用订单与采购服务,然后更新商品的冗余数据。

2)每次更新商品时,发布一条消息,订单与采购服务各自订阅这条消息,再各自更新商品的冗余数据。

前面讲解数据一致性问题时曾提到过类似的场景。

那么这两种处理办法会出现什么问题?

先说说第一种处理办法:如果商品服务每次更新商品时,都需要调用订单与采购服务,然后再更新冗余数据,则会出现以下两个问题。

1)数据一致性问题:如果订单和采购服务的冗余数据更新失败,整个操作就要回滚,商品服务的开发人员肯定不希望如此,因为冗余数据并又不是商品服务的核心需求,为什么要因为边缘流程而阻断了自身的核心流程?

2)依赖问题:从职责来说,商品服务应该关注商品本身,但是现在商品服务还需要调用订单、采购的服务。而且作为一个核心服务,依赖它的服务太多了,即后续每次商品服务更新商品时,都需要调用订单冗余数据更新、采购冗余数据更新、门店库存冗余数据更新、运营冗余数据更新等众多服务。

商品服务本意是要设计成底层服务,但是如果使用这种方案,它要依赖于很多其他服务,与原来作为底层服务的初衷相悖。因此,第一个方案直接被否决了。

下面讲第二种处理办法。通过消息发布订阅的方案有以下几点好处。

1)商品无须再调用其他服务,它只需要关注自身的逻辑,最多生成一条消息到MQ。

2)如果订单、采购等服务的冗余数据更新失败了,只需要使用消息重试机制就可以保证数据的一致性。

此时方案的架构如图14-2所示。

这样的方案已经比较完善了,而且开发人员基本都是这么做的,不过这个方案存在以下几个问题。

1)商品表的冗余数据需要更新(商品分类ID和生产批号ID)。

在这个项目中,仅仅把冗余数据进行保存远远不够,还需要将商品分类与生产批号的清单进行关联查询。也就是说,每个服务不仅要订阅商品变更一种消息,还需要订阅商品分类、商品生产批号的变更消息。

• 图14-2 基于消息订阅的数据同步方案

而且这里只是列举了一部分的结构,事实上,商品表中还有很多其他的字段是冗余的,比如保修类型、包换类型等。为了更新这些冗余数据,采购服务与订单服务往往需要订阅近10种消息,基本上要把商品的一小半逻辑复制过来。

2)每个依赖的服务需要重复实现冗余数据更新同步的逻辑。前面讲过,采购、订单及其他的服务都需要依赖商品数据,因此每个服务都需要把冗余数据的订阅、更新逻辑做一遍,最终重复代码就会很多。

3)MQ消息类型过多。联调时最麻烦的是MQ之间的联动,如果是接口联调还比较简单,因为调用服务器的接口相对可控而且比较容易追溯,但是如果是消息联调,因为经常不知道某条消息被哪台服务节点消费了,为了让特定的服务器消费特定的消息,就需要临时改动双方的代码,然而联调完成后,开发人员常常忘记把代码改回来。

因为并不希望出现这么多消息,特别是冗余数据这种非核心需求,最终项目组决定使用一个特别的同步冗余数据的方案,接下来进一步说明。

解耦业务逻辑的数据同步方案

解耦业务逻辑的数据同步方案设计思路是这样的。

1)将商品及商品相关的一些表(比如分类表、生产批号表、保修类型、包换类型等)实时同步到需要依赖和使用它们的服务的数据库,并且保持表结构不变。

2)在查询采购、订单等服务中的数据时,直接关联同步过来的商品相关表。

3)不允许采购、订单等服务修改商品相关表。

此时,整个方案架构如图14-3所示。

以上方案能轻松避免以下两个问题。

1)商品无须依赖其他服务,如果其他服务的冗余数据同步失败,它也不需要回滚自身的流程。

2)采购、订单等服务无须关注冗余数据的同步。

• 图14-3 解耦业务逻辑的数据同步方案

这个方案的缺点是增加了订单、采购等数据库的存储空间(因为增加了商品相关表)。

计算后会发现,之前数据冗余的方案中每个订单都需要保存一份商品的冗余数据,假设订单总量是1000万,商品总数是10万。如果采用之前数据冗余的方案,1000万条订单记录就要增加1000万条商品的冗余数据,相比之下,目前的方案更省空间,因为只增加了10万条商品的数据。

那么如何实时同步相关表数据呢?请看下节讲解。

本文给大家讲解的内容是微服务进阶场景实战:数据同步

  1. 下篇文章给大家讲解的内容是微服务进阶场景实战:基于Bifrost的数据同步方案
  2. 觉得文章不错的朋友可以转发此文关注小编;
  3. 感谢大家的支持!!
  4. 本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。
相关文章
|
3月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
260 0
|
3月前
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
143 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
4月前
|
关系型数据库 MySQL 分布式数据库
Super MySQL|揭秘PolarDB全异步执行架构,高并发场景性能利器
阿里云瑶池旗下的云原生数据库PolarDB MySQL版设计了基于协程的全异步执行架构,实现鉴权、事务提交、锁等待等核心逻辑的异步化执行,这是业界首个真正意义上实现全异步执行架构的MySQL数据库产品,显著提升了PolarDB MySQL的高并发处理能力,其中通用写入性能提升超过70%,长尾延迟降低60%以上。
|
4月前
|
消息中间件 存储 大数据
阿里云消息队列 Kafka 架构及典型应用场景
阿里云消息队列 Kafka 是一款基于 Apache Kafka 的分布式消息中间件,支持消息发布与订阅模型,满足微服务解耦、大数据处理及实时流数据分析需求。其通过存算分离架构优化成本与性能,提供基础版、标准版和专业版三种 Serverless 版本,分别适用于不同业务场景,最高 SLA 达 99.99%。阿里云 Kafka 还具备弹性扩容、多可用区部署、冷热数据缓存隔离等特性,并支持与 Flink、MaxCompute 等生态工具无缝集成,广泛应用于用户行为分析、数据入库等场景,显著提升数据处理效率与实时性。
|
7月前
|
消息中间件 人工智能 监控
文生图架构设计原来如此简单之分布式服务
想象一下,当成千上万的用户同时要求AI画图,如何公平高效地处理这些请求?文生图/图生图大模型的架构设计看似复杂,实则遵循简单而有效的原则:合理排队、分工明确、防患未然。
233 14
文生图架构设计原来如此简单之分布式服务
|
6月前
|
Cloud Native Serverless 流计算
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
350 12
|
8月前
|
传感器 监控 安全
智慧工地云平台的技术架构解析:微服务+Spring Cloud如何支撑海量数据?
慧工地解决方案依托AI、物联网和BIM技术,实现对施工现场的全方位、立体化管理。通过规范施工、减少安全隐患、节省人力、降低运营成本,提升工地管理的安全性、效率和精益度。该方案适用于大型建筑、基础设施、房地产开发等场景,具备微服务架构、大数据与AI分析、物联网设备联网、多端协同等创新点,推动建筑行业向数字化、智能化转型。未来将融合5G、区块链等技术,助力智慧城市建设。
361 1
|
9月前
|
人工智能 运维 监控
云卓越架构:企业稳定性架构体系和AI业务场景探秘
本次分享由阿里云智能集团公共云技术服务部上海零售技术服务高级经理路志华主讲,主题为“云卓越架构:企业稳定性架构体系和AI业务场景探秘”。内容涵盖四个部分:1) 稳定性架构设计,强调高可用、可扩展性、安全性和可维护性;2) 稳定性保障体系和应急体系的建立,确保快速响应和恢复;3) 重大活动时的稳定重宝策略,如大促或新业务上线;4) AI在企业中的应用场景,包括智能编码、知识库问答、创意广告生成等。通过这些内容,帮助企业在云计算环境中构建更加稳定和高效的架构,并探索AI技术带来的创新机会。
|
10月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
11月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
258 3