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