最近幾年，在DDD的領(lǐng)域，我們經(jīng)常會(huì)看到CQRS架構(gòu)的概念。我個(gè)人也寫了一個(gè)ENode框架，專門用來(lái)實(shí)現(xiàn)這個(gè)架構(gòu)。CQRS架構(gòu)本身的思想其實(shí)非常簡(jiǎn)單，就是讀寫分離。是一個(gè)很好理解的思想。就像我們用MySQL數(shù)據(jù)庫(kù)的主備，數(shù)據(jù)寫到主，然后查詢從備來(lái)查，主備數(shù)據(jù)的同步由MySQL數(shù)據(jù)庫(kù)自己負(fù)責(zé)，這是一種數(shù)據(jù)庫(kù)層面的讀寫分離。關(guān)于CQRS架構(gòu)的介紹其實(shí)已經(jīng)非常多了，大家可以自行百度或google。我今天主要想總結(jié)一下這個(gè)架構(gòu)相對(duì)于傳統(tǒng)架構(gòu)(三層架構(gòu)、DDD經(jīng)典四層架構(gòu))在數(shù)據(jù)一致性、擴(kuò)展性、可用性、伸縮性、性能這幾個(gè)方面的異同，希望可以總結(jié)出一些優(yōu)點(diǎn)和缺點(diǎn)，為大家在做架構(gòu)選型時(shí)提供參考。
前言
CQRS架構(gòu)由于本身只是一個(gè)讀寫分離的思想，實(shí)現(xiàn)方式多種多樣。比如數(shù)據(jù)存儲(chǔ)不分離，僅僅只是代碼層面讀寫分離，也是CQRS的體現(xiàn);然后數(shù)據(jù)存儲(chǔ)的讀寫分離，C端負(fù)責(zé)數(shù)據(jù)存儲(chǔ)，Q端負(fù)責(zé)數(shù)據(jù)查詢，Q端的數(shù)據(jù)通過C端產(chǎn)生的Event來(lái)同步，這種也是CQRS架構(gòu)的一種實(shí)現(xiàn)。今天我討論的CQRS架構(gòu)就是指這種實(shí)現(xiàn)。另外很重要的一點(diǎn)，C端我們還會(huì)引入Event Sourcing+In Memory這兩種架構(gòu)思想，我認(rèn)為這兩種思想和CQRS架構(gòu)可以完美的結(jié)合，發(fā)揮CQRS這個(gè)架構(gòu)的最大價(jià)值。
數(shù)據(jù)一致性
傳統(tǒng)架構(gòu)，數(shù)據(jù)一般是強(qiáng)一致性的，我們通常會(huì)使用數(shù)據(jù)庫(kù)事務(wù)保證一次操作的所有數(shù)據(jù)修改都在一個(gè)數(shù)據(jù)庫(kù)事務(wù)里，從而保證了數(shù)據(jù)的強(qiáng)一致性。在分布式的場(chǎng)景，我們也同樣希望數(shù)據(jù)的強(qiáng)一致性，就是使用分布式事務(wù)。但是眾所周知，分布式事務(wù)的難度、成本是非常高的，而且采用分布式事務(wù)的系統(tǒng)的吞吐量都會(huì)比較低，系統(tǒng)的可用性也會(huì)比較低。所以，很多時(shí)候，我們也會(huì)放棄數(shù)據(jù)的強(qiáng)一致性，而采用最終一致性;從CAP定理的角度來(lái)說，就是放棄一致性，選擇可用性。
CQRS架構(gòu)，則完全秉持最終一致性的理念。這種架構(gòu)基于一個(gè)很重要的假設(shè)，就是用戶看到的數(shù)據(jù)總是舊的。對(duì)于一個(gè)多用戶操作的系統(tǒng)，這種現(xiàn)象很普遍。比如秒殺的場(chǎng)景，當(dāng)你下單前，也許界面上你看到的商品數(shù)量是有的，但是當(dāng)你下單的時(shí)候，系統(tǒng)提示商品賣完了。其實(shí)我們只要仔細(xì)想想，也確實(shí)如此。因?yàn)槲覀冊(cè)诮缑嫔峡吹降臄?shù)據(jù)是從數(shù)據(jù)庫(kù)取出來(lái)的，一旦顯示到界面上，就不會(huì)變了。但是很可能其他人已經(jīng)修改了數(shù)據(jù)庫(kù)中的數(shù)據(jù)。這種現(xiàn)象在大部分系統(tǒng)中，尤其是高并發(fā)的WEB系統(tǒng)，尤其常見。
所以，基于這樣的假設(shè)，我們知道，即便我們的系統(tǒng)做到了數(shù)據(jù)的強(qiáng)一致性，用戶還是很可能會(huì)看到舊的數(shù)據(jù)。所以，這就給我們?cè)O(shè)計(jì)架構(gòu)提供了一個(gè)新的思路。我們能否這樣做：我們只需要確保系統(tǒng)的一切添加、刪除、修改操作所基于的數(shù)據(jù)是最新的，而查詢的數(shù)據(jù)不必是最新的。這樣就很自然的引出了CQRS架構(gòu)了。C端數(shù)據(jù)保持最新、做到數(shù)據(jù)強(qiáng)一致;Q端數(shù)據(jù)不必最新，通過C端的事件異步更新即可。所以，基于這個(gè)思路，我們開始思考，如何具體的去實(shí)現(xiàn)CQ兩端?？吹竭@里，也許你還有一個(gè)疑問，就是為何C端的數(shù)據(jù)是必須要最新的?這個(gè)其實(shí)很容易理解，因?yàn)槟阋薷臄?shù)據(jù)，那你可能會(huì)有一些修改的業(yè)務(wù)規(guī)則判斷，如果你基于的數(shù)據(jù)不是最新的，那意味著判斷就失去意義或者說不準(zhǔn)確，所以基于老的數(shù)據(jù)所做的修改是沒有意義的。
擴(kuò)展性
傳統(tǒng)架構(gòu)，各個(gè)組件之間是強(qiáng)依賴，都是對(duì)象之間直接方法調(diào)用;而CQRS架構(gòu)，則是事件驅(qū)動(dòng)的思想;從微觀的聚合根層面，傳統(tǒng)架構(gòu)是應(yīng)用層通過過程式的代碼協(xié)調(diào)多個(gè)聚合根一次性以事務(wù)的方式完成整個(gè)業(yè)務(wù)操作。而CQRS架構(gòu)，則是以Saga的思想，通過事件驅(qū)動(dòng)的方式，最終實(shí)現(xiàn)多個(gè)聚合根的交互。另外，CQRS架構(gòu)的CQ兩端也是通過事件的方式異步進(jìn)行數(shù)據(jù)同步，也是事件驅(qū)動(dòng)的一種體現(xiàn)。上升到架構(gòu)層面，那前者就是SOA的思想，后者是EDA的思想。SOA是一個(gè)服務(wù)調(diào)用另一個(gè)服務(wù)完成服務(wù)之間的交互，服務(wù)之間緊耦合;EDA是一個(gè)組件訂閱另一個(gè)組件的事件消息，根據(jù)事件信息更新組件自己的狀態(tài)，所以EDA架構(gòu)，每個(gè)組件都不會(huì)依賴其他的組件;組件之間僅僅通過topic產(chǎn)生關(guān)聯(lián)，耦合性非常低。
上面說了兩種架構(gòu)的耦合性，顯而易見，耦合性低的架構(gòu)，擴(kuò)展性必然好。因?yàn)镾OA的思路，當(dāng)我要加一個(gè)新功能時(shí)，需要修改原來(lái)的代碼;比如原來(lái)A服務(wù)調(diào)用了B,C兩個(gè)服務(wù)，后來(lái)我們想多調(diào)用一個(gè)服務(wù)D，則需要改A服務(wù)的邏輯;而EDA架構(gòu)，我們不需要?jiǎng)蝇F(xiàn)有的代碼，原來(lái)有B,C兩訂閱者訂閱A產(chǎn)生的消息，現(xiàn)在只需要增加一個(gè)新的消息訂閱者D即可。
從CQRS的角度來(lái)說，也有一個(gè)非常明顯的例子，就是Q端的擴(kuò)展性。假設(shè)我們?cè)瓉?lái)Q端只是使用數(shù)據(jù)庫(kù)實(shí)現(xiàn)的，但是后來(lái)系統(tǒng)的訪問量增大，數(shù)據(jù)庫(kù)的更新太慢或者滿足不了高并發(fā)的查詢了，所以我們希望增加緩存來(lái)應(yīng)對(duì)高并發(fā)的查詢。那對(duì)CQRS架構(gòu)來(lái)說很容易，我們只需要增加一個(gè)新的事件訂閱者，用來(lái)更新緩存即可。應(yīng)該說，我們可以隨時(shí)方便的增加Q端的數(shù)據(jù)存儲(chǔ)類型。數(shù)據(jù)庫(kù)、緩存、搜索引擎、NoSQL、日志，等等。我們可以根據(jù)自己的業(yè)務(wù)場(chǎng)景，選擇合適的Q端數(shù)據(jù)存儲(chǔ)，實(shí)現(xiàn)快速查詢的目的。這一切都?xì)w功于我們C端記錄了所有模型變化的事件，當(dāng)我們要增加一種新的View存儲(chǔ)時(shí)，可以根據(jù)這些事件得到View存儲(chǔ)的最新狀態(tài)。這種擴(kuò)展性在傳統(tǒng)架構(gòu)下是很難做到的。
可用性
可用性，無(wú)論是傳統(tǒng)架構(gòu)還是CQRS架構(gòu)，都可以做到高可用，只要我們做到讓我們的系統(tǒng)中每個(gè)節(jié)點(diǎn)都無(wú)單點(diǎn)即可。但是，相比之下，我覺得CQRS架構(gòu)在可用性方面，我們可以有更多的回避余地和選擇空間。
傳統(tǒng)架構(gòu)，因?yàn)樽x寫沒有分離，所以可用性要把讀寫合在一起綜合考慮，難度會(huì)比較更大。因?yàn)閭鹘y(tǒng)架構(gòu)，如果一個(gè)系統(tǒng)的高峰期的并發(fā)寫入很大，比如為2W，并發(fā)讀取也很大，比如為10W。那該系統(tǒng)必須優(yōu)化到能同時(shí)支持這種高并發(fā)的寫入和查詢，否則系統(tǒng)就會(huì)在高峰時(shí)掛掉。這個(gè)就是基于同步調(diào)用思路的系統(tǒng)的缺點(diǎn)，沒有一個(gè)東西去削峰填谷，保存瞬間多出來(lái)的請(qǐng)求，而必須讓系統(tǒng)不管遇到多少請(qǐng)求，都必須能及時(shí)處理完，否則就會(huì)造成雪崩效應(yīng)，造成系統(tǒng)癱瘓。但是一個(gè)系統(tǒng)，不會(huì)一直處在高峰，高峰可能只有半小時(shí)或1小時(shí);但為了確保高峰時(shí)系統(tǒng)不掛掉，我們必須使用足夠的硬件去支撐這個(gè)高峰。而大部分時(shí)候，都不需要這么高的硬件資源，所以會(huì)造成資源的浪費(fèi)。所以，我們說基于同步調(diào)用、SOA思想的系統(tǒng)的實(shí)現(xiàn)成本是非常昂貴的。
而在CQRS架構(gòu)下，因?yàn)镃QRS架構(gòu)把讀和寫分離了，所以可用性相當(dāng)于被隔離在了兩個(gè)部分去考慮。我們只需要考慮C端如何解決寫的可用性，Q端如何解決讀的可用性即可。C端解決可用性，我覺得是更加容易的，因?yàn)镃端是消息驅(qū)動(dòng)的。我們要做任何數(shù)據(jù)修改時(shí)，都會(huì)發(fā)送Command到分布式消息隊(duì)列，然后后端消費(fèi)者處理Command->產(chǎn)生領(lǐng)域事件->持久化事件->發(fā)布事件到分布式消息隊(duì)列->最后事件被Q端消費(fèi)。這個(gè)鏈路是消息驅(qū)動(dòng)的。相比傳統(tǒng)架構(gòu)的直接服務(wù)方法調(diào)用，可用性要高很多。因?yàn)榫退阄覀兲幚鞢ommand的后端消費(fèi)者暫時(shí)掛了，也不會(huì)影響前端Controller發(fā)送Command，Controller依然可用。從這個(gè)角度來(lái)說，CQRS架構(gòu)在數(shù)據(jù)修改上可用性要更高。不過你可能會(huì)說，要是分布式消息隊(duì)列掛了呢?呵呵，對(duì)，這確實(shí)也是有可能的。但是一般分布式消息隊(duì)列屬于中間件，一般中間件都具有很高的可用性(支持集群和主備切換)，所以相比我們的應(yīng)用來(lái)說，可用性要高很多。另外，因?yàn)槊钍窍劝l(fā)送到分布式消息隊(duì)列，這樣就能充分利用分布式消息隊(duì)列的優(yōu)勢(shì)：異步化、拉模式、削峰填谷、基于隊(duì)列的水平擴(kuò)展。這些特性可以保證即便前端Controller在高峰時(shí)瞬間發(fā)送大量的Command過來(lái)，也不會(huì)導(dǎo)致后端處理Command的應(yīng)用掛掉，因?yàn)槲覀兪歉鶕?jù)自己的消費(fèi)能力拉取Command。這點(diǎn)也是CQRS C端在可用性方面的優(yōu)勢(shì)，其實(shí)本質(zhì)也是分布式消息隊(duì)列帶來(lái)的優(yōu)勢(shì)。所以，從這里我們可以體會(huì)到EDA架構(gòu)(事件驅(qū)動(dòng)架構(gòu))是非常有價(jià)值的，這個(gè)架構(gòu)也體現(xiàn)了我們目前比較流行的Reactive Programming(響應(yīng)式編程)的思想。
然后，對(duì)于Q端，應(yīng)該說和傳統(tǒng)架構(gòu)沒什么區(qū)別，因?yàn)槎际且幚砀卟l(fā)的查詢。這點(diǎn)以前怎么優(yōu)化的，現(xiàn)在還是怎么優(yōu)化。但是就像我上面可擴(kuò)展性里強(qiáng)調(diào)的，CQRS架構(gòu)可以更方便的提供更多的View存儲(chǔ)，數(shù)據(jù)庫(kù)、緩存、搜索引擎、NoSQL，而且這些存儲(chǔ)的更新完全可以并行進(jìn)行，互相不會(huì)拖累。理想的場(chǎng)景，我覺得應(yīng)該是，如果你的應(yīng)用要實(shí)現(xiàn)全文索引這種復(fù)雜查詢，那可以在Q端使用搜索引擎，比如ElasticSearch;如果你的查詢場(chǎng)景可以通過keyvalue這種數(shù)據(jù)結(jié)構(gòu)滿足，那我們可以在Q端使用Redis這種NoSql分布式緩存?？傊?，我認(rèn)為CQRS架構(gòu)，我們解決查詢問題會(huì)比傳統(tǒng)架構(gòu)更加容易，因?yàn)槲覀冞x擇更多了。但是你可能會(huì)說，我的場(chǎng)景只能用關(guān)系型數(shù)據(jù)庫(kù)解決，且查詢的并發(fā)也是非常高。那沒辦法了，唯一的辦法就是分散查詢IO，我們對(duì)數(shù)據(jù)庫(kù)做分庫(kù)分表，以及對(duì)數(shù)據(jù)庫(kù)做一主多備，查詢走備機(jī)。這點(diǎn)上，解決思路就是和傳統(tǒng)架構(gòu)一樣了。
性能、伸縮性
本來(lái)想把性能和伸縮性分開寫的，但是想想這兩個(gè)其實(shí)有一定的關(guān)聯(lián)，所以決定放在一起寫。
伸縮性的意思是，當(dāng)一個(gè)系統(tǒng)，在100人訪問時(shí)，性能(吞吐量、響應(yīng)時(shí)間)很不錯(cuò)，在100W人訪問時(shí)性能也同樣不錯(cuò)，這就是伸縮性。100人訪問和100W人訪問，對(duì)系統(tǒng)的壓力顯然是不同的。如果我們的系統(tǒng)，在架構(gòu)上，能夠做到通過簡(jiǎn)單的增加機(jī)器，就能提高系統(tǒng)的服務(wù)能力，那我們就可以說這種架構(gòu)的伸縮性很強(qiáng)。那我們來(lái)想想傳統(tǒng)架構(gòu)和CQRS架構(gòu)在性能和伸縮性上面的表現(xiàn)。
說到性能，大家一般會(huì)先思考一個(gè)系統(tǒng)的性能瓶頸在哪里。只要我們解決了性能瓶頸，那系統(tǒng)就意味著具有通過水平擴(kuò)展來(lái)達(dá)到可伸縮的目的了(當(dāng)然這里沒有考慮數(shù)據(jù)存儲(chǔ)的水平擴(kuò)展)。所以，我們只要分析一下傳統(tǒng)架構(gòu)和CQRS架構(gòu)的瓶頸點(diǎn)在哪里即可。
傳統(tǒng)架構(gòu)，瓶頸通常在底層數(shù)據(jù)庫(kù)。然后我們一般的做法是，對(duì)于讀：通常使用緩存就可以解決大部分查詢問題;對(duì)于寫：辦法也有很多，比如分庫(kù)分表，或者使用NoSQL，等等。比如阿里大量采用分庫(kù)分表的方案，而且未來(lái)應(yīng)該會(huì)全部使用高大上的OceanBase來(lái)替代分庫(kù)分表的方案。通過分庫(kù)分表，本來(lái)一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器高峰時(shí)可能要承受10W的高并發(fā)寫，如果我們把數(shù)據(jù)放到十臺(tái)數(shù)據(jù)庫(kù)服務(wù)器上，那每臺(tái)機(jī)器只需要承擔(dān)1W的寫，相對(duì)于要承受10W的寫，現(xiàn)在寫1W就顯得輕松很多了。所以，應(yīng)該說數(shù)據(jù)存儲(chǔ)對(duì)傳統(tǒng)架構(gòu)來(lái)說，也早已不再是瓶頸了。
傳統(tǒng)架構(gòu)一次數(shù)據(jù)修改的步驟是：1)從DB取出數(shù)據(jù)到內(nèi)存;2)內(nèi)存修改數(shù)據(jù);3)更新數(shù)據(jù)回DB?？偣采婕暗?次數(shù)據(jù)庫(kù)IO。
然后CQRS架構(gòu)，CQ兩端加起來(lái)所用的時(shí)間肯定比傳統(tǒng)架構(gòu)要多，因?yàn)镃QRS架構(gòu)最多有3次數(shù)據(jù)庫(kù)IO，1)持久化命令;2)持久化事件;3)根據(jù)事件更新讀庫(kù)。為什么說最多?因?yàn)槌志没钸@一步不是必須的，有一種場(chǎng)景是不需要持久化命令的。CQRS架構(gòu)中持久化命令的目的是為了做冪等處理，即我們要防止同一個(gè)命令被處理兩次。那哪一種場(chǎng)景下可以不需要持久化命令呢?就是當(dāng)命令時(shí)在創(chuàng)建聚合根時(shí)，可以不需要持久化命令，因?yàn)閯?chuàng)建聚合根所產(chǎn)生的事件的版本號(hào)總是為1，所以我們?cè)诔志没录r(shí)根據(jù)事件版本號(hào)就能檢測(cè)到這種重復(fù)。
所以，我們說，你要用CQRS架構(gòu)，就必須要接受CQ數(shù)據(jù)的最終一致性，因?yàn)槿绻阋宰x庫(kù)的更新完成為操作處理完成的話，那一次業(yè)務(wù)場(chǎng)景所用的時(shí)間很可能比傳統(tǒng)架構(gòu)要多。但是，如果我們以C端的處理為結(jié)束的話，則CQRS架構(gòu)可能要快，因?yàn)镃端可能只需要一次數(shù)據(jù)庫(kù)IO。我覺得這里有一點(diǎn)很重要，對(duì)于CQRS架構(gòu)，我們更加關(guān)注C端處理完成所用的時(shí)間;而Q端的處理稍微慢一點(diǎn)沒關(guān)系，因?yàn)镼端只是供我們查看數(shù)據(jù)用的(最終一致性)。我們選擇CQRS架構(gòu)，就必須要接受Q端數(shù)據(jù)更新有一點(diǎn)點(diǎn)延遲的缺點(diǎn)，否則就不應(yīng)該使用這種架構(gòu)。所以，希望大家在根據(jù)你的業(yè)務(wù)場(chǎng)景做架構(gòu)選型時(shí)一定要充分認(rèn)識(shí)到這一點(diǎn)。
另外，上面再談到數(shù)據(jù)一致性時(shí)提到，傳統(tǒng)架構(gòu)會(huì)使用事務(wù)來(lái)保證數(shù)據(jù)的強(qiáng)一致性;如果事務(wù)越復(fù)雜，那一次事務(wù)鎖的表就越多，鎖是系統(tǒng)伸縮性的大敵;而CQRS架構(gòu)，一個(gè)命令只會(huì)修改一個(gè)聚合根，如果要修改多個(gè)聚合根，則通過Saga來(lái)實(shí)現(xiàn)。從而繞過了復(fù)雜事務(wù)的問題，通過最終一致性的思路做到了最大的并行和最少的并發(fā)，從而整體上提高系統(tǒng)的吞吐能力。
所以，總體來(lái)說，性能瓶頸方面，兩種架構(gòu)都能克服。而只要克服了性能瓶頸，那伸縮性就不是問題了(當(dāng)然，這里我沒有考慮數(shù)據(jù)丟失而帶來(lái)的系統(tǒng)不可用的問題。這個(gè)問題是所有架構(gòu)都無(wú)法回避的問題，唯一的解決辦法就是數(shù)據(jù)冗余，這里不做展開了)。兩者的瓶頸都在數(shù)據(jù)的持久化上，但是傳統(tǒng)的架構(gòu)因?yàn)榇蟛糠窒到y(tǒng)都是要存儲(chǔ)數(shù)據(jù)到關(guān)系型數(shù)據(jù)庫(kù)，所以只能自己采用分庫(kù)分表的方案。而CQRS架構(gòu)，如果我們只關(guān)注C端的瓶頸，由于C端要保存的東西很簡(jiǎn)單，就是命令和事件;如果你信的過一些成熟的NoSQL(我覺得使用文檔性數(shù)據(jù)庫(kù)如MongoDB這種比較適合存儲(chǔ)命令和事件)，且你也有足夠的能力和經(jīng)驗(yàn)去運(yùn)維它們，那可以考慮使用NoSQL來(lái)持久化。如果你覺得NoSQL靠不住或者沒辦法完全掌控，那可以使用關(guān)系型數(shù)據(jù)庫(kù)。但這樣你也要付出努力，比如需要自己負(fù)責(zé)分庫(kù)分表來(lái)保存命令和事件，因?yàn)槊詈褪录臄?shù)據(jù)量都是很大的。不過目前一些云服務(wù)如阿里云，已經(jīng)提供了DRDS這種直接支持分庫(kù)分表的數(shù)據(jù)庫(kù)存儲(chǔ)方案，極大的簡(jiǎn)化了我們存儲(chǔ)命令和事件的成本。就我個(gè)人而言，我覺得我還是會(huì)采用分庫(kù)分表的方案，原因很簡(jiǎn)單：確保數(shù)據(jù)可靠落地、成熟、可控，而且支持這種只讀數(shù)據(jù)的落地，框架內(nèi)置要支持分庫(kù)分表也不是什么難事。所以，通過這個(gè)對(duì)比我們知道傳統(tǒng)架構(gòu)，我們必須使用分庫(kù)分表(除非阿里這種高大上可以使用OceanBase);而CQRS架構(gòu)，可以帶給我們更多選擇空間。因?yàn)槌志没詈褪录呛芎?jiǎn)單的，它們都是不可修改的只讀數(shù)據(jù)，且對(duì)kv存儲(chǔ)友好，也可以選擇文檔型NoSQL，C端永遠(yuǎn)是新增數(shù)據(jù)，而沒有修改或刪除數(shù)據(jù)。最后，就是關(guān)于Q端的瓶頸，如果你Q端也是使用關(guān)系型數(shù)據(jù)庫(kù)，那和傳統(tǒng)架構(gòu)一樣，該怎么優(yōu)化就怎么優(yōu)化。而CQRS架構(gòu)允許你使用其他的架構(gòu)來(lái)實(shí)現(xiàn)Q，所以優(yōu)化手段相對(duì)更多。
結(jié)束語(yǔ)
我覺得不論是傳統(tǒng)架構(gòu)還是CQRS架構(gòu)，都是不錯(cuò)的架構(gòu)。傳統(tǒng)架構(gòu)門檻低，懂的人也多，且因?yàn)榇蟛糠猪?xiàng)目都沒有什么大的并發(fā)寫入量和數(shù)據(jù)量。所以應(yīng)該說大部分項(xiàng)目，采用傳統(tǒng)架構(gòu)就OK了。但是通過本文的分析，大家也知道了，傳統(tǒng)架構(gòu)確實(shí)也有一些缺點(diǎn)，比如在擴(kuò)展性、可用性、性能瓶頸的解決方案上，都比CQRS架構(gòu)要弱一點(diǎn)。大家有其他意見，歡迎拍磚，交流才能進(jìn)步，呵呵。所以，如果你的應(yīng)用場(chǎng)景是高并發(fā)寫、高并發(fā)讀、大數(shù)據(jù)，且希望在擴(kuò)展性、可用性、性能、可伸縮性上表現(xiàn)更優(yōu)秀，我覺得可以嘗試CQRS架構(gòu)。但是還有一個(gè)問題，CQRS架構(gòu)的門檻很高，我認(rèn)為如果沒有成熟的框架支持，很難使用。而目前據(jù)我了解，業(yè)界還沒有很多成熟的CQRS框架，java平臺(tái)有axon framework, jdon framework;.NET平臺(tái)，ENode框架正在朝這個(gè)方向努力。所以，我想這也是為什么目前幾乎沒有使用CQRS架構(gòu)的成熟案例的原因之一。另一個(gè)原因是使用CQRS架構(gòu)，需要開發(fā)者對(duì)DDD有一定的了解，否則也很難實(shí)踐，而DDD本身要理解沒個(gè)幾年也很難運(yùn)用到實(shí)際。還有一個(gè)原因，CQRS架構(gòu)的核心是非常依賴于高性能的分布式消息中間件，所以要選型一個(gè)高性能的分布式消息中間件也是一個(gè)門檻(java平臺(tái)有RocketMQ)，.NET平臺(tái)我個(gè)人專門開發(fā)了一個(gè)分布式消息隊(duì)列EQueue，呵呵。另外，如果沒有成熟的CQRS框架的支持，那編碼復(fù)雜度也會(huì)很復(fù)雜，比如Event Sourcing，消息重試，消息冪等處理，事件的順序處理，并發(fā)控制，這些問題都不是那么容易搞定的。而如果有框架支持，由框架來(lái)幫我們搞定這些純技術(shù)問題，開發(fā)人員只需要關(guān)注如何建模，實(shí)現(xiàn)領(lǐng)域模型，如何更新讀庫(kù)，如何實(shí)現(xiàn)查詢，那使用CQRS架構(gòu)才有可能，因?yàn)檫@樣才可能比傳統(tǒng)的架構(gòu)開發(fā)更簡(jiǎn)單，且能獲得很多CQRS架構(gòu)所帶來(lái)的好處。
轉(zhuǎn)型的最終目的 -提質(zhì)降本增效
分享到微信 ×
打開微信，點(diǎn)擊底部的“發(fā)現(xiàn)”，
使用“掃一掃”即可將網(wǎng)頁(yè)分享至朋友圈。