Service Mesh 在百度大规模落地实践

如果无法正常显示，请先停止浏览器的去广告插件。

1. 百度服务网格架构演进之旅百度云原生-陈谭军

3. 目录  服务网格架构  百度服务网格架构演进之旅  服务网格架构总结与展望

4. 调查调查1 未使用 Kubernetes 管理业务应用？调查2 未落地 Service Mesh 进行服务治理？

5. 服务网格架构

6. 服务网格服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用中，服务网格通常是由一系列轻量级的网络代理组成，它们与应用程序部署在一起，但对应用程序透明。基础设施稳定可靠网络代理应用透明

7. 服务网格服务网格架构开始进入准成熟期，以 Istio 为代表的服务网格在国内基本上是事实上的标准特点 • • • • • 市场更加理性技术日趋成熟回归价值本身生态逐步完善产品百花齐放

8. 百度服务网格架构演进之旅

9. 演进路线传统微服务 • 开发框架 bRPC、SpringCloud 等 • 通信协议 HTTP、gRPC、私有协议等 • 开发语言 C++、Golang、Java 等服务网格1.0 • 拥抱开源，基于 Istio 进行定制化开发，数据平面融合 Envoy 与 bRPC，提升转发性能 • 基于 bRPC，数据平面同时支持 Proxy 与 ProxyLess 模式，服务网格统一服务流量治理服务网格2.0 • 统一与融合公有云与集团云服务网格 • 基于 Istio，发布私有云服务网格

10. 服务网格 1.0 VIP Controller (127.0.0.1, 127.255.255.254) Console 定义 Link <Consumer, Provider> 直连模式 1.生成带 VIP 的 Link Sidecar 模式心跳检测高性能 Istiod 定义 Link <Consumer, Provider, 127.1.1.1> 适配内部基础设施没有 Iptables 消耗劫持性能好 2.xDS 推送 Link 信息心跳检测 Naming Agent 3.1 注册<Provider, 127.1.1.1:8000, PodX> 3.2 Naming 解析<Provider, 10.1.1.2:3001> 4.1 请求 <Provider, PodX> 4.2 返回<Provider, 127.1.1.1:8000> 返回 <Provider, 10.1.1.2:3000> 数据面 Envoy 6.请求 10.1.1.2:3001 127.1.1.1:8000 Envoy 0.0.0.0:3001 5.请求 Provider Naming Lib Consumer 10.1.1.1 Pod X 直连模式 Provider 0.0.0.0:3000 10.1.1.2 Pod Y 可回滚 Sidecar 故障可秒级切换保证业务接入 Mesh

11. 服务网格 1.0 私有协议措施原生模式 HTTP 是第一等公民服务延迟发现敏感内部服务发现 PaaS 原生网络代理带来的延迟难以接受环境无容器网络、内部无法使用 Iptables 等 • 对于私有协议，通过修改代码抽象(超时、重试、请求路由、负载均衡等)通用能力，支持新的私有协议，只需要实现相对应的 Codec 编解码 • 对延迟非常敏感的业务，融合 Envoy 与 bRPC 提供 Proxy 模式、基于 bRPC 提供 ProxyLess 模式 • 对于 Sidecar 管理与注入，升级内部 PaaS 支持 Sidecar 模式 • 对于流量劫持，通过 Envoy 联动 Naming Agent(服务发现系统) 研发新的流量劫持模式 • ……

12. 服务网格 2.0 插件式拓展控制平面与数据平面定制化控制平面与数据平面侵入式支持私有协议依赖内部基础设施，服务发现等场景化功能，Mesh 开关、bRPC 等中间态原因 • • • • 微服务治理社区标准化稳定数据平面性能加速低运维与产品易用微服务安全性目标态业务 One Cloud 全面上云、内外资源共池、软硬一体内外融合大背景资源分时弹性复用、统一库存共存、提升资源效能，加速业务 TOB 化建设侵入式、定制化、严重依赖内部基础设施等原有内部 Mesh 服务网格架构模式在百度智能云不适用统一云平台、减少重复投入，完善百度智能云云原生微服务产品矩阵，赋能内外部客户

