命令和查詢責任分離(CQRS)是指將數(shù)據(jù)存儲的讀取和更新操作分開的一種模式。實施 CQRS 據(jù)稱可以提高性能、可擴展性和安全性。遷移到 CQRS 模式所創(chuàng)造的靈活性，使系統(tǒng)能夠隨著時間的推移而更好地發(fā)展。不過 CQRS 模式有一些眾所周知的陷阱，本文介紹了三種實用的場景。

CQRS 模式可以創(chuàng)造奇跡：它可以將可擴展性、性能、安全性最大化，甚至可以打破 CAP 定理 (1)。盡管如此，CQRS 還是因為其引入的復雜性而獲得了一個有爭議的名字。例如，Martin Fowler 在其 CQRS 文章 (2) 中認為，應該少用甚至謹慎地應用該模式。

• 對大多數(shù)系統(tǒng)來說，CQRS 增加了風險的復雜性
• 你應該非常謹慎地使用 CQRS
• 雖然 CQRS 是工具箱中的一種模式，但要注意的是，它很難用得好，如果處理不當，很容易搞壞你重要的部件。

從我的觀點來看，CQRS 帶來的復雜性在很大程度上是偶然的，也是可避免的。為了說明我的觀點，我想先討論一下 CQRS 的目標，然后分析一下基于CQRS 系統(tǒng)中常見的三個復雜性的來源。

CQRS 的目標

CQRS 的目標是使用多種模型來表示相同的數(shù)據(jù)，與可擴展性、可用性、安全性、性能都沒有關系。在多個模型中表示相同的數(shù)據(jù)，這就是目標，剩下的都是副產(chǎn)品。不信?聽聽 Greg Young 在 DDDEU2016 大會上的演講 (3) ，他說 CQRS 是為了支持 Event Sourcing (事件溯源)實現(xiàn)而發(fā)明的。而且大家可能都知道，Event Sourcing 模型對于寫數(shù)據(jù)來說很強大，但是對于讀數(shù)據(jù)來說卻很糟糕，這就是當年他需要 CQRS 的原因：用多個模型來表示相同的數(shù)據(jù)。

CQRS 是如何實現(xiàn)這個目標的?通過確保只有一個模型作為數(shù)據(jù)的源頭，所有的修改都通過這個模型來達到。

讓我們來看看這個解讀如何幫助我們解決一些復雜的問題。

復雜性陷阱一：單向命令，或者說過度的隔離

據(jù)我所知，所有的 CQRS 的定義都遵循這個模式。

1. CQRS 是基于 CQS 原則，它指出，操作應該被分為兩組：改變數(shù)據(jù)的命令和查詢數(shù)據(jù)的命令。一旦我們將這一原則提升到架構層面，我們就會得到一個系統(tǒng)，用例被隔離成相同的兩組：命令和查詢。每個用例既可以是命令，也可以是查詢，但絕對不能同時是命令和查詢。
2. 一旦用例被隔離，我們會得到很多好處：多種模型、不同的持久化機制、獨立的可擴展性等。

你是否感覺到這里有什么問題?這個問題很微妙：所有的 CQRS 定義通常都是從解決方案 — 隔離開始，之后才定義問題 — 多模型。這就導致了對隔離太過熱衷：甚至將命令定義為單向的，操作服務器只返回 Ack/Nack 響應，必須輪詢一些讀模型存儲的實際命令才能返回結果。換句話說，復雜度如地獄式的釋放。

解決辦法：放寬隔離

讓我們退一步，重新考慮一下隔離的問題。我們已經(jīng)看到，根據(jù) CQRS 的說法，為了在多個模型中表示相同的數(shù)據(jù)，一個用例既可以寫數(shù)據(jù)，也可以讀數(shù)據(jù)。讀取模型不應該更新任何東西，這一點是不言而喻的，否則我們最終會有多個數(shù)據(jù)來源。但是，你真的應該讓你的命令空轉(zhuǎn)嗎?

其實不然，在不違反任何原則的情況下，一個命令可以安全地返回以下數(shù)據(jù)。

• 執(zhí)行結果：成功/失敗。
• 如果失?。哄e誤信息或驗證錯誤。
• 如果成功：聚合的新版本號。

這些信息將極大地改善你的系統(tǒng)的用戶體驗，因為：

• 你不需要向外部來源查詢命令執(zhí)行結果，你馬上就能得到它。在驗證命令，以及返回錯誤信息方面變得非常簡單;以及
• 如果你想刷新顯示的數(shù)據(jù)，你可以使用聚合的新版本來確定視圖模型是否反映了已執(zhí)行的命令。不會再顯示陳舊的數(shù)據(jù)了。

說到數(shù)據(jù)，我們能不能再放寬一點隔離?在很多情況下，受影響的聚合內(nèi)部包含的任何數(shù)據(jù)都可以作為命令執(zhí)行結果的一部分返回。但是，這里有一點細微的差別：確保返回的數(shù)據(jù)可以在以后從其中一個讀取模型中查詢。否則，在響應沒有到達客戶端的情況下，數(shù)據(jù)可能會有潛在的丟失風險。

你可以在 Daniel Whittaker 的博客 (4) 中看到這樣一個例子，他在博客中討論了命令執(zhí)行對象用于驗證命令的使用。

另外，在這個 gist 中 (5) ，你可以看到我在 C# 中使用的命令執(zhí)行結果對象。

復雜性陷阱二：Event sourcing (事件溯源)

由于歷史原因，CQRS 與 Event Sourcing 模式密切相關。畢竟，CQRS 的發(fā)明就是為了讓 Event Sourcing 模式成為可能。但是，讓我們重新評估一下這兩種模式之間的耦合關系。

