服务网格数据面性能深度调优

作者 | 汪翰林 、陈启钧

来源 | 经授权转载自 网易杭州研究院 公众号

服务网格作为云原生的重要技术，提升了微服务的流控、熔断、升级等服务治理能力，但同时 sidecar 的引入也导致了时延的增加。网易数帆通过对时延引入的具体分析，尝试利用 eBPF 和用户态协议栈技术，来对时延进行优化，并最大限度地考虑兼容性，做到对容器网络、sidecar 应用的无侵入加速。

1 时延分析  

服务网格中 sidecar 的引入在整个网络路径上增加了两个网络处理单元，从而不可避免地会引入时延。针对 sidecar 本身逻辑的优化来优化时延是社区的一个方向，比如 envoy 社区针对 mixer 的优化。另外一个方向是针对链路底层做优化。

如果打开整个链路来看，sidecar 会多引入 Service 到 sidecar 的链路以及 sidecar 到 sidecar 的链路，客户端和服务端总共多经过了四次内核态协议栈。我们通过了火焰图分析了 sidecar 应用 envoy 的 CPU 占用，发现内核态协议栈的 CPU 占比近 50%，所以针对内核态协议栈的优化效果理论上应该非常可观。

另外也可以针对容器网络做优化，比如使用 SRIOV 容器网络方案，不过会涉及对已有的容器网络方案的改造，有侵入性。

2 eBPF Sockops 优化 Service 和 sidecar 通信  

Service 和 sidecar 之间属于同一个节点的两个容器间的通信，可以采用 Sockops 组件进行加速。

Sockops 原本是开源 Cillium 中的一个组件，利用 sockmap 和 sk redirect 技术直接绕过 TCP/IP 协议栈将报文直接发给对端 socket，从而来加速同节点 socket 之间的通信。我们借用相关实现并作了增强开发，来适配 sidecar 的场景。

Sockops 加速在《eBPF 在网易轻舟云原生的应用实践》中有详细说明。

从最终测试结果来看，使用 Sockops 加速 Service 和 sidecar 的通信，可以降低时延 10% 左右。

3 用户态协议栈优化 sidecar 和 sidecar 通信  

sidecar 和 sidecar 之间的通信会涉及跨节点，无法使用 Sockops 进行加速，这里我们使用用户态协议栈替换内核态协议栈实现。用户态协议栈相较内核态协议栈可以在两个方面带来性能的提升：

• 消除内核态和用户态切换的开销；

• 将协议栈的实现代码放到独立的用户态进程中实现，去除 sidecar 中协议栈实现的 CPU 开销；

下面来具体说明相关实现。

VPP+VCL 分离式部署节省 CPU 资源  

为了兼顾到性能和资源占用，我们选择 VPP 作为用户态协议栈。VPP 作为独立进程实现用户态协议栈，并提供轻量级的 VCL 动态库供 sidecar 集成以实现 socket 接口的劫持，VPP 和 VCL 之间通过共享内存进行通信。

其中：

VCL - 实现 Socket 类接口劫持并和后端 VPP 完成交互

FIFO - 是基于共享内存封装的消息队列，用于 VCL 和 VPP 之间通信

Session - 维持传输层和上层应用会话之间的对应

TCP/IP - 对应内核的 TCP/IP 协议栈实现

AF_XDP - 实现将网卡的报文收发卸载到用户态

可见，VPP+VCL 分离式的部署模式将协议栈从应用端剥离，VPP 作为实现协议栈的独立进程可以服务于节点上的所有 sidecar，从而将 sidecar 和协议栈的 1:1 绑定部署关系，变为 N:1 的独立部署关系，节省了总体的 CPU 资源占用。同时，sidecar 也将更多的 CPU 资源用于自身业务逻辑的处理，提高了 CPU 资源的利用率，从而降低了 sidecar 节点的处理时延。

无侵入设计提升易用性  

无侵入设计体现在南北两个方向，南向对接容器网络，而北向对接 sidecar。

北向对接 sidecar 时，会通过 VCL 动态库供 sidecar 集成。VCL 动态库中会自动劫持 socket 接口，这样就无需 sidecar 修改代码。而且 VCL 动态库支持 LD_PRELOAD 加载方式，仅需要 sidecar 应用启动时指定此环境变量来配置 VCL 动态库的路径即可。

南向对接容器网络会麻烦一些。容器网络种类繁多，但是最终都会插入一个网口给 POD 使用，此网口以 veth 口居多，也有可能是 VF 口。由于并不是所有的流量都需要走 sidecar，比如 Service 和宿主机通信就只需要走内核态，那么如何在保留现有内核通信通道的情况下进行用户态协议栈的加速呢？

我们借助 AF_XDP 来做流量的分流。即先使用 XDP 针对于特定报文进行过滤，满足条件则送入 VPP，否则继续走内核。

报文分流到 VPP，再上送 sidecar 后，sidecar 还需要将报文发送给 Service，这条路径只能走内核，可以通过 Sockops 进行加速。

双栈支持  

双栈支持其实包括两个方面。

一个是基于 eth0 口基于 AF_XDP 的双栈分流，这个在上节中已经做了说明。

另一个是 sidecar 的双栈支持，因为 sidecar 也需要通过内核态和 Service 进行通信。

sidecar 的双栈支持需要 VCL 中针对报文做区分，需要走内核态的报文则重新调用原生的 socket 接口让报文走内核态协议栈。

4 优化效果  

针对不同的 RPS 测试 Both Sidecar 时延的情况，ua 表示启用了用户态协议栈优化。可以看出，用户态协议栈时延降低 30% 左右，Sockops 时延降低 10% 左右，两者结合后时延降低 35% 左右。

5 写在最后  

AF_XDP+ 用户态协议栈 +Sockops 针对服务网格 sidecar 场景，优化了内核协议栈的 CPU 资源占用，降低了 sidecar 所引入的端到端时延，且对当前的容器网络以及 sidecar 应用无修改，做到无侵入加速。用户态协议栈和 Sockops 的管控基于 Kubernetes Operator 进行开发，部署和运维也非常简单，根据需要可以单独进行部署，也可以合并使用。后续我们也会考虑将针对服务网格的这些加速套件进行开源。

另外，通过加速组件的灵活组合，除了 sidecar 加速，我们也上线了针对 API 网关的加速，单独的用户态协议栈加速组件我们也在拓展到 Redis、Nginx 等加速场景。

作者简介：

汪翰林，网易数帆系统开发专家，17 年软件开发老兵。曾就职于华三和华为，从事安全、视频监控、大数据和网络虚拟化等技术产品研发，目前在网易数帆轻舟云原生团队负责高性能网络技术预研和产品落地工作。

陈启钧，网易数帆资深工程师，十年以上开发经验，曾就职于华为，主要从事存储网络管理、容器以及网络虚拟化相关工作，专注于发现并解决问题。目前在网易数帆主要负责 VPC 网络、轻舟容器网络、轻舟服务网格等方面的性能调优工作，主要关注 Kubernetes、eBPF/XDP、用户态协议栈相关技术。

今日好文推荐

这20年，我“颠簸”在软件工程的列车上

我国互联网遭境外网络攻击；俄罗斯或将多家外企“国有化”；Linux内核被发现易于利用的漏洞｜Q资讯

TikTok美国数据或将由甲骨文存储，字节跳动无权访问

我放弃了年薪200万的岗位，因为“复制粘贴”的技术活让人厌恶

点个在看少个 bug 👇