微服务之间的数据依赖问题，你知道怎么解决吗

微服务，顾名思义，便是将我们法式拆分为最小化单位来提供服务。在一体化体系中，各个微服务也是弗成能自力存在的，那么微服务之间涉及到的数据依附问题，应该怎么处置呢。我们从场景入手来阐发斟酌此类问题。

一、场景

在一个供给链体系中，存在商品、贩卖订单、采购三个微服务，他们的主数据部门数据布局如下

数目

在设计这个供给链体系时，我们必要满意以下两个需求：

依据商品的型号/分类/天生年份/编码等查找订单；依据商品的型号/分类/天生年份/编码等查找采购订单。

初期我们的计划是如许设计的：严厉依照的微服务划分原则将商品相关的职责寄存在商品体系中。是以，在查询订单与采购单时，假如查询字段包括商品字段，我们必要依照如下次序进行查询：

先依据商品字段挪用商品的服务，然后返回匹配的商品信息；在订单或采购单中，经由过程 IN 语句匹配商品 ID，再联系关系查询对应的单据。

为了便利懂得这个进程，订单查询流程图如下图所示：

初期计划设计完后，很快我们就遇到了一系列问题：

跟着商品数目的增多，匹配的商品越来越多，于是订单服务中包括 IN 语句的查询效力越来越慢；商品作为一个焦点服务，依附它的服务越来越多，同时跟着商品数据量的增加，商品服务已不胜重负，相应速率也变慢，还存在哀求超时的环境；因为商品服务超时，相关服务处置哀求常常失败。

成果便是营业方每次查询订单或采购单时，只要带上了商品这个症结字，查询效力就会很慢并且总是失败。于是，我们从新想了一个新计划——数据冗余，下面我们一路来看下。

二、数据冗余的计划

数据冗余说白了便是在订单、采购单中保留一些商品字段信息。

为了便利懂得，我们借助上面现实营业场景详细阐明下，看看两者的区别。

临盆批次ID

调整架构计划后，每次查询时，我们就可以不再依附商品服务了。

然则，假如商品进行了更新，我们若何同步冗余的数据呢。在此分享2种办理方法。

每次更新商品时，先挪用订单与采购服务，再更新商品的冗余数据。每次更新商品时，先宣布一条新闻，订单与采购服务各自订阅这条新闻后，再各自更新商品冗余数据。

看到这里是不是感到很眼熟了呢。没错，这便是我们上一篇提到过的数据同等性问题。那么这2种计划会呈现哪些问题呢。

假如商品服务每次更新商品都要挪用订单与采购服务，然后再更新冗余数据，则会呈现以下两种问题。

数据同等性问题：假如订单与采购的冗余数据更新失败了，整个操作都必要回滚。这时商品服务的开发职员确定不愿意，由于冗余数据不是商品服务的焦点需求，不克不及由于边沿流程阻断了自身的焦点流程。依附问题：从职责来说，商品服务应该只存眷商品自己，然则如今商品还必要挪用订单与采购服务。并且，依附商品这个焦点服务的服务其实是太多了，也就导致后续商品服务每次更新商品时，都必要挪用更新订单冗余数据、更新采购冗余数据、更新门店库存冗余数据、更新运营冗余数据等一年夜堆服务。那么商品到底是下游服务照样上游服务。还能不克不及安心当底层焦点服务。

是以，第一个办理方法直接被我们反对了，即我们采取的第二个办理方法——经由过程新闻宣布订阅的计划，由于它存在如下 2 点上风。

商品无须挪用其他服务，它只必要存眷自身逻辑即可，顶多多天生一条新闻送到 MQ。假如订单、采购等服务的更新冗余数据失败了，我们使用新闻重试机制就可以了，终极能保证数据的同等性。

此时，我们的架构计划如下图所示：

这个计划看起来已经挺完善了，并且市道市情上根本也是这么做的，不外该计划存在如下几个问题。

在这个计划中，仅仅保留冗余数据还远远不够，我们还必要将商品分类与临盆批号的清单进行联系关系查询。也便是说，每个服务不但是订阅商品变革这一种新闻，还必要订阅商品分类、商品临盆批号变革等新闻。下面请注意查看订单表布局的加粗部门内容。

