微服務的興起以及現代軟件架構對可擴展性、靈活性和可維護性的需求導致開發(fā)人員接受各種設計模式。

近年來備受關注的一種模式是命令查詢職責分離 (CQRS) 模式。CQRS 特別適合命令（改變狀態(tài)）和查詢（讀取狀態(tài)）之間有明顯區(qū)別的系統(tǒng)。在本文中，我們將深入研究 CQRS 并了解如何使用 Spring 微服務來實現它。

了解 CQRS

什么是 CQRS？

命令查詢職責分離（CQRS）是一種架構模式，建議將數據修改操作（命令）與數據檢索操作（查詢）分離。這種分離允許開發(fā)專門的模型來查詢和更新數據，從而增強應用程序的清晰度和可擴展性。

CQRS 的核心目標是通過確保每個任務負責單個操作（命令或查詢，但絕不會同時負責兩者）來簡化任務。

起源與演變

CQRS 并不是一個全新的概念。它的根源可以追溯到 CQS（命令查詢分離），這是 Eiffel 編程語言的創(chuàng)建者 Bertrand Meyer 推廣的一項原則。雖然 CQS 主要是關于方法——聲明方法應該執(zhí)行命令或回答查詢，但 CQRS 將這一原則擴展到應用程序的架構級別，建議不同的架構組件處理命令和查詢。

為什么使用 CQRS？

• 可擴展性： CQRS 允許水平可擴展性，因為您可以根據需求部署命令或查詢服務的多個實例。讀取密集型和寫入密集型操作可以獨立擴展，從而優(yōu)化資源利用率。
• 靈活性： 命令和查詢之間的明確區(qū)別意味著開發(fā)人員可以為每個命令和查詢使用最合適的持久性機制、策略和優(yōu)化。例如，雖然關系數據庫可能用于事務命令操作，但非規(guī)范化視圖存儲甚至全文搜索引擎都可以提供查詢服務。
• 可維護性： 實施良好的 CQRS 模式簡化了代碼庫。通過讀取和寫入操作的單獨模型，開發(fā)人員可以專注于每個操作的細節(jié)，而不會分散不相關問題的注意力。這種隔離通常會產生更清晰的代碼，更容易維護和擴展。
• 增強的安全性： CQRS 本質上促進了更好的安全實踐。通過分離命令和查詢操作，可以更輕松地對寫入操作實施嚴格的驗證和授權檢查，同時優(yōu)化讀取操作的性能。

微服務中的 CQRS

微服務架構的興起放大了 CQRS 的必要性。在分布式系統(tǒng)中，服務通常需要自治和高度解耦，CQRS 提供了一條清晰的路徑。關注公眾號：碼猿技術專欄，回復關鍵詞：BAT，獲取大廠面試真題！每個微服務都可以采用 CQRS 模式，確保其處理命令和查詢的內部機制從其他服務中抽象出來。這也與領域驅動設計（DDD）非常吻合，其中領域事件可以觸發(fā)不同微服務中的命令。

潛在的陷阱

雖然 CQRS 提供了許多好處，但它也面臨著挑戰(zhàn)：

• 復雜性增加： 引入 CQRS 會增加開銷，尤其是在讀取和寫入之間的區(qū)別不明顯的系統(tǒng)中?？赡懿⒉豢偸切枰獙⒚總€讀取和寫入操作分開，這樣做可能會導致不必要的復雜性增加。
• 一致性： 鑒于寫入存儲和讀取存儲可能不同，確保它們之間的數據一致性可能具有挑戰(zhàn)性，尤其是在分布式系統(tǒng)中。

CQRS 與 Spring 微服務

Spring 生態(tài)系統(tǒng)擁有豐富的工具和框架，非常適合在微服務環(huán)境中實現 CQRS 模式。

設置 Spring 引導

第一步是建立一個基本的 Spring Boot 項目。如果您是 Spring Boot 新手，您可以使用Spring Initializr輕松初始化您的項目?；疽蕾図棸?Spring Web、Spring Data JPA 以及您喜歡的任何數據庫連接器。

