我为我们的金融科技软件设计了事件驱动的架构。它由三个部分组成。
第一部分有一个同步过程，
第二部分和第三部分有异步操作。响应回复客户端后，将Kafka（消息代理）的最终结果发送到第二部分和第三部分。
在第二部分中，我可不将结果返回给客户端。但是，将数据从第一部分发送到第二部分对于业务来说是必不可少的。
此外，DevOps 团队无法一直看着 Kafka Online，有时 Kafka 会宕机！值得注意的是，我知道 Kafka 有一个用于持久数据的弹性系统，但 Kafka 可能会宕机，我们丢失了重要数据。
如上图所示，如果 Kafka 出现故障，则第二部分和第三部分无法获取数据。所以我需要一个有弹性的系统来恢复丢失的数据。
解决方案
我为这个问题提供了许多解决方案，但我不知道哪个更好。
1、Debezium
Debezium 是可以处理此问题的最佳 CDC 工具之一。众所周知，Debezium 从数据库的日志中读取数据，如果 Kafka 停止或 Kafka 发生可怕的事情，它将停止，除非 Kafka 恢复回来。
不幸的是，我们在这个项目中没有使用这个工具，因为 DevOps 团队不同意这个架构。
2、发件箱设计模式
发件箱设计模式是解决此问题的直接方法。基于这种设计模式，我们在向 Kafka 发送数据之前，在 outbox 表中插入数据，在第二部分接收数据时，将接收到的字段添加到 outbox 表中。
实际上，在第一部分的发件箱中插入数据后，通过Kafka将数据发送到第二部分，第二部分调用GRPC将接收到的数据再次插入到第一部分的发件箱中。
在另一种情况下，我可以创建另一个微服务（恢复），在其中放置一个发件箱表。意思是在使用Kafka前后调用GRPC发送和接收数据。之后，我们检查所有必须发送和接收数据的数据。
收件箱并与实际数据进行比较
在这个方法中，我在第二部分通过 Kafka 将数据复制到收件箱中，并且每隔一小时检查一次实际输出与收件箱中的数据之间的差异。如果缺少某些数据，我可以理解收件箱和输出第一部分之间的矛盾（我在另一个表中有第一部分的输出数据）。我知道这种方法需要更多的硬盘和 IO，但我确信所有数据都进入第二部分。