2. 容量治理核心指标

容量治理的第一步不是“扩容”，而是把容量说清楚。物联网平台的成本之所以容易失控，往往是因为团队只盯着“设备总数”这一个数字，却忽略了连接、消息、存储、计算四条资源链路各自独立计费、独立瓶颈。本节把四类核心容量指标逐一拆开，说明它们的计量口径、典型量级，以及它们如何一步步转化为账单。

一、设备连接数：不是设备总数，而是并发连接峰值

设备连接数描述的是“同一时刻保持在线会话的设备数量”，单位是“个连接”或“并发连接”。它与设备台账里的注册总数是两个概念：注册 100 万台设备，如果只有 20 万台同时在线，计费与容量规划应以 20 万为准。连接数直接决定接入层网关的实例规格、长连接内存占用和 TLS 握手开销。

以 MQTT 接入为例，单台 4 核 8GB 的接入节点在开启 TLS、心跳 60 秒、QoS1 的常见配置下，可稳定承载约 5 万～8 万并发连接（示例经验值，需按实际压测校准）。若业务峰值需要 30 万并发连接，则至少需要 5～6 台节点并预留冗余。连接数还带来“连接时长”这一隐性成本：设备频繁断连重连会放大握手次数，推高 CPU 与认证调用量。

二、消息吞吐量：上行、下行与消息放大

消息吞吐量通常用“条/秒（TPS）”或“条/天”衡量，必须区分上行（设备→平台）、下行（平台→设备）和内部转发三类。物联网场景中一个常被低估的现象是消息放大：一条设备上报消息经规则引擎转发到 3 个下游系统，就产生 3 条内部消息；若再触发告警通知，还会叠加下行消息。计费与限流往往按“消息条数”而非“设备条数”结算，放大系数直接决定成本。

估算公式可写为：

日消息总量 = 设备数 × 单设备日均上报条数 × (1 + 转发放大系数)
峰值 TPS  ≈ 日消息总量 × 峰值集中系数 / 86400
示例：20 万设备 × 288 条/天 × (1 + 0.5) = 8640 万条/天
峰值 TPS ≈ 8640 万 × 0.15 / 86400 ≈ 1500 TPS

其中峰值集中系数表示业务高峰时段消息占比，示例取 0.15 属于合理假设。1500 TPS 的峰值决定了消息中间件分区数、消费组并发度和规则引擎实例数。

三、存储容量：时序数据、冷热分层与保留策略

存储容量按“GB·月”计费，核心变量是单条记录大小、写入频率和保留时长。以时序数据为例，一条包含设备 ID、时间戳、5 个测点的记录约 200 字节，20 万设备每 5 分钟上报一次：

日写入量 = 20 万 × 288 条 × 200 B ≈ 11.5 GB/天
保留 90 天 ≈ 1.04 TB（未计副本与索引膨胀）
若副本数 2、索引膨胀 1.3，实际占用 ≈ 2.7 TB

存储成本优化的关键不是压缩单条记录，而是冷热分层：近 7 天热数据放高性能存储供实时查询，7～90 天温数据降为低频存储，90 天以上归档或直接丢弃。保留策略每缩短一半，长期存储成本近似减半，但需与业务合规要求对齐。

四、计算资源：规则引擎、流处理与函数调用

计算资源以 vCPU·小时、函数调用次数或流处理 CU 计量。它由消息吞吐量和规则复杂度共同驱动：一条简单“字段过滤”规则消耗极低，而“窗口聚合 + 外部 API 调用 + 数据库写入”的规则会显著放大计算量。函数计算尤其要关注调用次数与执行时长两个维度，一次 200ms 的函数在 1500 TPS 下相当于持续占用约 0.3 个并发实例。

五、指标与成本的关联：从容量到账单

把四类指标串起来看，成本传导路径是清晰的：连接数决定接入层实例数与认证调用量；消息吞吐量决定中间件规格、规则引擎实例数和下行通知量；存储容量决定留存费用；计算资源决定流处理与函数费用。它们之间存在乘数关系，例如消息放大系数从 1.5 降到 1.2，日消息量就从 8640 万降到 6912 万，降幅约 20%，直接反映在消息费上。

因此容量治理的实操顺序建议是：先建立四类指标的采集口径（连接数取并发峰值、消息量区分上下行与内部转发、存储量按保留天数分层统计、计算量按规则与函数分别计量），再定位当前瓶颈链路，最后才决定扩容或优化。下面给出一份可直接填写的容量指标登记表示例：

掌握这四类指标的定义与传导关系后，后续的容量评估、压测和成本优化才有统一的度量基础。指标口径一旦统一，团队就能在“扩容”和“优化”之间做出有依据的取舍，而不是凭感觉加机器。