引言：微服務(wù)現(xiàn)在辣么火略步，業(yè)界流行的對(duì)比的卻都是所謂的Monolithic單體應(yīng)用描扯，而大量的系統(tǒng)在十幾年前都是已經(jīng)是分布式系統(tǒng)了，那么微服務(wù)作為新的理念和原來(lái)的分布式系統(tǒng)趟薄，或者說(shuō)SOA（面向服務(wù)架構(gòu)）是什么區(qū)別呢绽诚？

論微服務(wù)架構(gòu)的核心概念

微服務(wù)架構(gòu)和SOA區(qū)別

我們先看相同點(diǎn)

1. 需要Registry，實(shí)現(xiàn)動(dòng)態(tài)的服務(wù)注冊(cè)發(fā)現(xiàn)機(jī)制杭煎；

2. 需要考慮分布式下面的事務(wù)一致性恩够，CAP原則下，兩段式提交不能保證性能蜂桶，事務(wù)補(bǔ)償機(jī)制需要考慮；

3. 同步調(diào)用還是異步消息傳遞也切，如何保證消息可靠性旬痹？SOA由ESB來(lái)集成所有的消息漫雕；

4. 都需要統(tǒng)一的Gateway來(lái)匯聚吩翻、編排接口弧轧，實(shí)現(xiàn)統(tǒng)一認(rèn)證機(jī)制捺典，對(duì)外提供APP使用的RESTful接口；

5. 同樣的要關(guān)注如何再分布式下定位系統(tǒng)問(wèn)題你虹，如何做日志跟蹤卒暂，就像我們電信領(lǐng)域做了十幾年的信令跟蹤的功能；

那么差別在哪榨咐？

是持續(xù)集成介却、持續(xù)部署？對(duì)于CI块茁、CD（持續(xù)集成齿坷、持續(xù)部署），這本身和敏捷数焊、DevOps是交織在一起的永淌，我認(rèn)為這更傾向于軟件工程的領(lǐng)域而不是微服務(wù)技術(shù)本身；

使用不同的通訊協(xié)議是不是區(qū)別佩耳？微服務(wù)的標(biāo)桿通訊協(xié)議是RESTful遂蛀，而傳統(tǒng)的SOA一般是SOAP，不過(guò)目前來(lái)說(shuō)采用輕量級(jí)的RPC框架Dubbo干厚、Thrift李滴、gRPC非常多，在Spring Cloud中也有Feign框架將標(biāo)準(zhǔn)RESTful轉(zhuǎn)為代碼的API這種仿RPC的行為蛮瞄，這些通訊協(xié)議不應(yīng)該是區(qū)分微服務(wù)架構(gòu)和SOA的核心差別所坯；

是流行的基于容器框架還是虛擬機(jī)為主？Docker和虛擬機(jī)還是物理機(jī)都是架構(gòu)實(shí)現(xiàn)的一種方式挂捅，不是核心區(qū)別芹助；

微服務(wù)架構(gòu)的精髓在切分

服務(wù)的切分上有比較大的區(qū)別，SOA原本是以一種“集成”技術(shù)出現(xiàn)的闲先，很多技術(shù)方案是將原有企業(yè)內(nèi)部服務(wù)封裝為一個(gè)獨(dú)立進(jìn)程状土，這樣新的業(yè)務(wù)開發(fā)就可重用這些服務(wù)，這些服務(wù)很可能是類似供應(yīng)鏈伺糠、CRM這樣的非常大的顆粒蒙谓；而微服務(wù)這個(gè)“微”，就說(shuō)明了他在切分上有講究退盯，不妥協(xié)彼乌。無(wú)數(shù)的案例證明泻肯，如果你的切分是錯(cuò)誤的，那么你得不到微服務(wù)承諾的“低耦合慰照、升級(jí)不影響灶挟、可靠性高”之類的優(yōu)勢(shì)，而會(huì)比使用Monolithic有更多的麻煩毒租。

不拆分存儲(chǔ)的微服務(wù)是偽服務(wù)：

在實(shí)踐中稚铣，我們常常見(jiàn)到一種架構(gòu)，后端存儲(chǔ)是全部和在一個(gè)數(shù)據(jù)庫(kù)中墅垮，僅僅把前端的業(yè)務(wù)邏輯拆分到不同的服務(wù)進(jìn)程中惕医，本質(zhì)上和一個(gè)Monolithic一樣，只是把模塊之間的進(jìn)程內(nèi)調(diào)用改為進(jìn)程間調(diào)用算色，這種切分不可取抬伺，違反了分布式第一原則，模塊耦合沒(méi)有解決灾梦，性能卻受到了影響峡钓。

分布式設(shè)計(jì)第一原則 — “不要分布你的對(duì)象”

微服務(wù)的“Micro”這個(gè)詞并不是越小越好，而是相對(duì)SOA那種粗粒度的服務(wù)若河，我們需要更小更合適的粒度能岩，這種Micro不是無(wú)限制的小。

