ServiceMesh究竟解決什麼問題？

SM，第一篇

服務網格（ServiceMesh）這兩年異常之火，號稱是下一代微服務架構，接下來兩個月，準備系統性的寫寫這個東西，但願可以讓你們對最新的架構技術，有個初步的瞭解。

畫外音：

個人行文的風格了，「爲何」每每比「怎麼樣」更重要。

互聯網公司，常常使用的是微服務分層架構。

畫外音：

爲何要服務化，詳見《 服務化到底解決什麼問題？ 》。

隨着數據量不斷增大，吞吐量不斷增長，業務愈來愈複雜，服務的個數會愈來愈多，分層會愈來愈細，除了數據服務層，還會衍生出業務服務層，先後端分離等各類層次結構。

畫外音：

分層的細節，詳見《 互聯網分層架構演進 》。

不斷髮現主要矛盾，抽離主要矛盾，解決主要矛盾，架構天然演進了，微服務架構，潛在的主要矛盾會是什麼呢？

引入微服務架構，通常會引入一個RPC框架，來完成整個RPC的調用過程。

如上圖粉色部分所示，RPC分爲：

• RPC-client，它嵌在調用方進程裏

• RPC-server，是服務進程的基礎

畫外音：

《 離不開的微服務架構，脫不開的RPC細節 》。

不僅是微服務，MQ也是相似的架構：

如上圖粉色部分所示，MQ分爲：

• MQ-send-client

• MQ-server

• MQ-recv-client

畫外音：

《 MQ，互聯網架構解耦神器 》。

框架只是第一步，愈來愈多和RPC，和微服務相關的功能，會被加入進來。

例如：負載均衡

若是要擴展多種負載均衡方案，例如：

• 輪詢

• 隨機

• 取模

• 一致性哈希

RPC-client須要進行升級。

例如：數據收集

若是要對RPC接口處理時間進行收集，來實施統一監控與告警，也須要對RPC-client進行升級。

畫外音，處理時間分爲：

• 客戶端視角處理時間

• 服務端視角處理時間

若是要收集後者，RPC-server也要修改與上報。

又例如：服務發現

服務新增一個實例，通知配置中心，配置中心通知已註冊的RPC-client，將流量打到新啓動的服務實例上去，迅猛完成擴容。

再例如：調用鏈跟蹤

若是要作全鏈路調用鏈跟蹤，RPC-client和RPC-server都須要進行升級。

下面這些功能：

• 負載均衡

• 數據收集

• 服務發現

• 調用鏈跟蹤

• …

其實都不是業務功能，因此互聯網公司通常會有一個相似於「架構部」的技術部門去研發和升級相關功能，而業務線的技術部門直接使用相關框架、工具與平臺，享受各類「黑科技」帶來的便利。

完美！！！

理想很豐滿，現實卻很骨感，因爲：

• RPC-client，它嵌在調用方進程裏

• RPC-server，是服務進程的基礎

每每會面臨如下一些問題：

• 業務技術團隊，仍須要花時間去學習、使用基礎框架與各種工具，而不是全心全意將精力花在業務和產品上

• client要維護m個版本， server要維護n個版本，兼容性要測試m*n個版本

• 若是要支持不一樣語言，每每要開發C-client，Python-client，go-client，Java-client多語言版本

• 每次「黑科技」的升級，都須要推進上下游進行升級，這個週期每每是以季度、半年、又甚至更久，總體效率極低

畫外音：

兄弟，貴司推廣一個技術新產品，週期要多長？

這些耦合，這些通用的痛點，有沒有辦法解決呢？

一個思路是，將服務拆分紅兩個進程，解耦。

• 一個進程實現業務邏輯（無論是調用方，仍是服務提供方），biz，即上圖白色方塊

• 一個進程實現底層技術體系，proxy，即上圖藍色方塊

畫外音：

負載均衡、監控告警、服務發現與治理、調用鏈…等諸多基礎設施，都放到這一層實現。

• biz和proxy共同誕生，共同消亡，互爲本地部署，即上圖虛線方框

• biz和proxy之間，爲本地通信，即上圖黑色箭頭

• 全部biz之間的通信，都經過proxy之間完成，proxy之間才存在遠端鏈接，即上圖紅色箭頭

這樣就實現了「業務的歸業務，技術的歸技術」，實現了充分解耦，若是全部節點都實現瞭解耦，整個架構會演變爲：

• 綠色爲biz

• 藍色爲proxy

整個服務集羣變成了網格狀，這就是Service Mesh服務網格的由來。

架構演進，永無窮盡，痛點多了，天然要分層解耦。但願你們有收穫，後續再細聊SM的設計與架構細節。

思路比結論更重要。

                                                            

                                                                       架構師之路-分享技術思路