Service mesh有啥意義？

大家經(jīng)常講ServiceMesh是第三代微服務(wù)治理體系，但是在一家公司的服務(wù)治理體系向Mesh遷移過(guò)程中，會(huì)遇到很多現(xiàn)實(shí)的問(wèn)題，比如增加了成本（開(kāi)發(fā)成本、改造成本、抑或其他），最終得到了什么樣的收益呢？

首先我覺(jué)得意義肯定還是有的，只不過(guò)對(duì)于不同發(fā)展階段和成熟度的團(tuán)隊(duì)意義大小不同。

先從一些業(yè)界微服務(wù)治理時(shí)代比較成熟的公司說(shuō)下。

比如美團(tuán)或者微博的mesh解決方案，主要解決以下幾個(gè)問(wèn)題：

1. 中間件與業(yè)務(wù)進(jìn)程強(qiáng)耦合，彼此制約迭代升級(jí)，引入成本問(wèn)題和穩(wěn)定性問(wèn)題；

2. 異構(gòu)體系難融合，主要是部門(mén)、組織服務(wù)治理體系不統(tǒng)一，成熟度也不同；

3. 比如美團(tuán)主要是java技術(shù)棧，其他語(yǔ)言的治理能力相對(duì)較弱；

微博情況類(lèi)似，java棧有了motan，但其他語(yǔ)言治理能力還不完善，也比較碎片。

所以這兩家推動(dòng)Mesh主要解決的問(wèn)題有三個(gè)：

1. 推進(jìn)多服務(wù)治理解決方案的統(tǒng)一與標(biāo)準(zhǔn)；

2. 解決多語(yǔ)言問(wèn)題；

3. 解決中間件升級(jí)與業(yè)務(wù)進(jìn)程解耦的問(wèn)題；

剩下的一些通用服務(wù)治理能力，比如：降級(jí)、染色、灰度、高可用、trace、metric、服務(wù)注冊(cè)與發(fā)現(xiàn)、熔斷、限流。這些并不是因?yàn)橐雖esh才具備的，如果原有的服務(wù)治理體系比較成熟，這些能力是必須存在的，并不是因?yàn)橛辛薽esh這些服務(wù)治理能力才有的。

比如美團(tuán)的Mesh解決方案，其實(shí)只需要解決業(yè)務(wù)進(jìn)程與服務(wù)治理進(jìn)程之間通信和解耦就可以了，畢竟美團(tuán)的服務(wù)治理體系還是比較完備的，控制面完全自研，數(shù)據(jù)面做簡(jiǎn)單的遷移即可。

總結(jié)下，對(duì)于這些公司我理解mesh主要是解決多語(yǔ)言、多服務(wù)治理體系的標(biāo)準(zhǔn)化。

再說(shuō)下技術(shù)層面的事情。

mesh上現(xiàn)在很多服務(wù)治理能力，其實(shí)在mesh之前的解決方案已經(jīng)存在了，比如之前可能是在proxy上、agent上。

mesh簡(jiǎn)單來(lái)說(shuō)是將之前proxy、agent的能力打散成分布式的proxy，這么看確實(shí)增加了一些維護(hù)成本與通信成本（具體怎么解決這部分成本后面聊）。

如果把原有的中心化proxy的能力打散下放到分布式的proxy里面，其實(shí)和我們常用的client、sdk解決方案又有些類(lèi)似了。

mesh解決方案又跑不掉和k8s、容器做進(jìn)一步集成。

這就給大家一種想法，既然原有的proxy或者sdk可以解決mesh可以解決的問(wèn)題，那改造又有一定成本，需要適配到k8s，那mesh是否是一個(gè)高投入低產(chǎn)出的事情呢？

我們脫離mesh現(xiàn)狀問(wèn)個(gè)問(wèn)題。

我們是否需要一個(gè)開(kāi)箱即用的服務(wù)治理能力？不管這部分能力是以產(chǎn)品、組件、工具的方式承接的。

如果有了這個(gè)能力可以幫助我們做好業(yè)務(wù)進(jìn)程與服務(wù)治理進(jìn)程的隔離，兩者獨(dú)立升級(jí)互不影響。

如果有了這個(gè)能力，所有語(yǔ)言或者服務(wù)治理體系都可以低成本實(shí)現(xiàn)非常高級(jí)和精細(xì)化的服務(wù)治理需求，而無(wú)需開(kāi)發(fā)成本。

我相信你一定會(huì)說(shuō)，我想要。

