Flomesh Service Mesh(FSM)旨在提供服务网格功能、注重高性能和低资源消耗。这使得资源受限的边缘环境能够利用类似云的服务网格功能。
在本次测试中,我们对 FSM(v1.1.4) 和 Istio(v1.19.3) 进行了基准测试。主要关注在使用两种不同网格时的服务延迟分布,以及数据平面的资源开销。
FSM 使用 Pipy 作为数据平面,而 Istio 则使用 Envoy。
测试前,重要的是要注意,我们的重点是比较它们之间的延迟和资源消耗,而不是极限性能。
测试环境
基准测试在运行于 Azure Cloud VM 的 Kubernetes 集群中进行。该集群包括 2 个Standard_D8_v3节点。FSM 和 Istio 均配置为宽松流量模式和 mTLS,其他设置均为默认。
- Kubernetes:K3s v1.24.17+k3s1
- 操作系统:Ubuntu 20.04
- 节点:8 核 32G 内存 * 2
- Sidecar:1 核 512Mi 内存
测试工具位于 此仓库 的 fsm
分支,该仓库从 istio/tools 分叉而来。
测试流程
测试流程记录在 此文件 中。
测试工具中有两个应用程序:fortioclient 和 fortioserver。负载是由 kubectl exec
触发 fortioclient 生成的。
对于两个网格,都进行了基线(无 sidecar)和双边车(两个 sidecar)模式的测试。负载生成设置为在 QPS 1000 下的 2、4、8、16、32、64 并发。您可以查看 FSM 和 Istio 的基准配置。
还有一个重要方面是将 请求和限制资源 设置为 1000m
和 512Mi
。
延迟
图示:xxx_baseline 表示服务直接访问,不通过 sidecar;xxx_both 表示客户端和服务端都有 sidecar。
X 轴表示并发数;Y 轴表示延迟,单位是毫秒,数值越小越好。
P50
P90
P99
P999
资源消耗
在 CPU 和内存占用图中,X 轴表示并发数;CPU 图的 Y 轴单位毫秒数,内存图的 Y 轴为 Mi,二者都是越低越好。
客户端 sidecar CPU
服务器端 sidecar CPU
客户端 sidecar 内存
服务器端 sidecar 内存
总结
此次,我们对 FSM 和 Istio 数据平面在限制 sidecar 资源下进行了基准测试。
- 延迟:FSM 的 Pipy sidecar 代理的延迟低于 Istio 的 Envoy,特别是在高并发情况下。
- 资源消耗:仅有 2 个服务时,FSM 的 Pipy 比 Istio 的 Envoy 消耗更少的资源。
从结果来看,FSM 能够在低资源使用下仍保持高性能,更有效地利用资源。因此,FSM 特别适用于资源受限和大规模场景,有效降低成本。这些优势得益于 Pipy 的低资源消耗、高性能特性。
当然,FSM 除了适用于云计算场景,也适用于边缘计算场景。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。