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

sunnyalen

数据同步
下面讲授了数据统一性的解决计划，这一篇来说讲办事之间的数据依赖问题，仍是先来讲说详细的业务场景。
业务场景：如何解决微办事之间的数据依赖问题
在某个供给链零碎中，存在商品、定单、推销这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万条商品的数据。
那末如何实时同步相干表数据呢？请看下节讲授。
本文给大家讲授的内容是微办事进阶场景实战：数据同步
下篇文章给大家讲授的内容是微办事进阶场景实战：基于Bifrost的数据同步计划感觉文章不错的敌人能够转发此文关注小编；感激大家的反对！！

华人澳洲中文论坛

热图推荐

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

发表回复

sunnyalen
关注TA

图文推荐

华人澳洲中文论坛

热图推荐

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

发表回复

sunnyalen 关注TA

图文推荐

sunnyalen
关注TA