本周和大家聊聊架構(gòu)進(jìn)化史-大家可文末掃碼加入

隨著互聯(lián)網(wǎng)持續(xù)高歌猛進(jìn)，相關(guān)技術(shù)名詞也是層出不窮，ServiceMesh服務(wù)網(wǎng)格這兩年尤為火爆，然而很少有講清楚的文章。筆者這里用心整理了一篇文章，用11張圖演繹ServiceMesh的進(jìn)化歷程，由淺入深，老少咸宜，歡迎拍磚！

01

PART

單體應(yīng)用

萬(wàn)丈高樓平地起，要理解高端ServiceMesh，得先從單體應(yīng)用架構(gòu)開始。在沒(méi)有那么多架構(gòu)概念的“遠(yuǎn)古”年代，一個(gè)網(wǎng)站項(xiàng)目的全部功能都是在一個(gè)進(jìn)程的，一個(gè)B/S應(yīng)用架構(gòu)應(yīng)該是這樣的：

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

當(dāng)用戶訪問(wèn)量變大導(dǎo)致一臺(tái)服務(wù)器無(wú)法支撐時(shí)怎么辦呢？加服務(wù)器加負(fù)載均衡，架構(gòu)就變成這樣了：

B/S+負(fù)載均衡

后面發(fā)現(xiàn)把靜態(tài)文件獨(dú)立出來(lái)，通過(guò)CDN等手段進(jìn)行加速，可以提升應(yīng)用的整體響應(yīng)，然后架構(gòu)就變成：

B/S+前后端分離

然而上面3種架構(gòu)都還是單體應(yīng)用，只是在部署方面進(jìn)行了優(yōu)化，所以避免不了單體應(yīng)用的根本缺點(diǎn)：

·?代碼臃腫，應(yīng)用啟動(dòng)時(shí)間長(zhǎng)；（代碼超過(guò)1G的項(xiàng)目都有！）

·?回歸測(cè)試周期長(zhǎng)，修復(fù)一個(gè)小bug都需要完整的回歸測(cè)試；

·?應(yīng)用容錯(cuò)性差，某個(gè)小小功能的程序錯(cuò)誤可能導(dǎo)致整個(gè)系統(tǒng)宕機(jī)；

·?伸縮困難，單體應(yīng)用擴(kuò)展性能時(shí)只能整個(gè)應(yīng)用進(jìn)行擴(kuò)展；

·?開發(fā)協(xié)作困難，一個(gè)大型應(yīng)用系統(tǒng)，可能幾十個(gè)甚至上百個(gè)開發(fā)人員，大家都在維護(hù)一套代碼的話，代碼管理復(fù)雜度急劇增加。

02

PART

微服務(wù)

這個(gè)時(shí)候微服務(wù)誕生了，微服務(wù)架構(gòu)將單體應(yīng)用拆解成多個(gè)小粒度的微服務(wù) (micro-service)，通過(guò)HTTP API來(lái)組裝對(duì)外提供服務(wù)。由于每個(gè)微服務(wù)足夠小且功能內(nèi)聚，因此能很好地解決以往單體應(yīng)用的開發(fā)與發(fā)布困難的問(wèn)題。

微服務(wù)架構(gòu)的核心是為了解決應(yīng)用微服務(wù)化之后的服務(wù)治理問(wèn)題。一個(gè)微服務(wù)如何發(fā)現(xiàn)其他微服務(wù)呢？最簡(jiǎn)單的方式就是每個(gè)微服務(wù)里面配置其他微服務(wù)的地址，但是當(dāng)微服務(wù)數(shù)量眾多的時(shí)候，這樣做明顯不現(xiàn)實(shí)。所以需要使用到微服務(wù)架構(gòu)中的一個(gè)最重要的組件：服務(wù)注冊(cè)中心，所有服務(wù)都注冊(cè)到服務(wù)注冊(cè)中心，同時(shí)也可以從服務(wù)注冊(cè)中心獲取當(dāng)前可用的服務(wù)清單：

服務(wù)注冊(cè)中心

