Events 关于事件源、微服务、CQR的说明

我目前正在构建一个应用程序，我想使用微服务作为模式和GraphQl进行通信。我正在考虑使用kafka/rabbitmq+authZ+auth0+apollo+prisma。所有这些都在docker上运行。 我发现了很多关于事件来源、优势/劣势的资源，我一直在关注它在现实世界中的工作方式。就目前而言，我将这样做：

阿波罗引擎监控请求/响应。。 用于身份验证管理的身份验证0 授权授权 graphql网关。遗憾的是，我没有找到可靠的解决方案，我想我必须自己使用apollo+graphql工具来合并模式。 理想情况下：

Prisma代表比尔女士的阅读侧 bill的MS的书写端点头 现在，如果我理解正确，使用ApacheKafka+zookeeper：

作为消息代理的卡夫卡 Zookeeper作为事件商店。 如果我是对的，我可以假设：

有两种方法可以验证请求是否有效：

Write端只从事件存储（也称为zookeeper）获取事件，以验证请求的变异是否可能。 Write方面从传统数据库获取快照，以验证请求的变异。 然后它向kafka发布一个事件，我假设kafka会自动更新zookeeper，然后读取端可以使用该消息更新实体的私有快照。当然，其他人也可以使用此消息。 我不太了解ApacheKafka+zookeeper，过去我只使用rabbitmq作为消息传递服务。它们在形状上似乎相似，但在用法上却大不相同

事件源和基本消息传递之间的主要区别在于使用事件存储而不是实体的快照？在这种情况下，我们是否可以假设并非所有MS都需要事件存储策略？我的意思是，通过事件存储而不是通过私有数据库进行验证？如果是，是否有人能解释您何时需要活动商店，何时不需要？

---

我将尝试在概念层面上回答您的主要担忧，而不必拘泥于框架和实现的细节。希望这会有所帮助

有两种方法可以验证请求是否有效：

。Write端只从事件存储（也称为zookeeper）获取事件，以验证请求的变异是否可能

。Write方面从传统数据库获取快照，以验证请求的变异

我会选择第一种。要执行命令，您应该依赖当前事件流作为权限来确定模型的当前状态

体系结构的读取模型最终是一致的，这意味着在命令发生和它在读取模型上的反映之间存在任意延迟。尽管您可以在您的体系结构上工作，以确保延迟尽可能小，即使您忽略了这样做的成本，但您的读取模型仍然不是最新的

也就是说，您的命令应该基于当前事件存储针对您的命令模型运行

事件源和基本消息传递之间的主要区别在于使用事件存储而不是实体的快照？在这种情况下，我们是否可以假设并非所有MS都需要事件存储策略？我的意思是，通过事件存储而不是通过私有数据库进行验证？如果是，是否有人能解释您何时需要活动商店，何时不需要

事件源的整个概念是：不是将状态存储为只反映此类数据最新阶段的可更新数据，而是将状态存储为一系列可解释为达到此类状态的操作事件

因此，假设您有一块域，它以自由形式表示法读取：

实体A={Id:1；名称：某物；}

然后发生了一些事情，一个命令到达，将这个实体的名称更改为另一个东西

在传统存储中，您可以获取此类记录并将其更新为：

{Id:1；Name:Other Thing；}

但在事件源存储中，您不会有这样的记录，而是会有一个事件流，其中包含以下数据：

{创建Id=1的实体}>{将Id=1的实体重命名为某物}>{将Id=1的实体重命名为其他物}

现在，如果您按顺序重放这些事件，您将达到与传统存储相同的状态，只有您知道如何达到该状态，而传统存储将忘记这些历史

现在，回答你的问题，你是绝对正确的。并不是所有的微服务都应该使用事件存储，甚至不建议这样做。事实上，在微服务体系结构中，每个微服务都应该有自己的持久性机制，很多时候，每个微服务都是不同的技术，没有一个微服务可以直接访问另一个微服务的持久性，正如图中所示，另一个微服务可以访问您账单的微服务的事件存储

所以，最基本的决定因素是什么 u应当是：

您的微服务是不是可以从主动存储域内状态的演变而不是被动记录中获得更多

您的微服务领域是您对分析旧计算感兴趣的领域吗？也就是说，能够将域恢复到给定的时间点，这样你就可以理解它的状态的演化模式-在这里考虑一些复杂的审计，你想了解过去的计算< /P> 即使你对这两个问题的回答都是肯定的。。。这种体系结构增加的复杂性值得吗

作为本主题的结束语，请注意，您的模型中有多种模式交织在一起：

事件源只是将状态存储为一系列操作的行为，而不是可更新的中央数据中心。 处理读取模型与命令模型的模式称为CQRS命令查询责任分离

---

这两种模式经常一起使用，因为它们匹配得非常好，但这不是一个先决条件。您可以将数据与事件一起存储，而不必使用CQR将其拆分为两个模型，您可以将域组织为两个模型命令和查询，而无需将它们中的任何一个主要存储为事件。

感谢您的回答。如果事件存储未共享，这是否意味着如果MS需要属于另一个域的信息实体，它应该调用关联MS的读取端？或者它应该存储其他关联MS的所有事件吗？您可以随意选择。在某些情况下，您可能希望通过读取模型向其他MS查询所需的信息，但请注意，您正在创建更高级别的耦合，因为如果无法访问其他MS，您的MS将无法运行。第二种方法是，如果MS-B需要MS-A中某个实体的信息，则MS-B需要订阅该实体更改的通知，并保留此类数据的本地副本，以便在操作过程中更加独立，然后您必须处理最终的一致性问题。似乎没有什么灵丹妙药。谢谢你，我想我会选择一个组合，在我第一次需要实体时查询，然后订阅活动进行更新。非常感谢你