CQRS（命令查询职责分离）是一种在复杂商业应用中非常有用的模式，特别是当读操作和写操作有不同需求时。举个例子，写操作可能想要在关系型数据库中以规范化形式维护一个模型，而读操作则可以将模型表现为文档数据库中的文档。但是理解CQRS并不容易。它涉及到读操作、写操作、事件、命令、领域驱动设计（DDD）、事件溯源以及最终一致性等概念。实现CQRS的常见方式是创建两个服务，并通过事件进行通信。
我们的CQRS实现
为了将CQRS集成到我们的自定义框架中，我们使用了Axon框架。因为Axon是最容易使用的，并且对Spring Boot框架有很好的支持。架构图如下所示：
我们为写入和读取创建了两个单独的服务。这两个服务通过 RabbitMQ 连接。
写入服务
写入服务处理所有的更新操作。我们并没有试图说服开发人员认为写请求就是真正的命令。控制器负责从请求中创建命令，并通过命令网关发布命令。控制器与命令处理程序之间的通信是异步的。命令处理程序通过加载聚合根，执行业务逻辑，然后将事件发布到RabbitMQ来处理命令。与此同时，事件也被保存到事件存储中。在这个实现中，事件存储充当我们的单一真相来源。
读取服务
读取服务处理所有读取请求。这里没有应用任何业务逻辑。通过监听发布到 RabbitMQ 的事件来更新数据。开发人员可以选择任何关系数据库或 MongoDB 作为读取数据库。我们希望开发人员实现的是读取优化的模型。它们可以存储数据而不进行任何规范化以提高读取性能。
这是一个非常简单的实现。我们将读取和写入分为两个服务，那么我们为什么失败了呢？
为什么我们失败了？
1. 异步性
当我们引入CQRS时，开发人员的主要抱怨是“我们将如何更新UI，我们不知道记录是否成功保存”。这是一个非常合理的问题，它涉及到我们所熟悉的同步通信方式。这种方式很好，也是我们从一开始就习惯使用的编码方式。因为它易于推理。我们可以得到请求的完整流程。
那么为什么我们在事件驱动架构（EDA）中使用异步调用呢？很简单，就是为了提高响应能力。EDA 与异步通信无关。我们可以在不使用异步通信的情况下实现 CQRS。
2.工作量大
第二个主要抱怨是“完成基于 CQRS 的微服务需要两倍的工作量。“ 开发人员必须创建两项服务：命令服务和读取服务。但这就是我们实施 CQRS 的方式。
3.对所有服务使用 CQRS
我们告诉开发人员的是在每个微服务中使用 CQRS。我们认为整个系统应该是一个CQRS系统。其结果是引入了难以管理的复杂性，这是我们在实施 CQRS 时犯的主要错误之一。
4.较小的微服务
我们不能说微服务应该有多小，但我们可以确定它的边界。我们可以使用DDD和限界上下文等概念来识别微服务边界。在 CQRS 中，我们使用聚合的概念。聚合是 逻辑上相关的域对象。例如订单和订单项目。我们将订单和订单项目视为一件事。当我们保存订单时，会将其与订单项目一起保存。当我们无法识别聚合时，最终会将其拆分为单独的微服务。这给 CQRS 增加了巨大的复杂性。当收到保存订单的请求时，要如何保存订单项目？
更小的微服务意味着更多的微服务。由于我们将 CQRS 应用于所有服务，最终使服务数量增加了一倍。这是无法控制的。
总结
这次失败的主要原因是因为错误的实现，并且大多数与 CQRS 无关。我们从中学到的是，必须理解微服务和 CQRS 的关键概念，然后才能将它们整合好。
