作者：京東科技 倪新明

CQRS只是一種非常簡單的模式（pattern），CQRS本身并不是一種架構(gòu)風(fēng)格，和最終一致性/消息/讀寫分離/事件溯源/DDD等沒有必然的聯(lián)系，它最大優(yōu)勢是給我們帶來更多的架構(gòu)屬性選擇

1 CQRS 本質(zhì)

1.1 CQS：命令和查詢分離

命令和查詢分離，Command and Query Segregation，其核心思想是在任何一個對象的方法可以劃分為兩類

(資料圖片)

?查詢：獲取數(shù)據(jù)，返回查詢數(shù)據(jù)，但不改變數(shù)據(jù)狀態(tài)

?命令：改變數(shù)據(jù)狀態(tài)，不返回任何數(shù)據(jù)

基于CQS的思想，任何一個方法都可以拆分為命令和查詢兩部分：

private int origin = 0;private int add(int value){    origin += value;    return origin;}

上述方法既改變了數(shù)據(jù)，又返回了數(shù)據(jù)狀態(tài)，如果按照CQS的思想，則該方法可以拆成Command和Query兩部分，如下：

private void add(int value){    origin += value;}private int queryValue(){    return origin;}

是否嚴格遵循上述約定存在爭議，對于命令側(cè)是否返回數(shù)據(jù)實際業(yè)務(wù)訴求中并不一定能夠完全統(tǒng)一。比如：

?"出棧" 操作同時改變棧狀態(tài)和返回數(shù)據(jù)

?某些業(yè)務(wù)場景下可能會有返回業(yè)務(wù)主鍵的訴求，比如下單操作返回訂單號

1.2 CQRS：命令和查詢職責(zé)分離

Command and Query Responsibility Segregation，即命令查詢職責(zé)分離，由Greg Young提出 。CQRS在CQS基礎(chǔ)之上，將分離的級別從代碼方法級別擴展到對象級別。CQRS 模式的應(yīng)用非常簡單，如下圖所示

?

??

假設(shè)我們的服務(wù)為 OrderService，在非CQRS模式下同時包含了查詢和更新服務(wù)接口：

public class OrderService {   //  根據(jù)id查詢訂單    Order getOrder(OrderId)    // 查詢已支付訂單    List getPayedOrders()    // 下單    void placeOrder(Order)    // 取消訂單    void cancelOrder(OrderId) }

應(yīng)用CQRS模式之后的OrderService被拆分成了兩個接口，分別承擔(dān)查詢和寫職責(zé)：

/**命令側(cè)服務(wù)*/public class OrderService {    void placeOrder(PlaceOrderCommand command)    void cancelOrder(CancelOrderCommand command)}/** 查詢服務(wù)*/public class OrderQueryService{    Order GetOrder(OrderId)    List getPayedOrders()}

以上這種簡單的分離就是CQRS模式的全部了，是不是非常簡單？確實，單純的看，CQRS的確就是這么簡單。

CQRS最大優(yōu)勢就是基于這種職責(zé)分離能帶給我們更多的架構(gòu)屬性選擇。

?“查詢” 和 “命令” 兩側(cè)進行獨立部署以獲取更好的伸縮性

?“查詢” 和 “命令” 兩側(cè)獨立架構(gòu)設(shè)計

?“查詢” 和 “命令”兩側(cè)進行獨立數(shù)據(jù)模型設(shè)計

基于CQRS，我們可以衍生出更多的架構(gòu)屬性，結(jié)合實際的業(yè)務(wù)場景，進行差異化的架構(gòu)設(shè)計。

團隊引入CQRS模式之后，往往不僅僅是簡單的在類的職責(zé)層面對讀寫進行分離，一般會采用更為復(fù)雜的應(yīng)用架構(gòu)風(fēng)格，如下是典型的CQRS架構(gòu)風(fēng)格：

?

??

?命令側(cè)：命令側(cè)引入命令總線以支持對不同命令的靈活路由；突出領(lǐng)域模型的應(yīng)用

?查詢側(cè)：引入查詢總線對查詢請求進行路由；請求鏈路一般直接連接到存儲層，實現(xiàn)不同的定制化查詢需求

2 CQRS迷思

2.1 數(shù)據(jù)模型是否要分離

CQRS強調(diào)命令和查詢的職責(zé)分離，但在底層的數(shù)據(jù)模型層面，CQRS并沒有進行強制限定，即采用CQRS模式并沒有要求必須要進行數(shù)據(jù)模型的分離。是否要進行模型分離開發(fā)人員需要具體情況具體分析。

?分離模型：查詢側(cè)和寫側(cè)模型不互相干擾，各自在應(yīng)用層的實現(xiàn)復(fù)雜度比較低。但由于模型的分離，命令側(cè)和查詢側(cè)的數(shù)據(jù)一致性需要納入考慮范圍

?不分離：不需要考慮數(shù)據(jù)一致性問題，但由于查詢側(cè)和寫側(cè)對模型的訴求可能不一致，模型的設(shè)計往往需要折衷考慮。

2.2 CQRS 和 消息模式

CQRS和消息模式?jīng)]有必然聯(lián)系，落地CQRS 并不一定需要使用消息模式。

