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

数据同步

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

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

在某个供应链系统中，存在商品、订单、采购这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万条商品的数据。

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