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
  • 稳定性指标的测试
浏览 26
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报