前言
服务网格在百度核心业务大规模落地实践 具体细节倒还好,比较有价值的就是提出了落地图景和理想化状态。
蚂蚁集团 Service Mesh 进展回顾与展望 提供了演进脉络。
考虑的问题
- 技术选型
- 性能问题和资源问题
- 网络接入:iptables 还是直通
- 性能优化:一跳还是两跳,面向失败设计,Service Mesh 可以 fallback 为直连模式。
- Sidecar自身会消耗资源,增加业务的成本。
- 随着Sidecar规模的增长,开源的控制平面计算开销变大,导致Mesh配置下发时间变长,甚至无法工作。
- 改造成本
- 各种各样的微服务框架网格化改造和适配
- 各种各样的通信协议支持
享受网格场景场景化能力
- 服务治理策略
- 延迟感知负载均衡,基于Server 响应时间进行流量调度,尽量多调度给延迟低的Server
- 错误码调权,基于自定义错误码进行Server 调权,加速异常Server 节点的驱逐
- 备份重试,通过定时触发备份重试请求优化长度,提高可用性
- 动态备份重试,按分位值动态设置备份重试请求触发时间,支持备份重试请求熔断,防止重试风暴。
- 流量丢弃/全局流控,在线实施配置流量丢弃比例,摘除下游,提供统一流控预案
- 超时透传,实时透传上游超时给下游,帮助业务实现动态TTL机制
- trace 平台和监控平台
- 自动止损 ==> 稳定性预案平台, 根据监控平台的指标异常实时调参,执行流量降级、切机房、切流等 ==> 反馈到监控平台 ==> 稳定性预案平台继续调参, 实现闭环
- 混沌工程 深度解读:分布式系统韧性架构压舱石OpenChaos
- 系统容量评估(压测)
通过接入Mesh服务网格得到的一些启示:
- 服务网格不是微服务治理的银弹
- 完全无入侵的,支持所有协议,所有框架和所有治理策略的 Mesh 方案是不存在的
- 大规模工业化落地的平滑、稳定可控接入方案,涉及到大量对已有服务治理组件的兼容升级和改造
- 服务网格确实实现了业务逻辑和服务治理架构的解耦,解锁了很多新能力
- 服务网格结合可观测、故障止损、混沌工程,容量管理等场景化,才能发挥出最大价值
规范
SMI 和 UDPA 的关系与我在容器运行时中介绍到的 CRI 和 OCI 规范之间的关系很相似。
- SMI 规范提供了外部环境(实际上就是 Kubernetes)与控制平面交互的标准,使得 Kubernetes 及在其之上的应用,能够无缝地切换各种服务网格产品;SMI 与 Kubernetes 是彻底绑定的,规范的落地执行完全依靠在 Kubernetes 中部署 SMI 定义的 CRD 来实现。包括四方面的 API
- 流量规范(Traffic Specs),目标是定义流量的表示方式,比如 TCP 流量、HTTP/1 流量、HTTP/2 流量、gRPC 流量、WebSocket 流量等应该如何在配置中抽象和使用。
- 流量拆分(Traffic Split),目标是定义不同版本服务之间的流量比例,提供流量治理的能力,比如限流、降级、容错,等等,以满足灰度发布、A/B 测试等场景。
- 流量度量(Traffic Metrics),目标是为资源提供通用集成点,度量工具可以通过访问这些集成点来抓取指标。这部分完全遵循了 Kubernetes 的Metrics API进行扩充。
- 流量访问控制(Traffic Access Control),目标是根据客户端的身份配置,对特定的流量访问特定的服务提供简单的访问控制。
- UDPA 规范则提供了控制平面与数据平面交互的标准,使得服务网格产品能够灵活地搭配不同的边车代理,针对不同场景的需求,发挥各款边车代理的功能或者性能优势。
技术决策案例
欢乐游戏 Istio 云原生服务网格三年实践思考从笔者个人的观察来讲,istio 网格最具吸引力的,实际上就两点:
- 开放技术栈的想象空间,随着 istio、envoy、gRPC 整个生态越来越丰富,未来可能会有更多能力提供,开箱即用,业务团队不必投入开发;
- 多语言适配,不用为每种语言开发治理 sdk,例如 C++ 编写的 envoy 可以给所有用 gRPC 的 service 使用。 至于熔断、限流、均衡、重试、镜像、注入,以及 tracing 监控之类的能力,严格来讲不能算到网格头上,用 sdk 也是一样可以实现的。在团队语言统一的时候,只用维护一种语言版本的 sdk,此时采用治理 sdk 方案也是可行的,也就是所谓的微服务框架方案。采用 sdk 方式下的版本维护问题,以及后期进一步演进网格的问题,这些都不难解决。对于我们自己来讲,因为恰好有引进 golang 以及 gRPC,所以现在再看,选择 istio 作为网格方案也算合适。
接入网格,要考虑天时地利人和。即,需要满足一些基本条件:
- 需要项目阶段允许,如果团队本身一直在做快版本内容迭代,业务需求都忙不过来,恐怕也很难有人力保障。
- 要有基础设施环境支持(我们使用了腾讯云的 tke mesh 服务),这样不至于所有东西都从零开始。
此外,对于这类大的技术优化,还有必要先统一思想:
- 自上而下,获得各级管理干系人的认可,这样才好做较大人力的投入。
- 自下而上,发动同学们深度介入探讨,使得整体的方向、方案得到大家的认可,这样大家才有干劲。