全云端架构踩坑：化工定位项目断网一次，系统就瘫痪

去年参与一个化工园区的人员定位系统项目，踩了一个让我印象深刻的坑。今天把踩坑和排查的过程记录下来，给做工业场景架构选型的同行提个醒。

一、坑是怎么踩的

项目初期，我们选了一套全云端解算的架构方案。逻辑上很通顺：定位数据全部回传云端，由云端引擎统一解算，现场不需要部署高算力硬件，后期算法迭代也方便。

试运行阶段，问题来了。

第一次异常出现在园区网络割接那天。运维按计划做网络割接，云端通信临时中断，现场所有定位和报警功能直接停摆。当时中控室的值班人员还以为只是大屏卡了，过了几分钟才发现是整个系统都连不上了。

后来复盘时我们算了一笔账：化工生产区的网络割接、临时断网属于常态化作业，如果每次断网定位系统都瘫痪，那这套系统的安全管控价值就要打问号了。

二、排查过程

我们开始排查问题到底出在哪。一开始怀疑是网络设备的问题，换了交换机、加了备用链路，但割接时系统还是会断。

后来把链路拆开看，才发现问题不在网络设备，而在架构本身：数据从信标到网关、云端、解算、下发报警，链路层级太多。只要其中任何一环断了，整个系统就失效。

我们还发现另外两个问题：数千个标签每秒30次上报原始数据，带宽开销比预期高不少；报警延迟受网络波动影响，端到端延迟在3-4秒左右波动，留给安全预警的余量很小。

三、试了几个方向

排查清楚问题后，我们试了几个调整方向。

第一个方向：加备用链路。 给云端通信加了4G/5G备用链路，有线断了自动切换。这个方案能缓解部分问题，但割接期间如果备用链路也不稳定，系统还是会受影响。

第二个方向：把解算下沉到边缘。 在现场部署边缘网关，本地完成定位解算，原始测距数据不再全部回传云端，只回传解算后的坐标结果。这个调整之后，割接时系统不再停摆了，本地预警功能可以持续运行。

第三个方向：调整感知层的部署策略。 之前我们想在全厂区统一用高精度设备，后来发现不同区域的需求本来就不一样。高风险区需要亚米级精度，普通区域米级覆盖就够用。把高精度设备集中在高风险区，普通区域用低成本方案，整体投入降了不少。

四、最后跑通的架构

几个方向调整完之后，我们最终跑通的架构是这样的：

终端侧负责采集位置数据，边缘侧本地完成定位解算，本地平台负责报警处置和数据存储。端到端报警延迟控制在1秒以内，断网期间本地预警功能不受影响。

感知层采用分级部署：高风险区用UWB信标保证精度，普通区用蓝牙信标做米级覆盖，数据回传统一走LoRa自组网，不需要大面积破路布线。老厂区改造全程不停产，部署周期2-4周。

本地服务器提供标准化API接口，可以对接企业现有的MES、WMS、电子作业票系统，也可以按照AQ 3064.3规范的数据格式要求，将数据加密上传至省级/园区级安全风险管控平台。

五、这个坑让我明白的事

这次踩坑让我对工业场景的架构选型有了几个新的判断：

第一，离线容灾不是可选项，是必选项。 工业现场的网络割接、临时断网属于常态化作业，任何依赖外部网络的架构，都要先回答“断网了怎么办”。

第二，数据安全合规要前置考虑。 人员定位数据涉及厂区人员轨迹、作业行为等敏感信息，本地存储更符合化工企业的数据安全管理要求，也便于应对监管部门的现场调阅。

第三，实时性指标要留足余量。 新规要求5秒内报警，如果架构本身的延迟就在3-4秒波动，那余量太小，经不起网络抖动。

第四，感知层不一定要统一。 不同区域的风险等级和精度需求本来就不一样，统一用最高精度设备，成本上不划算，也没必要。

如果你也在做类似场景的架构选型，希望这个踩坑记录能帮你少走点弯路。欢迎评论区交流你在项目中遇到的坑。