軟件架構(gòu)的演進(jìn)

講正事兒之前，先講個(gè)故事——話說(shuō)，從前有個(gè)叫周星星的少年，從擺街邊攤起家，通過(guò)自己的奮斗，最終成為飲食界的大亨。他的發(fā)家過(guò)程經(jīng)歷了四個(gè)階段：

1. 街邊攤階段：這時(shí)剛剛創(chuàng)業(yè)，一窮二白，要錢沒(méi)錢、要人沒(méi)人，自己什么都得做，賣材料、做飯菜、擺桌子、收錢，全都他一個(gè)人搞定。剛開(kāi)始，客人不多，一個(gè)人游刃有余。后來(lái)，來(lái)光顧的客人也越來(lái)越多，一個(gè)人就忙不過(guò)來(lái)了，有時(shí)客人看要等很久就走了……于是，賺了些錢的他，盤算著開(kāi)個(gè)小店……
   

   街邊攤階段

2. 快餐店階段：他招了幾個(gè)員工，簡(jiǎn)單分為了三組：一組服務(wù)員，負(fù)責(zé)接送客人，人多的時(shí)候引導(dǎo)客人排隊(duì)；一組廚師，他自己做主廚，指導(dǎo)其他廚師做菜；一組采購(gòu)，負(fù)責(zé)買菜等。就這樣，快餐店開(kāi)起來(lái)了。三組人員各司其職……他家秘制的“撒尿牛丸”遠(yuǎn)近聞名，客人絡(luò)繹不絕……但慢慢地，有客人反映，他家的菜品太少，沒(méi)辦法滿足客人的需求了……
   

   快餐店階段

3. 大酒店階段：為了滿足客人越來(lái)越高的要求，他把快餐店升級(jí)為大酒店。他成立了四大廚師部門，分別為客人提供川菜、東北菜、粵菜、湘菜四大不同菜系，通過(guò)統(tǒng)一的后勤、財(cái)務(wù)把這四大菜系管理起來(lái)……剛開(kāi)始，一切都很好，賺的缽滿盆滿。但隨著生意越來(lái)越旺，客人越來(lái)越多，又開(kāi)始出問(wèn)題了：餐廳地方不夠！排隊(duì)的人越來(lái)越多。周星星打算開(kāi)分店，但問(wèn)題來(lái)了：這個(gè)分店，吃川菜的多，其他菜沒(méi)什么人吃；那個(gè)分店，吃粵菜的多，別的菜系廚師閑著……后來(lái)，又發(fā)生了一件事：吃東北菜的兩桌客人，一句“你愁啥”，一句“瞅你咋地”，就打起來(lái)了，攔都攔不住。這一鬧，把吃粵菜、川菜、湘菜的客人都給嚇跑了……精明的周星星一眼看出了問(wèn)題，這是因?yàn)樗膫€(gè)菜系共享了一個(gè)資源（餐廳），導(dǎo)致了一個(gè)服務(wù)出問(wèn)題，別的服務(wù)都遭殃。他意識(shí)到，要繼續(xù)發(fā)展，企業(yè)的組織方式還得調(diào)整。
   

   大酒店階段

4. 飲食集團(tuán)階段：周星星成立了周氏飲食集團(tuán)，掌控各個(gè)子公司，每個(gè)子公司都有獨(dú)立的前臺(tái)、后勤，互不干擾，自負(fù)盈虧。還有一個(gè)額外的好處，比如這段時(shí)間日料流行，那就多開(kāi)幾個(gè)日料店；又過(guò)一陣子，西餐流行，那就把日料店關(guān)一些，多開(kāi)些西餐店。整個(gè)集團(tuán)很靈活，總是能快速的抓住商機(jī)。至此，周星星成為飲食界的老大。
   

   飲食集團(tuán)階段

其實(shí)，軟件架構(gòu)的演進(jìn)過(guò)程和周氏企業(yè)演進(jìn)過(guò)程是一模一樣的！軟件架構(gòu)的演進(jìn)也分為四個(gè)階段：?jiǎn)误w架構(gòu)（街邊攤）、分層架構(gòu)（快餐店）、SOA架構(gòu)（大酒店）和微服務(wù)架構(gòu)（飲食集團(tuán)）

架構(gòu)演進(jìn)

