服務(wù)網(wǎng)格(ServiceMesh)這兩年異常之火，號(hào)稱是下一代微服務(wù)架構(gòu)，接下來兩個(gè)月，準(zhǔn)備系統(tǒng)性的寫寫這個(gè)東西，希望能夠讓大家對(duì)架構(gòu)技術(shù)，有個(gè)初步的了解。

畫外音：我的行文的風(fēng)格了，“為什么”往往比“怎么樣”更重要。

[[263683]]

互聯(lián)網(wǎng)公司，經(jīng)常使用的是微服務(wù)分層架構(gòu)。

畫外音：為什么要服務(wù)化，詳見《服務(wù)化到底解決什么問題?》。

隨著數(shù)據(jù)量不斷增大，吞吐量不斷增加，業(yè)務(wù)越來越復(fù)雜，服務(wù)的個(gè)數(shù)會(huì)越來越多，分層會(huì)越來越細(xì)，除了數(shù)據(jù)服務(wù)層，還會(huì)衍生出業(yè)務(wù)服務(wù)層，前后端分離等各種層次結(jié)構(gòu)。

不斷發(fā)現(xiàn)主要矛盾，抽離主要矛盾，解決主要矛盾，架構(gòu)自然演進(jìn)了，微服務(wù)架構(gòu)，潛在的主要矛盾會(huì)是什么呢?

引入微服務(wù)架構(gòu)，一般會(huì)引入一個(gè)RPC框架，來完成整個(gè)RPC的調(diào)用過程。

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

• RPC-client，它嵌在調(diào)用方進(jìn)程里
• RPC-server，是服務(wù)進(jìn)程的基礎(chǔ)

不只是微服務(wù)，MQ也是類似的架構(gòu)：

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

• MQ-send-client
• MQ-server
• MQ-recv-client

框架只是開始，越來越多和RPC，和微服務(wù)相關(guān)的功能，會(huì)被加入進(jìn)來。

例如：負(fù)載均衡

如果要擴(kuò)展多種負(fù)載均衡方案，例如：

• 輪詢
• 隨機(jī)
• 取模
• 一致性哈希

RPC-client需要進(jìn)行升級(jí)。

例如：數(shù)據(jù)收集

如果要對(duì)RPC接口處理時(shí)間進(jìn)行收集，來實(shí)施統(tǒng)一監(jiān)控與告警，也需要對(duì)RPC-client進(jìn)行升級(jí)。

畫外音，處理時(shí)間分為：

• 客戶端視角處理時(shí)間
• 服務(wù)端視角處理時(shí)間

如果要收集后者，RPC-server也要修改與上報(bào)。

又例如：服務(wù)發(fā)現(xiàn)

服務(wù)新增一個(gè)實(shí)例，通知配置中心，配置中心通知已注冊(cè)的RPC-client，將流量打到新啟動(dòng)的服務(wù)實(shí)例上去，迅猛完成擴(kuò)容。

再例如：調(diào)用鏈跟蹤

如果要做全鏈路調(diào)用鏈跟蹤，RPC-client和RPC-server都需要進(jìn)行升級(jí)。

下面這些功能：

• 負(fù)載均衡
• 數(shù)據(jù)收集
• 服務(wù)發(fā)現(xiàn)
• 調(diào)用鏈跟蹤
• …

其實(shí)都不是業(yè)務(wù)功能，所以互聯(lián)網(wǎng)公司一般會(huì)有一個(gè)類似于“架構(gòu)部”的技術(shù)部門去研發(fā)和升級(jí)相關(guān)功能，而業(yè)務(wù)線的技術(shù)部門直接使用相關(guān)框架、工具與平臺(tái)，享受各種“黑科技”帶來的便利。

理想很豐滿，現(xiàn)實(shí)卻很骨感，由于：

• RPC-client，它嵌在調(diào)用方進(jìn)程里
• RPC-server，是服務(wù)進(jìn)程的基礎(chǔ)

往往會(huì)面臨以下一些問題：

• 業(yè)務(wù)技術(shù)團(tuán)隊(duì)，仍需要花時(shí)間去學(xué)習(xí)、使用基礎(chǔ)框架與各類工具，而不是全心全意將精力花在業(yè)務(wù)和產(chǎn)品上
• client要維護(hù)m個(gè)版本， server要維護(hù)n個(gè)版本，兼容性要測(cè)試m*n個(gè)版本
• 如果要支持不同語言，往往要開發(fā)C-client，Python-client，go-client，Java-client多語言版本
• 每次“黑科技”的升級(jí)，都需要推動(dòng)上下游進(jìn)行升級(jí)，這個(gè)周期往往是以季度、半年、又甚至更久，整體效率極低

畫外音：兄弟，貴司推廣一個(gè)技術(shù)新產(chǎn)品，周期要多長(zhǎng)?

這些耦合，這些通用的痛點(diǎn)，有沒有辦法解決呢?

一個(gè)思路是，將服務(wù)拆分成兩個(gè)進(jìn)程，解耦。

• 一個(gè)進(jìn)程實(shí)現(xiàn)業(yè)務(wù)邏輯(不管是調(diào)用方，還是服務(wù)提供方)，biz，即上圖白色方塊
• 一個(gè)進(jìn)程實(shí)現(xiàn)底層技術(shù)體系，proxy，即上圖藍(lán)色方塊

畫外音：負(fù)載均衡、服務(wù)發(fā)現(xiàn)與治理、調(diào)用鏈…等諸多基礎(chǔ)設(shè)施，都放到這一層實(shí)現(xiàn)。

• biz和proxy共同誕生，共同消亡，互為本地部署，即上圖虛線方框
• biz和proxy之間，為本地通訊，即上圖黑色箭頭
• 所有biz之間的通訊，都通過proxy之間完成，proxy之間才存在遠(yuǎn)端連接，即上圖紅色箭頭

這樣就實(shí)現(xiàn)了“業(yè)務(wù)的歸業(yè)務(wù)，技術(shù)的歸技術(shù)”，實(shí)現(xiàn)了充分解耦，如果所有節(jié)點(diǎn)都實(shí)現(xiàn)了解耦，整個(gè)架構(gòu)會(huì)演變?yōu)椋?/p>

• 綠色為biz
• 藍(lán)色為proxy

整個(gè)服務(wù)集群變成了網(wǎng)格狀，這就是Service Mesh服務(wù)網(wǎng)格的由來。

架構(gòu)演進(jìn)，永無窮盡，痛點(diǎn)多了，自然要分層解耦。希望大家有收獲，后續(xù)再細(xì)聊SM的設(shè)計(jì)與架構(gòu)細(xì)節(jié)。

思路比結(jié)論更重要。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文