FA9# Service Mesh上线需解决的问题整理
共 1538字,需浏览 4分钟
·
2022-01-29 23:35
引言
越来越多的公司开始研究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
- 稳定性指标的测试