讀取QPS 10萬，寫入QPS 1000，如何設計系統架構？

你是否也曾深陷在臃腫的領域模型（Domain Model）的泥潭，一個?User?或?Order?實體類，既要處理復雜的業務邏輯和數據校驗，又要承載各種為前端展示而生的DTO轉換，導致模型越來越胖，讀寫性能相互掣肘？是時候用CQRS（命令查詢職責分離）?架構模式來解脫了！這是一種高級的架構模式，它將系統的數據更新操作（命令）和數據讀取操作（查詢）徹底分離，讓它們可以使用各自最優的模型和技術棧。

在 Spring Boot 中，CQRS是構建高性能、高可擴展性復雜業務系統的終極武器。它能將你的系統清晰地劃分為“指揮部”（處理命令）和“情報部”（響應查詢），讓兩側可以獨立演進和優化。本文將探討為什么“一個模型走天下”的傳統CRUD會成為瓶頸，通過一個實際的電商商品服務示例來展示CQRS的強大威力，并一步步指導你如何在 Spring Boot 中實現它 —— 讓我們今天就開始解鎖更高級的系統架構之道吧！

什么是CQRS模式？🤔

CQRS（Command Query Responsibility Segregation）的核心思想是：將一個系統中改變狀態的操作（命令）和讀取狀態的操作（查詢）在模型層面進行分離。

這意味著，同一個業務概念（如“商品”）在系統內部會有兩套完全不同的模型：

??命令模型 (Write Model / Command Model):?用于處理所有的數據創建、更新和刪除操作。這個模型通常是豐富的、包含復雜業務邏輯的領域模型（如JPA實體），并關注數據的一致性和驗證。
??查詢模型 (Read Model / Query Model):?專用于數據讀取和展示。這個模型通常是扁平化的、非規范化的“瘦”對象（如DTO），它被高度優化以滿足前端頁面的快速查詢需求。

這兩個模型之間通過某種機制（如事件、消息隊列、數據庫同步）進行數據同步。

這個模式的實現通常需要：

??命令 (Command):?一個封裝了修改系統狀態意圖的對象（如CreateProductCommand）。它不返回值。
??查詢 (Query):?一個封裝了數據請求的對象（如GetProductByIdQuery）。它只返回數據，不修改任何狀態。
??命令處理器 (Command Handler):?接收并處理命令，與命令模型交互。
??查詢處理器 (Query Handler):?接收并處理查詢，直接訪問查詢模型并返回數據。

為什么要在 Spring Boot 中使用CQRS模式？💡

CQRS能帶來諸多架構上的好處：

??性能與擴展性 (Performance & Scalability):?這是最核心的價值。你可以獨立地對讀、寫兩端進行優化和擴展。如果系統讀多寫少，你可以為查詢端增加多個只讀副本和緩存；如果寫操作復雜，你可以為命令端配置更強大的服務器，二者互不影響。
??優化的數據模型 (Optimized Data Models):?你可以為寫入操作設計一個高度規范化的、保證數據一致性的模型；同時為讀取操作設計一個或多個非規范化的、預先聚合好的“寬表”模型，免去復雜的關聯查詢。
??簡化的邏輯 (Simplified Logic):?命令端的代碼只關心業務邏輯和狀態變更，查詢端的代碼只關心如何最高效地拿數據。職責單一使得兩邊的代碼都更容易理解和維護。
??增強的安全性 (Enhanced Security):?查詢模型和API天然就是只讀的，沒有任何方法可以修改數據，這從根本上杜絕了通過查詢接口非法修改數據的風險。
??技術棧靈活性 (Technology Flexibility):?你甚至可以為讀寫兩端選擇不同的數據庫。例如，命令端使用關系型數據庫（如MySQL）保證事務，查詢端使用搜索引擎（如Elasticsearch）或文檔數據庫（如MongoDB）來提供高性能的復雜查詢。

問題所在：不堪重負的CRUD模型

在傳統的CRUD應用中，我們通常為“商品”定義一個Product實體類，它幾乎無所不能：

@Entity
public?class?Product?{@Id?private?Long id;@NotEmpty?// 用于創建和更新時的校驗private?String name;@Positive?// 校驗private?BigDecimal price;// 為業務邏輯而生，但在查詢列表時通常不需要，可能導致N+1問題@ManyToOne(fetch = FetchType.LAZY)?private?Category category;@JsonIgnore?// 為了在API中隱藏這個字段private?String internalCode;// ... 大量getter/setter, 業務方法, toString...
}

