Apache Kafka是一款很酷的产品，但假如你考虑将其使用于事件溯源，建议你应该再考虑一下。

Kafka是一个在生产者和消费者之间传递消息的绝佳工具，可选的主题持久性能让你永久存储消息，是的，永远，假如你愿意。

因而，假如你的消息是事件，可以将Kafka使用作事件存储或者事件日志，但它实际上不适合使用于事件溯源。

起因如下：

1. 加载当前状态

当服务收到请求对事件源实体进行状态更改的命令时，我们首先需要重新创立该对象的当前状态，我们通过从事件存储加载该特定实体ID的所有先前事件，而后将它们重新调使用我们的领域对象中的相应方法，快速播放事件直到当前状态。

在Kafka中加载像这样的特定实体的事件并不容易。主题通常以 “ 订单 ”，“ 付款 ”或者“ 通知 ” 等实体类型为中心进行分区，因而我们必需检查所有 “ 订单 ”的所有事件，并按其ID过滤它们以得到一个“ 订单”实体的状态，尽管这是可能的，但它并不实使用。

一种替代方案是每个实体有一个主题，但我们最终可能会遇到数以千计的主题，而且最重要的是，订阅服务的下游需要一种方法来自动发现每个新实体的新创立的主题，这 不太实际。

2. 一致的写操作

当我们的实体状态被重新创立时，是时候执行传入命令所请求的业务逻辑了，假如业务逻辑失败，我们会向用户端返回错误，但假如成功则会发出新事件。在这种情况下，我们必需能够将新事件保存到我们的事件存储中，同时保证在此期间没有为此特定实体ID存储其余事件，否则我们可能会破坏领域对象的一致性。

OCC来救援

保证写入一致性的一种方法是利使用事件存储的乐观并发控制，正确的事件存储为使用户提供了一种方式，即“仅当实体的版本仍为x时才保存此事件”，Kafka不支持这一点，来自该领域专家的建议处理方法似乎是在其前面放置一个“数据库”以提供一致性控制点，尽管在某些情况下这个建议可能是一个可行的处理方案，但从长远来看，选择更适合特定问题的工具可能更明智。

3. 单写

取得一致性的另一种方法是确保序列化写入，即便使用单写入器准则，这意味着我们确保关于特定实体ID的所有写入都发生在单个线程上。我们可以通过使我们的生产者堵塞等到其发布的事件被提交且可使用，这种设计会对性能产生严重影响。

它适合吗？

那么，Kafka在事件源架构中能否有一席之地？也许，大概，它可能是你的事件存储的一个很好的补充，作为将事件传输到下游查询服务或者读取模型的方式。

但是，在为我们的系统增加大量复杂的基础设备时，我们应该始终小心 – 所有这些都需要付出成本，因而请确保它足以满足你手头的问题！

Apache Kafka is not for Event Sourcing – SERIALIZE