文档参考：书名：《从程序员到架构师：大数据量、缓存、高并发、微服务、多团队协同等核心场景实战》-王伟杰
前文如下：
1.业务场景：如何解决微服务之间的数据依赖问题
在某个供应链系统中，存在商品、订单、采购这3个服务，它们的主数据部分结构表如下。
而在设计这个系统时，需要满足以下两点需求。
1）根据商品的型号、分类、生成年份、编码等查找订单。
2）根据商品的型号、分类、生成年份、编码等查找订单或采购单。
初期方案是这样设计的：首先，按照严格的微服务划分原则，把商品相关的职责放在商品服务中，所以在订单与采购单查询过程中，如果查询字段包含商品字段，就按照如下顺序进行查询。
1）先根据商品字段调用商品服务，然后返回匹配的商品信息。
2）在订单服务或采购服务中，通过IN语句匹配商品ID，再关联查询对应的单据。
初期方案设计完成后，很快就碰到了一系列问题。
1）随着商品数量的增多，匹配到的商品越来越多，于是订单和采购服务中包含IN语句的数据查询效率越来越低。
2）商品服务作为一个核心服务，依赖它的服务越来越多，同时随着商品数据量的增长，商品服务开始不堪重负，响应也变慢，还存在请求超时的情况。
3）因为商品服务超时，使得依赖它的服务处理请求也经常失败。这就导致业务方查询订单或者采购单时，每次只要加上商品ID这个关键字，查询效率就会很低，而且经常失败，于是团队想出了一个新的方案——冗余。
2. 数据冗余方案
通过这样的方案，每次查询订单或采购单时，就不需要依赖商品服务了，但是商品如果有更新，怎么同步冗余的数据呢？有两种处理办法。
1）每次更新商品时，先调用订单与采购服务，然后更新商品的冗余数据。
2）每次更新商品时，发布一条消息，订单与采购服务各自订阅这条消息，再各自更新商品的冗余数据。
那么这两种处理办法会出现什么问题？
先说说第一种处理办法：如果商品服务每次更新商品时，都需要调用订单与采购服务，然后再更新冗余数据，则会出现以下两个问题。
1）数据一致性问题：如果订单和采购服务的冗余数据更新失败，整个操作就要回滚，商品服务的开发人员肯定不希望如此，因为冗余数据并又不是商品服务的核心需求，为什么要因为边缘流程而阻断了自身的核心流程？
2）依赖问题：从职责来说，商品服务应该关注商品本身，但是现在商品服务还需要调用订单、采购的服务。而且作为一个核心服务，依赖它的服务太多了，即后续每次商品服务更新商品时，都需要调用订单冗余数据更新、采购冗余数据更新、门店库存冗余数据更新、运营冗余数据更新等众多服务。
商品服务本意是要设计成底层服务，但是如果使用这种方案，它要依赖于很多其他服务，与原来作为底层服务的初衷相悖。因此，第一个方案直接被否决了。
下面讲第二种处理办法。通过消息发布订阅的方案有以下几点好处。
1）商品无须再调用其他服务，它只需要关注自身的逻辑，最多生成一条消息到MQ。
2）如果订单、采购等服务的冗余数据更新失败了，只需要使用消息重试机制就可以保证数据的一致性。 此时方案的架构如图14-2所示。
1）商品表的冗余数据需要更新（商品分类ID和生产批号ID）。 在这个项目中，仅仅把冗余数据进行保存远远不够，还需要将商品分类与生产批号的清单进行关联查询。也就是说，每个服务不仅要订阅商品变更一种消息，还需要订阅商品分类、商品生产批号的变更消息。
而且这里只是列举了一部分的结构，事实上，商品表中还有很多其他的字段是冗余的，比如保修类型、包换类型等。为了更新这些冗余数据，采购服务与订单服务往往需要订阅近10种消息，基本上要把商品的一小半逻辑复制过来。
2）每个依赖的服务需要重复实现冗余数据更新同步的逻辑。前面讲过，采购、订单及其他的服务都需要依赖商品数据，因此每个服务都需要把冗余数据的订阅、更新逻辑做一遍，最终重复代码就会很多。
3）MQ消息类型过多。联调时最麻烦的是MQ之间的联动，如果是接口联调还比较简单，因为调用服务器的接口相对可控而且比较容易追溯，但是如果是消息联调，因为经常不知道某条消息被哪台服务节点消费了，为了让特定的服务器消费特定的消息，就需要临时改动双方的代码，然而联调完成后，开发人员常常忘记把代码改回来。
因为并不希望出现这么多消息，特别是冗余数据这种非核心需求，最终项目组决定使用一个特别的同步冗余数据的方案，接下来进一步说明。
3. 解耦业务逻辑的数据同步方案
解耦业务逻辑的数据同步方案设计思路是这样的。
1）将商品及商品相关的一些表（比如分类表、生产批号表、保修类型、包换类型等）实时同步到需要依赖和使用它们的服务的数据库，并且保持表结构不变。
2）在查询采购、订单等服务中的数据时，直接关联同步过来的商品相关表。
3）不允许采购、订单等服务修改商品相关表。
以上方案能轻松避免以下两个问题。
1）商品无须依赖其他服务，如果其他服务的冗余数据同步失败，它也不需要回滚自身的流程。
2）采购、订单等服务无须关注冗余数据的同步。
这个方案的缺点是增加了订单、采购等数据库的存储空间（因为增加了商品相关表）。
计算后会发现，之前数据冗余的方案中每个订单都需要保存一份商品的冗余数据，假设订单总量是1000万，商品总数是10万。如果采用之前数据冗余的方案，1000万条订单记录就要增加1000万条商品的冗余数据，相比之下，目前的方案更省空间，因为只增加了10万条商品的数据。
4 基于Bifrost的数据同步方案
4.1 技术选型
项目组决定找一个开源中间件，它需要满足以下5点要求。
1）支持实时同步。
2）支持增量同步。
3）不用写业务逻辑。
4）支持MySQL之间的同步。
5）活跃度高。
从以上对比来看，比较贴近场景需求的是Bifrost。其实Bifrost是一个相对比较年轻的中间件，而且它不支持集群。那为什么使用它呢？原因如下。
1）它的界面管理比较方便。
2）它的架构比较简单，出现问题后，可以自己调查问题，相对比较可控。之后即使作者不维护，团队也可以自己维护起来。
3）作者更新很活跃。
4）自带监控报警功能。
项目组最终决定使用Bifrost，此时整个方案的架构如图14-4所示。
4.2 Bifrost架构
在使用这个技术之前，还是要了解一下它的基本原理。Bifrost架构图如图14-5所示。
可以看出，Bifrost其实也是模拟成MySQL的从库，监听源数据库的Binlog，然后再同步到目标数据库。它支持多种目标数据库，本项目是从MySQL同步到MySQL。
4.3 注意事项
1.数据同步的延时
这个数据同步方案是有一定延时的，所以如果业务对同步功能有高时效的要求，那么尽量不要使用这个方案。举个例子，这里虽然同步了商品的数据到订单数据库，但是订单服务当中，如果提交订单需要检查库存的话，不建议把库存数据同步到订单数据库里，而是让订单服务每次都去请求商品数据库的库存。所以，其实同步过来的数据基本上只是用来展示、查询的，不涉及业务数据变更。
2.同步过来的数据是只读的
因为这里的数据同步是单向的，所以目标数据库中同步过来的数据是不能修改的。 在这个方案里，肯定不会去修改订单数据库里面同步过来的商品数据。也有一些其他场景，比如同步一些基础配置或者公用数据到各个数据库，而后在使用这些同步数据时，可能会发现一些遗漏，比如城市/区/县数据，这种情况下，也不能直接在业务数据库里修改，而是应该通知提供数据的系统去修改，之后再同步过来。
3.监控一定要到位
Bifrost不是高可用的，它本身也提供了一些告警的功能。除了依赖它本身的告警功能以外，还要额外监控Bifrost这个服务的状态，确保它出现异常时能及时发现。Bifrost本身也提供了API接口，用来让第三方的监控对接。
4.核心逻辑不建议依赖同步
数据因为同步过来的数据是有延时的，并且Bifrost本身没有设计高可用，所以并不推荐在核心逻辑上使用同步的数据。
