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

微服務(wù)現(xiàn)在辣么火，業(yè)界流行的對比的卻都是所謂的Monolithic單體應(yīng)用贡珊，而大量的系統(tǒng)在十幾年前都是已經(jīng)是分布式系統(tǒng)了，那么微服務(wù)作為新的理念和原來的分布式系統(tǒng)涉馁，或者說SOA（面向服務(wù)架構(gòu)）是什么區(qū)別呢门岔？

我們先看相同點：

1.需要Registry，實現(xiàn)動態(tài)的服務(wù)注冊發(fā)現(xiàn)機制烤送；

2.需要考慮分布式下面的事務(wù)一致性寒随，CAP原則下，兩段式提交不能保證性能帮坚，事務(wù)補償機制需要考慮妻往；

3.同步調(diào)用還是異步消息傳遞，如何保證消息可靠性试和？SOA由ESB來集成所有的消息讯泣；

4.都需要統(tǒng)一的Gateway來匯聚、編排接口阅悍，實現(xiàn)統(tǒng)一認證機制好渠，對外提供APP使用的RESTful接口昨稼；

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

那么差別在哪？

1.是持續(xù)集成霍掺、持續(xù)部署匾荆？對于CI、CD（持續(xù)集成杆烁、持續(xù)部署）牙丽，這本身和敏捷、DevOps是交織在一起的兔魂，我認為這更傾向于軟件工程的領(lǐng)域而不是微服務(wù)技術(shù)本身烤芦；

2.使用不同的通訊協(xié)議是不是區(qū)別？微服務(wù)的標(biāo)桿通訊協(xié)議是RESTful入热，而傳統(tǒng)的SOA一般是SOAP拍棕，不過目前來說采用輕量級的RPC框架Dubbo晓铆、Thrift勺良、gRPC非常多，在Spring Cloud中也有Feign框架將標(biāo)準(zhǔn)RESTful轉(zhuǎn)為代碼的API這種仿RPC的行為骄噪，這些通訊協(xié)議不應(yīng)該是區(qū)分微服務(wù)架構(gòu)和SOA的核心差別尚困；

3.是流行的基于容器框架還是虛擬機為主？Docker和虛擬機還是物理機都是架構(gòu)實現(xiàn)的一種方式链蕊，不是核心區(qū)別事甜；

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

1.服務(wù)的切分上有比較大的區(qū)別，SOA原本是以一種“集成”技術(shù)出現(xiàn)的滔韵，很多技術(shù)方案是將原有企業(yè)內(nèi)部服務(wù)封裝為一個獨立進程逻谦，這樣新的業(yè)務(wù)開發(fā)就可重用這些服務(wù)，這些服務(wù)很可能是類似供應(yīng)鏈陪蜻、CRM這樣的非常大的顆粒邦马；而微服務(wù)這個“微”，就說明了他在切分上有講究宴卖，不妥協(xié)滋将。無數(shù)的案例證明，如果你的切分是錯誤的症昏，那么你得不到微服務(wù)承諾的“低耦合随闽、升級不影響、可靠性高”之類的優(yōu)勢肝谭，而會比使用Monolithic有更多的麻煩掘宪。

2.不拆分存儲的微服務(wù)是偽服務(wù)：在實踐中蛾扇，我們常常見到一種架構(gòu)，后端存儲是全部和在一個數(shù)據(jù)庫中添诉，僅僅把前端的業(yè)務(wù)邏輯拆分到不同的服務(wù)進程中屁桑，本質(zhì)上和一個Monolithic一樣，只是把模塊之間的進程內(nèi)調(diào)用改為進程間調(diào)用栏赴，這種切分不可取蘑斧，違反了分布式第一原則，模塊耦合沒有解決须眷，性能卻受到了影響竖瘾。

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

.微服務(wù)的“Micro”這個詞并不是越小越好，而是相對SOA那種粗粒度的服務(wù)花颗，我們需要更小更合適的粒度捕传，這種Micro不是無限制的小。

如果我們將兩路（同步）通信與小/微服務(wù)結(jié)合使用扩劝，并根據(jù)比如“1個類=1個服務(wù)”的原則庸论，那么我們實際上回到了使用Corba、J2EE和分布式對象的20世紀(jì)90年代棒呛。遺憾的是聂示，新生代的開發(fā)人員沒有使用分布式對象的經(jīng)驗，因此也就沒有認識到這個主意多么糟糕簇秒，他們正試圖重復(fù)歷史鱼喉，只是這次使用了新技術(shù)，比如用HTTP取代了RMI或IIOP趋观。

