Selecting an Event Architecture

Selecting an Event Architecture

作者 | Jan Stenberg

译者 | 盖磊

标签 | 事件架构

如果你要设计一个分布式系统，它可能是基于微服务的，并且你在考虑采用 事件架构（Event Architecture），那么目前存在多种模型和技术可供使用。

David Dawson 近期在博客中介绍了多种类型的事件架构，并指出：非功能性需求是影响架构选择的一个主要因素。

http://daviddawson.me/blog/2017/07/10/styles-of-event-architecture.html

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 项目。

https://github.com/muoncore/stack-event

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

英文原文传送

https://www.infoq.com/news/2017/08/selecting-event-architecture

今日荐文

点击下方图片即可阅读

沈剑聊微服务：先做好你的服务拆分

---

以上

感谢阅读  

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/