健康检查在 CDN 里经常被当成一个配置项：填个 URL，设个间隔，失败三次摘节点，真到故障时，你会发现它要么太敏感，把好节点全摘了；要么太迟钝，用户已经骂了十分钟，它还说一切正常，健康检查的本质，是用有限探测去推断业务可用性的一套统计决策系统，探测只是传感器，判定、调度、恢复才是闭环。
先拆概念：健康检查到底在检查什么
四层健康检查看 TCP 握手和端口，它快、轻、误判相对少，但端口通不代表业务通，HTTP 500、TLS 证书过期、返回错误页、依赖数据库挂了，四层都可能显示健康。
七层健康检查看 HTTP/HTTPS 语义：Host、SNI、Path、Method、期望状态码、响应体关键字、响应时间，它更贴近业务，但成本更高，也更容易被缓存、鉴权、限流、WAF 干扰，比如你探 /health 返回 200，但真实业务路径已经 503，这种健康检查就是心理安慰。
健康检查，CDN 里最容易被低估的故障传感器
主动健康检查由探测源定时发请求,可控、可复现、发现快，缺点是探测流量、覆盖有限，而且探针路径未必等于用户路径，被动健康检查依赖真实流量、边缘日志、RUM、成功率和首包数据，真实全面，但冷门节点没流量时就是盲区，往往等用户先发现问题。
判定策略同样关键,连续失败阈值、成功恢复阈值、超时、重试、抖动抑制，决定了你是快速止损还是频繁误杀，硬故障如连接拒绝、超时，可以快摘；软故障如错误率升高、延迟抖动，应该慢摘、降权，而不是一刀切。
CDN 场景下，健康检查至少分四层
第一层是调度层,包括 GSLB、HTTP DNS，它检查边缘节点或机房是否健康，决定用户解析到哪，适合机房级容灾，但受 DNS TTL 和客户端缓存影响，切换会有滞后。
第二层是边缘回源层,边缘节点或回源代理检查源站、中间源，决定主备源切换、多源负载和区域回源，这是 CDN 健康检查最该做细的一层，因为某个源站可能对华东健康，对华南异常；集中探测说健康，不代表每个边缘回源都健康。
第三层是负载均衡和网关层,L4/L7 检查后端池，决定容器、VM 是否摘除，频率高、动作快，适合动态源站。
第四层是客户端侧观测,RUM、拨测、日志不是传统健康检查，但能校准主动探测的盲区，比如主动探测全绿，真实用户却大量超时，这时要相信被动数据。
方案对比：没有银弹，只有组合拳
主动 vs 被动：主动适合快速发现硬故障，被动适合发现真实业务劣化，生产环境建议主动兜底，被动校准，主动异常时触发被动确认，被动异常时加密主动探测。
集中 vs 分布：集中探测管理简单、结果一致，但视角单一；分布式探测贴近用户，能发现地域、运营商问题，但聚合复杂，容易误报，CDN 天然分布式，可以考虑核心源站集中探，边缘节点分布式探，再做多数派或分区判定。
四层 vs 七层：四层快，适合快速摘除；七层准，适合最终判定，常见做法是四层探端口，七层探业务路径，两者都过才算健康。
GET vs HEAD：HEAD 省流量，但有些源站不支持或语义不一致，GET 一个小对象更真实，但要注意绕过缓存、带鉴权、限制日志，别让健康检查自己变成 DDoS。
适用场景怎么选
静态资源回源,建议 GET 一个小文件，检查 200/206、Content-Length、ETag，不要只探首页，动态 API，用只读探针检查 JSON 里的业务状态，不要用写接口，直播和流媒体，TCP/TLS 握手加播放列表、切片探测，关注首包和卡顿，ICMP 基本没意义，多活容灾，适合分布式探测加地域聚合，再加人工确认阈值，避免全网同时切换，K8s 场景下，readiness 和 CDN 回源健康检查最好解耦，别让 CDN 高频探针打爆 kubelet 或业务日志。
选型建议：先定故障模型，再调参数
第一,先定义 SLO 和故障模型，你要发现端口挂、HTTP 5xx、内容错误、慢节点、地域故障中的哪些？目标不同，探针和阈值完全不同。
第二,分层配置，调度层低频、粗粒度、多探测源；边缘回源层高频、细粒度、分池；负载均衡层快频率、快摘除，不同层不要共用一套阈值。
第三,主动加被动，主动发现，被动确认，只看主动，容易误杀；只看被动，冷节点永远沉默。
第四,参数别拍脑袋，超时 1-3 秒，间隔 5-10 秒，失败 3 次，恢复 2-3 次，加随机抖动防共振，核心业务可以更敏感，但必须配熔断、降权和灰度恢复。
第五,探测请求要轻、可区分、绕过缓存、带鉴权、限制日志，否则健康检查本身就会成为故障源。
第六,摘除要渐进，恢复要更慢，多源站先降权再摘除，避免抖动，观测指标至少包括 MTTD、MTTR、误摘率、切换次数和探测成功率。
健康检查不是“能 ping 通就行”，而是让流量避开坏路径，同时不误杀好路径，它更像 CDN 的神经系统，平时不起眼，关键时刻决定你是优雅容灾，还是全网雪崩。
发表评论