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

講正事兒之前怒详，先講個故事——話說昆烁，從前有個叫周星星的少年静尼，從擺街邊攤起家传泊，通過自己的奮斗眷细，最終成為飲食界的大亨。他的發(fā)家過程經(jīng)歷了四個階段：

1. 街邊攤階段：這時剛剛創(chuàng)業(yè)普舆，一窮二白沼侣，要錢沒錢歉秫、要人沒人雁芙，自己什么都得做，賣材料、做飯菜筛圆、擺桌子太援、收錢，全都他一個人搞定仙蛉。剛開始荠瘪，客人不多，一個人游刃有余哀墓。后來篮绰，來光顧的客人也越來越多，一個人就忙不過來了臀突，有時客人看要等很久就走了……于是候学，賺了些錢的他磕瓷，盤算著開個小店……
   

   街邊攤階段

2. 快餐店階段：他招了幾個員工困食，簡單分為了三組：一組服務(wù)員，負責(zé)接送客人符匾，人多的時候引導(dǎo)客人排隊啊胶；一組廚師垛贤，他自己做主廚聘惦，指導(dǎo)其他廚師做菜；一組采購黔漂，負責(zé)買菜等禀酱。就這樣剂跟，快餐店開起來了酣藻。三組人員各司其職……他家秘制的“撒尿牛丸”遠近聞名臊恋，客人絡(luò)繹不絕……但慢慢地抖仅，有客人反映砖第，他家的菜品太少，沒辦法滿足客人的需求了……
   

   快餐店階段

3. 大酒店階段：為了滿足客人越來越高的要求放吩，他把快餐店升級為大酒店渡紫。他成立了四大廚師部門惕澎，分別為客人提供川菜颜骤、東北菜忍抽、粵菜、湘菜四大不同菜系干跛，通過統(tǒng)一的后勤楼入、財務(wù)把這四大菜系管理起來……剛開始久免，一切都很好阎姥，賺的缽滿盆滿呼巴。但隨著生意越來越旺，客人越來越多衣赶，又開始出問題了：餐廳地方不夠府瞄！排隊的人越來越多。周星星打算開分店鲸郊，但問題來了：這個分店秆撮，吃川菜的多换况，其他菜沒什么人吃；那個分店舒裤，吃粵菜的多惭每，別的菜系廚師閑著……后來亏栈，又發(fā)生了一件事：吃東北菜的兩桌客人，一句“你愁啥”黎侈，一句“瞅你咋地”峻汉，就打起來了脐往，攔都攔不住业簿。這一鬧，把吃粵菜柜思、川菜、湘菜的客人都給嚇跑了……精明的周星星一眼看出了問題号枕，這是因為四個菜系共享了一個資源（餐廳）陨享，導(dǎo)致了一個服務(wù)出問題，別的服務(wù)都遭殃蛙紫。他意識到坑傅，要繼續(xù)發(fā)展喷斋，企業(yè)的組織方式還得調(diào)整星爪。
   

   大酒店階段

4. 飲食集團階段：周星星成立了周氏飲食集團顽腾，掌控各個子公司，每個子公司都有獨立的前臺久信、后勤漓摩，互不干擾管毙，自負盈虧。還有一個額外的好處啃炸，比如這段時間日料流行南用，那就多開幾個日料店；又過一陣子，西餐流行忘巧，那就把日料店關(guān)一些砚嘴，多開些西餐店。整個集團很靈活耸采，總是能快速的抓住商機虾宇。至此如绸，周星星成為飲食界的老大。
   

   飲食集團階段

其實搪泳，軟件架構(gòu)的演進過程和周氏企業(yè)演進過程是一模一樣的岸军！軟件架構(gòu)的演進也分為四個階段：單體架構(gòu)（街邊攤）艰赞、分層架構(gòu)（快餐店）脏榆、SOA架構(gòu)（大酒店）和微服務(wù)架構(gòu)（飲食集團）