微服務(wù)和Domain Driven Design

一個簡單的圖書管理系統(tǒng)肯定無需微服務(wù)架構(gòu)扛禽。既然采用了微服務(wù)架構(gòu)，那么面對的問題空間必然是比較宏大皱坛，比如整個電商编曼、CRM。

如何拆解服務(wù)呢剩辟？

使用什么樣的方法拆解服務(wù)掐场？業(yè)界流行1個類=1個服務(wù)、1個方法=1個服務(wù)抹沪、2 Pizza團隊刻肄、2周能重寫完成等方法，但是這些都缺乏實施基礎(chǔ)融欧。我們必須從一些軟件設(shè)計方法中尋找敏弃，面向?qū)ο蠛驮O(shè)計模式適用的問題空間是一個模塊，而函數(shù)式編程的理念更多的是在代碼層面的微觀上起作用噪馏。

Eric Evans 的《領(lǐng)域驅(qū)動設(shè)計》這本書對微服務(wù)架構(gòu)有很大借鑒意義麦到，這本書提出了一個能將一個大問題空間拆解分為領(lǐng)域和實體之間的關(guān)系和行為的技術(shù)绿饵。目前來說，這是一個最合理的解決拆分問題的方案瓶颠，透過限界上下文（Bounded Context拟赊，下文簡稱為BC）這個概念，我們能將實現(xiàn)細節(jié)封裝起來粹淋，讓BC都能夠?qū)崿F(xiàn)SRP（單一職責(zé)）原則吸祟。而每個微服務(wù)正是BC在實際世界的物理映射，符合BC思路的微服務(wù)互相獨立松耦合桃移。

微服務(wù)架構(gòu)是一件好事屋匕，逼著大家關(guān)注設(shè)計軟件的合理性，如果原來在Monolithic中領(lǐng)域分析借杰、面向?qū)ο笤O(shè)計做不好过吻，換微服務(wù)會把這個問題成倍的放大

以電商中的訂單和商品兩個領(lǐng)域舉例，按照DDD拆解蔗衡，他們應(yīng)該是兩個獨立的限界上下文纤虽，但是訂單中肯定是包含商品的，如果貿(mào)然拆為兩個BC绞惦，查詢逼纸、調(diào)用關(guān)系就耦合在一起了，甚至有了麻煩的分布式事務(wù)的問題翩隧，這個關(guān)聯(lián)如何拆解樊展？BC理論認為在不同的BC中呻纹，即使是一個術(shù)語堆生，他的關(guān)注點也不一樣，在商品BC中眷唉，關(guān)注的是屬性驴娃、規(guī)格亭畜、詳情等等（實際上商品BC這個領(lǐng)域有價格、庫存蔗怠、促銷等等，把他作為單獨一個BC也是不合理的吩跋，這里為了簡化例子寞射，大家先認為商品BC就是商品基礎(chǔ)信息）， 而在訂單BC中更關(guān)注商品的庫存锌钮、價格桥温。所以在實際編碼設(shè)計中，訂單服務(wù)往往將關(guān)注的商品名稱梁丘、價格等等屬性冗余在訂單中侵浸，這個設(shè)計解脫了和商品BC的強關(guān)聯(lián)旺韭，兩個BC可以獨立提供服務(wù)，獨立數(shù)據(jù)存儲

小結(jié)

微服務(wù)架構(gòu)首先要關(guān)注的不是RPC/ServiceDiscovery/Circuit Breaker這些概念掏觉，也不是Eureka/Docker/SpringCloud/Zipkin這些技術(shù)框架区端，而是服務(wù)的邊界、職責(zé)劃分澳腹，劃分錯誤就會陷入大量的服務(wù)間的相互調(diào)用和分布式事務(wù)中织盼，這種情況微服務(wù)帶來的不是便利而是麻煩。

DDD給我們帶來了合理的劃分手段酱塔，但是DDD的概念眾多悔政，晦澀難以理解，如何抓住重點延旧，合理的運用到微服務(wù)架構(gòu)中呢谋国？

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

1.充血模型

