事件驱动的微服务架构中的数据

Question

我正在尝试构建一个事件驱动的微服务架构，据我所知，我建议构建我的服务没有数据库，而是使用事件存储技术基于事件驱动的微服务架构。

我的问题是，如果我的服务很小并且彼此完全独立，包括没有为每项服务提供专用数据库，那么我的活动商店应该作为一个单独的服务吗？＆＃34; service＆＃34;举办其他服务活动＆＃39;？

如果是，其中一个事件存储组件是消息总线（如apache Kafka），为了使服务可以使用和发布事件，是否意味着事件存储域是虚拟的？ （因为包括Kafka在内的整个组件并没有被打包成一个单元）。

Answer 1

我不建议构建一个必须在没有任何永久存储的情况下保留数据的应用程序。即使可以永久存储事件队列，但对随机数据访问也不是很好。想象一下，您的应用需要访问存储在队列中间的一些用户信息。由于您没有事件ID，因此您必须重新处理队列才能找到非常慢的信息。

事件队列对于解耦服务依赖关系很有用，但它不是一个好的永久数据存储。通常，您希望使用依赖于服务的消费者来处理队列，这些消费者将数据转换并转换为对服务有用的格式和存储。

另见this answer

Answer 2

事件存储只能是完整重播的事件日志，以重新生成服务的原始状态。如果您在Kafka中使用压缩主题，则可以最小化还原时间（压缩主题只会删除相同键的旧事件）。这适用于运行时状态。

有许多便于查询的选项。如果您不介意进入整个KStreams事物，最简单的方法是在KTable或State Store中实现可查询视图。这是在您的服务中构建的数据库（它在幕后使用RocksDB）。它充当备份日志中数据的磁盘备份缓存。这具有许多服务可以共享支持流的有用属性，但物化视图完全由每个服务拥有。

更一般地说，一个好的方法是做最简单的工作，然后进化。尽量保持服务无状态和事件驱动。如果您的要求需要有状态元素，请拉入KTables或州商店。如果您的数据需求增长，请查看分支到独立数据库。如果您从kafka支持的商店开始，通常可以使用Connect api相对轻松地迁移数据（尽管您的逻辑可能会受到影响）。

这种类型的实现值得注意的一个技巧是避免在服务之间合成请求 - 响应通道。而是跟随事件驱动架构，在其中构建事件的共享叙述。不久前，Martin Fowler对此进行了a good write up的讨论。他称之为事件协作。