Kmesh：高性能服务网格数据平面

2023年7月8日 · 阅读需 11 分钟

什么是服务网格

服务网格的概念最初由开发 Linkerd 软件的公司 Buoyant 在 2016 年提出。Linkerd 的 CEO Willian Morgan 给出了服务网格的最初定义：

服务网格是专门用于处理服务间通信的一个层。它负责在构成现代云原生应用的复杂服务拓扑中可靠地传递请求。实际上，服务网格通常通过部署在应用代码旁边的一组轻量级网络代理来实现，而应用程序本身无需感知这一层。

简单来说，服务网格是一层处理服务间通信的机制。它通过部署一组轻量级网络代理，为现代云原生应用提供透明且可靠的网络通信。

服务网格的本质在于解决微服务如何高效通信的问题。通过实现负载均衡、金丝雀路由和熔断等治理规则，服务网格能够协调流量，最大化服务集群的能力。这是服务治理演进的产物。

我们可以将服务治理的演进分为三代，并进行比较。从这一演进中可以看出，服务治理能力逐步从业务逻辑中剥离，并下沉到更低层次。

作为处理服务间通信的一层，服务网格有效弥补了 Kubernetes（k8s）中微服务治理的不足。作为云原生环境的下一代技术，它已成为云计算的关键组件。

近年来，服务网格受到广泛关注，涌现出诸多服务网格软件解决方案，如 Linkerd、Istio、Consul Connect 和 Kuma。虽然它们在软件架构上可能存在细微差别，但以 Istio（最流行的服务网格项目之一）为例，可以说明服务网格的基本架构：

以 Kubernetes 集群为例，当创建一个 Pod 实例时，服务网格软件会透明地在应用代码旁边部署一个代理容器（也称为边车，Istio 默认的边车软件为 Envoy）。Pods 之间的基本通信流程如下：

正如前文所述，服务网格通过在数据平面中引入代理层来实现透明的服务治理。然而，这也带来了一个问题：代理层的引入不可避免地增加了服务通信的延迟并降低了性能。

以 Istio 官方网站提供的数据为例，在集群环境中，微服务之间每跳的平均延迟增加了 2.65 毫秒。考虑到在微服务集群中，外部请求往往涉及多个微服务之间的调用，因此服务网格引入的延迟开销十分显著。随着服务网格应用的不断增长，代理架构带来的额外延迟已成为一个关键挑战。

为了解决这一问题，我们对 HTTP 服务的 L7 负载均衡进行了性能测试，以分析服务网格的通信性能。时间消耗的细分如下：

从对网格流量的详细分析中可以看出，服务间通信从一次连接建立变为三次，从两次协议栈遍历变为六次。时间消耗主要集中在数据拷贝、连接建立、上下文切换等方面，而流量治理实际引入的开销相对较小。

这就引出了一个问题：在保持应用透明治理的同时，是否能降低服务网格的延迟开销？

基于上述性能分析，我们对服务网格数据平面进行了两阶段优化。

Sockmap 是 Linux 4.14 引入的 eBPF 特性，它能够在节点内部在套接字之间重定向数据流，而无需经过复杂的内核协议栈，从而优化了网络路径上套接字之间数据转发的性能。

在服务网格场景中，Pod 内业务容器与本地代理组件之间的默认通信需要经过完整的内核协议栈，从而产生不必要的开销。通过 Sockmap 可以优化这一开销。下图展示了这一概念：

利用 Sockmap 加速服务网格数据平面的基本步骤如下：

在连接建立过程中，附加一个 eBPF 程序（类型为 BPF_PROG_TYPE_SOCK_OPS）拦截所有 TCP 连接建立动作：
- 在 BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB 状态下，添加客户端侧的 Sockmap 记录。
- 在 BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB 状态下，添加服务端侧的 Sockmap 记录。
- 将双方的套接字信息存储到 Sockmap 表中。
在 sendmsg 过程中，附加一个 eBPF 程序（类型为 BPF_PROG_TYPE_SK_MSG）拦截消息发送动作：
- 程序根据当前套接字信息查找 Sockmap 表，并将其与目标方的套接字信息关联，直接将流量重定向到目标套接字的接收队列。

通过利用 Sockmap 加速服务网格数据平面，我们在 60 个长连接场景下观察到服务访问的平均延迟降低了 10% 到 15%。