NGINX与Avi负载均衡性能比较与选型指南

1. 先把比较的坐标系立起来

负载均衡这个领域有个很有意思的现象：很多人做选型的时候，第一句话就是"哪个性能更好"，但真正落地之后发现，性能差异往往不是决定因素，反而是当初没考虑到的运维模型、扩展方式和故障边界在半年后开始咬人。NGINX 与 Avi 的比较就属于典型情况——这两个名字经常被放在同一张选型表里，但它们压根不是同一层的产品，直接对比 RPS 数字，得出的结论十有八九是误导性的。

我在几个不同规模的项目里都用过这两套方案：一个日请求量几百万的中型业务，用的是 NGINX 做七层入口；另一个是多租户的容器平台，几百个租户、上千个虚拟服务需要动态增删，最后上了 Avi 这类控制面与数据面分离的方案。踩过的坑不少，今天把"云端性能之比较"这件事拆开讲清楚，重点不在于给出一个"谁更快"的结论，而在于告诉你在什么条件下该怎么比、比出来的数字怎么解读、以及比完之后怎么选。

适合读这篇的人：正在做入口层选型的基础设施工程师、需要给团队解释"为什么我们不直接用 NGINX 就够了"的架构负责人、以及被压测报告里那些漂亮数字搞晕过的运维同学。不需要你对两者都很熟，但最好手上有过至少一次真实压测经历，这样后面的内容会更有共鸣。

1.1 两个东西到底是不是同一类产品

这是所有比较的起点，也是最多人搞混的地方。

NGINX 本质是一台单机上的软件负载均衡器/反向代理。它的形态极其轻：一个二进制、一份配置文件、若干 worker 进程。你给它多少 CPU，它就用多少 CPU；你开一台 8 核机器，它最多也就把 8 核吃满，想再往上就得前面再挂一层，或者用 DNS 轮询、四层设备做分发。它的性能上限是"一台机器"的上限，这个上限其实不低，但它的扩展方式是横向堆机器，而堆机器意味着你要自己解决配置分发、健康检查一致性、会话保持、证书同步这些事。

Avi 这类方案本质是一个系统：控制面（Controller 集群）负责配置管理、策略下发、指标采集和自动扩缩决策；数据面（Service Engine）是真正转发流量的组件，通常基于用户态网络栈，可以是一组虚拟机、一组容器，也可以跑在裸机上。你配置一个"虚拟服务"，控制面会把它编译成数据面配置下发下去，数据面再按需增加或减少实例。它的性能上限是"你能开多少个数据面实例"乘以"单实例能力"，扩展动作由系统自己完成。

所以严格来说，正确的比较对象应该是：单机 NGINX 对比单个 Avi 数据面实例（这一层是公平的硬件对硬件比较），以及NGINX 集群 + 自建管控 对比 Avi 整体方案（这一层比较的是系统能力和运维成本）。把单机 NGINX 的吞吐直接和整个 Avi 集群的总吞吐放一起比，那叫做标题党，不叫做技术比较。

我在一次内部评审上就见过这种对比表：左边写"NGINX：12 万 RPS"，右边写"Avi：80 万 RPS"，结论是 Avi 快 6 倍。实际情况是左边那台是 8 核 16G 的虚拟机，右边是 12 个数据面实例的集群。这种表格流出去，误导的是整个团队的判断。

1.2 性能比较必须先问清的四件事

在动手压测之前，有四件事不定下来，测出来的数字就没有意义。

第一，业务流量的形状。是短连接高频请求，还是长连接流式传输？是 TLS 全握手为主，还是会话复用率很高？是均匀小包，还是少量大文件下载？这四种形状对负载均衡器的压力点完全不同。NGINX 在大量短连接 + TLS 全握手的场景下，瓶颈往往在握手计算而不是转发；在长连接场景下，瓶颈变成文件描述符数量和内存。

第二，七层还是四层。四层转发几乎不消耗什么 CPU，两者都能轻松跑满网卡；七层要解析 HTTP 头、做路由匹配、改写、限流，才是真正的性能分水岭。很多对比文章不写清楚测试的是哪一层，读者自然对不上号。

第三，是否包含 TLS 终止。这一项能让结果差出三到五倍。开启 TLS 之后，CPU 花在握手和对称加解密上，转发逻辑的差异被稀释，比较的重心就从"谁的转发引擎快"变成了"谁的密码学实现更高效、能不能硬件卸载"。

