使用Kafka Streams构建事件源系统的经验
在基辅召开的JEEConf会议上，Amitay Horwitz描述了他和他的团队如何实施事件溯源的发票系统，他们在生产2年半后遇到的挑战以及他们如何使用Kafka Streams实施新设计。
Wix的软件工程师Horwitz 于2015年开始与他的团队一起开展新的发票服务，目的是帮助他们的客户管理发票并在线接收付款。在设计新服务时，他们希望创建一个小而简单的库，该库非侵入式，维护数据完整性，并且能够轻松添加自定义视图。为了实现所有目标，他们决定使用事件源架构来实现服务。
他们也遇到了问题，客户有时无法看到新创建的发票，因为从写入到读取是最终一致性。
但他们最大的问题是重建视图。确保在没有事件进入的情况下触发重建，事实证明它比预期的更复杂，特别是在具有来自各种服务器的事件的分布式环境中。这些问题使Horwitz寻求替代架构，同时保持事件溯源的好处。
Horwitz将Kafka描述为一个复制的，容错的，分布式附加日志。它通常用于pub-sub或队列，但他指出它可以做更多。Kafka中的基本结构是一个分区的主题，一个逻辑队列。生产者将根据消息中的key将消息推送到每个分区，然后消费者可以使用这些消息。对于事件源系统至关重要的两个重要特性是在单个分区内维护消息之间的排序，并且消息即使在消耗之后也可以存储。
Kafka Streams将流处理带给了Kafka。它有两个主要的抽象：
1. Horwitz认为流中的数据流是一种无限有序和可重放的不可变数据序列，这使得它对于事件源系统来说很有趣。保证了顺序。
2. 能在静态数据中看到Table，表Table存储聚合数据的某个时间点状态视图，该视图在接收到新消息时更新。
在使用Kafka的发票服务的新设计中，有一个快照状态存储，用于保存每个聚合的当前状态，从命令流接收命令后，命令处理程序Handler会根据聚合ID从快照状态存储中读取相应聚合的当前状态；然后，该处理程序Handler确定命令是成功被执行还是失败了，并通过结果流返回结果；如果命令执行成功，则会创建事件并将其发送到事件存储库；接下来，读取这边系统查询有新事件的流，并将状态存储中的聚合更新为其新状态（banq注：注意更新状态在读取这边，不是写入那边），他指出，命令处理程序Hanlder逻辑可以用非常简洁和声明的方式编写，在他的示例中只有60行Scala代码。
在新的架构中，Kafka位于中心，微服务与Kafka通信，彼此之间也通过Kafka进行通信。他们还可以在创建分析报告时将信息推送到Kafka或提取信息，总之，Horwitz指出，新设计给了他们几个优势：
1. 一个简单的声明式系统
2. 最终的一致性现在已被接受并优雅地处理
3. 添加或更改视图很容易
4. 使用Kafka提高了可扩展性和容错能力
新设计仍处于评估阶段，尽管他们在生产中大量使用卡夫卡。他指出，有人声称Kafka不适合CQRS或事件来源系统，但他认为，如果能进行权衡，Kafka可以被利用。如果使用不同的客户端属性保存页面视图事件，就可以根据该事件信息轻松创建聚合，这是一种事件溯源形式，他认为Kafka非常适合。
通过使用聚合的标识作为Kafka的分区键key，同一聚合的所有命令将最终位于命令主题的同一分区中，并将在单个线程中（单写）按顺序处理。这样，在前一个生成所有下游事件之前不会处理任何命令，并且Horwitz指出这将创建强大的一致性保证。
https://www.infoq.com/news/2018/07/event-sourcing-kafka-streams