架構(gòu)演進

1. 單體架構(gòu)：實際上沒什么架構(gòu)的概念须喂，所有的業(yè)務(wù)邏輯都在一個項目里打包成一個二進制的編譯后文件，通過這個文件進行部署仔役，并提供業(yè)務(wù)能力又兵。它就像上面的“街邊攤”，很小很靈活宙地。但是處理能力有限宅粥；沒有分工电谣，難以擴展。

2. 分層架構(gòu)：又叫“三明治”架構(gòu)企垦。分層架構(gòu)中的每一層都著特定的職能钞诡。層之間是隔離的湃崩，即一個請求，必須一層一層的傳遞誊抛，而不能跨層傳遞拗窃。分層架構(gòu)的流行泌辫，催生了大量的可復(fù)用的中間件。它就像上面的“快餐店”宾毒，有了明確分工的幾個組诈铛，團隊的能力大于個人墨礁，處理能力有了一定的提升恩静。但是面對更復(fù)雜服務(wù)要求的時候蹲坷，無論是擴展能力循签，還是服務(wù)能力懦底，都有點力不從心罕扎。

3. SOA架構(gòu)：即面向服務(wù)的架構(gòu)（Service Oriented Architecture）腔召，它的關(guān)注點是服務(wù)臀蛛。一個服務(wù)定義了一個相對獨立崖蜜、自包含、可重用的業(yè)務(wù)功能抡柿。服務(wù)間一般通過企業(yè)服務(wù)總線（ESB）的方式組裝起來洲劣。它就像上面的“大酒店”课蔬，可以把各個較獨立的服務(wù)組裝起來窍侧，對外提供更復(fù)雜的服務(wù)星持，滿足客戶更多樣化的需求宏胯。SOA架構(gòu)要提高擴展性谨湘，就需要采用“分布式”的方式了衫哥。那么撤逢，各種服務(wù)如何行“分布式化”？這就催生了下面要說的微服務(wù)架構(gòu)初狰。也可以認為奢入，微服務(wù)架構(gòu)就是SOA架構(gòu)分布式化的一種實現(xiàn)媳叨。

4. 微服務(wù)架構(gòu)：以一組小而自治的服務(wù)來構(gòu)建整個系統(tǒng)，系統(tǒng)的一大特點是去中心化武福，從而實現(xiàn)更靈活的擴展能力捉片。它就像上面的“飲食集團”汞舱，每個服務(wù)都獨立而自治，整個系統(tǒng)（集團）具有很強的彈性莹规，擴展自如访惜，風(fēng)險可控腻扇。當(dāng)然，這樣的彈性是要付出一定代價的窒篱，后面我們再詳細分析墙杯。

回顧軟件架構(gòu)的演進其實是與企業(yè)組織演進一樣的：都是為了滿足客戶越來越多括荡、越來越復(fù)雜的需求，不斷調(diào)整軟件（企業(yè)）內(nèi)部結(jié)構(gòu)的過程嫉髓。最后，都使得軟件（企業(yè)）的處理能力梧油、擴展能力儡陨、抗風(fēng)險能力等等更強量淌。

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

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

可以說晃痴，微服務(wù)是在領(lǐng)域驅(qū)動設(shè)計（DDD）、持續(xù)交付（DevOps）泣侮、對Web的理解（REST）活尊、六邊形架構(gòu)漏益、虛擬化平臺等一系列技術(shù)的基礎(chǔ)上，發(fā)展建立起來的铜犬。微服務(wù)架構(gòu)應(yīng)用這些技術(shù)解決了原來SOA中面臨的一系列問題癣猾∮啾可以說，這五大技術(shù)是微服務(wù)架構(gòu)的基石像捶，沒有它們，就不可能建立起微服務(wù)架構(gòu)唆垃。

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

