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

微服務(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ū)別呢媳拴？

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

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

需要考慮分布式下面的事務(wù)一致性屈溉，CAP原則下塞关，兩段式提交不能保證性能，事務(wù)補(bǔ)償機(jī)制需要考慮子巾；

同步調(diào)用還是異步消息傳遞帆赢，如何保證消息可靠性？SOA由ESB來(lái)集成所有的消息线梗；

都需要統(tǒng)一的Gateway來(lái)匯聚椰于、編排接口，實(shí)現(xiàn)統(tǒng)一認(rèn)證機(jī)制仪搔，對(duì)外提供APP使用的RESTful接口瘾婿；

同樣的要關(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ù)開(kāi)發(fā)就可重用這些服務(wù)秸妥，這些服務(wù)很可能是類(lèi)似供應(yīng)鏈滚停、CRM這樣的非常大的顆粒；而微服務(wù)這個(gè)“微”粥惧，就說(shuō)明了他在切分上有講究键畴，不妥協(xié)。無(wú)數(shù)的案例證明突雪，如果你的切分是錯(cuò)誤的起惕，那么你得不到微服務(wù)承諾的“低耦合、升級(jí)不影響咏删、可靠性高”之類(lèi)的優(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è)類(lèi)=1個(gè)服務(wù)”的原則，那么我們實(shí)際上回到了使用Corba蛇更、J2EE和分布式對(duì)象的20世紀(jì)90年代瞻赶。遺憾的是，新生代的開(kāi)發(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)單的圖書(shū)管理系統(tǒng)肯定無(wú)需微服務(wù)架構(gòu)。既然采用了微服務(wù)架構(gòu)豆混，那么面對(duì)的問(wèn)題空間必然是比較宏大篓像，比如整個(gè)電商、CRM崖叫。

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

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

Eric Evans 的《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》這本書(shū)對(duì)微服務(wù)架構(gòu)有很大借鑒意義爽室，這本書(shū)提出了一個(gè)能將一個(gè)大問(wèn)題空間拆解分為領(lǐng)域和實(shí)體之間的關(guān)系和行為的技術(shù)汁讼。目前來(lái)說(shuō)，這是一個(gè)最合理的解決拆分問(wèn)題的方案，透過(guò)限界上下文（Bounded Context嘿架，下文簡(jiǎn)稱(chēng)為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ù)存、促銷(xiāo)等等春锋，把他作為單獨(dú)一個(gè)BC也是不合理的矫膨，這里為了簡(jiǎn)化例子，大家先認(rèn)為商品BC就是商品基礎(chǔ)信息）期奔， 而在訂單BC中更關(guān)注商品的庫(kù)存侧馅、價(jià)格。所以在實(shí)際編碼設(shè)計(jì)中呐萌，訂單服務(wù)往往將關(guān)注的商品名稱(chēng)馁痴、價(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)思想是重中之重

充血模型

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

?

下面兩篇將為大家詳細(xì)介紹這兩個(gè)設(shè)計(jì)思路