事件驱动的微服务体系结构中的数据
我试图构建一个事件驱动的微服务体系结构，据我所知它建议构建我的服务而不是一个数据库，而是使用基于事件驱动的事件存储技术微服务架构。事件驱动的微服务体系结构中的数据
我的问题是，如果我的服务很小，完全独立于每个服务，并且每个服务都没有专用DB，那么我的Event Store应该作为一个单独的“服务”来存储其他服务事件“ ？
如果是，则其中一个事件存储组件是消息总线（如apache Kafka），以便服务可以使用和发布事件，这是否意味着事件存储域是虚拟的？ （因为包括Kafka在内的所有组件都未被封装为一个单元）。
我不会建议构建一个应用程序，它必须在没有任何永久存储的情况下保留数据。即使可以永久存储事件队列，对于随机数据访问来说也不是很好。想象一下，您的应用需要访问存储在队列中间的一些用户信息。由于您没有事件ID，您必须重新处理队列才能找到非常缓慢的信息。
事件队列对于分离服务依赖性很有用，但它不是一个好的永久数据存储。通常情况下，您需要处理与服务相关的消费者的队列，这些消费者将数据转换并转换为对服务有用的格式和存储。
事件存储可以无非是重播，完全的事件日志多了，再生一个服务的原始状态。如果您在Kafka中使用压缩主题，则可以最小化还原时间（压缩主题只会丢弃同一个键的旧事件）。这对于运行时状态很好。
有许多方便查询的选项。如果你不介意进入整个KStreams的事情，最简单的是实现KTable或State Store中的可查询视图。这是一个数据库（它在幕后使用RocksDB）构建在您的服务中。它充当支持日志中的数据的磁盘备份缓存。这具有支持流可以被许多服务共享的有用属性，但物化视图完全由每个服务拥有。
更一般地说，一个好方法是做最简单的事情，然后进行演变。尽量保持服务无状态和事件驱动。如果您的需求需要有状态的元素，则拉入KTables或州商店。如果您的数据需求增长，请考虑分支出独立的数据库。如果您开始使用kafka支持的商店，则通常可以使用Connect api相对轻松地迁移数据（尽管您的逻辑可能会受到影响）。
这种类型的实现值得注意的一个窍门是避免在服务之间合成请求 - 响应通道。相反，请遵循“事件驱动架构”，您可以在其中构建事件的共享叙述。马丁福勒有一段时间在这个a good write up。他称之为事件协作。 “
”完全独立“排除”没有针对每项服务的专用数据库“ –
是您的问题：”我应该为每个微服务拥有一个'Event store'实例还是一个全局'Event store'来存储来自所有微服务的事件？ “ –