事件驱动架构要避开的 5 个陷阱

事件驱动架构非常强大，非常适合用在分布式微服务环境中。事件驱动架构提供了解耦的架构、更容易实现的可伸缩性和更高程度的弹性。

请求应答（客户端和服务器）与事件流（发布和订阅）

但是，与请求和应答类型的架构相比，正确使用事件驱动架构要困难得多。

在过去的几年里，我们一直在逐步将我们不断增长的微服务（目前有 2300 个）从请求和应答模式迁移到事件驱动架构。下面是 Wix 工程师在实验事件驱动架构时遇到的 5 个陷阱。

这些陷阱让我们遭遇了生产事故，给我们带来了巨大痛苦，我们不得不进行重写，还得面对陡峭的学习曲线。对于每一个陷阱，我都提供了已经在 Wix 使用的经过实战验证的解决方案。

1. 写入数据库再触发事件（非原子操作）

我们以一个简单的电子商务流程为例（我们将在本文中使用这个示例）。

在支付处理完成后，应该更新商品库存，表示为客户保留商品。

写入数据库和产生事件是非原子操作

问题在于，将支付完成状态写入数据库，然后向 Kafka（或其他消息代理）生成“支付完成”事件并不是一个原子操作。在某些情况下，可能只有其中一个动作执行成功。

例如，数据库不可用或 Kafka 不可用可能会导致分布式系统不同部分之间的数据不一致。在这种情况下，库存可能与实际订单不一致。

原子性补救 1——Greyhound 弹性生产者

有几种方法可以缓解这个问题。在 Wix，我们使用了两种方式。第一种是使用我们自己的消息平台 Greyhound（https://github.com/wix/greyhound#greyhound），我们通过弹性生产者确保事件最终被写入 Kafka。这种缓解措施的缺点是最终可能会导致对下游事件的无序处理。Greyhound

Greyhound 生产者回退到 S3，一个将消息恢复到 Kafka 的专用服务

原子性补救 2——Debezium Kafka 源连接器

第二种确保数据库更新动作和 Kafka 生成动作都发生并且数据保持一致的方法是使用 Debezium Kafka 连接器。Debezium 连接器可以自动捕获数据库中发生的变更事件（CDC），并将它们生成到 Kafka 主题中。

使用 Debezium 数据库连接器和 Kafka Connect 结合使用可以保证事件最终被生成到 Kafka。此外，还可以保持事件的顺序。

Debezium 连接器确保变更事件最终与数据库保持一致

需要注意的是，Debezium 也支持其他事件流平台，如 Apache Pulsar。

2. 事件溯源无处不在

在事件溯源模式中，服务不是在业务操作时更新实体的状态，而是将事件保存到数据库中。服务通过重放事件来重建实体的状态。

这些事件也被发布到事件总线上，其他服务也可以在其他数据库上创建物化视图，这些数据库通过重放事件优化查询。

事件溯源——将变更事件持久化到事件存储中，通过重放事件重建状态

虽然这种模式有一定的优点（可靠的审计日志、实现“时间旅行”——能够在任何时间点获取实体的状态，并在相同的数据上构建多个视图），但到目前为止，它比更新保持在数据库中的实体状态的 CRUD 服务要复杂得多。

 事件溯源的缺点

• 复杂性——为了确保读取性能不受重放事件的影响，必须不时地获取实体状态快照，以减少性能损失。这增加了系统的复杂性，因为后台进程可能会出问题。当后台进程出问题时，数据可能是过时的。最重要的是，拥有两个数据副本意味着它们可能会不同步。

• 雪花属性——与 CRUD ORM 解决方案不同，事件溯源很难创建通用库和框架来简化开发并全局解决适合每一个应用场景的快照和读取优化。

• 只支持最终一致性（不适合写后读的场景）。

事件溯源替代方案——CRUD + CDC

利用简单的 CRUD 和向下游发布数据库变更事件（例如创建查询优化的物化视图）可以降低复杂性，增加灵活性，并仍然可以在特定用例中实现命令查询责任隔离（CQRS）。

对于大多数场景，服务可以公开一个简单的读取端点，这个端点从数据库获取实体的当前状态。随着规模的扩大，需要更复杂的查询，这个时候可以使用额外发布的变更事件来创建专门为复杂查询定制的物化视图。

CRUD——简单地读取数据库 + 用于外部物化视图的 CDC

为了避免将数据库变更作为契约暴露给其他服务，并在它们之间创建耦合，服务可以读取 CDC 主题并生成变更事件的“官方”API，类似于在事件溯源模式中创建的事件流。

3. 无上下文传播

切换到事件驱动架构意味着开发人员、DevOps 和 SRE 在调试产品问题和跟踪用户请求方面可能存在更大的困难。

与请求和应答模型不同，事件驱动架构没有可跟踪的 HTTP/RPC 请求链。调试代码变得更加困难，因为事件处理代码分散在服务代码中，无法通过简单地单击对象或模块的函数定义进行跟踪。

我们仍然以本文中使用的电子商务流程为例。订单服务必须使用多个来自 3 个不同主题的事件，这些事件都与同一个用户操作（在网商购买商品）相关。

完全事件驱动的微服务很难跟踪请求流

其他服务也使用来自一个或多个主题的多个事件。我们假设某些商品的库存水平是不正确的，这个时候，调查所有相关订单事件的处理就变得至关重要。否则，我们需要花很长时间查看各个服务的日志，并尝试手动将不同的证据片段连接在一起。

自动上下文传播