1. 單體架構(gòu)：實(shí)際上沒(méi)什么架構(gòu)的概念，所有的業(yè)務(wù)邏輯都在一個(gè)項(xiàng)目里打包成一個(gè)二進(jìn)制的編譯后文件，通過(guò)這個(gè)文件進(jìn)行部署，并提供業(yè)務(wù)能力。它就像上面的“街邊攤”，很小很靈活。但是處理能力有限；沒(méi)有分工，難以擴(kuò)展。

2. 分層架構(gòu)：又叫“三明治”架構(gòu)。分層架構(gòu)中的每一層都著特定的職能。層之間是隔離的，即一個(gè)請(qǐng)求，必須一層一層的傳遞，而不能跨層傳遞。分層架構(gòu)的流行，催生了大量的可復(fù)用的中間件。它就像上面的“快餐店”，有了明確分工的幾個(gè)組，團(tuán)隊(duì)的能力大于個(gè)人，處理能力有了一定的提升。但是面對(duì)更復(fù)雜服務(wù)要求的時(shí)候，無(wú)論是擴(kuò)展能力，還是服務(wù)能力，都有點(diǎn)力不從心。

3. SOA架構(gòu)：即面向服務(wù)的架構(gòu)（Service Oriented Architecture），它的關(guān)注點(diǎn)是服務(wù)。一個(gè)服務(wù)定義了一個(gè)相對(duì)獨(dú)立、自包含、可重用的業(yè)務(wù)功能。服務(wù)間一般通過(guò)企業(yè)服務(wù)總線（ESB）的方式組裝起來(lái)。它就像上面的“大酒店”，可以把各個(gè)較獨(dú)立的服務(wù)組裝起來(lái)，對(duì)外提供更復(fù)雜的服務(wù)，滿足客戶更多樣化的需求。SOA架構(gòu)要提高擴(kuò)展性，就需要采用“分布式”的方式了。那么，各種服務(wù)如何行“分布式化”？這就催生了下面要說(shuō)的微服務(wù)架構(gòu)。也可以認(rèn)為，微服務(wù)架構(gòu)就是SOA架構(gòu)分布式化的一種實(shí)現(xiàn)。

4. 微服務(wù)架構(gòu)：以一組小而自治的服務(wù)來(lái)構(gòu)建整個(gè)系統(tǒng)，系統(tǒng)的一大特點(diǎn)是去中心化，從而實(shí)現(xiàn)更靈活的擴(kuò)展能力。它就像上面的“飲食集團(tuán)”，每個(gè)服務(wù)都獨(dú)立而自治，整個(gè)系統(tǒng)（集團(tuán)）具有很強(qiáng)的彈性，擴(kuò)展自如，風(fēng)險(xiǎn)可控。當(dāng)然，這樣的彈性是要付出一定代價(jià)的，后面我們?cè)僭敿?xì)分析。

回顧軟件架構(gòu)的演進(jìn)其實(shí)是與企業(yè)組織演進(jìn)一樣的：都是為了滿足客戶越來(lái)越多、越來(lái)越復(fù)雜的需求，不斷調(diào)整軟件（企業(yè)）內(nèi)部結(jié)構(gòu)的過(guò)程。最后，都使得軟件（企業(yè)）的處理能力、擴(kuò)展能力、抗風(fēng)險(xiǎn)能力等等更強(qiáng)。

微服務(wù)架構(gòu)的產(chǎn)生

通過(guò)前面軟件架構(gòu)演進(jìn)史的介紹，可以對(duì)微服務(wù)的產(chǎn)生有個(gè)總體的認(rèn)識(shí)。下面講講微服務(wù)具體是如何從SOA架構(gòu)中衍生出來(lái)的。

可以說(shuō)，微服務(wù)是在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）、持續(xù)交付（DevOps）、對(duì)Web的理解（REST）、六邊形架構(gòu)、虛擬化平臺(tái)等一系列技術(shù)的基礎(chǔ)上，發(fā)展建立起來(lái)的。微服務(wù)架構(gòu)應(yīng)用這些技術(shù)解決了原來(lái)SOA中面臨的一系列問(wèn)題?？梢哉f(shuō)，這五大技術(shù)是微服務(wù)架構(gòu)的基石，沒(méi)有它們，就不可能建立起微服務(wù)架構(gòu)。

原SOA面臨的一些問(wèn)題，及微服務(wù)對(duì)此的解決之道：