正如我之前所說，CQRS 的目標是允許在不同的模型中表示相同的數(shù)據(jù)。如果你正在使用 event source 域模型，你絕對需要 CQRS 來執(zhí)行查詢。然而，還有很多其他合理的理由來實現(xiàn) CQRS，這些理由與 event source 無關。

• 你的系統(tǒng)以不同的表示模型顯示其實體。
• 你必須支持不同的查詢模型(搜索、圖、文檔等)。
• 寫入和讀入之間的差異很大，你希望將它們獨立擴展。
• 你不喜歡 ORM。

這是否意味著在所有這些情況下，你必須走 Event Sourcing 路線?如果你這么做，你就深陷復雜度陷阱。Event source 是一種業(yè)務領域的建模方式，也可能是最復雜的方式。因此，只有當你的業(yè)務領域證明你的業(yè)務領域是合理的，你才應該采用 Event Sourcing。讓我們來看看如何在其他情況下實現(xiàn) CQRS。

解決方案：CQRS != Event Sourcing

我們已經(jīng)學會了通過編寫事件處理程序來生成投影。如果沒有事件，如何實現(xiàn)投影?還有一種方法可以實現(xiàn)投影，我稱之為“基于狀態(tài)的投影”。這個主題值得單獨寫一個帖子，但我將簡單介紹三種實現(xiàn)“基于狀態(tài)的投影”的方法。

1. "臟"標志

你可以通過設置 IsDirty 標志來標記一個被更新的實體，并實現(xiàn)一個投影引擎來查詢臟實例，并將更新的數(shù)據(jù)投影到不同的模型中。要重建投影，你只需要將所有記錄的 dirty 標志設置就可以了。

2. 追加

在關系型數(shù)據(jù)庫中，你可以在表層跟蹤提交。例如在 SQL Server 中，你有一個內(nèi)置的機制，即 "rowversion" 列。這樣的功能也可以在其他關系型數(shù)據(jù)庫中實現(xiàn)。投射引擎將以類似于補訂的方式查詢更新的行，并將更新的數(shù)據(jù)進行投影。要從頭開始重建一個投影，必須將上次已知的提交 id “回滾” 到 0。

3. 數(shù)據(jù)庫視圖

如果你使用的是關系型數(shù)據(jù)庫，而你需要的只是用不同的模型來表示它的數(shù)據(jù)，那么數(shù)據(jù)庫視圖就很好用。沒錯，一個完全有效的 CQRS 系統(tǒng)可以在數(shù)據(jù)庫中實現(xiàn)。這可能是最不性感的解決方案 — 但它不僅可以工作，還自然地遵循了 CQRS 模式。

這些投影模型的方法可能并不酷，也不性感，但它們是有效的。我見過不少采用了這些方法的項目，它們的效果很好，沒有無端地淹沒在 event source 相關的復雜性中。

等等，我剛才是不是建議不惜一切代價忽略 Event Sourcing，因為它很復雜?當然不是! Event Sourcing 是你工具箱中最重要的工具之一。但是，作為任何工具，請在其上下文中使用它 — 能帶來商業(yè)價值的業(yè)務領域。核心子領域。另一方面，通用子域和支持子域，這些子域足夠簡單，可以用事務腳本或活動記錄模式實現(xiàn)，但仍然可以從 CQRS 中受益。在這種情況下，使用最簡單的工具來完成工作，并使用基于狀態(tài)的預測來獲取 CQRS 的好處。

復雜性陷阱三：好東西太多了

微服務的炒作吸引了很多人對 CQRS 的關注：如果你有一組獨立的服務需要查詢彼此的數(shù)據(jù)，那么 CQRS 就是通用的解決方案 (6) 。然而我已經(jīng)看到這種方法產(chǎn)生了巨大的數(shù)據(jù)流圖，在服務之間投射出大量的數(shù)據(jù)。

[[325623]]

這不一定是壞事，但在很多情況下這可能是一個信號，需要退一步重新考慮你的分解策略。有可能是你的服務過于細化，沒有反映出業(yè)務領域的邊界。如果是這種情況，你可以通過將服務邊界與相應的業(yè)務域重新對齊，大大降低架構的復雜性。

CQRS：解構

我想用 CQRS 的圖來總結一下。

此圖與您在網(wǎng)上可以找到的其他圖表不同。

這就是我所看到的和實現(xiàn) CQRS 模式。命令有響應。定義的投射機制是抽象的，與實現(xiàn)細節(jié)無關。里面可能是基于事件，或者是基于狀態(tài)，甚至是數(shù)據(jù)庫視圖。最后，沒有事件源(Event Sourcing)。按照業(yè)務域的要求，對系統(tǒng)的業(yè)務邏輯進行建模：活動記錄、域模型或事件源域模型。

與每一個正確應用的工具一樣，CQRS 應該降低復雜性，而不是誘導復雜性。如果你的體系結構的復雜性增加了，那么你很可能做錯了。

文中相關鏈接：

http://codebetter.com/gregyoung/2010/02/20/cqrs-and-cap-theorem/

https://martinfowler.com/bliki/CQRS.html

https://youtu.be/LDW0QWie21s?t=448

http://danielwhittaker.me/2016/04/20/how-to-validate-commands-in-a-cqrs-application/

https://gist.github.com/vladikk/86da55d0eb09d7a291b9f9a5b406f2c9

https://www.ibm.com/developerworks/cloud/library/cl-build-app-using-microservices-and-cqrs-trs/

英文原文：

https://vladikk.com/2017/03/20/tackling-complexity-in-cqrs/

本文轉(zhuǎn)載自微信公眾號「高可用架構 」，可以通過以下二維碼關注。轉(zhuǎn)載本文請聯(lián)系高可用架構 公眾號。