1忘闻、前言
隨著互聯(lián)網(wǎng)的發(fā)展贞间，網(wǎng)站應(yīng)用的規(guī)模也在不斷的擴(kuò)大坝锰，進(jìn)而導(dǎo)致系統(tǒng)架構(gòu)也在不斷的進(jìn)行變化。
-
從互聯(lián)網(wǎng)早起到現(xiàn)在今魔，系統(tǒng)架構(gòu)大體經(jīng)歷了下面幾個過程: 單體應(yīng)用架構(gòu)—>垂直應(yīng)用架構(gòu)—>分布式架構(gòu)—>SOA架構(gòu)—>微服務(wù)架構(gòu)勺像，當(dāng)然還有悄然興起的Service Mesh(服務(wù)網(wǎng)格化)障贸。如圖：
image.png 接下來我們就來了解一下每種系統(tǒng)架構(gòu)是什么樣子的， 以及各有什么優(yōu)缺點(diǎn)吟宦、為什么使用微服務(wù)架構(gòu)篮洁。
關(guān)鍵詞： 用戶訪問量（并發(fā)訪問）&代碼重復(fù)量、容錯率殃姓、可維護(hù)性袁波、水平擴(kuò)展
1.1 單體應(yīng)用架構(gòu)
互聯(lián)網(wǎng)早期，一般的網(wǎng)站應(yīng)用流量較小蜗侈，只需一個應(yīng)用篷牌，將所有功能代碼都部署在一起就可以，這樣可以減少開發(fā)踏幻、部署和維護(hù)的成本枷颊。
比如說一個電商系統(tǒng)，里面會包含很多用戶管理该面，商品管理夭苗，訂單管理，物流管理等等很多模塊隔缀，我們會把它們做成一個web項(xiàng)目题造，然后部署到一臺tomcat服務(wù)器上。
- 優(yōu)點(diǎn)：
項(xiàng)目架構(gòu)簡單猾瘸，小型項(xiàng)目的話界赔， 開發(fā)成本低
項(xiàng)目部署在一個節(jié)點(diǎn)上， 維護(hù)方便 - 缺點(diǎn)：
全部功能集成在一個工程中须妻，對于大型項(xiàng)目來講不易開發(fā)和維護(hù)
項(xiàng)目模塊之間緊密耦合仔蝌，單點(diǎn)容錯率低
無法針對不同模塊進(jìn)行針對性優(yōu)化和水平擴(kuò)展
1.2 垂直應(yīng)用架構(gòu)
隨著訪問量的逐漸增大，單一應(yīng)用只能依靠增加節(jié)點(diǎn)來應(yīng)對（加機(jī)器）荒吏，但是這時候會發(fā)現(xiàn)并不是所有的模塊都會有比較大的訪問量.
還是以上面的電商為例子， 用戶訪問量的增加可能影響的只是用戶和訂單模塊渊鞋， 但是對消息模塊的影響就比較小. 那么此時我們希望只多增加幾個訂單模塊绰更， 而不增加消息模塊. 此時單體應(yīng)用就做不到了， 垂直應(yīng)用就應(yīng)運(yùn)而生了.
所謂的垂直應(yīng)用架構(gòu)锡宋，就是將原來的一個應(yīng)用拆成互不相干的幾個應(yīng)用儡湾，以提升效率。比如我們可以將上面電商的單體應(yīng)用拆分成:
電商系統(tǒng)(用戶管理 商品管理 訂單管理)
后臺系統(tǒng)(用戶管理 訂單管理 客戶管理)
CMS系統(tǒng)(廣告管理 營銷管理)
這樣拆分完畢之后执俩，一旦用戶訪問量變大徐钠，只需要增加電商系統(tǒng)的節(jié)點(diǎn)就可以了，而無需增加后臺和CMS的節(jié)點(diǎn)役首。
- 優(yōu)點(diǎn)：
系統(tǒng)拆分實(shí)現(xiàn)了流量分擔(dān)尝丐，解決了并發(fā)問題显拜，而且可以針對不同模塊進(jìn)行優(yōu)化和水?dāng)U展，一個系統(tǒng)的問題不會影響到其他系統(tǒng)爹袁，提高容錯率 - 缺點(diǎn)：
系統(tǒng)之間相互獨(dú)立远荠， 無法進(jìn)行相互調(diào)用
系統(tǒng)之間相互獨(dú)立， 會有重復(fù)的開發(fā)任務(wù)
1. 3 分布式架構(gòu)
當(dāng)垂直應(yīng)用越來越多失息，重復(fù)的業(yè)務(wù)代碼就會越來越多譬淳。這時候，我們就思考可不可以將重復(fù)的代碼抽取出來盹兢，做成統(tǒng)一的業(yè)務(wù)層作為獨(dú)立的服務(wù)邻梆，然后由前端控制層調(diào)用不同的業(yè)務(wù)層服務(wù)呢？
這就產(chǎn)生了新的分布式系統(tǒng)架構(gòu)绎秒。它將把工程拆分成表現(xiàn)層和服務(wù)層兩個部分浦妄，服務(wù)層中包含業(yè)務(wù)邏輯。表現(xiàn)層只需要處理和頁面的交互替裆，業(yè)務(wù)邏輯都是調(diào)用服務(wù)層的服務(wù)來實(shí)現(xiàn)校辩。
- 優(yōu)點(diǎn)：
抽取公共的功能為服務(wù)層，提高代碼復(fù)用性 - 缺點(diǎn)：
系統(tǒng)間耦合度變高辆童，調(diào)用關(guān)系錯綜復(fù)雜宜咒，難以維護(hù)
1.4 SOA架構(gòu)
在分布式架構(gòu)下，當(dāng)服務(wù)越來越多把鉴，容量的評估故黑，小服務(wù)資源的浪費(fèi)等問題逐漸顯現(xiàn)，此時需增加一個調(diào)度中心對集群進(jìn)行實(shí)時管理庭砍。此時场晶，用于資源調(diào)度和治理中心(SOA Service OrientedArchitecture)是關(guān)鍵。
- 優(yōu)點(diǎn):
使用治理中心（ESB\dubbo）解決了服務(wù)間調(diào)用關(guān)系的自動調(diào)節(jié) - 缺點(diǎn):
服務(wù)間會有依賴關(guān)系怠缸，一旦某個環(huán)節(jié)出錯會影響較大( 服務(wù)雪崩 )
服務(wù)關(guān)系復(fù)雜诗轻，運(yùn)維、測試部署困難
1.5 微服務(wù)架構(gòu)
微服務(wù)理念圖：
微服務(wù)架構(gòu)在某種程度上是面向服務(wù)的架構(gòu)SOA繼續(xù)發(fā)展的下一步揭北，它更加強(qiáng)調(diào)服務(wù)的"徹底拆分"扳炬。
微服務(wù)架構(gòu)與SOA架構(gòu)的不同：
- 微服務(wù)架構(gòu)比 SOA架構(gòu)粒度會更加精細(xì)，讓專業(yè)的人去做專業(yè)的事情（專注）搔体，目的提高效率恨樟，每個服務(wù)于服務(wù)之間互不影響（一個微服務(wù)一個進(jìn)程），微服務(wù)架構(gòu)中疚俱，每個服務(wù)必須獨(dú)立部署劝术，微服務(wù)架構(gòu)更加輕巧，輕量級。
- SOA 架構(gòu)中可能數(shù)據(jù)庫存儲會發(fā)生共享养晋，微服務(wù)強(qiáng)調(diào)獨(dú)每個服務(wù)都是單獨(dú)數(shù)據(jù)庫衬吆，保證每個服務(wù)于服務(wù)之間互不影響。
- 項(xiàng)目體現(xiàn)特征微服務(wù)架構(gòu)比 SOA 架構(gòu)更加適合與互聯(lián)網(wǎng)公司敏捷開發(fā)匙握、快速迭代版本咆槽，因?yàn)榱６确浅＞?xì)。
- 優(yōu)點(diǎn)：
服務(wù)原子化拆分圈纺，獨(dú)立打包秦忿、部署和升級，保證每個微服務(wù)清晰的任務(wù)劃分蛾娶，利于擴(kuò)展
微服務(wù)之間采用Restful等輕量級http協(xié)議相互調(diào)用 - 缺點(diǎn)：
分布式系統(tǒng)開發(fā)的技術(shù)成本高（容錯灯谣、分布式事務(wù)等）
復(fù)雜性更高。各個微服務(wù)進(jìn)行分布式獨(dú)立部署蛔琅，當(dāng)進(jìn)行模塊調(diào)用的時候胎许，分布式將會變得更加麻煩。
2罗售、總結(jié)
- 單體架構(gòu)存在高并發(fā)瓶頸辜窑，不適合大型平臺，多用戶寨躁、高并發(fā)訪問量場景穆碎。
- 垂直架構(gòu)將平臺拆分多個子平臺，通過加機(jī)器加節(jié)點(diǎn)方式有效緩解高并發(fā)問題职恳，但多個子平臺存在代碼重復(fù)量（開發(fā)任務(wù)重復(fù)）問題所禀，比如公司多產(chǎn)品下，每個產(chǎn)品/平臺都需要登錄功能放钦。
- 分布式架構(gòu)將重復(fù)代碼獨(dú)立抽取色徘，分別部署，但存在調(diào)用關(guān)系錯綜復(fù)雜問題操禀。
- SOA架構(gòu)提供了服務(wù)治理協(xié)調(diào)方案（注冊中心Dubbo褂策、ESB總線等），存在數(shù)據(jù)庫共享颓屑、服務(wù)雪崩的問題辙培。
- 微服務(wù)架構(gòu)提供了服務(wù)治理、服務(wù)容錯邢锯、鏈路追蹤等一整套方案，徹底拆分搀别，業(yè)務(wù)功能服務(wù)化丹擎，更精細(xì)化，獨(dú)立進(jìn)程，但還是比較依賴網(wǎng)絡(luò)蒂培，技術(shù)成本高再愈。
