我们真的需要微服务中的事件源和CQRS吗？
根据我的理解，当数据库事务跨越微服务时，我们可以通过使用message-broker(kafka、RabbitMQ等）通过发布事件来解决这个问题，这样订阅者微服务就可以通过监听这些事件来更新他们的数据库。
在异常情况下，我们可以发送故障事件，以便订阅服务器服务更新它们的状态。
我们真的需要事件来源吗？
共有1个答案
一点也不。您可以拥有一个定义良好的微服务样式的体系结构，而无需CQRS和事件源。CQRS和事件源是一种内部微服务设计的解决方案。您可以选择使用CQRS和事件源实现所有或部分微服务。
让我们看看事件源可能会如何帮助您。事件源是使用事件而不是ORM（如实体框架或Hibernate）和SQL数据库还原实体当前状态的一种替代方法。假设您有一个微服务来存储关于书籍的数据。如果使用SQL，您将有控制器和endpoint来创建、更新和删除一本书，并将这些书存储在SQL表中。如果您想更新这本书，那么为了获得当前状态，您将返回SQL表并查询这本书（通过它的id），然后您的ORM将该表表示形式转换为一个图书对象（对象-关系阻抗不匹配问题），然后您将应用更改并将更改后的图书对象保存回SQL表。作为替代方案，您可以将books对象的事件存储在NoSQL数据库中，比如MongoDB或事件存储库中。现在，为了更新这本书，首先您需要恢复当前状态，您可以通过返回与这本书相关的所有事件并重播这些事件来恢复当前状态来实现这一点。您的事件成为真理的来源，并且您完全避免了ORM映射和SQL连接的瓶颈。事件存储为JSON文档，并且通常速度超快。
现在，使用CQRS-CQRS纯粹是一种分离关注点的模式。您可以使用CQRS将读端和写端分开。与写端相关的endpoint，如创建、更新和删除，生活在一个服务中，而读取端的endpoint生活在另一个服务中。您在这里获得的优势是独立的伸缩、部署、维护等。如果您的应用程序是读取密集型的，那么应该为读取端服务部署多个实例。
如果你想了解更多，请随时PM我。祝你好运！
-
本文向大家介绍为什么我们需要微服务容器？相关面试题，主要包含被问及为什么我们需要微服务容器？时的应答技巧和注意事项，需要的朋友参考一下 要管理基于微服务的应用程序，容器是最简单的选择。它帮助用户单独部署和开发。您还可以使用Docker将微服务封装到容器的镜像中。没有任何额外的依赖或工作，微服务可以使用这些元素。
-
我们有一个侦听事件的微服务，现在让我们调用这个。它侦听RabbitMQ上的审计事件()。任何想要调用的人都需要创建并激发。我们在一个公共模块中共享了pojo，因此可以共享它。 注意，最后一部分需要是同步的，这意味着如果数据库保存失败，我们不想发送电子邮件或类似的东西。目前，这是通过从中的事件处理程序中调用commandGateway来完成的，从调用commandGateway是否正确，如果不正确，
-
很明显，基于这些模式的系统是易于扩展的。但我想问你，具体怎么做？关于可伸缩性，我没有什么问题： 如何缩放聚合体？如果我将创建
-
我想创建一个CQRS和事件源架构，非常便宜，非常灵活，非常简单。 我想确保事件永远不会失败，至少到达发布者/事件存储，永远，因为这是业务所在。 天蓝 有了azure，我似乎不知道该用什么。 Azure服务总线 蔚蓝函数 Azure webjob（我想这可以用Azure函数代替） ？？（还有什么我忘了或者不知道的？） null 你的经验说明了什么？ 其他替代方案呢？（例如:)？
-
我开始阅读与CQRS相结合的事件源模式。据我所知，CQRS模式是一种将写操作和读操作分开的模式。事件源是一种模式，系统中的一切都由触发事件的命令启动。事件源模式需要一个事件总线。有几件事我没弄明白。 事件存储区包含发生在某个实体上的所有事件。如果我想查询这个实体的当前状态，我需要查询发生在这个实体上的所有事件，并重新创建它的当前状态。 所有事件历史记录都在事件存储区中。 为什么我不能有一个负责将每
-
我一直在读关于微服务和事件来源的文章，以及它是如何将服务从另一个服务中分离出来的。有两个概念我不清楚。首先，如果在微服务体系结构中，每个服务都可以独立开发，我们如何解释服务间的通信依赖？ 例如，如果服务A和服务B需要通信，那么A需要将一个事件发送到一个中央总线，而B需要监听该事件并根据该事件采取行动，但这似乎会产生很多依赖关系。现在，如果我正在开发服务B，我需要知道服务A可以生成的所有事件。此外，