マイクロサービスは、その名前が示すように、プログラムを最小限の単位に分割してサービスを提供することです。統合システムでは、各マイクロサービスが独立して存在することは不可能ですが、マイクロサービス間のデータ依存性の問題にどのように対処する必要がありますか？そのような問題を分析し、検討するために、現場から始めます。
1.シナリオ
サプライチェーンシステムには、商品、受注、調達の3つのマイクロサービスがあり、主なデータ部分のデータ構造は次のとおりです。
商品：
注文とサブ注文：
注文書とサブオーダー：
このサプライチェーンシステムを設計するときは、次の2つの要件を満たす必要があります。
- 製品のモデル/カテゴリ/世代年/コードなどに基づいて注文を検索します。
- アイテムのモデル/分類/世代年/コードなどに基づいて発注書を検索します。
初期のソリューションは、次のように設計されていました。マイクロサービス部門の原則に厳密に従って、商品関連の責任を商品システムに保存します。したがって、注文と発注書をクエリするときに、クエリフィールドに商品フィールドが含まれている場合は、次の順序でクエリを実行する必要があります。
- 最初に製品フィールドに従って製品のサービスを呼び出し、次に一致する製品情報を返します。
- 発注書または発注書で、INステートメントを使用して製品IDを照合し、対応するドキュメントを関連付けによって照会します。
このプロセスの理解を容易にするために、注文クエリのフローチャートを次の図に示します。
最初の計画が設計された後、すぐに一連の問題が発生しました。
- 製品の数が増えると、一致する製品が増えるため、注文サービスでのINステートメントのクエリ効率はますます遅くなります。
- コモディティはコアサービスであり、それに依存するサービスが増えていると同時に、コモディティデータの量が増えるにつれ、コモディティサービスが圧倒され、応答速度も遅くなり、リクエストがタイムアウトする場合があります。 ;
- 関連するサービス処理要求は、コモディティサービスのタイムアウトが原因で失敗することがよくあります。
その結果、ビジネス側が注文または発注書を照会するたびに、商品のキーワードが含まれている限り、照会の効率は非常に遅くなり、常に失敗します。そこで、新しいソリューションを再考しました。データの冗長性です。一緒に見てみましょう。
第二に、データの冗長性スキーム
率直に言って、データの冗長性は、注文と発注書にいくつかの商品フィールド情報を保存することです。
理解を容易にするために、上記の実際のビジネスシナリオを使用して詳細に説明し、2つの違いを確認します。
商品：
注文とサブ注文：
注文書とサブオーダー：
スキーマを調整した後、クエリを実行するたびにコモディティサービスに依存することはできなくなります。
しかし、アイテムが更新された場合、どのように冗長データを同期するのでしょうか？ここで2つのソリューションを共有します。
- 製品が更新されるたびに、最初に注文および購入サービスが呼び出され、次に製品の冗長データが更新されます。
- 每次更新商品时，先发布一条消息，订单与采购服务各自订阅这条消息后，再各自更新商品冗余数据。
看到这里是不是觉得很眼熟了呢？没错，这就是我们上一篇提到过的数据一致性问题。那么这2种方案会出现哪些问题呢？
如果商品服务每次更新商品都要调用订单与采购服务，然后再更新冗余数据，则会出现以下两种问题。
- 数据一致性问题：如果订单与采购的冗余数据更新失败了，整个操作都需要回滚。这时商品服务的开发人员肯定不乐意，因为冗余数据不是商品服务的核心需求，不能因为边缘流程阻断了自身的核心流程。
- 依赖问题：从职责来说，商品服务应该只关注商品本身，但是现在商品还需要调用订单与采购服务。而且，依赖商品这个核心服务的服务实在是太多了，也就导致后续商品服务每次更新商品时，都需要调用更新订单冗余数据、更新采购冗余数据、更新门店库存冗余数据、更新运营冗余数据等一大堆服务。那么商品到底是下游服务还是上游服务？还能不能安心当底层核心服务？
因此，第一个解决办法直接被我们否决了，即我们采取的第二个解决办法——通过消息发布订阅的方案，因为它存在如下 2 点优势。
- 商品无须调用其他服务，它只需要关注自身逻辑即可，顶多多生成一条消息送到 MQ。
- 如果订单、采购等服务的更新冗余数据失败了，我们使用消息重试机制就可以了，最终能保证数据的一致性。
此时，我们的架构方案如下图所示：
这个方案看起来已经挺完美了，而且市面上基本也是这么做的，不过该方案存在如下几个问题。
- 在这个方案中，仅仅保存冗余数据还远远不够，我们还需要将商品分类与生产批号的清单进行关联查询。也就是说，每个服务不只是订阅商品变更这一种消息，还需要订阅商品分类、商品生产批号变更等消息。下面请注意查看订单表结构的加粗部分内容。
以上只是列举了一部分的结构，事实上，商品表中还有很多字段存在冗余，比如保修类型、包换类型等。为了更新这些冗余数据，采购服务与订单服务往往需要订阅近十种消息，因此，我们基本上需要把商品的一小半逻辑复制过来。
- 每个依赖的服务需要重复实现冗余数据更新同步的逻辑。前面我们讲了采购、订单及其他服务都需要依赖商品数据，因此每个服务需要将冗余数据的订阅、更新逻辑做一遍，最终重复的代码就会很多。
- MQ 消息类型太多了：联调时最麻烦的是 MQ 之间的联动，如果是接口联调还好说，因为调用哪个服务器的接口相对可控而且比较好追溯；如果是消息联调就比较麻烦，因为我们常常不知道某条消息被哪台服务节点消费了，为了让特定的服务器消费特定的消息，我们就需要临时改动双方的代码。不过联调完成后，我们经常忘了改回原代码。
为此，我们不希望针对冗余数据这种非核心需求出现如此多的问题，最终决定使用一个特别的同步冗余数据方案，接下来我们进一步说明。
三、解耦业务逻辑的数据同步方案
解耦业务逻辑的数据同步方案的设计思路是这样的：
- 将商品及商品相关的一些表（比如分类表、生产批号表、保修类型、包换类型等）实时同步到需要依赖使用它们的服务的数据库，并且保持表结构不变；
- 在查询采购、订单等服务时，直接关联同步过来的商品相关表；
- 不允许采购、订单等服务修改商品相关表。
此时，整个方案的架构如下图所示：
以上方案就能轻松解决如下两个问题：
- 商品无须依赖其他服务，如果其他服务的冗余数据同步失败，它也不需要回滚自身的流程；
- 采购、订单等服务无须关注冗余数据的同步。
不过，该方案的“缺点”是增加了订单、采购等数据库的存储空间（因为增加了商品相关表）。
仔细计算后，我们发现之前数据冗余的方案中每个订单都需要保存一份商品的冗余数据，假设订单总数是 N，商品总数是 M，而 N 一般远远大于 M。因此，在之前数据冗余的方案中，N 条订单就会产生 N 条商品的冗余数据。相比之下，解耦业务逻辑的数据同步方案更省空间，因为只增加了 M 条商品的数据。
此时问题又来了，如何实时同步相关表的数据呢？我们直接找一个现成的开源中间件就可以了，不过它需要满足支持实时同步、支持增量同步、不用写业务逻辑、支持 MySQL 之间同步、活跃度高这五点要求。
根据这五点要求，我们在市面上找了一圈，发现了 Canal、Debezium、DataX、Databus、Flinkx、Bifrost 这几款开源中间件，它们之间的区别如下表所示：
从对比表中来看，比较贴近我们需求的开源中间件是 Bifrost，原因如下：
- 它的界面管理不错；
- 它的架构比较简单，出现问题后，我们可以自行调查，之后就算作者不维护了也可以自我维护，相对比较可控。
- 作者更新活跃；
- 自带监控报警功能。
因此，最终我们使用了 Bifrost 开源中间件，此时整个方案的架构如下图所示：
四、上线效果
整个架构方案上线后，商品数据的同步还算比较稳定，此时商品服务的开发人员只需要关注自身逻辑，无须再关注使用数据的人。如果需要关联使用商品数据的订单，采购服务的开发人员也无须关注商品数据的同步问题，只需要在查询时加上关联语句即可，实现了双赢。
然而，唯一让我们担心的是 Bifrost 不支持集群，没法保障高可用性。不过，到目前为止，它还没有出现宕机的情况，反而是那些部署多台节点负载均衡的后台服务常常会出现宕机。
最终，我们总算解决了服务之间数据依赖的问题。
五、总结
这里我们探讨了服务间的数据依赖问题，并给出了目前较为合适的解决方案。其实这里提到的方案不是一个很大众的方案，肯定会存在一些遗漏的问题没考虑，如果你有更好的方案，欢迎留言讨论。