如果我們將兩路（同步）通信與小/微服務(wù)結(jié)合使用萧福，并根據(jù)比如“1個(gè)類=1個(gè)服務(wù)”的原則拉鹃，那么我們實(shí)際上回到了使用Corba、J2EE和分布式對(duì)象的20世紀(jì)90年代鲫忍。遺憾的是膏燕，新生代的開發(fā)人員沒(méi)有使用分布式對(duì)象的經(jīng)驗(yàn)，因此也就沒(méi)有認(rèn)識(shí)到這個(gè)主意多么糟糕悟民，他們正試圖重復(fù)歷史煌寇，只是這次使用了新技術(shù)，比如用HTTP取代了RMI或IIOP逾雄。

微服務(wù)和Domain Driven Design

一個(gè)簡(jiǎn)單的圖書管理系統(tǒng)肯定無(wú)需微服務(wù)架構(gòu)项玛。既然采用了微服務(wù)架構(gòu)斤彼，那么面對(duì)的問(wèn)題空間必然是比較宏大，比如整個(gè)電商肉瓦、CRM永品。

如何拆解服務(wù)呢做鹰？

使用什么樣的方法拆解服務(wù)？業(yè)界流行1個(gè)類=1個(gè)服務(wù)鼎姐、1個(gè)方法=1個(gè)服務(wù)钾麸、2 Pizza團(tuán)隊(duì)更振、2周能重寫完成等方法，但是這些都缺乏實(shí)施基礎(chǔ)饭尝。我們必須從一些軟件設(shè)計(jì)方法中尋找肯腕，面向?qū)ο蠛驮O(shè)計(jì)模式適用的問(wèn)題空間是一個(gè)模塊，而函數(shù)式編程的理念更多的是在代碼層面的微觀上起作用钥平。

Eric Evans 的《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》這本書對(duì)微服務(wù)架構(gòu)有很大借鑒意義实撒，這本書提出了一個(gè)能將一個(gè)大問(wèn)題空間拆解分為領(lǐng)域和實(shí)體之間的關(guān)系和行為的技術(shù)。目前來(lái)說(shuō)涉瘾，這是一個(gè)最合理的解決拆分問(wèn)題的方案知态，透過(guò)限界上下文（Bounded Context，下文簡(jiǎn)稱為BC）這個(gè)概念立叛，我們能將實(shí)現(xiàn)細(xì)節(jié)封裝起來(lái)负敏，讓BC都能夠?qū)崿F(xiàn)SRP（單一職責(zé)）原則。而每個(gè)微服務(wù)正是BC在實(shí)際世界的物理映射秘蛇，符合BC思路的微服務(wù)互相獨(dú)立松耦合其做。

微服務(wù)架構(gòu)是一件好事，逼著大家關(guān)注設(shè)計(jì)軟件的合理性彤叉，如果原來(lái)在Monolithic中領(lǐng)域分析庶柿、面向?qū)ο笤O(shè)計(jì)做不好，換微服務(wù)會(huì)把這個(gè)問(wèn)題成倍的放大秽浇。

以電商中的訂單和商品兩個(gè)領(lǐng)域舉例浮庐，按照DDD拆解，他們應(yīng)該是兩個(gè)獨(dú)立的限界上下文柬焕，但是訂單中肯定是包含商品的审残，如果貿(mào)然拆為兩個(gè)BC，查詢斑举、調(diào)用關(guān)系就耦合在一起了搅轿，甚至有了麻煩的分布式事務(wù)的問(wèn)題，這個(gè)關(guān)聯(lián)如何拆解富玷？BC理論認(rèn)為在不同的BC中璧坟，即使是一個(gè)術(shù)語(yǔ)，他的關(guān)注點(diǎn)也不一樣赎懦，在商品BC中雀鹃，關(guān)注的是屬性、規(guī)格励两、詳情等等（實(shí)際上商品BC這個(gè)領(lǐng)域有價(jià)格黎茎、庫(kù)存、促銷等等当悔，把他作為單獨(dú)一個(gè)BC也是不合理的傅瞻，這里為了簡(jiǎn)化例子踢代，大家先認(rèn)為商品BC就是商品基礎(chǔ)信息）， 而在訂單BC中更關(guān)注商品的庫(kù)存嗅骄、價(jià)格胳挎。所以在實(shí)際編碼設(shè)計(jì)中，訂單服務(wù)往往將關(guān)注的商品名稱掸读、價(jià)格等等屬性冗余在訂單中串远，這個(gè)設(shè)計(jì)解脫了和商品BC的強(qiáng)關(guān)聯(lián)，兩個(gè)BC可以獨(dú)立提供服務(wù)儿惫，獨(dú)立數(shù)據(jù)存儲(chǔ)

小結(jié)

微服務(wù)架構(gòu)首先要關(guān)注的不是RPC/ServiceDiscovery/Circuit Breaker這些概念澡罚，也不是Eureka/Docker/SpringCloud/Zipkin這些技術(shù)框架，而是服務(wù)的邊界肾请、職責(zé)劃分留搔，劃分錯(cuò)誤就會(huì)陷入大量的服務(wù)間的相互調(diào)用和分布式事務(wù)中，這種情況微服務(wù)帶來(lái)的不是便利而是麻煩铛铁。

