前言

如果一個(gè)JAVA開發(fā)人員弓叛，不了解常見(jiàn)架構(gòu)的演進(jìn)，肯定會(huì)制約自己技術(shù)的選型和晉升空間诚纸。這里我列舉了目前主要的四種軟件架構(gòu)以及他們的優(yōu)缺點(diǎn)撰筷，希望能夠幫助軟件開發(fā)人員拓展知識(shí)面。（如有說(shuō)的不對(duì)之處還望指正）

一畦徘、單體架構(gòu)

單體架構(gòu)比較初級(jí)毕籽，典型的三級(jí)架構(gòu)，前端(Web/手機(jī)端)+中間業(yè)務(wù)邏輯層+數(shù)據(jù)庫(kù)層井辆。這是一種典型的Java Spring mvc或者Python Django框架的應(yīng)用关筒。其架構(gòu)圖如下所示：

單體架構(gòu)

單體架構(gòu)的應(yīng)用比較容易部署、測(cè)試掘剪， 在項(xiàng)目的初期平委，單體應(yīng)用可以很好地運(yùn)行。然而夺谁，隨著需求的不斷增加廉赔， 越來(lái)越多的人加入開發(fā)團(tuán)隊(duì)，代碼庫(kù)也在飛速地膨脹匾鸥。慢慢地蜡塌，單體應(yīng)用變得越來(lái)越臃腫，可維護(hù)性勿负、靈活性逐漸降低馏艾，維護(hù)成本越來(lái)越高。

下面是單體架構(gòu)應(yīng)用的一些缺點(diǎn)：

1.復(fù)雜性高：以一個(gè)百萬(wàn)行級(jí)別的單體應(yīng)用為例奴愉，整個(gè)項(xiàng)目包含的模塊非常多琅摩、模塊的邊界模糊、 依賴關(guān)系不清晰锭硼、 代碼質(zhì)量參差不齊房资、 混亂地堆砌在一起√赐罚可想而知整個(gè)項(xiàng)目非常復(fù)雜轰异。每次修改代碼都心驚膽戰(zhàn)岖沛， 甚至添加一個(gè)簡(jiǎn)單的功能， 或者修改一個(gè)Bug都會(huì)帶來(lái)隱含的缺陷搭独。

2.技術(shù)債務(wù)：隨著時(shí)間推移婴削、需求變更和人員更迭，會(huì)逐漸形成應(yīng)用程序的技術(shù)債務(wù)牙肝， 并且越積 越多唉俗。“ 不壞不修”惊奇， 這在軟件開發(fā)中非常常見(jiàn)互躬， 在單體應(yīng)用中這種思想更甚播赁。已使用的系統(tǒng)設(shè)計(jì)或代碼難以被修改颂郎，因?yàn)閼?yīng)用程序中的其他模塊可能會(huì)以意料之外的方式使用它。

3.部署頻率低：隨著代碼的增多容为，構(gòu)建和部署的時(shí)間也會(huì)增加乓序。而在單體應(yīng)用中， 每次功能的變更或缺陷的修復(fù)都會(huì)導(dǎo)致需要重新部署整個(gè)應(yīng)用坎背。全量部署的方式耗時(shí)長(zhǎng)替劈、 影響范圍大、 風(fēng)險(xiǎn)高得滤， 這使得單體應(yīng)用項(xiàng)目上線部署的頻率較低陨献。而部署頻率低又導(dǎo)致兩次發(fā)布之間會(huì)有大量的功能變更和缺陷修復(fù)，出錯(cuò)率比較高懂更。

4.可靠性差：某個(gè)應(yīng)用Bug眨业，例如死循環(huán)、內(nèi)存溢出等沮协， 可能會(huì)導(dǎo)致整個(gè)應(yīng)用的崩潰龄捡。

5.擴(kuò)展能力受限：單體應(yīng)用只能作為一個(gè)整體進(jìn)行擴(kuò)展，無(wú)法根據(jù)業(yè)務(wù)模塊的需要進(jìn)行伸縮慷暂。例如聘殖，應(yīng)用中有的模塊是計(jì)算密集型的，它需要強(qiáng)勁的CPU行瑞；有的模塊則是IO密集型的奸腺，需要更大的內(nèi)存。由于這些模塊部署在一起血久，不得不在硬件的選擇上做出妥協(xié)突照。

6.阻礙技術(shù)創(chuàng)新：單體應(yīng)用往往使用統(tǒng)一的技術(shù)平臺(tái)或方案解決所有的問(wèn)題， 團(tuán)隊(duì)中的每個(gè)成員 都必須使用相同的開發(fā)語(yǔ)言和框架洋魂，要想引入新框架或新技術(shù)平臺(tái)會(huì)非常困難绷旗。