命令、命令處理程序和聚合

在基于 Spring 的 CQRS 系統(tǒng)中，命令表示更改某些狀態(tài)的意圖，命令處理程序處理這些命令。

示例命令：

public class CreateUserCommand {
    private final String userId;
    private final String username;

    // Constructor, getters, and other methods...
}

對于每個命令，都定義了相應的命令處理程序。該處理程序包含處理命令的實際邏輯：

@Service
public class CreateUserCommandHandler implements CommandHandler<CreateUserCommand> {
    
    @Autowired
    private UserRepository userRepository;

    @Override
    public void handle(CreateUserCommand command) {
        User user = new User(command.getUserId(), command.getUsername());
        userRepository.save(user);
    }
}

在領域驅動設計（DDD）的背景下，狀態(tài)突變通常發(fā)生在聚合上。這些聚合可確保在保留任何更改之前遵守所有域規(guī)則。關注公眾號：碼猿技術專欄，回復關鍵詞：1111，獲取阿里內部Java性能調優(yōu)手冊！

查詢和查詢處理程序

類似地，查詢表示讀取某些狀態(tài)的請求，查詢處理程序處理這些請求。

查詢示例：

public class GetUserByIdQuery {
    private final String userId;

    // Constructor, getters, and other methods...
}

對應的查詢處理程序：

@Service
public class GetUserByIdQueryHandler implements QueryHandler<GetUserByIdQuery, User> {
    
    @Autowired
    private UserRepository userRepository;

    @Override
    public User handle(GetUserByIdQuery query) {
        return userRepository.findById(query.getUserId()).orElse(null);
    }
}

將事件溯源與 Axon 框架集成

雖然 CQRS 提供了隔離機制，但可以使用事件源來簡化命令和查詢之間狀態(tài)的維護。Axon 框架是一種有助于使用 Spring 實現 CQRS 和事件溯源的流行框架。

對于 Axon，事件在命令處理后發(fā)布。這些事件可以被持久化，然后用于重新創(chuàng)建聚合的狀態(tài)。它還有助于保持查詢端與命令端同步。

與 Apache Kafka 的異步通信

鑒于微服務的分布式特性，在服務之間實現異步通信通常是有益的。Apache Kafka 可以集成到 Spring 生態(tài)系統(tǒng)中，以實現強大的事件驅動架構，這在 CQRS 設置中特別有用。

命令端產生的事件可以推送到Kafka主題中，查詢端可以使用這些事件來更新自己的數據存儲。這確保了命令端和查詢端之間的解耦，使系統(tǒng)更具彈性和可擴展性。

事件溯源和 CQRS

雖然 CQRS 專注于分離命令和查詢職責，但事件溯源可確保應用程序狀態(tài)的每次更改都被捕獲在事件對象中，并按照它們應用于同一聚合的順序存儲。這種方法允許您重建過去的狀態(tài)，并且與 CQRS 結合使用時特別有利。

事件溯源的本質

事件溯源是關于持久化域事件而不是狀態(tài)本身。這些事件捕獲狀態(tài)轉換。通過重放它們，可以重建聚合的當前狀態(tài)。

例如，您將存儲所有交易（例如存款和取款等事件），而不是存儲銀行帳戶的當前余額。通過重播這些事件可以得出當前余額。

事件溯源的好處

• 審計跟蹤： 事件溯源提供了自然的變更審計日志。這對于可追溯性和歷史記錄至關重要的領域至關重要。
• 臨時查詢： 您可以確定系統(tǒng)在任何時間點的狀態(tài)。這對于調試和理解過去的狀態(tài)非常有價值。
• 事件重播： 通過重播事件，您可以重新生成讀取優(yōu)化的視圖。當您想要創(chuàng)建新的投影或重建損壞的投影時，這尤其有用。

將事件溯源與 CQRS 集成