這個Product實體既要負責寫入時的驗證和業務邏輯，又要負責讀取時的JSON序列化。

??模型臃腫：?一個類承擔了過多的職責，變得難以理解和維護。
??性能問題：?查詢一個簡單的列表可能也會觸發懶加載，或者返回大量不必要的字段。更新時，一個簡單的價格修改可能需要加載整個復雜的對象。
??優化困難：?針對讀和寫的優化策略相互沖突，無法兩全其美。

??CQRS模式來修復
CQRS將上述Product模型拆分為兩個：

1.?命令模型：?一個完整的、包含校驗和業務方法的Product實體，僅用于處理創建和更新命令。
2.?查詢模型：?一個或多個簡單的ProductDTO，僅包含頁面展示所需的字段，僅用于處理查詢。

一步步實現 Java 示例：銀行賬戶操作

這是一個概念性的例子，展示了讀寫分離的思想。

第一步：定義命令、查詢和模型

// 命令
class?DepositMoneyCommand?{?double?amount;?/* ... */?}
// 查詢
class?GetAccountBalanceQuery?{ String accountId;?/* ... */?}
// 寫模型 (領域實體)
class?BankAccount?{?private?double?balance;?public?void?deposit(double?amount)?{?this.balance += amount; } }
// 讀模型 (DTO)
class?AccountBalanceDTO?{?double?balance;?/* ... */?}

第二步：實現命令處理器和查詢處理器

// 命令處理器 - 負責修改
class?BankAccountCommandHandler?{public?void?handle(DepositMoneyCommand command)?{// 1. 加載寫模型BankAccount?account?=?repository.findById(command.getAccountId());// 2. 執行業務邏輯account.deposit(command.getAmount());// 3. 保存寫模型repository.save(account);// 4. (可選) 發布事件，通知更新讀模型}
}// 查詢處理器 - 負責讀取
class?BankAccountQueryHandler?{public?AccountBalanceDTO?handle(GetAccountBalanceQuery query)?{// 直接從一個優化的讀庫（或視圖）中查詢，返回DTOreturn?readDb.findBalance(query.getAccountId());}
}

Spring Boot 應用案例：CQRS化的商品服務

第一步：實現命令端 (Write Side)

// 命令對象
public?record?CreateProductCommand(String name, BigDecimal price)?{}// JPA實體 (寫模型)
@Entity?public?class?Product?{?/* ... */?}// 命令處理器
@Service
public?class?ProductCommandHandler?{private?final?ProductRepository productRepo;private?final?ApplicationEventPublisher eventPublisher;@Transactionalpublic?void?handle(CreateProductCommand command)?{Product?product?=?new?Product(command.name(), command.price());productRepo.save(product);// 發布事件，用于更新讀模型eventPublisher.publishEvent(new?ProductCreatedEvent(this, product));}
}

第二步：實現查詢端 (Read Side)

// DTO (讀模型)
public?record?ProductDTO(Long id, String name)?{}// 查詢處理器
@Service
public?class?ProductQueryHandler?{private?final?JdbcTemplate jdbcTemplate;?// 使用JdbcTemplate直接查詢，性能更高public?List<ProductDTO>?handleGetAllProducts()?{return?jdbcTemplate.query("SELECT id, name FROM product",?(rs, rowNum) ->?new?ProductDTO(rs.getLong("id"), rs.getString("name")));}
}

第三步：在控制器中按職責分發

@RestController
@RequestMapping("/products")
public?class?ProductController?{private?final?ProductCommandHandler commandHandler;private?final?ProductQueryHandler queryHandler;// 寫操作 -> 調用命令處理器@PostMappingpublic?void?createProduct(@RequestBody?CreateProductCommand command)?{commandHandler.handle(command);}// 讀操作 -> 調用查詢處理器@GetMappingpublic?List<ProductDTO>?getAllProducts()?{return?queryHandler.handleGetAllProducts();}
}

CQRS 與事件溯源 (Event Sourcing)

這是一個天作之合，但兩者并非綁定關系：

??CQRS:?是關于分離讀寫模型的架構模式。
??事件溯源 (Event Sourcing):?是一種持久化技術。它不保存對象的最終狀態，而是保存導致該狀態的所有事件序列。
CQRS 的查詢端（讀模型）可以完美地通過監聽事件溯源產生的事件流，來構建和維護自己所需的、高度優化的數據視圖。