搭建自己的 IoT Platform我为什么劝你先从 Part 1 这样的地基开始虽然市面上的 IoT 云平台已经卷到免费额度随便送、文档堆成山、SDK 遍地走但真到要落地一个具体项目时很多人会发现“白嫖”的上限其实卡得很死。我自己之前接过好几个设备接入的活儿最开始图省事直接挂在商业云平台上设备量少的时候确实轻松可一旦牵扯到私有化部署、数据不出内网、定制告警规则这些需求商业平台反而成了最大的瓶颈。这就是我写“Build Your Own IoT Platform”系列的原因我想把从零搭一套自己的 IoT Platform 的完整过程拆开来讲Part 1 重点解决“地基”问题整体架构长什么样、设备怎么接进来、消息怎么流转、数据怎么存以及在这条路上你会踩到哪些文档里不会写的坑。这个系列适合谁不是那种几个月就能上线商用的巨型平台而是适合个人开发者、创业团队或者公司内部需要一套轻量级、可控、可定制的设备接入与数据处理系统的人。你说它复杂其实核心链路就是“设备上报数据 → 网关接纳 → 消息路由 → 存储 → 可视化”你说它简单可每一步展开都有大量细节任何一个环节没处理好后面设备一多就崩。所以这篇 Part 1 我会带你把整条主链路打通用的都是开源组件和最小可用配置一台 4G 内存的小服务器就能跑起来。1. 为什么我决定自己搭一套 IoT Platform而不是继续用云服务1.1 商业 IoT 云平台的隐形天花板商业 IoT 平台像是租精装房拎包入住确实香。注册账号、创建产品、添加设备、下载 SDK半小时就能看到设备数据在网页上滚动。但住久了你会发现几个很现实的问题第一是连接层不透明。设备接入协议、认证流程、消息流转链路全都是黑盒。你用平台提供的 SDK 上报数据平台显示了“已接收”但这一步背后发生了什么日志里看不到。一旦设备行为异常排查起来只能反复跟平台技术客服来回沟通效率极低。第二是数据主权和传输链路受限。遇到金融、医疗、工控这类项目数据根本不允许经过第三方云服务器。即使允许上云海量设备高频上报的消息经过平台网关转发每一条都要按消息数计费月度账单看着头疼。第三是定制化需求无法满足。比如我想在设备消息到达时先做一道本地过滤把无效数据丢弃再进存储或者我想把设备状态实时同步到我自己的业务系统里这些逻辑在商业平台上是很难做到灵活的你只能在平台预设的规则引擎里“戴着镣铐跳舞”。1.2 自建方案的核心收益与适用边界自己搭 IoT Platform本质上是把“租精装房”变成“自己装修毛坯房”省下了灵活性和控制力付出的代价是前期工作量和长期运维责任。从收益上看自建平台带来的核心价值集中在三个层面链路透明每一层都是开源的每一跳都可在日志中追踪。设备断连、消息丢失、数据库写入慢我能准确知道问题出在哪一段不用看平台脸色。成本可控开源组件 一台普通的 Linux 服务器承载上千台设备的中等负载没有问题主要开销就是服务器费用本身。相比按消息量计费的模式长期看明显更划算尤其适合高频上报的设备场景。二次开发自由我可以调用任何一层组件的接口做定制。比如在消息中间件里做动态分流在数据存储层前加一套自己的缓存策略这些逻辑按自己的业务需求来写。但我也得说句公道话自建并不适合所有人。如果你的目标是做消费级产品、有完善的合规需求或者团队没有 DevOps 能力我不建议自建。自建平台适合的是那些需要私有化、需要灵活控制接入流程、有内部技术团队能维护一套系统的场景。这也是我为什么一直说做技术选型时先想清楚边界再动手。1.3 为什么 Part 1 要先搭地基“Build Your Own IoT Platform”这个系列我规划成了多个部分Part 1 不是上来就写代码而是先把底座立起来。我见过太多人一上来就尝试写一个“全功能的 IoT 平台”又是设备管理又是规则引擎又是大屏展示结果做了两个月还在边缘模块里打转核心链路一条都没跑通。Part 1 的定位就是打通主路。我不追求功能数量不追求界面多炫只做设备接入、消息路由、数据存储、基础可视化这一条最小可用链路。等这条路稳了后面再谈设备影子、OTA、告警引擎、边缘计算这些进阶模块时你才有一个可靠的依托。2. 整体架构设计一台服务器也能跑起来的轻量 IoT Platform2.1 四个核心层次设备接入、消息路由、数据存储、应用呈现在搭东西之前你脑子里得先有一张图。一个自建的轻量 IoT Platform我习惯拆成四个层次设备接入层负责接收设备端的网络连接处理认证鉴权和基础协议解析。这一层的核心组件是 MQTT Broker。MQTT 是物联网场景下最主流的轻量级消息传输协议设备端和服务器之间通过发布/订阅模式通信非常适合网络不稳定、设备资源受限的场景。消息路由层设备上报的消息到达 Broker 之后不会直接进业务系统而是通过规则把不同主题的消息路由到对应的处理逻辑里。这里可以完成数据格式转换、消息过滤、字段清洗等任务。我在设计时把这一层做成独立的消费者服务方便后面扩展计算逻辑。数据存储层IoT 场景的数据有非常明显的时序特征设备上报的温度、湿度、电压、位置这些数据都是附带着时间戳的数值记录。因此核心存储我选用了时序数据库专门用来高效处理这类数据。同时还需要一套关系型数据库来存设备元数据、用户信息、产品模型等结构化数据。应用呈现层数据存下来之后最终要展示给用户看。这一层包含设备管理后台、实时数据看板、历史数据查询接口。Part 1 阶段不需要做得多复杂但至少能让设备数据“看得见”形成闭环。这四个层次各层之间通过标准接口衔接。消息到达 Broker 后由消息路由层的消费者订阅相关主题经过处理后写入时序数据库最终由后台服务查询数据渲染到前端页面。整个过程从设备上报到数据可见延迟在一秒以内已经能支撑绝大多数监控类场景。2.2 技术选型思路每个环节选什么为什么这么选选型这件事我不想直接扔给你一张工具清单然后说“用这个准没错”。每个组件背后都有取舍我按实际体验来聊聊。MQTT Broker 选型EMQX 还是 MosquittoMQTT Broker 是接入层的核心节点。社区里最常见的两个选择是 EMQX 和 Mosquitto。Mosquitto 非常轻量资源占用极小一个几百 KB 的二进制文件就能跑起来配完生效适合设备数量不大、功能需求简单的场景。EMQX 则是一个工业级的产品支持分布式集群、百万级并发连接、内置规则引擎和丰富的插件生态当然资源占用也更高。如果只是玩一玩、接几个开发板Mosquitto 完全足够。但如果你是想认真搭建一个能承载多设备、后续还要做扩展的平台我建议从 EMQX 入手。它核心开源版已经覆盖了认证、ACL、数据桥接、监控告警等功能后面系统升级时可以平滑过渡到集群模式。Part 1 我选择 EMQX因为它自带 Web 控制台可以直观看到连接状态和消息流量调试阶段非常省心。时序数据库选型InfluxDB 还是 TDengine时序数据存储我调研过 InfluxDB、TDengine、TimescaleDB 几个方案。InfluxDB 是时序数据库领域的老牌选手生态成熟、资料多、API 简单1.x 和 2.x 版本差异较大需要留意版本选择。TDengine 是国内团队开源的时序数据库在写入性能和高压缩率上非常出色3.x 版本引入 SQL 标准接口后上手成本也低了很多。我的选择是 InfluxDB 1.8 版本。原因很直接它稳定、文档全、社区案例多而且 1.x 的 Flux 查询和 HTTP API 对开发者非常友好。做项目时你总会遇到需要查资料的时刻选一个“搜得到答案”的工具能省下大量时间。TDengine 的写入性能确实更猛但如果你还没到设备量百万级、日增数据几百 GB 的程度InfluxDB 的差距你感受不到。后台技术栈选型Node.js 还是 Go后台服务承担着业务逻辑处理、API 提供等职责可以选择 Node.js、Go、Java 等语言。Node.js 的特点是开发效率高、生态丰富JavaScript 全栈工程师容易上手。Go 的特点是性能强、并发模型优秀、部署产物是单一二进制文件IoT 后端写起来十分顺手。如果团队技术栈是 JS 为主选 Node.js 我觉得一点毛病都没有如果是从零开始选我会偏向 Go。Io 场景天然是并发密集的设备消息同时涌入时Go 的 goroutine 模型能把代码写得很优雅部署和运维也简单。Part 1 我用 Go 写一个中间数据处理服务拆包、过滤、转发一套流程代码量不大但逻辑清晰。前端可视化选型Grafana 还是自研页面数据可视化部分有两个路线。一个是用 Grafana 直接对接时序数据库几行配置就能出监控大盘另一个是自己写一套前端页面调用后台 API 渲染图表。Grafana 的优势是快速、美观、免开发适合内部展示自研页面的优势是自由、能与业务系统深度整合。Part 1 我两者都用实时监控先用 Grafana 快速搭好设备管理页面用自研的简版后台。这样既能在项目早期看到效果又不至于被 Grafana 的定制能力限制住。2.3 最小可用架构的数据流走向把这四个层串起来看数据是这么走的设备端通过 MQTT 协议连接到 EMQX Broker 的 1883 端口连接时带上设备证书信息完成鉴权。设备消息按主题组织比如设备 ID 为dev001的温度传感器上报主题是devices/dev001/telemetrypayload 是一段 JSON{temp: 23.5, hum: 60.2, ts: 1736064000}。EMQX 收到消息后一方面在控制台生成消息统计日志另一方面通过规则引擎把消息转发到内置的 WebHook 桥接让后台服务感知到消息到达。后台服务订阅特定主题拉取消息后解析 JSON 字段做数据校验和字典映射再批量写入 InfluxDB。用户在 Grafana 或自研管理后台发起数据查询请求后台从 InfluxDB 查询对应时间范围的序列数据返回给前端渲染成折线图、仪表盘或表格。整个闭环在 1 到 2 秒内完成设备消息实时性完全够用。3. Part 1 的落地实操把地基一步一步打牢3.1 环境准备与基础服务部署开始之前先在服务器上准备好运行环境。我这边用一台 4C8G 的云主机操作系统是 Ubuntu 22.04 LTS。这个配置对于 Part 1 的规模来说绰绰有余实际上 2C4G 也能跑只是后面开 Grafana 和多个容器时代理线程会稍微吃紧。我的建议是全程用 Docker Compose 统一编排。这样做的好处有三点环境一致性换服务器直接复制配置、服务隔离各组件互不干扰、升级回滚方便换镜像版本即可。下面是docker-compose.yml的关键部分version: 3.8 services: emqx: image: emqx/emqx:5.1.6 container_name: iot-emqx restart: always ports: - 1883:1883 # MQTT TCP 端口 - 8083:8083 # WebSocket 端口 - 8084:8084 # MQTT over TLS 端口 - 18083:18083 # Dashboard 控制台 influxdb: image: influxdb:1.8.10 container_name: iot-influxdb restart: always ports: - 8086:8086 environment: - INFLUXDB_DBiot_platform - INFLUXDB_ADMIN_USERadmin - INFLUXDB_ADMIN_PASSWORDyour_password_here volumes: - influxdb-data:/var/lib/influxdb grafana: image: grafana/grafana:10.2.2 container_name: iot-grafana restart: always ports: - 3000:3000 volumes: - grafana-data:/var/lib/grafana volumes: influxdb-data: grafana-data:启动命令很简单在docker-compose.yml所在目录执行docker compose up -d三个服务就一起拉起来了。然后访问http://服务器IP:18083用默认账号admin/public登录 EMQX 控制台第一次登录会要求修改密码。注意几个细节EMQX 默认监听端口已经绑定到宿主机改了配置文件后要用docker compose restart emqx重启容器才能生效InfluxDB 的数据库名不区分大小写后面配置连接串时要严格对应。3.2 设备接入层EMQX 的认证与主题规划设备接入 EMQX 后第一个要解决的问题是认证鉴权不能让任意客户端连上来发消息。EMQX 5.x 提供了内置认证和数据库认证两种路径。我推荐用 MySQL 或者内置数据库存储设备凭证这样在后台管理设备时可以直接操作数据表和设备元数据表保持统一。为了方便入门我建议先开启 EMQX 的“内置数据库认证”在 Dashboard 的“访问控制”里创建一个认证类型选择 “Built-in Database”数据里填上用户名和密码作为设备的访问凭证。设备连接 MQTT 时把这两个字段填到username和password里即可。密码存储方式用户名密码之外生产场景建议用加盐哈希EMQX 支持多种哈希算法比如sha256配一个随机盐值。这些细节后面单独写一篇Part 1 阶段先用明文密码跑通流程重点在于理解认证链路是通的。主题规划是另一个重要话题。设备主题的命名方式直接影响后续权限控制和消息路由的复杂程度。我的建议是采用三层结构设备主题规范devices/{device_id}/{message_type} - devices/dev001/telemetry设备上报的遥测数据 - devices/dev001/status设备在线/离线状态 - devices/dev001/command平台下发给设备的命令 - devices/dev001/response设备对命令的响应同时每个设备在 ACL 里只允许操作自己前缀下的主题。在 EMQX Dashboard 里创建 ACL 规则允许设备dev001订阅devices/dev001/#禁止订阅其他前缀。这样即使有设备凭证泄露攻击面也能被压到最小。3.3 消息路由层后台服务订阅主题并把消息写入 InfluxDB设备消息到达 EMQX 后需要一个后台服务去订阅主题、消费消息。我写了一个简单的 Go 服务来做转发处理。先来看它的整体设计package main import ( context encoding/json fmt log strings time mqtt github.com/eclipse/paho.mqtt.golang influxdb2 github.com/influxdata/influxdb-client-go/v2 ) type Telemetry struct { DevID string json:dev_id Temp float64 json:temp Humidity float64 json:hum Lat float64 json:lat Lon float64 json:lon Timestamp int64 json:ts } func main() { broker : tcp://127.0.0.1:1883 username : iot_backend password : backend_password opts : mqtt.NewClientOptions().AddBroker(broker) opts.SetClientID(iot-backend-consumer) opts.SetUsername(username) opts.SetPassword(password) opts.SetAutoReconnect(true) opts.SetConnectRetryInterval(5 * time.Second) client : mqtt.NewClient(opts) if token : client.Connect(); token.Wait() token.Error() ! nil { log.Fatalf(MQTT connect failed: %v, token.Error()) } defer client.Disconnect(250) // 订阅所有设备的遥测数据 topic : devices//telemetry if token : client.Subscribe(topic, 1, handleMessage); token.Wait() token.Error() ! nil { log.Fatalf(Subscribe failed: %v, token.Error()) } log.Printf(backend service started, subscribed to %s, topic) select {} } func handleMessage(client mqtt.Client, msg mqtt.Message) { var telemetry Telemetry if err : json.Unmarshal(msg.Payload(), telemetry); err ! nil { log.Printf(parse message failed: %v, raw%s, err, string(msg.Payload())) return } telemetry.DevID extractDeviceID(msg.Topic()) if err : writeToInflux(telemetry); err ! nil { log.Printf(write influx failed: %v, err) } } func extractDeviceID(topic string) string { parts : strings.Split(topic, /) if len(parts) 2 { return parts[1] } return unknown } func writeToInflux(t Telemetry) error { client : influxdb2.NewClient(http://127.0.0.1:8086, your_influx_token) defer client.Close() writeAPI : client.WriteAPIBlocking(, iot_platform) point : influxdb2.NewPoint( device_telemetry, map[string]string{device_id: t.DevID}, map[string]interface{}{ temp: t.Temp, hum: t.Humidity, lat: t.Lat, lon: t.Lon, }, time.Unix(t.Timestamp, 0), ) return writeAPI.WritePoint(context.Background(), point) }这段代码里几个关键点值得展开讲MQTT 客户端的自动重连机制IoT 场景中消息链路必须足够健壮。我设置了SetAutoReconnect(true)当与 Broker 的连接意外断开后客户端会自动尝试重连。同时设置了 5 秒的重试间隔和阻塞等待保证网络抖动恢复后消息能继续消费不需要人工干预。QoS 级别的选择订阅时用的 QoS 是 1意思是消息至少送达一次允许重复。配合 MQTT 协议的去重机制能保证消息不丢但可能出现重复后端的幂等处理可以兜底。如果选 QoS 0消息可能因为网络抖动直接丢失这在 IoT 数据链路里是不可接受的。InfluxDB 的表结构设计每个 InfluxDB 点由 measurement 名称、一组 tag、一组 field 和一个时间戳组成。我把设备 ID 放在 tag 里原因是 InfluxDB 会对 tag 建索引按设备查询数据时会走索引效率很高。而温湿度这些数值放到 field 里因为 field 是具体的数据值不参与索引。这两个概念容易混淆如果 tag 和 field 用反了查询性能会显著下降。实际部署时我建议把服务源码编译成一个二进制文件扔到服务器上跑或者也可以做一个独立的 Docker 容器。配置项通过环境变量注入比如 Broker 地址、InfluxDB 连接串不要硬编码在代码里。这些规范本身不复杂但早点养成习惯后面维护省心。3.4 数据存储层时序数据的模型设计确认数据能写入 InfluxDB 之后接着要设计合理的存储模型。IoT 数据的核心特点是“一次写入多次查询”海量历史数据是按时间维度组织的所以存储模型要围绕查询场景来设计。我这边建了一个device_telemetry的 measurement用一个简单示例来演示Measurement:device_telemetryTag:device_id设备 ID索引查询的关键维度Field:temp温度、hum湿度、lat纬度、lon经度Timestamp: 消息中的ts字段转换成纳秒时间戳在 InfluxDB 命令行或 HTTP API 里查询某个设备最近一小时的平均温度SELECT mean(temp) FROM device_telemetry WHERE device_id dev001 AND time now() - 1h GROUP BY time(5m) FILL(null)返回的是每 5 分钟一个平均温度的数据再用 Grafana 连接数据源直接绘图即可。有一点容易被忽视时序数据量一旦上去不做保留策略你会被磁盘告警淹没。InfluxDB 1.8 用RETENTION POLICY来管理数据生命周期。例如我只需要保留 30 天的原始数据超过 30 天的自动清除。这样做不仅可以控制磁盘占用还能让查询只关心有效时间窗口性能更好。创建保留策略的命令如下CREATE RETENTION POLICY rp_30d ON iot_platform DURATION 30d REPLICATION 1 DEFAULT如果有更冷的数据需要长期归档可以再建一个长时间粒度的降采样保存到另一个 RP比如把原始数据每 15 分钟聚合成一条均值记录。这个思想在时序数据库叫 Continuous Query能有效解决“原始数据太大、查询历史太慢”的问题。3.5 应用呈现层Grafana 快速搭起监控大盘数据进到 InfluxDB 之后不把它可视化一眼望过去就像在跑一个没有仪表盘的赛车你不知道当前跑多快、温度多高。这里我推荐直接用 Grafana理由前面选型时已经说过它和 InfluxDB 的集成非常顺畅。在 Grafana 里添加 InfluxDB 数据源的配置步骤登录 Grafana默认账号密码是admin/admin首次登录会要求修改密码。点击左侧“Configuration” → “Data Sources” → “Add data source”。选择 InfluxDB在 Query Language 一栏选择 InfluxQL。HTTP URL 填http://influxdb:8086容器内部网络Access 选 Server。数据库填iot_platformUser/Password 填 InfluxDB 建库时设置的管理账号密码。点击 Save Test看到 “Success” 就连接成功了。然后创建一个新的 Dashboard添加 Panel查询语句示例SELECT mean(temp) FROM device_telemetry WHERE device_id dev001 AND $timeFilter GROUP BY time($__interval) fill(null)$timeFilter 和 $__interval 是 Grafana 的宏变量会自动替换为当前选择的日期范围和合理的聚合间隔。选好设备 ID、时间范围、图表类型一个实时温度监控曲线就出来了。如果你是给客户做演示Dashboard 里再配几个统计面板比如在线设备数、今日消息总量、最近告警事件效果会显得非常专业。这些数据指标可以从 EMQX 的监控 API 或 InfluxDB 里聚合查询得到。4. 踩坑实录连接不稳定、消息丢失、内存告警4.1 设备频繁断连心跳参数和 Keep Alive 调优我第一个踩的比较深的问题是设备频繁掉线。现象是设备每几十秒掉一次线几秒后又自动重连日志里全是 CONNECT/DISCONNECT 的记录。排查思路通常是先看 MQTT 的 Keep Alive 设置。MQTT 协议规定客户端和 Broker 之间会按 Keep Alive 周期发送心跳包。如果 Broker 在1.5 倍 Keep Alive时间内没收到任何报文就会判定设备失联并断开连接。调优时把客户端的 Keep Alive 从默认的 60 秒改成 30 秒同时把 EMQX Broker 侧会话过期时间调大防止设备闪断后 session 被立刻清空。还有一点设备端如果用的是拨号网络或者 WiFi信号弱的时候心跳包可能发不出去这种场景建议把 Keep Alive 控制在 15 到 30 秒之间同时把 MQTT 的 Clean Session 设为 false保证断线后能恢复未确认的消息。真正把设备端的保活机制调到合理的状态之后掉线率直接下降了百分之九十。4.2 消息莫名丢失QoS 0 和 QoS 1 的真实区别还有一次是排查“数据怎么少了一条”的问题。原因是设备上报时用了 QoS 0而 MQTT Broker 在极端情况下的确可能丢弃 QoS 0 消息。表现是客户端发布消息时没有得到任何错误提示服务端日志也看不到异常但消息就是没到订阅方手里。MQTT 的 QoS 有 0、1、2 三个等级QoS消息保证适用场景QoS 0最多一次可能丢失高频瞬态数据如 GPS 坐标点偶尔丢几条无关紧要QoS 1至少一次可能重复遥测数据、设备状态等核心数据需要确保不丢QoS 2恰好一次性能开销大订单、支付等业务关键数据必须严格不重复不丢设备端采集遥测数据我用 QoS 1配合订阅端的去重逻辑消息丢失问题得到解决。但要注意QoS 越高Broker 和网络开销越大如果所有消息都上 QoS 2高并发下性能会很吃亏。IoT 场景没有绝对正确的选择每个业务都要在“可靠性”和“性能”之间做权衡。4.3 磁盘和内存暴涨数据保留策略与索引优化第三个坑比较隐蔽。跑了几天以后我发现时数据库的磁盘占用涨得很快一台 80G 的服务器眼看就要撑不住。查了 InfluxDB 的数据目录发现数据文件增长速率远超预期。我排查到两个原因一是当时做消息测试时设备的频率没有控制每秒上报一次一天就是八万余条记录每条记录里还带着不必要的字段数据量自然爆炸二是没有及时设置数据保留策略所有历史数据都在库里躺着越积越多。解决方式给 InfluxDB 的数据配置上自动压缩和 30 天保留策略。在 EMQX 的规则引擎里把“无效字段剔除”这步前移到消息入口处只把有用的字段转发给后台服务。后台服务写了批量写入逻辑定时攒一批数据再写库减少调度开销CPU 和内存占用都降下来了。除此之外记得给服务器配置日志轮转。容器里的 EMQX、Grafana 日志如果不做切割/var/lib/docker 目录也会静默涨满这同样是个经常被忽视的坑。4.4 一个容易被无视的性能劣化点全表扫描与高基数 Tag最近做优化时又遇到一个有意思的问题随着设备数量从几十涨到几百InfluxDB 的写入性能和查询速度开始明显下滑。根源在于 tag 的设计。在 InfluxDB 中tag 的值如果每一个都是唯一的比如直接拿毫秒级时间戳或 UUID 做 tag会被识别为“高基数”导致索引膨胀性能急剧下降。把类似“消息 ID”这种字段放到 field而不是 tag能显著缓解这个问题。IoT 场景下像设备 ID、产品类型、区域这些有限枚举的字段才适合放在 tag 里其他唯一性很强的数据放到 field 里即可。5. 从 Part 1 到 Part 2下一步可以往哪里扩展Part 1 这条主链路现在能跑通了设备通过 MQTT 接入 EMQX后台服务订阅主题并写入 InfluxDBGrafana 从 InfluxDB 拉数据展示。只要设备端能连上 server 并发布主题消息你在浏览器里马上就能看到实时曲线这种“自己搭的东西活了”的感觉说实话很有成就感。但一个真正可用的 IoT 平台远远不止这些。目前这个版本还缺几个关键模块一是设备管理与认证体系到现在为止设备凭证是手动配置的设备多了以后需要一个管理后台来维护产品模型、设备列表和密钥生命周期二是告警引擎数据超出阈值时主动推送通知这是监控场景的刚需三是规则引擎EMQX 本身自带强大的规则引擎我只是用了其中很小一部分的数据转发能力后面应该把设备心跳检测、上下线事件、异常数据自动隔离等逻辑下沉到规则引擎里去解决四是设备影子与命令下发让平台能够主动下发配置、控制指令到设备这会牵扯到另一套双向通信机制的设计。所以接下来可以继续往这些方向做扩展。如果是自己学习我建议一步步来先把“设备管理”和“告警”这两个最常见的能力补上再去碰数据可视化大屏和 OTA。每加一层功能都要保证主数据链路不出问题这是整个平台的地基。最后再分享一点我自己的体会搭建 IoT 平台最难的其实不是某个组件的配置而是对整个链路的掌控感。你用商业云平台时很多东西是别人封装好的你会觉得“好像挺简单”等你自建一遍每一步都亲眼见证数据是怎么从设备端流到前端页面的那种掌控感会彻底改变你对系统设计的理解。Part 1 地基已经打好接下来可以放心盖楼了。