2.事件驅(qū)動

上文我們聊了微服務(wù)的DDD之間的關(guān)系，很多人還是覺得很虛幻迁沫，DDD那么復(fù)雜的理論芦瘾，聚合根、值對象集畅、事件溯源近弟，到底我們該怎么入手呢？

實際上DDD和面向?qū)ο笤O(shè)計挺智、設(shè)計模式等等理論有千絲萬縷的聯(lián)系祷愉，如果不熟悉OOA、OOD赦颇，DDD也是使用不好的二鳄。不過學(xué)習(xí)這些OO理論的時候，大家往往感覺到無用武之地媒怯，因為大部分的Java程序員開發(fā)生涯是從學(xué)習(xí)J2EE經(jīng)典的分層理論開始的（Action订讼、Service、Dao）扇苞，在這種分層理論中欺殿，我們基本沒有啥機會使用那些所謂的“行為型”的設(shè)計模式，這里的核心原因鳖敷，就是J2EE經(jīng)典分層的開發(fā)方式是“貧血模型”脖苏。

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

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

事務(wù)腳本的核心是過程棍潘，可以認為大部分的業(yè)務(wù)處理都是一條條的SQL，事務(wù)腳本把單個SQL組織成為一段業(yè)務(wù)邏輯，在邏輯執(zhí)行的時候蜒谤，使用事務(wù)來保證邏輯的ACID山宾。最典型的就是存儲過程。當(dāng)然我們在平時J2EE經(jīng)典分層架構(gòu)中鳍徽，經(jīng)常在Service層使用事務(wù)腳本资锰。

使用這種開發(fā)方式，對象只用于在各層之間傳輸數(shù)據(jù)用阶祭，這里的對象就是“貧血模型”绷杜，只有數(shù)據(jù)字段和Get/Set方法，沒有邏輯在對象中濒募。

我們以一個庫存扣減的場景來舉例：

業(yè)務(wù)場景

首先談一下業(yè)務(wù)場景鞭盟，一個下訂單扣減庫存（鎖庫存），這個很簡單

先判斷庫存是否足夠瑰剃，然后扣減可銷售庫存齿诉，增加訂單占用庫存，然后再記錄一個庫存變動記錄日志（作為憑證）

貧血模型的設(shè)計

首先設(shè)計一個庫存表 Stock晌姚，有如下字段

設(shè)計一個Stock對象(Getter和Setter省略)

Service入口

設(shè)計一個StockService粤剧，在其中的lock方法中寫邏輯

入?yún)?spuId, skuId, num)

實現(xiàn)偽代碼

ok，打完收工挥唠，如果做的好一些抵恋，可以把update和select count合一，這樣可以利用一條語句完成自旋宝磨，解決并發(fā)問題（高手）弧关。

小結(jié)一下：

有沒有發(fā)現(xiàn)，在這個業(yè)務(wù)領(lǐng)域非常重要的核心邏輯 — 下訂單扣減庫存中操作過程中唤锉，Stock對象根本不用出現(xiàn)世囊，全部是數(shù)據(jù)庫操作SQL，所謂的業(yè)務(wù)邏輯就是由多條SQL構(gòu)成腌紧。Stock只是CRUD的數(shù)據(jù)對象而已茸习，沒邏輯可言畜隶。

馬丁福勒定義的“貧血模型”是反模式壁肋，面對簡單的小系統(tǒng)用事務(wù)腳本方式開發(fā)沒問題，業(yè)務(wù)邏輯復(fù)雜了籽慢，業(yè)務(wù)邏輯浸遗、各種狀態(tài)散布在大量的函數(shù)中，維護擴展的成本一下子就上來箱亿，貧血模型沒有實施微服務(wù)的基礎(chǔ)跛锌。

雖然我們用Java這樣的面向?qū)ο笳Z言來開發(fā)，但是其實和過程型語言是一樣的，所以很多情況下大家用數(shù)據(jù)庫的存儲過程來替代Java寫邏輯反而效果會更好髓帽，（ps：用了Spring boot也不是微服務(wù)）.

