引言

越來(lái)越多的公司開始研究Service Mesh，線上大批量應(yīng)用案例的依舊很少，已經(jīng)上線的很多問題解決的并不完美，為后面迭代和穩(wěn)定性埋下隱患。目前來(lái)看整體開源生態(tài)成熟度還有需要完善，本文為筆者試水service mesh過程中發(fā)現(xiàn)的問題歸納整理。

一、目標(biāo)與價(jià)值

業(yè)務(wù)側(cè)只需要引入輕量級(jí)SDK，其他基礎(chǔ)能力下沉到網(wǎng)格SideCar代理中，一個(gè)美好的愿望 “接管所有非業(yè)務(wù)關(guān)心的能力”。

1.業(yè)務(wù)賦能價(jià)值

提升開發(fā)效率：只需專注業(yè)務(wù)

加速業(yè)務(wù)探索：快速迭代上線、快速驗(yàn)證

代理升級(jí)無(wú)感知：不需要費(fèi)力推動(dòng)業(yè)務(wù)升級(jí)或者通過卡點(diǎn)升級(jí)引起的各類問題

2.運(yùn)維提效價(jià)值

• 治理體系統(tǒng)一：屏蔽不同語(yǔ)言體系治理的復(fù)雜性
• 技術(shù)演進(jìn)統(tǒng)一：不必關(guān)心版本碎片化問題，能力統(tǒng)一自住演進(jìn)

二、組織形態(tài)整合

如果將Service Mesh作為公司戰(zhàn)略推動(dòng)，Service Mesh依賴Kubernate底座，相關(guān)人員最好整合到一個(gè)部門，統(tǒng)一運(yùn)維和開發(fā)。

將Service Mesh團(tuán)隊(duì)、Serverless團(tuán)隊(duì)、容器團(tuán)隊(duì)整合到一個(gè)部門負(fù)責(zé)云原生體系建設(shè)

其他部門配合改造和對(duì)接

三、技術(shù)問題

下面就使用最廣泛的Istio和Envoy為例就其線上運(yùn)行需要解決的技術(shù)問題歸納整理。

1.注冊(cè)中心接入服務(wù)網(wǎng)格

實(shí)現(xiàn)目的： 公司已有的注冊(cè)中心接入服務(wù)網(wǎng)格(Istio)，完成服務(wù)注冊(cè)與發(fā)現(xiàn)能力

基本原理： 通過Istio提供的ServiceEntry將網(wǎng)格外注冊(cè)中心接入網(wǎng)格

https://mp.weixin.qq.com/s/4bTdmaQVKi8YHhBJCbrVKQ

2.RPC框架協(xié)議兼容問題

實(shí)現(xiàn)目的： 需要實(shí)現(xiàn)網(wǎng)格內(nèi)外通信，那網(wǎng)格內(nèi)的服務(wù)調(diào)用原有服務(wù)需要支持原有的RPC協(xié)議

基本原理： 與使用的RPC框架關(guān)聯(lián)，如果使用gRPC自研由于Istio原生支持HTTP/2則改動(dòng)極小，如果使用dubbo或者自研RPC框架，可以通過EnvoyFilter轉(zhuǎn)換實(shí)現(xiàn)，可以參考騰訊開源框架 aeraki

https://github.com/aeraki-framework/aeraki

3.網(wǎng)格流量治理問題

實(shí)現(xiàn)目的： 網(wǎng)格流量需要支持限流、熔斷等治理能力并與現(xiàn)有治理平臺(tái)融合

基本原理： 通過Envoy提供的Filter插件機(jī)制，將限流配置與EnvoyFilter規(guī)則映射完成限流，可以參考網(wǎng)易開源的slime框架

https://github.com/slime-io/slime

4.網(wǎng)格流量監(jiān)控問題

實(shí)現(xiàn)目的： 網(wǎng)格流量的監(jiān)控指標(biāo)和埋點(diǎn)需要與原有監(jiān)控體系融合

實(shí)現(xiàn)原理： Istio提供了kiali、jaeger、grafana、prometheus相關(guān)監(jiān)控體系，將這些這表對(duì)接到原有監(jiān)控系統(tǒng)。另外一些自定義的監(jiān)控指標(biāo)可以通過wasm擴(kuò)展。

https://mp.weixin.qq.com/s/ZO7dZ3mddISFjB4NTJHdjQ

5.按需訂閱配置(懶加載)問題

在默認(rèn)情況下，Istio會(huì)全量下發(fā)注冊(cè)中心配置信息，占用過多的內(nèi)存嚴(yán)重影響性能。常見的方案有：

社區(qū)SidecarScope的隔離

全局代理方案第一跳先去代理拿服務(wù)依賴的配置，之后不再需要跟代理通信(參考Slime提供的懶加載功能)

通過在SideCar中同時(shí)部署Agent的方式維護(hù)服務(wù)依賴關(guān)系

6.熱部署和升級(jí)問題

在對(duì)代理SideCar進(jìn)行部署和升級(jí)時(shí)的處理，需要做到平滑先摘流量再部署升級(jí)。

進(jìn)程級(jí)別代理方式，對(duì)數(shù)據(jù)面進(jìn)行監(jiān)控、版本管理和升級(jí)

雙容器模式，一個(gè)容器運(yùn)行，另外一個(gè)容器Standby;Standby容器完成升級(jí)后檢測(cè)正常后再切換

依賴應(yīng)用發(fā)布升級(jí)數(shù)據(jù)面

7.性能和穩(wěn)定性問題

數(shù)據(jù)面代理會(huì)增加耗時(shí)，據(jù)螞蟻商業(yè)版本是數(shù)據(jù)面單跳延遲在0.5ms以內(nèi)，平均為0.2~0.3ms

穩(wěn)定性指標(biāo)的測(cè)試