DDD給我們帶來(lái)了合理的劃分手段隔显，但是DDD的概念眾多，晦澀難以理解饵逐，如何抓住重點(diǎn)括眠，合理的運(yùn)用到微服務(wù)架構(gòu)中呢？

我認(rèn)為如下的幾個(gè)架構(gòu)思想是重中之重：

1. 充血模型

2. 事件驅(qū)動(dòng)

微服務(wù)和充血模型

上文我們聊了微服務(wù)的DDD之間的關(guān)系倍权，很多人還是覺(jué)得很虛幻掷豺，DDD那么復(fù)雜的理論，聚合根薄声、值對(duì)象当船、事件溯源，到底我們?cè)撛趺慈胧帜兀?/p>

實(shí)際上DDD和面向?qū)ο笤O(shè)計(jì)默辨、設(shè)計(jì)模式等等理論有千絲萬(wàn)縷的聯(lián)系德频，如果不熟悉OOA、OOD缩幸，DDD也是使用不好的壹置。不過(guò)學(xué)習(xí)這些OO理論的時(shí)候，大家往往感覺(jué)到無(wú)用武之地表谊，因?yàn)榇蟛糠值腏ava程序員開發(fā)生涯是從學(xué)習(xí)J2EE經(jīng)典的分層理論開始的（Action蒸绩、Service、Dao）铃肯，在這種分層理論中，我們基本沒(méi)有啥機(jī)會(huì)使用那些所謂的“行為型”的設(shè)計(jì)模式传蹈，這里的核心原因押逼，就是J2EE經(jīng)典分層的開發(fā)方式是“貧血模型”步藕。

Martin Fowler在他的《企業(yè)應(yīng)用架構(gòu)模式》這本書中提出了兩種開發(fā)方式“事務(wù)腳本”和“領(lǐng)域模型”，這兩種開發(fā)分別對(duì)應(yīng)了“貧血模型”和“充血模型”挑格。

事務(wù)腳本開發(fā)模式

事務(wù)腳本的核心是過(guò)程咙冗，可以認(rèn)為大部分的業(yè)務(wù)處理都是一條條的SQL，事務(wù)腳本把單個(gè)SQL組織成為一段業(yè)務(wù)邏輯漂彤，在邏輯執(zhí)行的時(shí)候雾消，使用事務(wù)來(lái)保證邏輯的ACID。最典型的就是存儲(chǔ)過(guò)程挫望。當(dāng)然我們?cè)谄綍r(shí)J2EE經(jīng)典分層架構(gòu)中立润，經(jīng)常在Service層使用事務(wù)腳本。

使用這種開發(fā)方式媳板，對(duì)象只用于在各層之間傳輸數(shù)據(jù)用桑腮，這里的對(duì)象就是“貧血模型”，只有數(shù)據(jù)字段和Get/Set方法蛉幸，沒(méi)有邏輯在對(duì)象中破讨。

我們以一個(gè)庫(kù)存扣減的場(chǎng)景來(lái)舉例：

業(yè)務(wù)場(chǎng)景

首先談一下業(yè)務(wù)場(chǎng)景，一個(gè)下訂單扣減庫(kù)存（鎖庫(kù)存）奕纫，這個(gè)很簡(jiǎn)單提陶。先判斷庫(kù)存是否足夠，然后扣減可銷售庫(kù)存匹层，增加訂單占用庫(kù)存隙笆，然后再記錄一個(gè)庫(kù)存變動(dòng)記錄日志（作為憑證）

貧血模型的設(shè)計(jì)

首先設(shè)計(jì)一個(gè)庫(kù)存表 Stock，有如下字段：

設(shè)計(jì)一個(gè)Stock對(duì)象(Getter和Setter省略)：

Service入口

設(shè)計(jì)一個(gè)StockService又固，在其中的lock方法中寫邏輯仲器，入?yún)?spuId, skuId, num)。

實(shí)現(xiàn)偽代碼

ok仰冠，打完收工乏冀，如果做的好一些，可以把update和select count合一洋只，這樣可以利用一條語(yǔ)句完成自旋辆沦，解決并發(fā)問(wèn)題（高手）。

小結(jié)

在此我向大家推薦一個(gè)架構(gòu)學(xué)習(xí)交流群识虚。交流學(xué)習(xí)群號(hào)：736220120 ?里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring肢扯，MyBatis，Netty源碼分析担锤，高并發(fā)蔚晨、高性能、分布式、微服務(wù)架構(gòu)的原理铭腕，JVM性能優(yōu)化银择、分布式架構(gòu)等這些成為架構(gòu)師必備的知識(shí)體系。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源累舷，目前受益良多浩考。

