事件源和CQR如何帮助解耦微服务？
事件源和CQR如何帮助实现微服务的解耦架构。
我们可以让微服务拥有自己的数据，其他人通过服务访问数据，即使是通过传统的持久性手段。不是吗？
共有1个答案
事件源和CQR无意用于解耦服务。
使用CQR实现的主要目标是提高服务的性能，因为您可以对写入（命令）和读取（查询）使用不同的持久性类型。
有鉴于此，您可以使用高性能的写类型持久性（如事件日志）来存储服务中发生的所有事件，并使用关系模型（例如）进行读取，在读取中以查询所需的方式存储信息。
实现两个模型之间一致性的方法通常是使用命令模型生成的事件，查询使用这些事件来更新读取模型。这种应用方法的缺点是最终的一致性，因为读取模型的更新不会立即发生。
与cqrs密切相关的是事件源，它规定模型中的所有修改都应该像事件存储中的事件一样存储。这样，您就有了应用程序中所有操作的历史记录。这样做的好处是，您有一个用于审计目的的所有更改的历史记录，并且写入速度非常快。缺点是，如果您想获得当前状态，您必须重放自开始以来的所有事件。
为了解决这个问题，您可以使用cqrs获取实际状态来进行查询
-
我已经意识到事件源、CQRS、DDD和微服务有一段时间了，现在我想尝试并开始实施一些东西并尝试一些东西。 我一直在研究CQRS的技术方面，我理解其中的DDD概念。写入端如何处理来自UI的命令并发布其中的事件，以及读取端如何处理事件并在其上创建投影。 我遇到的困难是沟通 所以我想重点关注eventstore（这一个：https://eventstore.com/不那么模棱两可）。这就是我想要使用的，
-
脚本 我正在使用微服务构建快递服务系统。我不确定一些事情，这是我的场景 预订API-这是客户下订单的地方 付款API-这是我们处理预订付款的地方 通知API-有服务负责在一切完成后发送通知。 系统采用事件驱动架构。当客户下预订订单时，我在预订应用编程接口中提交本地交易并发布事件。支付应用编程接口和通知应用编程接口订阅了各自的事件。一旦完成，支付和通知应用编程接口需要向预订应用编程接口确认。 我的问
-
我正在计划一个使用事件源的微服务模型。为了实现高可伸缩性和高吞吐量处理能力，我将使用Kafka作为微服务的消息代理。 在这一点上，我有问题的实现模型，以能够拥有Kafka主题和分区的好处。我的模型需要满足一些要求： 微服务必须从message broker获取数据(post/patch/put/delete) 数据一致性是强制性的，如果实体A需要实体B的先前存在，则必须只存在实体A的指向实体B的有
-
我们正在设计我们的新系统，它很可能是从头开始编写的，因为旧系统非常非常旧。对我们的系统来说，保留系统中发生的所有事情的审计跟踪日志非常重要。 由于审计跟踪的重要性，我们决定遵循事件源架构以获得它的所有好处。另一个关键因素是我们有多个团队在不同的“域”上工作。也就是说，我们想将每个域拆分为自己的服务（微服务架构），这样每个团队都可以独立工作。 我们面临的最大问题是谁将负责微服务之间的事件共享。例如，
-
假设方法和的责任密切相关 第一个例子： 如果 •和在class中定义（因此class具有高度的内聚性） •类别使用和类别使用 然后 •与和类耦合 •更改的签名只需要更改，而不需要更改 第二个例子： 如果 •在类中定义（因此与耦合） •用类定义（因此与耦合） 然后 •更改的签名只需要更改，而不需要更改 a） 据我所知，上一个例子中的类与第一个例子中的类并不耦合！还是我错过了什么？ b） 据我所知，第
-
我正在为我们的新后端项目考虑一些框架/编程方法。它涉及后端forfrontend实现，该实现聚合了下游服务。为简单起见，以下是它所经历的步骤： 请求进入Web服务器 Web服务器发出下游请求 下游请求返回结果 Web服务器返回请求 事件驱动编程如何比“常规”按请求处理线程更好？一些网站试图解释，它通常归结为这样的东西： 第二种解决方案是非阻塞调用。调用方没有等待答案，而是继续执行，但提供了一个回调