发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 大数据 扩展性 并发编程 事件驱动 分布式 SOA

什么是事件溯源Event Sourcing?

    
2016-11-04 15:07
赞助商链接

本文比较全面以易懂方式阐述了什么是事件溯源以及优缺点。

什么是Event Sourcing?
“传统”保存应用程序变化数据的方式是存储当前状态。例如,您的应用程序可能是一个日历,所以您想存储约会。它可能看起来像这样:

约会ID 开始时间 结束时间 标题
1 09:30 10:45 会议
2 11:15 11:30 饭局


这是一张看起来很熟悉的数据表。它可能是关系数据库中的一个表,或一个键值存储中的一组文档,甚至一个存储在内存中的对象列表。重点是,它代表了系统的状态,因为它是现在。让我问你一个问题:这个系统是如何进入这个状态的?

审计日志audit log
要回答这个问题,您可以创建一个审计日志。除了记录创建或更新约会,在审计日志中您还将记录描述所发生的事件(一个“事件”)。对于一个单一的约会,它可能看起来像这样:


Sequence 事件Event
1 约会被创建:
时间:09:30 - 10:30
Title: 开会
2 约会重新被安排: 09:30 - 10:45
3 标题被改变: 饭局

相比如果你只有系统的当前状态,这揭示了一个大量的信息。在约会被创建一次,约会改期一次,它的标题被改变了。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<IEvent> 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存储事件在事务日志中并将其运用到数据表操作上。


Event Sourcing: Awesome, powerful & different:

4
EventSourcing     

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com