如何选取事件架构

  • Jan Stenberg
  • 盖磊

2017 年 8 月 29 日

话题:语言 & 开发架构

如果你要设计一个分布式系统,它可能是基于微服务的,并且你在考虑采用事件架构(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

语言 & 开发架构