13. 产品架构 Baidu Cloud 核心组件托管 xds 请求 Sidecar App 1 托管网格 Gateway Istiod CRD 配置管理生命周期管理链路追踪 Prom 监控精细化流量管理零信任安全日志服务多集群管理 xds Istiod Sidecar xds 请求 App 2 Kubernetes 独立网格 Gateway xds Sidecar Sidecar App 1 App 2 Kubernetes

14. 托管控制平面 endpoint endpoint 7.0.0.8 Istiod …… LoadBalancer xds xds Meta Cluster endpoint traffic xds xds APIServer Sidecar sleep traffic 北京集群 A Sidecar helloworld Sidecar sleep Gateway APIServer Gateway Sidecar helloworld 苏州集群 B

15. 多实例管理

16. 多实例管理 xds istio-system-aaa istio-system-bbb Istiod Istiod …… traffic 实现原理 • xds xds xds 对应账户的若干 ns • Sidecar Service A traffic ns1 workspaceID=aaa Sidecar Service B ns2 使用选择性服务发现与 WebhookConfiguration 只作用于 Sidecar Service C traffic Sidecar Service D workspaceID=bbb 集群所有 Istiod 共用一个集群粒度的中间证书 ns3 核心特点 • 多个租户会共享一个 k8s 集群，而非一个租户独占一个 k8s 集群 • 租户通过命名空间中 workspaceID 表示身份 • 集群中的多个网格实例对应的 Istiod，安装在独立的 ns

17. 云原生网关

18. 云原生网关 blb-nginx Envoy 在并发数 4w 与 QPS 11w 的前提下，blb-nginx 在后端服务滚动升级期间，超时数量明显增加而 Envoy 只是瞬间出现超时

19. 云原生网关长连接 p99(ms) 长连接 QPS 1,200 25,000 20712 19306 20,000 19872 15652 1,000 800 14619 15,000 10,000 19236 1020 736 624 600 10832 11061 10525 400 5,000 340 410 200 48 0 500 1000 0 2000 blb-nginx ingress-nginx 56 54 49 500 1000 blb-nginx envoy ingress-nginx 2000 envoy 短连接 QPS 10,000 8945 9,000 8,000 7,000 6,000 5354 3,000 2,000 3380 2698 • 4966 5,000 4,000 总结 7168 3356 2907 1993 500 统网关，性能整体与 Nginx 持平，但长尾延时效果要好 1,000 0 高并发场景下，Envoy 在配置变更期间稳定性优于传 1000 blb-nginx 2000 ingress-nginx envoy

20. 云原生网关 Istiod xds xds Gateway traffic LoadBalancer traffic 选型 Envoy • 性能和配置变更稳定性明显优于传统网关 • 具有原生功能丰富、可观测性、社区开源、易扩展等特性 xds App 1 Sidecar App 2 • 合理架构，控制平面与数据平面分离 • 统一技术栈与流量管控、资源复用特点 APIServer 北京集群 A • 高性能、低成本 • 纯托管免运维，更好的 SLA 保障 • 丰富的路由策略、灰度治理、可观测性等

21. 性能优化

22. 控制平面 - xDS 按需下发现状 • xDS 数据量的大小和网络规模成正相关，在大规模场景下，会带来较多的网络性能损耗 • 手动配置 Sidecar CRD 依赖用户梳理服务间的依赖关系，较为困难与复杂方案 • Aeraki 提供 Lazy Sidecar 自动根据上下游调用关系下发 Sidecar，仅将需要的 xDS 推送到数据平面，以减少资源消耗 • Slime 使用自定义 CRD 自动分析上下游依赖关系并将其转换成 Sidecar 下发给控制平面，实现 xDS 按需下发，解决配置全量下发问题

23. 控制平面 - xDS 按需下发 APIServer 2,8 reconcile 3,9 watch CRD 资源 LazySidecar Controller Istiod 1 注入 sidecar 4,10 xDS 配置推送 Sidecar Nginx 6 HTTP 上报调用关系 Gateway 5 首次请求 7 首次请求 Sidecar Service A 11 后续请求 Sidecar Service B 优势 • 用户不需要手动配置服务间的依赖关系，服务间调用依赖关系是完全自动生成与配置的。 • Envoy 只会获得自身相关的 xDS 配置，性能优越。 • 对 Istio 和 Envoy 无任何定制化修改，可拓展性与可维护性强。 • 无需依赖 access log 或监控组件获取调用关系。

