引言
這是一篇講解微服務(wù)系統(tǒng)在擴(kuò)展性伸縮性方面的演進(jìn)文章，Jonas Boner認(rèn)為目前普通的微服務(wù)最終將演進(jìn)為事件驅(qū)動(dòng)的響應(yīng)式微系統(tǒng)架構(gòu)。
今天系統(tǒng)架構(gòu)大概有三種:單體Monolith、微單體Micoliths和微服務(wù)Microsystems，所謂微單體就是介于單體和微服務(wù)之間的一種，有很多服務(wù)，數(shù)據(jù)庫(kù)也進(jìn)行了分庫(kù)分表，不像單體那樣只有一個(gè)大的WAR應(yīng)用和一個(gè)數(shù)據(jù)庫(kù)，但是又不像微服務(wù)那樣，每個(gè)服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫(kù)，互不干涉。
大部分微單體系統(tǒng)是切分了單體系統(tǒng)而形成的，每個(gè)Microlith由一個(gè)臺(tái)服務(wù)器運(yùn)行，有自己的REST/Servlet，有自己的服務(wù)和JPA數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)訪問(wèn)是一種同步堵塞式的數(shù)據(jù)庫(kù)線程連接池方式訪問(wèn)，微單之間式通過(guò)同步的堵塞的RPC訪問(wèn)(比如Dubbo和gRPC)，這樣的系統(tǒng)沒(méi)有彈性，不具有伸縮。
Carl Hewitt說(shuō): 一個(gè)Actor模型不是真正的Actor，一個(gè)系統(tǒng)中應(yīng)該有多個(gè)Actors。
邁向可擴(kuò)展的微服務(wù)系統(tǒng)是引入Actor模型，有三種有用的方式：
1. 事件第一的DDD Events-first DDD
2. 響應(yīng)式設(shè)計(jì) Reactive Design
3. 基于事件的持久 Event-Based Persistence
實(shí)踐的事件第一的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)
這種方式有別于傳統(tǒng)的DDD，傳統(tǒng)DDD最后可能形成一個(gè)臃腫的肥胖的聚合根，大家都把東西塞在里面，這種方式的問(wèn)題在于我們過(guò)于關(guān)注聚焦名詞：領(lǐng)域?qū)ο螅拖裎覀冞^(guò)于關(guān)注數(shù)據(jù)表一樣。
相反，我們應(yīng)該首先聚焦關(guān)注發(fā)生了什么事情，也就是動(dòng)詞，是事件。
Greg Young說(shuō)：當(dāng)你開(kāi)始對(duì)事件建模時(shí)，將會(huì)強(qiáng)迫你思考系統(tǒng)的行為，而不是思考系統(tǒng)的結(jié)構(gòu)。
具體怎么做呢？在傳統(tǒng)DDD中，分析建模第一步是找出情景場(chǎng)景，也就是有界的上下文，但是如何定義有界的上下文卻很難定義，有可能來(lái)自于用例需求的分解等等，但是這些邊界劃分不一定是面向領(lǐng)域的，可能是面向功能的，所以，事件建模就是通過(guò)事件來(lái)定義有界上下文。
比如訂單發(fā)生的地方是一個(gè)上下文，而進(jìn)出庫(kù)事件發(fā)生的地方又是一個(gè)上下文。這些上下文都是因?yàn)榘l(fā)生不同事件而自然形成邊界。
事件重要特征是它代表發(fā)生的事實(shí)，這在很多跟蹤系統(tǒng)中有非常重要的應(yīng)用，比如貨物跟蹤，財(cái)務(wù)和人事跟蹤記賬系統(tǒng)等等。
尋找發(fā)生的事實(shí)，如同大偵探波羅探案一樣，他在東方快車謀殺案中自詡和上帝一樣能看清真相，當(dāng)然這也可能來(lái)自于他的強(qiáng)迫癥，當(dāng)他發(fā)現(xiàn)犯罪事實(shí)竟然是來(lái)自每個(gè)人的人性之惡時(shí)，他再也不敢自詡上帝了。
我們使用DDD分析的系統(tǒng)真相，當(dāng)然不會(huì)涉及到道德和人性幽暗，所以，在這樣的邏輯系統(tǒng)我們是可以
扮演上帝的，那么如何發(fā)現(xiàn)需求中的事實(shí)真相呢？通過(guò)事件風(fēng)暴，Event Storming。
事實(shí)是遵循因果一致性的，理解事實(shí)是如何進(jìn)行因果相關(guān)，Peter Alvaro說(shuō):因果性通往時(shí)空的途徑。哲學(xué)大師康德認(rèn)為時(shí)空是我們觀察世界的方式，而時(shí)空蘊(yùn)含的因果性正是我們科學(xué)追尋發(fā)現(xiàn)的目標(biāo)。
因果關(guān)系代表了一種因果一致性，有因必有果，這是一致的，不會(huì)前后矛盾，是前后順序的，如同老子說(shuō)：道生一，一生二，二生三，三生萬(wàn)物，這也是表達(dá)了一種因果一致性。因果一致性對(duì)立面就是矛盾，如果發(fā)現(xiàn)矛盾，實(shí)際就是否定了因果一致性，有時(shí)我們會(huì)從矛盾方面去證偽因果一致性。因果一致性是形式邏輯的重要特征。
既然存在因果一致性，就會(huì)存在一致性自然形成的邊界，比如從第一因一直到最后一個(gè)果，這就自然形成了一條因果鏈，這條因果鏈自然也就形成自己的邊界，如果兩條因果鏈放在一起，我們能夠區(qū)分它們也是因?yàn)檫吔绮煌５窃诜鸾袒颥F(xiàn)代藝術(shù)中，經(jīng)常把最后一個(gè)果和第一個(gè)因再鏈接起來(lái)，形成了因果循環(huán)，也就是輪回，這實(shí)際破壞了一致性，是非時(shí)空理性思維方式。
在軟件需求中，我們?nèi)绾伟l(fā)現(xiàn)因果鏈形成的邊界？一般這樣邊界中需要包含可變狀態(tài)和已經(jīng)發(fā)生的事實(shí)，這些事實(shí)其實(shí)是造成狀態(tài)可變的原因，只不過(guò)表現(xiàn)形式不同而已。
所以，DDD中的尋找聚合，實(shí)際就是尋找因果一致性單元，也是尋找會(huì)發(fā)生failure的單元。
響應(yīng)式設(shè)計(jì)
響應(yīng)式設(shè)計(jì)分為兩個(gè)階段：初期的響應(yīng)式編程和分布式的響應(yīng)式系統(tǒng)。
響應(yīng)式編程能夠幫助我們讓獨(dú)立的實(shí)例系統(tǒng)(一個(gè)VM 一個(gè)JVM或一臺(tái)服務(wù)器)內(nèi)部運(yùn)行更高效。通向響應(yīng)式第一步是引入異步，也就是引入非堵塞，能夠更有效地利用資源，防止數(shù)據(jù)庫(kù)連接池的暴障拖垮數(shù)據(jù)庫(kù)，或一個(gè)很輕的小動(dòng)作就能讓巍峨的Oracle當(dāng)機(jī)趴下，這些都是同步堵塞造成的罪行。
異步和非堵塞能夠降低共享資源比如數(shù)據(jù)庫(kù)表等的競(jìng)爭(zhēng)，避免大量使用事務(wù)機(jī)制造成的死鎖和數(shù)據(jù)庫(kù)連接池耗盡。
使用異步和非堵塞，會(huì)降低快速訪問(wèn)沖擊緩慢的后端系統(tǒng)，比如大量的并行峰值訪問(wèn)會(huì)立即打趴巍峨的ORacle數(shù)據(jù)庫(kù)。在一個(gè)大型系統(tǒng)在，存在各種不同處理效率的子系統(tǒng)，如何在快與慢之間協(xié)調(diào)，異步系統(tǒng)往往扮演重要的協(xié)調(diào)身份。
引入了響應(yīng)式編程可以幫助處理好一臺(tái)機(jī)器內(nèi)多線程問(wèn)題，而響應(yīng)式系統(tǒng)則是帶給我們多臺(tái)機(jī)器之間的分布式協(xié)調(diào)高效處理，實(shí)現(xiàn)彈性和伸縮性。
響應(yīng)式系統(tǒng)是基于異步消息傳遞，能夠在空間和時(shí)間兩個(gè)維度上解耦。能夠?qū)崿F(xiàn)從CPU核到Socket 到容器到服務(wù)器到數(shù)據(jù)中心的透明化處理方式。
真正微服務(wù)系統(tǒng)應(yīng)該是響應(yīng)式編程+響應(yīng)式系統(tǒng)，每個(gè)微服務(wù)都需要被設(shè)計(jì)為一個(gè)分布式的微系統(tǒng)，
首先，將無(wú)狀態(tài)行為從有狀態(tài)的實(shí)體中分離出來(lái)，形成命令或事件，事件代表行為，實(shí)體代表結(jié)構(gòu)，這樣行為和結(jié)構(gòu)才能分別各自擴(kuò)展伸縮。因?yàn)閿U(kuò)展無(wú)狀態(tài)行為比擴(kuò)展有狀態(tài)的實(shí)體要容易得多。
基于事件的持久化
JIM Gray說(shuō)：覆蓋式更新(update-in-place)是設(shè)計(jì)師是原罪，它違反了傳統(tǒng)幾百年來(lái)的會(huì)計(jì)記賬實(shí)踐。
Pat Helland說(shuō)：真相是日志Log，數(shù)據(jù)庫(kù)只是日志子集的緩存。
對(duì)于建立一種可伸縮的持久存儲(chǔ)系統(tǒng)來(lái)說(shuō)，事件日志才是正道。
CRUD增刪改查已經(jīng)死了，只能留下增讀兩個(gè)操作CR，更新和刪除UD應(yīng)該放入墳?zāi)埂?/p>
事件溯源Event Sourcing是一種CR，通過(guò)事件建模，能夠讓你注重系統(tǒng)中的來(lái)龍去脈，時(shí)間成為系統(tǒng)關(guān)鍵因素。
通過(guò)事件日志記錄事件按時(shí)間發(fā)生的順序，一旦發(fā)生事件就不斷新增追加到事件日志，其他使用者只要根據(jù)時(shí)間順序不斷讀取這些事件，再執(zhí)行這些事件代表的動(dòng)作，事件代表因，事件執(zhí)行后自然會(huì)產(chǎn)生結(jié)果。
同時(shí)，事件日志避免了面向?qū)ο蠛完P(guān)系數(shù)據(jù)庫(kù)的不匹配阻抗問(wèn)題。讓對(duì)象歸對(duì)象，讓數(shù)據(jù)庫(kù)歸數(shù)據(jù)庫(kù)，
對(duì)象用于命令執(zhí)行寫操作，而數(shù)據(jù)庫(kù)用于查詢讀操作，通過(guò)CQRS分離讀寫操作。使用事件日志同步讀寫兩個(gè)系統(tǒng)的數(shù)據(jù)。
如何協(xié)調(diào)不同聚合之間的交互呢？通過(guò)事件驅(qū)動(dòng)的工作流，比如有三個(gè)聚合：訂單、支付和庫(kù)存，下訂單時(shí)，需要支付系統(tǒng)支付鈔票，然后從庫(kù)存出貨， 其中交互流程是這樣：
1. 開(kāi)始訂單處理
2. 訂單系統(tǒng)發(fā)出保留訂購(gòu)商品的命令給庫(kù)存系統(tǒng)
3. 庫(kù)存系統(tǒng)接受命令后，檢查是否有庫(kù)存，如果有執(zhí)行保留該商品命令，發(fā)出商品被保留的事件
4. 訂單系統(tǒng)因?yàn)槭孪扔嗛喠松唐繁槐Ａ舻氖录驗(yàn)橥ㄟ^(guò)Kafka等事件流總線會(huì)接受到商品被保留的事件，
5. 訂單系統(tǒng)然后向支付系統(tǒng)發(fā)出扣款支付的命令
6. 支付系統(tǒng)接受到扣款命令后，如果能夠扣款，執(zhí)行扣款，發(fā)出已經(jīng)支付的事件。
7. 訂單系統(tǒng)因?yàn)橐彩孪扔嗛喠酥Ц断到y(tǒng)的事件，將接受到已經(jīng)支付的事件。
8. 訂單系統(tǒng)向庫(kù)存系統(tǒng)發(fā)出發(fā)貨命令。
9. 庫(kù)存系統(tǒng)接受發(fā)貨命令，將之前預(yù)先保留的商品進(jìn)行真正出庫(kù)，發(fā)出商品裝運(yùn)事件。
10. 訂單系統(tǒng)因?yàn)橐彩孪扔嗛喠藥?kù)存系統(tǒng)的事件，將接受到商品已經(jīng)出庫(kù)裝貨的事件。
11. 訂單系統(tǒng)確認(rèn)整個(gè)訂單完成。
分布式事務(wù)怎么處理？
Pat Helland說(shuō)，兩段提交的分布式事務(wù)其實(shí)是一種反高可用性的協(xié)議。
使用最終一致性的事務(wù)協(xié)議是一種猜測(cè)、抱歉試錯(cuò)和補(bǔ)償?shù)膮f(xié)議。比如Saga模式，Saga協(xié)調(diào)器能夠知道長(zhǎng)事務(wù)運(yùn)行中所有事務(wù)步驟，如果任何一個(gè)步驟，比如上面庫(kù)存系統(tǒng)出錯(cuò)，Saga協(xié)調(diào)器將會(huì)采取補(bǔ)償回退之前所有步驟。
總結(jié)：不要建立微單系統(tǒng)，微服務(wù)其實(shí)是分布式微系統(tǒng)，積極擁抱響應(yīng)式設(shè)計(jì)原則，擁抱事件第一的DDD和事件持久化方案。