1. 如何劃分服務(wù)：SOA雖然提出了以服務(wù)為核心的觀念沉删，但是對于如何劃分服務(wù)矾瑰，并沒有很好的指導(dǎo)方法×购唬“領(lǐng)域驅(qū)動設(shè)計”理論為如何進行服務(wù)劃分提供了方法論采幌。雖然對于微服務(wù)架構(gòu)休傍，如何劃分服務(wù)仍是一大難題，但比之前有了一定改善人柿。
2. 服務(wù)如何集成：持續(xù)集成及DevOps技術(shù)的發(fā)展忙厌，為自動化的服務(wù)集成逢净，提供了一系列工具和解決方案。多個協(xié)同工作的服務(wù)需要集成測試婶芭、聯(lián)合部署犀农，沒有自動化的持續(xù)集成基本無法實施宰掉。持續(xù)集成是微服務(wù)架構(gòu)中的一個不可或缺的部分赁濒。
3. 服務(wù)如何通信：隨著HTTP技術(shù)的發(fā)展拒炎，產(chǎn)生了RESTful的架構(gòu)風(fēng)格击你，它為服務(wù)之間通信和集成提供了很好的解決方案谎柄。其中最重要的一點是資源的概念，將服務(wù)看成是對外提供的一系列資源鸿摇，資源在服務(wù)內(nèi)的形態(tài)與客戶端能看到的表現(xiàn)形態(tài)是分離的拙吉。一般使用HTTP作為REST的底層通信協(xié)議揪荣。HTTP提供了get、post必逆、put揽乱、delete等動詞凰棉，可以很好的表達對資源的使用陌粹；同時，HTTP周邊有一整套完善的生態(tài)系統(tǒng)或舞，可以使得服務(wù)的通信映凳、負載均衡邮破、緩存仆救、監(jiān)控等更加容易彤蔽。
4. 服務(wù)內(nèi)部如何組織：六邊形架構(gòu)通過對領(lǐng)域模型顿痪、應(yīng)用送膳、適配器的劃分，使得業(yè)務(wù)領(lǐng)域的邊界更加清晰撕阎，服務(wù)具有更好的可擴展性虏束，更容易測試厦章。微服務(wù)中的單個服務(wù)，一般使用六邊形的架構(gòu)風(fēng)格汗侵。
5. 服務(wù)如何擴展：虛擬化技術(shù)的發(fā)展晰韵，尤其是Docker技術(shù)熟妓、云技術(shù)的發(fā)展起愈，使得服務(wù)的分布式安裝、部署官觅、彈性擴展成為一件相對容易的事阐污。彈性擴展是微服務(wù)架構(gòu)的一個重要優(yōu)點疤剑，脫離了虛擬化技術(shù)闷堡，這個優(yōu)點將很難實現(xiàn)杠览。

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

上面說了那么多微服務(wù)纵势，到底什么才是微服務(wù)呢钦铁？這里姑且給出一個定義：微服務(wù)就是一些協(xié)同工作的小而自治的服務(wù)。所謂“小”佛点，就是專注做好一件事超营；所謂“自治”阅虫，就是服務(wù)是獨立的實體，服務(wù)之間彼此獨立米碰，修改部署一個服務(wù)不會影響其他服務(wù)吕座。

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

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

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

“天下熙熙皆為利來瓦哎，天下攘攘皆為利往”——這么多人追隨微服務(wù)而來柔逼，必有其“利”卒落！相比之前的架構(gòu)蜂桶，微服務(wù)主要有下面幾個優(yōu)點：

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

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

俗話說：“天下沒有免費的午餐”县钥，要獲得微服務(wù)帶來益處若贮，是要付出一定代價的！下面看看微服務(wù)對比原來架構(gòu)帶來了哪些挑戰(zhàn)：