有沒(méi)有發(fā)現(xiàn)，在這個(gè)業(yè)務(wù)領(lǐng)域非常重要的核心邏輯 — 下訂單扣減庫(kù)存中操作過(guò)程中被盈，Stock對(duì)象根本不用出現(xiàn)析孽，全部是數(shù)據(jù)庫(kù)操作SQL，所謂的業(yè)務(wù)邏輯就是由多條SQL構(gòu)成只怎。Stock只是CRUD的數(shù)據(jù)對(duì)象而已袜瞬，沒(méi)邏輯可言。

馬丁福勒定義的“貧血模型”是反模式尝盼，面對(duì)簡(jiǎn)單的小系統(tǒng)用事務(wù)腳本方式開發(fā)沒(méi)問(wèn)題吞滞，業(yè)務(wù)邏輯復(fù)雜了，業(yè)務(wù)邏輯盾沫、各種狀態(tài)散布在大量的函數(shù)中裁赠，維護(hù)擴(kuò)展的成本一下子就上來(lái)，貧血模型沒(méi)有實(shí)施微服務(wù)的基礎(chǔ)赴精。

雖然我們用Java這樣的面向?qū)ο笳Z(yǔ)言來(lái)開發(fā)佩捞，但是其實(shí)和過(guò)程型語(yǔ)言是一樣的，所以很多情況下大家用數(shù)據(jù)庫(kù)的存儲(chǔ)過(guò)程來(lái)替代Java寫邏輯反而效果會(huì)更好蕾哟，（ps：用了Spring boot也不是微服務(wù)）一忱。

領(lǐng)域模型的開發(fā)模式

領(lǐng)域模型是將數(shù)據(jù)和行為封裝在一起，并與現(xiàn)實(shí)世界的業(yè)務(wù)對(duì)象相映射谭确。各類具備明確的職責(zé)劃分帘营，使得邏輯分散到合適對(duì)象中。這樣的對(duì)象就是“充血模型” 逐哈。

在具體實(shí)踐中芬迄，我們需要明確一個(gè)概念，就是領(lǐng)域模型是有狀態(tài)的昂秃，他代表一個(gè)實(shí)際存在的事物禀梳。還是接著上面的例子，我們?cè)O(shè)計(jì)Stock對(duì)象需要代表一種商品的實(shí)際庫(kù)存肠骆，并在這個(gè)對(duì)象上面加上業(yè)務(wù)邏輯的方法算途。

這樣做下單鎖庫(kù)存業(yè)務(wù)邏輯的時(shí)候，每次必須先從Repository根據(jù)主鍵load還原Inventory這個(gè)對(duì)象蚀腿，然后執(zhí)行對(duì)應(yīng)的lock(num)方法改變這個(gè)Inventory對(duì)象的狀態(tài)（屬性也是狀態(tài)的一種）嘴瓤，然后再通過(guò)Repository的save方法把這個(gè)對(duì)象持久化到存儲(chǔ)去。

完成上述一系列操作的是Application,Application對(duì)外提供了這種集成操作的接口：

領(lǐng)域模型開發(fā)方法最重要的是把扣減造成的狀態(tài)變化的細(xì)節(jié)放到了Inventory對(duì)象執(zhí)行，這就是對(duì)業(yè)務(wù)邏輯的封裝廓脆。

Application對(duì)象的lock方法可以和事務(wù)腳本方法的StockService的lock來(lái)做個(gè)對(duì)比畏浆，StockService是完全掌握所有細(xì)節(jié)，一旦有了變化（比如庫(kù)存為0也可以扣減）狞贱，Service方法要跟著變；而Application這種方式不需要變化蜀涨，只要在Inventory對(duì)象內(nèi)部計(jì)算就可以了瞎嬉。代碼放到了合適的地方，計(jì)算在合適層次厚柳，一切都很合理氧枣。這種設(shè)計(jì)可以充分利用各種OOD、OOP的理論把業(yè)務(wù)邏輯實(shí)現(xiàn)的很漂亮别垮。

充血模型的缺點(diǎn)

從上面的例子便监，在Repository的load 到執(zhí)行業(yè)務(wù)方法，再到save回去碳想，這是需要耗費(fèi)一定時(shí)間的烧董，但是這個(gè)過(guò)程中如果多個(gè)線程同時(shí)請(qǐng)求對(duì)Inventory庫(kù)存的鎖定，那就會(huì)導(dǎo)致狀態(tài)的不一致胧奔，麻煩的是針對(duì)庫(kù)存的并發(fā)不僅難處理而且很常見(jiàn)逊移。

貧血模型完全依靠數(shù)據(jù)庫(kù)對(duì)并發(fā)的支撐，實(shí)現(xiàn)可以簡(jiǎn)化很多龙填，但充血模型就得自己實(shí)現(xiàn)了胳泉，不管是在內(nèi)存中通過(guò)鎖對(duì)象，還是使用Redis的遠(yuǎn)程鎖機(jī)制岩遗，都比貧血模型復(fù)雜而且可靠性下降扇商，這是充血模型帶來(lái)的挑戰(zhàn)。更好的辦法是可以通過(guò)事件驅(qū)動(dòng)的架構(gòu)來(lái)取消并發(fā)宿礁。

