DDD CQRS架構和傳統架構的優缺點比較

五柳-先生發表於2016-06-21
架構

明天就是大年三十了，今天在家有空，想集中整理一下CQRS架構的特點以及相比傳統架構的優缺點分析。先提前祝大家猴年新春快樂、萬事如意、身體健康！

最近幾年，在DDD的領域，我們經常會看到CQRS架構的概念。我個人也寫了一個ENode框架，專門用來實現這個架構。CQRS架構本身的思想其實非常簡單，就是讀寫分離。是一個很好理解的思想。就像我們用MySQL資料庫的主備，資料寫到主，然後查詢從備來查，主備資料的同步由MySQL資料庫自己負責，這是一種資料庫層面的讀寫分離。關於CQRS架構的介紹其實已經非常多了，大家可以自行百度或google。我今天主要想總結一下這個架構相對於傳統架構（三層架構、DDD經典四層架構）在資料一致性、擴充套件性、可用性、伸縮性、效能這幾個方面的異同，希望可以總結出一些優點和缺點，為大家在做架構選型時提供參考。

前言

CQRS架構由於本身只是一個讀寫分離的思想，實現方式多種多樣。比如資料儲存不分離，僅僅只是程式碼層面讀寫分離，也是CQRS的體現；然後資料儲存的讀寫分離，C端負責資料儲存，Q端負責資料查詢，Q端的資料通過C端產生的Event來同步，這種也是CQRS架構的一種實現。今天我討論的CQRS架構就是指這種實現。另外很重要的一點，C端我們還會引入Event Sourcing+In Memory這兩種架構思想，我認為這兩種思想和CQRS架構可以完美的結合，發揮CQRS這個架構的最大價值。

資料一致性

傳統架構，資料一般是強一致性的，我們通常會使用資料庫事務保證一次操作的所有資料修改都在一個資料庫事務裡，從而保證了資料的強一致性。在分散式的場景，我們也同樣希望資料的強一致性，就是使用分散式事務。但是眾所周知，分散式事務的難度、成本是非常高的，而且採用分散式事務的系統的吞吐量都會比較低，系統的可用性也會比較低。所以，很多時候，我們也會放棄資料的強一致性，而採用最終一致性；從CAP定理的角度來說，就是放棄一致性，選擇可用性。

CQRS架構，則完全秉持最終一致性的理念。這種架構基於一個很重要的假設，就是使用者看到的資料總是舊的。對於一個多使用者操作的系統，這種現象很普遍。比如秒殺的場景，當你下單前，也許介面上你看到的商品數量是有的，但是當你下單的時候，系統提示商品賣完了。其實我們只要仔細想想，也確實如此。因為我們在介面上看到的資料是從資料庫取出來的，一旦顯示到介面上，就不會變了。但是很可能其他人已經修改了資料庫中的資料。這種現象在大部分系統中，尤其是高併發的WEB系統，尤其常見。

所以，基於這樣的假設，我們知道，即便我們的系統做到了資料的強一致性，使用者還是很可能會看到舊的資料。所以，這就給我們設計架構提供了一個新的思路。我們能否這樣做：我們只需要確保系統的一切新增、刪除、修改操作所基於的資料是最新的，而查詢的資料不必是最新的。這樣就很自然的引出了CQRS架構了。C端資料保持最新、做到資料強一致；Q端資料不必最新，通過C端的事件非同步更新即可。所以，基於這個思路，我們開始思考，如何具體的去實現CQ兩端。看到這裡，也許你還有一個疑問，就是為何C端的資料是必須要最新的？這個其實很容易理解，因為你要修改資料，那你可能會有一些修改的業務規則判斷，如果你基於的資料不是最新的，那意味著判斷就失去意義或者說不準確，所以基於老的資料所做的修改是沒有意義的。

擴充套件性

傳統架構，各個元件之間是強依賴，都是物件之間直接方法呼叫；而CQRS架構，則是事件驅動的思想；從微觀的聚合根層面，傳統架構是應用層通過過程式的程式碼協調多個聚合根一次性以事務的方式完成整個業務操作。而CQRS架構，則是以Saga的思想，通過事件驅動的方式，最終實現多個聚合根的互動。另外，CQRS架構的CQ兩端也是通過事件的方式非同步進行資料同步，也是事件驅動的一種體現。上升到架構層面，那前者就是SOA的思想，後者是EDA的思想。SOA是一個服務呼叫另一個服務完成服務之間的互動，服務之間緊耦合；EDA是一個元件訂閱另一個元件的事件訊息，根據事件資訊更新元件自己的狀態，所以EDA架構，每個元件都不會依賴其他的元件；元件之間僅僅通過topic產生關聯，耦合性非常低。

