(轉(zhuǎn))單體架構(gòu),SOA架構(gòu),微服務(wù)架構(gòu),分布式架構(gòu),集群架構(gòu)

單體架構(gòu)

什么是單體架構(gòu)

一個(gè)歸檔包(例如war格式或者Jar格式)包含了應(yīng)用所有功能的應(yīng)用程序,我們通常稱之為單體應(yīng)用。架構(gòu)單體應(yīng)用的方法論,我們稱之為單體應(yīng)用架構(gòu),這是一種比較傳統(tǒng)的架構(gòu)風(fēng)格。。

單體架構(gòu)示例圖

QQ截圖20180517151958.png

單體架構(gòu)的缺陷

1.復(fù)雜性高

整個(gè)項(xiàng)目包含的模塊非常多,模塊的邊界模糊,依賴關(guān)系不清晰,代碼質(zhì)量參差不齊,整個(gè)項(xiàng)目非常復(fù)雜。每次修改代碼都心驚膽戰(zhàn),甚至添加一個(gè)簡(jiǎn)單的功能,或者修改一個(gè)BUG都會(huì)造成隱含的缺陷。

2.技術(shù)債務(wù)逐漸上升

隨著時(shí)間推移、需求變更和人員更迭,會(huì)逐漸形成應(yīng)用程序的技術(shù)債務(wù),并且越積越多。已使用的系統(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.擴(kuò)展能力受限,無(wú)法按需伸縮

單體應(yīng)用只能作為一個(gè)整體進(jìn)行擴(kuò)展,無(wú)法結(jié)合業(yè)務(wù)模塊的特點(diǎn)進(jìn)行伸縮。

5.阻礙技術(shù)創(chuàng)新

單體應(yīng)用往往使用統(tǒng)一的技術(shù)平臺(tái)或方案解決所有問題,團(tuán)隊(duì)的每個(gè)成員都必須使用相同的開發(fā)語(yǔ)言和架構(gòu),想要引入新的框架或技術(shù)平臺(tái)非常困難。

由于單體架構(gòu)的缺陷日益明顯,所以越來(lái)越多的公司采用微服務(wù)架構(gòu)范式解決上面提到的單體架構(gòu)中的問題。

不同于構(gòu)建單一、龐大的應(yīng)用,微服務(wù)架構(gòu)將應(yīng)用拆分為一套小且互相關(guān)聯(lián)的服務(wù)。

SOA架構(gòu)

SOA是Service-Oriented Architecture的英文縮寫,就是面向服務(wù)的架構(gòu)。這里的服務(wù)可以理解為service層業(yè)務(wù)服務(wù)。

單一應(yīng)用架構(gòu)

當(dāng)網(wǎng)站流量很小時(shí),只需一個(gè)應(yīng)用,將所有功能都部署在一起,以減少部署節(jié)點(diǎn)和成本。

垂直應(yīng)用架構(gòu)

當(dāng)訪問量逐漸增大,單一應(yīng)用增加機(jī)器帶來(lái)的加速度越來(lái)越小,將應(yīng)用拆成互不相干的幾個(gè)應(yīng)用,以提升效率。

分布式服務(wù)架構(gòu)

當(dāng)垂直應(yīng)用越來(lái)越多,應(yīng)用之間交互不可避免,將核心業(yè)務(wù)抽取出來(lái),作為獨(dú)立的服務(wù),逐漸形成穩(wěn)定的服務(wù)中心,使前端應(yīng)用能更快速的響應(yīng)多變的市場(chǎng)需求。

流動(dòng)計(jì)算架構(gòu)

當(dāng)服務(wù)越來(lái)越多,容量的評(píng)估,小服務(wù)資源的浪費(fèi)等問題逐漸顯現(xiàn),此時(shí)需增加一個(gè)調(diào)度中心基于訪問壓力實(shí)時(shí)管理集群容量,提高集群利用率。

此時(shí),用于提高機(jī)器利用率的SOA服務(wù)治理方案是關(guān)鍵。

Dubbo就是SOA服務(wù)治理方案的核心框架。

總結(jié):dubbo不僅可以對(duì)服務(wù)進(jìn)行治理,而且還可以對(duì)服務(wù)進(jìn)行調(diào)用。

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

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

簡(jiǎn)而言之,微服務(wù)架構(gòu)風(fēng)格的開發(fā)方法,是以開發(fā)一組小型服務(wù)的方式來(lái)開發(fā)一個(gè)獨(dú)立的應(yīng)用系統(tǒng)的。其中每個(gè)小型服務(wù)都運(yùn)行在自己的進(jìn)程中,并經(jīng)常采用HTTP資源API輕量的機(jī)制來(lái)相互通信。

這些服務(wù)圍繞業(yè)務(wù)功能進(jìn)行構(gòu)建,并能通過(guò)全自動(dòng)的部署機(jī)制來(lái)進(jìn)行獨(dú)立部署。這些微服務(wù)可以使用不同的語(yǔ)言來(lái)編寫,并且可以使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)。對(duì)這些微服務(wù)我們僅做最低限度的集中管理。

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

QQ截圖20180517201613.png

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

每個(gè)微服務(wù)可獨(dú)立運(yùn)行在自己的進(jìn)程里

一系列獨(dú)立運(yùn)行的微服務(wù)共同構(gòu)建起整個(gè)系統(tǒng)

每個(gè)服務(wù)為獨(dú)立的業(yè)務(wù)開發(fā),一個(gè)微服務(wù)只關(guān)注某個(gè)特定的功能,如訂單管理、用戶管理等