領(lǐng)域模型和微服務(wù)的關(guān)系

上面講了領(lǐng)域模型的實(shí)現(xiàn)案铺，但是他和微服務(wù)是什么關(guān)系呢？在實(shí)踐中窘拯，這個(gè)Inventory是一個(gè)限界上下文的聚合根红且，我們可以認(rèn)為一個(gè)聚合根就是一個(gè)微服務(wù)進(jìn)程。

不過(guò)問(wèn)題又來(lái)了涤姊，一個(gè)庫(kù)存的Inventory一定和商品信息是有關(guān)聯(lián)的暇番，僅僅靠Inventory中的冗余那點(diǎn)商品ID是不夠的，商品的上下架狀態(tài)等等都是業(yè)務(wù)邏輯需要的思喊，那不是又把商品Sku這樣的重型對(duì)象引入了這個(gè)微服務(wù)壁酬？?jī)蓚€(gè)重型的對(duì)象在一個(gè)服務(wù)中？這樣的微服務(wù)拆不開啊，還是必須依靠商品庫(kù)舆乔？岳服！

微服務(wù)和事件驅(qū)動(dòng)

我們采用了領(lǐng)域驅(qū)動(dòng)的開發(fā)方式，使用了充血模型希俩，享受了他的好處吊宋，但是也不得不面對(duì)他帶來(lái)的弊端。這個(gè)弊端在分布式的微服務(wù)架構(gòu)下面又被放大颜武。

事務(wù)一致性

事務(wù)一致性的問(wèn)題在Monolithic下面不是大問(wèn)題璃搜，在微服務(wù)下面卻是很致命，我們回顧一下所謂的ACID原則：

1. Atomicity – 原子性鳞上，改變數(shù)據(jù)狀態(tài)要么是一起完成这吻，要么一起失敗

2. Consistency – 一致性，數(shù)據(jù)的狀態(tài)是完整一致的

3. Isolation – 隔離線篙议，即使有并發(fā)事務(wù)唾糯，互相之間也不影響

4. Durability – 持久性， 一旦事務(wù)提交鬼贱，不可撤銷

在單體服務(wù)和關(guān)系型數(shù)據(jù)庫(kù)的時(shí)候移怯，我們很容易通過(guò)數(shù)據(jù)庫(kù)的特性去完成ACID。但是一旦你按照DDD拆分聚合根-微服務(wù)架構(gòu)吩愧，他們的數(shù)據(jù)庫(kù)就已經(jīng)分離開了芋酌，你就要獨(dú)立面對(duì)分布式事務(wù)，要在自己的代碼里面滿足ACID雁佳。

對(duì)于分布式事務(wù)脐帝，大家一般會(huì)想到以前的JTA標(biāo)準(zhǔn)，2PC兩段式提交糖权。我記得當(dāng)年在Dubbo群里面堵腹，基本每周都會(huì)有人詢問(wèn)Dubbo啥時(shí)候支撐分布式事務(wù)。實(shí)際上根據(jù)分布式系統(tǒng)中CAP原則星澳，當(dāng)P(分區(qū)容忍)發(fā)生的時(shí)候疚顷，強(qiáng)行追求C（一致性），會(huì)導(dǎo)致（A）可用性禁偎、吞吐量下降腿堤，此時(shí)我們一般用最終一致性來(lái)保證我們系統(tǒng)的AP能力。當(dāng)然不是說(shuō)放棄C如暖，而是在一般情況下CAP都能保證笆檀，在發(fā)生分區(qū)的情況下，我們可以通過(guò)最終一致性來(lái)保證數(shù)據(jù)一致盒至。

例：在電商業(yè)務(wù)的下訂單凍結(jié)庫(kù)存場(chǎng)景酗洒。需要根據(jù)庫(kù)存情況確定訂單是否成交士修。

假設(shè)你已經(jīng)采用了分布式系統(tǒng)，這里訂單模塊和庫(kù)存模塊是兩個(gè)服務(wù)樱衷，分別擁有自己的存儲(chǔ)（關(guān)系型數(shù)據(jù)庫(kù)）棋嘲。

在一個(gè)數(shù)據(jù)庫(kù)的時(shí)候，一個(gè)事務(wù)就能搞定兩張表的修改矩桂，但是微服務(wù)中沸移，就沒(méi)法這么做了。

在DDD理念中侄榴，一次事務(wù)只能改變一個(gè)聚合內(nèi)部的狀態(tài)阔籽，如果多個(gè)聚合之間需要狀態(tài)一致，那么就要通過(guò)最終一致性牲蜀。訂單和庫(kù)存明顯是分屬于兩個(gè)不同的限界上下文的聚合，這里需要實(shí)現(xiàn)最終一致性绅这，就需要使用事件驅(qū)動(dòng)的架構(gòu)涣达。

事件驅(qū)動(dòng)實(shí)現(xiàn)最終一致性

