1. 制造时序平台高可用工程导论

制造时序平台是承载产线设备状态、工艺参数、质量检测结果与能耗数据的核心基础设施。它需要把来自PLC、SCADA、OPC UA网关、边缘采集盒与MES系统的数据，以秒级甚至毫秒级频率写入时序数据库，并向看板、报警、追溯、SPC分析与AI模型持续提供查询服务。一旦平台不可用，轻则看板延迟、报警漏发，重则工艺追溯断链、批次质量无法判定。因此，高可用不是附加功能，而是制造时序平台的基础工程属性。

课程目标与高可用的定义

本课程的目标是让读者具备“设计—部署—观测—切换—复盘”制造时序平台高可用能力的完整工程视角。具体包括：理解制造时序数据的写入与查询特征；掌握采集链路、消息缓冲、时序存储、查询服务各层的高可用设计方法；能够为关键组件设定可量化的可用性目标；能够通过指标、日志与演练判断系统是否真正具备故障切换能力。

高可用（High Availability，HA）通常用可用性公式衡量：可用性 = 平均无故障时间 /（平均无故障时间 + 平均修复时间）。例如某平台年计划运行365天，全年累计不可用时间为52.6分钟，则可用性约为99.99%；若累计不可用时间为8.76小时，则约为99.9%。制造场景中，不同业务对可用性的要求并不相同：实时报警与联锁相关链路通常要求99.99%以上，历史追溯与报表可接受99.9%，而离线模型训练对在线可用性要求更低。高可用的本质不是“永不出故障”，而是故障发生时业务影响可控、恢复时间可预期、数据不丢失或可补偿。

制造时序数据的典型特征

制造时序数据与互联网监控数据有明显差异，理解这些差异是设计高可用方案的前提。

• 写入频率高且稳定：一条汽车焊装线可能有数百台机器人，每台机器人每秒上报数十个关节电流、温度与节拍点，单厂写入量可达每秒数十万点。
• 时间戳强绑定：数据必须与设备时钟、工位节拍、批次号对齐，时间戳错乱会直接导致追溯失效。
• 标签维度多：设备ID、产线、工位、工艺段、物料批次、班次等标签组合，使单条测点的时间线数量庞大。
• 冷热分层明显：最近数小时至数天的数据用于实时看板与报警，数月甚至数年的数据用于质量追溯与模型训练。
• 乱序与补传常见：边缘网络抖动、网关重启、设备缓存补发都会造成数据迟到，平台必须支持乱序写入与去重。
• 写入与查询并发：产线不停机，写入持续不断；同时看板、报警、追溯查询也在并发访问，资源竞争明显。

这些特征决定了制造时序平台的高可用不能只靠“数据库主从”解决，而必须覆盖采集、传输、缓冲、存储、查询与消费的整条链路。

平台典型架构与可用性挑战全景

一个典型的制造时序平台通常分为五层：边缘采集层（PLC/传感器/OPC UA网关）、接入与缓冲层（MQTT/Kafka/边缘缓存）、时序存储层（时序数据库集群）、查询与服务层（查询网关、报警引擎、API）、消费层（看板、MES、SPC、AI平台）。每一层都有各自的单点风险与高可用手段。

下面这张图把五层架构、关键组件、典型故障点与对应的高可用手段放在同一张关系图中，便于建立全景认知。

从架构到工程：可用性挑战的落地判断

有了全景图，还需要把“高可用”落到可观测、可判断的工程指标上。制造时序平台最值得关注的四个端到端指标是：写入成功率、数据新鲜度、查询成功率与P99延迟、故障恢复时间（RTO）与数据丢失窗口（RPO）。

以一个示例场景说明：某工厂有3条产线，共1200个测点，采集频率为1秒/点，则理论写入速率为1200点/秒。若平台在早班高峰出现Kafka消费积压，数据新鲜度从2秒恶化到90秒，看板仍能显示但已失去实时意义。此时即使“服务没宕”，也不能算高可用。因此，判断标准应写成可执行的门槛，例如：

需要强调的是，上表中的数值是教学示例，实际项目中应根据产线节拍、质量追溯要求和运维人力共同确定。高可用工程的第一步，就是把这些目标写进设计文档，而不是等故障发生后再讨论“算不算可用”。