如果你也想在IT行業(yè)拿高薪菠赚，可以參加我們的訓(xùn)練營課程，選擇最適合自己的課程學(xué)習(xí)郑藏，技術(shù)大牛親授衡查，7個月后，進入名企拿高薪必盖。我們的課程內(nèi)容有：Java工程化拌牲、高性能及分布式、高性能歌粥、深入淺出塌忽。高架構(gòu)。性能調(diào)優(yōu)失驶、Spring土居，MyBatis，Netty源碼分析和大數(shù)據(jù)等多個知識點嬉探。如果你想拿高薪的装盯，想學(xué)習(xí)的，想就業(yè)前景好的甲馋，想跟別人競爭能取得優(yōu)勢的埂奈，想進阿里面試但擔(dān)心面試不過的，你都可以來定躏，群號為：575745314

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

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

在具體實踐中碧聪，我們需要明確一個概念冒版，就是領(lǐng)域模型是有狀態(tài)的，他代表一個實際存在的事物逞姿。還是接著上面的例子辞嗡，我們設(shè)計Stock對象需要代表一種商品的實際庫存，并在這個對象上面加上業(yè)務(wù)邏輯的方法.

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

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

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

Application對象的lock方法可以和事務(wù)腳本方法的StockService的lock來做個對比，StockService是完全掌握所有細節(jié)丰泊，一旦有了變化（比如庫存為0也可以扣減）薯定，Service方法要跟著變；而Application這種方式不需要變化瞳购，只要在Inventory對象內(nèi)部計算就可以了沉唠。代碼放到了合適的地方，計算在合適層次苛败，一切都很合理满葛。這種設(shè)計可以充分利用各種OOD、OOP的理論把業(yè)務(wù)邏輯實現(xiàn)的很漂亮罢屈。

充血模型的缺點

從上面的例子嘀韧，在Repository的load 到執(zhí)行業(yè)務(wù)方法，再到save回去缠捌，這是需要耗費一定時間的锄贷，但是這個過程中如果多個線程同時請求對Inventory庫存的鎖定，那就會導(dǎo)致狀態(tài)的不一致曼月，麻煩的是針對庫存的并發(fā)不僅難處理而且很常見谊却。

貧血模型完全依靠數(shù)據(jù)庫對并發(fā)的支撐，實現(xiàn)可以簡化很多哑芹，但充血模型就得自己實現(xiàn)了炎辨，不管是在內(nèi)存中通過鎖對象，還是使用Redis的遠程鎖機制聪姿，都比貧血模型復(fù)雜而且可靠性下降碴萧，這是充血模型帶來的挑戰(zhàn)。更好的辦法是可以通過事件驅(qū)動的架構(gòu)來取消并發(fā)末购。

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

上面講了領(lǐng)域模型的實現(xiàn)破喻，但是他和微服務(wù)是什么關(guān)系呢？在實踐中盟榴，這個Inventory是一個限界上下文的聚合根曹质，我們可以認為一個聚合根就是一個微服務(wù)進程。

不過問題又來了擎场，一個庫存的Inventory一定和商品信息是有關(guān)聯(lián)的羽德，僅僅靠Inventory中的冗余那點商品ID是不夠的，商品的上下架狀態(tài)等等都是業(yè)務(wù)邏輯需要的顶籽，那不是又把商品Sku這樣的重型對象引入了這個微服務(wù)玩般？兩個重型的對象在一個服務(wù)中？這樣的微服務(wù)拆不開啊礼饱，還是必須依靠商品庫？！

接上文镊绪，我們采用了領(lǐng)域驅(qū)動的開發(fā)方式匀伏，使用了充血模型，享受了他的好處蝴韭，但是也不得不面對他帶來的弊端够颠。這個弊端在分布式的微服務(wù)架構(gòu)下面又被放大。

事務(wù)一致性

事務(wù)一致性的問題在Monolithic下面不是大問題榄鉴，在微服務(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ù)庫的時候付魔，我們很容易通過數(shù)據(jù)庫的特性去完成ACID聊品。但是一旦你按照DDD拆分聚合根-微服務(wù)架構(gòu)，他們的數(shù)據(jù)庫就已經(jīng)分離開了几苍，你就要獨立面對分布式事務(wù)翻屈，要在自己的代碼里面滿足ACID。

