AWS · 为什么需要物联网平台：自建 MQTT 集群和 IoT Core，差距在哪

如果你只接几十台设备，写个 MQTT Broker + 一张设备表就能跑。但当设备数爬到十万、百万，跨地域、固件要批量升级、出了故障要追溯"这条消息是谁发的"，纯粹的"收数管道"就会迅速崩塌。

这一篇先不急着讲 AWS 的某个具体服务，而是把"为什么需要物联网平台"这件事说清楚——再看 AWS 是怎么用一组产品把这套复杂度接住的。

1.问题背景：自建MQTT集群和用IoT Core，差距在哪

抛开术语，设备接入要解决的现实问题无非这几条：

协议杂：老设备只会 HTTP，新设备爱用 MQTT，车机走 MQTT over WebSocket，工控现场还有 Modbus/OPC UA。你不能要求每台设备都改协议。
身份认证乱：一机一密还是一型一密？证书怎么发？设备被伪造了怎么踢？
连接不稳定：基站切换、隧道丢包、设备休眠，连接会断，断了自己要不要重连、状态要不要补报，平台得兜住。
数据既要用又要存：实时告警要秒级，历史分析要落库，机器学习要喂流——一条设备消息往往要同时流向多个地方。
设备要被"管理"：固件升级、配置下发、批量注册、远程诊断，这些是"设备"作为资产必然产生的运维动作。
数据会乱序、会迟到：设备弱网重连后补发旧数据、网关批量上报错峰，平台要能识别"这条消息此刻还有没有意义"。
固件碎片化：同型号设备跑着五六个固件版本，升级要能分组、灰度、回滚，不能"一升级全变砖"。
厂商黑盒：设备来自不同供应商，字段命名、单位、精度各一套，上层应用若逐个适配会崩溃。
运维黑盒：设备在线率多少、消息堆积多少、哪台设备在刷异常，靠人盯不可能，必须可观测。

这些事单做一件都不难，难的是把它们整成一个统一、可扩展、还得高可用的系统。这恰恰是物联网平台存在的理由。

2.设计理念：为什么用托管平台，而不是自己搭

自建一套"能跑"的物联网后端，初期成本看似低；但要做到"可靠、安全、可扩展"，隐性成本极高：

维度	自建（朴素版）	托管平台（如 AWS IoT）
连接规模	单机 Broker 几千~几万，再往上要自己分片	托管的消息代理，按设备数弹性
安全	自己实现认证/加密/轮换，易留坑	X.509、TLS、策略引擎开箱即用
高可用	得自己做主备、容灾	Multi-AZ 内建
设备管理	自己写注册/OTA/监控	设备注册表、Job、CloudWatch 内建
时间成本	大量重复造轮子	聚焦业务差异化

所以"平台化"的本质是：把"设备又多又杂又时断时续"这个现实，收敛成平台一侧干净、业务一侧简单的结构。你付出的代价是"学习它的模型"，换回的是"不用自己扛那一整套基础设施"。

3.实际应用：AWS IoT 的产品矩阵

AWS 没有把 IoT 做成一个单体产品，而是一组"各管一段"的服务，拼起来覆盖端到云：

AWS IoT 总体架构

AWS IoT 架构图（官方原图）

AWS IoT Greengrass 边缘架构（官方原图）

AWS IoT Core：设备接入与消息中枢，负责协议终结、身份认证、消息路由（规则引擎）和设备影子。
AWS IoT Greengrass：边缘运行时，把计算、消息、ML 推断下沉到设备/网关侧，断网也能本地自治。
AWS IoT Device Management：设备注册、批量预置、远程运维、OTA（Job）。
AWS IoT Device Defender：安全审计与异常行为检测（如消息突增、未授权连接）。
AWS IoT TwinMaker：数字孪生，把物理世界建模成可查询的实体-组件-关系图。
分析与 downstream：规则引擎把消息转给 S3（存储）、DynamoDB（时序/状态）、Lambda（计算）、Kinesis（流）、SQS/SNS（解耦）等。

这套分层的意义在于：每一层都可以独立替换或跳过。比如你只想要"设备连上来 + 转发到 Kinesis"，用 IoT Core + 规则引擎就够；想要边缘智能，再加 Greengrass。

3.4 一条消息的完整生命周期

设备消息从产生到被消费，要跨好几道关，任何一道漏了都会"数据对不上账"：

mermaid

sequenceDiagram
  participant D as 设备
  participant B as 消息代理 Broker
  participant R as 规则引擎
  participant A as 动作端点(S3/DDB/Lambda)
  participant S as 设备影子
  D->>B: 发布 topic/telemetry
  B->>R: 匹配规则 SQL
  R->>A: 命中则转发
  D->>S: 同步 reported 状态
  S-->>APP: 应用读影子/下发 desired

注意每一步都可能"至少一次"重复投递，消费侧（Lambda、数据库）要自己处理幂等——这也是（三）要展开的可靠性前提。

3.5 本系列要拆的"五件事"

记住一条主线，后面五篇都围绕它：连接 → 消息 → 物模型 → 设备管理 → 运维高可用。

（二）稳定连接：设备怎么连、怎么认、怎么扛抖动；
（三）消息与规则引擎：连上来之后数据怎么流、怎么分发；
（四）物模型与数字孪生：软件怎么"理解"设备；
（五）海量设备管理：几万台设备怎么注册、升级、就近接入；
（六）智能运维与高可用：平台怎么"稳得住、追得到"。

AWS 的每个服务，都能映射回这五件事上的某一环——读懂这张图，再读阿里云、火山引擎的同主题文档都不会慌。

4.注意事项

别神话平台：平台解决的是"基础设施复杂度"，不解决"你的业务模型怎么设计"。物模型、Topic 规划、数据流向仍要你自己想清楚。
成本是按量计费的：设备数、消息数、规则动作次数都计费，架构设计直接影响账单，详见（三）（五）。
多 Region 不是自动全球分发：IoT Core 是区域级服务，全球部署需要自己在多个 Region 各起一套并用账号/路由打通，留在（五）展开。
数据驻留与合规：IoT Core 是区域级，欧洲设备的数据要留在对应 Region，跨国部署先评估合规（如 GDPR），别等上线才补。
团队技能曲线：分层服务意味着团队要懂"哪层归谁"，前期学习成本不低，但换来长期可演进、可替换。

5.小结

物联网平台的价值，不在于"能收设备数据"，而在于把连接、认证、消息、设备管理、运维这些横切关注点统一接住，让你只关心业务数据本身。AWS 用一组分层服务（Core / Greengrass / Device Management / Defender / TwinMaker + 下游分析）把这条数据生命周期覆盖完整——这正是后面五篇要逐层拆解的主线。

一句收尾：平台的价值，不是替你写业务，而是把"设备又多又杂又时断时续"这件脏活揽过去，让你只管业务数据本身。

参考链接

AWS IoT 总文档：https://docs.aws.amazon.com/iot/
AWS IoT Core 是什么：https://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html
AWS IoT 服务全景：https://aws.amazon.com/iot/

AWS · 为什么需要物联网平台：自建 MQTT 集群和 IoT Core，差距在哪 ​

1.问题背景：自建MQTT集群和用IoT Core，差距在哪 ​

2.设计理念：为什么用托管平台，而不是自己搭 ​

3.实际应用：AWS IoT 的产品矩阵 ​

3.4 一条消息的完整生命周期 ​

3.5 本系列要拆的"五件事" ​

4.注意事项 ​

5.小结 ​

参考链接 ​