微服務(wù)之間通過(guò)一些輕量的通信機(jī)制進(jìn)行通信,如REST API接口進(jìn)行調(diào)用

可以使用不同的語(yǔ)言與存儲(chǔ)技術(shù)

全自動(dòng)的部署機(jī)制

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

1.易于開發(fā)和維護(hù)

一個(gè)微服務(wù)只關(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ì)維持在可控狀態(tài);

2.單個(gè)微服務(wù)啟動(dòng)較快

單個(gè)微服務(wù)代碼量較少,所以啟動(dòng)會(huì)比較快;

3.局部修改容易部署

單體應(yīng)用只要有修改,就要重新部署整個(gè)應(yīng)用,微服務(wù)解決了這樣的問題。一般來(lái)說(shuō),對(duì)某個(gè)微服務(wù)進(jìn)行修改,只需要重新部署這個(gè)服務(wù)即可;

4.技術(shù)棧不受限

在微服務(wù)中,我們可以結(jié)合項(xiàng)目業(yè)務(wù)及團(tuán)隊(duì)的特點(diǎn),合理地選擇技術(shù)棧

5.按需伸縮

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

1.運(yùn)維要求較高

更多的服務(wù)意味著更多的運(yùn)維投入。在單體架構(gòu)中只需要保證一個(gè)應(yīng)用的正常運(yùn)行;而在微服務(wù)中,需要保證幾十甚至幾百個(gè)服務(wù)的正常運(yùn)行與協(xié)作,帶來(lái)了巨大的挑戰(zhàn);

2.分布式固有的復(fù)雜性

使用微服務(wù)構(gòu)建的是分布式系統(tǒng)。對(duì)于一個(gè)分布式系統(tǒng),系統(tǒng)容錯(cuò)、網(wǎng)絡(luò)延遲、分布式事務(wù)等都帶來(lái)了巨大的挑戰(zhàn);

3.接口調(diào)整成本高

微服務(wù)之間通過(guò)接口進(jìn)行通信。如果修改某個(gè)微服務(wù)的API,可能所有使用了該接口的微服務(wù)都需要做調(diào)整;

4.重復(fù)勞動(dòng)

很多服務(wù)可能都會(huì)使用到相同的功能。而這個(gè)功能并沒有達(dá)到分解為一個(gè)微服務(wù)的程度,這個(gè)時(shí)候,可能各個(gè)服務(wù)都會(huì)開發(fā)這一功能,導(dǎo)致代碼重復(fù)。

微服務(wù)設(shè)計(jì)原則

單一職責(zé)原則

服務(wù)自治原則

輕量級(jí)通信原則

接口明確原則

微服務(wù)和SOA的區(qū)別

微服務(wù)架構(gòu)強(qiáng)調(diào)的第一個(gè)重點(diǎn)就是業(yè)務(wù)系統(tǒng)需要徹底的組件化和服務(wù)化

微服務(wù)不再?gòu)?qiáng)調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線,同時(shí)SOA的思想進(jìn)入到單個(gè)業(yè)務(wù)系統(tǒng)內(nèi)部實(shí)現(xiàn)真正的組件化。

分布式-微服務(wù)-集群的區(qū)別

分布式

QQ截圖20180517203448.png

service A、B、C、D 分別是業(yè)務(wù)組件,通過(guò)API Geteway進(jìn)行業(yè)務(wù)訪問。

將一個(gè)大的系統(tǒng)劃分為多個(gè)業(yè)務(wù)模塊,業(yè)務(wù)模塊分別部署到不同的機(jī)器上,各個(gè)業(yè)務(wù)模塊之間通過(guò)接口進(jìn)行數(shù)據(jù)交互。

區(qū)別分布式的方式是根據(jù)不同機(jī)器不同業(yè)務(wù)。

注:分布式需要做好事務(wù)管理。

集群模式

QQ截圖20180517203458.png

集群模式是不同服務(wù)器部署同一套服務(wù)對(duì)外訪問,實(shí)現(xiàn)服務(wù)的負(fù)載均衡。

區(qū)別集群的方式是根據(jù)部署多臺(tái)服務(wù)器業(yè)務(wù)是否相同。

注:集群模式需要做好session共享,確保在不同服務(wù)器切換的過(guò)程中不會(huì)因?yàn)闆]有獲取到session而中止退出服務(wù)。

一般配置Nginx*的負(fù)載容器實(shí)現(xiàn):靜態(tài)資源緩存、Session共享可以附帶實(shí)現(xiàn),Nginx支持5000個(gè)并發(fā)量。

分布式是否屬于微服務(wù)?

答案是肯定的。微服務(wù)的意思也就是將模塊拆分成一個(gè)獨(dú)立的服務(wù)單元通過(guò)接口來(lái)實(shí)現(xiàn)數(shù)據(jù)的交互。

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

微服務(wù)的設(shè)計(jì)是為了不因?yàn)槟硞€(gè)模塊的升級(jí)和BUG影響現(xiàn)有的系統(tǒng)業(yè)務(wù)。

微服務(wù)與分布式的細(xì)微差別是,微服務(wù)的應(yīng)用不一定是分散在多個(gè)服務(wù)器上,他也可以是同一個(gè)服務(wù)器。

作者:意識(shí)流丶

鏈接:http://www.itdecent.cn/p/92ca0bfbd52f

來(lái)源:簡(jiǎn)書

著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán),非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

友情鏈接更多精彩內(nèi)容