二喜鼓、分布式應(yīng)用

大型互聯(lián)網(wǎng)架構(gòu)演進(jìn)過(guò)程

架構(gòu)師應(yīng)具備的分布式知識(shí)

主流分布式架構(gòu)設(shè)計(jì)詳解

文末有架構(gòu)圖集領(lǐng)取

中級(jí)架構(gòu)，分布式應(yīng)用衔肢，中間層分布式+數(shù)據(jù)庫(kù)分布式庄岖，是單體架構(gòu)的并發(fā)擴(kuò)展，將一個(gè)大的系統(tǒng)劃分為多個(gè)業(yè)務(wù)模塊角骤，業(yè)務(wù)模塊分別部署在不同的服務(wù)器上隅忿，各個(gè)業(yè)務(wù)模塊之間通過(guò)接口進(jìn)行數(shù)據(jù)交互。數(shù)據(jù)庫(kù)也大量采用分布式數(shù)據(jù)庫(kù)邦尊，如redis背桐、ES、solor等蝉揍。通過(guò)LVS/Nginx代理應(yīng)用链峭，將用戶請(qǐng)求均衡的負(fù)載到不同的服務(wù)器上。其架構(gòu)圖如下所示：

分布式架構(gòu)

該架構(gòu)相對(duì)于單體架構(gòu)來(lái)說(shuō)又沾，這種架構(gòu)提供了負(fù)載均衡的能力弊仪，大大提高了系統(tǒng)負(fù)載能力，解決了網(wǎng)站高并發(fā)的需求杖刷。另外還有以下特點(diǎn)：

1.降低了耦合度：把模塊拆分,使用接口通信,降低模塊之間的耦合度励饵。

2.責(zé)任清晰：把項(xiàng)目拆分成若干個(gè)子項(xiàng)目,不同的團(tuán)隊(duì)負(fù)責(zé)不同的子項(xiàng)目。

3.擴(kuò)展方便：增加功能時(shí)只需要再增加一個(gè)子項(xiàng)目,調(diào)用其他系統(tǒng)的接口就可以滑燃。

4.部署方便:可以靈活的進(jìn)行分布式部署役听。

5.提高代碼的復(fù)用性：比如service層,如果不采用分布式rest服務(wù)方式架構(gòu)就會(huì)在手機(jī)wap商城,微信商城,pc,android，ios每個(gè)端都要寫一個(gè)service層邏輯,開發(fā)量大,難以維護(hù)一起升級(jí),這時(shí)候就可以采用分布式rest服務(wù)方式,公用一個(gè)service層表窘。

缺點(diǎn) : 系統(tǒng)之間的交互要使用遠(yuǎn)程通信,接口開發(fā)增大工作量,但是利大于弊典予。

三、微服務(wù)架構(gòu)

服務(wù)的前世今生

基于分布式思想下的RPC解決方案

Dubbo應(yīng)用及源碼解讀

SpringBoot

SpringCloud應(yīng)用及源碼解讀

Docker虛擬化技術(shù)

文末領(lǐng)取清晰圖片

微服務(wù)架構(gòu)蚊丐，主要是中間層分解熙参，將系統(tǒng)拆分成很多小應(yīng)用（微服務(wù)），微服務(wù)可以部署在不同的服務(wù)器上麦备，也可以部署在相同的服務(wù)器不同的容器上孽椰。當(dāng)應(yīng)用的故障不會(huì)影響到其他應(yīng)用，單應(yīng)用的負(fù)載也不會(huì)影響到其他應(yīng)用凛篙，其代表框架有Spring cloud黍匾、Dubbo等。其架構(gòu)圖如下所示：

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

1.易于開發(fā)和維護(hù)：一個(gè)微服務(wù)只會(huì)關(guān)注一個(gè)特定的業(yè)務(wù)功能呛梆，所以它業(yè)務(wù)清晰锐涯、代碼量較少。開發(fā)和維護(hù)單個(gè)微服務(wù)相對(duì)簡(jiǎn)單填物。而整個(gè)應(yīng)用是由若干個(gè)微服務(wù)構(gòu)建而成的纹腌，所以整個(gè)應(yīng)用也會(huì)被維持在一個(gè)可控狀態(tài)霎终。

2.單個(gè)微服務(wù)啟動(dòng)較快：單個(gè)微服務(wù)代碼量較少， 所以啟動(dòng)會(huì)比較快升薯。

