数据同步
上面讲解了数据一致性的解决方案,这一篇来讲讲服务之间的数据依赖问题,还是先来说说具体的业务场景。
业务场景:如何解决微服务之间的数据依赖问题
在某个供应链系统中,存在商品、订单、采购这3个服务,它们的主数据部分结构表如下。
![](https://i-blog.csdnimg.cn/blog_migrate/74615dcf5d304e6b6dbbd1c389ffa21c.png)
而在设计这个系统时,需要满足以下两点需求。
1)根据商品的型号、分类、生成年份、编码等查找订单。
2)根据商品的型号、分类、生成年份、编码等查找订单或采购单。
初期方案是这样设计的:首先,按照严格的微服务划分原则,把商品相关的职责放在商品服务中,所以在订单与采购单查询过程中,如果查询字段包含商品字段,就按照如下顺序进行查询。
1)先根据商品字段调用商品服务,然后返回匹配的商品信息。
2)在订单服务或采购服务中,通过IN语句匹配商品ID,再关联查询对应的单据。
订单的整个查询流程如图14-1所示。
![](https://i-blog.csdnimg.cn/blog_migrate/0e4e7fcc5b4abcb60b6ea08bd21ae5d8.png)
• 图14-1 查询流程
初期方案设计完成后,很快就碰到了一系列问题。
1)随着商品数量的增多,匹配到的商品越来越多,于是订单和采购服务中包含IN语句的数据查询效率越来越低。
2)商品服务作为一个核心服务,依赖它的服务越来越多,同时随着商品数据量的增长,商品服务开始不堪重负,响应也变慢,还存在请求超时的情况。
3)因为商品服务超时,使得依赖它的服务处理请求也经常失败。
这就导致业务方查询订单或者采购单时,每次只要加上商品ID这个关键字,查询效率就会很低,而且经常失败,于是团队想出了一个新的方案——冗余。
数据冗余方案
数据冗余方案即在订单、采购单中保存一些商品的字段信息,具体如下。
![](https://i-blog.csdnimg.cn/blog_migrate/00a165eb5a11bc621b497aef2aff96dd.png)
通过这样的方案,每次查询订单或采购单时,就不需要依赖商品服务了,但是商品如果有更新,怎么同步冗余的数据呢?有两种处理办法。
1)每次更新商品时,先调用订单与采购服务,然后更新商品的冗余数据。
2)每次更新商品时,发布一条消息,订单与采购服务各自订阅这条消息,再各自更新商品的冗余数据。
前面讲解数据一致性问题时曾提到过类似的场景。
那么这两种处理办法会出现什么问题?
先说说第一种处理办法:如果商品服务每次更新商品时,都需要调用订单与采购服务,然后再更新冗余数据,则会出现以下两个问题。
1)数据一致性问题:如果订单和采购服务的冗余数据更新失败,整个操作就要回滚,商品服务的开发人员肯定不希望如此,因为冗余数据并又不是商品服务的核心需求,为什么要因为边缘流程而阻断了自身的核心流程?
2)依赖问题:从职责来说,商品服务应该关注商品本身,但是现在商品服务还需要调用订单、采购的服务。而且作为一个核心服务,依赖它的服务太多了,即后续每次商品服务更新商品时,都需要调用订单冗余数据更新、采购冗余数据更新、门店库存冗余数据更新、运营冗余数据更新等众多服务。
商品服务本意是要设计成底层服务,但是如果使用这种方案,它要依赖于很多其他服务,与原来作为底层服务的初衷相悖。因此,第一个方案直接被否决了。
下面讲第二种处理办法。通过消息发布订阅的方案有以下几点好处。
1)商品无须再调用其他服务,它只需要关注自身的逻辑,最多生成一条消息到MQ。
2)如果订单、采购等服务的冗余数据更新失败了,只需要使用消息重试机制就可以保证数据的一致性。
此时方案的架构如图14-2所示。
这样的方案已经比较完善了,而且开发人员基本都是这么做的,不过这个方案存在以下几个问题。
1)商品表的冗余数据需要更新(商品分类ID和生产批号ID)。
在这个项目中,仅仅把冗余数据进行保存远远不够,还需要将商品分类与生产批号的清单进行关联查询。也就是说,每个服务不仅要订阅商品变更一种消息,还需要订阅商品分类、商品生产批号的变更消息。
![](https://i-blog.csdnimg.cn/blog_migrate/98b497e57401da6cfdc87c64884fdcc6.png)
• 图14-2 基于消息订阅的数据同步方案
而且这里只是列举了一部分的结构,事实上,商品表中还有很多其他的字段是冗余的,比如保修类型、包换类型等。为了更新这些冗余数据,采购服务与订单服务往往需要订阅近10种消息,基本上要把商品的一小半逻辑复制过来。
2)每个依赖的服务需要重复实现冗余数据更新同步的逻辑。前面讲过,采购、订单及其他的服务都需要依赖商品数据,因此每个服务都需要把冗余数据的订阅、更新逻辑做一遍,最终重复代码就会很多。
3)MQ消息类型过多。联调时最麻烦的是MQ之间的联动,如果是接口联调还比较简单,因为调用服务器的接口相对可控而且比较容易追溯,但是如果是消息联调,因为经常不知道某条消息被哪台服务节点消费了,为了让特定的服务器消费特定的消息,就需要临时改动双方的代码,然而联调完成后,开发人员常常忘记把代码改回来。
因为并不希望出现这么多消息,特别是冗余数据这种非核心需求,最终项目组决定使用一个特别的同步冗余数据的方案,接下来进一步说明。
解耦业务逻辑的数据同步方案
解耦业务逻辑的数据同步方案设计思路是这样的。
1)将商品及商品相关的一些表(比如分类表、生产批号表、保修类型、包换类型等)实时同步到需要依赖和使用它们的服务的数据库,并且保持表结构不变。
2)在查询采购、订单等服务中的数据时,直接关联同步过来的商品相关表。
3)不允许采购、订单等服务修改商品相关表。
此时,整个方案架构如图14-3所示。
以上方案能轻松避免以下两个问题。
1)商品无须依赖其他服务,如果其他服务的冗余数据同步失败,它也不需要回滚自身的流程。
2)采购、订单等服务无须关注冗余数据的同步。
![](https://i-blog.csdnimg.cn/blog_migrate/1442ac7fc74deabe2d23233e60584713.png)
• 图14-3 解耦业务逻辑的数据同步方案
这个方案的缺点是增加了订单、采购等数据库的存储空间(因为增加了商品相关表)。
计算后会发现,之前数据冗余的方案中每个订单都需要保存一份商品的冗余数据,假设订单总量是1000万,商品总数是10万。如果采用之前数据冗余的方案,1000万条订单记录就要增加1000万条商品的冗余数据,相比之下,目前的方案更省空间,因为只增加了10万条商品的数据。
那么如何实时同步相关表数据呢?请看下节讲解。
本文给大家讲解的内容是微服务进阶场景实战:数据同步
资源获取:
大家 点赞、收藏、关注、评论啦 、 查看 👇🏻 👇🏻 👇🏻 微信公众号获取联系方式 👇🏻 👇🏻 👇🏻
精彩专栏推荐订阅:在 下方专栏 👇🏻 👇🏻 👇🏻 👇🏻
每天学四小时:Java+Spring+JVM+分布式高并发,架构师指日可待