3. 工业物联网场景下的性能指标体系
在工业物联网（IIoT）系统中，性能不是一个单一维度的概念。一条产线每秒上报 5000 个测点、云端看板延迟 3 秒刷新、边缘网关断网 40 秒后自动补传——这些现象分别对应吞吐量、延迟、可用性与数据完整性等不同指标。如果只盯着“系统快不快”，往往会在真正出问题时找不到根因。本节把 IIoT 性能拆成六个可度量、可验证、可写入 SLA 的指标维度，并说明它们在 ThingWorx 架构中的落点。
六个核心指标的定义与边界
吞吐量（Throughput）指单位时间内系统成功处理并持久化的数据量或事务数，常用单位是“消息/秒”“测点写入/秒”或“事务/分钟”。它衡量的是“容量”，不是“速度”。在 ThingWorx 中，吞吐量通常受三处约束：设备侧采集频率、Edge 与 Platform 之间的 WebSocket/HTTP 通道带宽、以及 Platform 端 Stream 与 Value Stream 的写入能力。注意区分“峰值吞吐”与“稳态吞吐”：峰值可能靠缓冲撑住，稳态才反映长期承载能力。
延迟（Latency）指数据从产生到可被消费或可见所经历的时间，通常拆成采集延迟、传输延迟、处理延迟和呈现延迟四段。工业场景对延迟的容忍度差异极大：运动控制闭环要求毫秒级，而设备健康趋势分析可以接受秒级甚至分钟级。因此延迟指标必须绑定具体链路，例如“从 PLC 扫描到 ThingWorx 属性更新”的端到端延迟，而不是笼统的“系统延迟”。
可用性（Availability）指系统在约定时间内可正常提供服务的时间比例，常用“9 的个数”表达：99.9% 对应年停机约 8.76 小时，99.99% 对应约 52.6 分钟。IIoT 可用性要区分“平台可用”与“数据链路可用”——平台在线但边缘网关离线，对业务而言仍是不可用。可用性通常用 MTBF（平均无故障时间）和 MTTR（平均修复时间）计算：Availability = MTBF / (MTBF + MTTR)。
数据完整性（Data Integrity）指数据在采集、传输、存储全过程中不丢失、不重复、不错序、不被篡改的程度。工业数据完整性常用“完整率”度量：应到测点数与实际入库测点数之比。断网补传、去重、时间戳对齐、校验和都是保障完整性的手段。完整性一旦破坏，后续分析和 AI 模型都会失真，因此它常被列为比延迟更优先的指标。
恢复时间目标（RTO）指故障发生后，业务恢复到可接受服务水平所允许的最长停机时间。它回答“能停多久”。恢复点目标（RPO）指故障发生时，允许丢失的数据时间窗口。它回答“能丢多少”。RTO 与 RPO 是一对约束：RTO 决定恢复速度（热备、自动切换、容器重启），RPO 决定备份与同步频率（实时同步、分钟级快照、小时级归档）。
关键区分：吞吐量看“容量”，延迟看“速度”，可用性看“在线比例”，完整性看“数据质量”，RTO 看“停机时长”，RPO 看“数据丢失窗口”。六者互相制约，优化时必须明确优先级。
指标如何落到 ThingWorx 的具体对象上
把指标映射到平台对象，才能被监控和优化。吞吐量对应 Stream 与 ValueStream 的写入速率，以及 Thing 属性更新频率；延迟对应 RemoteThing 的 polling 周期、Edge 的 WebSocket 推送间隔、以及 Mashup 的 AutoRefresh 设置；可用性对应 Platform 集群节点、ThingWorx Foundation 服务与 Edge 网关的在线状态；数据完整性对应 Edge 的 Store and Forward 队列、Thing 属性的 persistent 标志与时间戳质量码；RTO/RPO 则对应数据库备份策略、PostgreSQL 主从切换、以及 Edge 本地缓存的保留窗口。
示例：一条产线监控链路的指标设定
假设某产线有 200 个测点，采集周期 500ms，即理论吞吐约 400 测点/秒。若要求端到端延迟不超过 2 秒、数据完整率不低于 99.9%、可用性 99.9%、RTO 5 分钟、RPO 1 分钟，则可推导出：Edge 本地队列至少能缓存 1 分钟数据（约 24000 个测点），Platform 侧 Stream 写入能力需留 2 倍余量（约 800 测点/秒），数据库需每分钟做一次增量快照。这些数字是示例假设，实际项目需按现场压测结果调整。
| 指标 | 示例目标值 | 主要观测点 | 典型优化手段 |
|---|---|---|---|
| 吞吐量 | ≥ 800 测点/秒（2 倍余量） | Stream 写入速率、Edge 发送队列 | 批量写入、压缩、提高采集聚合粒度 |
| 延迟 | 端到端 ≤ 2 秒 | Edge 推送间隔、Mashup 刷新周期 | 减少中间跳数、启用推送替代轮询 |
| 可用性 | ≥ 99.9% | Platform 节点、Edge 在线状态 | 集群部署、网关双机、健康检查 |
| 数据完整性 | ≥ 99.9% | 补传队列、入库计数比对 | Store and Forward、去重、时间戳对齐 |
| RTO | ≤ 5 分钟 | 故障切换耗时、服务重启时间 | 热备、自动故障转移、容器化 |
| RPO | ≤ 1 分钟 | 备份间隔、同步延迟 | 增量快照、流式同步、Edge 缓存 |
实践建议：先确定业务可接受的 RTO/RPO，再反推可用性与完整性目标，最后用吞吐量和延迟验证架构是否撑得住。顺序反了，容易做出“很快但会丢数据”的系统。
常见误区：把“平均延迟”当作唯一延迟指标。工业场景更应关注 P95/P99 延迟，因为偶发的长尾延迟可能直接导致控制指令超时或看板数据跳变。
六个指标不是并列关系，而是有优先级的约束体系。对大多数 IIoT 场景，数据完整性和可用性优先于延迟，延迟优先于吞吐量；RTO/RPO 则是兜底约束，决定系统在极端故障下的可恢复边界。理解这一点，才能在 ThingWorx 中做出合理的参数取舍与架构决策。