前言
服务网格在百度核心业务大规模落地实践 具体细节倒还好,比较有价值的就是提出了落地图景和理想化状态。
考虑的问题
- 技术选型
- 性能问题和资源问题
- 网络接入: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 规范则提供了控制平面与数据平面交互的标准,使得服务网格产品能够灵活地搭配不同的边车代理,针对不同场景的需求,发挥各款边车代理的功能或者性能优势。