對于分布式事務(wù)妻坝，大家一般會想到以前的JTA標(biāo)準(zhǔn)妖胀，2PC兩段式提交。我記得當(dāng)年在Dubbo群里面惠勒，基本每周都會有人詢問Dubbo啥時候支撐分布式事務(wù)赚抡。實際上根據(jù)分布式系統(tǒng)中CAP原則，當(dāng)P(分區(qū)容忍)發(fā)生的時候纠屋，強行追求C（一致性）涂臣，會導(dǎo)致（A）可用性、吞吐量下降售担，此時我們一般用最終一致性來保證我們系統(tǒng)的AP能力赁遗。當(dāng)然不是說放棄C，而是在一般情況下CAP都能保證族铆，在發(fā)生分區(qū)的情況下岩四，我們可以通過最終一致性來保證數(shù)據(jù)一致。

例：

在電商業(yè)務(wù)的下訂單凍結(jié)庫存場景哥攘。需要根據(jù)庫存情況確定訂單是否成交剖煌。

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

在一個數(shù)據(jù)庫的時候桶唐，一個事務(wù)就能搞定兩張表的修改，但是微服務(wù)中茉兰，就沒法這么做了尤泽。

在DDD理念中，一次事務(wù)只能改變一個聚合內(nèi)部的狀態(tài)规脸，如果多個聚合之間需要狀態(tài)一致坯约，那么就要通過最終一致性。訂單和庫存明顯是分屬于兩個不同的限界上下文的聚合莫鸭，這里需要實現(xiàn)最終一致性闹丐，就需要使用事件驅(qū)動的架構(gòu)。

事件驅(qū)動實現(xiàn)最終一致性

事件驅(qū)動架構(gòu)在領(lǐng)域?qū)ο笾g通過異步的消息來同步狀態(tài)黔龟，有些消息也可以同時發(fā)布給多個服務(wù)妇智，在消息引起了一個服務(wù)的同步后可能會引起另外消息，事件會擴散開氏身。嚴(yán)格意義上的事件驅(qū)動是沒有同步調(diào)用的巍棱。

例子：

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

庫存服務(wù)在接收到Order Created 事件后航徙，將庫存表格中的某sku減掉可銷售庫存，增加訂單占用庫存陷虎，然后再發(fā)送一個Inventory Locked事件給消息隊列

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

有人問，如果庫存不足尚猿，鎖定不成功怎么辦窝稿？ 簡單，庫存服務(wù)發(fā)送一個Lock Fail事件凿掂， 訂單服務(wù)接收后伴榔，把訂單置為“已取消”。

好消息庄萎，我們可以不用鎖踪少！

事件驅(qū)動有個很大的優(yōu)勢就是取消了并發(fā)，所有請求都是排隊進來糠涛，這對我們實施充血模型有很大幫助援奢，我們可以不需要自己來管理內(nèi)存中的鎖了。取消鎖忍捡，隊列處理效率很高集漾，事件驅(qū)動可以用在高并發(fā)場景下切黔，比如搶購。

是的帆竹，用戶體驗有改變绕娘，

用了這個事件驅(qū)動脓规，用戶的體驗有可能會有改變栽连，比如原來同步架構(gòu)的時候沒有庫存，就馬上告訴你條件不滿足無法下單侨舆，不會生成訂單秒紧；但是改了事件機制，訂單是立即生成的挨下，很可能過了一會系統(tǒng)通知你訂單被取消掉熔恢。 就像搶購“小米手機”一樣，幾十萬人在排隊臭笆，排了很久告訴你沒貨了叙淌，明天再來吧。如果希望用戶立即得到結(jié)果愁铺，可以在前端想辦法鹰霍，在BFF（Backend For Frontend）使用CountDownLatch這樣的鎖把后端的異步轉(zhuǎn)成前端同步，當(dāng)然這樣BFF消耗比較大茵乱。

沒辦法茂洒，產(chǎn)品經(jīng)理不接受，