事件驅(qū)動(dòng)架構(gòu)在領(lǐng)域?qū)ο笾g通過(guò)異步的消息來(lái)同步狀態(tài)，有些消息也可以同時(shí)發(fā)布給多個(gè)服務(wù)证薇，在消息引起了一個(gè)服務(wù)的同步后可能會(huì)引起另外消息度苔，事件會(huì)擴(kuò)散開。嚴(yán)格意義上的事件驅(qū)動(dòng)是沒(méi)有同步調(diào)用的浑度。

例：在訂單服務(wù)新增訂單后寇窑，訂單的狀態(tài)是“已開啟”，然后發(fā)布一個(gè)Order Created事件到消息隊(duì)列上：

庫(kù)存服務(wù)在接收到Order Created 事件后箩张，將庫(kù)存表格中的某sku減掉可銷售庫(kù)存甩骏，增加訂單占用庫(kù)存，然后再發(fā)送一個(gè)Inventory Locked事件給消息隊(duì)列：

訂單服務(wù)接收到Inventory Locked事件先慷，將訂單的狀態(tài)改為“已確認(rèn).

有人問(wèn)饮笛，如果庫(kù)存不足，鎖定不成功怎么辦论熙？ 簡(jiǎn)單福青，庫(kù)存服務(wù)發(fā)送一個(gè)Lock Fail事件， 訂單服務(wù)接收后脓诡，把訂單置為“已取消”无午。

好消息，我們可以不用鎖祝谚！

事件驅(qū)動(dòng)有個(gè)很大的優(yōu)勢(shì)就是取消了并發(fā)宪迟，所有請(qǐng)求都是排隊(duì)進(jìn)來(lái)，這對(duì)我們實(shí)施充血模型有很大幫助踊跟，我們可以不需要自己來(lái)管理內(nèi)存中的鎖了踩验。取消鎖鸥诽，隊(duì)列處理效率很高，事件驅(qū)動(dòng)可以用在高并發(fā)場(chǎng)景下箕憾，比如搶購(gòu)牡借。

是的，用戶體驗(yàn)有改變袭异。

用了這個(gè)事件驅(qū)動(dòng)钠龙，用戶的體驗(yàn)有可能會(huì)有改變，比如原來(lái)同步架構(gòu)的時(shí)候沒(méi)有庫(kù)存御铃，就馬上告訴你條件不滿足無(wú)法下單碴里，不會(huì)生成訂單；但是改了事件機(jī)制上真，訂單是立即生成的咬腋，很可能過(guò)了一會(huì)系統(tǒng)通知你訂單被取消掉。 就像搶購(gòu)“小米手機(jī)”一樣睡互，幾十萬(wàn)人在排隊(duì)根竿，排了很久告訴你沒(méi)貨了，明天再來(lái)吧就珠。如果希望用戶立即得到結(jié)果寇壳，可以在前端想辦法，在BFF（Backend For Frontend）使用CountDownLatch這樣的鎖把后端的異步轉(zhuǎn)成前端同步妻怎，當(dāng)然這樣BFF消耗比較大壳炎。

沒(méi)辦法，產(chǎn)品經(jīng)理不接受逼侦。

產(chǎn)品經(jīng)理說(shuō)用戶的體驗(yàn)必須是沒(méi)有庫(kù)存就不會(huì)生成訂單匿辩，這個(gè)方案會(huì)不斷的生成取消的訂單，他不能接受榛丢，怎么辦撒汉？那就在訂單列表查詢的時(shí)候，略過(guò)這些cancel狀態(tài)的訂單吧涕滋，也許需要一個(gè)額外的視圖來(lái)做睬辐。我并不是一個(gè)理想主義者，解決當(dāng)前的問(wèn)題是我首先要考慮的宾肺，我們?cè)O(shè)計(jì)微服務(wù)的目的是本想是解決業(yè)務(wù)并發(fā)量溯饵。而現(xiàn)在面臨的卻是用戶體驗(yàn)的問(wèn)題，所以架構(gòu)設(shè)計(jì)也是需要妥協(xié)的:( 但是至少分析完了锨用，我知道我妥協(xié)在什么地方丰刊，為什么妥協(xié)，未來(lái)還有可能改變增拥。

多個(gè)領(lǐng)域多表Join查詢

我個(gè)人認(rèn)為聚合根這樣的模式對(duì)修改狀態(tài)是特別合適啄巧，但是對(duì)搜索數(shù)據(jù)的確是不方便寻歧，比如篩選出一批符合條件的訂單這樣的需求，本身聚合根對(duì)象不能承擔(dān)批量的查詢?nèi)蝿?wù)秩仆，因?yàn)檫@不是他的職責(zé)码泛。那就必須依賴“領(lǐng)域服務(wù)（Domain Service）”這種設(shè)施。

當(dāng)一個(gè)方法不便放在實(shí)體或者值對(duì)象上澄耍，使用領(lǐng)域服務(wù)便是最佳的解決方法噪珊，請(qǐng)確保領(lǐng)域服務(wù)是無(wú)狀態(tài)的。

