Service Mesh上線需解決的問題整理
引言
越來越多的公司開始研究Service Mesh，線上大批量應用案例的依舊很少，已經上線的很多問題解決的并不完美，為后面迭代和穩定性埋下隱患。目前來看整體開源生態成熟度還有需要完善，本文為筆者試水service mesh過程中發現的問題歸納整理。
一、目標與價值
業務側只需要引入輕量級SDK，其他基礎能力下沉到網格SideCar代理中，一個美好的愿望 “接管所有非業務關心的能力”。
1.業務賦能價值
提升開發效率：只需專注業務
加速業務探索：快速迭代上線、快速驗證
代理升級無感知：不需要費力推動業務升級或者通過卡點升級引起的各類問題
2.運維提效價值
- 治理體系統一：屏蔽不同語言體系治理的復雜性
- 技術演進統一：不必關心版本碎片化問題，能力統一自住演進
二、組織形態整合
如果將Service Mesh作為公司戰略推動，Service Mesh依賴Kubernate底座，相關人員最好整合到一個部門，統一運維和開發。
將Service Mesh團隊、Serverless團隊、容器團隊整合到一個部門負責云原生體系建設
其他部門配合改造和對接
三、技術問題
下面就使用最廣泛的Istio和Envoy為例就其線上運行需要解決的技術問題歸納整理。
1.注冊中心接入服務網格
實現目的： 公司已有的注冊中心接入服務網格(Istio)，完成服務注冊與發現能力
基本原理： 通過Istio提供的ServiceEntry將網格外注冊中心接入網格
https://mp.weixin.qq.com/s/4bTdmaQVKi8YHhBJCbrVKQ
2.RPC框架協議兼容問題
實現目的： 需要實現網格內外通信，那網格內的服務調用原有服務需要支持原有的RPC協議
基本原理： 與使用的RPC框架關聯，如果使用gRPC自研由于Istio原生支持HTTP/2則改動極小，如果使用dubbo或者自研RPC框架，可以通過EnvoyFilter轉換實現，可以參考騰訊開源框架 aeraki
https://github.com/aeraki-framework/aeraki
3.網格流量治理問題
實現目的： 網格流量需要支持限流、熔斷等治理能力并與現有治理平臺融合
基本原理： 通過Envoy提供的Filter插件機制，將限流配置與EnvoyFilter規則映射完成限流，可以參考網易開源的slime框架
https://github.com/slime-io/slime
4.網格流量監控問題
實現目的： 網格流量的監控指標和埋點需要與原有監控體系融合
實現原理： Istio提供了kiali、jaeger、grafana、prometheus相關監控體系，將這些這表對接到原有監控系統。另外一些自定義的監控指標可以通過wasm擴展。
https://mp.weixin.qq.com/s/ZO7dZ3mddISFjB4NTJHdjQ
5.按需訂閱配置(懶加載)問題
在默認情況下，Istio會全量下發注冊中心配置信息，占用過多的內存嚴重影響性能。常見的方案有：
社區SidecarScope的隔離
全局代理方案第一跳先去代理拿服務依賴的配置，之后不再需要跟代理通信(參考Slime提供的懶加載功能)
通過在SideCar中同時部署Agent的方式維護服務依賴關系
6.熱部署和升級問題
在對代理SideCar進行部署和升級時的處理，需要做到平滑先摘流量再部署升級。
進程級別代理方式，對數據面進行監控、版本管理和升級
雙容器模式，一個容器運行，另外一個容器Standby;Standby容器完成升級后檢測正常后再切換
依賴應用發布升級數據面
7.性能和穩定性問題
數據面代理會增加耗時，據螞蟻商業版本是數據面單跳延遲在0.5ms以內，平均為0.2~0.3ms
穩定性指標的測試