解決服務(wù)發(fā)現(xiàn)問(wèn)題后，接著需要解決微服務(wù)分布式部署帶來(lái)的第二個(gè)問(wèn)題：服務(wù)配置管理的問(wèn)題。當(dāng)服務(wù)數(shù)量超過(guò)一定程度之后，如果需要在每個(gè)服務(wù)里面分別維護(hù)每一個(gè)服務(wù)的配置文件，運(yùn)維人員估計(jì)要哭了。那么，就需要用到微服務(wù)架構(gòu)里面第二個(gè)重要的組件：配置中心，微服務(wù)架構(gòu)就變成下面這樣了：

配置中心

以上應(yīng)用內(nèi)部的服務(wù)治理，當(dāng)客戶端或外部應(yīng)用調(diào)用服務(wù)的時(shí)候怎么處理呢？服務(wù)A可能有多個(gè)節(jié)點(diǎn)，服務(wù)A、服務(wù)B和服務(wù)C的服務(wù)地址都不同，服務(wù)授權(quán)驗(yàn)證在哪里做？這時(shí)，就需要使用到服務(wù)網(wǎng)關(guān)提供統(tǒng)一的服務(wù)入口，最終形成典型微服務(wù)架構(gòu)：

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

上面是一個(gè)典型的微服務(wù)架構(gòu)，當(dāng)然微服務(wù)的服務(wù)治理還涉及很多內(nèi)容，比如：

·?通過(guò)熔斷、限流等機(jī)制保證高可用；

·?微服務(wù)之間調(diào)用的負(fù)載均衡；

·?分布式事務(wù)（2PC、3PC、TCC等）；

·?服務(wù)調(diào)用鏈跟蹤等。

03

PART

Sevice Mesh

隨著業(yè)務(wù)的發(fā)展和微服務(wù)化的深入，微服務(wù)架構(gòu)里面的各種服務(wù)治理反而會(huì)成為前進(jìn)的桎梏，因?yàn)榧夹g(shù)門檻太高，大量企業(yè)無(wú)法推進(jìn)下去。于是Service Mesh誕生了！以Linkerd，Envoy，Ngixmesh為代表的代理模式（邊車模式）應(yīng)運(yùn)而生，這就是第一代Service Mesh，它將分布式服務(wù)的通信抽象為單獨(dú)一層，在這一層中實(shí)現(xiàn)負(fù)載均衡、服務(wù)發(fā)現(xiàn)、認(rèn)證授權(quán)、監(jiān)控追蹤、流量控制等分布式系統(tǒng)所需要的功能，作為一個(gè)和服務(wù)對(duì)等的代理服務(wù)，和服務(wù)部署在一起，接管服務(wù)的流量，通過(guò)代理之間的通信間接完成服務(wù)之間的通信請(qǐng)求。

如果我們從一個(gè)全局視角來(lái)看，就會(huì)得到如下部署圖：

如果我們暫時(shí)略去服務(wù)，只看Service Mesh的單機(jī)組件組成的網(wǎng)絡(luò)：

何為Service Mesh服務(wù)網(wǎng)格？這會(huì)兒大家應(yīng)該理解了！

然后為了提供統(tǒng)一的上層運(yùn)維入口，Service Mesh演化出了集中式的控制面板，所有的單機(jī)代理組件通過(guò)和控制面板交互進(jìn)行網(wǎng)絡(luò)拓?fù)洳呗缘母潞蛦螜C(jī)數(shù)據(jù)的匯報(bào)。這就是以Istio為代表的第二代Service Mesh。

只看單機(jī)代理組件(數(shù)據(jù)面板)和控制面板的Service Mesh全局部署視圖如下：

至此，11張圖見證了單體架構(gòu)到微服務(wù)到服務(wù)網(wǎng)格的變遷，展示了Service Mesh到底是什么，以及是如何一步步演化到今天這樣一個(gè)形態(tài)。這兩年還有很多熱門的技術(shù)名詞如中臺(tái)、Severless、Faas、CloudNative，讓996的程序員們各種懵。技術(shù)演進(jìn)浩浩蕩蕩，順之者昌逆之者亡，追逐高薪，必須直面！本周三(9號(hào)).NET社區(qū)邀請(qǐng)了重磅大咖(本文貢獻(xiàn)者之一)，在線分享《這些年的互聯(lián)網(wǎng)架構(gòu)進(jìn)化史》，歡迎大家掃碼進(jìn)交流社群！

掃碼即可加入 添加微信 zhaoxiNET007

總結(jié)

以上是生活随笔為你收集整理的11张图演进SeviceMesh服务网格的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。