1. 如何劃分服務(wù)：SOA雖然提出了以服務(wù)為核心的觀念，但是對(duì)于如何劃分服務(wù)，并沒(méi)有很好的指導(dǎo)方法?！邦I(lǐng)域驅(qū)動(dòng)設(shè)計(jì)”理論為如何進(jìn)行服務(wù)劃分提供了方法論。雖然對(duì)于微服務(wù)架構(gòu)，如何劃分服務(wù)仍是一大難題，但比之前有了一定改善。
2. 服務(wù)如何集成：持續(xù)集成及DevOps技術(shù)的發(fā)展，為自動(dòng)化的服務(wù)集成，提供了一系列工具和解決方案。多個(gè)協(xié)同工作的服務(wù)需要集成測(cè)試、聯(lián)合部署，沒(méi)有自動(dòng)化的持續(xù)集成基本無(wú)法實(shí)施。持續(xù)集成是微服務(wù)架構(gòu)中的一個(gè)不可或缺的部分。
3. 服務(wù)如何通信：隨著HTTP技術(shù)的發(fā)展，產(chǎn)生了RESTful的架構(gòu)風(fēng)格，它為服務(wù)之間通信和集成提供了很好的解決方案。其中最重要的一點(diǎn)是資源的概念，將服務(wù)看成是對(duì)外提供的一系列資源，資源在服務(wù)內(nèi)的形態(tài)與客戶端能看到的表現(xiàn)形態(tài)是分離的。一般使用HTTP作為REST的底層通信協(xié)議。HTTP提供了get、post、put、delete等動(dòng)詞，可以很好的表達(dá)對(duì)資源的使用；同時(shí)，HTTP周邊有一整套完善的生態(tài)系統(tǒng)，可以使得服務(wù)的通信、負(fù)載均衡、緩存、監(jiān)控等更加容易。
4. 服務(wù)內(nèi)部如何組織：六邊形架構(gòu)通過(guò)對(duì)領(lǐng)域模型、應(yīng)用、適配器的劃分，使得業(yè)務(wù)領(lǐng)域的邊界更加清晰，服務(wù)具有更好的可擴(kuò)展性，更容易測(cè)試。微服務(wù)中的單個(gè)服務(wù)，一般使用六邊形的架構(gòu)風(fēng)格。
5. 服務(wù)如何擴(kuò)展：虛擬化技術(shù)的發(fā)展，尤其是Docker技術(shù)、云技術(shù)的發(fā)展，使得服務(wù)的分布式安裝、部署、彈性擴(kuò)展成為一件相對(duì)容易的事。彈性擴(kuò)展是微服務(wù)架構(gòu)的一個(gè)重要優(yōu)點(diǎn)，脫離了虛擬化技術(shù)，這個(gè)優(yōu)點(diǎn)將很難實(shí)現(xiàn)。

微服務(wù)架構(gòu)的特點(diǎn)

上面說(shuō)了那么多微服務(wù)，到底什么才是微服務(wù)呢？這里姑且給出一個(gè)定義：微服務(wù)就是一些協(xié)同工作的小而自治的服務(wù)。所謂“小”，就是專注做好一件事；所謂“自治”，就是服務(wù)是獨(dú)立的實(shí)體，服務(wù)之間彼此獨(dú)立，修改部署一個(gè)服務(wù)不會(huì)影響其他服務(wù)。

按Martin Fowler大神的想法，微服務(wù)應(yīng)該具備以下特點(diǎn)：