24. 数据平面 - TLS 加速 privateKeyProvider : CryptoMB xds Envoy BoringSSL privateKeyProvider Istiod 前提 xds TLS Envoy BoringSSL xds TLS Envoy BoringSSL privateKeyProvider privateKeyProvider App1 App2 Pod Pod Pod TLS • Envoy 1.20+ 或者 Istio 1.14+ • 利用第三代 Intel® 至强® 可扩展处理器指令 AVX512、Envoy 中的 CryptoMB Private Key Provider 以及 Istio 中使用 ProxyConfig 配置实现 Envoy TLS 加速

25. TLS 加速 QPS 平均时延(ms) 900 857 800 685 700 400 1400 1200 531 475 500 1620 1600 727 600 1800 988 1000 372 795 800 300 600 200 400 100 200 0 0 1000 2000 4000 加速前加速后 QPS 整体提升约 30%-40% 平均请求时延降低 100%+ 387 361 60 1000 2000 4000 加速前加速后

26. 网格红利

27. 安全管理基础概念 • 零信任安全：代表新一代的网络安全防护理念，关键在于打破默认的“信任”，就是“持续验证，永不信任”。 • SPIFFE：提供了覆盖身份、身份证书的类型以及创建、管理和颁发方式的定义，贯彻了零信任的安全模型，为构建基础设施提供了标准框架。 • Istio：Citadel 实现了 SPIFFE 规范，数据格式由 Istio 自己实现，通信格式采用 xDS(SDS) 协议规范。 • SPIRE：实现基础设施 SPIFFE 规范，使用服务端与代理的分级策略采用概念威胁模型，尽可能地提升安全性和降低威胁带来的影响。SPIFFE 和 SPIRE 都是 CNCF 的孵化沙箱项目。具体实现中包含 SPIRE Agent、SPIRE Server。 • SVID：是工作负载向资源或调用者证明其身份的文件。SVID 包含一个 SPIFFE ID，代表了服务的身份。 • PKI：(Public Key Infrastructure) 即公开密钥体系，PKI 技术就是利用公钥理论建立的提供信息安全服务的基础设施。

28. 安全管理 Root CA Intermediate CA Intermediate CA Workload Workload Workload Workload Workload Workload Cluster A Cluster B

29. 安全管理 PKI 基础设施优势 k8s-workload-registar k8s-workload-registar UpstreamAuthority UpstreamAuthority 有了共同的信任根，集 Spire Server 群之间就可以互相验证 Spire Server • 支持跨网格/集群通信：身份，进而实现跨集群通信 Spire Agent Spire Agent Spire Agent Spire Agent • 轻松实现证书轮换：可 SDS API SDS API SDS API SDS API 以按集群/网格实现证 x.509 SVID x.509 SVID x.509 SVID x.509 SVID UDS UDS UDS UDS Envoy Envoy Envoy Envoy Workload Workload Workload Workload Cluster A Node 1 Cluster A Node 2 Cluster B Node 1 Cluster B 书轮换，而不是轮换根节点证书，减少停机时 Node 2 间 • 兼容内部 PKI 基础设施，完成服务认证

30. 环境复用问题服务服务服务配置服务应用更新 • 某个公有云内部业务产品迭代频繁，内部调用关系日趋复杂，构建线下环境的任务越来越繁重服务配置服务服务配置更新应用更新 • 多套闭环环境构建成本高、维护难度大 • 环境问题严重降低工程效率，增加人力成本服务配置更新需要维护完整环境的应用更新和上下游调用关系配置

31. 环境复用未携带流量标识的用户流量 Service A Sidecar 携带 v1 标识的用户流量 Service B Sidecar Service C Sidecar Service D Sidecar Service B v1 Service D v1 Sidecar Sidecar 实现原理收益 • 流量标记 HTTP header 中的 baggage 字段，匹配规则 • 大幅降低特性环境构建成本，提升问题排查效率是 x-mesh-traffic-lane=环境名称 • 利用 Istio 路由功能中的流量匹配规则和转发能力 • 只需要维护每次需求用到的模块，系统根据流量标识，处理上下游调用关系