上面說了兩種架構的耦合性，顯而易見，耦合性低的架構，擴充套件性必然好。因為SOA的思路，當我要加一個新功能時，需要修改原來的程式碼；比如原來A服務呼叫了B,C兩個服務，後來我們想多呼叫一個服務D，則需要改A服務的邏輯；而EDA架構，我們不需要動現有的程式碼，原來有B,C兩訂閱者訂閱A產生的訊息，現在只需要增加一個新的訊息訂閱者D即可。

從CQRS的角度來說，也有一個非常明顯的例子，就是Q端的擴充套件性。假設我們原來Q端只是使用資料庫實現的，但是後來系統的訪問量增大，資料庫的更新太慢或者滿足不了高併發的查詢了，所以我們希望增加快取來應對高併發的查詢。那對CQRS架構來說很容易，我們只需要增加一個新的事件訂閱者，用來更新快取即可。應該說，我們可以隨時方便的增加Q端的資料儲存型別。資料庫、快取、搜尋引擎、NoSQL、日誌，等等。我們可以根據自己的業務場景，選擇合適的Q端資料儲存，實現快速查詢的目的。這一切都歸功於我們C端記錄了所有模型變化的事件，當我們要增加一種新的View儲存時，可以根據這些事件得到View儲存的最新狀態。這種擴充套件性在傳統架構下是很難做到的。

可用性

可用性，無論是傳統架構還是CQRS架構，都可以做到高可用，只要我們做到讓我們的系統中每個節點都無單點即可。但是，相比之下，我覺得CQRS架構在可用性方面，我們可以有更多的迴避餘地和選擇空間。

傳統架構，因為讀寫沒有分離，所以可用性要把讀寫合在一起綜合考慮，難度會比較更大。因為傳統架構，如果一個系統的高峰期的併發寫入很大，比如為2W，併發讀取也很大，比如為10W。那該系統必須優化到能同時支援這種高併發的寫入和查詢，否則系統就會在高峰時掛掉。這個就是基於同步呼叫思路的系統的缺點，沒有一個東西去削峰填谷，儲存瞬間多出來的請求，而必須讓系統不管遇到多少請求，都必須能及時處理完，否則就會造成雪崩效應，造成系統癱瘓。但是一個系統，不會一直處在高峰，高峰可能只有半小時或1小時；但為了確保高峰時系統不掛掉，我們必須使用足夠的硬體去支撐這個高峰。而大部分時候，都不需要這麼高的硬體資源，所以會造成資源的浪費。所以，我們說基於同步呼叫、SOA思想的系統的實現成本是非常昂貴的。

而在CQRS架構下，因為CQRS架構把讀和寫分離了，所以可用性相當於被隔離在了兩個部分去考慮。我們只需要考慮C端如何解決寫的可用性，Q端如何解決讀的可用性即可。C端解決可用性，我覺得是更加容易的，因為C端是訊息驅動的。我們要做任何資料修改時，都會傳送Command到分散式訊息佇列，然後後端消費者處理Command->產生領域事件->持久化事件->釋出事件到分散式訊息佇列->最後事件被Q端消費。這個鏈路是訊息驅動的。相比傳統架構的直接服務方法呼叫，可用性要高很多。因為就算我們處理Command的後端消費者暫時掛了，也不會影響前端Controller傳送Command，Controller依然可用。從這個角度來說，CQRS架構在資料修改上可用性要更高。不過你可能會說，要是分散式訊息佇列掛了呢？呵呵，對，這確實也是有可能的。但是一般分散式訊息佇列屬於中介軟體，一般中介軟體都具有很高的可用性（支援叢集和主備切換），所以相比我們的應用來說，可用性要高很多。另外，因為命令是先傳送到分散式訊息佇列，這樣就能充分利用分散式訊息佇列的優勢：非同步化、拉模式、削峰填谷、基於佇列的水平擴充套件。這些特性可以保證即便前端Controller在高峰時瞬間傳送大量的Command過來，也不會導致後端處理Command的應用掛掉，因為我們是根據自己的消費能力拉取Command。這點也是CQRS C端在可用性方面的優勢，其實本質也是分散式訊息佇列帶來的優勢。所以，從這裡我們可以體會到EDA架構（事件驅動架構）是非常有價值的，這個架構也體現了我們目前比較流行的Reactive Programming（響應式程式設計）的思想。