產(chǎn)品經(jīng)理說用戶的體驗必須是沒有庫存就不會生成訂單瓶竭，這個方案會不斷的生成取消的訂單督勺，他不能接受，怎么辦斤贰？那就在訂單列表查詢的時候智哀，略過這些cancel狀態(tài)的訂單吧，也許需要一個額外的視圖來做荧恍。我并不是一個理想主義者瓷叫，解決當(dāng)前的問題是我首先要考慮的，我們設(shè)計微服務(wù)的目的是本想是解決業(yè)務(wù)并發(fā)量块饺。而現(xiàn)在面臨的卻是用戶體驗的問題赞辩，所以架構(gòu)設(shè)計也是需要妥協(xié)的:( 但是至少分析完了，我知道我妥協(xié)在什么地方授艰，為什么妥協(xié)辨嗽，未來還有可能改變。

推薦一個交流學(xué)習(xí)群：575745314里面會分享一些資深架構(gòu)師錄制的視頻錄像：有Spring淮腾，MyBatis糟需，Netty源碼分析屉佳，高并發(fā)、高性能洲押、分布式武花、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識體系杈帐。還能領(lǐng)取免費的學(xué)習(xí)資源体箕，目前受益良多：

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

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

當(dāng)一個方法不便放在實體或者值對象上，使用領(lǐng)域服務(wù)便是最佳的解決方法尽楔，請確保領(lǐng)域服務(wù)是無狀態(tài)的投储。

我們的查詢?nèi)蝿?wù)往往很復(fù)雜，比如查詢商品列表阔馋，要求按照上個月的銷售額進行排序玛荞； 要按照商品的退貨率排序等等。但是在微服務(wù)和DDD之后垦缅，我們的存儲模型已經(jīng)被拆離開冲泥，上述的查詢都是要涉及訂單、用戶壁涎、商品多個領(lǐng)域的數(shù)據(jù)凡恍。如何搞？ 此時我們要引入一個視圖的概念怔球。比如下面的嚼酝，查詢用戶名下訂單的操作，直接調(diào)用兩個服務(wù)自己在內(nèi)存中join效率無疑是很低的竟坛，再加上一些filter條件闽巩、分頁，沒法做了担汤。于是我們將事件廣播出去涎跨，由一個單獨的視圖服務(wù)來接收這些事件，并形成一個物化視圖（materialized view）崭歧，這些數(shù)據(jù)已經(jīng)join過隅很，處理過，放在一個單獨的查詢庫中率碾，等待查詢叔营，這是一個典型的以空間換時間的處理方式屋彪。

經(jīng)過分析，除了簡單的根據(jù)主鍵Find或者沒有太多關(guān)聯(lián)的List查詢绒尊，我們大部分的查詢?nèi)蝿?wù)可以放到單獨的查詢庫中畜挥，這個查詢庫可以是關(guān)系數(shù)據(jù)庫的ReadOnly庫，也可以是NoSQL的數(shù)據(jù)庫婴谱，實際上我們在項目中使用了ElasticSearch作為專門的查詢視圖蟹但，效果很不錯

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

除了多領(lǐng)域join的問題，我們在業(yè)務(wù)中還會經(jīng)常碰到一些場景勘究，比如電商中的商品信息是基礎(chǔ)信息矮湘，屬于單獨的BC斟冕，而其他BC口糕，不管是營銷服務(wù)、價格服務(wù)磕蛇、購物車服務(wù)景描、訂單服務(wù)都是需要引用這個商品信息的。但是需要的商品信息只是全部的一小部分而已秀撇，營銷服務(wù)需要商品的id和名稱超棺、上下架狀態(tài)；訂單服務(wù)需要商品id呵燕、名稱棠绘、目錄、價格等等再扭。這比起商品中心定義一個商品（商品id氧苍、名稱、規(guī)格泛范、規(guī)格值让虐、詳情等等）只是一個很小的子集。這說明不同的限界上下文的同樣的術(shù)語罢荡，但是所指的概念不一樣赡突。 這樣的問題映射到我們的實現(xiàn)中，每次在訂單区赵、營銷模塊中直接查詢商品模塊惭缰，肯定是不合適，因為商品中心需要適配每個服務(wù)需要的數(shù)據(jù)笼才，提供不同的接口并發(fā)量必然很大,服務(wù)之間的耦合嚴(yán)重漱受，一旦宕機、升級影響的范圍很大患整。

特別是最后一條拜效，嚴(yán)重限制了我們獲得微服務(wù)提供的優(yōu)勢“松耦合喷众、每個服務(wù)自己可以頻繁升級不影響其他模塊”。這就需要我們通過事件驅(qū)動方法紧憾，適當(dāng)冗余一些數(shù)據(jù)到不同的BC去到千，把這種耦合拆解開。這種耦合有時候是通過Value Object嵌入到實體中的方式赴穗，在生成實體的時候就冗余憔四，比如訂單在生成的時候就冗余了商品的信息；有時候是通過額外的Value Object列表方式般眉，營銷中心冗余一部分相關(guān)的商品列表數(shù)據(jù)了赵，并隨時關(guān)注監(jiān)聽商品的上下級狀態(tài)，同步替換掉本限界上下文的商品列表甸赃。

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

