微服务拆分后的数据依赖问题-对于数据集成同步和实时跨库查询的选择思考

今天我准备跟大家聊一下，在微服务拆分以后跨微服务之间的数据依赖问题，怎么样去做解决。在去年的时候，我就专门录过一个视频讲怎么样去实现微服务拆分以后的跨库查询。

对于微服务拆分以后，我们一般都在强调微服务对应的底层的数据库也做了拆分，所以说一定会去出现跨微服务的数据依赖的问题。

我们举一个简单的例子，你现在有一个订单微服务，有一个物料的微服务，同时还有一个采购应用的前端应用，那么一定会出现一个采购订单查看的这么一个简单功能。特别是在明细的时候，你查采购订单明细，一定会看到采购订单的编号、采购订单的名称，订单明细里面涉及到物料的编号、物料的名称、物料的类型、订购的数据。但是基于数据库的三范式设计，你实际的订单明细表里面只有物料ID信息，那么你要去看到完整的订单明细，一定是涉及到订单明细表和物料表之间要去做相应的数据表之间的关联查询才能够完成。

在原来我数据库没拆分的时候，这个事情就很简单，只是一个数据库的关联SQL语句就能够解决问题，但是拆分以后这个事情就变麻烦了，那么在这种情况下面，我们究竟应该还是去采用传统的底层的数据库的数据集成同步，还是实时用实时查不要再去做数据的多点落地。

对于数据的集成同步很简单，也就是说我的物料微服务，只要新增变更了任何的物料信息，我都同步一份到我的订单微服务对应的数据库里面，这样一定是带来了相应的数据冗余的问题，在数据冗余以后一定会带来数据的延迟、数据的不一致。

但是好处也是显而易见，就是说订单微服务、物料微服务对应的数据库，包括整个微服务，如果出现宕机，你不会对我的订单微服务，包括上层的订单应用造成任何影响。也就是说我能够更好去做好订单微服务和物料微服务两个模块之间的这么一个解耦。但是这个事情并不是微服务架构下面推荐的一个方式，在微服务架构下面我们更推荐的是类似于通过消息中间件，通过CQRS命令职责查询分离这么一些方式来做两个微服务之间的一个解耦。

但是你可能同时也要问，就是我有一些操作本来就是涉及到两个微服务实时查询的组合操作，那么这种事情怎么样去解决呢？

也就是我们经常说的，你需要同时调用订单微服务和物料微服务提供的API接口，拿到两个数据集以后在应用的前端去做API接口的组合和数据的集成整合这么一个操作。那这个时候你可能又会问，我前端有订单的应用，也有合同的应用，也有库存的应用，我前端有很多的应用，可能都会涉及到查订单信息，那是不是我所有的前端应用都要去做这种底层API接口的组合，这个事情不就变得越来越麻烦了吗？

构建跨微服务的领域服务层进行API组合

所以在整个的微服务架构里面，我一直的理解就是在底层的微服务上层，还有一个我们叫领域组合服务层，领域组合服务层也可以是一个独立的微服务模块，它提供组合API接口的能力，也就是说我原来各个前端应用都要去做的API接口组合这个事情，我统一的在领域层这个地方去做相应的组合整合就可以了。只做一次，这是一种方式。

第二种方式就是说你领域组合做这个事情，你也会觉得要去做跨库查询、要去做API接口返回的多个数据集的整合比较麻烦。那在微服务架构下面还有一种方式，就是我原来讲的你的物料数据可能要多点同步，在多个微服务对应的后台的数据库去做数据落地，那这个多点同步这个事情我能不能变成只做一次同步，上层的微服务应用都共享这个同步以后的数据？

我说到这个地方，大家可能就已经想到跟我原来讲的数据中台的概念就很类似了。

构建分布式统一ODS查询库

也就是说涉及到即时共享的数据，我不要去做多点同步了，我所有的东西都同步到数据中台统一的ODS库里面。在做简单的清洗整合以后，那这个数据中台的ODS库，它一定已经是满足了你要去做关联SQL查询的所有的数据表数据记录的要求的。所以通过这个共享的ODS层，你可以很方便的提供出类似于采购订单的明细查询的这种组合的API接口，而且也不存在跨库查询的这一些事情，这个也是值得推荐的一个方法。

所以简单总结一下，就是在微服务架构拆分以后如何去更好解决数据依赖的问题。首先明确的反对一个方法，就是仍然像传统单体架构下面，你把同一个数据在多个微服务中心之间去做数据集成同步。在反对这个以后，我们形成了两种方法，第一种方法就叫我们去建独立的领域组合层，通过领域组合层提供这种组合API接口服务的能力，这是第一种方式。第二种方式就是从多点同步转变到单点的数据集成同步，构建一个统一共享的数据中台的ODS层，由ODS层提供共享的数据服务能力。

好了，今天的简单分享就到这个地方，希望对大家有所启发。