#
https://www.ngdata.com/parsing-a-large-json-file-efficiently-and-easily/
https://sites.google.com/site/gson/streaming
http://www.acuriousanimal.com/2015/10/23/reading-json-file-in-stream-mode-with-gson.html
public static void main(String [] args) throws IOException {
String filePath = "C:big-data.json";
FileInputStream in = new FileInputStream(new File(filePath));
JsonReader reader = new JsonReader(new InputStreamReader(in, "UTF-8"));
Gson gson = new GsonBuilder().create();
// reader.beginObject();
// reader.nextName();
reader.beginObject();//跳過(guò)"{"
while (reader.hasNext()) {
// Read data into object model
JsonToken jsonToken = reader.peek();
if(jsonToken.equals(JsonToken.NAME)) {
String name = reader.nextName();
if(name.equalsIgnoreCase("SUMMARY")) {
// reader.beginObject();
Summary summary = gson.fromJson(reader, Summary.class);
logger.info(summary.toString());
break;
// reader.endObject();//跳過(guò)"}"
}
} /*else if(jsonToken.equals(JsonToken.BEGIN_OBJECT)) {
reader.beginObject();
} else if(jsonToken.equals(JsonToken.STRING)) {
logger.info(reader.nextString());
} else if(jsonToken.equals(JsonToken.NUMBER)) {
logger.info(reader.nextInt() + "");
} else if(jsonToken.equals(JsonToken.END_OBJECT)) {
reader.endObject();
} */
// Summary summary = gson.fromJson(reader, Summary.class);
// break;
}
reader.close();
}
SpringBoot 整合 Quartz 實(shí)現(xiàn)定時(shí)任務(wù)管理模塊
https://juejin.im/post/5a7157f56fb9a01cb049a158
https://www.oschina.net/news/91924/10-open-source-technology-trends-2018
http://www.iteye.com/news/32843
JAX-RS 2比JAX-RS 1增加了過(guò)濾器、攔截器、異步處理等特性。@import url(http://www.aygfsteel.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);
JAXRSClientSpringBoot
CXFSpringBoot
Restfull Webservice書源碼
JAX-RS 2.0 REST客戶端編程實(shí)例
本人的DEMO
設(shè)計(jì)文檔模板：
- 系統(tǒng)背景和定位
- 業(yè)務(wù)需求描述
- 領(lǐng)域語(yǔ)言整理，主要是整理領(lǐng)域中的各種術(shù)語(yǔ)的定義，名詞解釋
- 領(lǐng)域劃分（分析出子域、核心域、支撐域）
- 系統(tǒng)用例圖
- 每個(gè)子域的領(lǐng)域模型設(shè)計(jì)（實(shí)體、值對(duì)象、聚合、領(lǐng)域事件，需要注意的是：領(lǐng)域模型是需要抽象的，要分析業(yè)務(wù)本質(zhì)，而不是簡(jiǎn)單的直接對(duì)需求進(jìn)行建模）
- 領(lǐng)域模型詳細(xì)說(shuō)明（如為什么這樣設(shè)計(jì)的原因、模型內(nèi)對(duì)象的關(guān)系、各種業(yè)務(wù)規(guī)則、數(shù)據(jù)一致性規(guī)則等）
- 領(lǐng)域服務(wù)、倉(cāng)儲(chǔ)、工廠設(shè)計(jì)
- Saga業(yè)務(wù)流程設(shè)計(jì)
- 關(guān)鍵聚合根的狀態(tài)流轉(zhuǎn)圖
- 場(chǎng)景走查（講述如何通過(guò)領(lǐng)域模型、領(lǐng)域服務(wù)、倉(cāng)儲(chǔ)、Saga流程等完成系統(tǒng)用例以及關(guān)鍵業(yè)務(wù)流程的）
- 架構(gòu)設(shè)計(jì)（如傳統(tǒng)三層架構(gòu)、經(jīng)典四層架構(gòu)、CQRS/ES架構(gòu)）
一些其他的思考：
- 去除一切花俏的建模技巧，我覺(jué)得最重要的方向就是去努力分析問(wèn)題和事物的本質(zhì)，針對(duì)這個(gè)本質(zhì)進(jìn)行領(lǐng)域建模。這個(gè)領(lǐng)域建模，最主要的還是鍛煉的人的事物抽象能力。10個(gè)人，建出來(lái)的領(lǐng)域模型都不同。本質(zhì)原因就是大家對(duì)同一個(gè)問(wèn)題的理解不同，對(duì)事物的本質(zhì)的理解不同。雖然最終都能解決當(dāng)前的問(wèn)題，但是對(duì)適應(yīng)未來(lái)需求變化的能力卻是不同。
- 所以，我們要把時(shí)間花在多理解業(yè)務(wù)上，讓自己成為領(lǐng)域?qū)＜遥挥羞@樣，才能充分理解業(yè)務(wù)。多理解一點(diǎn)業(yè)務(wù)，你才能更好的抽象出業(yè)務(wù)本質(zhì)背后的領(lǐng)域模型。很少有人能做到很快理解業(yè)務(wù)，并很快針對(duì)業(yè)務(wù)設(shè)計(jì)出正確的領(lǐng)域模型，至少我是不行。
- 領(lǐng)域建模需要時(shí)間，是一個(gè)迭代的過(guò)程，人無(wú)完人。而時(shí)間很多時(shí)候也不會(huì)很充足，所以，不太可能一步到位把領(lǐng)域設(shè)計(jì)做的很完美。我們?cè)谡w項(xiàng)目規(guī)劃的時(shí)候可能會(huì)有個(gè)大的架構(gòu)設(shè)計(jì)、業(yè)務(wù)大圖（邊界思維），但是不可能達(dá)到領(lǐng)域設(shè)計(jì)的粒度，只能是一期一期的完善，到最后可能才會(huì)有完整的上面的目錄內(nèi)容。每一期都需要考慮支持的場(chǎng)景約束、上下文、系統(tǒng)邊界、持續(xù)集成的相關(guān)設(shè)計(jì)。設(shè)計(jì)product, not project。
從遇到問(wèn)題開(kāi)始
當(dāng)人們要做一個(gè)軟件系統(tǒng)時(shí)，一般總是因?yàn)橛龅搅耸裁磫?wèn)題，然后希望通過(guò)一個(gè)軟件系統(tǒng)來(lái)解決。
比如，我是一家企業(yè)，然后我覺(jué)得我現(xiàn)在線下銷售自己的產(chǎn)品還不夠，我希望能夠在線上也能銷售自己的產(chǎn)品。所以，自然而然就想到要做一個(gè)普通電商系統(tǒng)，用于實(shí)現(xiàn)在線銷售自己企業(yè)產(chǎn)品的目的。
再比如，我是一家互聯(lián)網(wǎng)公司，公司有很多系統(tǒng)對(duì)外提供服務(wù)，面向很多客戶端設(shè)備。但是最近由于各種原因，導(dǎo)致服務(wù)經(jīng)常出故障。所以，我們希望通過(guò)各種措施提高服務(wù)的質(zhì)量和穩(wěn)定性。其中的一個(gè)措施就是希望能做一個(gè)灰度發(fā)布的平臺(tái)，這個(gè)平臺(tái)可以提供灰度發(fā)布的服務(wù)。然后，當(dāng)某個(gè)業(yè)務(wù)系統(tǒng)做了一些修改并需要發(fā)布時(shí)，可以使用我們的灰度發(fā)布平臺(tái)來(lái)非常方便的實(shí)現(xiàn)灰度發(fā)布的功能。比如在灰度發(fā)布平臺(tái)上方便的定制允許哪些特定的客戶端才會(huì)訪問(wèn)新服務(wù)，哪些客戶端繼續(xù)使用老服務(wù)。灰度發(fā)布平臺(tái)可以提供各種灰度的策略。有了這樣的灰度發(fā)布機(jī)制，那即便系統(tǒng)的新邏輯有什么問(wèn)題，受影響的面也不會(huì)很大，在可控范圍內(nèi)。所以，如果公司里的所有對(duì)外提供服務(wù)的系統(tǒng)都接入了灰度平臺(tái)，那這些系統(tǒng)的發(fā)布環(huán)節(jié)就可以更加有保障了。
總之，我們做任何一個(gè)軟件系統(tǒng)，都是有原因的，否則就沒(méi)必要做這個(gè)系統(tǒng)，而這個(gè)原因就是我們遇到的問(wèn)題。所以，通過(guò)問(wèn)題，我們就知道了我們需要一個(gè)什么樣的系統(tǒng)，這個(gè)系統(tǒng)解決什么樣的問(wèn)題。最后，我們就很自然的得出了一個(gè)目標(biāo)，即知道了自己要什么。比如我要做一個(gè)論壇、一個(gè)博客系統(tǒng)、一個(gè)電商平臺(tái)、一個(gè)灰度發(fā)布系統(tǒng)、一個(gè)IDE、一個(gè)分布式消息隊(duì)列、一個(gè)通信框架，等等。
DDD切入點(diǎn)1 - 理解概念
DDD的全稱為Domain-driven Design，即領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)。下面我從領(lǐng)域、問(wèn)題域、領(lǐng)域模型、設(shè)計(jì)、驅(qū)動(dòng)這幾個(gè)詞語(yǔ)的含義和聯(lián)系的角度去闡述DDD是如何融入到我們平時(shí)的軟件開(kāi)發(fā)初期階段的。要理解什么是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)，首先要理解什么是領(lǐng)域，什么是設(shè)計(jì)，還有驅(qū)動(dòng)是什么意思，什么驅(qū)動(dòng)什么。
什么是領(lǐng)域（Domain）？
前面我們已經(jīng)清楚的知道我們現(xiàn)在要做一個(gè)什么樣的系統(tǒng)，這個(gè)系統(tǒng)需要解決什么問(wèn)題。我認(rèn)為任何一個(gè)系統(tǒng)都會(huì)屬于某個(gè)特定的領(lǐng)域，比如論壇是一個(gè)領(lǐng)域，只要你想做一個(gè)論壇，那這個(gè)論壇的核心業(yè)務(wù)是確定的，比如都有用戶發(fā)帖、回帖等核心基本功能。比如電商平臺(tái)、普通電商系統(tǒng)，這種都屬于網(wǎng)上電商領(lǐng)域，只要是這個(gè)領(lǐng)域的系統(tǒng)，那都有商品瀏覽、購(gòu)物車、下單、減庫(kù)存、付款交易等核心環(huán)節(jié)。所以，同一個(gè)領(lǐng)域的系統(tǒng)都具有相同的核心業(yè)務(wù)，因?yàn)樗麄円鉀Q的問(wèn)題的本質(zhì)是類似的。
因此，我們可以推斷出，一個(gè)領(lǐng)域本質(zhì)上可以理解為就是一個(gè)問(wèn)題域，只要是同一個(gè)領(lǐng)域，那問(wèn)題域就相同。所以，只要我們確定了系統(tǒng)所屬的領(lǐng)域，那這個(gè)系統(tǒng)的核心業(yè)務(wù)，即要解決的關(guān)鍵問(wèn)題、問(wèn)題的范圍邊界就基本確定了。通常我們說(shuō)，要成為一個(gè)領(lǐng)域的專家，必須要在這個(gè)領(lǐng)域深入研究很多年才行。因?yàn)橹挥心阊芯苛撕芏嗄辏悴艜?huì)遇到非常多的該領(lǐng)域的問(wèn)題，同時(shí)你解決這個(gè)領(lǐng)域中的問(wèn)題的經(jīng)驗(yàn)也非常豐富。很多時(shí)候，領(lǐng)域?qū)＜冶燃夹g(shù)專家更加吃香，比如金融領(lǐng)域的專家。
什么是設(shè)計(jì)（Design）？
DDD中的設(shè)計(jì)主要指領(lǐng)域模型的設(shè)計(jì)。為什么是領(lǐng)域模型的設(shè)計(jì)而不是架構(gòu)設(shè)計(jì)或其他的什么設(shè)計(jì)呢？因?yàn)镈DD是一種基于模型驅(qū)動(dòng)開(kāi)發(fā)的軟件開(kāi)發(fā)思想，強(qiáng)調(diào)領(lǐng)域模型是整個(gè)系統(tǒng)的核心，領(lǐng)域模型也是整個(gè)系統(tǒng)的核心價(jià)值所在。每一個(gè)領(lǐng)域，都有一個(gè)對(duì)應(yīng)的領(lǐng)域模型，領(lǐng)域模型能夠很好的幫我們解決復(fù)雜的業(yè)務(wù)問(wèn)題。
從領(lǐng)域和代碼實(shí)現(xiàn)的角度來(lái)理解，領(lǐng)域模型綁定了領(lǐng)域和代碼實(shí)現(xiàn)，確保了最終的代碼實(shí)現(xiàn)就一定是解決了領(lǐng)域中的核心問(wèn)題的。因?yàn)椋?）領(lǐng)域驅(qū)動(dòng)領(lǐng)域模型設(shè)計(jì)；2）領(lǐng)域模型驅(qū)動(dòng)代碼實(shí)現(xiàn)。我們只要保證領(lǐng)域模型的設(shè)計(jì)是正確的，就能確定領(lǐng)域模型可以解決領(lǐng)域中的核心問(wèn)題；同理，我們只要保證代碼實(shí)現(xiàn)是嚴(yán)格按照領(lǐng)域模型的意圖來(lái)落地的，那就能保證最后出來(lái)的代碼能夠解決領(lǐng)域的核心問(wèn)題的。這個(gè)思路，和傳統(tǒng)的分析、設(shè)計(jì)、編碼這幾個(gè)階段被割裂（并且每個(gè)階段的產(chǎn)物也不同）的軟件開(kāi)發(fā)方法學(xué)形成鮮明的對(duì)比。
什么是驅(qū)動(dòng)（Driven）？
上面其實(shí)已經(jīng)提到了，就是：1）領(lǐng)域驅(qū)動(dòng)領(lǐng)域模型設(shè)計(jì)；2）領(lǐng)域模型驅(qū)動(dòng)代碼實(shí)現(xiàn)。這個(gè)就和我們傳統(tǒng)的數(shù)據(jù)庫(kù)驅(qū)動(dòng)開(kāi)發(fā)的思路形成對(duì)比了。DDD中，我們總是以領(lǐng)域?yàn)檫吔纾治鲱I(lǐng)域中的核心問(wèn)題（核心關(guān)注點(diǎn)），然后設(shè)計(jì)對(duì)應(yīng)的領(lǐng)域模型，再通過(guò)領(lǐng)域模型驅(qū)動(dòng)代碼實(shí)現(xiàn)。而像數(shù)據(jù)庫(kù)設(shè)計(jì)、持久化技術(shù)等這些都不是DDD的核心，而是外圍的東西。
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）告訴我們的最大價(jià)值我覺(jué)得是：當(dāng)我們要開(kāi)發(fā)一個(gè)系統(tǒng)時(shí)，應(yīng)該盡量先把領(lǐng)域模型想清楚，然后再開(kāi)始動(dòng)手編碼，這樣的系統(tǒng)后期才會(huì)很好維護(hù)。但是，很多項(xiàng)目（尤其是互聯(lián)網(wǎng)項(xiàng)目，為了趕工）都是一開(kāi)始模型沒(méi)想清楚，一上來(lái)就開(kāi)始建表寫代碼，代碼寫的非常冗余，完全是過(guò)程是的思考方式，最后導(dǎo)致系統(tǒng)非常難以維護(hù)。而且更糟糕的是，出來(lái)混總是要還的，前期的領(lǐng)域模型設(shè)計(jì)的不好，不夠抽象，如果你的系統(tǒng)會(huì)長(zhǎng)期需要維護(hù)和適應(yīng)業(yè)務(wù)變化，那后面你一定會(huì)遇到各種問(wèn)題維護(hù)上的困難，比如數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)不合理，代碼到處冗余，改BUG到處引入新的BUG，新人對(duì)這種代碼上手困難，等。而那時(shí)如果你再想重構(gòu)模型，那要付出的代價(jià)會(huì)比一開(kāi)始重新開(kāi)發(fā)還要大，因?yàn)槟氵€要考慮兼容歷史的數(shù)據(jù)，數(shù)據(jù)遷移，如何平滑發(fā)布等各種頭疼的問(wèn)題。所以，就導(dǎo)致我們最后天天加班。
雖然，我們都知道這個(gè)道理，但是我也明白，人的習(xí)慣很難改變的，大部分人都很難從面向過(guò)程式的想到哪里寫到哪里的思想轉(zhuǎn)變?yōu)榛谙到y(tǒng)化的模型驅(qū)動(dòng)的思維。我想，這或許是DDD很難在中國(guó)或國(guó)外流行起來(lái)的原因吧。但是，我想這不應(yīng)該成為我們放棄學(xué)習(xí)DDD的原因，對(duì)吧！
概念總結(jié)：
- 領(lǐng)域就是問(wèn)題域，有邊界，領(lǐng)域中有很多問(wèn)題；
- 任何一個(gè)系統(tǒng)要解決的那個(gè)大問(wèn)題都對(duì)應(yīng)一個(gè)領(lǐng)域；
- 通過(guò)建立領(lǐng)域模型來(lái)解決領(lǐng)域中的核心問(wèn)題，模型驅(qū)動(dòng)的思想；
- 領(lǐng)域建模的目標(biāo)針對(duì)我們?cè)陬I(lǐng)域中所關(guān)心的問(wèn)題，即只針對(duì)核心關(guān)注點(diǎn)，而不是整個(gè)領(lǐng)域中的所有問(wèn)題；
- 領(lǐng)域模型在設(shè)計(jì)時(shí)應(yīng)考慮一定的抽象性、通用性，以及復(fù)用價(jià)值；
- 通過(guò)領(lǐng)域模型驅(qū)動(dòng)代碼的實(shí)現(xiàn)，確保代碼讓領(lǐng)域模型落地，代碼最終能解決問(wèn)題；
- 領(lǐng)域模型是系統(tǒng)的核心，是領(lǐng)域內(nèi)的業(yè)務(wù)的直接沉淀，具有非常大的業(yè)務(wù)價(jià)值；
- 技術(shù)架構(gòu)設(shè)計(jì)或數(shù)據(jù)存儲(chǔ)等是在領(lǐng)域模型的外圍，幫助領(lǐng)域模型進(jìn)行落地；
DDD切入點(diǎn)2 - 理解領(lǐng)域、拆分領(lǐng)域、細(xì)化領(lǐng)域
理解領(lǐng)域知識(shí)是基礎(chǔ)
上面我們通過(guò)第一步，雖然我們明確了要做一個(gè)什么樣的系統(tǒng)，該系統(tǒng)主要解決什么問(wèn)題，但是就這樣我們還無(wú)法開(kāi)始進(jìn)行實(shí)際的需求分析和模型設(shè)計(jì)，我們還必須將我們的問(wèn)題進(jìn)行拆分，需求進(jìn)行細(xì)化。有些時(shí)候，需求方，即提出問(wèn)題的人，很可能自己不清楚具體想要什么。他只知道一個(gè)概念，一個(gè)大的目標(biāo)。比如他只知道要做一個(gè)股票交易系統(tǒng)，一個(gè)灰度發(fā)布系統(tǒng)，一個(gè)電商平臺(tái)，一個(gè)開(kāi)發(fā)工具，等。但是他不清楚這些系統(tǒng)應(yīng)該具體做成什么樣子。這個(gè)時(shí)候，我認(rèn)為領(lǐng)域?qū)＜揖头浅Ｖ匾耍珼DD也非常強(qiáng)調(diào)領(lǐng)域?qū)＜业闹匾浴Ｒ驗(yàn)轭I(lǐng)域?qū)＜覍?duì)這個(gè)領(lǐng)域非常了解，對(duì)領(lǐng)域內(nèi)的各種業(yè)務(wù)場(chǎng)景和各種業(yè)務(wù)規(guī)則也非常清楚，總之，對(duì)這個(gè)領(lǐng)域內(nèi)的一切業(yè)務(wù)相關(guān)的知識(shí)都非常了解。所以，他們自然就有能力表達(dá)出系統(tǒng)該做成什么樣子。所以，要知道一個(gè)系統(tǒng)到底該做成什么樣子，到底哪些是核心業(yè)務(wù)關(guān)注點(diǎn)，只能靠沉淀領(lǐng)域內(nèi)的各種知識(shí)，別無(wú)他法。因此，假設(shè)你現(xiàn)在打算做一個(gè)電商平臺(tái)，但是你對(duì)這個(gè)領(lǐng)域沒(méi)什么了解，那你一定得先去了解下該領(lǐng)域內(nèi)主流的電商平臺(tái)，比如淘寶、天貓、京東、亞馬遜等。這個(gè)了解的過(guò)程就是你沉淀領(lǐng)域知識(shí)的過(guò)程。如果你不了解，就算你領(lǐng)域建模的能力再?gòu)?qiáng)，各種技術(shù)架構(gòu)能力再?gòu)?qiáng)也是使不上力。領(lǐng)域?qū)＜也皇悄硞€(gè)固定的角色，而是某一類人，這類人對(duì)這個(gè)領(lǐng)域非常了解。比如，一個(gè)開(kāi)發(fā)人員也可以是一個(gè)領(lǐng)域?qū)＜摇＜僭O(shè)你在一個(gè)公司開(kāi)發(fā)和維護(hù)一個(gè)系統(tǒng)已經(jīng)好幾年了，但是這個(gè)系統(tǒng)的產(chǎn)品經(jīng)理（PD）可能已經(jīng)換過(guò)好幾任了，這種情況下，我相信這幾任產(chǎn)品經(jīng)理都沒(méi)有比你更熟悉這個(gè)領(lǐng)域。
拆分領(lǐng)域
上面我們明白了，領(lǐng)域建模的基礎(chǔ)是要先理解領(lǐng)域，讓自己成為領(lǐng)域?qū)＜摇Ｈ绻龅搅诉@點(diǎn)，我們就打好了堅(jiān)實(shí)的基礎(chǔ)了。但是，有時(shí)一個(gè)領(lǐng)域往往太復(fù)雜，涉及到的領(lǐng)域概念、業(yè)務(wù)規(guī)則、交互流程太多，導(dǎo)致我們沒(méi)辦法直接針對(duì)這個(gè)大的領(lǐng)域進(jìn)行領(lǐng)域建模。所以，我們需要將領(lǐng)域進(jìn)行拆分，本質(zhì)上就是把大問(wèn)題拆分為小問(wèn)題，然后各個(gè)擊破的思路。然后既然把一個(gè)大的領(lǐng)域劃分為了多個(gè)小的領(lǐng)域（子域），那最關(guān)鍵的就是要理清每個(gè)子域的邊界；然后要搞清楚哪些子域是核心子域，哪些是非核心子域，哪些是公共支撐子域；然后，還要思考子域之間的聯(lián)系是什么。那么，我們?cè)撊绾蝿澐肿佑蚰兀课业膫€(gè)人看法是從業(yè)務(wù)相關(guān)性的角度去思考，也就是我們平時(shí)說(shuō)的按業(yè)務(wù)功能為出發(fā)點(diǎn)進(jìn)行劃分。還是拿經(jīng)典的電商系統(tǒng)來(lái)分析，通常一個(gè)電商系統(tǒng)都會(huì)包含好幾個(gè)大塊，比如：
- 會(huì)員中心：負(fù)責(zé)用戶賬號(hào)登錄、用戶信息的管理；
- 商品中心：負(fù)責(zé)商品的展示、導(dǎo)航、維護(hù)；
- 訂單中心：負(fù)責(zé)訂單的生成和生命周期管理；
- 交易中心：負(fù)責(zé)交易相關(guān)的業(yè)務(wù)；
- 庫(kù)存中心：負(fù)責(zé)維護(hù)商品的庫(kù)存；
- 促銷中心：負(fù)責(zé)各種促銷活動(dòng)的支持；
上面這些中心看起來(lái)很自然，因?yàn)榇蠹覍?duì)電子商務(wù)的這個(gè)領(lǐng)域都已經(jīng)非常熟悉了，所以都沒(méi)什么疑問(wèn)，好像很自然的樣子。所以，領(lǐng)域劃分是不是就是沒(méi)什么挑戰(zhàn)了呢？顯然不是。之所以我們覺(jué)得子域劃分很簡(jiǎn)單，是因?yàn)槲覀儗?duì)整個(gè)大領(lǐng)域非常了解了。如果我們遇到一個(gè)冷門的領(lǐng)域，就沒(méi)辦法這么容易的去劃分子域了。這就需要我們先去努力理解領(lǐng)域內(nèi)的知識(shí)。所以，我個(gè)人從來(lái)不相信什么子域劃分的技巧什么的東西，因?yàn)槲矣X(jué)得這個(gè)工作沒(méi)有任何訣竅可以使用。當(dāng)我們不了解一個(gè)東西的時(shí)候，如何去拆解它？當(dāng)我們對(duì)整個(gè)領(lǐng)域有一定的熟悉了，了解了領(lǐng)域內(nèi)的相關(guān)業(yè)務(wù)的本質(zhì)和關(guān)系，我們就自然而然的能劃分出合理的子域了。不過(guò)并不是所有的系統(tǒng)都需要?jiǎng)澐肿佑虻模行┫到y(tǒng)只是解決一個(gè)小問(wèn)題，這個(gè)問(wèn)題不復(fù)雜，可能只有一兩個(gè)核心概念。所以，這種系統(tǒng)完全不需要再劃分子域。但不是絕對(duì)的，當(dāng)一個(gè)領(lǐng)域，我們的關(guān)注點(diǎn)越來(lái)越多，每個(gè)關(guān)注點(diǎn)我們關(guān)注的信息越來(lái)越多的時(shí)候，我們會(huì)不由自主的去進(jìn)一步的劃分子域。比如，也許我們一開(kāi)始將商品和商品的庫(kù)存都放在商品中心里，但是后來(lái)由于庫(kù)存的維護(hù)越來(lái)越復(fù)雜，導(dǎo)致揉在一起對(duì)我們的系統(tǒng)維護(hù)帶來(lái)一定的困難時(shí)，我們就會(huì)考慮將兩者進(jìn)行拆分，這個(gè)就是所謂的業(yè)務(wù)垂直分割。
細(xì)化子域
通過(guò)上面的兩步，我們了解了領(lǐng)域里的知識(shí)，也對(duì)領(lǐng)域進(jìn)行了子域劃分。但這樣還不夠，憑這些我們還無(wú)法進(jìn)行后續(xù)的領(lǐng)域模型設(shè)計(jì)。我們還必須再進(jìn)一步細(xì)化每個(gè)子域，進(jìn)一步明確每個(gè)子域的核心關(guān)注點(diǎn)，即需求細(xì)化。我覺(jué)得我們需要細(xì)化的方面有以下幾點(diǎn)：
- 梳理領(lǐng)域概念：梳理出領(lǐng)域內(nèi)我們關(guān)注的概念、概念的關(guān)系，并統(tǒng)一交流詞匯，形成統(tǒng)一語(yǔ)言；
- 梳理業(yè)務(wù)規(guī)則：梳理出領(lǐng)域內(nèi)我們關(guān)注的各種業(yè)務(wù)規(guī)則，DDD中叫不變性（invariants），比如唯一性規(guī)則，余額不能小于零等；
- 梳理業(yè)務(wù)場(chǎng)景：梳理出領(lǐng)域內(nèi)的核心業(yè)務(wù)場(chǎng)景，比如電商平臺(tái)中的加入購(gòu)物車、提交訂單、發(fā)起付款等核心業(yè)務(wù)場(chǎng)景；
- 梳理業(yè)務(wù)流程：梳理出領(lǐng)域內(nèi)的關(guān)鍵業(yè)務(wù)流程，比如訂單處理流程，退款流程等；
從上面這4個(gè)方面，我們從領(lǐng)域概念、業(yè)務(wù)規(guī)則、交互場(chǎng)景、業(yè)務(wù)流程等維度梳理了我們到底要什么，整理了整個(gè)系統(tǒng)應(yīng)該具備的功能。這個(gè)工作我覺(jué)得是一個(gè)非常具有創(chuàng)造性和有難度的工作。我們一方面會(huì)主觀的定義我們想要什么；另一方面，我們還會(huì)思考我們要的東西的合理性。我認(rèn)為這個(gè)就是產(chǎn)品經(jīng)理的工作，產(chǎn)品經(jīng)理必須要負(fù)起職責(zé)，把他的產(chǎn)品充分設(shè)計(jì)好，從各個(gè)方面去考慮，如何設(shè)計(jì)一個(gè)產(chǎn)品，才能更好的解決用戶的核心訴求，即領(lǐng)域內(nèi)的核心問(wèn)題。如果對(duì)領(lǐng)域不夠了解，如果想不清楚用戶到底要什么，如果思考問(wèn)題不夠全面，談何設(shè)計(jì)出一個(gè)合理的產(chǎn)品呢？
關(guān)于領(lǐng)域概念的梳理，我覺(jué)得可以采用四色原型分析法，這個(gè)分析法通過(guò)系統(tǒng)的方法，將概念劃分為不同的種類，為不同種類的概念標(biāo)注不同的顏色。然后將這些概念有機(jī)的組合起來(lái)，從而讓我們可以清晰的分析出概念和概念之間的關(guān)系。有興趣的同學(xué)可以在網(wǎng)上搜索下四色原型。
注意：上面我說(shuō)的這四點(diǎn)，重點(diǎn)是梳理出我們要什么功能，而不是思考如何實(shí)現(xiàn)這些功能，如何實(shí)現(xiàn)是軟件設(shè)計(jì)人員的職責(zé)。
DDD切入點(diǎn)3 - 領(lǐng)域模型設(shè)計(jì)
這部分內(nèi)容，我想學(xué)習(xí)DDD的人都很熟悉了。DDD原著中提出了很多實(shí)用的建模工具：聚合、實(shí)體、值對(duì)象、工廠、倉(cāng)儲(chǔ)、領(lǐng)域服務(wù)、領(lǐng)域事件。我們可以使用這些工具，來(lái)設(shè)計(jì)每一個(gè)子域的領(lǐng)域模型。最終通過(guò)領(lǐng)域模型圖將設(shè)計(jì)沉淀下來(lái)。要使用這些工具，首先就要理解每個(gè)工具的含義和使用場(chǎng)景。不要以為很簡(jiǎn)單哦，比如聚合的劃分就是一個(gè)非常具有藝術(shù)的活。同一個(gè)系統(tǒng)，不同的人設(shè)計(jì)出來(lái)的聚合是完全不同的。而且很有可能高手之間的最后設(shè)計(jì)出來(lái)的差別反而更大，實(shí)際上我認(rèn)為是世界觀的相互碰撞，呵呵。所以，要領(lǐng)域建模，我覺(jué)得每個(gè)人都應(yīng)該去學(xué)學(xué)哲學(xué)知識(shí)，這有助于我們更好的認(rèn)識(shí)世界，更好的理解事物的本質(zhì)。
關(guān)于這些建模工具的概念和如何運(yùn)用我就不多展開(kāi)了，我博客里也有很多這方面的介紹。下面我再講一下我認(rèn)為比較重要的東西，比如到底該如何領(lǐng)域建模？步驟應(yīng)該是怎么樣的？
領(lǐng)域建模的方法
通過(guò)上面我介紹的細(xì)化子域的內(nèi)容，現(xiàn)在再來(lái)談該如何領(lǐng)域建模，我覺(jué)得就方便很多了。我的主要方法是：
- 劃分好邊界上下文，通常每個(gè)子域（sub domain）對(duì)應(yīng)一個(gè)邊界上下文（bounded context），同一個(gè)邊界上下文中的概念是明確的，沒(méi)有任何歧義；
- 在每個(gè)邊界上下文中設(shè)計(jì)領(lǐng)域模型，具體的領(lǐng)域模型設(shè)計(jì)方法有很多種，如以場(chǎng)景為出發(fā)點(diǎn)的四色原型分析法，或者我早期寫的這篇文章；這個(gè)步驟最核心的就是找出聚合根，并找出每個(gè)聚合根包含的信息；關(guān)于如何設(shè)計(jì)聚合，可以看一下我寫的這篇文章；
- 畫出領(lǐng)域模型圖，圈出每個(gè)模型中的聚合邊界；
- 設(shè)計(jì)領(lǐng)域模型時(shí)，要考慮該領(lǐng)域模型是否滿足業(yè)務(wù)規(guī)則，同時(shí)還要綜合考慮技術(shù)實(shí)現(xiàn)等問(wèn)題，比如并發(fā)問(wèn)題；領(lǐng)域模型不是概念模型，概念模型不關(guān)注技術(shù)實(shí)現(xiàn)，領(lǐng)域模型關(guān)心；所以領(lǐng)域模型才能直接指導(dǎo)編碼實(shí)現(xiàn)；
- 思考領(lǐng)域模型是如何在業(yè)務(wù)場(chǎng)景中發(fā)揮作用的，以及是如何參與到業(yè)務(wù)流程的每個(gè)環(huán)節(jié)的；
- 場(chǎng)景走查，確認(rèn)領(lǐng)域模型是否能滿足領(lǐng)域中的業(yè)務(wù)場(chǎng)景和業(yè)務(wù)流程；
- 模型持續(xù)重構(gòu)、完善、精煉；
領(lǐng)域模型的核心作用：
- 抽象了領(lǐng)域內(nèi)的核心概念，并建立概念之間的關(guān)系；
- 領(lǐng)域模型承擔(dān)了領(lǐng)域內(nèi)的狀態(tài)的維護(hù)；
- 領(lǐng)域模型維護(hù)了領(lǐng)域內(nèi)的數(shù)據(jù)之間的業(yè)務(wù)規(guī)則，數(shù)據(jù)一致性；
下圖是我最近做個(gè)一個(gè)普通電商系統(tǒng)的商品中心的領(lǐng)域模型圖，給大家參考：
領(lǐng)域模型設(shè)計(jì)只是軟件設(shè)計(jì)中的一小部分
需要特別注意的是，領(lǐng)域模型設(shè)計(jì)只是整個(gè)軟件設(shè)計(jì)中的很小一部分。除了領(lǐng)域模型設(shè)計(jì)之外，要落地一個(gè)系統(tǒng)，我們還有非常多的其他設(shè)計(jì)要做，比如：
- 容量規(guī)劃
- 架構(gòu)設(shè)計(jì)
- 數(shù)據(jù)庫(kù)設(shè)計(jì)
- 緩存設(shè)計(jì)
- 框架選型
- 發(fā)布方案
- 數(shù)據(jù)遷移、同步方案
- 分庫(kù)分表方案
- 回滾方案
- 高并發(fā)解決方案
- 一致性選型
- 性能壓測(cè)方案
- 監(jiān)控報(bào)警方案
等等。上面這些都需要我們平時(shí)的大量學(xué)習(xí)和積累。作為一個(gè)合格的開(kāi)發(fā)人員或架構(gòu)師，我覺(jué)得除了要會(huì)DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)，還要會(huì)上面這么多的技術(shù)能力，確實(shí)是非常不容易的。所以，千萬(wàn)不要以為會(huì)DDD了就以為自己很牛逼，實(shí)際上你會(huì)的只是軟件設(shè)計(jì)中的冰山一角而已。
總結(jié)
本文的重點(diǎn)是基于我個(gè)人對(duì)DDD的一些理解，希望能整理出一些自己總結(jié)出來(lái)的一些感悟和經(jīng)驗(yàn)，并分享給大家。我相信很多人已經(jīng)看過(guò)太多DDD書上的東西，我總是感覺(jué)書上的東西看似都太”正規(guī)“，很多時(shí)候我們讀了之后很難消化，就算理解了書里的內(nèi)容，當(dāng)我們想要運(yùn)用到實(shí)踐中時(shí)，總是感覺(jué)無(wú)從下手。本文希望通過(guò)通俗易懂的文字，介紹了一部分我對(duì)DDD的學(xué)習(xí)感悟和實(shí)踐心得，希望能給大家一些啟發(fā)和幫助。
最近幾年，在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ù)通過(guò)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)說(shuō)，就是放棄一致性，選擇可用性。
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)，尤其常見(jiàn)。
所以，基于這樣的假設(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ù)不必最新，通過(guò)C端的事件異步更新即可。所以，基于這個(gè)思路，我們開(kāi)始思考，如何具體的去實(shí)現(xiàn)CQ兩端。看到這里，也許你還有一個(gè)疑問(wèn)，就是為何C端的數(shù)據(jù)是必須要最新的？這個(gè)其實(shí)很容易理解，因?yàn)槟阋薷臄?shù)據(jù)，那你可能會(huì)有一些修改的業(yè)務(wù)規(guī)則判斷，如果你基于的數(shù)據(jù)不是最新的，那意味著判斷就失去意義或者說(shuō)不準(zhǔn)確，所以基于老的數(shù)據(jù)所做的修改是沒(méi)有意義的。
擴(kuò)展性
傳統(tǒng)架構(gòu)，各個(gè)組件之間是強(qiáng)依賴，都是對(duì)象之間直接方法調(diào)用；而CQRS架構(gòu)，則是事件驅(qū)動(dòng)的思想；從微觀的聚合根層面，傳統(tǒng)架構(gòu)是應(yīng)用層通過(guò)過(guò)程式的代碼協(xié)調(diào)多個(gè)聚合根一次性以事務(wù)的方式完成整個(gè)業(yè)務(wù)操作。而CQRS架構(gòu)，則是以Saga的思想，通過(guò)事件驅(qū)動(dòng)的方式，最終實(shí)現(xiàn)多個(gè)聚合根的交互。另外，CQRS架構(gòu)的CQ兩端也是通過(guò)事件的方式異步進(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ì)依賴其他的組件；組件之間僅僅通過(guò)topic產(chǎn)生關(guān)聯(lián)，耦合性非常低。
上面說(shuō)了兩種架構(gòu)的耦合性，顯而易見(jiàn)，耦合性低的架構(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)說(shuō)，也有一個(gè)非常明顯的例子，就是Q端的擴(kuò)展性。假設(shè)我們?cè)瓉?lái)Q端只是使用數(shù)據(jù)庫(kù)實(shí)現(xiàn)的，但是后來(lái)系統(tǒng)的訪問(wèn)量增大，數(shù)據(jù)庫(kù)的更新太慢或者滿足不了高并發(fā)的查詢了，所以我們希望增加緩存來(lái)應(yīng)對(duì)高并發(fā)的查詢。那對(duì)CQRS架構(gòu)來(lái)說(shuō)很容易，我們只需要增加一個(gè)新的事件訂閱者，用來(lái)更新緩存即可。應(yīng)該說(shuō)，我們可以隨時(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īng)顟B(tài)。這種擴(kuò)展性在傳統(tǒng)架構(gòu)下是很難做到的。
可用性
可用性，無(wú)論是傳統(tǒng)架構(gòu)還是CQRS架構(gòu)，都可以做到高可用，只要我們做到讓我們的系統(tǒng)中每個(gè)節(jié)點(diǎn)都無(wú)單點(diǎn)即可。但是，相比之下，我覺(jué)得CQRS架構(gòu)在可用性方面，我們可以有更多的回避余地和選擇空間。
傳統(tǒng)架構(gòu)，因?yàn)樽x寫沒(méi)有分離，所以可用性要把讀寫合在一起綜合考慮，難度會(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)，沒(méi)有一個(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)。所以，我們說(shuō)基于同步調(diào)用、SOA思想的系統(tǒng)的實(shí)現(xiàn)成本是非常昂貴的。
而在CQRS架構(gòu)下，因?yàn)镃QRS架構(gòu)把讀和寫分離了，所以可用性相當(dāng)于被隔離在了兩個(gè)部分去考慮。我們只需要考慮C端如何解決寫的可用性，Q端如何解決讀的可用性即可。C端解決可用性，我覺(jué)得是更加容易的，因?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)說(shuō)，CQRS架構(gòu)在數(shù)據(jù)修改上可用性要更高。不過(guò)你可能會(huì)說(shuō)，要是分布式消息隊(duì)列掛了呢？呵呵，對(duì)，這確實(shí)也是有可能的。但是一般分布式消息隊(duì)列屬于中間件，一般中間件都具有很高的可用性（支持集群和主備切換），所以相比我們的應(yīng)用來(lái)說(shuō)，可用性要高很多。另外，因?yàn)槊钍窍劝l(fā)送到分布式消息隊(duì)列，這樣就能充分利用分布式消息隊(duì)列的優(yōu)勢(shì)：異步化、拉模式、削峰填谷、基于隊(duì)列的水平擴(kuò)展。這些特性可以保證即便前端Controller在高峰時(shí)瞬間發(fā)送大量的Command過(guò)來(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)該說(shuō)和傳統(tǒng)架構(gòu)沒(méi)什么區(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)景，我覺(jué)得應(yīng)該是，如果你的應(yīng)用要實(shí)現(xiàn)全文索引這種復(fù)雜查詢，那可以在Q端使用搜索引擎，比如ElasticSearch；如果你的查詢場(chǎng)景可以通過(guò)keyvalue這種數(shù)據(jù)結(jié)構(gòu)滿足，那我們可以在Q端使用Redis這種NoSql分布式緩存。總之，我認(rèn)為CQRS架構(gòu)，我們解決查詢問(wèn)題會(huì)比傳統(tǒng)架構(gòu)更加容易，因?yàn)槲覀冞x擇更多了。但是你可能會(huì)說(shuō)，我的場(chǎng)景只能用關(guān)系型數(shù)據(jù)庫(kù)解決，且查詢的并發(fā)也是非常高。那沒(méi)辦法了，唯一的辦法就是分散查詢IO，我們對(duì)數(shù)據(jù)庫(kù)做分庫(kù)分表，以及對(duì)數(shù)據(jù)庫(kù)做一主多備，查詢走備機(jī)。這點(diǎn)上，解決思路就是和傳統(tǒng)架構(gòu)一樣了。
性能、伸縮性
本來(lái)想把性能和伸縮性分開(kāi)寫的，但是想想這兩個(gè)其實(shí)有一定的關(guān)聯(lián)，所以決定放在一起寫。
伸縮性的意思是，當(dāng)一個(gè)系統(tǒng)，在100人訪問(wèn)時(shí)，性能（吞吐量、響應(yīng)時(shí)間）很不錯(cuò)，在100W人訪問(wèn)時(shí)性能也同樣不錯(cuò)，這就是伸縮性。100人訪問(wèn)和100W人訪問(wèn)，對(duì)系統(tǒng)的壓力顯然是不同的。如果我們的系統(tǒng)，在架構(gòu)上，能夠做到通過(guò)簡(jiǎn)單的增加機(jī)器，就能提高系統(tǒng)的服務(wù)能力，那我們就可以說(shuō)這種架構(gòu)的伸縮性很強(qiáng)。那我們來(lái)想想傳統(tǒng)架構(gòu)和CQRS架構(gòu)在性能和伸縮性上面的表現(xiàn)。
說(shuō)到性能，大家一般會(huì)先思考一個(gè)系統(tǒng)的性能瓶頸在哪里。只要我們解決了性能瓶頸，那系統(tǒng)就意味著具有通過(guò)水平擴(kuò)展來(lái)達(dá)到可伸縮的目的了（當(dāng)然這里沒(méi)有考慮數(shù)據(jù)存儲(chǔ)的水平擴(kuò)展）。所以，我們只要分析一下傳統(tǒng)架構(gòu)和CQRS架構(gòu)的瓶頸點(diǎn)在哪里即可。
傳統(tǒng)架構(gòu)，瓶頸通常在底層數(shù)據(jù)庫(kù)。然后我們一般的做法是，對(duì)于讀：通常使用緩存就可以解決大部分查詢問(wèn)題；對(duì)于寫：辦法也有很多，比如分庫(kù)分表，或者使用NoSQL，等等。比如阿里大量采用分庫(kù)分表的方案，而且未來(lái)應(yīng)該會(huì)全部使用高大上的OceanBase來(lái)替代分庫(kù)分表的方案。通過(guò)分庫(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)該說(shuō)數(shù)據(jù)存儲(chǔ)對(duì)傳統(tǒng)架構(gòu)來(lái)說(shuō)，也早已不再是瓶頸了。
傳統(tǒng)架構(gòu)一次數(shù)據(jù)修改的步驟是：1）從DB取出數(shù)據(jù)到內(nèi)存；2）內(nèi)存修改數(shù)據(jù)；3）更新數(shù)據(jù)回DB。總共涉及到2次數(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ù)。為什么說(shuō)最多？因?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ù)。
所以，我們說(shuō)，你要用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。我覺(jué)得這里有一點(diǎn)很重要，對(duì)于CQRS架構(gòu)，我們更加關(guān)注C端處理完成所用的時(shí)間；而Q端的處理稍微慢一點(diǎn)沒(méi)關(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è)聚合根，則通過(guò)Saga來(lái)實(shí)現(xiàn)。從而繞過(guò)了復(fù)雜事務(wù)的問(wèn)題，通過(guò)最終一致性的思路做到了最大的并行和最少的并發(fā)，從而整體上提高系統(tǒng)的吞吐能力。
所以，總體來(lái)說(shuō)，性能瓶頸方面，兩種架構(gòu)都能克服。而只要克服了性能瓶頸，那伸縮性就不是問(wèn)題了（當(dāng)然，這里我沒(méi)有考慮數(shù)據(jù)丟失而帶來(lái)的系統(tǒng)不可用的問(wèn)題。這個(gè)問(wèn)題是所有架構(gòu)都無(wú)法回避的問(wèn)題，唯一的解決辦法就是數(shù)據(jù)冗余，這里不做展開(kāi)了）。兩者的瓶頸都在數(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)單，就是命令和事件；如果你信的過(guò)一些成熟的NoSQL（我覺(jué)得使用文檔性數(shù)據(jù)庫(kù)如MongoDB這種比較適合存儲(chǔ)命令和事件），且你也有足夠的能力和經(jīng)驗(yàn)去運(yùn)維它們，那可以考慮使用NoSQL來(lái)持久化。如果你覺(jué)得NoSQL靠不住或者沒(méi)辦法完全掌控，那可以使用關(guān)系型數(shù)據(jù)庫(kù)。但這樣你也要付出努力，比如需要自己負(fù)責(zé)分庫(kù)分表來(lái)保存命令和事件，因?yàn)槊詈褪录臄?shù)據(jù)量都是很大的。不過(guò)目前一些云服務(wù)如阿里云，已經(jīng)提供了DRDS這種直接支持分庫(kù)分表的數(shù)據(jù)庫(kù)存儲(chǔ)方案，極大的簡(jiǎn)化了我們存儲(chǔ)命令和事件的成本。就我個(gè)人而言，我覺(jué)得我還是會(huì)采用分庫(kù)分表的方案，原因很簡(jiǎn)單：確保數(shù)據(jù)可靠落地、成熟、可控，而且支持這種只讀數(shù)據(jù)的落地，框架內(nèi)置要支持分庫(kù)分表也不是什么難事。所以，通過(guò)這個(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ù)，而沒(méi)有修改或刪除數(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ǔ)
我覺(jué)得不論是傳統(tǒng)架構(gòu)還是CQRS架構(gòu)，都是不錯(cuò)的架構(gòu)。傳統(tǒng)架構(gòu)門檻低，懂的人也多，且因?yàn)榇蟛糠猪?xiàng)目都沒(méi)有什么大的并發(fā)寫入量和數(shù)據(jù)量。所以應(yīng)該說(shuō)大部分項(xiàng)目，采用傳統(tǒng)架構(gòu)就OK了。但是通過(guò)本文的分析，大家也知道了，傳統(tǒng)架構(gòu)確實(shí)也有一些缺點(diǎn)，比如在擴(kuò)展性、可用性、性能瓶頸的解決方案上，都比CQRS架構(gòu)要弱一點(diǎn)。大家有其他意見(jiàn)，歡迎拍磚，交流才能進(jìn)步，呵呵。所以，如果你的應(yīng)用場(chǎng)景是高并發(fā)寫、高并發(fā)讀、大數(shù)據(jù)，且希望在擴(kuò)展性、可用性、性能、可伸縮性上表現(xiàn)更優(yōu)秀，我覺(jué)得可以嘗試CQRS架構(gòu)。但是還有一個(gè)問(wèn)題，CQRS架構(gòu)的門檻很高，我認(rèn)為如果沒(méi)有成熟的框架支持，很難使用。而目前據(jù)我了解，業(yè)界還沒(méi)有很多成熟的CQRS框架，java平臺(tái)有axon framework, jdon framework；.NET平臺(tái)，ENode框架正在朝這個(gè)方向努力。所以，我想這也是為什么目前幾乎沒(méi)有使用CQRS架構(gòu)的成熟案例的原因之一。另一個(gè)原因是使用CQRS架構(gòu)，需要開(kāi)發(fā)者對(duì)DDD有一定的了解，否則也很難實(shí)踐，而DDD本身要理解沒(méi)個(gè)幾年也很難運(yùn)用到實(shí)際。還有一個(gè)原因，CQRS架構(gòu)的核心是非常依賴于高性能的分布式消息中間件，所以要選型一個(gè)高性能的分布式消息中間件也是一個(gè)門檻（java平臺(tái)有RocketMQ），.NET平臺(tái)我個(gè)人專門開(kāi)發(fā)了一個(gè)分布式消息隊(duì)列EQueue，呵呵。另外，如果沒(méi)有成熟的CQRS框架的支持，那編碼復(fù)雜度也會(huì)很復(fù)雜，比如Event Sourcing，消息重試，消息冪等處理，事件的順序處理，并發(fā)控制，這些問(wèn)題都不是那么容易搞定的。而如果有框架支持，由框架來(lái)幫我們搞定這些純技術(shù)問(wèn)題，開(kāi)發(fā)人員只需要關(guān)注如何建模，實(shí)現(xiàn)領(lǐng)域模型，如何更新讀庫(kù)，如何實(shí)現(xiàn)查詢，那使用CQRS架構(gòu)才有可能，因?yàn)檫@樣才可能比傳統(tǒng)的架構(gòu)開(kāi)發(fā)更簡(jiǎn)單，且能獲得很多CQRS架構(gòu)所帶來(lái)的好處。