其實(shí)我們一直想要的服務(wù)治理能力是解耦的、標(biāo)準(zhǔn)化的、低成本的。

• 解耦：服務(wù)治理能力與業(yè)務(wù)處理進(jìn)程解耦，與語(yǔ)言無(wú)關(guān)，升級(jí)迭代方便；

• 標(biāo)準(zhǔn)化：所有語(yǔ)言、服務(wù)治理現(xiàn)狀都可以快速達(dá)到一個(gè)統(tǒng)一的服務(wù)治理階段，協(xié)議標(biāo)準(zhǔn)化、metric、日志等標(biāo)準(zhǔn)化；

• 低成本：業(yè)務(wù)研發(fā)不需要關(guān)注因?yàn)樯?jí)、迭代、維護(hù)，環(huán)境遷移帶來(lái)的成本（私有化部署、單體、微服務(wù)、云原生）；
  

正是因?yàn)楝F(xiàn)在的mesh解決方案沒(méi)有做到一鍵搭建或者開(kāi)箱即用，我們會(huì)覺(jué)得想要的收益和現(xiàn)有改造的付出不成正比，也就會(huì)質(zhì)疑mesh的價(jià)值與意義。

說(shuō)句題外話，其實(shí)我覺(jué)得私有化部署和云原生部署對(duì)于一款技術(shù)產(chǎn)品來(lái)說(shuō)一樣重要，云原生很性感，但是我覺(jué)得在未來(lái)的10年，私有化部署和云原生還是會(huì)對(duì)半開(kāi)，因?yàn)槭芟抻谛袠I(yè)、規(guī)范、以及各種法律的出臺(tái)，有些行業(yè)不能用云上產(chǎn)品，本地化的私有化部署一直存在需求，做好本地化部署將是產(chǎn)品的一大賣(mài)點(diǎn)。

而且私有化部署其實(shí)是一個(gè)技術(shù)考驗(yàn)，怎么將一個(gè)云端多容器具備cicd流水線的產(chǎn)品，快速低成本的部署到一臺(tái)內(nèi)網(wǎng)的4c8g的win7系統(tǒng)其實(shí)是個(gè)技術(shù)挑戰(zhàn)。

回過(guò)頭說(shuō)mesh。

上面提到這些mesh其實(shí)是基礎(chǔ)的服務(wù)治理能力。

有了mesh，很多企業(yè)會(huì)集成很多個(gè)性化的需求。比如流量染色的壓測(cè)、數(shù)據(jù)安全的管控，國(guó)際化業(yè)務(wù)如何與國(guó)內(nèi)做好隔離？saas系統(tǒng)之間如何做好不同租戶(hù)之間的隔離，既可以通過(guò)業(yè)務(wù)層面解決，也可以在mesh層面解決，我個(gè)人覺(jué)得隨著數(shù)據(jù)安全的要求越來(lái)越多，mesh層（流量層）還是要具備兜底能力的。

上面提到了，最開(kāi)始架構(gòu)從proxy轉(zhuǎn)變?yōu)閙esh的過(guò)程中，大家會(huì)疑惑會(huì)不會(huì)產(chǎn)生性能問(wèn)題？

mesh帶來(lái)的最大的改變是對(duì)流量的治理與管控，中間需要兩跳（業(yè)務(wù)進(jìn)程?->?sidecar?->?sidecar），這種延遲問(wèn)題其實(shí)現(xiàn)在慢慢解決了。比如最開(kāi)始的localhost通信，變成了UDS通信，現(xiàn)在又有了ebpf，性能上來(lái)了。sidecar之間可以通過(guò)協(xié)議優(yōu)化，比如采用quic/gRpc，長(zhǎng)鏈接、多路復(fù)用。但是學(xué)習(xí)和維護(hù)成本其實(shí)也是相應(yīng)的增加了，也就說(shuō)因?yàn)閙esh，其實(shí)我們又面對(duì)了新的問(wèn)題與新的挑戰(zhàn)。

第二個(gè)問(wèn)題是原有的一些proxy類(lèi)的、SDK的解決方案也不甘落后，也在迭代自己的解決方案了。比如gRPC開(kāi)始集成Istio的Control Plane了，并命名為Proxyless，也就是說(shuō)用了gRPC，你就具備了Istio的mesh能力了，那還需要從頭到尾做復(fù)雜的mesh改造嗎？

未必。

service mesh描繪了一種服務(wù)治理的終態(tài)，但現(xiàn)有的mesh解決方案并不是這種終態(tài)，所以mesh的投入與價(jià)值確實(shí)是一個(gè)值得討論的話題。