事件驱动架构：原理、挑战与最佳实践

### 事件驱动架构：原理、挑战与最佳实践 #### 1. 事件驱动架构的关键要点 在事件驱动架构中，有诸多方面需要管理，包括用于分发事件的事件代理、用于查询数据或排队的事件存储、数据产品的摄入管道，以及将数据转化为价值的分析组件。同时，存在两种类型的边界：应用内部组件间的事件流，以及不同领域应用之间的通信，这两者都需要进行治理。 治理模型方面，事件驱动架构应遵循与向其他领域提供数据产品和 API 相同的模式。所有事件流（如事件流和队列）必须由事件提供者（数据提供者）拥有。为避免其他领域的消费者获取内部通信渠道，建议对应用内部事件流和领域间事件流进行严格隔离。 隔离方法有多种，例如通过多个服务实现隔离：着陆区的服务保持领域无关性，用于领域间分发；运营账户或订阅中的服务用于应用的内部架构。也可以部署和共享专用平台，如在数据管理着陆区。还可使用专用事件流或事件中心、命名约定（如嵌入域名或使用前缀），或者通过消费者组、认证或多集群进行隔离。 #### 2. 内部流与业务流 内部流用于应用组件间的内部通信，允许是技术性的，无需立即适应业务用途。这些流被视为应用或领域逻辑的一部分，只能由产生它们的应用领域消费，不过其中的事件可作为有意义业务流的输入。在元数据策略上可以相对宽松，例如在队列或事件流注册表中的信息可以不那么详细。 业务流（领域间流）仅允许其他领域消费，已为业务消费做好准备，因此进行了读取优化。它们是解耦的，能与旧版本兼容，并且在注册表中为数据消费者提供的信息比内部流更详细，应遵循所有的数据管理原则。 #### 3. 事件存储的应用 ##### 3.1 作为数据产品存储 如果数据需要长期存储，流平台可以用作数据库和数据产品存储。借助事件溯源、状态存储和现代流平台的回退功能，可以创建不断填充新数据的联合数据产品。消费者可以使用回退方法生成数据副本，即从第一条消息到最后一条消息重新读取所有事件，回退后通过流实时更新数据副本。此方法可通过变更数据捕获（CDC）读取应用事务日志中的所有更改来实现。 在长期存储数据时，需要确定流在何种条件下可以进行长期或无限期的数据保留。若不进行监控而实施较长的保留期，架构可能成本高昂，还可能违反保留和数据生命周期管理政策（如 GDPR）。可以设定只保留最新或唯一消息的原则，或者将消息卸载到数据产品架构中，使用成本较低的存储选项。 ##### 3.2 作为应用后端 理论上，中央流平台可以用作应用后端，例如 Kafka 可作为应用数据存储，但一般不建议这样做。原因如下： - 流本质上是异步的，对于无延迟要求的应用虽不是问题，但需移除保留限制，否则应用数据可能丢失。 - 会使应用与企业数据分发目的紧密耦合，这是两个不同的关注点，不应混合治理。 若决定使用流平台作为应用后端，建议制定明确的治理规则。可以为每个领域明确此模式的范围，或者为特定领域创建更多平台。使用流平台作为后端的最大风险是创建集成数据库。对于从其他流派生的流，也应遵循类似原则，避免消费者直接消费这些事件流导致混乱。 #### 4. 流作为运营骨干 事件流平台是连接事务系统和分析系统的解决方案，其组件具有以下功能： - 用内存系统扩展运营系统，跟踪所有历史数据，当运营系统决策需要更多历史上下文时，流平台提供该数据。 - 为运营系统添加实时决策逻辑，例如客户购买新产品时，通过流咨询金融系统检查未结余额。 - 使用命令溯源持久化命令并重现系统的完整状态，以便将缺失的订单重新添加到列表中并在稍后执行。 在构建大规模运营异步消息系统时，可能会遇到背压问题，即系统接收数据的速度超过处理速度。解决方法包括添加额外资源，或者设置队列限制，将超出限制的消息丢弃或存储在其他地方。 同样的架构可用于设计具有多技术后端的运营系统，流可以支持不同数据库之间的数据同步或数据的组合与集成。基于微服务的架构也常依赖事件驱动架构，事件流是微服务之间通信的模式之一。 #### 5. 保证与一致性 流处理比批处理更复杂，处理失败和不一致时需要额外考虑。 ##### 5.1 一致性级别 - 最终一致性：保证所有数据最终会反映在平台上，但传播可能需要时间。这是一种弱保证，适用于非关键数据。 - 强一致性：保证所有事件按顺序处理，平台确认任何更新传播到所有数据副本；任何实体或节点进行更新后，所有副本在更新完成前被锁定。但在事件速度过高时，实现强一致性可能很困难，因此在许多用例中，最终一致性是唯一可行的方法。为确保最终一致性的正确性，可使用额外数据库持久化所有数据并偶尔进行对账，使用 CDC 等工具确保更改正确传递，或构建额外服务读取、验证和重新传递缺失的消息。 ##### 5.2 处理方法 - 至少一次处理：确保消息不会丢失，但不保证消息唯一且仅传递一次，允许有重复和多次处理。 - 恰好一次处理：保证每个事件恰好且仅传递一次，无消息丢失和重复。实现此模型可能需要额外的重新传递模式，一些工程师使用额外标识符验证消息的唯一性。 - 至多一次处理：不保证所有消息正确传递，消息可能丢失或多次传递。 可以根据用例需求和其他约束组合不同的模型，例如先使用最终一致性模型不确认接收地传递消息，偶尔比较所有消息，移除重复项并重新传递缺失的消息，以确保恰好一次