📚 课程目录第2章设备接入层性能指标设计

2. 设备接入层性能指标设计

设备接入层是 IoT 平台的第一道关口，它直接面对海量终端、弱网环境和不稳定的供电条件。接入层性能指标如果设计得含糊，后续的容量规划、告警阈值和故障定位都会失去依据。本节围绕四个核心指标——连接成功率、消息吞吐量、时延分布、断连重连率——说明它们的采集点、计算方式和业务含义，并给出可落地的实现思路。

一、先明确采集点：指标从哪里来

接入层通常由接入网关（MQTT Broker 集群、CoAP/HTTP 网关）、鉴权服务、会话存储和消息路由组成。指标采集点必须落在这些组件的关键路径上，而不是在业务侧“估算”。

连接成功率：采集点在接入网关的 TCP/TLS 握手完成、协议层 CONNECT 报文处理完成、鉴权返回结果三处。只有三者都成功，才计为一次成功连接。
消息吞吐量：采集点在网关的入站报文解析后、出站报文编码前，以及消息路由的转发队列。入站与出站要分开统计，避免上下行互相掩盖。
时延分布：采集点包括设备到网关的网络 RTT、网关内部处理耗时、路由转发耗时、端到端确认耗时。至少区分 P50、P95、P99。
断连重连率：采集点在会话管理模块，记录正常断开（DISCONNECT）、异常断开（心跳超时、TCP RST）以及重连请求的会话标识。

采集点必须带时间戳和设备/会话标识，否则无法把连接、消息、断连关联到同一台设备，也就无法判断是单设备问题还是集群问题。

二、连接成功率：定义与计算

连接成功率不能简单用“成功次数 / 总尝试次数”，因为总尝试次数里可能混入了重试。推荐按“首次连接尝试”和“含重试的最终成功率”两个口径分别统计。

首次连接成功率 = 首次 CONNECT 成功数 / 首次 CONNECT 尝试数
最终连接成功率 = 最终建立会话的设备数 / 发起连接的设备数
鉴权失败率     = 鉴权拒绝数 / CONNECT 请求数

业务含义上，首次成功率反映设备出厂配置、证书和网络环境的整体健康度；最终成功率反映平台对弱网和重试的容忍能力。若首次成功率低但最终成功率高，说明重试机制有效，但设备侧体验差、功耗高；若两者都低，则要排查鉴权服务、证书过期或网关容量。

三、消息吞吐量：入站、出站与有效载荷

吞吐量要区分“报文数/秒”和“有效载荷字节/秒”。很多平台只统计报文数，结果大量小报文把连接数打满，实际业务数据量却很小。建议同时记录：

入站消息速率（msg/s）与入站字节速率（B/s）；
出站消息速率与出站字节速率；
按 QoS 等级拆分：QoS0 不落盘、QoS1 至少一次、QoS2 恰好一次，三者的吞吐成本差异很大；
按主题前缀或产品维度拆分，便于定位是哪个业务在打满带宽。

计算时使用滑动窗口，例如 1 分钟窗口内每 10 秒采样一次，再取均值与峰值。业务含义是：均值决定容量规划，峰值决定限流和扩容策略。若入站峰值持续接近网关处理上限，即使平均利用率只有 40%，也可能在突发时出现丢包和时延飙升。

四、时延分布：不要只看平均值

接入层时延至少包含四段：设备到网关的网络时延、网关协议解析与鉴权时延、消息路由与队列时延、端到端确认时延。平均值会被大量正常请求拉低，掩盖长尾问题，因此必须看分布。

端到端时延 = t_ack - t_publish
P95 时延   = 95% 的请求时延小于该值
超时率     = 时延 > 阈值 的请求数 / 总请求数

示例阈值可设为：QoS0 端到端 P95 小于 200 ms，QoS1 小于 500 ms，QoS2 小于 1 s。若 P99 远高于 P95，通常说明存在队列积压、GC 停顿或个别慢节点。业务含义是：P95 决定大多数设备的体验，P99 决定告警和重试策略，超时率决定是否触发熔断。

五、断连重连率：区分正常与异常

断连重连率要拆成三个量：断连率、重连成功率、重连频次。正常断开（设备主动 DISCONNECT）不应计入异常断连。异常断连包括心跳超时、TCP RST、网关主动踢除和鉴权过期。

异常断连率 = 异常断连次数 / 在线会话数
重连成功率 = 重连成功次数 / 重连尝试次数
重连频次   = 单位时间内单设备重连次数

业务含义：异常断连率高，说明网络或设备电源不稳定；重连成功率低，说明网关或鉴权在重连风暴下不可用；重连频次高但每次都能成功，说明设备在“抖动”，会持续消耗连接资源和电量。工程上通常对单设备设置重连频次阈值，例如 5 分钟内超过 10 次即标记为异常设备并限流。

六、把四个指标串起来看

单独看任何一个指标都容易误判。例如连接成功率 99.9% 看似很好，但如果断连重连率很高，说明设备在反复重连，实际在线稳定性差；吞吐量很高但时延 P99 超过 2 秒，说明系统在过载边缘运行。建议在监控面板上把四个指标放在同一时间轴上，并叠加设备数、网关 CPU、队列深度等资源指标，形成“现象—原因”的对照。

一个可用的接入层健康度判断顺序：先看连接成功率是否低于 99%，再看异常断连率是否超过 1%，然后看 P95 时延是否超过业务阈值，最后看吞吐量峰值是否接近网关处理上限。四者中任意一项越界，都应触发对应层级的告警。

七、采集实现要点

在实现上，接入网关应暴露结构化指标，例如通过 Prometheus 格式输出：

iot_connect_attempts_total{result="success|auth_fail|timeout"}
iot_messages_in_total{qos="0|1|2"}
iot_messages_out_total{qos="0|1|2"}
iot_message_latency_seconds_bucket{le="0.2|0.5|1|2"}
iot_disconnect_total{reason="normal|heartbeat_timeout|tcp_reset|kicked"}
iot_reconnect_attempts_total{result="success|fail"}

时延用直方图桶而不是平均值，便于计算分位数；断连原因用标签区分，避免把正常断开算进异常。采集频率建议 10～15 秒一次，过密会增加网关负担，过疏会漏掉突发抖动。所有指标都应带设备产品、区域、网关节点等维度，方便按业务切片分析。

最后要强调：指标设计不是一次性的。设备规模、协议版本、网络制式变化后，阈值和采集点都要重新校准。建议每季度用真实设备做一次接入压测，验证四个指标在目标规模下是否仍然可观测、可告警、可定位。