我們的查詢?nèi)蝿?wù)往往很復(fù)雜齐莲，比如查詢商品列表痢站，要求按照上個(gè)月的銷售額進(jìn)行排序； 要按照商品的退貨率排序等等选酗。但是在微服務(wù)和DDD之后阵难，我們的存儲(chǔ)模型已經(jīng)被拆離開，上述的查詢都是要涉及訂單芒填、用戶多望、商品多個(gè)領(lǐng)域的數(shù)據(jù)。如何搞氢烘？ 此時(shí)我們要引入一個(gè)視圖的概念。比如下面的家厌，查詢用戶名下訂單的操作播玖，直接調(diào)用兩個(gè)服務(wù)自己在內(nèi)存中join效率無(wú)疑是很低的，再加上一些filter條件饭于、分頁(yè)蜀踏，沒(méi)法做了。于是我們將事件廣播出去掰吕，由一個(gè)單獨(dú)的視圖服務(wù)來(lái)接收這些事件果覆，并形成一個(gè)物化視圖（materialized view），這些數(shù)據(jù)已經(jīng)join過(guò)殖熟，處理過(guò)局待，放在一個(gè)單獨(dú)的查詢庫(kù)中，等待查詢菱属，這是一個(gè)典型的以空間換時(shí)間的處理方式钳榨。

經(jīng)過(guò)分析，除了簡(jiǎn)單的根據(jù)主鍵Find或者沒(méi)有太多關(guān)聯(lián)的List查詢纽门，我們大部分的查詢?nèi)蝿?wù)可以放到單獨(dú)的查詢庫(kù)中薛耻，這個(gè)查詢庫(kù)可以是關(guān)系數(shù)據(jù)庫(kù)的ReadOnly庫(kù)，也可以是NoSQL的數(shù)據(jù)庫(kù)赏陵，實(shí)際上我們?cè)陧?xiàng)目中使用了ElasticSearch作為專門的查詢視圖饼齿，效果很不錯(cuò)饲漾。

限界上下文（Bounded Context）和數(shù)據(jù)耦合

除了多領(lǐng)域join的問(wèn)題，我們?cè)跇I(yè)務(wù)中還會(huì)經(jīng)常碰到一些場(chǎng)景缕溉，比如電商中的商品信息是基礎(chǔ)信息考传，屬于單獨(dú)的BC，而其他BC倒淫，不管是營(yíng)銷服務(wù)伙菊、價(jià)格服務(wù)、購(gòu)物車服務(wù)敌土、訂單服務(wù)都是需要引用這個(gè)商品信息的镜硕。但是需要的商品信息只是全部的一小部分而已，營(yíng)銷服務(wù)需要商品的id和名稱返干、上下架狀態(tài)兴枯；訂單服務(wù)需要商品id、名稱矩欠、目錄财剖、價(jià)格等等。這比起商品中心定義一個(gè)商品（商品id癌淮、名稱躺坟、規(guī)格、規(guī)格值乳蓄、詳情等等）只是一個(gè)很小的子集咪橙。這說(shuō)明不同的限界上下文的同樣的術(shù)語(yǔ)，但是所指的概念不一樣虚倒。 這樣的問(wèn)題映射到我們的實(shí)現(xiàn)中美侦，每次在訂單、營(yíng)銷模塊中直接查詢商品模塊魂奥，肯定是不合適菠剩，因?yàn)椋?/p>

商品中心需要適配每個(gè)服務(wù)需要的數(shù)據(jù)，提供不同的接口

并發(fā)量必然很大

服務(wù)之間的耦合嚴(yán)重耻煤，一旦宕機(jī)具壮、升級(jí)影響的范圍很大

特別是最后一條，嚴(yán)重限制了我們獲得微服務(wù)提供的優(yōu)勢(shì)“松耦合哈蝇、每個(gè)服務(wù)自己可以頻繁升級(jí)不影響其他模塊”嘴办。這就需要我們通過(guò)事件驅(qū)動(dòng)方法，適當(dāng)冗余一些數(shù)據(jù)到不同的BC去买鸽，把這種耦合拆解開涧郊。這種耦合有時(shí)候是通過(guò)Value Object嵌入到實(shí)體中的方式，在生成實(shí)體的時(shí)候就冗余眼五，比如訂單在生成的時(shí)候就冗余了商品的信息妆艘；有時(shí)候是通過(guò)額外的Value Object列表方式彤灶，營(yíng)銷中心冗余一部分相關(guān)的商品列表數(shù)據(jù)，并隨時(shí)關(guān)注監(jiān)聽商品的上下級(jí)狀態(tài)批旺，同步替換掉本限界上下文的商品列表幌陕。

下圖一個(gè)下單場(chǎng)景分析，在電商系統(tǒng)中汽煮，我們可以認(rèn)為會(huì)員和商品是所有業(yè)務(wù)的基礎(chǔ)數(shù)據(jù)搏熄，他們的變更應(yīng)該是通過(guò)廣播的方式發(fā)布到各個(gè)領(lǐng)域，每個(gè)領(lǐng)域保留自己需要的信息暇赤。