然後，對於Q端，應該說和傳統架構沒什麼區別，因為都是要處理高併發的查詢。這點以前怎麼優化的，現在還是怎麼優化。但是就像我上面可擴充套件性裡強調的，CQRS架構可以更方便的提供更多的View儲存，資料庫、快取、搜尋引擎、NoSQL，而且這些儲存的更新完全可以並行進行，互相不會拖累。理想的場景，我覺得應該是，如果你的應用要實現全文索引這種複雜查詢，那可以在Q端使用搜尋引擎，比如ElasticSearch；如果你的查詢場景可以通過keyvalue這種資料結構滿足，那我們可以在Q端使用Redis這種NoSQL分散式快取。總之，我認為CQRS架構，我們解決查詢問題會比傳統架構更加容易，因為我們選擇更多了。但是你可能會說，我的場景只能用關係型資料庫解決，且查詢的併發也是非常高。那沒辦法了，唯一的辦法就是分散查詢IO，我們對資料庫做分庫分表，以及對資料庫做一主多備，查詢走備機。這點上，解決思路就是和傳統架構一樣了。


效能、伸縮性

本來想把效能和伸縮性分開寫的，但是想想這兩個其實有一定的關聯，所以決定放在一起寫。

伸縮性的意思是，當一個系統，在100人訪問時，效能（吞吐量、響應時間）很不錯，在100W人訪問時效能也同樣不錯，這就是伸縮性。100人訪問和100W人訪問，對系統的壓力顯然是不同的。如果我們的系統，在架構上，能夠做到通過簡單的增加機器，就能提高系統的服務能力，那我們就可以說這種架構的伸縮性很強。那我們來想想傳統架構和CQRS架構在效能和伸縮性上面的表現。

說到效能，大家一般會先思考一個系統的效能瓶頸在哪裡。只要我們解決了效能瓶頸，那系統就意味著具有通過水平擴充套件來達到可伸縮的目的了（當然這裡沒有考慮資料儲存的水平擴充套件）。所以，我們只要分析一下傳統架構和CQRS架構的瓶頸點在哪裡即可。

傳統架構，瓶頸通常在底層資料庫。然後我們一般的做法是，對於讀：通常使用快取就可以解決大部分查詢問題；對於寫：辦法也有很多，比如分庫分表，或者使用NoSQL，等等。比如阿里大量採用分庫分表的方案，而且未來應該會全部使用高大上的OceanBase來替代分庫分表的方案。通過分庫分表，本來一臺資料庫伺服器高峰時可能要承受10W的高併發寫，如果我們把資料放到十臺資料庫伺服器上，那每臺機器只需要承擔1W的寫，相對於要承受10W的寫，現在寫1W就顯得輕鬆很多了。所以，應該說資料儲存對傳統架構來說，也早已不再是瓶頸了。

傳統架構一次資料修改的步驟是：1）從DB取出資料到記憶體；2）記憶體修改資料；3）更新資料回DB。總共涉及到2次資料庫IO。

然後CQRS架構，CQ兩端加起來所用的時間肯定比傳統架構要多，因為CQRS架構最多有3次資料庫IO，1）持久化命令；2）持久化事件；3）根據事件更新讀庫。為什麼說最多？因為持久化命令這一步不是必須的，有一種場景是不需要持久化命令的。CQRS架構中持久化命令的目的是為了做冪等處理，即我們要防止同一個命令被處理兩次。那哪一種場景下可以不需要持久化命令呢？就是當命令時在建立聚合根時，可以不需要持久化命令，因為建立聚合根所產生的事件的版本號總是為1，所以我們在持久化事件時根據事件版本號就能檢測到這種重複。

所以，我們說，你要用CQRS架構，就必須要接受CQ資料的最終一致性，因為如果你以讀庫的更新完成為操作處理完成的話，那一次業務場景所用的時間很可能比傳統架構要多。但是，如果我們以C端的處理為結束的話，則CQRS架構可能要快，因為C端可能只需要一次資料庫IO。我覺得這裡有一點很重要，對於CQRS架構，我們更加關注C端處理完成所用的時間；而Q端的處理稍微慢一點沒關係，因為Q端只是供我們檢視資料用的（最終一致性）。我們選擇CQRS架構，就必須要接受Q端資料更新有一點點延遲的缺點，否則就不應該使用這種架構。所以，希望大家在根據你的業務場景做架構選型時一定要充分認識到這一點。

