后端开发实践系列之四——简单可用的CQRS编码实践

显示全部楼层 · 2019-10-12 10:23:24

本文只讲了一件事情：软件模子中存在读模子和写模子之分，CQRS便为此而生。

20多年前，Bertrand Meyer在他的《Object-Oriented Software Construction》一书中提出了CQS（Command Query Seperation，下令查询分离）的概念，指出：

Every method should either be a command that performs an action, or a query that returns data to the caller, but never both. (一个方法要么作为一个“下令”实验一个操作，要么作为一次“查询”向调用方返回数据，但两者不能共存。）

这里的“下令”可以理解为更新软件状态的写操作，Martin Fowler将此称为“Modifier”；而“查询”即为读操作，是无副作用的。这种分离的好处在于使步调变得更轻易推理与维护，由于查询操作不会更新软件状态，在编码时我们将更加有信心。试想，假如步调中出了一个bug，假如这个bug出如今查询过程中，那么我们至少可以消除这个bug大概给软件带来脏数据的恐惊。

后来，Greg Young在此基础上提出了CQRS（Command Query Resposibility Segregation，下令查询职责分离），将CQS的概念从方法层面提拔到了模子层面，即“下令”和“查询”分别使用差别的对象模子来表示。

接纳CQRS的驱动力除了从CQS那边继承来的好处之外，还旨在管理软件中日益复杂的查扣题目，比如偶然我们渴望从差别的维度查询数据，或者需要将各种数据进行组合后返回给调用方。此时，将查询逻辑与业务逻辑糅合在一起会使软件迅速腐化，诸如逻辑混乱、可读性变差以及可扩展性降低等等一些列题目。

一个例子

设想电商体系中的订单（Order）对象，一开始其对应的OrderRepository类可以简单到只包罗2个方法：

<code>public interface OrderRepository {
void save(Order order);
Order byId(String id);
}</code>

复制代码

在项目标演进中，你大概需要依次实现以下需求：

查询某个Order详情，详情中不消包罗Order的某些字段；
查询Order列表，列表中所展示的数据比Order详情更少；
根据时间、种别和金额等多种筛选条件查询Order列表；
展示Order中的产品（Product）概要信息，而Product属于另一个业务实体；
展示Order下单人的昵称，下单人信息属于另一个单独的账户体系，用户修改昵称之后，Order下单人昵称也需要相应更新；
......

当这些需求实现完后，你大概会发现OrderRepository和范畴模子已经被各种“查询”功能淹没了。什么？OrderRepository不是给范畴模子提供Order聚合根对象的吗，为什么却充斥着如此多的查询逻辑？

CQRS通过单独的读模子管理上述题目，其大抵的架构图如下：

对于Command侧，紧张的讲究是将业务用例建模成对应的Command对象，然后在对Command的处理流程中应用焦点的业务逻辑，此中最紧张的是范畴模子的建模，关于此的内容请参考笔者的《范畴驱动筹划(DDD)编码实践》文章，本文偏重先容Query侧的编码实践。

在本文中，查询模子（Query Model）也被表达为读模子（Read Model）；下令模子（Command Model）也被表达为写模子（Write Model）。

CQRS实现模式概览

常见误解

在网上搜索一番，你会发现很多关于CQRS的文章都将CQRS与Event Sourcing（事故溯源）结合起来使用，这轻易让人以为接纳CQRS就肯定需要同时使用Event Sourcing，毕竟上这是一种误解。CQRS究其本意只是要求“读写模子的分离”，并未要求使用Event Sourcing；再者，Event Sourcing会极大地增加软件的复杂度，而本文寻求的是“简单可用的CQRS”，因此本文将不会涉及Event Sourcing相关内容。更多内容，请参考简化版CQRS的文章。

别的需要指出的是，读写模子的分离并不肯定意味着数据存储的分离，不外在现实应用中，数据存储分离是一种常见的CQRS实践模式，在这种模式中，写模子的数据会同步到读模子数据存储中，同步过程通常通过消息机制完成，在DDD场景下，消息通常承载的是范畴事故（Domain Event）。

查询模子的数据来源

无论是单体还是微服务，所读数据的唯一正确来源（Single Source of Truth）终极都来自于业务实体（Entity）对象（比如DDD中的聚合根），基于此，所读数据的来源形式大抵分为以下几种：

所读数据来源于同一个历程空间的单个实体（后文简称“单历程单实体”），这里的历程空间指某个单体应用或者单个微服务；
所读数据来源于同一个历程空间中的多个实体（后文简称“单历程跨实体”）；
所读数据来源于差别历程空间中的多个实体（后文简称“跨历程跨实体”）。

读写模子的分离形式

CQRS中的读写分离存在2个条理，一层是代码中的模子是否需要分离，另一层是数据存储是否需要分离，总结下来有以下几种：

共享存储/共享模子：读写模子共享数据存储（即同一个数据库），同时也共享代码模子，数查询据通过模子转换（Projection）后返回给调用方，毕竟上这不能算CQRS，但是对于很多中小型项目而言已经足够；
共享存储/分离模子：共享数据存储，代码中分别创建写模子和读模子，读模子通过最恰当于查询的方式进行建模；
分离存储/分离模子：数据存储和代码模子都是分离的，这种方式通常用于需要聚合查询多个子体系的情况，比如微服务体系。

将以上“查询模子的数据来源”与“读写模子的分离形式”相组合，我们可以得到以下差别的CQRS模式及着实用范围：

数据来源形式	模子分离形式	实用范围
单历程单实体	共享存储/共享模子	着实算不上CQRS，但对于很多中小型项目已经足够
单历程单实体	共享存储/分离模子	实用于单实体查询比力复杂或者对查询服从要求较高的场景
单历程单实体	差别存储/分离模子	实用于对单个实体的查询非常复杂的场景
单历程跨实体	共享存储/共享模子	不实用
单历程跨实体	共享存储/分离模子	实用于查询比力复杂的场景，比如需要做多表join操作
单历程跨实体	分离存储/分离模子	实用于复杂查询或者对查询服从要求较高的情况
跨历程跨实体	共享存储/共享模子	不实用
跨历程跨实体	共享存储/分离模子	不实用
跨历程跨实体	分离存储/分离模子	紧张用于微服务中需要对多个服务进行聚合查询的场景

总结下来，有以下几种常见做法：

单历程单实体 + 共享存储/共享模子
单历程单实体 + 共享存储/分离模子
单历程跨实体 + 共享存储/分离模子
单历程跨实体 + 分离存储/分离模子
跨历程跨实体 + 分离存储/分离模子

接下来，针对以上几种常见做法，本文将依次给出编码示例。

CQRS编码实践

本文的示例是一个简单的电商体系，此中包罗以下微服务：

服务	用途	所含实体	Git地址
订单服务	用于用户下单	Order	ecommerce-order-service
订单查询服务	用于订单的CQRS查询操作	无	ecommerce-order-query-service
产品服务	用于管理/展示产品信息	Product Category(产品目录)	ecommerce-product-service
库存服务	用于管理产品对应的库存	Inventory	ecommerce-inventory-service

示例代码请参考：

https://github.com/e-commerce-sample

请注意，本文的示例电商项目只是一个假造出来的简单项目，仅仅用于演示CQRS的各种编码模式，并不具备现实参考价值。

针对以上各种CQRS模式组合，本文将使用电商体系中的以下业务用例进行演示：

CQRS模式	业务查询用例	所属服务
单历程单实体 + 共享存储/共享模子	Inventory详情查询	库存服务
单历程单实体 + 共享存储/分离模子	Product择要查询	产品服务
单历程跨实体 + 共享存储/分离模子	Product详情查询（包罗Category信息）	产品服务
单历程跨实体 + 分离存储/分离模子	Product详情查询（包罗Category信息）	产品服务
跨历程跨实体 + 分离存储/分离模子	Order详情查询（包罗Product信息）	订单查询服务

1. 单历程单实体 + 共享存储/共享模子

对于简单的单体或者微服务应用，这种方式是最自然最直接的方式，毕竟上我们并不需要太多筹划上的思考便能想到这种方式。在这种方式中，存在单个范畴实体模子同时用于读写操作，在向调用方返回查询数据时，需要针对性地对范畴模子进行转换，转换的目标在于：

调用方所需的数据模子与范畴模子大概不同等；
有些敏感信息是不能返回给调用方的，需要屏蔽；
从筹划上讲，范畴模子不能直接返回给调用方，否则会产生范畴模子的走漏
将范畴模子直接返回给调用方会在范畴模子与对外接口间产生强耦合，倒霉于范畴模子自身的演进。

这里，我们以“库存(Inventory)详情查询”为例进行演示，Inventory范畴模子定义如下：

<code>public class Inventory{
private String id;
private String productId;
private String productName;
private int remains;
private Instant createdAt;
}</code>

复制代码

在获取Inventory详情时，我们并不需要返回范畴模子中的productId和createdAt字段，于是在Inventory中创建相应的转换方法如下：

<code> public InventoryRepresentation toRepresentation() {
return new InventoryRepresentation(this.id,
this.productName,
this.remains);
}</code>

复制代码

这里的InventoryRepresentation即表示读模子，后缀Representation取自REST中的“R”，表示读模子是一种数据显现，下文将相沿这种定名形式。在InventoryApplicationService服务中返回InventoryRepresentation:

<code> public InventoryRepresentation byId(String inventoryId) {
return repository
.byId(inventoryId)
.toRepresentation();
}</code>

复制代码

值得一提的是，在查询Inventory时，我们使用了应用服务（ApplicationService）-InventoryApplicationService，此时的InventoryApplicationService同时负担了读操作和写操作的业务入口，在实践中也可以将此二者分脱离来，即让InventoryApplicationService只负责写操作，而另行创建InventoryRepresentationService专门用于读操作。

别的，抛开CQRS，为了包管每一个聚合根实体自身的完备性，即便在没有调用方查询的情况下，笔者也发起为每一个聚合根提供一个Representation 并对外袒露查询接口。因此每一个聚合根中都会有一个toRepresentation()方法，该方法仅仅返回当前聚合根的状态，而不会关联其他实体对象（比如下文提到的“单历程跨实体”）。

2. 单历程单实体 + 共享存储/分离模子

偶然，即便是对于单个实体，其查询也会变得复杂，为了维护读写过程相互的清晰性，我们可以对读模子和写模子分别建模，毕竟上这也是CQRS的本意。

在Product服务中，需要返回Product的择要信息，并对返回列表进行分页处理，为此独立于ApplicationService创建ProductRepresentationService，直接从数据库读取数据构建ProductSummaryRepresentation。

<code> @Transactional(readOnly = true)
public PagedResource<ProductSummaryRepresentation> listProducts(int pageIndex, int pageSize) {
MapSqlParameterSource parameters = new MapSqlParameterSource();
parameters.addValue("limit", pageSize);
parameters.addValue("offset", (pageIndex - 1) * pageSize);
List<ProductSummaryRepresentation> products = jdbcTemplate.query(SELECT_SQL, parameters,
(rs, rowNum) -> new ProductSummaryRepresentation(rs.getString("ID"),
rs.getString("NAME"),
rs.getBigDecimal("PRICE")));
int total = jdbcTemplate.queryForObject(COUNT_SQL, newHashMap(), Integer.class);
return PagedResource.of(total, pageIndex, products);
}</code>

复制代码

这里，我们绕过了范畴模子Product，也绕过了其对应的ProductRepository，以最快速的方式从数据库中直接获取数据。

3. 单历程跨实体 + 共享存储/分离模子

既然单个实体都有必要使用分离模子，那么在同一个历程空间中的跨实体查询更有来由使用分离模子的形式。对于简单形式跨实体查询，还用不着使用分离的存储，只需要做一些join团结查询即可。

在Product服务中，存在Product和Category两个聚合根对象，在查询Product时，我们渴望一并带上Category的信息，为此创建ProductWithCategoryRepresentation如下：

<code>@Value
public class ProductWithCategoryRepresentation {
private String id;
private String name;
private String categoryId;
private String categoryName;
}</code>

复制代码

在ProductRepresentationService中，直接从数据库获取Product和Category数据，此时需要对PRODUCT和CATEGORY两张表做join操作：

<code> @Transactional(readOnly = true)
public ProductWithCategoryRepresentation productWithCategory(String id) {
String sql = "SELECT PRODUCT.ID, PRODUCT.NAME, CATEGORY.ID AS CATEGORY_ID, CATEGORY.NAME AS CATEGORY_NAME FROM PRODUCT JOIN CATEGORY ON PRODUCT.CATEGORY_ID=CATEGORY.ID WHERE PRODUCT.ID=:productId;";
return jdbcTemplate.queryForObject(sql, of("productId", id),
(rs, rowNum) -> new ProductWithCategoryRepresentation(rs.getString("ID"),
rs.getString("NAME"),
rs.getString("CATEGORY_ID"),
rs.getString("CATEGORY_NAME")));
}</code>

复制代码

需要注意的是，假如join的级联太多，那么会大大影响查询的服从，并且使步调变得更加复杂。一般来讲，假如join次数达到了3次及其以上，发起思量接纳分离存储的形式。

4. 单历程跨实体 + 分离存储/分离模子

依然以返回ProductWithCategoryRepresentation为例，假设我们以为先前的join操作太复杂或者太低效了，需要接纳专门的数据库来简化查询提拔服从。

为此创建单独的读模子数据库表PRODUCT_WITH_CATEGORY：

<code>CREATE TABLE PRODUCT_WITH_CATEGORY
(
PRODUCT_ID VARCHAR(32) NOT NULL,
PRODUCT_NAME VARCHAR(100) NOT NULL,
CATEGORY_ID VARCHAR(32) NOT NULL,
CATEGORY_NAME VARCHAR(100) NOT NULL,
PRIMARY KEY (PRODUCT_ID)
) CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;
</code>

复制代码

读写同步通常通过范畴事故的形式完成，由于是在同一个历程空间中，因此读写同步相比于跨历程的同步来说，可以有更多的选择：

使用历程内事故机制（比如Guava的EventBus），在与写操作雷同的事件中同步，这种方式的好处是可以包管写操作与同步操作的原子性进而确保读写间的数据同等性，缺点是在写操作过程中存在额外的数据库同步开销进而增加了写操作的延迟时间；
使用历程内事故机制，独立事件同步（比如Guava的AsyncEventBus），这种方式的好处是写操作和同步操作相互独立互不影响，缺点是无法包管二者的原子性进而大概使体系产生脏数据；
使用独立的消息机制（比如RabbitMQ/Kafka等），独立事件同步，可以将查询功能分离为单独的子体系，毕竟上这种方式已经与“跨历程跨实体 + 分离存储/分离模子”相似，因此请参考“5. 跨历程跨实体 + 分离存储/分离模子”末节。

5. 跨历程跨实体 + 分离存储/分离模子

这种方式在微服务中最常见，由于微服务体系首先是多历程的，每个服务都内聚性地管理自身的聚合根对象，别的，微服务的数据存储通常也是独占式的，意味着在微服务体系中数据存储肯定是分离的，在这种场景下，跨微服务之间的查询通常接纳“API Compositon”模式或者本文的CQRS模式。

在"跨历程跨实体 + 分离存储/分离模子"中，存在一个单独的查询服务用于CQRS的读操作，查询所需数据通常通过事故机制从差别的其他业务服务中同步而来，读操作所返回的数据通过API Gateway或者BFF向外袒露，示意图如下：

在本文的示例电商项目中，需要在查询Order的时间同时带上Product的信息，但是由于Order和Product分别属于差别的服务，为此创建ecommerce-order-query-service查询服务，该服务负责吸收Order和Product服务发布的范畴事故以同步其自身的读模子OrderWithProductRepresentation。

在ecommerce-order-query-service服务中，在吸收到OrderEvent事故后，OrderQueryRepresentationService负责分别调用Order和Product的接口完成数据同步：

<code> public void cqrsSync(OrderEvent event) {
String orderUrl = "http://localhost:8080/orders/{id}";
String productUrl = "http://localhost:8082/products/{id}";
OrderRepresentation orderRepresentation = restTemplate.getForObject(orderUrl, OrderRepresentation.class, event.getOrderId());
List<Product> products = orderRepresentation.getItems().stream().map(orderItem -> {
ProductRepresentation productRepresentation = restTemplate.getForObject(productUrl,
ProductRepresentation.class,
orderItem.getProductId());
return new Product(productRepresentation.getId(),
productRepresentation.getName(),
productRepresentation.getDescription());
}).collect(Collectors.toList());
OrderWithProductRepresentation order = new OrderWithProductRepresentation(
orderRepresentation.getId(),
orderRepresentation.getTotalPrice(),
orderRepresentation.getStatus(),
orderRepresentation.getCreatedAt(),
orderRepresentation.getAddress(),
products
);
dao.save(order);
log.info("CQRS synced order {}.",orderId);
}</code>

复制代码

在本例中，ecommerce-order-query-service查询服务使用了关系型数据库，但在现实应用中应该根据项目所需选择恰当的数据存储机制。例如，对于海量数据的查询，可以选择诸如MongoDB或者Cassandra之类的NoSQL数据库；而对于需要进行全文搜索的场景，可以接纳Elasticsearch等。

毕竟上，在吸收并处理事故时，存在2中风格，一种是本例中的仅将事故作为消息关照，然后调用其他服务的API接口完成同步，另一种是直接使用事故所携带的数据进行同步，更多关于这2种风格的比力，请参考笔者的《事故驱动架构(EDA)编码实践》文章。

事故驱动架构总是意味着异步，它将给软件带来以下方面的影响：

读模子和写模子之间不再是强事件同等性，而是终极同等性。
从用户体验上讲，用户发起操作之后将不再立即返回结果数据，此时要么需要调用方（比如前端）进行轮询查询，要么需要在用户体验上[做些衡量】(http://danielwhittaker.me/2014/10/27/4-ways-handle-eventual-consistency-ui/)，比如使用确认页面延迟用户对查询数据的获取。