建站
咨詢
售后
建站咨詢
新聞中心
介紹
微服務的興起以及現(xiàn)代軟件架構(gòu)對可擴展性、靈活性和可維護性的需求，促使開發(fā)者采用各種設計模式。近年來，命令查詢責任分離（Command Query Responsibility Segregation，CQRS）模式在實踐中獲得大量推廣。CQRS特別適用于那些命令（用于修改狀態(tài)）和查詢（用于讀取狀態(tài)）之間存在明顯區(qū)別的系統(tǒng)。本文將深入探討CQRS，并演示如何使用Spring微服務進行實現(xiàn)。
什么是 CQRS？
命令查詢職責分離（CQRS）是一種架構(gòu)模式，建議將數(shù)據(jù)修改操作（命令）與數(shù)據(jù)檢索操作（查詢）分離。這種分離允許為查詢和更新數(shù)據(jù)開發(fā)專門的模型，提高應用程序的清晰度和可擴展性。
CQRS 的核心目標是通過確保每個任務負責單個操作（命令或查詢，但絕不會同時負責兩者）來簡化任務。
起源和演進
CQRS并不是一個全新的概念。它的根源可以追溯到CQS（Command Query Separation，命令查詢分離）原則，該原則由Eiffel編程語言的創(chuàng)建者Bertrand Meyer推廣。盡管CQS主要關(guān)注方法層面，即一個方法應該執(zhí)行命令或回答查詢，但CQRS將這一原則擴展到了應用程序的架構(gòu)層面，建議使用獨立的架構(gòu)組件處理命令和查詢。
為什么使用CQRS？
- 可擴展性：CQRS允許水平擴展，可以根據(jù)需求部署多個命令或查詢服務的實例。讀操作和寫操作可以獨立進行擴展，優(yōu)化資源利用率。
- 靈活性：命令和查詢之間職責明確，意味著開發(fā)者可以針對每個操作使用最適合的持久化機制、策略和優(yōu)化方式。例如，雖然關(guān)系數(shù)據(jù)庫可能用于事務性命令操作，但非規(guī)范化的視圖存儲甚至全文搜索引擎可以用于處理查詢。
- 可維護性：良好實現(xiàn)的CQRS模式簡化了代碼庫。通過為讀操作和寫操作分別建立模型，開發(fā)者可以專注于每個操作的具體內(nèi)容，而不會被無關(guān)的問題分散注意力。這種分離有利于開發(fā)出更清晰、更易于維護和擴展的代碼。
- 增強安全性：CQRS本質(zhì)上促進了更好的安全實踐。通過分離命令和查詢操作，可以更容易地對寫操作進行嚴格的驗證和授權(quán)檢查，同時優(yōu)化讀操作以提高性能。
CQRS在微服務中的應用
在分布式系統(tǒng)中，服務通常需要具有自治性和高度解耦，CQRS提供了一個清晰的路徑。每個微服務都可以采用CQRS模式，確保它處理命令和查詢的內(nèi)部細節(jié)與其他服務分離。這也與領(lǐng)域驅(qū)動設計（DDD）非常契合，其中領(lǐng)域事件可以觸發(fā)不同微服務中的命令操作。
潛在的問題
盡管CQRS帶來了許多好處，但也存在一些挑戰(zhàn)：
- 復雜性增加：引入CQRS可能會增加開銷，特別是在讀操作和寫操作之間的區(qū)別不明顯的系統(tǒng)中。并不總是需要將每個讀操作和寫操作分離，這樣做可能會導致不必要的復雜性增加。
- 一致性：考慮到寫存儲和讀存儲可能是不同的，確保它們之間的數(shù)據(jù)一致性可能具有挑戰(zhàn)性，特別是在分布式系統(tǒng)中。
使用Spring微服務實現(xiàn)CQRS
Spring生態(tài)系統(tǒng)中豐富的工具和框架非常適合在微服務環(huán)境中實現(xiàn)CQRS模式。
新建一個Spring Boot項目
第一步是創(chuàng)建一個基本的Spring Boot項目。如果你是第一次使用Spring Boot，可以使用Spring Initializr初始化項目?？梢愿鶕?jù)自己偏好引入一些必需的依賴項包括Spring Web、Spring Data JPA、數(shù)據(jù)庫連接器等。
命令、命令處理器和聚合
在基于Spring的CQRS系統(tǒng)中，命令表示改變某個狀態(tài)的意圖，而命令處理器則用于處理這些命令。
命令示例如下：
public class CreateUserCommand {
private final String userId;
private final String username;
// 構(gòu)造函數(shù), getters，以及其他方法...
}對于每個命令，都需要定義了相應的命令處理器。該處理器需要包含處理命令的實際邏輯，如下：
@Service
public class CreateUserCommandHandler implements CommandHandler {
@Autowired
private UserRepository userRepository;
@Override
public void handle(CreateUserCommand command) {
User user = new User(command.getUserId(), command.getUsername());
userRepository.save(user);
}
} 在領(lǐng)域驅(qū)動設計（DDD）的上下文中，狀態(tài)變更通常發(fā)生在聚合根上。這些聚合根需要遵循所有領(lǐng)域規(guī)則，然后在對數(shù)據(jù)變更進行持久化。
查詢和查詢處理器
類似地，查詢表示讀取某些狀態(tài)的請求，而查詢處理器則處理這些請求。
查詢命令示例：
public class GetUserByIdQuery {
private final String userId;
// 構(gòu)造函數(shù), getters, 以及其他方法
}對應的查詢處理器：
@Service
public class GetUserByIdQueryHandler implements QueryHandler {
@Autowired
private UserRepository userRepository;
@Override
public User handle(GetUserByIdQuery query) {
return userRepository.findById(query.getUserId()).orElse(null);
}
} 事件溯源及Axon框架集成
盡管CQRS提供了分離的機制，但使用事件溯源可以簡化在命令和查詢之間維護狀態(tài)的過程。Axon Framework是一個實現(xiàn)了CQRS和事件溯源的流行框架。
在Axon中，事件在命令處理后進行發(fā)布。這些事件可以被持久化，然后用于重新創(chuàng)建聚合根的狀態(tài)，有助于保持查詢端與命令端的同步。
使用Apache Kafka進行異步通信
考慮到微服務的分布式特性，實現(xiàn)服務之間的異步通信是非常有必要的。可以將Apache Kafka集成到Spring生態(tài)系統(tǒng)中，以實現(xiàn)強大的事件驅(qū)動架構(gòu)，這在CQRS設置中尤其有用。
由命令端產(chǎn)生的事件可以推送到Kafka的主題中，查詢端可以消費這些事件來更新自己的數(shù)據(jù)存儲。這確保了命令端和查詢端之間的解耦，使系統(tǒng)更具彈性和可擴展性。
事件溯源和CQRS
盡管CQRS專注于分離命令和查詢的責任，但事件溯源確保將應用程序狀態(tài)的每次更改捕獲在事件對象中，并按照應用順序存儲在相同聚合根上。這樣允許你重建過去的狀態(tài)，在與CQRS結(jié)合使用時特別有優(yōu)勢。
事件溯源的核心思想
事件溯源是一種將領(lǐng)域事件持久化而不是持久化狀態(tài)本身的方式。這些事件捕獲狀態(tài)轉(zhuǎn)換。通過重新播放這些事件，可以重建聚合根的當前狀態(tài)。
例如，可以存儲銀行賬戶的所有交易（像存款和提款這樣的事件），而不是僅存儲當前余額。通過重新播放這些事件，可以計算出當前余額。
事件溯源的好處
- 審計追蹤：事件溯源提供了自然的更改審計日志，這對于需要追溯性和歷史記錄的領(lǐng)域非常重要。
- 時間查詢：可以確定系統(tǒng)在任何時間點的狀態(tài)。這對于調(diào)試和理解過去的狀態(tài)非常有用。
- 事件重放：通過重新播放事件，可以重新生成面向讀取的優(yōu)化視圖。當你想要創(chuàng)建新投影或重建損壞的投影時，這特別有用。
事件溯源與CQRS集成
CQRS和事件溯源是相輔相成的，表現(xiàn)在以下幾個方面：
- 解耦：就像CQRS中的命令和查詢解耦一樣，通過事件溯源，事件（代表狀態(tài)變化）與實際狀態(tài)解耦，這促進了松散耦合的架構(gòu)。
- 可擴展性：CQRS中讀操作和寫操作的分離性與事件驅(qū)動系統(tǒng)非常契合。命令模型處理命令并生成事件，而查詢模型處理查詢并可以通過偵聽這些事件進行更新。
- 彈性：通過重播事件，可以在發(fā)生故障甚至遷移到全新系統(tǒng)時重新構(gòu)建系統(tǒng)的狀態(tài)。
使用Spring和Axon框架實現(xiàn)
正如之前提到的，Axon Framework為在Spring應用程序中實現(xiàn)CQRS和事件溯源提供了一種無縫的方案：
- 聚合根和事件處理：在Axon中，聚合根負責處理命令和生成事件。在處理完命令后，它們會應用導致狀態(tài)變化的事件。
@Aggregate
public class Account {
@AggregateIdentifier
private String accountId;
private int balance;
@CommandHandler
public void handle(WithdrawMoneyCommand cmd) {
if (cmd.getAmount() > balance) {
throw new InsufficientFundsException();
}
apply(new MoneyWithdrawnEvent(cmd.getAccountId(), cmd.getAmount()));
}
@EventSourcingHandler
public void on(MoneyWithdrawnEvent evt) {
this.balance -= evt.getAmount();
}
}- 事件存儲：Axon提供了一種存儲和檢索事件的機制。這些事件可以重播，以重建聚合根的狀態(tài)。
- 投影：Axon中的投影提供了CQRS的查詢端。它們監(jiān)聽事件并更新讀取優(yōu)化的視圖。這樣，查詢模型始終與最新的更改保持同步。
挑戰(zhàn)和考慮因素
盡管CQRS和事件溯源可以帶來巨大的好處，但也帶來了復雜性。
復雜性開銷
- 架構(gòu)復雜性：CQRS和事件溯源引入了額外的層次和組件到系統(tǒng)中，如事件存儲、命令和事件總線以及同步機制。
- 學習曲線：對于不熟悉這些模式的團隊來說，需要一個學習階段。從傳統(tǒng)的基于CRUD的系統(tǒng)轉(zhuǎn)變思維可能是具有挑戰(zhàn)性的。
數(shù)據(jù)一致性
- 最終一致性：由于命令和查詢模型的分隔性質(zhì)，即時一致性常常被犧牲以換取最終一致性。這意味著在命令端進行的更改在查詢端反映出來之前可能會有延遲。
- 事件順序：確保事件按照生成的順序進行處理，特別是在分布式系統(tǒng)中，可能會很棘手，但對于維護一致的狀態(tài)至關(guān)重要。
事件版本控制
隨著時間的推移，事件的結(jié)構(gòu)或語義可能會發(fā)生變化，從而帶來以下挑戰(zhàn)：
- 版本不匹配：處理同一事件類型的不同版本可能變得復雜。
- 事件升級：隨著事件的演變，系統(tǒng)必須能夠?qū)⑴f版本的事件升級到新版本，而不修改存儲的事件。
數(shù)據(jù)存儲和重放
- 存儲考慮：由于所有事件都被存儲，事件存儲庫可能會迅速增長，導致存儲成本增加和潛在的性能問題。
- 重放持續(xù)時間：通過重放大量歷史事件來重建系統(tǒng)狀態(tài)可能耗時很長，影響系統(tǒng)的恢復和初始化時間。
其他系統(tǒng)集成
使用CQRS和事件溯源的系統(tǒng)與不遵循這些模式的外部系統(tǒng)集成可能具有挑戰(zhàn)性，特別是在數(shù)據(jù)同步和事務管理方面。
邊界確定
- 粒度決策：決定應用CQRS和事件溯源的粒度非常重要。在微觀級別實施可能導致過度復雜化，而過于廣泛地實施可能會削弱其好處。
- 領(lǐng)域復雜性：對于簡單的域來說，這些模式可能過于復雜。它們更適用于復雜的領(lǐng)域，其中好處超過了實施和維護成本。
工具和基礎設施
雖然有像Axon這樣的工具和框架支持CQRS和事件溯源，但它們可能并不完全適合所有場景?？赡苄枰M行定制實現(xiàn)，這可能會增加項目的復雜性和持續(xù)時間。
結(jié)論
CQRS為擴展和組織微服務提供了一種獨特的方式。當與Spring生態(tài)系統(tǒng)結(jié)合使用時，它可以提供一個強大的工具包，用于構(gòu)建健壯、可擴展和易于維護的系統(tǒng)。然而，就像所有架構(gòu)決策一樣，需要權(quán)衡利弊并確保它是否適合你的實際場景。
網(wǎng)頁題目：從CRUD到CQRS：使用Spring微服務轉(zhuǎn)變你的架構(gòu)策略
文章地址：http://www.5511xx.com/article/cddheoi.html