32. 落地规模与收益业务 • 内外客户核心产品线 Mesh 接入数 10+，如地图、搜索、百度健康、外部客户等 • 在线 Mesh 实例数达 10 万+，每天 PV 流量超过万亿收益 • 大幅降低治理策略迭代成本与周期，从数月缩短到天级别、甚至分钟级别 • 系统核心可用性和整体容灾、防雪崩能力得到提升 • 降低研发与测试成本，提升工程效能 • 协同其它基础设施系统，极大提升系统稳定性与可用性

33. 回顾运维管理托管控制平面性能网关云原生网关多实例管理优化网格控制平面红利数据平面服务安全业务收益落地规模未来计划与探索私有协议延迟服务可拓展式支持私有协议，如 Aeraki 等发现非侵入式支持其它注册中心敏感业务 bRPC Sidecar bRPC ProxyLess eBPF 场景赋能更多业务解锁高级红利提升稳定性

34. 整体架构地图应用场景服务治理 Feed 商业搜索环境复用服务观测百度内部云服务网格产品混顿工程手百容量管理外部客户灰度发布 …… …… 公有云服务网格产品私有化微服务产品服务发现协议支持 HTTP baidu-std 协议可拓展架构基础设施 BNS 框架支持 bRPC ODP 框架 SDK/探针权限系统 Consul Zookeeper …… PaaS 平台 Istiod Sidecar Sidecar App ProxyLess App 监控系统调用链系统

35. 服务网格架构总结与展望

36. 抛砖引玉业务存在跨语言、跨框架、服务治理能力不统一服务治理策略变更频繁、有动态服务治理的需求问题问题想基于 Mesh 做更多上层的服务治理场景，需要整个网络通信层可编程、零信任等微服务开发框架迭代频繁、需要和业务解耦

37. 抛砖引玉只有适合内部基础设施的架构才是最优之选，合适的架构是第一选择求实 Mesh 代理不能有很大的网络延迟，性能是第一要素性能 Mesh 是否有劫持流量开关、代理故障可自动回滚、业务生产稳定可用是第一原则平稳 Mesh 作为基础设施，对于业务来说，产品易用是第一印象需要协同周边生态，如 PaaS、可观测性等，才能更好地为业务服务，发挥第一优势易用生态 • 拥抱开源，不等于开箱即用，需要适配公司基础设施，如 PaaS、服务框架等。 • Service Mesh 不是万能钥匙，完全无侵入、支持所有协议、拥有各种高级治理策略的服务网格方案是不存在的。 • 业务 Mesh 化改造确实能带来很多的收益，解锁各种高级能力，这是传统微服务不能满足的，但是需要协同其它基础设施，才能发挥出最大价值。

38. 未来展望 eBPF eBPF（extened Berkeley Packet Filter）是一种内核技术，它允许开发人员在不修改内核代码的情况下运行特定的功能。常用于网络监控、安全过滤、性能分析、网络加速和虚拟化等多种应用场景。 Ambient Mesh Ambient Mesh 这是 Istio 提供的一种新的数据平面模式，旨在简化操作，提供更广泛的应用兼容性，并降低基础设施的成本。国产化考虑到业务会运行在各类国产化环境，服务网格架构整个技术体系需要适配与兼容 ARM 和 PPC 等芯片架构、统信 UOS 和麒麟等国产操作系统社区生态社区生态竞争激烈与日益繁荣，控制平面与数据平面或许逐渐标准化、通用化，目前来看在国内 Istio 还是独占鳌头。 ……

39. 未来展望内部云 Mesh (地图、大商业) 公有云 Mesh (对接公有云生态) 私有云 Mesh (客户定制拓展) 拓展机制(服务发现、多协议、服务高级治理策略等) 应用场景流量治理服务安全服务观测多协议通信容量管理灰度发布 …… • 以公有云 Mesh 为基座，支撑内部集团云与私有云，继续打磨“托管式、标准化、安全、稳定、易用、高扩展” 的服务网格产品 • 继续拥抱开源，融入与共建服务网格社区生态，向开源社区贡献力量 • ……

40. 结语架构不是一蹴而就的，只有能够赋能业务，架构才能有生命力。 Service Mesh 不会是微服务架构演进的终极方向。

41. 感谢聆听