蓝科溯源

100％准确的审核日志 ——审核功能通常都是后来才加上去的，导致了先天性的漏洞危险。在 Event Sourcing 下，每一状态更新都对应着一个或多个事件，提供了100％精准的审核日志。

想要与大师面对面吗？

Chris Richardson 在微服务架构领域的研究非常权威新颖，我们为大家精选了三篇微服务架构系列文章进行翻译，本文为该系列第二篇：「事件溯源（Event Sourcing）型微服务」。

事件被持久化在事件 store 里。事件 store 不仅是数据库，同时还像是一个消息代理。它提供 API 让服务可以订阅事件。每个存储在事件 store 里的事件都经由 store 发送到相关的订阅者。 事件 store 是事件驱动微服务架构的核心。

为何要采用事件溯源（Event Sourcing）架构

如上篇 《Chris Richardson 微服务系列之「事件驱动型微服务」》 所言，你可以用事件驱动架构来解决微服务中分布式数据管理的难题。不过，实现事件驱动架构需要面临一大挑战，是 自动更新数据库并发布事件 。

以下是订单服务如何处理更新订单的请求：

以订单实体为例，来看看事件溯源（Event Sourcing）架构是如何运作的。

想要了解微服务领域前沿的动态吗？

Chris Richardson，是世界著名的软件大师，经典技术著作 《 POJOS IN ACTION 》 一书的作者，也是  cloudfoundry.com 初的创始人，他的研究领域包括 Spring、Scala、微服务架构设计、NoSQL 数据库、分布式数据管理、事件驱动的应用编程等。

事件溯源（ Event Sourcing）架构的其他优势

如你所见，事件溯源（Event Sourcing）架构 解决了实现事件驱动架构的难题 。持久化业务事件还有如下的其他好处：

事件溯源（Event Sourcing）架构的实例

既然事件溯源（Event Sourcing）架构的好处如此显而易见，那么下期我们将带大家一同探索事件溯源（Event Sourcing）架构的实例 Eventuate 是如何把这种独特而强大的方法付诸实现的。

试想一下 创建订单 用例。实现此用例的服务必须完成两项操作：在 “ORDER（订单）” 数据表中插入一行新数据，然后发布 OrderCreated 事件。两项操作都必须自动完成。如果因为错误只发生了一项操作，那么整个系统都会出错。

方便的时序查询 ——因为事件溯源（Event Sourcing）架构保存了每个业务对象的完整历史，所以可以非常直观地实现时序查询和重建实体的历史状态。

Chris Richardson 与 Martin Fowler、Sam Newman、Adrian Cockcroft 等并称为 世界十大软件架构师。Chris 与家人居住在美国加州奥克兰市的海滨小镇，他定期为企业提供微服务设计培训和实战项目的架构咨询服务。

以往，每张订单对应 “ORDER ” 表中的一行数据和其他关联的诸如 ORDER_LINE_ITEM 数据表。但如果用事件溯源（Event Sourcing）架构时，Order Service（订单服务）会以持久化其状态变化的事件——比如：创建、确认、送达和取消 ——的方式去存储一张订单。每个事件都包含足够多的数据去重建订单的状态。

关于事件溯源（Event Sourcing）架构

这一问题有一种的解决方法——一种名叫事件溯源（Event Sourcing）的架构模式。传统的保存实体的办法是保存其当前状态，而事件溯源（Event Sourcing）架构却采用一种迥然不同的，以事件为核心的方式来做持久化。业务对象是通过保存一连串变化的事件来进行持久化。

DaoCloud 现联手世界著名软件大师 Chris Richardson 为您现场布道微服务架构，助力企业应用的成功转型。我们为您推荐由 Chris Richardson 和《 Docker 源码分析》一书的作者孙宏亮共同讲授的 微服务架构及容器技术高端系列课程。

每当对象状态发生改变时，新的事件会被添加到事件序列中。由于这是一步操作， 所以其粒度天生微小 。通过重放这些事件可以重建整个实体的当前状态。

通常的处理办法，是使用包含数据库和消息代理的分布式事务。然而，由于之前提到的原因，我们不愿这么做。因此我们需要：事件溯源（Event Sourcing）架构模式。

在此架构中，更新实体的请求（要么是外部的 HTTP 请求，要么是其他服务发布的事件）都通过从事件 store 中取得的实体事件进行处理，重建实体的当前状态，更新实体和保存新事件。