第四，健康检查与动态配置的频率。静态配置下两者都很快；但如果后端实例每分钟变动几十次，控制面下发配置的开销就会显现出来。Avi 这类方案在这一项上有天然优势，因为它的配置变更走的是增量下发；而 NGINX 传统上要 reload，reload 意味着新老 worker 交替，虽然平滑，但高频 reload 会带来内存峰值和连接抖动。

提示：如果你只想抄一个结论——同硬件同场景下，单实例转发性能 NGINX 通常不输甚至略优，因为它的路径最短；系统级的弹性、多租户和自动化能力 Avi 更强，但那是用控制面复杂度和许可成本换来的。剩下的内容是把这句话拆开讲透。

2. 架构差异决定了性能天花板

不聊架构直接聊数字，等于不看发动机谈油耗。这两套方案的性能特征，几乎完全可以从它们的架构推出来。

2.1 NGINX 的进程模型与事件驱动

NGINX 的核心是一个 master 进程加若干个 worker 进程。master 只做管理——读配置、绑端口、拉起和回收 worker；真正干活的是 worker，每个 worker 是单线程的，内部跑一个事件循环（Linux 上是 epoll），所有连接都在这个循环里非阻塞地处理。

这个模型的妙处在于：单线程避免了锁竞争，事件驱动避免了为每个连接开线程的栈开销。一个连接在等待网络 IO 的时候不占用任何 CPU，worker 转去处理别的连接。所以 NGINX 能用很小的内存撑起很高的并发连接数——几万个并发连接在几十 MB 内存里跑是很常见的事。

代价也很明确：一个 worker 只能用一个 CPU 核。想吃满 8 核就配 8 个 worker。这里有个细节，worker_processes auto会按 CPU 核数自动设置，但在容器里如果没限制 CPU 配额，读到的可能是宿主机的核数，结果开出一堆 worker 互相抢 CPU，上下文切换飙升，性能反而掉下来。容器化部署时我一般显式写死数字。

并发连接数的计算公式值得记一下：

最大并发连接 ≈ worker_processes × worker_connections ÷ 2

除以 2 是因为作为反向代理，每条客户端连接都要额外占用一个到后端的连接（文件描述符）。比如 8 个 worker、每个worker_connections 10240，理论并发上限约 40960。但这只是 fd 上限，实际还要看worker_rlimit_nofile、系统ulimit -n、以及内存。每条约 200 字节的连接状态，4 万连接也就 8MB 左右，真正的瓶颈通常是 fd 和上游连接池。

上游连接复用是个容易被忽略的优化点。默认情况下 NGINX 对每个客户端请求都新建一条到后端的连接，后端如果撑不住 TIME_WAIT 就会出问题。加一段 upstream keepalive 配置能显著降低后端压力和延迟：

