工赋开发者社区 | 事件驱动架构要避开的 5 个陷阱

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

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

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

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

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

写入数据库再触发事件

（非原子操作）

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

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

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

问题在于，将支付完成状态写入数据库，然后向 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。

事件溯源无处不在

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

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

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

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

事件溯源的缺点

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

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

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

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

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

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

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

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

无上下文传播

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

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

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

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

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

自动上下文传播

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

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

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

发布包含大消息体的事件

在处理包含大消息体的事件（大于 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/wix-engineering/chunks-producer-consumer-f97a834df00d）和这里（https://medium.com/workday-engineering/large-message-handling-with-kafka-chunking-vs-external-store-33b0fc4ccf14）找到。基本前提是生产者发送带有额外元数据的数据块，帮助消费者重新组装它们。