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

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

了解 CQRS

什么是 CQRS？

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

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

起源與演變

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

為什么使用 CQRS？

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

微服務中的 CQRS

微服務架構的興起放大了 CQRS 的必要性。在分布式系統中，服務通常需要自治和高度解耦，CQRS 提供了一條清晰的路徑。每個微服務都可以采用 CQRS 模式，確保其處理命令和查詢的內部機制從其他服務中抽象出來。這也與領域驅動設計（DDD）非常吻合，其中領域事件可以觸發不同微服務中的命令。

潛在的陷阱

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

• 復雜性增加： 引入 CQRS 會增加開銷，尤其是在讀取和寫入之間的區別不明顯的系統中。可能并不總是需要將每個讀取和寫入操作分開，這樣做可能會導致不必要的復雜性增加。
• 一致性： 鑒于寫入存儲和讀取存儲可能不同，確保它們之間的數據一致性可能具有挑戰性，尤其是在分布式系統中。

CQRS 與 Spring 微服務

Spring 生態系統擁有豐富的工具和框架，非常適合在微服務環境中實現 CQRS 模式。

設置 Spring 引導

第一步是建立一個基本的 Spring Boot 項目。如果您是 Spring Boot 新手，您可以使用Spring Initializr輕松初始化您的項目。基本依賴項包括 Spring Web、Spring Data JPA 以及您喜歡的任何數據庫連接器。

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

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

示例命令：

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）的背景下，狀態突變通常發生在聚合上。這些聚合可確保在保留任何更改之前遵守所有域規則。

查詢和查詢處理程序

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

查詢示例：

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 提供了隔離機制，但可以使用事件源來簡化命令和查詢之間狀態的維護。Axon 框架是一種有助于使用 Spring 實現 CQRS 和事件溯源的流行框架。

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

與 Apache Kafka 的異步通信

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

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

事件溯源和 CQRS

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

事件溯源的本質

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

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

事件溯源的好處

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

將事件溯源與 CQRS 集成

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

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

使用 Spring 和 Axon 框架實現

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

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

@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 提供了一種存儲和檢索事件的機制。可以重播這些事件以重建聚合的狀態。

投影： Axon 中的投影提供了 CQRS 的查詢端。他們監聽事件并更新讀取優化視圖。這樣，您的查詢模型始終會根據最新更改保持更新。

挑戰和考慮因素

雖然 CQRS 和事件溯源可以提供巨大的好處，但它們也具有復雜性。意識到這些挑戰將確保更明智、更順利的實施。

復雜性開銷

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

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

數據一致性

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

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

事件版本控制

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

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

數據存儲和重放

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

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

與其他系統集成

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

確定邊界

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

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

工具和基礎設施

雖然有像 Axon 和框架這樣的工具支持 CQRS 和事件溯源，但它們可能并不總是適合所有場景。可能需要自定義實現，這會增加項目的復雜性和持續時間。

結論

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