Docker Swarm作为Docker原生的集群编排工具，以轻量、易用著称，不少团队会在云主机上直接搭建Swarm集群来承载容器化应用。Vultr云服务器凭借按小时计费、多区域部署和高性价比，成为个人开发者和小型团队的常见选择。但在生产环境中，Swarm集群的调度效率、overlay网络吞吐以及节点间通信延迟，都会直接影响业务表现。本文选取Vultr的几款主力机型，从CPU、内存、磁盘I/O和容器网络四个方面进行基准测试，帮助读者判断Vultr是否适合运行Docker Swarm。
测试环境与工具链
本次评测选用了Vultr位于东京和新加坡两个区域的云主机，涉及三款典型机型：高频型（High Frequency）、通用型（Regular Performance）以及AMD高性能型。每台实例均运行Ubuntu 22.04 LTS操作系统，Docker版本为24.0.7，Docker Swarm模式开启。为了排除公网抖动对结果的影响，所有网络吞吐测试均在Vultr私有网络内进行，节点间通过内网IP互连。
基础性能测试使用sysbench评估CPU与内存子系统，fio测试磁盘随机读写和顺序读写能力，iperf3测量节点间TCP与UDP吞吐。Swarm集群层面则通过创建多副本服务、触发滚动更新以及压测VIP负载均衡来观察调度与网络转发的实际表现。此外，我们还部署了一个简单的Nginx容器服务，使用wrk从集群外部发起HTTP请求，记录延迟和每秒请求数。
# 初始化Swarm管理节点 docker swarm init --advertise-addr <管理节点内网IP> # 在其他节点加入集群 docker swarm join --token <令牌> <管理节点内网IP>:2377 # 创建跨节点的overlay网络 docker network create --driver overlay --attachable app-net
所有基准测试均重复运行三次取平均值，以减少云环境性能波动带来的误差。需要说明的是，Vultr不同区域和不同母机负载可能导致测试结果存在一定浮动，因此本文数据主要反映在常规空闲时段下的性能水平，供选型时参考。
单节点基础性能：CPU、内存与磁盘
单节点性能是Swarm集群整体表现的基石。我们首先使用sysbench的CPU测试，计算20000以内所有质数的耗时。高频型实例（4 vCPU，8GB内存）完成单线程测试平均耗时约10.2秒，多线程测试约2.6秒；通用型实例（4 vCPU，8GB内存）单线程约12.8秒，多线程约3.1秒；AMD型实例（4 vCPU，8GB内存）单线程约11.5秒，多线程约2.9秒。可以看出，高频型在单核性能上领先明显，这对Swarm中大量短连接调度请求有很大帮助。
内存带宽测试中，三款机型吞吐差距不大，高频型略占优势，达到约22GB/s的写入速度。磁盘性能差异更为突出：高频型使用NVMe SSD，4K随机写入达到约18000 IOPS，顺序写入约1.2GB/s；通用型使用普通SSD，4K随机写入约4500 IOPS，顺序写入约350MB/s；AMD型同样使用NVMe但优化不同，4K随机写入约12000 IOPS。对于容器镜像拉取、日志写入以及数据库类容器来说，磁盘性能直接影响Swarm服务的启动和运行速度。
# 使用fio测试4K随机写入 fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=4k --size=1G --numjobs=4 --runtime=60 --time_based --group_reporting # 使用sysbench测试CPU多线程性能 sysbench cpu --cpu-max-prime=20000 --threads=4 run
从单节点数据看，Vultr高频型在CPU单核和磁盘I/O上具备明显优势，适合运行需要快速响应的Swarm管理节点或数据库类服务。通用型虽然在磁盘性能上偏弱，但价格更低，适合纯计算或内存密集型任务。如果集群中大量使用Redis、MySQL等有状态服务，建议管理节点和工作节点都选择高频型或AMD型，避免磁盘成为瓶颈。
Swarm网络与调度开销
Docker Swarm默认使用overlay网络实现跨节点容器通信。我们在一台管理节点和两台工作节点上部署iperf3容器，测试overlay网络下的TCP吞吐。结果显示，高频型节点之间的overlay网络吞吐约为1.8Gbps，而相同节点使用host网络时吞吐约为2.3Gbps，损耗约20%。这一损耗主要来自VXLAN封装和解封装以及用户态数据平面处理。对于大多数Web应用和API服务来说，这个吞吐水平足够，但如果你运行的是高带宽分布式存储或大数据计算任务，需要把网络模式切换为host或使用macvlan。
# 在overlay网络上运行iperf3服务端 docker service create --name iperf-server --network app-net --publish 5201:5201 networkstatic/iperf3 -s # 从另一节点运行iperf3客户端 docker run --rm --network app-net networkstatic/iperf3 -c iperf-server -t 30
调度开销方面，我们通过循环创建和删除100个小型服务（每个服务2个副本）来测试Swarm管理节点的响应速度。高频型管理节点平均创建一个服务耗时约180毫秒，删除耗时约90毫秒；通用型管理节点平均创建耗时约260毫秒，删除约140毫秒。滚动更新方面，对10副本的Nginx服务执行镜像更新，高频型集群完成全部更新平均耗时约4秒，通用型约6秒。这些数据表明Swarm的调度器非常轻量，管理节点性能对集群规模的影响远小于Kubernetes，即使在通用型实例上，几百个服务的日常调度也完全能胜任。
需要注意的是，Swarm的默认VIP负载均衡通过内核IPVS实现，每个服务对外暴露的虚拟IP会将流量分发到后端副本。我们在三节点集群上部署Nginx服务，副本数为6，使用wrk从集群外部进行压测。在并发100、持续30秒的条件下，高频型集群的吞吐约为4800 RPS，平均延迟22毫秒；通用型集群吞吐约为3100 RPS，平均延迟35毫秒。切换到host模式后，吞吐提升约15%，延迟降低约10%。这说明对于高并发入口服务，使用host网络或直接通过外部负载均衡器绕过Swarm VIP会更高效。
实际应用场景测试与结论
为了更贴近真实业务，我们模拟了一个典型的微服务链路：一个Nginx前端、一个Python Flask API服务和一个Redis缓存服务，三者分别部署在Swarm集群的不同节点上。使用Locust生成混合读写流量，观察全链路延迟和错误率。在500并发用户下，高频型集群的95分位延迟约180毫秒，通用型约为260毫秒，错误率均为0。随着并发提升到1000，通用型集群开始出现少量超时，而高频型依然保持稳定。这说明在中等负载下，Vultr通用型实例尚可支撑，但一旦接近资源上限，CPU调度和磁盘I/O的短板就会放大。
# 创建Nginx服务并暴露到外部 docker service create --name web --replicas 3 --publish published=80,target=80,mode=host nginx:alpine # 使用wrk进行压测 wrk -t12 -c400 -d30s http://<节点公网IP>/
综合来看，Vultr云服务器运行Docker Swarm的性能表现符合预期：高频型实例在CPU、磁盘和网络方面都提供了足够的性能余量，适合作为生产集群的主选；AMD型是性价比很高的备选，特别适合计算密集任务；通用型实例适合开发测试或低负载环境，但磁盘性能偏弱，不建议运行大量有状态服务。在集群规模方面，3到5个节点的Swarm集群在Vultr上运行非常流畅，管理节点选择2 vCPU、4GB内存的高频型即可满足上千个服务的调度需求。
最后需要提醒的是，Vultr的私有网络在同一区域内是免费的，跨区域则需要走公网或额外配置。在生产部署中，建议所有Swarm节点位于同一区域并启用私有网络，以降低overlay网络的封装开销和通信延迟。同时，定期监控磁盘I/O和网络吞吐，当发现overlay网络成为瓶颈时，可以结合host模式、macvlan或外部负载均衡来优化整体架构。总体而言，Vultr是搭建轻量级Docker Swarm集群的可靠选择，尤其在成本敏感的场景下表现突出。
VultrDocker Swarm性能评测修改时间：2026-08-28 22:05:43