什么是事件溯源Event Sourcing？

转载：http://www.jdon.com/48501
本文比较全面以易懂方式阐述了什么是事件溯源以及优缺点。
什么是Event Sourcing?“传统”保存应用程序变化数据的方式是存储当前状态。
例如，您的应用程序可能是一个日历，所以您想存储约会。它可能看起来像这样：约会ID 开始时间 结束时间 标题
1 09:30 10:45 会议
2 11:15 11:30 饭局

这是一张看起来很熟悉的数据表。它可能是关系数据库中的一个表，或一个键值存储中的一组文档，甚至一个存储在内存中的对象列表。重点是，它代表了系统的状态，因为它是现在。让我问你一个问题：这个系统是如何进入这个状态的？审计日志audit log要回答这个问题，您可以创建一个审计日志。除了记录创建或更新约会，在审计日志中您还将记录描述所发生的事件（一个“事件”）。对于一个单一的约会，它可能看起来像这样：
Sequence 事件Event1
约会被创建:时间：09:30 - 10:30
Title: 开会2
约会重新被安排: 09:30 - 10:453
标题被改变: 饭局

相比如果你只有系统的当前状态，这揭示了一个大量的信息。在约会被创建一次，约会改期一次，它的标题被改变了。10:30是预约结束时间，但它后来被改期，之前的预约信息会消失。这种信息对应用程序的用户来说是非常有用的，因为他们可以看到发生了什么事，他们应该责怪谁。开发人员也将从中获利最多；当你看到为什么导致某个特定的状态时，寻找问题的原因就变得容易得多了。单一真理之源除了你的当前状态以外存在一个审计日志是有用的，但有一个问题：冲突。如果你发现自己在目前的状态A，而你的审计日志说是B，你现在有两个问题。你不仅要诊断手头的问题，而且你也必须找出其中的差异原因。问题是，你有两个“真相”的来源，陈述你系统的状态应该是什么样的。您的应用程序只能查看到当前状态，所以它没有任何问题。你作为一个开发人员面对两个来源的真相。因为他们冲突，也就都没有真正值得信任，如同一个人戴两只表，如果时间不一样，都无法信任了。事件溯源如果我们消除审计日志，我们只有一个真相的来源，但我们失去了所有详细的历史信息，这些信息我们非常重视。如果我们消除了当前的状态呢？这是事件溯源的本质：它不是存储系统的当前状态，您只存储导致该状态的事件。为了获得当前状态，您可以在内存中“重播”这些事件。当前状态只是发生了事件的“短暂”表示。它不是恒久不变的。你可以改变你的应用程序的状态，但你不能改变事件。他们已经成为不争的事实。重播为了得到您的系统的当前状态，您将必须重播所有的事件。所有的事件？嗯，不是真的都是。您当前的状态通常被分为几个逻辑的“对象”，这将是传统上一个表中的行。如果您唯一标识每个对象，您只需要重播该对象的事件，以获得该对象的状态。让我们来看看一个非常简单的例子，我们的日历目前的状态。
class Appointment{public Guid AppointmentId { get; }public DateTime StartTime { get; private set; }public DateTime EndTime { get; private set; }public string Title { get; private set; }public bool IsCanceled { get; private set; }}

事件看上去如下：class AppointmentCreated{public Guid AppointmentId { get; }public DateTimeOffset StartTime { get; }public DateTimeOffset EndTime { get; }public string Title { get; }}class AppointmentRescheduled{public DateTimeOffset StartTime { get; }public DateTimeOffset EndTime { get; }}class AppointmentRenamed{public string Title { get; }}class AppointmentCanceled{}

AppointmentCanceled 事件没有任何属性。它的类型代表发生了一个有意义的事件。从约会视角重播这些事件看起来像什么呢？void ReplayEvent(AppointmentCreated @event){AppointmentId = @event.AppointmentId;StartTime = @event.StartTime;EndTime = @event.EndTime;Title = @event.Title;}void ReplayEvent(AppointmentRescheduled @event){StartTime = @event.StartTime;EndTime = @event.EndTime;}void ReplayEvent(AppointmentRenamed @event){Title = @event.Title;}void ReplayEvent(AppointmentCanceled @event){IsCanceled = true;}

