使用 eBPF 加速阿里云服务网格 ASM
背景
随着云原生应用架构的快速发展，微服务架构已经成为了构建现代应用的主要方式之一。而在微服务架构中，服务间的通信变得至关重要。为了实现弹性和可伸缩性，许多组织开始采用服务网格技术来管理服务之间的通信。
Istio 作为目前最受欢迎的服务网格之一，提供了一套强大的功能，以简化服务网格的管理和操作。它通过引入一组专门的代理（即 Sidecar）来实现在服务之间进行流量管理、监控和安全控制等功能。
在 Istio 中，Sidecar 是一种特殊的代理，它与每个服务实例一起部署，并负责处理该实例与其他服务之间的通信。它位于服务容器内部，与应用程序实例一同运行，并通过拦截和转发网络流量来提供服务网格的功能。
然而，正因为 Sidecar 与每个服务实例一同运行，它也可能引入一些潜在的性能问题，其中一个主要问题就是延迟。
由于每个服务实例都需要与其对应的 Sidecar 进行通信，这增加了请求路径的长度和网络延迟。此外，Sidecar 还要负责执行各种功能，如流量管理、监控和安全控制等，这也会对性能产生一定的影响。
针对 Sidecar 引入的延迟问题，业内常用采用 eBPF sockops 技术来优化，在同一个节点下，短路两个进程间的 socket 通信，也就是让 tcp 报文不用经过 TCP/IP 协议栈。 加速后的流量路径示意图如下：
阿里云服务网格最近上线了sidecar 加速组件, 接下来我们来测试验证下，特别是对比其开启前后实际的加速效果。
安装部署和环境介绍
环境准备
首先，按照文档，创建一个 ASM 实例，笔者采用当前 ASM 最新版本 v1.18 企业版
然后，创建一个 ACK 集群，ASM sidecar 加速组件仅支持 ACK 托管版本和 ACK 专有版本集群。笔者创建了一个 ACK 托管版本实例 ，版本使用 v1.26, 集群包含 3 节点，节点操作系统镜像使用了文档推荐的 Alibaba Cloud Linux3。并把 ACK 添加到 ASM 实例下。
环境信息如下：
✅ASM 实例
✅ACK 集群
网络 CNI 插件选用了 terway
部署测试例子
这里采用了从 istio 官方的benchmark 工具下抽离出的简化版压测程序。
根据Sidecar Acceleration 组件文档提示，组件开启不能加速已有存量 TCP 连接，因此，笔者通过 DestinationRule 配置了 客户端侧的相关连接池配置，通过设置连接的空闲时间 30s 来保证前后多轮测试，连接总是新建的。（前后两轮测试间隔 30s 以上即可）
拷贝如上 yaml ，kubectl apply 即可。注意部署前已将 default namespace 开启了 sidecar 自动注入。
压测模型： 很简单就是 fortioclient -> fortioserver , 注入 sidecar 后，压测流量路径变为：
[ fortioclient -> sidecar ] -> [ sidecar -> fortioserver ]
Yaml 配置简单说明如下：
1） 考虑到 envoy 路由和负载均衡能力大部分功能由 outbound sidecar 起作用，上述配置特意调大了 outbound sidecar 的 CPU ，设置其 CPU limit 为 4000m, concurrency 对应调整为 4 （性能最优），避免压测客户端成为瓶颈。
为了测试多阶段都能加速的效果，特意通过 pod 亲和性将 fortioclient 和 fortioserver 调度到同一个节点。
3）每一轮的压测结果可以通过 fortioclient 的 8080 端口访问进行查看。
压测方法：
1) http 请求性能压测
2) tcp 请求性能压测
其中 labels 是对应这一轮压测的名称，可用于区别多轮压测结果。
qps 需要根据实际压测场景进行调整。设置为 0 表示无上限。设置为非零表示采用固定 QPS 进行压测。
fortio 相关参数含义可以参考官方链接文档： https://github.com/fortio/fortio
性能测试
为了避免压测时相关干扰信息，可以将日志暂时关闭。在 ASM 控制台的可观测配置下操作关闭即可。
首先进行一轮环境的 QPS 上限测试。对比开启前后的 QPS 是否有提升。
压测相关参数设置：
64 并发
QPS 不设上限
持续压测 30s
http payload 1024 (1KB) size
压测结果：
也可以通过 fortioclient 的 loadbalancer ip 访问查看相关直方图，可以看到大部分请求的 latency 分布情况。
测试开启 Sidecar Acceleration 加速组件后效果：
在 ACK 控制台的组件管理菜单下找到加速组件，点击安装；
安装提示成功后，再次使用同样的压测命令进行压测：
压测结果：
开启前后对比：
从 QPS 角度来看，13521 / 11461.0 = 1.179739987784661， 18% 左右的 QPS 提升。
Latency 角度来看: 4.732/5.583 = 0.8475729894322049, 平均 AVG latency 降低 16% 左右。
我们可以通过 fortio UI 提供的直方图可以直观地看出，加速组件开启后，延迟更低，大部分请求在低延时区域。 未开启加速组件之前的请求，对比有超出一部分请求在较高的延时区域。
笔者进行了多轮压测，排除了相关环境抖动因素。
调整并发进行多轮压测，QPS 基本提升都能保证在 15% 左右。
然后，再次进行了一组 TCP 的压测对比
压测相关参数配置：
64 并发
1024 payload
持续压测 30s
开启前：
执行如下命令进行压测;
进行多轮压力测试，多轮压测差异不大，排除干扰信息。
开启后：
执行如下命令：
开启前后直方图对比：
QPS 前后对比：
85665/54564.9 = 1.5699653073679234 , 50%多的 QPS 提升，这是因为对于 TCP 来说，sidecar/envoy 仅做 tcp 负载均衡纯转发，不用做 HTTP 报文解析。
因此，在这种场景下，报文通过 TCP/IP 协议栈所占用的时间比重相对较高。我们通过 Latency 对比也可以看出。
Latency 前后对比：
0.746 ms / 1.172.ms = 0.636 ，接近 40% 的 latency 降低。
总结
服务网格下的 Sidecar 代理业务服务的收发请求，并提供业务层面的流量控制（路由）、负载均衡等功能，会引入一定的 Latency 延迟。 通过 eBPF 技术（部署 sidecar 加速组件）将同节点下两个进程间的 TCP 报文进行 socket 短路可以提升一定的性能，HTTP 场景下 QPS 可提升 15% 左右, 有效地降低业务请求的 Latency 。
实际业务场景下，对于 Latency 敏感型的业务，我们可以通过 pod 亲和性将上下游的依赖服务部署在同一个节点，采用 Sidecar Acceleration Using eBPF 组件来保证服务更低的 Latency 和 更高的 QPS 。
阿里云云原生 2019-05-21 加入
还未添加个人简介
评论