1. 通過(guò)服務(wù)實(shí)現(xiàn)組件化：使用微服務(wù)作為組裝應(yīng)用的組件，有三大好處：一是可以獨(dú)立部署、替換和升級(jí)；二是由于強(qiáng)迫使用網(wǎng)絡(luò)通信，會(huì)使得接口更加明確；三是可以實(shí)現(xiàn)不同技術(shù)棧的組合。
2. 圍繞業(yè)務(wù)能力組織服務(wù)：按照業(yè)務(wù)劃分服務(wù)，更符合康威定律。一個(gè)服務(wù)可以由一個(gè)全棧團(tuán)隊(duì)負(fù)責(zé)。相比分層架構(gòu)，一個(gè)變更需要更少的溝通，也就更高效。
3. 產(chǎn)品而非項(xiàng)目模式：微服務(wù)架構(gòu)倡導(dǎo)一個(gè)團(tuán)隊(duì)負(fù)責(zé)一個(gè)“微服務(wù)”完整的生命周期，把每個(gè)微服務(wù)當(dāng)成一個(gè)產(chǎn)品來(lái)看待。
4. 智能端點(diǎn)與啞管道：傳統(tǒng)SOA架構(gòu)，強(qiáng)調(diào)ESB（企業(yè)服務(wù)總線）等中間件，試圖把這些中間件做得更智能；而微服務(wù)架構(gòu)與此相反，更強(qiáng)調(diào)把這些智能放到端點(diǎn)（也就是微服務(wù)）中，而微服務(wù)之間的通信應(yīng)盡量簡(jiǎn)單。微服務(wù)就像Unix中的一個(gè)獨(dú)立的命令，他們間的通信就像Unix中的管道那么簡(jiǎn)單。這也是微服務(wù)與傳統(tǒng)SOA的一個(gè)重要差別。
5. “去中心化”治理：整體式應(yīng)用往往傾向于采用單一技術(shù)棧，微服務(wù)架構(gòu)則鼓勵(lì)使用最合適技術(shù)棧完成各自的任務(wù)。
6. “去中心化”數(shù)據(jù)管理：微服務(wù)架構(gòu)倡導(dǎo)讓每個(gè)微服務(wù)管理其自有數(shù)據(jù)，并允許不同微服務(wù)采用不同的數(shù)據(jù)持久化技術(shù)。
7. 基礎(chǔ)設(shè)施自動(dòng)化：通過(guò)持續(xù)集成和持續(xù)交付等方法自動(dòng)化的構(gòu)建、部署微服務(wù)。
8. 為容錯(cuò)設(shè)計(jì)：因?yàn)槲⒎?wù)可能隨時(shí)出現(xiàn)故障，微服務(wù)架構(gòu)中實(shí)時(shí)監(jiān)控和日志機(jī)制非常重要，可以幫助快速發(fā)現(xiàn)故障。出現(xiàn)故障時(shí)微服務(wù)應(yīng)該盡可能自動(dòng)恢復(fù)。
9. 演進(jìn)式設(shè)計(jì)：微服務(wù)應(yīng)用更注重快速更新，因此系統(tǒng)的設(shè)計(jì)會(huì)隨時(shí)間不斷變化及演進(jìn)。

微服務(wù)架構(gòu)的優(yōu)勢(shì)

“天下熙熙皆為利來(lái)，天下攘攘皆為利往”——這么多人追隨微服務(wù)而來(lái)，必有其“利”！相比之前的架構(gòu)，微服務(wù)主要有下面幾個(gè)優(yōu)點(diǎn)：

1. 技術(shù)異構(gòu)性：微服務(wù)可以輕松采用不同的技術(shù)棧。
2. 彈性：一個(gè)服務(wù)不可用不會(huì)導(dǎo)致整個(gè)系統(tǒng)不可用。
3. 擴(kuò)展：可以只針對(duì)那些需要擴(kuò)展的微服務(wù)進(jìn)行擴(kuò)展。
4. 簡(jiǎn)化部署：不用重新部署整個(gè)應(yīng)用，只需要部署個(gè)別服務(wù)，并可以快速回滾。
5. 與組織結(jié)構(gòu)相匹配：符合康威定律。
6. 可組合性：對(duì)已有功能組合實(shí)現(xiàn)新的應(yīng)用。
7. 可替代性：重新實(shí)現(xiàn)某個(gè)服務(wù)相對(duì)容易些。

微服務(wù)架構(gòu)的挑戰(zhàn)

俗話說(shuō)：“天下沒(méi)有免費(fèi)的午餐”，要獲得微服務(wù)帶來(lái)益處，是要付出一定代價(jià)的！下面看看微服務(wù)對(duì)比原來(lái)架構(gòu)帶來(lái)了哪些挑戰(zhàn)：

1. 版本
各個(gè)微服務(wù)應(yīng)該用統(tǒng)一版本號(hào)呢，還是各自獨(dú)立版本？”——一旦為圖方便，使用統(tǒng)一一個(gè)版本，就會(huì)使得微服務(wù)帶來(lái)的“自治、獨(dú)立發(fā)布部署”的優(yōu)點(diǎn)不復(fù)存在。而每個(gè)服務(wù)維護(hù)不同的版本，又為版本管理的復(fù)雜度帶來(lái)極大的挑戰(zhàn)。并且不同版本之間的兼容性測(cè)試也會(huì)十分復(fù)雜。