1. 版本
各個微服務(wù)應(yīng)該用統(tǒng)一版本號呢锥咸，還是各自獨立版本细移？”——一旦為圖方便弧轧，使用統(tǒng)一一個版本，就會使得微服務(wù)帶來的“自治速缨、獨立發(fā)布部署”的優(yōu)點不復(fù)存在代乃。而每個服務(wù)維護不同的版本仿粹，又為版本管理的復(fù)雜度帶來極大的挑戰(zhàn)吭历。并且不同版本之間的兼容性測試也會十分復(fù)雜晌区。

2. 代碼
重復(fù)的代碼怎么辦通贞？——這還用問嗎？根據(jù)DRY原則捡偏，當(dāng)然要抽取出來——然而银伟，在微服務(wù)時绘搞，則不是這樣的。因為不同服務(wù)間一旦抽取了公共的業(yè)務(wù)邏輯琉预，就意味著這兩個服務(wù)耦合在一起了蒿褂。公共模塊的變更會影響這兩個服務(wù)。所以啄栓，一般建議微服務(wù)內(nèi)遵守DRY原則，而跨服務(wù)可以適當(dāng)違反DRY原則……這同時又帶來了另外一個問題近速，就是重構(gòu)代碼會變得十分困難削葱，出現(xiàn)共性的問題淳梦，可能需要多個團隊同時修改。在老板眼里首繁，這就是資源浪費啊。

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

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

5. 分布式
微服務(wù)架構(gòu)是典型的分布式架構(gòu)射亏。天生具有分布式架構(gòu)所面臨的挑戰(zhàn)智润∥戳荆可以了解一下：分布式系統(tǒng)的八大謬誤，CAP定理兼蜈。這些復(fù)雜性为狸，都是微服務(wù)架構(gòu)需要克服的献宫。

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

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

可見踢代，微服務(wù)架構(gòu)面臨的挑戰(zhàn)難度還是比較高的胳挎。雖然慕爬，現(xiàn)有的一些微服務(wù)框架可以幫助解決一部分問題，但要將微服務(wù)落地姥卢，這些挑戰(zhàn)仍然是需要認真面對的独榴。

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

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

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

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

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

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

有些反對這個觀點的人說：“即使系統(tǒng)規(guī)模不大奕纫，使用微服務(wù)也可以使系統(tǒng)更解耦烫沙，后面擴展更容易”〕湃幔——這是本末倒置了您访。并不是微服務(wù)架構(gòu)使得系統(tǒng)更解耦，而恰恰相反檀训，是解耦做好了享言，才能做好微服務(wù)架構(gòu)览露！優(yōu)秀微服務(wù)架構(gòu)實踐的前提是合理劃分服務(wù)，使得服務(wù)高內(nèi)聚铭腕、低耦合多糠，而不是反過來浩考。微服務(wù)架構(gòu)中劃分服務(wù)的方法論是DDD（按照限界上下文來劃分服務(wù)）析孽，這個方法論并不要求一定是微服務(wù)架構(gòu)，各種架構(gòu)都可以實施怜俐。正如前面所說“越不了解一個領(lǐng)域邓尤，為服務(wù)找到合適的限界上下文就越難”。微服務(wù)架構(gòu)中季稳，一旦服務(wù)邊界劃錯了景鼠，帶來的后果是災(zāi)難性的痹扇；而不是分布式的架構(gòu)中浓恶，這種錯誤的修正要容易得多。

2. 看組織結(jié)構(gòu)：
微服務(wù)架構(gòu)倡導(dǎo)的是每個服務(wù)由一個具備全棧能力的團隊負責(zé)杜窄。如果當(dāng)前組織是按技能劃分的，比如前端團隊莉钙、后端團隊磁玉、數(shù)據(jù)庫團隊等吮铭，那就不是很合適谓晌。要么放棄微服務(wù)，要么調(diào)整組織結(jié)構(gòu)胧奔。

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

4. 看人員能力：

不管一開始看起來什么樣捍靠，它永遠是人的問題磁携。

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

最后如暖，

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

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