所以，總體來說，效能瓶頸方面，兩種架構都能克服。而只要克服了效能瓶頸，那伸縮性就不是問題了（當然，這裡我沒有考慮資料丟失而帶來的系統不可用的問題。這個問題是所有架構都無法迴避的問題，唯一的解決辦法就是資料冗餘，這裡不做展開了）。兩者的瓶頸都在資料的持久化上，但是傳統的架構因為大部分系統都是要儲存資料到關係型資料庫，所以只能自己採用分庫分表的方案。而CQRS架構，如果我們只關注C端的瓶頸，由於C端要儲存的東西很簡單，就是命令和事件；如果你信的過一些成熟的NoSQL（我覺得使用文件性資料庫如MongoDB這種比較適合儲存命令和事件），且你也有足夠的能力和經驗去運維它們，那可以考慮使用NoSQL來持久化。如果你覺得NoSQL靠不住或者沒辦法完全掌控，那可以使用關係型資料庫。但這樣你也要付出努力，比如需要自己負責分庫分表來儲存命令和事件，因為命令和事件的資料量都是很大的。不過目前一些雲服務如阿里雲，已經提供了DRDS這種直接支援分庫分表的資料庫儲存方案，極大的簡化了我們儲存命令和事件的成本。就我個人而言，我覺得我還是會採用分庫分表的方案，原因很簡單：確保資料邏輯、成熟、可靠、可控。所以，通過這個對比我們知道傳統架構，我們必須使用分庫分表（除非阿里這種高大上可以使用OceanBase）；而CQRS架構，可以帶給我們更多選擇空間。因為持久化命令和事件是很簡單的，它們都是不可修改的只讀資料，且對kv儲存友好，也可以選擇文件型NoSQL，C端永遠是新增資料，而沒有修改或刪除資料。最後，就是關於Q端的瓶頸，如果你Q端也是使用關係型資料庫，那和傳統架構一樣，該怎麼優化就怎麼優化。而CQRS架構允許你使用其他的架構來實現Q，所以優化手段相對更多。

結束語

我覺得不論是傳統架構還是CQRS架構，都是不錯的架構。傳統架構門檻低，懂的人也多，且因為大部分專案都沒有什麼大的併發寫入量和資料量。所以應該說大部分專案，採用傳統架構就OK了。但是通過本文的分析，大家也知道了，傳統架構確實也有一些缺點，比如在擴充套件性、可用性、效能瓶頸的解決方案上，都比CQRS架構要弱一點。大家有其他意見，歡迎拍磚，交流才能進步，呵呵。所以，如果你的應用場景是高併發寫、高併發讀、大資料，且希望在擴充套件性、可用性、效能、可伸縮性上表現更優秀，我覺得可以嘗試CQRS架構。但是還有一個問題，CQRS架構的門檻很高，我認為如果沒有成熟的框架支援，很難使用。而目前據我瞭解，業界還沒有很多成熟的CQRS框架，java平臺有axon framework, jdon framework；.NET平臺，ENode框架正在朝這個方向努力。所以，我想這也是為什麼目前幾乎沒有使用CQRS架構的成熟案例的原因之一。另一個原因是使用CQRS架構，需要開發者對DDD有一定的瞭解，否則也很難實踐，而DDD本身要理解沒個幾年也很難運用到實際。還有一個原因，CQRS架構的核心是非常依賴於高效能的分散式訊息中介軟體，所以要選型一個高效能的分散式訊息中介軟體也是一個門檻（java平臺有RocketMQ），.NET平臺我個人專門開發了一個分散式訊息佇列EQueue，呵呵。另外，如果沒有成熟的CQRS框架的支援，那編碼複雜度也會很複雜，比如Event Sourcing，訊息重試，訊息冪等處理，事件的順序處理，併發控制，這些問題都不是那麼容易搞定的。而如果有框架支援，由框架來幫我們搞定這些純技術問題，開發人員只需要關注如何建模，實現領域模型，如何更新讀庫，如何實現查詢，那使用CQRS架構才有可能，因為這樣才可能比傳統的架構開發更簡單，且能獲得很多CQRS架構所帶來的好處。


轉載：http://www.jdon.com/47852

相關文章