保證最終一致性

最終一致性成功依賴很多條件

1. 依賴消息傳遞的可靠性心例，可能A系統(tǒng)變更了狀態(tài)，消息發(fā)到B系統(tǒng)的時(shí)候丟失了鞋囊，導(dǎo)致AB的狀態(tài)不一致止后。

2. 依賴服務(wù)的可靠性，如果A系統(tǒng)變更了自己的狀態(tài)溜腐，但是還沒(méi)來(lái)得及發(fā)送消息就掛了译株，也會(huì)導(dǎo)致狀態(tài)不一致。

我記得JavaEE規(guī)范中的JMS中有針對(duì)這兩種問(wèn)題的處理要求挺益，一個(gè)是JMS通過(guò)各種確認(rèn)消息（Client Acknowledge等）來(lái)保證消息的投遞可靠性歉糜，另外是JMS的消息投遞操作可以加入到數(shù)據(jù)庫(kù)的事務(wù)中-即沒(méi)有發(fā)送消息，會(huì)引起數(shù)據(jù)庫(kù)的回滾（沒(méi)有查資料望众，不是很準(zhǔn)確的描述匪补，請(qǐng)專家指正）。不過(guò)現(xiàn)在符合JMS規(guī)范的MQ沒(méi)幾個(gè)黍檩，特別是保一致性需要降低性能，現(xiàn)在標(biāo)榜高吞吐量的MQ都把問(wèn)題拋給了我們自己的應(yīng)用解決始锚。所以這里介紹幾個(gè)常見(jiàn)的方法刽酱，來(lái)提升最終一致性的效果。

使用本地事務(wù)

還是以上面的訂單扣取信用的例子：

訂單服務(wù)開啟本地事務(wù)瞧捌，首先新增訂單棵里；

然后將Order Created事件插入一張專門Event表，事務(wù)提交姐呐；

有一個(gè)單獨(dú)的定時(shí)任務(wù)線程殿怜，定期掃描Event表，掃出來(lái)需要發(fā)送的就丟到MQ曙砂，同時(shí)把Event設(shè)置為“已發(fā)送”头谜。

方案的優(yōu)勢(shì)是:

使用了本地?cái)?shù)據(jù)庫(kù)的事務(wù)，如果Event沒(méi)有插入成功鸠澈，那么訂單也不會(huì)被創(chuàng)建柱告；線程掃描后把event置為已發(fā)送截驮，也確保了消息不會(huì)被漏發(fā)（我們的目標(biāo)是寧可重發(fā)，也不要漏發(fā)际度，因?yàn)镋vent處理會(huì)被設(shè)計(jì)為冪等）葵袭。

缺點(diǎn)是:

需要單獨(dú)處理Event發(fā)布在業(yè)務(wù)邏輯中，繁瑣容易忘記乖菱；Event發(fā)送有些滯后坡锡；定時(shí)掃描性能消耗大，而且會(huì)產(chǎn)生數(shù)據(jù)庫(kù)高水位隱患窒所；我們稍作改進(jìn)鹉勒，使用數(shù)據(jù)庫(kù)特有的MySQL Binlog跟蹤（阿里的Canal）或者Oracle的GoldenGate技術(shù)可以獲得數(shù)據(jù)庫(kù)的Event表的變更通知，這樣就可以避免通過(guò)定時(shí)任務(wù)來(lái)掃描了墩新。

不過(guò)用了這些數(shù)據(jù)庫(kù)日志的工具贸弥，會(huì)和具體的數(shù)據(jù)庫(kù)實(shí)現(xiàn)（甚至是特定的版本）綁定，決策的時(shí)候請(qǐng)慎重海渊。

使用Event Sourcing 事件溯源

事件溯源對(duì)我們來(lái)說(shuō)是一個(gè)特別的思路绵疲，他并不持久化Entity對(duì)象，而是只把初始狀態(tài)和每次變更的Event記錄下來(lái)臣疑，并在內(nèi)存中根據(jù)Event還原Entity對(duì)象的最新狀態(tài)盔憨，具體實(shí)現(xiàn)很類似數(shù)據(jù)庫(kù)的Redolog的實(shí)現(xiàn)，只是他把這種機(jī)制放到了應(yīng)用層來(lái)讯沈。

雖然事件溯源有很多宣稱的優(yōu)勢(shì)郁岩，引入這種技術(shù)要特別小心，首先他不一定適合大部分的業(yè)務(wù)場(chǎng)景缺狠，一旦變更很多的情況下问慎，效率的確是個(gè)大問(wèn)題；另外一些查詢的問(wèn)題也是困擾挤茄。

我們僅僅在個(gè)別的業(yè)務(wù)上探索性的使用Event Souring和AxonFramework如叼，由于實(shí)現(xiàn)起來(lái)比較復(fù)雜，具體的情況還需要等到實(shí)踐一段時(shí)間后再來(lái)總結(jié)穷劈，也許需要額外的一篇文章來(lái)詳細(xì)描述笼恰。