负载均衡负载指标详解CPU、连接数、I/O、网卡吞吐量如何采集与分配核心结论先行负载均衡系统确实可以根据系统压力来进行分配这类策略统称为动态负载均衡或称 least-load / 资源感知调度。它和轮询、加权轮询这类静态策略的区别在于分配依据不是顺序或静态权重而是实时采集的各服务器压力指标。下面把这句话拆开讲透——每个指标是什么、怎么采集、怎么用它来分配。一、负载均衡可以根据系统压力分配吗如何设置1.1 可以但要回答三个问题根据系统压力分配这件事本质是一个反馈控制系统必须解决问题内容采什么采集哪些指标CPU、连接数、I/O、网卡……单一还是组合怎么采采集方式主动轮询 / 被动上报 / 探针采集频率怎么判多指标怎么归一成一个压力分并据此排序/筛选节点1.2 主流实现方式方式一反向代理主动探测如 Nginx 模块Nginx 原生不带按 CPU/IO 分配的策略开源版只有least_conn最少连接。要按系统压力分需扩展# Nginx 原生支持的最接近压力分配的策略最少连接数 upstream backend { least_conn; # 把请求发给当前活跃连接数最少的节点 server 10.0.0.1:8080; server 10.0.0.2:8080; server 10.0.0.3:8080; }要按 CPU/IO/网卡分配通常用Nginx Plus商业版的queue 健康检查主动模式或引入Lua 独立指标源Prometheus/OpenResty 自研。方式二客户端负载均衡如 Spring Cloud LoadBalancer / Ribbon 替代品客户端从注册中心Eureka/Nacos拉到服务列表后自己调接口问你现在压力多大再决定调谁。可自定义ServiceInstanceListSupplier把指标接入选择逻辑。方式三专用负载均衡器LVS keepalived、F5、A10LVS内核态默认策略是 WLC加权最少连接、LBLC基于局部性的最少连接不带 CPU/IO 采集需配合 keepalived 的健康检查脚本vrrp_scriptcheck_script由用户脚本采集指标、动态调整weight。F5 / A10硬件自带深度健康监控可监控 CPU、内存、连接数、响应延迟有动态比率Dynamic Ratio策略节点压力高自动降权。方式四服务网格 / Kubernetes最现代的做法Kubernetes 原生调度根据节点资源请求量requests、实际用量metrics-server / Prometheus Adapter、节点压力pressure 信号disk/memory/pid调度 Pod。HPA水平自动扩缩容根据 CPU/内存/自定义指标自动增减副本数是用压力指标调整容量的典型落地。Istio可按负载如 outbound 连接数、延迟做流量切分。1.3 一个最小可用的按 CPU 分配配置示例Nginx Lua 伪代码-- 每个后端节点暴露 /metrics 接口返回 {cpu: 0.72, conn: 130}-- 网关侧 OpenResty 拉取并排序选最低者转发localnodesupstream_get_nodes()localscores{}for_,nodeinipairs(nodes)dolocalmhttp_get(node.addr../metrics)scores[node]m.cpum.conn/1000-- 归一化加权endtable.sort(scores,function(a,b)returna.scoreb.scoreend)returnforward_to(scores[1].node)关键设计点采集与转发解耦。指标采集放后台异步刷新如每 1~5s 一次请求路径上只读缓存不要在每次请求里同步去拉指标——否则网关本身会被压垮。二、各指标是什么、怎么衡量系统压力2.1 CPU 负载CPU Load是什么反映 CPU 繁忙程度的核心指标有两层含义别混CPU 使用率utilization%CPU 处于非空闲状态的占比。如 75% 表示 75% 的时间片在干活。CPU 平均负载load average单位时间内处于可运行状态和不可中断睡眠状态的进程平均数Linux 的定义。注意它算的是进程数不是百分比。Linux 怎么看uptime# load average: 1.20, 0.85, 0.60 ← 1分钟 / 5分钟 / 15分钟top/htop# 看 %Cpu(s) us/sy/id 和 loadcat/proc/loadavg# 1.20 0.85 0.60 2/1234 12345怎么用它衡量压力经验法则load average ÷ CPU 逻辑核数 比值≈ 1.0刚好满载无积压 0.7偏闲 1.0有进程在排队等 CPU开始积压 核数 × 2明显过载响应延迟会急剧上升例如 8 核机器load 1.2 → 比值 0.15 → 很闲load 16 → 比值 2.0 → 过载。作为分配指标的优缺点优点最直接反映计算类负载压力采集简单。缺点对 I/O 密集型服务不敏感——一个卡在等数据库的请求CPU 几乎不涨但系统已经很堵。所以不能只看 CPU。不可中断睡眠D 状态进程会被计入 load average因此高 I/O 等待会让 load 飙升这时 load high 但 CPU% low——这是经典的I/O bound信号。2.2 连接数Connections是什么当前节点上正在/累计处理的网络连接数。常用两类口径活跃连接数active connections当前 ESTABLISHED 状态的连接反映正在服务的并发量。新建连接速率conn/s单位时间新建连接数反映请求速率。怎么看# Nginx 自身状态需开 stub_statusActive connections:15server accepts handled requests8456845632891Reading:0Writing:1Waiting:14# 系统层ss-s# 连接数汇总ss-tnstate established|wc-l# 当前已建立连接数netstat-an|grepESTABLISHED|wc-lcat/proc/sys/net/netfilter/nf_conntrack_count# 连接跟踪表条目数怎么衡量压力连接数 ≠ 请求数。一个连接可复用多个请求HTTP keep-alive、连接池。真正反映压力的是活跃并发连接数与处理速率的组合连接数高 新建速率高 高并发压力。连接数高但不一定意味着过载若服务器处理快、连接都是 keep-alive 空闲等待Waiting 多其实并不忙。所以 Nginx 的least_conn优先看正在处理Reading/Writing的连接Waiting 的不算重。作为分配指标的优缺点优点对I/O 密集 / 长连接服务数据库代理、推送、WebSocket特别有意义弥补 CPU 指标的盲区。缺点连接数高不一定压力大需结合每连接处理速率看才准。2.3 I/O 使用率Disk/Network I/O是什么磁盘 I/O 和网络 I/O 的繁忙度但本节指磁盘网卡吞吐单列在 2.4。核心指标指标含义%util时间区间内磁盘有 I/O 在执行的占比最接近使用率。注意它是时间占比不是带宽占比r/s w/s每秒读/写完成次数IOPSrkB/s wkB/s每秒读/写吞吐量awaitI/O 平均等待时间含队列等待ms 级最反映压力的指标%iowaitCPU 侧CPU 等待 I/O 完成的时间占比高说明 I/O 是瓶颈怎么看iostat-x1# 每秒一次看各盘的 %util / await / r/s w/siotop# 按进程看谁在读写vmstat1# bo/bi 列 wa(iowait) 列cat/proc/diskstats# 内核原始计数器怎么衡量压力%util接近 100% 说明磁盘一直忙但对多队列 SSD 含义会失真并发处理多个 I/O 时 util 也可能满但实际还有余力。更可靠的是awaitHDD 超过 ~10–20ms、SSD 超过 ~1–5ms说明队列在堆积压力真实升高。%iowaitvmstat 的wa持续 5–10%说明 CPU 在干等 I/O整个系统 I/O bound。作为分配指标的优缺点优点对日志写、文件存储、数据库这类磁盘密集服务是命脉。缺点对纯内存/计算型服务基本无意义采集开销相对 CPU 大一点。2.4 网卡吞吐量Network Throughput是什么单位时间内网卡收发的数据量分两向入向rx / ingress接收的 Bps / pps出向tx / egress发送的 Bps / pps注意区分两个维度带宽bps / Bps每秒字节数反映数据量。包速率pps每秒包数反映小包处理压力。对转发/网关类服务pps 比 bps 更先到瓶颈内核中断、协议栈开销主要看包数。怎么看# 瞬时cat/proc/net/dev# iface: bytes packets errs ... tx bytes packets ...# 历史曲线 / 速率sar-nDEV1# 每秒各网卡 rxkB/s txkB/sifstat1/ nethogs# 按进程/网卡看带宽ethtool-Seth0# 网卡硬件计数器丢包、错误帧# 容量对照ethtooleth0|grepSpeed# Speed: 10000Mb/s → 千兆/万兆怎么衡量压力和网卡标称带宽比千兆网卡理论上 ~125MB/s到 ~80% 利用率100MB/s就开始排队、丢包概率上升。更关键看丢包和错误ifconfig的RX/TX drop / overruns、ethtool -S的rx_missed_errors有非零说明网卡/队列已经扛不住压力到了硬上限。网卡满载会导致软中断softirq占满 CPU表现为top里si列飙高、单个 CPU 核被打满因为中断默认绑在 0 号核需 RPS/RFS 分散。作为分配指标的优缺点优点对CDN、网关、视频/文件下载、流量中转类服务最直接。缺点对普通业务服务单机流量很少触到网卡上限区分度低。三、如何根据这些指标进行分配3.1 核心思路把多指标归一成一个压力分单一指标都有盲区工业界几乎都用加权组合。构造一个压力函数pressure_score w1 * cpu_load_ratio # 0~1 w2 * conn_utilization # 当前连接 / 最大连接 w3 * io_pressure # await 归一化或 %util w4 * net_utilization # 当前吞吐 / 网卡上限 w5 * (1 - health) # 健康/延迟惩罚权重w1~w5按服务类型定计算型服务推荐引擎、视频转码w1 大w3 小。I/O 型服务数据库、文件服务w3、w2 大。网关/转发型服务w4、w2 大w1 小。长连接/推送服务w2 为主导。3.2 分配算法选择算法做法适用最小压力least-pressure选pressure_score最低的节点指标可信、采集及时时最优加权最小连接WLC选连接数/权重最小者权重可由指标动态调整LVS/通用工程上最常用动态权重dynamic ratio后台定时根据指标重算每个节点的 weight再用 WRR 转发F5、NginxLua 主流做法EWMA 平滑用指数加权移动平均平滑指标避免瞬时抖动导致抖动调度任何动态策略都建议加带冷却的水位过滤压力超过阈值如 load核数×1.5的节点直接摘除只在不超载节点里轮询保护性策略必选之一3.3 工程落地要点避免常见坑采集与转发解耦后台异步刷新指标缓存请求路径只读缓存。平滑而非瞬时用 EWMA 或 5s 平均否则一个瞬时尖峰会让流量在节点间来回跳oscillation。设上下限保护单节点压力超阈值摘除但保留优雅恢复避免抖动反复摘/挂。避免羊群效应压力指标采集失败时不要默认压力 0会被当成最闲狂灌流量应降级为上次值或摘除节点。指标采集本身要轻量/proc读取成本极低避免在采集路径上引入重依赖如每次都fork一个top。分层硬件层用 LVS 做连接/带宽4 层应用层用 Nginx/网关做 CPU/延迟7 层各取所长。3.4 一个完整的动态权重逻辑伪代码EWMA_ALPHA0.3THRESHOLD0.8# 压力分超过 0.8 摘除defupdate_weight(node):raw(0.4*node.cpu_ratio0.3*node.conn_ratio0.2*node.io_await_norm0.1*node.net_ratio)node.scoreEWMA_ALPHA*raw(1-EWMA_ALPHA)*node.score# 平滑ifnode.scoreTHRESHOLD:node.weight0# 摘除等恢复else:node.weightint(100*(1-node.score))# 越闲权重越大四、还有哪些指标4.1 应用/业务层指标往往比系统指标更先反映用户感知响应延迟latencyP50/P95/P99 响应时间。最贴近用户体验延迟升高往往比 CPU 升高更早。采集APMSkyWalking/Pinpoint、nginx upstream_response_time、Prometheus histogram。错误率error rate5xx 比例、超时数。错误率高的节点应快速摘除。请求队列深度queue depth应用线程池/连接池排队长度反映积压。GC 频率/耗时JVM 类服务Full GC 频繁 压力大。4.2 资源/系统层补充指标内存使用率 / swap可用内存低、swap in/out 活跃 内存压力。free、vmstat si/so。CPU 软中断softirq占比top的si列高说明网卡/内核在忙。CPU 上下文切换次数csvmstat的cs列异常高说明线程竞争激烈。句柄数 / 进程数lsof | wc -l、ps到达上限会拒绝服务。磁盘/内存满pressure signalKubernetes 的 node conditionDiskPressure/MemoryPressure/PIDPressure。4.3 基础设施层机房/网络延迟RTT节点间 ping用于就近性调度。电源/温度硬件负载均衡器/数据中心层关心。成本/价格多云环境下按单价调度spot 实例优先。4.4 指标分层速查表层次指标反映什么硬件/内核CPU% / load、iowait、softirq、cs、内存、swap、句柄机器底层压力网络连接数、带宽/pps、丢包、RTT网络侧压力应用延迟分位、错误率、队列深度、GC业务真实压力基础设施机房位置、成本、温度调度决策因素五、这些指标是如何采集的5.1 三种采集模式模式做法优缺点本地读取/proc / sysfs进程直接读内核暴露的伪文件成本最低最常用。Nginx/agent 都这么做主动探测pull监控系统定时去节点抓/metrics解耦集中管理。Prometheus 模式被动上报push节点上 agent 主动把指标推给中心实时性好适合短生命周期实例。StatsD/Telegraf5.2 关键指标采集来源速查指标采集源典型命令/接口CPU 使用率/负载/proc/stat、/proc/loadavgtop、vmstat、sar连接数/proc/net/tcp、/proc/net/netstat、netfilterss -s、/proc/sys/net/netfilter/nf_conntrack_count磁盘 I/O/proc/diskstatsiostat -x、/proc/diskstats网卡吞吐/proc/net/devsar -n DEV、/proc/net/dev内存/proc/meminfofree、vmstat进程级/proc/pid/*pidstat、/proc/pid/io、/proc/pid/status应用层暴露/metricsPrometheus 格式/metrics、APM 上报5.3 典型采集链路Prometheus 模式业界主流节点 cAdvisor/node_exporter --scrape-- Prometheus --query-- Adapter/网关 (暴露 /metrics) (TSDB存储) (HPA / 动态权重)node_exporter采 CPU/内存/磁盘/网络等机器指标。cAdvisor采容器指标。应用埋点采延迟、QPS、错误率Micrometer / OpenTelemetry。Prometheus Adapter把 Prometheus 的查询转成 Kubernetes 自定义指标 API供 HPA 用。Linux 直采模式轻量自研网关侧脚本 --read-- /proc/* --compute-- 压力分 -- 动态权重适合不想引入重型监控的中小系统成本极低。5.4 采集频率的取舍太低如 60s跟不上突发压力调度滞后。太高如 1s采集开销、抖动放大。经验值5–10s采集 EWMA 平滑是多数系统的甜点。HPA 默认 30s 扩缩容且带冷却时间防抖。5.5 指标采集的坑多核/多队列失真%util在 NVMe 多队列上会假满load 在多核上的基准是核数不是 1。容器里看不准容器/proc默认看到的是宿主机视图需 cgroup v2 或node_exporter的 cgroup 采集器CPU 要看cpu.cfs_quota_us配额而非宿主 load。时钟与平均窗口load average 的 1/5/15 分钟窗口对突发不敏感要实时还得看/proc/stat的差分。采集失败的处理超时/拉不到指标时绝不能当作压力 0否则该节点被当成最闲狂灌流量——典型故障源。六、总结一张图回答能不能、怎么配、用什么能不能根据系统压力分配 → 能叫动态负载均衡 / 资源感知调度 │ 怎么设置 │ ┌────┴───────────────────────────────────┐ │ 1. 采集node_exporter / /proc / APM │ │ 2. 归一pressure_score Σ wi * xi │ │ 3. 平滑EWMA 水位阈值摘除 │ │ 4. 分配动态权重 WRR / WLC / least-pressure │ │ 5. 解耦采集异步转发只读缓存 │ └─────────────────────────────────────────┘ │ 用什么指标 │ CPU负载 ── 计算型主力 连接数 ── I/O/长连接主力 I/O使用率── 存储/数据库主力 网卡吞吐 ── 网关/流量型主力 延迟/错误率/队列深度/GC应用层更贴近用户 内存/swap/softirq/cpuctxswitch系统层补充一句话收束负载均衡可以、也应该按系统压力分配做法是多指标加权归一 → EWMA 平滑 → 动态权重 WRR/WLC采集靠/proc Prometheus 体系并务必把采集与转发解耦、对失败降级保护。指标本身各有盲区组合用 加延迟/错误率这类用户感知指标才稳。相关文档[[任务分配器分配算法详解-从轮询到动态负载]] — 分配算法本身的演进[[任务分配器容量评估与规划-如何算QPS怎么压测怎么选型]] — 容量与压测[[Nginx负载均衡策略详解-配置与原理]] — least_conn 等原生策略[[任务分配器与业务服务器连接管理详细设计]] — 连接数指标的工程化
