网易轻舟服务网格数据面性能优化实践

本文分析了服务网格数据面的性能瓶颈，并引出基于用户态协议栈的加速方案。详细介绍了VPP+VCL的用户态协议栈开源社区方案，其针对服务网格sidecar加速的优势和不足，以及网易数帆做了哪些增强，从而实现对服务网格sidecar的无侵入加速。最后介绍VPP+VCL用户态方案在加速网易轻舟云原生平台服务网格产品的落地实践，并给出实际的性能测试结果。

引子

服务网格通过引入sidecar提升了监控、流控、熔断等服务治理能力且对业务无侵入，但同时sidecar的引入在整个网络路径上也相当于增加了两个网络处理单元，从而不可避免的会引入时延。

从业务方的角度来看，引入sidecar后的时延肯定是越短越好，特别是业务方微服务化后对时延敏感的业务，如内部各模块之间的服务化调用。

所以，本文中的性能如果没有特别说明，都是指时延指标。

时延分析

如果打开整个端到端的通信链路可以看出，sidecar引入后整个应用之间的通信链路其实是非常长的。应用发送的请求被iptables劫持后，经过内核协议栈发送给sidecar，sidecar经过处理后再通过内核协议栈发送出去，这里一般要先经过容器网络，虚拟VPC网络，再经过物理网络，之后才被接收端的sidecar收到，sidecar处理后再通过内核协议栈发送给最终的应用，整个过程要经过6次内核协议栈，而响应报文也要反向重复这一过程。但是如果去掉sidecar呢？可以看到只需要经过两次内核协议栈就可以了，相当于sidecar引入后多增加了4次内核协议栈的调用，另外还多引入了几次iptables报文处理。

总体来看，整个链路包括物理网络、虚拟网络、Guest主机网络几个部分。其中，物理网络链路（包含在图中的⑦部分）不可控，这里不做讨论。而虚拟网络链路又分为虚拟VPC网络和容器网络。下面就来逐个分析下各个阶段可能的时延优化措施。

虚拟VPC网络

先看虚拟VPC网络（包含在图中的⑥部分）。一般来说，虚拟化会带来约10%的时延开销，那么这部分开销可以省掉吗？答案是肯定的，我们可以使用裸机容器的方案，略去中间的虚拟化层。

容器网络

再看容器网络（包含在图中的⑤部分）。这部分依赖于具体的容器网络方案，比如你网桥用的是Linux bridge、OVS还是VPP，虚拟端口用的是veth还是VF，性能都会不一样。VF+用户态OVS会是一个相对成熟以及性能较好的方案。RDMA也会是一个优化方向，不过这会牵扯到业务端改造，无法做到无侵入，同时还需要综合考虑组网以及硬件成本等因素。

Guest主机网络

最后重点来看Guest主机网络（图中①②③④⑧⑨部分）