CQRS 和事件溯源通過以下方式相互補充：

• 解耦： 正如命令和查詢在 CQRS 中解耦一樣，通過事件源，事件（表示狀態(tài)更改）與實際狀態(tài)解耦。這促進了松散耦合的架構。
• 可擴展性： CQRS 中讀取和寫入的隔離性質非常適合事件驅動系統(tǒng)。命令模型處理命令并生成事件，而查詢模型處理查詢并可以通過偵聽這些事件來更新。
• 彈性： 通過重放事件的能力，可以在發(fā)生故障時重建系統(tǒng)狀態(tài)，甚至可以遷移到全新的系統(tǒng)。

使用 Spring 和 Axon 框架實現

如前所述，Axon 框架提供了一種在 Spring 應用程序中實現 CQRS 和事件源的無縫方法：

聚合和事件處理： 在 Axon 中，聚合負責命令處理和事件生成。處理命令后，它們應用導致狀態(tài)更改的事件。

@Aggregate
publicclass Account {
    @AggregateIdentifier
    private String accountId;
    privateint balance;

    @CommandHandler
    public void handle(WithdrawMoneyCommand cmd) {
        if (cmd.getAmount() > balance) {
            thrownew 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 和事件溯源可以提供巨大的好處，但它們也具有復雜性。意識到這些挑戰(zhàn)將確保更明智、更順利的實施。

復雜性開銷

架構復雜性： CQRS 和事件源向系統(tǒng)引入了額外的層和組件，例如事件存儲、命令和事件總線以及同步機制。

學習曲線： 對于剛接觸這些模式的團隊，將有一個學習階段。從傳統(tǒng)的基于 CRUD 的系統(tǒng)的概念轉變可能具有挑戰(zhàn)性。

數據一致性

最終一致性： 鑒于命令和查詢模型的隔離性質，通常會為了最終一致性而犧牲即時一致性。這意味著在命令端所做的更改反映在查詢端之前可能會有延遲。

事件排序： 確保事件按照生成的順序進行處理，尤其是在分布式系統(tǒng)中，可能很棘手，但對于保持一致的狀態(tài)至關重要。

事件版本控制

隨著時間的推移，事件的結構或語義可能會發(fā)生變化，從而導致以下挑戰(zhàn)：

• 版本不匹配： 處理同一事件類型的不同版本可能會變得復雜。
• 事件升級： 隨著事件的發(fā)展，系統(tǒng)必須能夠將舊事件升級為新版本，而不改變存儲的事件。

數據存儲和重放

存儲注意事項： 由于存儲所有事件，事件存儲可能會快速增長，從而導致存儲成本增加和潛在的性能問題。

重播持續(xù)時間： 通過重播長期歷史事件來重建系統(tǒng)狀態(tài)可能非常耗時，會影響系統(tǒng)恢復和初始化時間。

與其他系統(tǒng)集成

將使用 CQRS 和事件源的系統(tǒng)與不遵循這些模式的外部系統(tǒng)集成可能具有挑戰(zhàn)性，特別是在數據同步和事務管理方面。

確定邊界

粒度決策： 決定應用 CQRS 和事件溯源的粒度至關重要。在微觀層面上實施它們可能會導致過于復雜化，而過于廣泛地實施可能會削弱好處。

域復雜性： 這些模式對于簡單域來說可能有點過分了。它們更適合復雜的領域，其好處超過了實施和維護成本。

工具和基礎設施

雖然有像 Axon 和框架這樣的工具支持 CQRS 和事件溯源，但它們可能并不總是適合所有場景?？赡苄枰远x實現，這會增加項目的復雜性和持續(xù)時間。

結論

CQRS 提供了一種獨特的方式來擴展和組織微服務。當與 Spring 的生態(tài)系統(tǒng)結合時，它可以提供強大的工具包來構建健壯、可擴展和可維護的系統(tǒng)。然而，與所有架構決策一樣，必須權衡利弊并確保它適合您的特定用例。