前两年我负责一个跨工厂的M2M/IoT Integration Platform项目压力测试当天出了个让我睡不着觉的P0两万台设备同时上报数据消息网关先卡死紧接着数据库写入延迟直接崩掉最终生产数据丢了近四万条。这次事故之后我把这套平台从设备接入、数据采集、OTA升级到边缘网关的整个链路全部重写了一遍。这篇文章不聊PPT架构只讲我在这个M2M/IoT集成平台上真正踩过的坑、拆过的组件、验证过的方案适合正在自研或准备选型IoT平台的团队参考。1. 先把边界画清楚M2M/IoT集成平台到底应该管哪些事很多团队把IoT平台理解成“设备把数据发到云端就算结束”这是第一个坑。真正的M2M/IoT Integration Platform要管的不是一条单向数据流而是设备全生命周期的四件事设备接入、连接管理、数据处理、反向控制与升级。如果一开始只按“数据采集通道”设计后面业务侧要求远程重启设备、批量升级固件时整个平台都要推倒重来。我在项目初期就吃到了这个教训。当时业务方说只需要“把设备数据拿过来看看”结果平台上线两个月现场要求增加远程参数修改第四个月要求支持固件灰度升级到了第七个月还要我们把每台设备的全生命周期档案做成报表。这些需求逼着平台从“数据管道”演化成“设备中枢”这一步如果架构上没有预留后期就是灾难。1.1 设备接入层不是“连上网”就结束了我们接入的设备大概分四类Modbus TCP 的 PLC、OPC UA 的数控系统、MQTT 的传感器网关、还有几款走私有 TCP 协议的定制设备。每一类的报文格式完全不一样有的用大端字节序有的还带 CRC 校验有的心跳包三秒一发。如果让每台设备直连业务接口代码会迅速变成一团乱麻。我们的做法是做一个统一的协议接入网关每个协议单独一个 ConnectorConnector 负责与设备通信、解析原始报文并转换成平台内部的规范消息结构。这个抽象层是整个平台最值得投入的部分。后面接入第6种协议时只需要新写一个 Connector不用动任何消费端。内部消息结构长这样{ deviceId: wsn-plant-02-cnc-001, ts: 1715000000000, type: telemetry, data: { speed: 1200, load: 73.2, temp: 56.4 }, quality: 1 }所有业务系统只认这个结构不同协议的差异全被挡在外面。这套结构本身也是我们后面做海量数据采集、做二次开发的基础。1.2 数据模型与消息契约省掉后续80%的麻烦设备数据最忌讳“现采现卖”。设备厂商经常把业务字段塞在自定义 JSON 里比如{v:123}这种如果平台不定义模型下游做报表、做告警时会疯掉。我们参考物模型思路把每个设备类型抽象成属性、事件、服务三类能力。属性是周期性上报的状态值事件是设备发生异常时的瞬时信息服务是平台可以调用的远程能力。设备注册时会绑定一个物模型接入网关解析出原始数据后按照物模型做字段映射。平台对外呈现的始终是稳定的业务语义。这一步做完业务方接数据的速度快了很多。他们不需要关心01 03 00 00 00 02是什么意思只需要知道“负载率 73.2%”这条数据可用。后面做告警、做报表、做数据转发都是基于这套语义模型而不是每次去翻协议文档。2. 平台总体架构与核心组件选型边缘端和云端怎么分工2.1 一套清晰的层级划分我们最终采用“边缘采集 云端汇聚”的两层架构。边缘层部署在工厂现场负责连接设备、本地解析、缓存断网期间的数据云端负责设备管理、消息路由、规则引擎、持久化存储和 OTA。边缘设备全部使用 Docker Compose 部署每个协议 Connector 是一个独立容器另外还有一个 edge-agent 容器负责与云端建立安全的 MQTT over TLS 长连接并做本地数据缓冲。这样即使广域网断掉边缘还能继续采集恢复后按时间顺序回补。云端核心组件如下模块选型职责消息网关EMQX 5.x设备连接、MQTT 消息收发、主题权限控制规则引擎自研 Go 服务数据过滤、字段映射、告警判断时序存储ClickHouse设备历史数据、海量写入、按时间聚合业务库PostgreSQL设备档案、物模型、升级任务、用户权限缓存Redis设备会话、最新状态、分布式锁、限流这套选型不是随便定的。消息网关必须支持高并发连接和 MQTT 协议族EMQX 可以横向扩展社区也活跃时序存储要扛住每秒几千上万条的写入ClickHouse 在同类产品里性价比最高业务库则保持传统的关系模型方便做复杂的设备档案管理。2.2 边缘网关的操作系统选型从 Linux 到 Windows IoT Enterprise 的考量大部分边缘网关我们用的是 Debian Linux稳定、资源占用低。但有一类场景很特殊现场必须跑 Windows 生态的采集驱动和上位机组态软件这些软件只提供 exe 驱动在 Linux 上没法跑。我在这类中大型设备上选了 Windows 11 IoT Enterprise LTSC 2024版本号 26100.3576。很多团队对 Windows IoT Enterprise 有个误解以为它是普通 Windows 的精简版。其实它最大的价值是长期服务渠道LTSC 版本只推送安全更新不推送功能更新也就不存在 Win11 突然重启、Edge 弹广告之类的幺蛾子。适合作为固定用途的边缘采集网关。这里要特别强调部署用的是正规商业授权渠道获取的系统镜像批量设备激活走企业批量授权方案。不要用网上那些来路不明的精简版安全性和稳定性都没法保障。这个问题我在后面第五部分还会展开讲。2.3 云端核心中间件消息、规则、存储消息网关我们选了 EMQX主要看中了它的多租户隔离和扩展能力。设备连接和业务消息走不同的主题空间设备侧使用带证书的 MQTT 连接业务侧使用独立的内部主题避免两边互相干扰。EMQX 的规则引擎可以用来做简单的数据转发但我们没有过度依赖太复杂的业务逻辑还是下沉到自研规则引擎里。规则引擎用 Go 写消费消息网关转过来的数据做类型校验、字段映射、单位换算然后写入 ClickHouse。刚开始我们图省事在规则引擎里直接同步调用业务 API后来这个设计直接导致了第三章的高并发事故。规则引擎里有一块很关键设备上下线的生命周期事件要单独处理。设备上线、离线、注册、注销这些事件不能和普通遥测数据混在一起否则消费端做状态判断时要写一堆复杂逻辑。我们把它拆成了独立的 event 主题规则引擎消费后更新设备在线状态并把事件写入 PostgreSQL方便业务方追踪设备行为。3. 海量数据采集场景的P0事故复盘一条数据管道是怎么被打死的3.1 事故经过第一次全链路压测我们接入了 2 万台真实设备和 4 万台模拟设备每台设备每 10 秒上报一条理论峰值 TPS 约 6000。压测开始后不到五分钟监控面板上规则引擎的 CPU 直接拉满EMQX 的消息积压数从 0 涨到 30 多万条ClickHouse 的写入延迟从 50ms 涨到 6 秒最后消息队列里的数据有一批被消费失败生产库和时序库出现了严重不一致。事后统计丢失了 3.7 万条遥测数据还有约 20% 的数据因为消费顺序乱了导致历史曲线出现回跳。这就是典型的 P0。虽然当时是压测环境但这个事故如果发生在真实生产现场质量部门肯定会直接找上门。3.2 排查链路我们没有直接拍脑袋改参数而是按链路一层层看先看 EMQX消息网关本身负载只有 20%说明消息进来没问题瓶颈在下游。看规则引擎CPU 100%但 goroutine 数量正常初步判断不是死锁而是某个同步操作阻塞。看业务 API发现规则引擎在逐条调用设备档案服务接口平均耗时 300ms6000 TPS 直接把它打挂下游打到超时又不断重试把线程池占满。再看消费端用的是 MQTT QoS 1服务器在重试机制下重复投递了大量消息业务侧没有做幂等重复数据又被写进了 ClickHouse。根因最后定位成三个同步阻塞、消费无幂等、存储写入没有批量聚合。3.3 修复方案异步、幂等、批量、背压第一件事把规则引擎里所有同步调用改成异步事件。调用业务 API 改为发到内部消息队列由独立的 worker 消费如果 API 不可用worker 重试三次后进死信队列绝不阻塞主数据链路。第二件事统一消息 ID消费端做幂等。每条消息在边缘端生成唯一 msgId规则引擎消费时先查 Redis 去重重复消息直接丢弃。Redis 缓存按小时过期避免无限增长。第三件事写入 ClickHouse 时做批量聚合。原来逐条 INSERT改成按 500 条一批 Batch Insert写入性能提升了近 20 倍。同时加上背压机制如果 ClickHouse 写入延迟超过阈值规则引擎自动降低消费速率而不是无限积压。修复后压测数据6000 TPS 下规则引擎 CPU 稳定在 45%消息积压数控制在 1 万以内写入延迟低于 200ms。这次事故让我意识到M2M/IoT 集成平台的性能瓶颈往往不在消息中间件而在消费端的设计。4. OTA升级模块落地AWS IoT OTA用户策略的权限模型与实际问题4.1 OTA的流程拆解设备远程升级是 M2M/IoT 集成平台里最容易“看着简单、做起来抓狂”的模块。以 AWS IoT 的 OTA 为例完整流程分四步固件上传到 S3、创建 OTA 更新 Job、设备端发现并获取 Job、下载固件并校验。这四步里权限配置的坑最多。在集成平台里OTA 不只是一个“文件推送”动作它牵扯到设备端状态机、版本管理、灰度策略、失败回滚。我们最初做 OTA 时只考虑了“把固件发下去”结果现场设备升级失败后没有回滚机制导致一批控制器固件版本混乱。后来我们把 OTA 流程设计成云端创建升级批次、按比例灰度、设备端主动拉取、下载完成后双分区切换、失败后自动回滚。4.2 用户策略和 IoT 策略权限不是一个地方配的很多团队在 AWS IoT OTA 上卡住是因为搞混了两类策略。IAM 用户策略控制的是“人/服务”能不能调用 AWS IoT APIIoT 策略控制的是“设备/客户端”能不能针对某个主题进行 publish/subscribe。设备端执行 OTA 时用的是设备自身的凭证所以必须把相关的 IoT 策略附加到设备证书上光配 IAM 用户策略没用。下面是一个可用的设备策略示例{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ iot:DescribeJobExecution, iot:GetPendingJobExecutions, iot:StartNextPendingJobExecution, iot:UpdateJobExecution ], Resource: * }, { Effect: Allow, Action: iot:Subscribe, Resource: [ arn:aws:iot:region:account-id:topicfilter/$aws/things/${thingName}/jobs/* ] }, { Effect: Allow, Action: iot:Receive, Resource: [ arn:aws:iot:region:account-id:topic/$aws/things/${thingName}/jobs/* ] }, { Effect: Allow, Action: iot:Publish, Resource: [ arn:aws:iot:region:account-id:topic/$aws/things/${thingName}/jobs/* ] } ] }除此之外设备从 S3 下载固件时还需要有权限访问预签名 URL。如果使用 AWS IoT 的 credentials providerrole alias还需要允许设备 AssumeRole并给对应的角色附加 S3 Bucket 的s3:GetObject权限。这里最容易漏的就是 S3 桶策略只给角色权限还不够桶策略如果没有放行 IoT 服务主体照样 403。4.3 实际踩坑记录我们第一次上线 OTA设备一直提示 job 不可用。排查下来问题出在 IoT 策略的 Resource 写死了 account-id而测试设备是另一个账号下的导致权限验证不过。后来又遇到 S3 桶策略没给 IoT 服务主体s3:GetObject权限设备能拿到任务但下载固件报 403。设备端也踩了坑状态机没做断点续传设备下载到 80% 网络闪断后重启直接放弃任务然后反复上报失败。后来我们在设备端实现了一个先下载到临时分区、校验哈希后再切换启动分区的流程。下载过程支持断点续传任务执行状态在本地持久化这样不管网络怎么断恢复后都能接着跑。OTA 升级做完平台才真正具备远程运维能力。但要提醒一点OTA 的灰度发布非常重要千万不要全量推先在测试设备上验证再按 10% 灰度逐步扩大到全量。另外每次 OTA 任务结束后都要把设备端上报的版本号回写到设备档案库不然运维人员永远不知道现场实际跑的是什么固件。5. Windows IoT 企业版在边缘网关上的自用优化从补丁到精简的完整流程5.1 为什么固定用途网关用 LTSC 版本前面提到边缘网关选了 Windows 11 IoT Enterprise LTSC 2024。普通 Windows 10/11 每半年一个大功能更新放在生产设备上简直是灾难。LTSC 版本只做安全质量更新不会突然改 UI、不会自动装应用生命周期可以拉得很长。这对边缘网关很重要现场几十台设备没人愿意半夜被系统更新重启搞挂。另外IoT Enterprise LTSC 相比商业版少了大量 UWP 应用系统镜像占用更小内存占用低。实测同样一台 i5 8500T 工控机普通 Win11 空闲内存约 2.8GBIoT Enterprise LTSC 空闲内存约 2.1GB。别小看这几百 MB在 8GB 内存的网关设备上影响还是明显的。5.2 安装后的补丁和基础安全配置安装完系统后第一件事不是精简而是先把补丁打满。以 26100.3576 这个版本为例它属于 24H2 分支建议先安装最新的累积更新和 .NET 补丁确保系统处于安全状态。补丁管理要统一走 WSUS 或 Intune不要每台设备手动点更新。然后做基础安全加固包括禁用不必要的远程桌面端口、关闭不用的 SMB 共享、配置 Windows 防火墙只允许边缘网关与云端的 MQTT 端口出方向、设置 BitLocker 保护系统盘如果设备支持。对于性能敏感的网关可以按需关闭遥测和部分后台任务。但要注意如果设备需要接收微软安全更新不能完全关闭遥测和更新服务。我们一般保留自动更新但设置为深夜维护窗口并在业务低峰期重启。5.3 精简流程与实战命令精简的第一步是卸载用不上的可选功能。使用 DISM 和 PowerShell 移除可选功能包但绝不碰系统核心组件。示例命令需要管理员权限# 查看当前已安装的功能包 DISM /Online /Get-Packages # 移除指定的可选功能包根据实际名称替换 DISM /Online /Remove-Package /PackageName:Microsoft-Windows-MediaPlayer-Package~31bf3856ad364e35~amd64~~10.0.26100.1 # 关闭休眠功能并删除休眠文件 powercfg /hibernate off # 设置电源计划为高性能 powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c # 禁用 SysMainSuperfetch减少磁盘占用 Stop-Service SysMain -Force Set-Service SysMain -StartupType Disabled命令里的包名要根据实际系统环境调整不要照抄。另外不要删除 Windows Defender就算要关闭实时保护也建议保留系统服务防止现场误插 U 盘导致中毒。精简后我们做了验证系统启动时间从 28 秒缩短到 19 秒空闲内存降到 1.3GB采集服务在长期运行 7×24 小时后内存占用率明显下降。注意精简完后必须做一轮完整功能回归确保远程运维通道、防火墙规则、采集驱动都不受影响。实测下来 Windows IoT Enterprise 用在固定功能的边缘网关上确实比普通 Windows 省心太多。6. 平台级运维把 P0 变成 P2 的观测手段与习惯6.1 可观测性从第一天开始很多集成平台都是先跑起来再补监控导致 P0 时只能靠猜。我们的经验是从第一个设备接入那一天就把观测体系建好。指标方面使用 Prometheus Grafana 监控 EMQX、规则引擎、ClickHouse、边缘节点重点看连接数、消息吞吐、积压数量、写入延迟日志方面所有服务统一输出 JSON 格式日志带 traceId关联设备 ID、消息 ID链路追踪方面云端用 OpenTelemetry 接入从 MQTT 消息进入网关到写入 ClickHouse 全程记录耗时。设备侧也要上报心跳和状态指标边缘网关的 CPU、内存、磁盘、进程状态统一通过 MQTT 主题发到云端汇总到平台监控。这样才能做到“设备没上线、网关先告警”。6.2 告警阈值设置经验告警不是越多越好要分等级。我们的默认阈值告警项阈值等级消息网关连接数突降下降超过 20% 持续 1 分钟P1消息积压数 50000 持续 5 分钟P1消费延迟 30 秒P2ClickHouse 写入延迟 500ms 持续 3 分钟P2边缘节点离线超过 2 分钟未上报心跳P2这些阈值不是拍脑袋定的是根据压测结果反推的。6000 TPS 下正常积压不超过 1 万所以阈值 5 万留了足够余量。告警要支持静默和升级机制避免周末凌晨因为小波动打扰值班人。我还建议给每个边缘网关配一个“最后上报时间”指标超时触发 P2这样可以提前发现设备掉线的苗头。6.3 压测与容量规划经验最后聊一个容易被忽略的事集成平台一定要做全链路压测而且要在架构设计阶段就做不是上线前一晚临时测。我们压测工具用了 Locust 模拟 MQTT 设备一台压测机可以模拟 5 万连接但要注意压测机和被测系统不要在同一个交换机下否则网络先到瓶颈。容量规划方面我们的经验数据单台 8C16G 的 EMQX 节点可以稳定支持 10 万设备连接但消息吞吐超过每秒 3 万条时建议横向扩容ClickHouse 单节点写入建议控制在 5 万 qps 以内超过就做分片集群。边缘网关的性能更要提前评估因为现场设备种类杂CPU 不仅要跑协议解析还要跑本地缓存和日志建议按峰值负载的 1.5 倍选硬件。最后再分享一个个人体会设备接入平台最容易翻车的地方不是高并发而是数据管道的可维护性。M2M/IoT 集成平台做得好不好看它在故障和需求变更面前还能不能优雅地扩展。我的习惯是每季度做一次故障演练人为断掉一个边缘节点、停掉一个规则引擎实例、模拟一次 OTA 失败看系统能不能自愈或快速恢复。这个习惯帮我们提前暴露了不少问题也让我对这个平台越来越有信心。