服务网格架构演进之旅
服务网格架构概述
服务网格(Service Mesh)是一个基础设施层,用于处理服务间通信,通过轻量级网络代理(如 Envoy)保证请求在复杂服务拓扑中可靠穿梭。当前服务网格架构已进入准成熟期,以 Istio 为代表,技术日趋成熟,生态逐步完善,产品百花齐放。
百度服务网格架构演进
百度服务网格架构经历了从传统微服务到服务网格 1.0 和 2.0 的演进:
- 传统微服务:依赖开发框架(bRPC、Spring Cloud)、通信协议(HTTP、gRPC)、开发语言(C++、Golang、Java)等,存在服务治理能力不统一、私有协议支持不足等问题。
- 服务网格 1.0:基于 Istio,实现统一服务网格,但原生模式对私有协议支持不足,对延迟敏感业务和 PaaS 环境存在挑战。
- 服务网格 2.0:定制化控制平面与数据平面,支持私有协议,融合 bRPC 与 Envoy,提供 Proxy 和 ProxyLess 模式,实现服务网格统一流量治理。
服务网格 2.0 架构特点
- 产品架构:采用托管控制平面、多实例管理、云原生网关、精细化流量管理、生命周期管理、链路追踪等核心组件。
- 多实例管理:多个租户共享一个 Kubernetes 集群,通过 workspaceID 表示身份,实现选择性服务发现与 WebhookConfiguration。
- 云原生网关:在并发数 4w 与 QPS 11w 场景下,Envoy 稳定性优于传统网关,性能与 Nginx 持平,长尾延时效果更好。
- 性能优化:通过 Aeraki 和 Slime 实现控制平面 xDS 按需下发,减少资源消耗;利用 BoringSSL 和 CryptoMB 实现 TLS 加速,QPS 整体提升约 30%-40%,平均请求时延降低 100%。
网格红利
- 安全管理:基于 SPIFFE 和 SPIRE 实现 SPIFFE 规范,支持跨网格/集群通信、证书轮换,兼容内部 PKI 基础设施。
- 环境复用:通过流量标记 HTTP header 中的 baggage 字段,匹配规则为 x-mesh-traffic-lane=环境名称,实现流量隔离,降低环境构建成本。
落地规模与收益
- 业务收益:内外客户核心产品线 Mesh 接入数 10+(如地图、搜索、百度健康等),在线 Mesh 实例数达 10 万+,每天 PV 流量超过万亿。
- 系统收益:大幅降低治理策略迭代成本,提升系统可用性和容灾能力,降低研发与测试成本。
未来展望
- 技术方向:探索 eBPF 和 Ambient Mesh 技术,适配国产化环境(ARM、PPC 芯片架构,统信 UOS、麒麟操作系统)。
- 产品拓展:以公有云 Mesh 为基座,支撑内部集团云与私有云,继续打磨“托管式、标准化、安全、稳定、易用、高扩展”的服务网格产品。
- 社区生态:继续拥抱开源,融入与共建服务网格社区生态,向开源社区贡献力量。
结语
架构不是一蹴而就的,只有能够赋能业务,架构才能有生命力。服务网格不会是微服务架构演进的终极方向。