我一直在研究微服务，尤其是 this video 提出的 CQRS 模式。我认为命令部分对我来说很容易理解，只要我接受最终的一致性并且很好。但是，当您使用其 API 对非规范化查询层进行简单查询时会发生什么。我这样想是因为当查询正确时，您可能会将非规范化数据延迟加载到查询层？特别是如果您要查询的数据实际上是分散在微服务中的数据的聚合，您是否必须求助于使用某种上下文 ID 触发 fetch data 事件的大规模编排，然后所有微服务依次发布它们的数据相同的上下文 ID 以便反规范化器可以侦听并将聚合数据填充到其层并最终响应客户端？
【问题讨论】：
标签： cqrs
您描述的实际上是 API 组合模式 - https://microservices.io/patterns/data/api-composition.html
在 CQRS 中，将使用单独的数据库进行查询。结果将直接从此专用数据库中检索。
CQRS 通常与事件溯源模式相结合。 (https://microservices.io/patterns/data/event-sourcing.html) 这意味着系统中的任何状态变化都将由一个事件来表示。
在查询服务/逻辑中，您需要订阅所有感兴趣的事件，并在事件处理程序中相应地更新查询数据库中的数据。因此查询数据库中的数据最终与命令端数据库中的数据一致。
(https://microservices.io/patterns/data/cqrs.html)
CQRS 使查询更容易/更有效，并改进了关注点分离。 但是，正如您所看到的，它的实现比 API 组合更复杂，并且它有一个先天的问题 - 复制滞后 - 查询数据库中的数据可能无法反映最新状态。所以一般建议尽可能使用 API 组合，仅在必要时使用 CQRS。
【讨论】：