3.局部修改容易部署：單體應(yīng)用只要有修改莱褒，就得重新部署整個(gè)應(yīng)用，微服務(wù)解決了這樣的問(wèn)題涎劈。一般來(lái)說(shuō)广凸，對(duì)某個(gè)微服務(wù)進(jìn)行修改壹蔓，只需要重新部署這個(gè)服務(wù)即可鲜棠。

4.技術(shù)棧不受限：在微服務(wù)架構(gòu)中，可以結(jié)合項(xiàng)目業(yè)務(wù)及團(tuán)隊(duì)的特點(diǎn)嫁乘，合理地選擇技術(shù)棧蹦浦。例如某些服務(wù)可使用關(guān)系型數(shù)據(jù)庫(kù)MySQL扭吁；某些微服務(wù)有圖形計(jì)算的需求，可以使用Neo4j白筹；甚至可根據(jù)需要智末，部分微服務(wù)使用Java開發(fā)谅摄，部分微服務(wù)使用Node.js開發(fā)徒河。

微服務(wù)雖然有很多吸引人的地方，但它并不是免費(fèi)的午餐送漠，使用它是有代價(jià)的顽照。使用微服務(wù)架構(gòu)面臨的挑戰(zhàn)。

1.運(yùn)維要求較高：更多的服務(wù)意味著更多的運(yùn)維投入闽寡。在單體架構(gòu)中代兵，只需要保證一個(gè)應(yīng)用的正常運(yùn)行。而在微服務(wù)中爷狈，需要保證幾十甚至幾百個(gè)服務(wù)服務(wù)的正常運(yùn)行與協(xié)作植影，這給運(yùn)維帶來(lái)了很大的挑戰(zhàn)。

2.分布式固有的復(fù)雜性：使用微服務(wù)構(gòu)建的是分布式系統(tǒng)涎永。對(duì)于一個(gè)分布式系統(tǒng)思币，系統(tǒng)容錯(cuò)、網(wǎng)絡(luò)延遲羡微、分布式事務(wù)等都會(huì)帶來(lái)巨大的挑戰(zhàn)谷饿。

3.接口調(diào)整成本高：微服務(wù)之間通過(guò)接口進(jìn)行通信。如果修改某一個(gè)微服務(wù)的API妈倔，可能所有使用了該接口的微服務(wù)都需要做調(diào)整博投。

4.重復(fù)勞動(dòng)：很多服務(wù)可能都會(huì)使用到相同的功能，而這個(gè)功能并沒(méi)有達(dá)到分解為一個(gè)微服務(wù)的程度盯蝴，這個(gè)時(shí)候毅哗，可能各個(gè)服務(wù)都會(huì)開發(fā)這一功能听怕，從而導(dǎo)致代碼重復(fù)。盡管可以使用共享庫(kù)來(lái)解決這個(gè)問(wèn)題（例如可以將這個(gè)功能封裝成公共組件虑绵，需要該功能的微服務(wù)引用該組件）叉跛，但共享庫(kù)在多語(yǔ)言環(huán)境下就不一定行得通了。

四蒸殿、云原生架構(gòu)

云計(jì)算從工業(yè)化應(yīng)用到如今筷厘，已走過(guò)十五個(gè)年頭，然而大量應(yīng)用使用云的方式仍停滯在傳統(tǒng) IDC 時(shí)代： 虛擬機(jī)代替了原來(lái)的物理機(jī)：使用文件保存應(yīng)用數(shù)據(jù)宏所，大量自帶的三方技術(shù)組件酥艳，沒(méi)有經(jīng)過(guò)架構(gòu)改造（如 微服務(wù)改造）的應(yīng)用上云，傳統(tǒng)的應(yīng)用打包與發(fā)布方式等等爬骤。對(duì)于如何使用這些技術(shù)充石，沒(méi)有絕對(duì)的對(duì)與錯(cuò)， 只是在云的時(shí)代不能充分利用云的強(qiáng)大能力霞玄，不能從云技術(shù)中獲得更高的可用性與可擴(kuò)展能力骤铃，也不能 利用云提升發(fā)布和運(yùn)維的效率，是一件非常遺憾的事情坷剧。

因此云的時(shí)代需要新的技術(shù)架構(gòu)惰爬，來(lái)幫助企業(yè)應(yīng)用能夠更好地利 用云計(jì)算優(yōu)勢(shì)，充分釋放云計(jì)算的技術(shù)紅利惫企，讓業(yè)務(wù)更敏捷撕瞧、成本更低的同時(shí)又可伸縮性更靈活，而這 些正好就是云原生架構(gòu)專注解決的技術(shù)點(diǎn)狞尔。