你开始一个空白对象。然后为每个发生的事件简单调用ReplayEvent，按照它们发生的顺序。这是所有您需要重新创建当前状态的步骤。修改状态因为状态是代表过去发生的事件，修改状态就是通过添加事件实现。获得当前状态是对象的一种职责责任，它方便让所有的业务逻辑放在一个地方，包括业务规则的知识，它是DDD中的哲学。当前状态的对象（或实体对象或领域对象，不管你怎么称呼它）也会对自己负责一致性；它是唯一的创造事件的角色，也负责从过去的事件重播决定是否允许或禁止某个操作：你的约会已经取消；你就不能再取消了。class Appointment{public Appointment(Guid id,DateTimeOffset startTime,DateTimeOffset endTime,string title){if(endTime < startTime)throw new EndTimeBeforeStartTimeException();AppendEvent(new AppointmentCreated(id, startTime, endTime, title));}public void Reschedule(DateTimeOffset startTime,DateTimeOffset endTime){AppendEvent(new AppointmentRescheduled(startTime, endTime));}public void Cancel(){if (IsCanceled)throw new AppointmentAlreadyCanceledException();AppendEvent(new AppointmentCanceled());}}

AppendEvent 是一个方法，该方法将为指定的唯一对象也就是约会Appointment代表的对象添加一个事件到存储中。在方法内完成参数的验证。它使得一种方法最终负责数据的有效性和一致性。为简洁起见，Reschedule 不验证参数，但Cancel根据目前的状态检查操作是否允许。当前，如果您试图取消已被取消的约会，将引发异常。通常不会这样。我们可以跳过检查，并只是存储事件。它不会改变已被取消的事实；当重播时，我们还将设置iscanceled属性为true时。这里的要点是：你不必总是需要维护和基于状态验证。有时它会忽略多余的事件。注意，所有的构造器和Reschedule或Cancel 的方法都是存储事件。他们并没有直接修改状态。为什么？我们已经有了一个基于事件修改状态的方法：ReplayEvent方法。所以，除了存储事件，AppendEvent也将立即重播的事件。数据表事件的规则特点：1. 事件描述了已经发生的事情，因为我们不能改变过去，他们是不可变的。在他们持久后，事件不能改变。2.扩展以前的规则：他们不能被删除。3.每一个事件都包含表示状态变化所需的所有信息，并能够重播它。如果他们可以来自其他事件，他们不应该包括计算值。4.事件的元数据包含它的类型，当它发生时间5.您不能查询事件。它们只用于重放一个给定的时间内系统的状态。对于一个事件源对象，一个更改状态的请求只会导致三个东西中的一个：1.存储事件；2.抛出一个例外（因为一个业务规则会被侵犯）；3.什么都不做。其他的结果，如直接修改对象的状态或进行数据库调用，都是非常令人沮丧的，因为它们是副作用。副作用通常不会被存储的事件表示，这意味着你不能重播它们。也使测试更难。好处因为你只需要读取和附加事件，存储是非常容易的。你需要做的唯一的事情是添加一个事件和检索事件列表。你可以存储事件在任何地方：在一个表中，一个键值存储，一个文件目录，一个电子邮件，或几乎任何你可以想象的地方。由于事件是不可变的，他们是非常容易缓存，这使您能够获得优异的性能。您将不再需要显式的事务，因为您只需要插入数据，而不需要更新或删除它；您也只需要一个表、集合、set，或是您的数据存储组数据。事务就像一把锁，所以不需要事务是一种像无锁代码：没有死锁和性能快得多。您还得到一个免费的审计日志，您可以在调试时使用，看看到底发生了什么，为什么系统处于一个特定的状态。如果您确定实体类中的操作是无副作用得，它基本上生活在隔离中，类Class将有一个非常低的耦合度量。你已经从系统的其余部分中分离出了业务逻辑。如果你已经实现了这些分离，测试你的逻辑可以表示为“指定的这些事件发生了，当这个操作被请求，那么这些事件是否被存储？”或者，“那么这个异常会被抛出吗？”你不必处理建立在代数上的关系数据库，因为你的对象不是。事件溯源回避了对象关系阻抗匹配。你的真理之源是一个数据库中的一堆事件。在你存储它们之后，你也可以通过一个消息系统广播到世界各地。它很容易让其他应用程序知道在你的系统中发生了什么。您不再需要到另一个系统存储中查询数据，然后复制以找出发生了什么变化。所有您需要存储的是：一个唯一对象标识符的列表和他们的最新已知的版本号。缺点当然，每一个方法的缺点，事件溯源也不例外。最重要的实际缺点是：没有简单的方法来查看您的应用程序的持久状态是什么，你不能通过查询得知。只有当你只能看到运行时发生了什么时。一个解决方案，是使用一个单独的模型读取发生在您的系统中的事件，由此需要CQRS。事件溯源是一个完全不同于大多数人都习惯的方法。您需要定义可以在您的系统中发生的每一个事件，所以添加新的功能可能会比过去习惯的慢。为了弥补这一差距，你的数据变得更珍贵。事件溯源听起来像是一个非常低效的机制来存储状态。它比当前状态直接存储需要更多的存储空间。它还需要更多的处理时间，仅仅是因为需要检索更多的数据才能到达当前状态。因为你现在拥有几乎无限量的存储和处理能力，克服这些不足是很容易的。其中之一是使用快照。快照你可能会认为，当一个事件流包含数千或数万的事件时，您的系统必须变得缓慢，因为每一个操作需要重播所有这些事件。嗯，不一定。记住，唯一做回放事件是由于要改变有状态。它应该是幂等；无论你重播事件一次或一百次，它应该有相同的结局。我们重播以后，比如一万事件，我们可以得到结果状态的快照并存储，以最后一个重播事件为标识。现在，当我们想要当前状态时，我们只需加载快照和回放快照以后任何发生的事件，如果你已经正确创建了你的快照，为了重放所有的事件加载快照和重放新的事件应该是相同。测试前面提到过测试变得容易多了。让我们更具体一点，展示如何测试一个事件溯源对象。private AppointmentCreated CreateAppointmentCreatedEvent(){return new AppointmentCreated(appointmentId: Guid.NewGuid(),startTime: DateTimeOffset.Now.AddHours(3),endTime: DateTimeOffset.Now.AddHours(4),title:"Appointment"
);}private AppointmentRenamed CreateAppointmentRenamedEvent(){return new AppointmentRenamed(title:
"Renamed appointment"
);}private Appointment CreateSut(IEnumerable events){var sut = new Appointment();foreach (var @event in events)sut.ReplayEvent(@event);return sut;}[Fact]public void Reschedule_AppendsAppointmentRescheduled(){
// GIVEN these events have happened
var events = new IEvent[]{CreateAppointmentCreatedEvent(),CreateAppointmentRenamedEvent()};var sut = CreateSut(events);
// WHEN we ask to reschedule
var newStartTime = DateTimeOffset.Now.AddHours(5);var newEndTime = DateTimeOffset.Now.AddHours(6);sut.Reschedule(newStartTime, newEndTime);
// THEN does the AppointmentRescheduledEvent get published?
sut.AppendedEvents.ShouldAllBeEquivalentTo(new[]{new AppointmentRescheduled(newStartTime, newEndTime)},config => config.RespectingRuntimeTypes());}

请注意，测试可以分为三个逻辑部分：给定的一些状态，什么时候一个动作执行，那么我们可以观察到这种行为吗？这种测试正式的语言为：Cucumber 。类比事件溯源是非常强大的思维方式，但它不真的是新的。我们大多数人都是熟悉的系统中都存在它。一些例子：1.您的银行帐户可能存储使用事件溯源。当前账户余额只是你所做的所有存款和取款的最终结果。2.版本控制系统。每个提交或更改到文件都是一个事件。如果您重播所有的事件，您将得到源代码的当前状态。3.大多数大型RDBM关系数据库内部使用事件溯源。简单地说，只有三个事件：插入，更新和删除。RDBMS存储事件在事务日志中并将其运用到数据表操作上。