Service Mesh 在百度的落地实践及思考
如果无法正常显示，请先停止浏览器的去广告插件。
1. Service Mesh 在百度的
落地实践及思考
陈鹏
2. 讲师简介
陈鹏 | 百度
资深研发工程师
ee.msup.com.cn
2019-至今 百度 Service Mesh 从0到1的大规模落地研发和实践
2017-2018 百度检索系统 PB 级 Table 存储研发
2015-2016 百度搜索在线系统 PAAS 研发
3. 目录
• 百度服务治理现状 & Istio 落地的挑战
• Istio 在百度生产环境大规模落地的实践分享
• 实践思考 & 落地 Mesh 的一些建议
ee.msup.com.cn
4. 百度 Service Mesh 编年史
2019年：基于 Istio + Envoy 深度研发，多个核心业务大规模落地
拥抱开源
2018.07：Istio 1.0版本发布，可用于生产环境
2017年：自研 Service Mesh 系统 BMesh，控制面 + 数据面 均采用 Go 语言实现，搜索服务前端模块上线
跟进社区
2016.09：Service Mesh 概念首次提出
内部探索
2016年初：百度网盘UFC系统，Proxy + 控制中心设计，超大规模落地，实例数20w，千亿PV
2013年：搜索并行服务系统，开始研发独立的 proxy 代理流量，大规模服役，Service Mesh 在百度的萌芽
ee.msup.com.cn
5. 为什么要引入 Service Mesh
• 多语言技术栈能力不统一
•
•
•
•
C++：bRPC
Java: Spring Cloud
PHP: RAL
Go: GDP
• 服务治理周期长
• lib库和业务进程耦合
• 上线周期长、推动困难,策略调整周期长达数月
• 产品能力弱
• 以配置文件为主
• 可视化能力弱,缺乏平台化和产品化能力
ee.msup.com.cn
6. Istio 落地的遇到的最普遍问题
• Istio 原生几乎只支持 HTTP 协议
• Envoy 虽然支持部分其他协议，如 thrift，dubbo 等，但存在一些问题
• 这些协议的 netwrok filter 功能都比较弱，如不支持高级的 content based routing 等
• 控制面 Istio 中 VirtualService 不支持非 HTTP 协议的策略配置，只能通过 EnvoyFilter
下发，体验不好
• Istio 几乎只能在 K8S 环境运行良好
• 最新版本 Istio 虽然支持了虚拟机，但支持程度有限
• Istio 无法自动 watch 非 K8S Service 资源，需要手动或其他系统生成 ServiceEntry /
WorkloadEntry 资源
• Sidecar 注入和管理困难，需要 PaaS 适配
ee.msup.com.cn
7. Istio 在生产环境落地面临的更多问题
• 产品能力
• 稳定性，性能问题
• 服务发现集成，框架支持
• 生产级流量调度策略缺失，私有协议支持
• Sidecar 注入，大规模 Sidecar 管理
• K8S 依赖
ee.msup.com.cn
8. 如何处理 Istio 对 K8S 的深度依赖
• Sidecar 注入和管理
• K8S：透明注入提升用户接入体验
• 解法：升级内部 PaaS，支持 Sidecar 模式
• Istio配置存储
• K8S：各类流量策略 CRD，通过 Api Server + Etcd 读写
• 解法：予以保留，独立部署 K8S Api Server + Etcd 两个组件
• 服务和流量模型
• K8S：容器网络， ClusterIP， Iptables流量劫持
• 解法：研发新的流量劫持模式
ee.msup.com.cn
9. 基于 Naming 系统的流量劫持
Sidecar正常
Sidecar故障
Heartbeat
Naming
Agent
1 伪装注册 <Provider: 127.1.1.1:8000>
Envoy
4 服务发现 <Provider: 10.1.1.2:3000/3001>
5. Request 10.1.1.2:3000/3001
Listen 127.1.1.1:8000
Envoy
Listen 0.0.0.0:3001
3 Request Provider
2 服务发现 <Provider: 127.1.1.1:8000>
Consumer Provider
Listen 127.1.1.1:8000 Listen 0.0.0.0:3000
直连模式
<Provider: 10.1.1.2:3000>
pod1: 10.1.1.1
高性能
没有 Iptables 处理开销，额外延时 < 0.2ms
Envoy 内存占用低，使用Sidecar CRD，XDS 数据量 O(N) -> O(1)
Inbound 流量劫持可选(绝大部分策略集中在 Outbound)
使用支持主机网络 / 动态端口等生产环境
ee.msup.com.cn
pod2: 10.1.1.2
可回滚
Sidecar 故障秒级切回直连
业务方放心接入 Mesh
10. Envoy 和 bRPC 内核动态切换
Envoy 优点
灵活 Filter 扩展机制
XDS 动态配置分发
ee.msup.com.cn
bRPC 优点
高性能用户态线程
优秀的 IO 机制
11. 延时和开销大幅降低
8k qps 延时
1ms -> 0.2ms
ee.msup.com.cn
8k qps CPU
2.5 -> 0.9
12. 问题：
Isito 不支持业务线的私有协议怎么办？
Istio 不支持业务线在用的高级服务治理策略怎么办？
ee.msup.com.cn
13. 扩展支持私有协议和高级策略
私有协议支持 高级策略
全面支持baidu std / nshead / http / dubbo BackupRequest / DynamicBP：快速重试 优化长尾
私有协议自动嗅探 LocalityAware / LocalityAwarePlus：综合吞吐、延时、错误
码计算权值的智能负载流量更均匀
降低业务接入成本 赋能其它框架 / 语言
接入 Mesh 不会造成能力缺失
策略实时生效 提升服务治理效率
ee.msup.com.cn
Sidecar 模式 策略天然和框架及语言无关
一次实现 所有框架和语言复用
14. Istio原生产品能力缺失
VirtualService.yaml
DestinationRule.yaml
ServiceEntry.yaml
Sidecar.yaml
EnvoyFilter.yaml
Gateway.yaml
PeerAuthentication.yaml
…
Istio CRD众多
Kiali 能力较弱，不易扩展和集成其它基础设施（账户、权限、审计等）
Cloud Native = yaml工程师
ee.msup.com.cn
15. 自研内部产品 - 服务治理
丰富的服务治理策略
易用的UI体验
ee.msup.com.cn
16. 自研内部产品 – 运维管理
机房切流
链路级服务网格开关
快速故障止损
ee.msup.com.cn
17. 自研内部产品 – 版本管理
所有操作可溯源
一键回滚至任一版本
ee.msup.com.cn
18. Mesh 落地后的更多价值
有了 Mesh 之后我们还能做什么？
Mesh 使整个服务网络变得可编程
因此，我们可以基于 Mesh 做更多的事情
ee.msup.com.cn
19. 平台化能力
Mesh 使整个服务网络变得可编程
因此，我们可以基于 Mesh 做更多的事情
A PP1
A P P 2-1
混沌
平台 容量
平台
控制
平面 控制
平面
边车
A P P 2-2
A PP1
A P P 2-3
边
车
A P P 2-2
A P P 2-1
混沌工程 容量压测
混沌平台负责调度任务、效果评估
服务网格负责故障注入 容量平台负责发起评估任务、评估效果
服务网格负责实施流量调度
ee.msup.com.cn
20. 线上效果 - 可用性提升
ee.msup.com.cn
21. Service Mesh 落地全景图
ee.msup.com.cn
22. 落地规模及收益
业务线
手机百度
Feed
规模
服务：数千个
实例：10w
流量：千亿
收益
跨语言统一服务治理能力
服务可用性提升
百度地图 服务治理周期：月级 -> 分钟级
搜索 变更效率提升：10X
商业广告系统 服务治理体验提升
ee.msup.com.cn
23. 思考：Service Mesh 落地的核心要素
务实 性能
适配公司基础设施
实现生产线服务治理策略 极致性能优化
打消业务方性能顾虑
让业务方能低成本
接入 Mesh
稳定 体验
完善监控
链路级 Mesh 开关
Sidecar 故障自动秒级回滚 平台化
产品化
拒绝做 yaml 工程师
让业务方敢大规模
接入 Mesh
ee.msup.com.cn
让核心业务能
接入 Mesh
让业务方觉得
Mesh 好用
24. 思考：关于需不需要引入 Mesh
不一定要引入 Mesh 的场景
• 业务几乎都是单语言，有成熟的框架提供服务治理能力（如 Java + SpringCloud）
• 治理策略变更不频繁，可以通过上线解决
• 框架升级不频繁，不会和业务升级相互耦合、影响
引入 Mesh 反而会带来技术复杂度和性能开销
适合引入 Mesh 的场景
•业务场景跨多语言，各语言框架服务治理能力不统一，对业务整体可用性造成影响
•策略变更频繁，有动态服务治理的强需求
•框架迭代频繁，需要和业务解耦
•想基于 Mesh 做更多上层的服务治理场景（混沌、智能调参、容量压测等），需要整个网络通信层可编程
•业务规模庞大，需要一种可复制的基础设施，满足规模化服务治理需求
引入 Mesh 可以解决若干痛点问题，提升效率
ee.msup.com.cn
25. 思考：引入 Mesh 的成本
几乎没有成本的场景 有一定成本的场景
•业务是 HTTP 协议
•托管在原生 K8S 上
•业务本身是长耗时请求，或对 Mesh 引入的
延时可以容忍（2ms） •有私有协议（开发 NetworkFilter，控制面 API 支
持）
•托管在 K8S + 虚拟机（手动生成管理虚拟机相关
CRD 资源，解决 Sidecar 注入和管理问题）
基本可以直接接入 需要一定的研发人力支持
高成本的场景
•业务规模大，大量私有协议需要开发支持
•托管在 K8S + 虚拟机 + 无容器网络 + 私有注册中心（还需要额外处理流量劫持问题）
•大量业务高级流量调度策略（需要开发支持）
•对性能、延迟有要求（需要深入优化 Isito + Envoy 性能）
•服务配置需要权限控制、审计，有用户体验要求（需要一个产品团队开发上层产品）
需要一定规模的研发+产品团队支持
ee.msup.com.cn
26. 欢迎大家线下交流
ee.msup.com.cn
27. 关注msup公众号
获取更多工程效能实践案例