2. 代碼
重復(fù)的代碼怎么辦？——這還用問(wèn)嗎？根據(jù)DRY原則，當(dāng)然要抽取出來(lái)——然而，在微服務(wù)時(shí)，則不是這樣的。因?yàn)椴煌?wù)間一旦抽取了公共的業(yè)務(wù)邏輯，就意味著這兩個(gè)服務(wù)耦合在一起了。公共模塊的變更會(huì)影響這兩個(gè)服務(wù)。所以，一般建議微服務(wù)內(nèi)遵守DRY原則，而跨服務(wù)可以適當(dāng)違反DRY原則……這同時(shí)又帶來(lái)了另外一個(gè)問(wèn)題，就是重構(gòu)代碼會(huì)變得十分困難，出現(xiàn)共性的問(wèn)題，可能需要多個(gè)團(tuán)隊(duì)同時(shí)修改。在老板眼里，這就是資源浪費(fèi)啊。

3. 界面
服務(wù)拆分了，那用戶界面怎么辦？——如果不分，那界面就是所有服務(wù)耦合的地方，很容易就退回到分層合作的模式；如果界面也分開(kāi)，要怎么組合在一起，給用戶最終呈現(xiàn)一個(gè)統(tǒng)一的整體呢？雖然可以通過(guò)“UI片段組合”或者“前端專用后端”的方法予以解決，但其引入的復(fù)雜性也是一項(xiàng)不小的挑戰(zhàn)。

4. 數(shù)據(jù)
各服務(wù)是共享數(shù)據(jù)還是獨(dú)占數(shù)據(jù)？——如果共享數(shù)據(jù)，這些數(shù)據(jù)就是微服務(wù)之間耦合的點(diǎn)。一個(gè)微服務(wù)修改了數(shù)據(jù)或者數(shù)據(jù)結(jié)構(gòu)，就可能對(duì)另外的服務(wù)產(chǎn)生影響。而如果數(shù)據(jù)分離到每個(gè)服務(wù)中，又帶來(lái)了一些新的挑戰(zhàn)，比如：如何保證事務(wù)的一致性、如何處理報(bào)表系統(tǒng)等等。這些都是設(shè)計(jì)上要面臨的挑戰(zhàn)。

5. 分布式
微服務(wù)架構(gòu)是典型的分布式架構(gòu)。天生具有分布式架構(gòu)所面臨的挑戰(zhàn)?？梢粤私庖幌拢?a target="_blank" rel="nofollow">分布式系統(tǒng)的八大謬誤，CAP定理。這些復(fù)雜性，都是微服務(wù)架構(gòu)需要克服的。

6. 監(jiān)控
監(jiān)控對(duì)于微服務(wù)架構(gòu)十分重要。一個(gè)業(yè)務(wù)流程可能涉及多個(gè)微服務(wù)協(xié)同工作，日志散落在各處。如果沒(méi)有有效的監(jiān)控手段，出了問(wèn)題將很難查。

7. 安全
服務(wù)之間的調(diào)用，能信任嗎？——如果全信任，意味著攻擊者只要進(jìn)入內(nèi)網(wǎng)中，就可以采用中間人攻擊任何服務(wù)。如果不信任，那服務(wù)之間的認(rèn)證、鑒權(quán)、證書發(fā)布、證書管理等一系列復(fù)雜的安全問(wèn)題，都是需要認(rèn)真考慮的。

可見(jiàn)，微服務(wù)架構(gòu)面臨的挑戰(zhàn)難度還是比較高的。雖然，現(xiàn)有的一些微服務(wù)框架可以幫助解決一部分問(wèn)題，但要將微服務(wù)落地，這些挑戰(zhàn)仍然是需要認(rèn)真面對(duì)的。

該不該用微服務(wù)架構(gòu)？

關(guān)于這個(gè)問(wèn)題，《微服務(wù)設(shè)計(jì)》的作者這樣建議道：

越不了解一個(gè)領(lǐng)域，為服務(wù)找到合適的限界上下文就越難。請(qǐng)考慮首先構(gòu)建單塊系統(tǒng)，當(dāng)穩(wěn)定以后再進(jìn)行拆分。一塊塊地拆分你的系統(tǒng)，持續(xù)地改進(jìn)和演進(jìn)系統(tǒng)，擁抱變化！

我在此基礎(chǔ)上，再增加“四看”：

• 看系統(tǒng)規(guī)模
• 看組織結(jié)構(gòu)
• 看基礎(chǔ)設(shè)施
• 看人員能力