自动为所有事件添加请求上下文使得过滤与用户请求相关的事件变得非常简单。在我们的示例中，添加了 2 个事件标头——requesttid 和 userId。这两个标识都能极大地帮助我们进行问题诊断。

为每个事件自动附加用户请求上下文，便于跟踪和调试

在 Wix，当事件被生成和消费时，Greyhound 会自动传播用户请求上下文。此外，我们还可以在日志中找到请求上下文，这样就可以针对特定的用户请求过滤日志。

4. 发布包含大消息体的事件

在处理包含大消息体的事件（大于 5MB，例如图像识别、视频分析等）时，人们可能会倾向于将它们发布到 Kafka（或 Pulsar），但这可能会大大增加延迟、降低吞吐量并增加内存压力（特别是当不使用分层存储时 0。

幸运的是，有几种方法可以克服这个问题，包括压缩、将消息体拆分为块、将消息体放入对象存储并只在流式平台中传递引用。

大消息体补救措施 1——压缩

Kafka 和 Pulsar 都支持压缩消息体。你可以尝试几种压缩算法（lz4、snappy 等），找到最适合你的压缩算法。如果消息体比较大（最多 5MB）， 50% 的压缩率可以帮你保持消息代理集群良好的性能。

Kafka 级别的压缩通常比应用程序级别的更好，因为消息体可以批量压缩，从而提高压缩比。

大消息体补救措施 2——分块

减少代理压力和覆盖消息大小限制的另一种方法是将消息分割为块。

分块是 Pulsar 的内置功能（有一些限制），但对于 Kafka 来说，分块必须发生在应用程序级别。

如何在应用程序级实现分块的示例可以在这里（https://medium.com/wix-engineering/chunks-producer-consumer-f97a834df00d）和这里（https://medium.com/workday-engineering/large-message-handling-with-kafka-chunking-vs-external-store-33b0fc4ccf14）找到。基本前提是生产者发送带有额外元数据的数据块，帮助消费者重新组装它们。

生产者将数据分成块，消费者将其组装复原

这两种示例方法的不同之处在于它们如何组装数据块。第一个示例将数据块保存在某个持久存储中，当所有数据块都生成后，消费者一次性获取所有数据块。第二个示例让消费者在所有数据块到达后在主题分区中向后查找第一个数据块。

大消息体补救措施 3——使用对象存储的引用

最后一种方法是简单地将消息体内容存储在对象存储中（如 S3），并将对象的引用（通常是 URL）作为事件的消息体。这些对象存储允许在不影响第一个字节延迟的情况下持久化任何所需的大小。

在生成链接之前，需要确保消息体内容已经完全上传到对象存储中，否则消费者需要不断重试，直到可以开始下载它。

5. 不处理重复事件

大多数消息代理和事件流平台默认保证至少一次传递，这意味着一些事件可能出现重复，或者可能会被处理两次（或多次）。

确保重复事件的副作用只发生一次叫作幂等性。

我们继续以本文中一直使用的电子商务流程为例。由于一些处理错误导致需要进行重复处理，记录到库存数据库中的已购买商品的库存量下降得可能比实际的要多一些。

消费者多次处理导致库存变得不正确

其他副作用包括多次调用第三方 API（在我们的示例中，这可能意味着对相同的事件和商品两次调用降低库存数量的服务）。

等幂补救——revisionId（版本控制）

在需要等幂处理的情况下，可以考虑使用乐观锁技术。在发生更新之前需要先读取存储实体的当前 revisionId（或版本），如果有多方尝试同时更新实体（同时增加版本），那么第二个尝试更新的一方将失败，因为版本与之前读取的不匹配。

在对重复事件进行幂等处理时，revisionId 必须是唯一的，并且是事件本身的一部分，这样可以确保两个事件不共享相同的 id，并且针对同一 revisionId 的第二次更新将（静默地）失败。

为每个事件附加 transactionId，避免重复处理

特别是在使用 Kafka 时，有可能配置精确一次语义，但由于某些故障，数据库更新仍然可能出现重复。在这种情况下，txnId 可以是主题 - 分区 - 偏移量三元组，这样可以保证 id 是唯一的。

总结

迁移到事件驱动架构可以是一个循序渐进的过程，这样可以减少与之相关的风险，比如调试困难和心里层面的复杂性。微服务架构允许为每个不同的服务灵活地选择模式。HTTP/RPC 端点可以作为事件处理的一部分进行调用，反之亦然。

作为这种渐进迁移的结果，我强烈建议采用 CDC 模式，将其作为一种既能确保数据一致性（陷阱 1）又能避免与完全成熟的事件溯源相关的复杂性和风险（陷阱 2）的方法。CDC 模式仍然允许将请求和应答模式与事件处理模式结合在一起。

解决陷阱 3（在事件流中传播用户请求上下文）将大大提高快速查找生产事故根源的能力。

陷阱 4 和陷阱 5 的补救措施是针对具体场景的——陷阱 4 的消息体非常大，而陷阱 5 的副作用不是幂等的。如果没有必要，就不需要做出这些变更。尽管作为最佳实践，可以使用压缩（陷阱 4）和事务 ID（陷阱 5）。

原文链接：

https://natansil.medium.com/event-driven-architecture-5-pitfalls-to-avoid-b3ebf885bdb1

相关阅读：

一文读懂什么是 Web3 架构

深度剖析 Apache EventMesh 云原生分布式事件驱动架构

事件总线 + 函数计算构建云上最佳事件驱动架构应用

企业级业务架构设计：方法论与实践 学习笔记