upstream backend { server 10.0.0.11:8080; server 10.0.0.12:8080; keepalive 128; # 每个 worker 缓存 128 条空闲长连接 keepalive_requests 1000; # 单条连接最多复用 1000 次 keepalive_timeout 60s; } server { location / { proxy_http_version 1.1; proxy_set_header Connection ""; proxy_pass http://backend; } }

注意proxy_set_header Connection ""这一行，很多人漏了它，结果长连接复用完全不生效，配置写了等于没写。这是我在实际排查中遇到过不止一次的坑。

2.2 Avi 的服务引擎与控制器分离架构

Avi 这套方案把"管理"和"转发"彻底切开。控制器集群通常三节点起步，负责配置接收、策略编译、下发、指标聚合和自动扩缩决策；服务引擎是纯转发组件，从控制器拿到配置后自己跑，即使控制器短暂不可用，已下发的配置仍然生效，转发不中断。这个设计对可用性的意义很大——控制面故障不影响数据面，这是云原生场景里非常关键的一条。

服务引擎的转发路径通常走用户态网络栈（数据平面开发工具包那一套），网卡直接交给用户态程序管，绕开内核协议栈，减少内存拷贝和上下文切换。单实例的吞吐能做到很高，几十 Gbps 级别在合适的硬件上是可以达到的。代价是它需要独占网卡或者特定的网卡虚拟化支持，部署环境有要求，不是随便一台机器就能跑起来。

配置下发是增量式的。你改一个虚拟服务的策略，控制器只把差异部分推给相关的服务引擎，不需要重启进程。这一点在频繁变更的场景下优势明显：NGINX 的 reload 虽然平滑，但一次 reload 会产生新的 worker 进程、旧 worker 要等现有连接处理完才退出，高频 reload 会导致内存占用出现锯齿状波动，连接数多的时候这个波动会很明显。

自动扩缩是另一个关键差异。控制面持续采集每个服务引擎的 CPU、连接数、吞吐、延迟等指标，当指标越过阈值时自动增加实例，流量通过 ECMP 或者上游的负载均衡器分摊过去。这个过程对使用者是透明的。NGINX 侧要做同样的事，你得自己写一套监控 + 决策 + 扩缩 + 注册的逻辑，工作量和可靠性都要自己扛。

2.3 数据面路径的长度差异

把两条路径画出来对比（这里用文字描述，不画图）：

NGINX 的路径是：网卡 → 内核协议栈 → epoll 事件 → worker 用户态处理 → 内核协议栈 → 网卡。中间有两次用户态和内核态的切换，有数据拷贝。这个路径不短，但极其成熟稳定，内核的 TCP 栈帮你处理了拥塞控制、重传、窗口调整这些复杂事情。

Avi 服务引擎的路径是：网卡（或虚拟网卡队列）→ 用户态直接收包 → 用户态处理 → 用户态直接发包。省掉了内核切换和拷贝，理论上延迟更低、单核吞吐更高。但代价是 TCP 栈要自己在用户态实现（或者用现成的用户态协议栈），行为细节和内核栈不完全一致，遇到极端网络状况时表现可能有差异。

所以你会看到一个现象：在小包、低延迟、高并发的测试里，用户态转发优势明显；在复杂网络环境、需要精细拥塞控制的场景里，内核栈反而更稳。这不是谁先进谁落后的问题，是取舍。

注意：不要拿"用户态转发一定比内核转发快"当公理。虚拟化环境下网卡的队列模型、是否支持多队列、中断是否绑核，这些因素对结果的影响可能比用户态/内核态的选择更大。我见过内核转发跑赢用户态转发的案例，原因就是用户态那台机器的网卡中断全压在一个核上。

3. 实测维度拆解与压测方法

现在进入实操部分。这一节的目标是让你能自己搭一套可复现的对比测试，而不是照抄别人的数字。

3.1 指标定义与常见的测法陷阱

先明确定义，否则团队内部讨论会各说各话。

第一个陷阱是压测客户端自己成了瓶颈。单台压测机用 wrk 打简单响应，一般也就在几万到十几万 RPS 量级，再往上客户端先撑不住了。这时候你测到的"平台上限"其实是"压测机上限"。解决办法要么是多台压测机分布式打流，要么用专业硬件压测仪，要么至少监控压测机的 CPU 和网络，确认它没跑满。

我做过一次粗算：单台 16 核压测机，wrk 开 8 个线程，打 1KB 响应的 HTTP 请求，大概能到 15 万 RPS 左右就顶住了。要压出 50 万 RPS 的目标，至少需要 4 台压测机同时打，并且要确认汇聚交换机不成瓶颈。

第二个陷阱是忽略了 TIME_WAIT 的堆积。短连接压测跑几分钟之后，压测机和被测机上的 TIME_WAIT 能堆到几万条，端口耗尽，结果曲线突然掉下去，你会误以为是负载均衡器扛不住了。压测前把net.ipv4.tcp_tw_reuse打开、ip_local_port_range调宽，能缓解不少。

第三个陷阱是响应体大小不一致。如果一边测 1KB 响应一边测 100KB 响应，比较毫无意义。压测时固定响应体大小，并且分别在 1KB 和 64KB 两档各跑一轮，得到两组数字，才能反映真实业务。

3.2 压测环境搭建与关键配置

环境要求很简单，但每一条都不能省。

被测机方面：关闭 CPU 频率调节（设为 performance 模式），关闭透明大页，网卡多队列开启并把中断均匀绑到各个核上（irqbalance或者手动写/proc/irq/*/smp_affinity），确认 NUMA 节点对齐。

# CPU 频率固定到 performance cpupower frequency-set -g performance # 关闭透明大页 echo never > /sys/kernel/mm/transparent_hugepage/enabled # 查看网卡队列数，多队列能显著提升小包吞吐 ethtool -l eth0 # 确认中断分布是否均匀 cat /proc/interrupts | grep eth0

压测客户端用 wrk 或者 wrk2，后者能提供更准确的延迟分布统计，避免协调遗漏（coordinated omission）问题。跑的时候一定要开延迟统计：

# 4 线程 400 连接，持续 120 秒，输出延迟分布 wrk -t4 -c400 -d120s --latency -s pipeline.lua http://<target>/test

如果测 TLS，建议用两档密钥对比：

# RSA 2048 全握手 wrk -t4 -c200 -d60s --latency -H "Connection: close" https://<target>/test # ECDSA P-256 全握手 wrk -t4 -c200 -d60s --latency --cert key.pem https://<target>/eco

实测经验是：单核对 RSA 2048 全握手大约每秒一两千次，换成 ECDSA P-256 能提升三到五倍。如果业务允许，把证书换成 ECDSA 是性价比极高的优化，改动量极小，收益立竿见影。前提是客户端支持——现代浏览器和主流移动端基本都没问题。

还要记录服务端的资源使用。压测过程中用sar -u 1、pidstat -w 1观察 CPU 使用率、上下文切换次数，用ss -s看连接状态分布。这些数据比单纯的 RPS 数字有价值得多，因为它们告诉你"瓶颈在哪"。

3.3 结果怎么读，别被平均值骗了

跑完一轮，你会拿到一张表。我按自己的经验给一个定性的对照，具体数字因硬件和场景而异，不要当标准答案：

读这张表要注意几件事。

一是不要把"略优"当成"碾压"。七层短连接场景下，用户态转发的优势通常在 10% 到 30% 之间，这个差距在真实业务里很容易被其他环节抹平——上游应用的响应时间、数据库查询、缓存命中率，随便一个抖动都比这 20% 大得多。为了 20% 的转发性能去引入一套复杂度高得多的系统，很多时候是亏的。

二是长尾延迟比平均值重要。两套方案的平均延迟可能都在 5 毫秒，但 P99 可能是 20 毫秒和 8 毫秒，这个差异对用户体验的影响远大于平均值。wrk2 的--latency输出里会给出分位数，一定要看。如果只有平均值好看、P99 很差，说明存在排队或者 GC 式的停顿，这种系统在流量尖峰时会突然崩。

三是关注资源效率而不是绝对吞吐。同样是 10 万 RPS，一个用 4 核一个用 8 核，成本差一倍。算"每 Gbps 需要多少核"，比算"总共能跑多少 RPS"有用得多，因为云上你付的就是核的钱。

4. 场景化选型：什么情况下谁更合适

性能数字只是选型的一个维度。真正决定选择的，是场景约束。

4.1 中小规模与边缘节点：单机方案的性价比压倒性

如果你的业务是几台到几十台后端、日请求量在千万以内、变更频率不高，那 NGINX 几乎是默认答案。原因很实在：部署成本低到可以忽略，一个包一份配置，十分钟能上线；资源占用小，一台 2 核 4G 的机器就能扛住相当规模的流量；出问题好排查，日志格式熟悉，配置一眼能看懂，不用理解一整套控制面和数据面的交互逻辑。

边缘节点场景更能体现它的优势。边缘机器往往资源有限、网络环境复杂、无人值守，你需要的是一套"启动就能跑、不需要连中心控制面也能工作"的组件。NGINX 天生符合——配置在本地，不依赖任何外部服务。而控制面与数据面分离的方案在边缘场景会遇到一个现实问题：控制面连不上怎么办？虽然设计方案里通常会有本地缓存和降级逻辑，但配置变更、证书轮换这些操作在断连状态下会很别扭。

我在一个边缘项目里做过计算：50 个边缘节点，每个节点跑一个 NGINX 实例做入口，配置用统一的模板生成 + 定期同步。整套管控逻辑大概写了六百行脚本，跑了一年多没出过大问题。如果换成系统级方案，光是控制面集群的资源开销和许可费用就超过了整个边缘节点的硬件预算。

4.2 大规模多租户：控制面价值开始显现

当实例数量上去、租户变多、变更变频繁的时候，账就算反了。

设想一个容器平台，五百个租户，每个租户有自己的域名、证书、路由规则、限流策略，而且这些配置每天都在变——新租户开通、旧租户下线、证书自动轮换、灰度发布调整权重。这时候如果还用 NGINX 加自建管控，你要解决的问题清单会变成：配置模板引擎、配置版本管理与回滚、变更的原子性（改一半失败怎么办）、批量下发的并发控制、证书的自动申请与分发、每个实例的健康状态采集、异常实例的自动摘除与恢复。

这套东西不是做不出来，是要投入人力长期维护，而且每个环节出问题都会影响线上。系统级方案把这些做成了产品能力：配置有版本、下发是增量的、失败会重试、状态可观测、扩缩自动。你要付的是许可费用和学习成本。

多租户还有一个隐性需求是隔离。不同租户的流量特征差异很大，一个大租户的突发流量不应该影响其他租户。系统级方案通常支持按虚拟服务分配资源、设置配额和限速，隔离粒度更细。NGINX 侧要做到同等隔离，通常得给每个大租户单独开实例，资源利用率就下来了。

4.3 混合云与全局调度：这是系统方案的强项

跨多个环境部署的时候，全局负载均衡（按地理、按延迟、按权重把用户导到最近或最优的集群）是很常见的需求。系统级方案一般内置这个能力，控制面能看到所有集群的数据面状态，做统一的调度决策，故障时自动摘除整个集群。

NGINX 侧要做全局调度，通常得在 DNS 层做文章，或者再引入一层全局调度组件。DNS 方案的问题是生效慢（受 TTL 影响）、粒度粗、无法感知实时健康状态。要做得精细就得自己搭一套全局决策服务，又是一笔投入。

不过这里也要泼一盆冷水：全局调度听起来很美，实际落地时受限于客户端 DNS 缓存、运营商递归解析、以及跨集群的数据一致性。很多团队上了全局调度之后发现，实际生效的调度比例远低于预期。所以这一项的价值要结合业务实际判断，不要为了架构图好看而上。

5. 常见问题与排查实录

这一节是我踩过的坑和帮别人排查过的案例，都是文档里不会写的。

5.1 NGINX 侧的高频问题

问题一：压测 RPS 上不去，CPU 却只用了 30%。

这是最典型的一个。原因通常是 worker 数量没配对，或者连接都压在少数几个 worker 上。检查方法：ps -eLo pid,tid,psr,pcpu | grep nginx看各个 worker 线程的 CPU 分布。如果只有一个核在跑，说明worker_processes设成了 1，或者是在容器里读到了错误的核数。还有一种可能是accept_mutex相关配置导致的惊群问题，现代内核上一般建议关掉。

另一个原因是上游连接没复用，每个请求都新建 TCP 连接，CPU 全花在三次握手和 TIME_WAIT 处理上了。这时候ss -s会看到大量 TIME_WAIT，加上面说的 upstream keepalive 配置就能解决。

问题二：reload 之后内存翻倍，甚至被 OOM 杀掉。

NGINX 的 reload 是平滑的：master 启动新 worker，旧 worker 停止接收新连接，等现有连接处理完再退出。这个过程中新老 worker 同时存在，内存占用会短暂翻倍。如果单实例内存已经接近上限，reload 就成了压死骆驼的最后一根稻草。

解决办法有几个方向：控制单实例的内存水位，别让它跑到 80% 以上；降低 reload 频率，把多次变更合并成一次；或者用配置热加载的方案（部分商业版本支持），避免进程更替。我在一个高连接数的场景里就是把 reload 从"每次变更触发"改成了"变更合并后每五分钟一次"，内存锯齿就消失了。

问题三：TLS 握手把 CPU 吃满。

先确认是不是真的全握手。ss -s看不到这个，要看 NGINX 的$ssl_session_reused变量，或者在 access log 里加上这一项。会话复用率低的话，先检查ssl_session_cache和ssl_session_tickets有没有开。开了之后复用率通常能到 80% 以上，握手压力骤降。

如果复用已经开了还是吃满，那就换密钥算法。RSA 2048 换成 ECDSA P-256，单核握手能力能提升三到五倍。如果客户端兼容性有顾虑，可以双证书并存，让服务端按客户端能力协商。

5.2 系统级方案侧的高频问题

问题一：数据面实例加起来了，但流量没分过去。

这是部署环节最容易出问题的地方。数据面实例扩容之后，需要上游的路由设备（或者 ECMP 配置）把流量分发到新实例。如果新实例注册了但上游没感知，流量就全压在老实例上，你看到的现象是"扩容了但性能没提升"。

排查顺序：先确认控制面里新实例的状态是不是"就绪"，再确认上游路由表里有没有新实例的地址，最后确认新实例上的虚拟服务配置是否完整下发。这三步任何一步断链都会导致流量不均衡。我在一个项目里遇到过新实例网卡 MTU 配置不一致，导致大包被丢弃，表现出来就是"新实例能收到流量但吞吐很低"，查了挺久。

问题二：控制面与数据面版本不一致导致的诡异行为。

系统级方案的组件多，升级时如果控制面和数据面版本不匹配，可能会出现配置下发成功但行为不符合预期的情况。这类问题日志里往往看不出明显报错，因为配置语法本身是合法的，只是语义在新版本里变了。

经验是：升级时严格按官方给的兼容矩阵走，不要跳版本，控制面先升、数据面后升，升完观察一段时间再动下一批。生产环境分批升级，每批控制在 20% 以内。

问题三：自动扩缩过于灵敏，导致实例频繁抖动。

扩缩策略的阈值和冷却时间没调好，流量稍微波动就触发扩容，扩容完指标下来了又缩容，来回震荡。这个现象在小流量时段尤其明显。

调整思路是：扩容要快、缩容要慢。扩容阈值可以设得敏感一些，但缩容要加足够的冷却时间（比如连续 10 分钟低于阈值才缩），并且设置最小实例数兜底。另外要注意指标的选择，用 CPU 做扩缩依据时，如果业务有明显的突发特征，容易误判，可以考虑用并发连接数和 P99 延迟的组合指标。

5.3 问题速查表

6. 成本与运维视角的隐性账

性能比较的最后一块，也是最容易被忽略的一块：总拥有成本。这个账不算清楚，前面所有的性能数字都是空中楼阁。

6.1 许可费用与人力成本的换算

单机软件方案的成本结构很直观：软件本身开源免费（商业版另算），硬件按需，人力投入主要在初期搭建和后续的自动化脚本维护。以一个中等规模场景为例，初期投入大概是一到两个人月，后续维护可能占 0.2 个人力。

系统级方案的成本结构是：许可费用（按实例数或按吞吐计费，规模越大越贵）、控制面集群的硬件资源（三个节点起步，即使流量很小这部分也不能省）、以及学习成本（团队要理解它的模型、会排查它的问题）。初期投入可能是三到五个人月，后续维护 0.3 到 0.5 个人力。

所以分水岭很清楚：当自建管控的维护成本超过系统方案的许可成本时，就该换了。粗略估算是实例数超过五十、或者每月配置变更超过几百次的时候，自建的边际成本开始快速上升。低于这个规模，单机方案的经济性优势非常明显。

这里要提醒一句：不要低估"自建管控"的隐性复杂度。写一个能下发配置的脚本可能只要一天，但要做到配置原子性、失败重试、灰度发布、状态可观测、异常自愈，那是数量级的差别。我见过一个团队信心满满地自建，半年后这套脚本变成了没人敢动的祖传代码，最后推倒重来。

6.2 可观测性差异带来的排查效率

这一项很难量化，但实际影响很大。

单机方案的日志格式完全由你掌控，access log 里想加什么变量就加什么，出问题时 grep 一下配置文件就知道全貌。缺点是缺少全局视图，要看整个集群的状态得自己搭监控。

系统级方案自带指标采集和可视化，每个虚拟服务的请求数、延迟分布、错误率、后端健康状况都能在控制台看到，排查时省去了拼凑数据的过程。代价是它的指标口径是固定的，想加自定义维度不容易，遇到"这个指标为什么是这个值"的问题时，往往要去翻文档甚至找支持。

我的实际体会是：日常运维单机方案更顺手，故障定位系统方案更快。因为故障定位往往需要跨多个实例看全局，这正是系统方案的强项。而在平时，改个配置、加条规则，单机方案的操作路径短得多。

6.3 一个我个人的判断框架

写了这么多，最后给一个我自己用的判断流程，不是什么严谨的方法论，就是踩坑踩出来的直觉。

先问规模：实例数少于三十、变更每天少于十次，直接上单机方案，别犹豫。这个规模下系统方案的成本收不回来。

再问变更：如果配置变更频繁且要求原子性和可回滚，倾向系统方案。特别是多租户场景，这个需求几乎绕不开。

再问团队：团队里有没有人能长期维护那套自建管控？如果答案是不确定，那还是选系统方案，把复杂度交给产品，人力省下来做业务。

最后问预算：系统方案的许可费用是不是在可接受范围？如果预算卡得很紧，单机方案加上有限的自动化，也能撑起不小的规模。

我在实际操作中的体会是，绝大多数团队的真实需求落在中间地带——规模不算小、变更不算多、团队不算大。这种时候没有标准答案，最务实的做法是先用单机方案快速上线，把业务跑起来，同时把配置管理的规范建立好（模板化、版本化、可回滚），等到确实扛不住的时候再迁移。迁移的成本主要在于配置的重新表达，如果前期配置结构清晰，迁移并没有想象中那么痛苦。反过来，一上来就上重型方案，团队还没搞清楚自己的流量特征，很容易把系统用成一个昂贵的单机。