据我了解，我正在尝试构建事件驱动的微服务架构。建议在没有数据库的情况下构建我的服务，而是使用基于事件驱动微服务的事件存储技术建筑。
我的问题是，如果我的服务很小并且彼此完全独立，包括每个服务没有专用数据库，我的事件存储是否应该作为一个单独的单元“服务”来保存其他服务事件？
如果是，事件存储组件之一是消息总线（如 apache Kafka），以便服务可以消费和发布事件，这是否意味着事件存储域是虚拟的？ （因为包括 Kafka 在内的整个组件没有被打包为一个单元）。
【问题讨论】：
Event store 实例还是一个全局 Event store 来保存来自所有微服务的事件？”
标签： architecture apache-kafka microservices datastore event-sourcing
我不建议构建一个必须在没有任何永久存储的情况下保留数据的应用。即使可以永远存储事件队列，但对于随机数据访问来说并不是很好。想象一下，您的应用程序需要访问存储在队列中间的一些用户信息。由于您没有事件 ID，因此您必须重新处理队列才能找到非常慢的信息。
事件队列对于解耦服务依赖很有用，但它不是一个好的永久数据存储。通常，您需要使用依赖于服务的消费者来处理队列，这些消费者将数据转换并移动为对服务有用的格式和存储。
【讨论】：
事件存储只不过是完全重放的事件日志，以重新生成服务的原始状态。如果您在 Kafka 中使用压缩主题，则可以最小化恢复时间（压缩主题只会丢弃相同键的旧事件）。这对于运行时状态很好。
有许多选项可以方便查询。如果您不介意深入了解整个 KStreams，最简单的方法是在 KTable 或 State Store 中实现可查询视图。这是在您的服务中构建的数据库（它在幕后使用 RocksDB）。它充当支持日志中数据的磁盘支持缓存。这有一个有用的属性，支持流可以由许多服务共享，但物化视图完全由每个服务拥有。
更一般地说，一个好的方法是做最简单的事情，然后发展它。尽量保持服务无状态和事件驱动。如果您的需求需要有状态的元素，请引入 KTables 或状态存储。如果您的数据需求增长，请寻求扩展到独立数据库。如果您从 kafka 支持的存储开始，您通常可以使用 Connect api 相对轻松地迁移数据（尽管您的逻辑可能会受到影响）。
对于这种类型的实现，一个值得注意的技巧是避免在服务之间合成请求-响应通道。而是遵循事件驱动架构，您可以在其中建立事件的共享叙述。不久前，Martin Fowler 对此有 a good write up。他称之为事件协作。
【讨论】：