【圖文詳解】更強大的微服務(wù)架構(gòu)——SeviceMesh ！
本周和大家聊聊架構(gòu)進化史-大家可文末掃碼加入
隨著互聯(lián)網(wǎng)持續(xù)高歌猛進，相關(guān)技術(shù)名詞也是層出不窮，ServiceMesh服務(wù)網(wǎng)格這兩年尤為火爆，然而很少有講清楚的文章。筆者這里用心整理了一篇文章，用11張圖演繹ServiceMesh的進化歷程，由淺入深，老少咸宜，歡迎拍磚！
萬丈高樓平地起，要理解高端ServiceMesh，得先從單體應(yīng)用架構(gòu)開始。在沒有那么多架構(gòu)概念的“遠古”年代，一個網(wǎng)站項目的全部功能都是在一個進程的，一個B/S應(yīng)用架構(gòu)應(yīng)該是這樣的：
當用戶訪問量變大導(dǎo)致一臺服務(wù)器無法支撐時怎么辦呢？加服務(wù)器加負載均衡，架構(gòu)就變成這樣了：
后面發(fā)現(xiàn)把靜態(tài)文件獨立出來，通過CDN等手段進行加速，可以提升應(yīng)用的整體響應(yīng)，然后架構(gòu)就變成：
然而上面3種架構(gòu)都還是單體應(yīng)用，只是在部署方面進行了優(yōu)化，所以避免不了單體應(yīng)用的根本缺點：
·?代碼臃腫，應(yīng)用啟動時間長；（代碼超過1G的項目都有！）
·?回歸測試周期長，修復(fù)一個小bug都需要完整的回歸測試；
·?應(yīng)用容錯性差，某個小小功能的程序錯誤可能導(dǎo)致整個系統(tǒng)宕機；
·?伸縮困難，單體應(yīng)用擴展性能時只能整個應(yīng)用進行擴展；
·?開發(fā)協(xié)作困難，一個大型應(yīng)用系統(tǒng)，可能幾十個甚至上百個開發(fā)人員，大家都在維護一套代碼的話，代碼管理復(fù)雜度急劇增加。
這個時候微服務(wù)誕生了，微服務(wù)架構(gòu)將單體應(yīng)用拆解成多個小粒度的微服務(wù) (micro-service)，通過HTTP API來組裝對外提供服務(wù)。由于每個微服務(wù)足夠小且功能內(nèi)聚，因此能很好地解決以往單體應(yīng)用的開發(fā)與發(fā)布困難的問題。
微服務(wù)架構(gòu)的核心是為了解決應(yīng)用微服務(wù)化之后的服務(wù)治理問題。一個微服務(wù)如何發(fā)現(xiàn)其他微服務(wù)呢？最簡單的方式就是每個微服務(wù)里面配置其他微服務(wù)的地址，但是當微服務(wù)數(shù)量眾多的時候，這樣做明顯不現(xiàn)實。所以需要使用到微服務(wù)架構(gòu)中的一個最重要的組件：服務(wù)注冊中心，所有服務(wù)都注冊到服務(wù)注冊中心，同時也可以從服務(wù)注冊中心獲取當前可用的服務(wù)清單：
解決服務(wù)發(fā)現(xiàn)問題后，接著需要解決微服務(wù)分布式部署帶來的第二個問題：服務(wù)配置管理的問題。當服務(wù)數(shù)量超過一定程度之后，如果需要在每個服務(wù)里面分別維護每一個服務(wù)的配置文件，運維人員估計要哭了。那么，就需要用到微服務(wù)架構(gòu)里面第二個重要的組件：配置中心，微服務(wù)架構(gòu)就變成下面這樣了：
以上應(yīng)用內(nèi)部的服務(wù)治理，當客戶端或外部應(yīng)用調(diào)用服務(wù)的時候怎么處理呢？服務(wù)A可能有多個節(jié)點，服務(wù)A、服務(wù)B和服務(wù)C的服務(wù)地址都不同，服務(wù)授權(quán)驗證在哪里做？這時，就需要使用到服務(wù)網(wǎng)關(guān)提供統(tǒng)一的服務(wù)入口，最終形成典型微服務(wù)架構(gòu)：
上面是一個典型的微服務(wù)架構(gòu)，當然微服務(wù)的服務(wù)治理還涉及很多內(nèi)容，比如：
·?通過熔斷、限流等機制保證高可用；
·?微服務(wù)之間調(diào)用的負載均衡；
·?分布式事務(wù)（2PC、3PC、TCC等）；
·?服務(wù)調(diào)用鏈跟蹤等。
隨著業(yè)務(wù)的發(fā)展和微服務(wù)化的深入，微服務(wù)架構(gòu)里面的各種服務(wù)治理反而會成為前進的桎梏，因為技術(shù)門檻太高，大量企業(yè)無法推進下去。于是Service Mesh誕生了！以Linkerd，Envoy，Ngixmesh為代表的代理模式（邊車模式）應(yīng)運而生，這就是第一代Service Mesh，它將分布式服務(wù)的通信抽象為單獨一層，在這一層中實現(xiàn)負載均衡、服務(wù)發(fā)現(xiàn)、認證授權(quán)、監(jiān)控追蹤、流量控制等分布式系統(tǒng)所需要的功能，作為一個和服務(wù)對等的代理服務(wù)，和服務(wù)部署在一起，接管服務(wù)的流量，通過代理之間的通信間接完成服務(wù)之間的通信請求。
如果我們從一個全局視角來看，就會得到如下部署圖：
如果我們暫時略去服務(wù)，只看Service Mesh的單機組件組成的網(wǎng)絡(luò)：
何為Service Mesh服務(wù)網(wǎng)格？這會兒大家應(yīng)該理解了！
然后為了提供統(tǒng)一的上層運維入口，Service Mesh演化出了集中式的控制面板，所有的單機代理組件通過和控制面板交互進行網(wǎng)絡(luò)拓撲策略的更新和單機數(shù)據(jù)的匯報。這就是以Istio為代表的第二代Service Mesh。
只看單機代理組件(數(shù)據(jù)面板)和控制面板的Service Mesh全局部署視圖如下：
至此，11張圖見證了單體架構(gòu)到微服務(wù)到服務(wù)網(wǎng)格的變遷，展示了Service Mesh到底是什么，以及是如何一步步演化到今天這樣一個形態(tài)。這兩年還有很多熱門的技術(shù)名詞如中臺、Severless、Faas、CloudNative，讓996的程序員們各種懵。技術(shù)演進浩浩蕩蕩，順之者昌逆之者亡，追逐高薪，必須直面！本周三(9號).NET社區(qū)邀請了重磅大咖(本文貢獻者之一)，在線分享《這些年的互聯(lián)網(wǎng)架構(gòu)進化史》，歡迎大家掃碼進交流社群！
掃碼即可加入 添加微信 zhaoxiNET007