?

??

如果我們采用了CQRS模式，但是命令和查詢兩側(cè)底層所依賴的數(shù)據(jù)模型并未分離，而是基于共享的數(shù)據(jù)存儲和數(shù)據(jù)模型，命令和查詢之間不需要額外的交互，命令側(cè)的數(shù)據(jù)更新對查詢側(cè)實時可見。在這種架構(gòu)模式下，兩側(cè)基于共享的數(shù)據(jù)已經(jīng)天然的集成在一起，不需要額外機制進行通信，自然也無需引入消息了。如果我們采用CQRS模式，并且命令和查詢兩側(cè)進行了數(shù)據(jù)模型的分離，二者各自依賴獨立的數(shù)據(jù)模型。同時，數(shù)據(jù)存儲也分開部署。命令側(cè)負責(zé)數(shù)據(jù)的更新，而查詢側(cè)只負責(zé)數(shù)據(jù)的查詢，如何將數(shù)據(jù)的更新及時同步到查詢側(cè)是需要解決的問題。在這種架構(gòu)模式下，使用消息模式作為兩側(cè)的通信機制是個不錯的選擇，當(dāng)然，這并不是唯一的選項。

2.3 CQRS 和 ES（Event Sourcing, 事件溯源)

ES 并不是一個新的概念，在最早的金融系統(tǒng)中就已經(jīng)應(yīng)用。要了解ES，我們需要先看看傳統(tǒng)的數(shù)據(jù)存儲。在傳統(tǒng)應(yīng)用中，數(shù)據(jù)庫例如MySQL（假設(shè)存儲介質(zhì)是數(shù)據(jù)庫，）中存儲的始終是數(shù)據(jù)的最新的狀態(tài)。例如我們對某條用戶的信息進行了多次的修改或編輯，然后保存將數(shù)據(jù)存儲到數(shù)據(jù)庫中。無論何時，數(shù)據(jù)庫中都會記錄最后的、最新的用戶狀態(tài)。我們只要根據(jù)id或其他信息查詢數(shù)據(jù)庫中相應(yīng)的記錄就能獲取該用戶的最新信息。這是應(yīng)用中典型的數(shù)據(jù)存儲特點。

當(dāng)然，我們可以基于特定的數(shù)據(jù)模型設(shè)計以保存數(shù)據(jù)的更改記錄。????

這種數(shù)據(jù)存儲模式的特點是簡單，不需要額外的維護復(fù)雜的設(shè)計，我們能夠非常容易的獲取最新的用戶信息。但是不幸的是，我們丟失了歷史信息，包括用戶的意圖信息。而這些信息則有助于我們進行數(shù)據(jù)回滾、用戶行為分析以及開發(fā)過程中的調(diào)試等等。

?

??

在ES模式下，數(shù)據(jù)庫中存儲的不在是數(shù)據(jù)最新狀態(tài)，而是數(shù)據(jù)的變更記錄，更官方的說法是 “事件（Event）”。數(shù)據(jù)庫中存儲的數(shù)據(jù)變化的事件流。我們基于事件流可以對最新狀態(tài)進行重建，同時也可以便捷的重現(xiàn)任何歷史節(jié)點數(shù)據(jù)。ES需要解決大量事件的存儲和高效的實例重建問題，后續(xù)單獨的文章再介紹ES。

2.4 CQRS 和 Eventual Consistency（最終一致性）

最終一致性也常常在服務(wù)之間引入，最終一致性的目的是為了提高擴展性和可用性。

CQRS和最終一致性同樣沒有必然的聯(lián)系。往往采用CQRS后，查詢和命令兩側(cè)會采用獨立的數(shù)據(jù)模型，在這種架構(gòu)模式下，命令側(cè)的數(shù)據(jù)變化后及時同步到查詢側(cè)，兩側(cè)數(shù)據(jù)并非實時，在一定的延時后兩側(cè)數(shù)據(jù)最終達成一致。

3 結(jié)語

CQRS的最大優(yōu)勢在于通過將命令和查詢的職責(zé)分離，為架構(gòu)師提供了更多的架構(gòu)屬性選擇，我們可以在查詢側(cè)和命令側(cè)進行獨立的架構(gòu)設(shè)計。對象級別的職責(zé)分離就是CQRS的全部了，但在實踐中涌現(xiàn)出了很多更為靈活也更為復(fù)雜的架構(gòu)風(fēng)格，比如總線的引入、數(shù)據(jù)模型的分離、一致性報這個策略、事件溯源等等。額外的組件或技術(shù)的引入必然導(dǎo)致復(fù)雜性和成本上升，這些選型的采納需要團隊的權(quán)衡。