如何选取事件架构

如果你要设计一个分布式系统，它可能是基于微服务的，并且你在考虑采用事件架构（Event Architecture），那么目前存在多种的模型和技术可供使用。 David Dawson 近期在的博客帖子中介绍了 [多种风格类型的事件架构，并指出，非功能性需求是影响架构实现选择的一个主要因素。

Dawson 是一位自由职业的系统架构师，他将事件架构简单地定义为一种基于事件的软件架构。鉴于事件也是数据模型的一部分，因此事件架构也是一种数据架构。他强调指出，事件架构并非定义服务交互方式的一系列技术或特定模型。

分阶段事件驱动架构（SEDA，Staged Event-Driven Architecture）是一种简单并很好确立的模型。SEDA 本质上是一个工作流过程，其中各个组件根据自身的处理情况发出事件去驱动整个过程，而事件通常使用某种消息总线进行传输。Dawson 指出，SEDA 模型的一个重要问题是事件的生存期很短，因而在会在传输或组件离线过程中丢失。因此与其让系统采纳最终一致性，不如实现一种Dawson 所称的“期许一致性”（Hopeful Consistency）。只要所有组件工作正常，系统就是一致的。一旦有组件崩溃，那么最终将会得到不一致的系统，这时必须做手工恢复去回到一致性状态。Dawson 称其为“面向实体的微服务”，并强烈建议不要采纳这种架构。

为重建一致性状态，Dawson 给出的最优解决方案是将事件看作是一种数据，并持久化事件流。这样我们就可以在任一时刻重放（Replay）流以恢复状态，并且借助此得到真正的最终一致性系统。从中我们还可以得到其它一些优点，例如可以对同一事件流给出多个视图。

从Dawson 的经验来看，尽管通常称持久化事件流为“事件溯源”，但是他坚信这并非正确的，因为它不是去重建一个实体的状态，而是对不受限实体集创建视图。鉴于此，他更愿意称其为“类型流处理”（Style Stream Processing）。他认为 Kafka 正是使用了这样的架构。Kafka 客户按流的顺序依次读取事件，但在重放事件时可以从头开始，或是从所需的特定事件处开始。

用 DDD 的术语解释，聚合（aggregate）是处于一致性范畴内的一系列实体。通过对一个聚合的所有更改发出和持久化事件，并通过重放而获取的同一事件而构建同一聚合的状态，我们可以得到经事件溯源的聚合根，Dawson 称其为“真实事件溯源”。Daswon 指出，具有独立单一事件流在重建聚合过程中是非常重要的。对于创建视图等其它一些需求，必须要创建独立的流。

为辅助构建基于事件架构模型的系统，Dawson 创建了 Muon Stack 项目。它是一系列面向消息和事件的软件库和服务，用于构建分布式系统。其中包括了一个事件流 API 客户端，以及一个名为“ Photon ”的事件存储。目前他正致力于构建 Muon Stack 对 Kafka 的接口。

查看英文原文： Selecting an Event Architecture