3. 离线检测与状态管理：连接性探针、状态机设计、切换阈值、心跳异常处理
离线友好网络层的核心挑战是从“无感在线”过渡到“优雅降级”，而非简单粗暴的断网提示。本章将离线检测与状态管理拆解为四个紧密关联的模块：连接性探针负责采集原始可达性数据，状态机维护网络连接的生命周期，切换阈值控制状态转移的灵敏度，心跳异常处理应对瞬时抖动与长期中断。这些模块共同构成网络层离线检测与决策的闭环。
3.1 边界与分层定位
离线检测应当位于网络层内部，与应用层业务隔离。其职责边界是：
- 上边界：不直接暴露原始探针结果给业务层，只输出归一化后的连接状态枚举。
- 下边界：不替代传输层（TCP）的拥塞控制，仅检测端到端可达性与延迟。
- 左右边界：与缓存层、RPC 层通过标准状态回调接口协作，避免循环依赖。
在分层架构中，离线检测与状态管理属于网络层附属子系统，通常实现为一个独立模块，暴露以下服务：
- 状态查询（同步/异步）
- 状态变化订阅（Observer 模式）
- 探针控制（启动/停止/配置）
3.2 组件职责
| 组件 | 核心职责 |
|---|---|
| 连接性探针 （Health Probe） | 按固定时间间隔向目标端点发送 PING / HTTP HEAD / DNS 查询，收集延迟、丢包率、HTTP状态码。输出：原始探针结果。 |
| 状态机 （Connectivity State Machine） | 维护 Online → Limited → Offline 状态转换，根据探针数据和切换阈值做出状态跃迁决策。输出：当前状态及持续时间。 |
| 切换阈值引擎 （Threshold Engine） | 定义每个状态转换的触发条件，支持动态调整（如根据历史基线、业务优先级）。输出：满足切换条件的布尔值。 |
| 心跳异常处理器 （Heartbeat Anomaly Handler） | 监听心跳超时、连续失败、响应模式异常。可触发快速状态回退或降级回调。输出：异常分类与建议动作。 |
3.3 数据流 / 控制流 / 信任链路
关键数据流：
探针实例（Ping/HTTP/DNS） → 原始探针结果队列 → 阈值引擎（滑动窗口统计） → 状态机（状态转移） → 状态发布（订阅者） → 切换执行器（路由/缓存策略调整）
探针实例（Ping/HTTP/DNS） → 原始探针结果队列 → 阈值引擎（滑动窗口统计） → 状态机（状态转移） → 状态发布（订阅者） → 切换执行器（路由/缓存策略调整）
控制流由状态机主导：外部配置中心推送新阈值 → 阈值引擎重新计算 → 状态机根据新条件更新状态。心跳异常处理作为独立支线，一旦触发，优先对状态机产生“紧急降级”事件。
信任链路要求：探针数据源必须经过防篡改校验（应用层签名），状态机输出必须幂等，避免重复通知导致切换震荡。
3.4 选型权衡
| 维度 | 选项 | 优势 | 风险 |
|---|---|---|---|
| 探针类型 | ICMP Ping | 轻量、底层、低开销 | 可能被防火墙屏蔽；无法反映应用层可用性 |
| HTTP HEAD / TCP Connect | 更贴近业务可达性 | 延迟开销大；需目标服务配合 | |
| 阈值策略 | 固定阈值（如连续 3 次超时即离线） | 简单可预期 | 网络抖动易导致误切换 |
| 自适应阈值（基于历史 RTT 的移动平均 + 3σ） | 减少误判，适应不同网络环境 | 实现复杂；冷启动阶段数据量不足 | |
| 心跳间隔 | 短间隔（1~3s） | 快速响应 | 高电量/带宽消耗 |
| 长间隔（10~30s） | 节省资源 | 离线检测滞后，影响用户体验 |
推荐默认组合：混合探针（主用 HTTP HEAD，备用 ICMP Ping）；阈值采用基于滑动窗口的 60% 失败率（窗口大小=5 次）；心跳间隔 5s，连续 2 次失败进入 Limited，连续 4 次进入 Offline。
3.5 风险点与应对
- 误切换（假阳性）：瞬时网络抖动导致错误离线。应对：设置“确认延迟期”（如在 Offline 前先进入 Limited 状态停留 2 个周期）；启用抖动抑制（忽略单次超时后立即恢复的样本）。
- 漏切换（假阴性）：探针选择不当导致检测不到真实中断。应对：至少部署两种探针，并使用独立线程/协程；对临界状态执行额外验证（如并行探测）。
- 状态不一致：集群中多节点状态不同步。应对：状态机输出附带版本号；通过一致性哈希将同一用户/业务路由到状态一致的节点。
- 探针资源泄露：长期运行导致 socket/线程泄漏。应对：为探针设置生命周期超时；探针实例采用对象池 + 自动回收。
3.6 落地步骤
- 定义连接性探针工厂：支持 ICMP、TCP、HTTP 等类型，每个探针携带独立配置（间隔、超时、目标地址）。
- 实现滑动窗口与统计聚合：对最近 N 次探针结果维护一个环形缓冲区，计算失败率、平均延迟。
- 构建状态机核心：采用有限状态机驱动，状态包括 Online、Limited、Offline、Unknown（初始态）。每个状态定义允许的入口事件和出口条件。
- 设计阈值引擎配置：支持运行时热更新（通过配置中心），提供“切换阈值”、“降级恢复延迟”、“最小稳定时间”等参数。
- 集成心跳异常处理器：单独注册异常检测钩子，监听超时、重复失败模式。当检测到突发连续失败（如 5/5 全失败）时，跳过 Limited 直接进入 Offline。
- 发布状态变更事件：状态机输出严格的事件接口，包含新旧状态、时间戳、触发原因。下游网络路由层、缓存层、UI 层分别注册监听。
- 测试与灰度：在测试环境模拟丢包、延迟、缓慢恢复等场景；生产环境按 1%→10%→全量逐步放开。
3.7 验收标准
| 维度 | 指标 | 合格线 |
|---|---|---|
| 离线检测延迟 | 从真实断网到状态机输出 Offline 的时间 | ≤ 15s |
| 切换准确率 | 真实离线事件中被正确标记为 Offline 的占比 | ≥ 99% |
| 误判率 | 网络正常时被错误标记为 Offline/Limited 的占比 | ≤ 0.5% |
| 状态震荡次数 | 10 分钟内状态翻转超过 3 次的比例 | ≤ 1% |
| 探针资源消耗 | 单探针 CPU 占用 + 内存使用 | CPU ≤ 5%，内存 ≤ 1MB |
3.8 离线检测与状态管理核心流程
常见陷阱：将状态机实现为简单的“在线/离线”二元状态，忽略 Limited 中间态，会导致频繁状态翻转。务必保留 Limited 作为缓冲区，并设置最小驻留时间（如 10s）。另外，不要将业务层重试与网络层探针混为一谈——探针负责感知，重试负责恢复，两者需要不同的超时与幂等策略。