建站
咨詢
售后
建站咨詢
新聞中心
背景問題
簡單的需求
當(dāng)我們系統(tǒng)中的數(shù)據(jù)模型層級較少時(shí)，數(shù)據(jù)模型足夠簡單時(shí)，模型與數(shù)據(jù)庫可以直接進(jìn)行映射。這種簡單數(shù)據(jù)模型使我們不需要針對其相互關(guān)系進(jìn)行復(fù)雜的建模設(shè)計(jì)，直接在工程中使用經(jīng)典的三層模型就足以支撐項(xiàng)目需求。
成都創(chuàng)新互聯(lián)公司是專業(yè)的涇源網(wǎng)站建設(shè)公司，涇源接單;提供網(wǎng)站建設(shè)、網(wǎng)站制作,網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行涇源網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!
對于這種簡單系統(tǒng)，過度設(shè)計(jì)會增加后續(xù)維護(hù)、重構(gòu)的成本(并不能保證預(yù)設(shè)計(jì)能完美符合后續(xù)需求)。同時(shí)，對于簡單系統(tǒng)，我們大部分的需求都只涉及其中的少量數(shù)據(jù)模型邏輯處理。
而我們直接對數(shù)據(jù)模型進(jìn)行CURD就能滿足需求，進(jìn)而的結(jié)論就是：
針對簡單需求，我們不需要特別區(qū)別查詢和增刪改的程序結(jié)構(gòu)。
復(fù)雜的需求
如果我們的系統(tǒng)具有一定復(fù)雜性，這種復(fù)雜性可能是源于訪問頻次、數(shù)據(jù)量或者是數(shù)據(jù)模型數(shù)量。這時(shí)候我們遇到的問題是數(shù)據(jù)在查詢和更新的需求差距逐漸變大。
- 頻次：數(shù)據(jù)的查詢頻次會遠(yuǎn)高于新增、更新、刪除頻次。
- 數(shù)據(jù)量：數(shù)據(jù)量變大后會增加對數(shù)據(jù)進(jìn)行分庫分表的設(shè)計(jì)訴求，從而導(dǎo)致數(shù)據(jù)查詢變得的復(fù)雜性(涉及分表關(guān)鍵字)。
- 數(shù)據(jù)模型數(shù)量：數(shù)據(jù)模型數(shù)量的增大，會導(dǎo)致在進(jìn)行新增、更新與刪除操作時(shí)同時(shí)影響的數(shù)據(jù)模型變多，而在查詢時(shí)同時(shí)跨多模型的查詢條件會讓查詢的性能具有極大的挑戰(zhàn)性。
根據(jù)以上舉例我們可以發(fā)現(xiàn)，當(dāng)我們的需求具有一定的復(fù)雜性后，根據(jù)引入復(fù)雜性的不同，會導(dǎo)致系統(tǒng)功能上需要用更加復(fù)雜的設(shè)計(jì)來對需求的復(fù)雜性進(jìn)行支撐。同時(shí)我們也可以發(fā)現(xiàn)，引入的不同復(fù)雜性在增刪改和查詢方面的帶來的功能需求差別很大。
所以：
需求的復(fù)雜性會放大程序中查詢和增刪改的設(shè)計(jì)差異。
DDD的需求
如果我們對系統(tǒng)整體的構(gòu)建與設(shè)計(jì)有了更高的可維護(hù)性與可擴(kuò)展性要求，以至于我們需要使用DDD來設(shè)計(jì)整個(gè)系統(tǒng)。
在這種情況下往往模型中具有相對復(fù)雜的模型關(guān)系，在增刪改時(shí)我們需要將所有請求封裝為領(lǐng)域?qū)ο螅员愠绦蚩梢曰陬I(lǐng)域模型完成大量復(fù)雜的校驗(yàn)、業(yè)務(wù)邏輯。而在查詢需求時(shí)，我們常常需要組織跨領(lǐng)域數(shù)據(jù)來完成一個(gè)列表中數(shù)據(jù)內(nèi)容的展示。所以：
在DDD設(shè)計(jì)中，增刪改操作便于應(yīng)用領(lǐng)域模型執(zhí)行，而查詢操作往往無法直接通過領(lǐng)域模型執(zhí)行。
CQRS模式
問題的抽象
根據(jù)第一節(jié)中的內(nèi)容我們可以發(fā)現(xiàn)，在進(jìn)行系統(tǒng)架構(gòu)設(shè)計(jì)時(shí)，當(dāng)系統(tǒng)出現(xiàn)復(fù)雜性后存在一個(gè)核心問題：
增刪改類型的功能與查詢類型的功能，在功能需求上具有較大的差異。
這種差異帶來的直接結(jié)果就是在系統(tǒng)開發(fā)的過程中，針對增刪改和查詢操作的業(yè)務(wù)設(shè)計(jì)上差異會比較大。如果舉幾個(gè)例子來說的話，比如：
- 針對增刪改系統(tǒng)我們需要事務(wù)來保證多領(lǐng)域模型的更新原子性;針對查詢我們需要增加緩存來提高熱點(diǎn)數(shù)據(jù)的查詢性能。
- 數(shù)據(jù)讀取和寫入的模型通常是不匹配的，他們維護(hù)和查詢的列或者屬性坑沒有交集。
- 在更新的時(shí)候查詢數(shù)據(jù)可能會產(chǎn)生沖突。
- 使用統(tǒng)一模型進(jìn)行存儲可能會導(dǎo)致復(fù)雜查詢時(shí)的性能降低。
CQRS本質(zhì)
由于存在增刪改與查詢邏輯有差異的這個(gè)問題，為了更好的針對差異進(jìn)行抽象，我們可以將它們分開進(jìn)行設(shè)計(jì)。也就是我們的CQRS模式，即命令查詢的責(zé)任分離Command Query Responsibility Segregation模式。其中我們稱增刪改為命令型操作。
CQRS本質(zhì)上是一種讀寫分離設(shè)計(jì)思想，這種框架設(shè)計(jì)模式將命令型業(yè)務(wù)和查詢型業(yè)務(wù)分開單獨(dú)處理。通過這種方式，CQRS可以針對命令和查詢單獨(dú)進(jìn)行業(yè)務(wù)模型上的設(shè)計(jì)，從而用更加適合各自場景的方案與組件來提供能力。
查詢
查詢操作并不會修改數(shù)據(jù)庫中的內(nèi)容，所以查詢本身是一種冪等操作，以同一個(gè)查詢條件在系統(tǒng)不改變的情況下反復(fù)執(zhí)行會返回相同的結(jié)果，我們可以針對這種特性提供數(shù)據(jù)緩存來提高系統(tǒng)性能;同時(shí)因?yàn)椴挥绊憯?shù)據(jù)庫，查詢邏輯是不會產(chǎn)生數(shù)據(jù)一致性問題。查詢往往會存在較高的使用頻率。
命令操作會直接修改數(shù)據(jù)庫，并針對多個(gè)領(lǐng)域模型的情況下我們需要增加來保證操作的原子性。而對于一個(gè)命令操作，我們往往是不直接依賴命令的返回值的，所以通?？梢援惒綀?zhí)行命令操作。對于一般系統(tǒng)來說，往往命令操作的使用頻次會較低。
簡單實(shí)用
由于CQRS的本質(zhì)是對于讀寫操作的分離，所以比較簡單的CQRS的做法是：
CQ兩端數(shù)據(jù)庫表共享，CQ兩端只是在上層代碼上分離。
這種做法在不對數(shù)據(jù)庫進(jìn)行分離設(shè)計(jì)的情況下，CQ兩端在上層代碼進(jìn)行分離個(gè)字單獨(dú)維護(hù)，例如命令型的都用xxxManagerController、xxxManagerService來定義，而查詢則直接用xxxController、xxxService定義。
因?yàn)槭褂猛粋€(gè)數(shù)據(jù)庫，所以沒有CQ兩端的數(shù)據(jù)一致性問題。但因?yàn)橐呀?jīng)對上層代碼進(jìn)行了抽離，所以可以滿足一些設(shè)計(jì)特性如：
- 命令應(yīng)基于任務(wù)，而不是以數(shù)據(jù)為中心。
- 命令可以放置在隊(duì)列上進(jìn)行異步處理，而不是同步處理。
- 查詢從不修改數(shù)據(jù)庫。 查詢返回的 DTO 不封裝任何域知識。
這種方案可以滿足代碼邏輯上的分離維護(hù)，但由于是使用同一數(shù)據(jù)庫表，所以無法根據(jù)CQ兩種業(yè)務(wù)的特點(diǎn)單獨(dú)進(jìn)行模型設(shè)計(jì)。
關(guān)注性能
在代碼分離的基礎(chǔ)上，我們可以再將數(shù)據(jù)存儲的模型進(jìn)行物理分離，讀取存儲可以是寫入存儲的只讀副本，使用多個(gè)只讀副本可以提高查詢性能;也可能為讀取模型單獨(dú)設(shè)計(jì)庫表。單獨(dú)對查詢和更新進(jìn)行模型設(shè)計(jì)可以減小設(shè)計(jì)和實(shí)現(xiàn)的難度。并且此時(shí)讀取數(shù)據(jù)庫可使用自己的已針對查詢進(jìn)行優(yōu)化的數(shù)據(jù)架構(gòu)。比如讀數(shù)據(jù)庫可以直接存儲查詢數(shù)據(jù)寬表從而避免進(jìn)行join操作或者復(fù)雜的查詢映射。甚至可以針對讀取操作使用mongo或者es等nosql數(shù)據(jù)庫對查詢邏輯進(jìn)行增強(qiáng)。
分離后的數(shù)據(jù)將存在在不同的數(shù)據(jù)庫中，Q的數(shù)據(jù)由C端同步過來。通常，這是通過在每次更新數(shù)據(jù)庫時(shí)使寫入模型發(fā)布事件來實(shí)現(xiàn)的。 而說到數(shù)據(jù)同步則就有同步執(zhí)行和異步執(zhí)行兩種方案：
- 同步：導(dǎo)致性能降低，但是可以保證數(shù)據(jù)的強(qiáng)一致性。
- 異步：擁有較高的性能，但需要系統(tǒng)接受最終一致性的。
同樣的，這種同步也可以解釋為對緩存進(jìn)行的更新，即：查詢數(shù)據(jù)庫是使用緩存，而寫入數(shù)據(jù)庫使用普通MySQL，兩者之間數(shù)據(jù)同步通過領(lǐng)域事件實(shí)現(xiàn)最終一致性。
進(jìn)一步強(qiáng)化
進(jìn)一步的，由于命令操作實(shí)際上是對“操作”進(jìn)行的記錄，而只有查詢才需要將所有的操作進(jìn)行匯總展示?；谶@種思想，可以使用事件溯源EventSourcing模式來進(jìn)行命令操作的記錄。在這種方案下，保存記錄時(shí)更新的不是當(dāng)前的記錄，而是會導(dǎo)致狀態(tài)變化的事件日志，每個(gè)事件表示對數(shù)據(jù)所作的一系列更改，而我們可以通過重播事件構(gòu)造數(shù)據(jù)當(dāng)前的狀態(tài)(可以參考Mysql的Binlog設(shè)計(jì))。這種記錄的優(yōu)點(diǎn)是可以根據(jù)回放，重現(xiàn)每一次狀態(tài)變更的時(shí)間點(diǎn)以及變更軌跡。而查詢則可以根據(jù)當(dāng)前狀態(tài)的快照來為查詢提速。來自于網(wǎng)絡(luò)的架構(gòu)圖：
這種設(shè)計(jì)模式聽起來就比較復(fù)雜，但是卻有很多好處，例如：實(shí)現(xiàn)透明的分布式處理，當(dāng)使用事件作為狀態(tài)改變的引擎時(shí)，你可以通過實(shí)現(xiàn)多任務(wù)并發(fā)處理，比如通過JVM并行計(jì)算或事件消息總線機(jī)制，事件能夠很容易序列化，并在多個(gè)服務(wù)器之間傳送。同時(shí)因?yàn)槭潜Ａ舻牟僮饔涗洠梢栽诨胤诺臅r(shí)候?qū)τ诋惓２僮鲾?shù)據(jù)進(jìn)行過濾，從而增加了數(shù)據(jù)的魯棒性。
使用挑戰(zhàn)
如果希望使用CQRS，根據(jù)你希望實(shí)現(xiàn)的系統(tǒng)性能，你需要評估當(dāng)前系統(tǒng)架構(gòu)以及個(gè)人經(jīng)驗(yàn)是否有以下能力：
- 復(fù)雜性設(shè)計(jì)：盡管CQRS基礎(chǔ)理念較為容易理解，但是這種模式會導(dǎo)致系統(tǒng)的構(gòu)建復(fù)雜度上升，尤其是進(jìn)一步使用事件溯源模式時(shí)。
- 消息隊(duì)列處理：在進(jìn)行高性能設(shè)計(jì)的時(shí)候，通常會使用消息處理命令和發(fā)布更新事件。在此情況下，應(yīng)用程序必須處理消息失敗或重復(fù)的消息。
- 最終一致性：如果分離讀取和寫入數(shù)據(jù)庫，讀取數(shù)據(jù)可能會過時(shí)。 必須更新讀取模型存儲，以反映對寫入模型存儲區(qū)所做的更改，并且在用戶根據(jù)過時(shí)的讀取數(shù)據(jù)發(fā)出請求時(shí)，可能很難檢測到這種情況。
選型建議
對于以下場景不建議引入CQRS：
- 領(lǐng)域或者業(yè)務(wù)十分簡單。
- 基本的CRUD就可以支撐完整的系統(tǒng)數(shù)據(jù)訪問需求。
如果系統(tǒng)存在一定的復(fù)雜性，并且有以下的特點(diǎn)，則可以根據(jù)特點(diǎn)，選擇適合的CQRS實(shí)現(xiàn)方式。
- 在用戶操作中，需要在用戶界面中進(jìn)行一系列的復(fù)雜操作來最終定義、組裝、修改領(lǐng)域模型。寫模型需要有完成的命令處理堆棧，包括：輸入驗(yàn)證、業(yè)務(wù)處理、業(yè)務(wù)驗(yàn)證。而讀模型只需要返回視圖中所用到的DTO數(shù)據(jù)。讀模型與寫模型只需要最終一致性關(guān)系。
- 對于用戶的操作訪問，需要以較小的粒度定義命令，并通過合并命令的方式避免命令沖突。
- 數(shù)據(jù)寫入和數(shù)據(jù)讀取之前存在比較大的性能區(qū)別，需要分開進(jìn)行數(shù)據(jù)優(yōu)化。尤其是讀取次數(shù)遠(yuǎn)大于寫入次數(shù)的場景，可以對讀模型進(jìn)行水平擴(kuò)展。
- 當(dāng)團(tuán)隊(duì)人員可以分拆分，組成專門針對復(fù)雜業(yè)務(wù)寫場景的組，以及專門針對高頻查詢和用戶界面的組。
- 當(dāng)系統(tǒng)隨時(shí)間不斷演進(jìn)，不斷包含多個(gè)版本的模型，或者業(yè)務(wù)規(guī)則會定期修改?？梢栽趯懩Ｊ街邪鄠€(gè)版本的模型，而讀模式中使用統(tǒng)一的視圖模型。
- 與其他系統(tǒng)集成時(shí)，希望不會受到其他系統(tǒng)故障的影響(讀寫庫表分離)。
最后
總的來說，CQRS是處理復(fù)雜問題的一種具體實(shí)現(xiàn)方案，常用于配合DDD使用。
總結(jié)CQRS 的主要優(yōu)點(diǎn)包括：
- 獨(dú)立縮放：CQRS 允許讀取和寫入工作負(fù)載獨(dú)立縮放，這可能會減少鎖爭用。
- 優(yōu)化的數(shù)據(jù)架構(gòu)： 讀取端可使用針對查詢優(yōu)化的架構(gòu)，寫入端可使用針對更新優(yōu)化的架構(gòu)。
- 安全性：更輕松地確保僅正確的域?qū)嶓w對數(shù)據(jù)執(zhí)行寫入操作。
- 關(guān)注點(diǎn)分離：分離讀取和寫入端可使模型更易維護(hù)且更靈活。 大多數(shù)復(fù)雜的業(yè)務(wù)邏輯被分到寫模型。 讀模型會變得相對簡單。
- 查詢更簡單：通過將具體化視圖存儲在讀取數(shù)據(jù)庫中，應(yīng)用程序可在查詢時(shí)避免復(fù)雜聯(lián)接。
本文標(biāo)題：一篇帶你了解一下CQRS模式
文章路徑：http://www.5511xx.com/article/dhjpghc.html
