CQRS（命令查詢職責(zé)分離）是一種在復(fù)雜商業(yè)應(yīng)用中非常有用的模式，特別是當(dāng)讀操作和寫操作有不同需求時(shí)。舉個(gè)例子，寫操作可能想要在關(guān)系型數(shù)據(jù)庫中以規(guī)范化形式維護(hù)一個(gè)模型，而讀操作則可以將模型表現(xiàn)為文檔數(shù)據(jù)庫中的文檔。但是理解CQRS并不容易。它涉及到讀操作、寫操作、事件、命令、領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）、事件溯源以及最終一致性等概念。實(shí)現(xiàn)CQRS的常見方式是創(chuàng)建兩個(gè)服務(wù)，并通過事件進(jìn)行通信。

我們的CQRS實(shí)現(xiàn)

為了將CQRS集成到我們的自定義框架中，我們使用了Axon框架。因?yàn)锳xon是最容易使用的，并且對Spring Boot框架有很好的支持。架構(gòu)圖如下所示：

我們?yōu)閷懭牒妥x取創(chuàng)建了兩個(gè)單獨(dú)的服務(wù)。這兩個(gè)服務(wù)通過 RabbitMQ 連接。

寫入服務(wù)

寫入服務(wù)處理所有的更新操作。我們并沒有試圖說服開發(fā)人員認(rèn)為寫請求就是真正的命令?？刂破髫?fù)責(zé)從請求中創(chuàng)建命令，并通過命令網(wǎng)關(guān)發(fā)布命令?？刂破髋c命令處理程序之間的通信是異步的。命令處理程序通過加載聚合根，執(zhí)行業(yè)務(wù)邏輯，然后將事件發(fā)布到RabbitMQ來處理命令。與此同時(shí)，事件也被保存到事件存儲(chǔ)中。在這個(gè)實(shí)現(xiàn)中，事件存儲(chǔ)充當(dāng)我們的單一真相來源。

讀取服務(wù)

讀取服務(wù)處理所有讀取請求。這里沒有應(yīng)用任何業(yè)務(wù)邏輯。通過監(jiān)聽發(fā)布到 RabbitMQ 的事件來更新數(shù)據(jù)。開發(fā)人員可以選擇任何關(guān)系數(shù)據(jù)庫或 MongoDB 作為讀取數(shù)據(jù)庫。我們希望開發(fā)人員實(shí)現(xiàn)的是讀取優(yōu)化的模型。它們可以存儲(chǔ)數(shù)據(jù)而不進(jìn)行任何規(guī)范化以提高讀取性能。

這是一個(gè)非常簡單的實(shí)現(xiàn)。我們將讀取和寫入分為兩個(gè)服務(wù)，那么我們?yōu)槭裁词×四兀?/span>

為什么我們失敗了？

1. 異步性

當(dāng)我們引入CQRS時(shí)，開發(fā)人員的主要抱怨是“我們將如何更新UI，我們不知道記錄是否成功保存”。這是一個(gè)非常合理的問題，它涉及到我們所熟悉的同步通信方式。這種方式很好，也是我們從一開始就習(xí)慣使用的編碼方式。因?yàn)樗子谕评怼Ｎ覀兛梢缘玫秸埱蟮耐暾鞒獭?/span>

那么為什么我們在事件驅(qū)動(dòng)架構(gòu)（EDA）中使用異步調(diào)用呢？很簡單，就是為了提高響應(yīng)能力。EDA 與異步通信無關(guān)。我們可以在不使用異步通信的情況下實(shí)現(xiàn) CQRS。

2.工作量大

第二個(gè)主要抱怨是“完成基于 CQRS 的微服務(wù)需要兩倍的工作量?！?開發(fā)人員必須創(chuàng)建兩項(xiàng)服務(wù)：命令服務(wù)和讀取服務(wù)。但這就是我們實(shí)施 CQRS 的方式。

3.對所有服務(wù)使用 CQRS

我們告訴開發(fā)人員的是在每個(gè)微服務(wù)中使用 CQRS。我們認(rèn)為整個(gè)系統(tǒng)應(yīng)該是一個(gè)CQRS系統(tǒng)。其結(jié)果是引入了難以管理的復(fù)雜性，這是我們在實(shí)施 CQRS 時(shí)犯的主要錯(cuò)誤之一。

4.較小的微服務(wù)

我們不能說微服務(wù)應(yīng)該有多小，但我們可以確定它的邊界。我們可以使用DDD和限界上下文等概念來識(shí)別微服務(wù)邊界。在 CQRS 中，我們使用聚合的概念。聚合是 邏輯上相關(guān)的域?qū)ο?。例如訂單和訂單?xiàng)目。我們將訂單和訂單項(xiàng)目視為一件事。當(dāng)我們保存訂單時(shí)，會(huì)將其與訂單項(xiàng)目一起保存。當(dāng)我們無法識(shí)別聚合時(shí)，最終會(huì)將其拆分為單獨(dú)的微服務(wù)。這給 CQRS 增加了巨大的復(fù)雜性。當(dāng)收到保存訂單的請求時(shí)，要如何保存訂單項(xiàng)目？

更小的微服務(wù)意味著更多的微服務(wù)。由于我們將 CQRS 應(yīng)用于所有服務(wù)，最終使服務(wù)數(shù)量增加了一倍。這是無法控制的。

總結(jié)

這次失敗的主要原因是因?yàn)殄e(cuò)誤的實(shí)現(xiàn)，并且大多數(shù)與 CQRS 無關(guān)。我們從中學(xué)到的是，必須理解微服務(wù)和 CQRS 的關(guān)鍵概念，然后才能將它們整合好。