以上只是列举了一部门的布局，事实上，商品表中还有许多字段存在冗余，好比保修类型、包换类型等。为了更新这些冗余数据，采购服务与订单服务每每必要订阅近十种新闻，是以，我们根本上必要把商品的一小半逻辑复制过来。

每个依附的服务必要反复实现冗余数据更新同步的逻辑。前面我们讲了采购、订单及其他服务都必要依附商品数据，是以每个服务必要将冗余数据的订阅、更新逻辑做一遍，终极反复的代码就会许多。MQ 新闻类型太多了：联调时最麻烦的是 MQ 之间的联动，假如是接口联调还好说，由于挪用哪个服务器的接口相对可控并且比拟好追溯；假如是新闻联调就比拟麻烦，由于我们经常不知道某条新闻被哪台服务节点花费了，为了让特定的服务器花费特定的新闻，我们就必要暂时修改两边的代码。不外联调完成后，我们常常忘了改回原代码。

为此，我们不愿望针对冗余数据这种非焦点需求呈现如斯多的问题，终极决议使用一个分外的同步冗余数据计划，接下来我们进一步阐明。

三、解耦营业逻辑的数据同步计划

解耦营业逻辑的数据同步计划的设计思绪是如许的：

将商品及商品相关的一些表（好比分类表、临盆批号表、保修类型、包换类型等）及时同步到必要依附使用它们的服务的数据库，而且坚持表布局不变；在查询采购、订单等服务时，直接联系关系同步过来的商品相关表；不容许采购、订单等服务改动商品相关表。

此时，整个计划的架构如下图所示：

以上计划就能轻松办理如下两个问题：

商品无须依附其他服务，假如其他服务的冗余数据同步失败，它也不必要回滚自身的流程；采购、订单等服务无须存眷冗余数据的同步。

不外，该计划的“毛病”是增长了订单、采购等数据库的存储空间（由于增长了商品相关表）。

细心计算后，我们发现之前数据冗余的计划中每个订单都必要保留一份商品的冗余数据，假设订单总数是 N，商品总数是 M，而 N 一样平常远弘远于 M。是以，在之前数据冗余的计划中，N 条订单就会发生 N 条商品的冗余数据。相比之下，解耦营业逻辑的数据同步计划更省空间，由于只增长了 M 条商品的数据。

此时问题又来了，若何及时同步相关表的数据呢。我们直接找一个现成的开源中央件就可以了，不外它必要满意支撑及时同步、支撑增量同步、不消写营业逻辑、支撑 MySQL 之间同步、活跃度高这五点要求。

依据这五点要求，我们在市道市情上找了一圈，发现了 Canal、Debezium、DataX、Databus、Flinkx、Bifrost 这几款开源中央件，它们之间的区别如下表所示：

从对照表中来看，比拟切近我们需求的开源中央件是 Bifrost，缘故原由如下：

它的界面治理不错；它的架构比拟简单，呈现问题后，我们可以自行查询拜访，之后就算作者不维护了也可以自我维护，相对照较可控。作者更新活跃；自带监控报警功效。

是以，终极我们使用了 Bifrost 开源中央件，此时整个计划的架构如下图所示：

四、上线后果

整个架构计划上线后，商品数据的同步还算比拟稳固，此时商品服务的开发职员只必要存眷自身逻辑，无须再存眷使用数据的人。假如必要联系关系使用商品数据的订单，采购服务的开发职员也无须存眷商品数据的同步问题，只必要在查询时加上联系关系语句即可，实现了双赢。

然而，独一让我们担忧的是 Bifrost 不支撑集群，没法保障高可用性。不外，到今朝为止，它还没有呈现宕机的环境，反而是那些部署多台节点负载平衡的后台服务经常会呈现宕机。

终极，我们总算办理了服务之间数据依附的问题。

五、总结

这里我们探究了服务间的数据依附问题，并给出了今朝较为适宜的办理计划。实在这里提到的计划不是一个很年夜众的计划，确定会存在一些漏掉的问题没斟酌，假如你有更好的计划，迎接留言讨论。