保證最終一致性

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

1:依賴消息傳遞的可靠性项玛，可能A系統(tǒng)變更了狀態(tài)貌笨，消息發(fā)到B系統(tǒng)的時候丟失了，導(dǎo)致AB的狀態(tài)不一致

2:依賴服務(wù)的可靠性襟沮，如果A系統(tǒng)變更了自己的狀態(tài)锥惋，但是還沒來得及發(fā)送消息就掛了。也會導(dǎo)致狀態(tài)不一致

我記得JavaEE規(guī)范中的JMS中有針對這兩種問題的處理要求开伏，一個是JMS通過各種確認消息（Client Acknowledge等）來保證消息的投遞可靠性膀跌，另外是JMS的消息投遞操作可以加入到數(shù)據(jù)庫的事務(wù)中-即沒有發(fā)送消息，會引起數(shù)據(jù)庫的回滾（沒有查資料硅则，不是很準(zhǔn)確的描述淹父，請專家指正）。不過現(xiàn)在符合JMS規(guī)范的MQ沒幾個怎虫，特別是保一致性需要降低性能暑认，現(xiàn)在標(biāo)榜高吞吐量的MQ都把問題拋給了我們自己的應(yīng)用解決。所以這里介紹幾個常見的方法大审，來提升最終一致性的效果蘸际。

使用本地事務(wù)還是以上面的訂單扣取信用的例子

訂單服務(wù)開啟本地事務(wù)，首先新增訂單徒扶；然后將Order Created事件插入一張專門Event表粮彤，事務(wù)提交；有一個單獨的定時任務(wù)線程，定期掃描Event表导坟，掃出來需要發(fā)送的就丟到MQ屿良，同時把Event設(shè)置為“已發(fā)送”。

方案的優(yōu)勢是使用了本地數(shù)據(jù)庫的事務(wù)惫周，如果Event沒有插入成功尘惧，那么訂單也不會被創(chuàng)建；線程掃描后把event置為已發(fā)送递递，也確保了消息不會被漏發(fā)（我們的目標(biāo)是寧可重發(fā)喷橙，也不要漏發(fā)，因為Event處理會被設(shè)計為冪等）登舞。

缺點是需要單獨處理Event發(fā)布在業(yè)務(wù)邏輯中贰逾，繁瑣容易忘記；Event發(fā)送有些滯后菠秒；定時掃描性能消耗大疙剑，而且會產(chǎn)生數(shù)據(jù)庫高水位隱患；我們稍作改進稽煤，使用數(shù)據(jù)庫特有的MySQL Binlog跟蹤（阿里的Canal）或者Oracle的GoldenGate技術(shù)可以獲得數(shù)據(jù)庫的Event表的變更通知核芽，這樣就可以避免通過定時任務(wù)來掃描了.

不過用了這些數(shù)據(jù)庫日志的工具，會和具體的數(shù)據(jù)庫實現(xiàn)（甚至是特定的版本）綁定酵熙，決策的時候請慎重。

使用Event Sourcing 事件溯源

事件溯源對我們來說是一個特別的思路驰坊，他并不持久化Entity對象匾二，而是只把初始狀態(tài)和每次變更的Event記錄下來，并在內(nèi)存中根據(jù)Event還原Entity對象的最新狀態(tài)拳芙，具體實現(xiàn)很類似數(shù)據(jù)庫的Redolog的實現(xiàn)察藐，只是他把這種機制放到了應(yīng)用層來。

雖然事件溯源有很多宣稱的優(yōu)勢舟扎，引入這種技術(shù)要特別小心分飞，首先他不一定適合大部分的業(yè)務(wù)場景，一旦變更很多的情況下睹限，效率的確是個大問題譬猫；另外一些查詢的問題也是困擾。

我們僅僅在個別的業(yè)務(wù)上探索性的使用Event Souring和AxonFramework羡疗，由于實現(xiàn)起來比較復(fù)雜染服，具體的情況還需要等到實踐一段時間后再來總結(jié)，也許需要額外的一篇文章來詳細描述