1. 看系統(tǒng)規(guī)模：
從前面架構(gòu)演進(jìn)的歷史，可以知道微服務(wù)是為解決規(guī)模比較大的系統(tǒng)的問(wèn)題而誕生的。如果現(xiàn)在的業(yè)務(wù)量以及未來(lái)一、兩年內(nèi)的業(yè)務(wù)量都不會(huì)很大，一臺(tái)服務(wù)器就可以搞定，這樣小規(guī)模的系統(tǒng)就沒(méi)必要硬上微服務(wù)。因?yàn)檫@樣微服務(wù)帶來(lái)的挑戰(zhàn)比它帶來(lái)的好處大得多。

有些反對(duì)這個(gè)觀點(diǎn)的人說(shuō)：“即使系統(tǒng)規(guī)模不大，使用微服務(wù)也可以使系統(tǒng)更解耦，后面擴(kuò)展更容易”?！@是本末倒置了。并不是微服務(wù)架構(gòu)使得系統(tǒng)更解耦，而恰恰相反，是解耦做好了，才能做好微服務(wù)架構(gòu)！優(yōu)秀微服務(wù)架構(gòu)實(shí)踐的前提是合理劃分服務(wù)，使得服務(wù)高內(nèi)聚、低耦合，而不是反過(guò)來(lái)。微服務(wù)架構(gòu)中劃分服務(wù)的方法論是DDD（按照限界上下文來(lái)劃分服務(wù)），這個(gè)方法論并不要求一定是微服務(wù)架構(gòu)，各種架構(gòu)都可以實(shí)施。正如前面所說(shuō)“越不了解一個(gè)領(lǐng)域，為服務(wù)找到合適的限界上下文就越難”。微服務(wù)架構(gòu)中，一旦服務(wù)邊界劃錯(cuò)了，帶來(lái)的后果是災(zāi)難性的；而不是分布式的架構(gòu)中，這種錯(cuò)誤的修正要容易得多。

2. 看組織結(jié)構(gòu)：
微服務(wù)架構(gòu)倡導(dǎo)的是每個(gè)服務(wù)由一個(gè)具備全棧能力的團(tuán)隊(duì)負(fù)責(zé)。如果當(dāng)前組織是按技能劃分的，比如前端團(tuán)隊(duì)、后端團(tuán)隊(duì)、數(shù)據(jù)庫(kù)團(tuán)隊(duì)等，那就不是很合適。要么放棄微服務(wù)，要么調(diào)整組織結(jié)構(gòu)。

3. 看基礎(chǔ)設(shè)施：
虛擬化/云化、持續(xù)集成等自動(dòng)化基礎(chǔ)設(shè)施，是微服務(wù)實(shí)施和運(yùn)維的有力保障。如果組織目前還不具備這些基礎(chǔ)設(shè)施，那么微服務(wù)的落地將面臨很多困難。

4. 看人員能力：

不管一開(kāi)始看起來(lái)什么樣，它永遠(yuǎn)是人的問(wèn)題。

微服務(wù)架構(gòu)賦權(quán)給開(kāi)發(fā)人員以增進(jìn)自治也是充滿挑戰(zhàn)的。過(guò)去人們習(xí)慣把工作扔給別人，習(xí)慣指責(zé)別人，現(xiàn)在要讓他們對(duì)自己的工作完全負(fù)責(zé)可能會(huì)讓其感覺(jué)不舒服。微服務(wù)架構(gòu)要求研發(fā)團(tuán)隊(duì)具備全棧技術(shù)能力，對(duì)單個(gè)研發(fā)人員的綜合素質(zhì)要求也比以往更高。如果人員沒(méi)有從心理上和技能上準(zhǔn)備好，強(qiáng)行推行微服務(wù)，很可能為失敗埋下種子。

最后，

按照InfoQ發(fā)布的2019架構(gòu)和設(shè)計(jì)領(lǐng)域趨勢(shì)報(bào)告，微服務(wù)架構(gòu)很可能進(jìn)入晚期大眾階段，這也意味著，按照Gartner炒作周期，微服務(wù)架構(gòu)已經(jīng)走過(guò)了盲目追捧和幻滅谷底階段，開(kāi)始逐漸走向成熟，走向切實(shí)可落地階段。

微服務(wù)是一個(gè)很容易被濫用或誤用的術(shù)語(yǔ)。本文從架構(gòu)演進(jìn)史入手，介紹了微服務(wù)架構(gòu)的來(lái)龍去脈、它的優(yōu)點(diǎn)以及它帶來(lái)的挑戰(zhàn)。希望可以幫助大家更好的理解微服務(wù)架構(gòu)。根據(jù)自己項(xiàng)目的實(shí)際情況，權(quán)衡利弊，決定是否向微服務(wù)架構(gòu)演進(jìn)。