2.7 為何當(dāng)系統(tǒng)遇到性能瓶頸時(shí)，經(jīng)常無能為力？
性能瓶頸原因分析
我們?cè)诓豢紤]硬件瓶頸的情況，只從軟件角度來分析，系統(tǒng)的瓶頸產(chǎn)生的過程如下：
軟件系統(tǒng)上線以后隨著數(shù)據(jù)的不斷積累和需求的不斷變化，將面臨兩個(gè)不同維度的主要問題：
隨著時(shí)間積累，用戶量的上升與數(shù)據(jù)量的積累
隨著系統(tǒng)的使用反饋，帶來的需求變更與升級(jí)
對(duì)應(yīng)的解決方案：
數(shù)據(jù)量與請(qǐng)求量的上升，我們可以采用的解決方案就是負(fù)載均衡。
例如通過容器化技術(shù)實(shí)現(xiàn)負(fù)載均衡。
面對(duì)需求的調(diào)整與反饋，那我們只能提供不斷的調(diào)整系統(tǒng)來應(yīng)對(duì)。
基于上述的兩種解決方案，最終系統(tǒng)的瓶頸，將主要產(chǎn)生在如下的兩個(gè)地方：
由于設(shè)計(jì)缺陷，導(dǎo)致業(yè)務(wù)不可控
底層大量有狀態(tài)的服務(wù)依賴，導(dǎo)致無法無限的負(fù)載均衡。
性能瓶頸的解決方案
其實(shí)這兩個(gè)這兩個(gè)問題本質(zhì)上也是一個(gè)問題，上帝的歸上帝，凱撒的歸凱撒。
系統(tǒng)業(yè)務(wù)設(shè)計(jì)應(yīng)該由業(yè)務(wù)模型來解決，有狀態(tài)的服務(wù)的依賴，要做到可拆分。
? ? 在Command中業(yè)務(wù)的交互，這個(gè)過程中將需要通過業(yè)務(wù)模型的交互完成業(yè)務(wù)邏輯的處理，同時(shí)要將模型數(shù)據(jù)與查詢數(shù)據(jù)存儲(chǔ)起來。通過事件機(jī)制實(shí)現(xiàn)對(duì)數(shù)據(jù)的廣播，然后由各Query模塊訂閱并同步其數(shù)據(jù)，利用事件的廣播機(jī)制同步數(shù)據(jù)，實(shí)現(xiàn)對(duì)有狀態(tài)的數(shù)據(jù)分散。
? ? 在這個(gè)過程中其實(shí)，domain-storage 、EventBus 、 QueryStorage 這些概念都不重要，因?yàn)檫@些都是技術(shù)，具體方案時(shí)取決于你的選型，而CQRS也非常容易落地，其實(shí)最復(fù)雜的是DomainModel的建立過程，也就是業(yè)務(wù)模型的建立過程，而業(yè)務(wù)模型的建立也是解決第一個(gè)問題的根本，所以說上述的兩個(gè)瓶頸其實(shí)都可以歸結(jié)到一個(gè)問題上。
如下代碼演示domain生命周期的監(jiān)控與事件發(fā)布
Demo模型代碼：
模型交互代碼：
打印日志如下:
上述代碼來源codingapi的開源框架 https://github.com/codingapi/springboot-framework
本框架基于springboot為提供領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)與事件風(fēng)暴開發(fā)落地，提供的范式開源框架。
