为什么单一指标无法判断节点健康状态
判断一个CDN节点是否可用，最简单粗暴的办法是看它能不能连通，其次是看延迟高不高。但真实运维场景远比这复杂。一个带宽打满的节点，延迟可能依然很低，因为它只是出口拥堵，ICMP探测一切正常；一个磁盘IO饱和的节点，回源请求大量堆积，缓存命中率骤降，但网络层面几乎看不出异常。反过来，某些节点各项网络指标都很漂亮，实际上后台进程已经出现内存泄漏，随时可能崩溃。
这说明节点的健康状态是一个多维概念，横跨网络层、传输层、应用层和资源层。任何单一指标都只反映了某个切面，用它做调度决策必然产生误判。举个例子，某视频平台早期仅以响应时间为依据做流量调度，结果某次区域故障中，故障节点的探测响应依然在合理范围内（因为探测请求太小），大量用户流量持续被调度过去，直到业务报错大面积爆发才被动切换。这类事故的核心教训是：健康判定必须建模成综合评分问题，而不是阈值判断问题。
综合评分的思路是把节点看作一个多属性决策对象，为每个维度设定指标，采集数据后归一化，再按权重聚合出一个0到100的分数。分数高代表节点状态良好，分数跌破阈值则触发调度降权或摘除。这个模型的关键在于：选哪些指标、如何归一化、权重怎么定，下面逐个展开。
四个核心维度与关键指标的选择
一个实用的评分体系不需要堆砌几十个指标，指标越多采集成本越高，边际价值反而下降。实践中通常收敛到四个维度：网络质量、服务能力、负载水平和稳定性。
网络质量维度关注节点与用户之间链路的体验，常用指标包括探测延迟、丢包率、TCP建连时间和首字节时间。这类数据由分布在各地的拨测点周期性采集，建议每个节点至少覆盖三个以上不同运营商的拨测源，避免单运营商链路抖动造成误判。丢包率是其中区分度最好的指标，轻微丢包对大文件传输的影响远超对探测包的影响，权重应该适当调高。
服务能力维度衡量节点实际处理业务的能力，核心指标是缓存命中率和回源成功率。命中率下降往往意味着节点本地缓存被污染或容量不足，回源压力增大，会连锁引发源站负载升高。此外HTTP状态码分布也值得纳入，5xx比例上升是应用层故障最直接的信号，比网络探测更早暴露问题。
负载水平和稳定性两个维度决定了节点的可持续服务能力。负载维度包括CPU使用率、内存使用率、磁盘使用率、带宽利用率，其中带宽利用率最关键，因为CDN的资源瓶颈通常在带宽。稳定性维度则看时间序列特征，比如最近一小时内指标是否剧烈波动、进程是否发生过重启、探测结果是否出现间歇性超时。波动大的节点即使当前各项数值正常，也应扣分，因为不稳定的节点随时可能恶化。
| 维度 | 代表指标 | 采集方式 | 建议权重 |
|---|---|---|---|
| 网络质量 | 延迟、丢包率、建连时间 | 多运营商拨测 | 30% |
| 服务能力 | 缓存命中率、5xx比例、回源成功率 | 日志与访问统计 | 30% |
| 负载水平 | 带宽利用率、CPU、内存、磁盘 | 节点Agent上报 | 25% |
| 稳定性 | 指标波动率、重启次数、超时频率 | 时序数据分析 | 15% |
权重并非一成不变，视频类业务可以调高网络质量权重，动态加速类业务则应提高服务能力维度权重。权重的设计本质上是对业务SLA的量化表达，建议通过历史故障复盘来校准，让模型给出的低分节点尽量与真实故障节点重合。
指标归一化与评分聚合的实现
不同指标的量纲差异巨大，延迟用毫秒，命中率用百分比，重启次数是整数计数，直接加权求和没有意义，必须先做归一化。常用方法有线性映射和分段函数两种。对于延迟这类指标，可以设定理想值和可接受上限，落在两者之间线性衰减；对于丢包率这种存在突变语义的指标，分段函数更合适，丢包0.1%以内算满分，超过3%直接接近零分，中间区间平滑过渡。
下面给出一个简化的评分计算示例，用Python实现：
def normalize(value, good, bad):
"""线性归一化，good为理想值，bad为不可接受值"""
if value <= good:
return 1.0
if value >= bad:
return 0.0
return (bad - value) / (bad - good)
def node_health_score(metrics):
# 网络质量维度，权重0.30
net = (
normalize(metrics["rtt_ms"], 20, 200) * 0.4
+ normalize(metrics["loss_pct"], 0.1, 3.0) * 0.4
+ normalize(metrics["connect_ms"], 30, 300) * 0.2
)
# 服务能力维度，权重0.30
svc = (
normalize(100 - metrics["hit_ratio"], 0, 40) * 0.6
+ normalize(metrics["error_5xx_pct"], 0, 5) * 0.4
)
# 负载维度，权重0.25
load = (
normalize(metrics["bandwidth_util"], 60, 100) * 0.6
+ normalize(metrics["cpu_util"], 70, 100) * 0.4
)
# 稳定性维度，权重0.15
stable = (
max(0, 1 - metrics["reboot_count"] * 0.5) * 0.5
+ (1 - min(metrics["fluctuation"], 1)) * 0.5
)
return net * 0.30 + svc * 0.30 + load * 0.25 + stable * 0.15
# 示例节点数据
node = {
"rtt_ms": 45, "loss_pct": 0.3, "connect_ms": 60,
"hit_ratio": 88, "error_5xx_pct": 0.5,
"bandwidth_util": 75, "cpu_util": 60,
"reboot_count": 0, "fluctuation": 0.2,
}
print(node_health_score(node) * 100) # 输出综合评分聚合方式上，加权平均是主流做法，但要注意它的一个缺陷：低分项会被高分项稀释。一个丢包率高达5%的节点，如果其他指标都正常，加权平均后仍有七八十分，显然不符合直觉。解决办法是引入一票否决或惩罚机制，比如任一关键指标低于0.2时，最终分数乘以惩罚系数，或者直接把节点标记为不可用。调度系统通常会把节点分成三档：80分以上正常参与调度，60到80分降权调度，60分以下摘除并告警。
动态权重、数据质量与工程落地要点
静态权重模型上线后，很快会遇到新问题。大规模突发流量期间，带宽利用率整体升高，如果负载维度权重固定，所有节点分数同步下降，评分失去区分度。合理的做法是引入动态权重：当检测到区域性网络劣化时，临时提高服务能力和稳定性维度权重，让真正扛得住业务的节点优先获得流量。也可以用历史数据训练权重，比如收集故障样本，统计哪些指标在故障前最先异常，据此调整维度权重配比。
数据质量往往比模型本身更影响效果。拨测点覆盖不足会让某些节点长期没有网络数据，评分默认给满分或零分都会造成调度偏差，正确处理是按数据新鲜度衰减：超过五分钟没有新数据的指标项，其权重自动转移给同维度其他指标，整个节点长时间无数据则进入未知状态，调度上保守处理。另外要注意指标采集本身的资源开销，高频探测和全量日志分析在万级节点规模下成本可观，可以采用分层采集策略，健康节点低频采样，异常节点自动提升采样频率。
最后是落地节奏的建议。新模型不要直接接管调度，先以旁路模式运行一段时间，只输出分数和告警，由人工对比模型判断与实际故障的吻合度，迭代归一化参数和权重后再逐步放开自动调度权限。评分结果还应该持久化存储，形成节点健康历史曲线，这对容量规划、故障复盘和节点扩缩容决策都有很高的参考价值。一个持续校准的评分模型，会让整个CDN体系的稳定性提升进入正向循环。