《5.首届eBPF大会_eBPF技术在服务网格场景应用经验总结与展望.pptx》由会员分享,可在线阅读,更多相关《5.首届eBPF大会_eBPF技术在服务网格场景应用经验总结与展望.pptx(10页珍藏版)》请在三个皮匠报告上搜索。
1、首届中国首届中国eBPFeBPF研讨会研讨会eBPF技术在服务网格场景应用经验总结与展望首届中国首届中国eBPFeBPF研讨会研讨会服务治理发展历程服务治理发展历程第一代:第一代:服务治理能力内嵌在业务代码中典型技术:SOA、ESB第二代:第二代:服务治理能力抽象到统一SDK实现典型技术:Spring Cloud、Dubbo第三代:第三代:服务治理能力归一到服务网格Node 1服务1业务逻辑服务治理Node 2服务2业务逻辑服务治理服务总线服务发现负载均衡熔断容错动态路由优势优势 简单使用依赖少 代码重复少 治理逻辑代码和业务代码分开 独立进程,用户业务非侵入、语言无关 治理逻辑升级业务无感知
2、 可以渐进的微服务化劣势劣势 代码耦合 代码重复高 运维复杂 解耦差,开发要求高 SDK语言绑定、代码侵入 基于SDK开发学习门槛高 在用系统改造代价大 治理能力升级影响用户业务 代理的性能和资源开销Node 1服务1自身业务SDK服务治理Node 2服务2自身业务SDK服务治理服务总线服务发现负载均衡熔断容错动态路由Node 1服务1自身业务服务网格服务网格服务治理Node 2服务2自身业务服务网格服务网格服务治理通信基础服务发现负载均衡熔断容错动态路由基础设施层基础设施层业务层业务层首届中国首届中国eBPFeBPF研讨会研讨会服务网格架构及问题服务网格架构及问题sidecar架构存在明显的
3、时延底噪开销,已成为业界共识的痛点问题架构存在明显的时延底噪开销,已成为业界共识的痛点问题网格数据面存在的挑战:网格数据面存在的挑战:时延性能差:时延性能差:服务访问单跳增加23ms,无法满足时延敏感应用诉求 资源占用大:资源占用大:代理节点占用大量CPU/MEM开销,业务容器部署密度低 观测运维能力不足观测运维能力不足:观测运维信息只能体现sidecar之间的部分,无法实现E2E观测运维;三方协议治理支持不足三方协议治理支持不足:只支持主流协议,协议扩展性不足https:/istio.io/latest/docs/ops/deployment/performance-and-scalabil
4、ity/时延开销大首届中国首届中国eBPFeBPF研讨会研讨会sockmapsockmap加速网格数据面加速网格数据面sockmap是linux在4.14引入的一个bpf特性,可实现socket间数据流的重定向,而无需经过复杂的内核协议栈,优化链路上socket间的数据转发性能;sockmap加速服务网格需要注意的问题:加速服务网格需要注意的问题:NAT场景场景sockmap无法配对无法配对:envoy通过iptables实现流量透明劫持(inbound:15006/outbound:15001),NAT后tcp链路两端的socket信息无法通过sockmap直接配对;社区解法:envoy的i
5、nbound/outbound端口可以事先获得,因此可以在sockmap程序中“写死”,但这并不优雅,且无法推广到其他NAT场景;首届中国首届中国eBPFeBPF研讨会研讨会sockmapsockmap加速网格数据面加速网格数据面NAT场景的基本思路:场景的基本思路:新增bpf helper bpf_sk_original_addr1,支持获取NAT前的目的地址信息;增加nat_map表,记录NAT信息;sockmap实施具体步骤:实施具体步骤:BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB状态添加client侧sockmap记录;BPF_SOCK_OPS_PASSIVE
6、_ESTABLISHED_CB状态添加server侧sockmap记录,并调用bpf_sk_original_addr获取NAT前目的地址信息,并构造正反两条nat_map记录;send流程,结合nat_map查找要redirect的目的地址信息,调用bpf_msg_redirect_hash进行redirect;close阶段在sockops hook中,清理两个map信息;1bpf helper:bpf_sk_original_addr openEuler 2209已原生支持,正在推kernel社区首届中国首届中国eBPFeBPF研讨会研讨会sockmapsockmap加速网格数据面效果加