云原生

1.代碼結(jié)構(gòu)發(fā)生巨大變化：在云的環(huán)境中丛版，比如“如何獲取存儲(chǔ)”變成了若干服務(wù)，包括對(duì)象存儲(chǔ)服務(wù)偏序、塊存儲(chǔ)服務(wù)和沒(méi)有隨機(jī) 訪問(wèn)的文件存儲(chǔ)服務(wù)页畦。云不僅改變了開發(fā)人員獲得這些存儲(chǔ)能力的界面，還在于云產(chǎn)品在這些 OpenAPI? 或者開源 SDK 背后把分布式場(chǎng)景中的高可用挑戰(zhàn)研儒、自動(dòng)擴(kuò)縮容挑戰(zhàn)豫缨、安全挑戰(zhàn)、運(yùn)維升級(jí)挑戰(zhàn)等都處理了

2.非功能性特性的大量委托：不能說(shuō)云計(jì)算解決了所有非功能性問(wèn)題殉摔，但確實(shí)大量非功能性特性州胳，特別是分布式環(huán)境下復(fù)雜非功能 性問(wèn)題，被云產(chǎn)品處理掉了以大家最頭疼的高可用為例逸月，云產(chǎn)品在多個(gè)層面為應(yīng)用提供了解決方案：

虛機(jī)：當(dāng)虛機(jī)檢測(cè)到底層硬件異常時(shí)栓撞，自動(dòng)幫助應(yīng)用做熱遷移，遷移后的應(yīng)用不需重新啟動(dòng)而仍然具 備對(duì)外服務(wù)的能力，應(yīng)用對(duì)整個(gè)遷移過(guò)程都不會(huì)有任何感知瓤湘；

容器：有時(shí)應(yīng)用所在的物理機(jī)是正常的瓢颅，只是應(yīng)用自身的問(wèn)題（比如 bug、資源耗盡等）而無(wú)法正常 對(duì)外提供服務(wù)弛说。容器通過(guò)監(jiān)控檢查探測(cè)到進(jìn)程狀態(tài)異常挽懦，從而實(shí)施異常節(jié)點(diǎn)的下線、新節(jié)點(diǎn)上線和生產(chǎn)流量的切換等操作木人，整個(gè)過(guò)程自動(dòng)完成而無(wú)需運(yùn)維人員干預(yù)信柿；

云服務(wù)：如果應(yīng)用把“有狀態(tài)”部分都交給了云服務(wù)（如緩存、數(shù)據(jù)庫(kù)醒第、對(duì)象存儲(chǔ)等）渔嚷，加上全局對(duì) 象的持有小型化或具備從磁盤快速重建能力，由于云服務(wù)本身是具備極強(qiáng)的高可用能力稠曼，那么應(yīng)用本身 會(huì)變成更薄的“無(wú)狀態(tài)”應(yīng)用形病，因?yàn)楦呖捎霉收蠋?lái)的業(yè)務(wù)中斷會(huì)降至分鐘級(jí)；如果應(yīng)用是 N-M 的對(duì)等 架構(gòu)架構(gòu)模式霞幅，那么結(jié)合Load Balancer 產(chǎn)品可獲得幾乎無(wú)損的高可用能力漠吻！

3.高度自動(dòng)化的軟件交付：基于云原生的自動(dòng)化軟件交付相比較當(dāng)前的人工軟件交付是一個(gè)巨大的進(jìn)步。以微服務(wù)為例司恳，應(yīng)用微 服務(wù)化以后途乃，往往被部署到成千上萬(wàn)個(gè)節(jié)點(diǎn)上，如果系統(tǒng)不具備高度的自動(dòng)化能力抵赢，任何一次新業(yè)務(wù)的 上線欺劳，都會(huì)帶來(lái)極大的工作量挑戰(zhàn)，嚴(yán)重時(shí)還會(huì)導(dǎo)致業(yè)務(wù)變更超過(guò)上線窗口而不可用铅鲤。

對(duì)于云原生架構(gòu)，沒(méi)有全部展示出來(lái)枫弟，那如果有感興趣了解的老友們呢...可以私信我獲取邢享，喜歡小編的分布式、微服務(wù)系統(tǒng)圖的也能分享給大家哦~小編對(duì)架構(gòu)體系做了一系列的系統(tǒng)圖淡诗，很開心能分享給大家骇塘，私信小編就可以啦！