如果你正在做物联网相关产品而且碰巧又深度用过亚马逊云服务那 AWS IoT 这套体系迟早会出现在你的技术选型清单里。这篇内容我想从一个实际做产品的角度拆解一下如何基于 AWS IoT 构建一个自定义的物联网 App包括设备接入、消息流转、OTA 升级、App 端架构设计以及那些文档里不会写明白的坑。先交代一下背景。我之前做过一个工业设备远程监控项目设备端跑的是 FreeRTOS网关侧用了 AWS IoT Core 做消息中转App 端既要实时看设备数据又要支持远程配置下发和固件升级。整个链路从零开始搭中间踩了不少坑也总结了一些比较顺手的做法。这篇文章适合三类人看一是准备用 AWS IoT 做产品但还在选型的团队二是已经在用但想把架构做得更稳的开发者三是纯粹想了解物联网云端架构的爱好者。我会把核心概念、实操步骤、常见问题都串起来讲尽量让有基础的人能直接照着做没基础的人也能看懂在干什么。1. 整体设计思路为什么选 AWS IoT 而不是自建 MQTT Broker先聊一个最容易被问的问题市面上有 EMQX、Mosquitto 这类开源 MQTT Broker也有阿里云 IoT、腾讯云 IoT 这些国内平台为什么要选 AWS IoT我的看法是如果你本身就在 AWS 生态里跑业务AWS IoT 的集成成本是最低的如果你的设备要出海AWS 的区域覆盖和合规体系也是实打实的优势。但这不代表它没有缺点后面我会专门说。1.1 核心优势不是 MQTT Broker而是一套设备管理平台AWS IoT Core 表面上是个 MQTT 消息接入层但它的定位其实远不止消息中转。它包含设备认证X.509 证书、授权策略IoT Policy、设备影子Device Shadow、规则引擎Rules Engine、设备管理Thing Registry、固件更新OTA等一整套能力。你不需要像自建 MQTT 那样再单独搞一套设备认证服务和影子数据存储这些 AWS IoT Core 都帮你做了。举个例子设备上报温度数据到topic/dev/{device_id}/telemetry你想把这个数据实时写入 DynamoDB同时触发一个 Lambda 做异常告警再更新设备的影子状态。如果自建 MQTT你得自己写消费端程序处理这些逻辑但用 AWS IoT 规则引擎一条 SQL 语句加两个 action 就能搞定而且是全托管的不用关心扩展性。1.2 架构选型设备、网关、App 三端如何分工我这次的系统架构是分三层的。设备端是传感器加 MCU通过 MQTT 协议直接连 AWS IoT Core中间有一层边缘网关负责协议转换和数据聚合App 端作为控制面既接收设备实时数据也发起控制指令。选型时有一个关键判断设备和 App 之间是直连还是通过云端中转。工业场景我强烈建议走云端中转。原因很简单设备往往在 NAT 后面没有公网 IPApp 直连设备基本不可能另外直连方案遇到固件升级就非常被动你没法通过云端批量管理设备。AWS IoT Core 这边天然就是中转架构设备只跟云端保持 MQTT 长连接App 想控制设备时通过云端发布消息即可。1.3 自建方案对比什么情况下别用 AWS IoT当然AWS IoT 也不是万能的。如果你的设备量很小比如几十台以内而且团队对 MQTT 协议栈非常熟自建一个 Mosquitto 加数据库可能成本更低。另外如果你的业务合规要求数据必须留在本地那 AWS IoT Core 这类公有云服务就不适合你得考虑 AWS Greengrass 加本地部署的方案或者干脆选其他私有化 IoT 平台。还要注意一个隐性成本AWS IoT Core 的定价是按连接分钟数和消息数计费的。这意味着你设备发消息的频率越高成本越大。我之前有个客户做高频传感器采集每台设备每秒上报 10 条数据一个月下来消息费用吓死人。后来我们把上报频率降到每 5 秒一条实时性要求高的数据走 Amazon SNS 推送成本一下就下来了。所以选型时要提前算好消息量和连接时长别等账单出来再后悔。2. 设备接入的完整实操证书、策略、物模型设备接入是整个链路里最容易出问题的一环尤其是权限策略配置。我之前见过很多开发者在本地跑通了一切一旦上了生产环境设备全部连不上最后发现是 IoT Policy 写得太紧或者证书没激活。下面把标准流程拆开讲。2.1 创建设备和证书三种方式怎么选AWS IoT Core 注册设备有三种常见方式。第一种是通过控制台手动创建 Thing然后生成证书并下载好处是直观适合测试环境第二种是通过 AWS CLI 批量创建适合在生产环境初始化大量设备第三种是通过 Just-in-Time ProvisioningJITP自动注册设备第一次连接时自动发放证书适合消费类产品的量产场景。我建议如果你只是做原型验证用第一种如果是正式项目直接用 CLI 脚本化创建把设备信息写入 DynamoDB 做台账。我们当时用 CLI 写了一个 Python 脚本输入设备序列号自动生成 Thing、证书、策略并绑定然后把设备证书烧录到产测工具里整个流程在产线上非常顺畅。2.2 最关键的 IoT Policy 配置IoT Policy 是 AWS IoT 的访问控制层它决定了你的设备能发布和订阅哪些 Topic。这一块是很多刚上手的人最懵的地方因为它的语法和 IAM Policy 有些类似但又有自己的专属动作和资源格式。举一个我常用的最小权限策略设备只允许发布dev/{device_id}/telemetry主题订阅dev/{device_id}/cmd和dev/{device_id}/shadow/update/accepted{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [iot:Publish], Resource: [arn:aws:iot:us-east-1:123456789012:topic/dev/${iot:Connection.Thing.ThingName}/telemetry] }, { Effect: Allow, Action: [iot:Subscribe, iot:Receive], Resource: [ arn:aws:iot:us-east-1:123456789012:topicfilter/dev/${iot:Connection.Thing.ThingName}/cmd, arn:aws:iot:us-east-1:123456789012:topicfilter/dev/${iot:Connection.Thing.ThingName}/shadow/update/accepted ] } ] }注意到Resource里的arn:aws:iot:us-east-1:123456789012:topic/dev/${iot:Connection.Thing.ThingName}/telemetry了吗这里的${iot:Connection.Thing.ThingName}会自动替换成当前证书绑定的 Thing Name。这样每台设备只能操作自己的主题天然隔离不会出现设备 A 把消息发到设备 B 主题下的安全问题。这是 AWS IoT 多租户设备管理最核心的权限模型一定要用起来。2.3 设备影子让 App 随时拿到设备最新状态设备影子Device Shadow是 AWS IoT 里非常实用的一个功能它可以理解为云端维护的一份设备状态 JSON 文档。设备可以把当前状态上报到影子App 端也可以直接读影子拿到最新状态即使设备处于离线状态。为什么要用影子因为 MQTT 是发布订阅模式App 端如果想知道设备当前状态要么维护一份本地缓存要么主动发消息询问设备。但设备可能不在线也可能忙不过来。影子提供的就是一个“云端缓存 最终一致性”的方案设备定期把状态同步到影子App 任何时候读影子都能拿到设备最近一次上报的状态。影子 JSON 的核心结构是这样{ state: { desired: { power: on, temperature: 45 }, reported: { power: on, temperature: 45 } } }其中desired是用户期望的状态reported是设备实际报告的状态。设备启动时订阅$aws/things/{thing_name}/shadow/update/accepted和/delta主题当云端desired和reported不一致时AWS IoT 会往delta主题发布差异消息设备收到后执行操作并更新reported这样 App 就能一直拿到准确状态。我在实际项目里有一个体会影子数据适合放“状态类”数据比如开关状态、当前模式、固件版本但不适合放高频遥测数据。高频遥测走普通 MQTT 主题落库影子只保存低频状态这样既控制成本又让影子保持轻量。3. 消息流转从设备数据到 App 可用的后端接口设备接进来只是第一步关键是数据怎么流转到 App 端。AWS IoT 里这条链路通常分两段设备到云端通过 MQTT云端到 App通过 API Gateway Lambda 或者 MQTT over WebSocket。3.1 设备到云端的实时数据链路设备通过 MQTT 发布消息到dev/{device_id}/telemetry主题AWS IoT Core 收到消息后会触发规则引擎。规则引擎的用法非常直接在控制台创建一条规则定义 SQL 语句解析消息 JSON然后添加一个或多个动作。比如我要把每条遥测数据写入 DynamoDBSQL 是这样的SELECT device_id, timestamp, temperature, humidity FROM dev//telemetry注意dev//telemetry里的是通配符能匹配任意设备 ID。这样所有设备上报的数据都会流到同一条规则里处理。动作选择 DynamoDB指定表名和主键字段AWS IoT 会帮你自动写入。如果你需要做数据清洗或者加一些字段再入库可以先用 Lambda 做预处理再让 Lambda 去写数据库。但说实话大部分场景直接用规则引擎投递就够了少一层 Lambda 就少一层延迟和费用。3.2 App 端实时获取数据轮询还是长连接App 端要实时拿到设备数据有两个方案。一个是 App 通过 HTTPS 调用 API Gateway 查询数据库适合秒级延迟的场景实现最简单另一个是 App 通过 MQTT over WebSocket 直接订阅主题适合毫秒级延迟的场景但实现复杂度高一些。我的建议是MVP 阶段用 HTTPS API 轮询就够了最多轮询间隔 3 秒用户体验完全可以接受。等用户量上来或者真的需要毫秒级推送时再引入 WebSocket 或者 Amazon SNS / Pinpoint 做推送通知。有一件事值得提醒不要直接用 AWS IoT 的 MQTT 端点给大量 App 客户端做订阅。原因有二一是 IoT Core 的连接数计费会非常惊人一个 App 用户就是一个长连接一万个用户就是一万个并发连接二是 IoT Core 的 Topic 权限模型面向设备做 App 端的用户鉴权不如 Cognito 和 API Gateway 顺手。App 端还是走 API Gateway 更合适设备端才走 MQTT这个边界要拎清楚。3.3 用户策略热词里提到的 aws iot ota 用户策略最近在圈子里看到有人讨论“aws iot ota 用户策略”这个话题结合我做过的项目深有感触。它其实指的是当你通过 AWS IoT 的 OTA 服务向设备推送固件时不仅仅是设备端需要权限触发 OTA 任务的用户或服务账号也需要对应的 IAM 策略同时设备端接收 OTA 时也要有相应的 IoT Policy 允许它访问$aws/things/{thing_name}/jobs相关的主题。一句话总结OTA 涉及两层权限一层是控制面谁有权限创建 OTA 任务属于 IAM 策略一层是数据面设备是否有权限订阅 job 主题属于 IoT Policy。这两层经常被搞混导致任务创建成功但设备端收不到升级指令或者设备能收指令但下载不了固件。3.3.1 控制面 IAM 策略创建 OTA 任务时你的 CLI 或控制台身份需要具备iot:CreateJob、iot:CreateStream、s3:GetObject等权限。下面是一份最小 IAM 策略示例给一个发布系统专用服务账号使用{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ iot:CreateJob, iot:CreateStream, iot:DescribeJob, iot:DescribeStream, iot:GetPendingJobExecutions ], Resource: * }, { Effect: Allow, Action: [s3:GetObject], Resource: arn:aws:s3:::your-firmware-bucket/* } ] }这里s3:GetObject是为了让 OTA 服务拉取固件文件。如果你的固件放在 S3 且没有公开访问这一步绝对不能少否则创建任务时会直接报权限错误。3.3.2 数据面 IoT Policy设备端要接收 OTA 任务必须在 IoT Policy 里允许访问 Job 相关主题。下面是设备端 IoT Policy 里需要增加的一段{ Effect: Allow, Action: [iot:Subscribe, iot:Receive], Resource: [ arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/jobs/* ] }同时还要允许发布 job 执行状态回执{ Effect: Allow, Action: [iot:Publish], Resource: arn:aws:iot:us-east-1:123456789012:topic/$aws/things/${iot:Connection.Thing.ThingName}/jobs/* }设备端用了 AWS 官方的 IoT Device SDK 时OTA 相关的 topic 都是 SDK 内部拼接的你只需要保证策略权限够用即可不需要自己手动处理 topic 拼接逻辑。但如果你是自己写的 MQTT 客户端就要严格按照$aws/things/{thing_name}/jobs/$next/get、$aws/things/{thing_name}/jobs/$next/accepted这类主题格式来组织代码搞错一个前缀任务就跑不起来。3.4 数据落库与离线消息补发设备上报的数据除了实时流转通常还需要落库做历史分析和报表。推荐的做法是IoT 规则引擎把原始数据写入 Amazon S3 冷存一份同时用 DynamoDB 或 Timestream 存热数据。DynamoDB 适合按设备 ID 时间戳查最近记录Timestream 适合做时序聚合查询。如果设备长时间离线重连后 App 端如何补数据这里有两种常见策略。第一种是设备端本地存储离线期间把数据存在 SD 卡或者 Flash 里重连后按时间批量补传第二种是 App 端在设备离线期间先记录“数据缺失”时间窗口等设备恢复后向设备请求补传。第一种方案对设备端存储有要求第二种对 App 端逻辑要求高你需要根据自己设备的存储能力和网络状况选。4. 实操过程从零搭一个温控设备 IoT App 示例理论讲了不少我们来做一个能跑通的最小闭环。目标一台设备用电脑上的模拟器就行一个 App用网页模拟通过 AWS IoT Core 实现温控设备的远程控制和实时状态展示。这个例子做完你就理解了整个 IoT App 的核心链路。4.1 云端准备建 Thing、证书、策略、规则第一步在 AWS IoT Core 控制台创建 Thing名称叫demo_thermostat_01。第二步生成证书并下载测试环境可以直接一键生成并激活。下载下来的三个文件设备证书、私钥、Amazon Root CA 证书存放到模拟设备程序的目录。第三步为设备绑定 IoT Policy策略内容可以参考 2.2 里的配置把 Thing Name 用*通配也行仅限测试环境生产环境务必用${iot:Connection.Thing.ThingName}做隔离。第四步创建规则规则名称save_telemetry_to_dbSQL 语句SELECT device_id, temperature, humidity, timestamp FROM dev//telemetry动作写入 DynamoDB 表telemetry_records主键device_id排序键timestamp。4.2 模拟设备端Python 脚本上报数据并响应对控制指令下面是一个用 Python 写的模拟设备它每秒上报一次温度和湿度同时订阅控制主题收到set_temperature指令后调整目标温度。import json import time import random from awscrt import io, mqtt from awsiot import mqtt_connection_builder ENDPOINT your-iot-endpoint.iot.us-east-1.amazonaws.com CLIENT_ID demo_thermostat_01 THING_NAME demo_thermostat_01 PATH_TO_CERT demo_thermostat_01.cert.pem PATH_TO_KEY demo_thermostat_01.private.key PATH_TO_ROOT_CA AmazonRootCA1.pem current_temp 24.0 target_temp 24.0 def on_message(topic, payload, dup, qos, retain, **kwargs): global target_temp data json.loads(payload) print(f收到控制指令: {data}) if target_temperature in data: target_temp data[target_temperature] def main(): mqtt_connection mqtt_connection_builder.mtls_from_path( endpointENDPOINT, cert_filepathPATH_TO_CERT, pri_key_filepathPATH_TO_KEY, ca_filepathPATH_TO_ROOT_CA, client_idCLIENT_ID, clean_sessionFalse, keep_alive_secs30 ) connect_future mqtt_connection.connect() connect_future.result() print(设备已连接 AWS IoT Core) topic_cmd fdev/{THING_NAME}/cmd mqtt_connection.subscribe(topic_cmd, qosmqtt.QoS.AT_LEAST_ONCE, callbackon_message) topic_telemetry fdev/{THING_NAME}/telemetry while True: global current_temp current_temp (target_temp - current_temp) * 0.1 random.uniform(-0.1, 0.1) payload json.dumps({ device_id: THING_NAME, temperature: round(current_temp, 2), humidity: round(random.uniform(40, 60), 2), timestamp: int(time.time() * 1000) }) mqtt_connection.publish(topic_telemetry, payload, qosmqtt.QoS.AT_LEAST_ONCE) print(f上报遥测: {payload}) time.sleep(5) if __name__ __main__: main()注意这里面有几个细节。clean_sessionFalse表示断线重连后要恢复之前的订阅关系keep_alive_secs30是心跳间隔建议设置在 30 到 60 秒之间太短费电费流量太长可能导致服务端误判离线。设备在 while 循环里用了 5 秒上报一次真实产品里要根据业务需求动态调整上报频率。4.3 App 端通过 API Gateway 读数据和下发指令App 端我通常用 API Gateway 暴露两个接口。一个GET /devices/{device_id}用于查询设备最新状态一个POST /devices/{device_id}/commands用于下发控制指令。查询接口从 DynamoDB 读取最新一条记录逻辑很简单。下发指令接口稍微复杂一点因为 Lambda 需要拿到 AWS IoT 的客户端去发布 MQTT 消息。下面是一个精简版 Python Lambdaimport boto3 import json iot_data boto3.client(iot-data, region_nameus-east-1) def lambda_handler(event, context): device_id event[pathParameters][device_id] body json.loads(event[body]) target_temp body.get(target_temperature) if target_temp is None: return {statusCode: 400, body: json.dumps({error: target_temperature is required})} topic fdev/{device_id}/cmd payload json.dumps({target_temperature: target_temp}) response iot_data.publish( topictopic, qos1, payloadpayload ) return {statusCode: 200, body: json.dumps({result: command sent})}这里有一个容易踩的坑Lambda 执行角色需要额外加一条 IoT 的权限策略允许iot:Publish到dev/*/cmd主题。很多人在测试时发现 Lambda 返回 200但设备端收不到消息一查日志才发现是缺少 iot:Publish 权限。另外别忘了iot-data和iot是两个不同的 client一个是发消息的一个是管理用的别搞混。4.4 联调验证从 App 下发指令到设备端生效全链路联调时我会开三个窗口同时看一个是 Python 模拟设备的终端一个是 AWS CloudWatch 日志一个是 DynamoDB 表数据。先在 App 端调用POST /devices/demo_thermostat_01/commandsbody 传{target_temperature: 20}。如果一切正常你会看到 Python 模拟设备控制台打印出“收到控制指令”的字样然后从下一次上报开始temperature 字段会逐渐逼近 20 度同时 DynamoDB 表里新写入的记录温度值也在变化。如果设备端没收到优先查三个地方IoT Policy 里iot:Subscribe和iot:Receive的 Resource 是否包含对应主题Lambda 执行角色是否有 iot:Publish 权限设备订阅的主题和 Lambda 发布的主题是否完全一致包括大小写和斜杠。5. 固件 OTA 升级的完整解法任务创建到设备侧落地的全过程OTA 是物联网产品无法避开的一环也是最容易出幺蛾子的地方。AWS IoT Core 提供了 Jobs 服务来管理 OTA 任务结合 S3 存储固件可以做到远程批量升级。接下来详细说一遍完整流程重点讲如何配置用户策略。5.1 固件上传与任务创建第一步把固件包上传到 S3 存储桶比如my-iot-bucket下的firmware/thermostat_v2.bin。建议固件包做签名校验AWS IoT 支持在 OTA 任务里指定固件签名 profile设备端验证签名后再刷入避免固件在传输过程中被篡改。第二步通过控制台或 CLI 创建 OTA 更新任务。控制台路径AWS IoT Core - Remote Actions - Jobs - Create job。选择“Create streaming job”指定 S3 固件地址、IAM 角色允许 IoT 访问 S3、目标设备组可以按 Thing Group 选一批设备也可以选单个设备。CLI 方式创建任务的参考命令aws iot create-job \ --job-id ota-thermostat-v2-001 \ --targets arn:aws:iot:us-east-1:123456789012:thing/demo_thermostat_01 \ --document {operation:ota_update,firmware_version:v2.0.0,file:thermostat_v2.bin} \ --document-source s3://my-iot-bucket/firmware/thermostat_v2.bin \ --presigned-url-config {roleArn:arn:aws:iam::123456789012:role/iot-ota-role,expiresInSec:3600}这里presigned-url-config的作用很关键它让 AWS IoT 生成一个临时的 S3 预签名 URL设备端通过这个 URL 直接下载固件不需要在设备上配置长期有效的 S3 凭证安全性更好。5.2 设备端处理 OTA 任务的逻辑设备端通过订阅$aws/things/{thing_name}/jobs/$next/get来获取待执行的任务。AWS IoT Device SDK 的jobs模块帮你封装了这套逻辑只需要在设备启动时初始化 Job 监听器即可。如果不用 SDK 或想自己实现核心流程是订阅$aws/things/{thing_name}/jobs/notify-next当有新任务时收到通知。请求$aws/things/{thing_name}/jobs/$next/get获取任务详情包括 S3 预签名 URL。下载固件到本地临时分区校验哈希和签名。写入备份分区重启引导程序执行切换。上报任务状态SUCCEEDED或FAILED到$aws/things/{thing_name}/jobs/{job_id}/update。这里要特别强调的是第 3 步和第 4 步这决定了 OTA 的可靠性。工业设备或者智能家居设备做 OTA一定要有 A/B 分区设计或者至少要有“固件回滚”能力。我见过太多产品把 OTA 做成“直接覆盖当前固件”一旦写入失败设备变砖。哪怕你的 MCU 没有双分区条件至少要在 bootloader 里留一个 recovery 模式能通过串口或云端恢复。5.3 OTA 任务状态监控与失败重试创建完 OTA 任务后怎么知道设备升级成没成功AWS IoT 控制台的 Jobs 页面能看到每个设备的执行状态常见状态有 QUEUED、IN_PROGRESS、SUCCEEDED、FAILED、TIMED_OUT。你可以在创建任务时设置超时时间和最大执行次数设备上报成功后任务才会标记为 SUCCEEDED。我自己踩过的一个坑是任务状态显示 SUCCEEDED 但固件实际没生效。原因是在设备端我上报 SUCCEEDED 用的是“下载完成”回调而不是“固件启动成功”回调导致任务记录和实际版本不一致。所以设备端上报成功状态的位置一定要放在新固件启动并完成自检之后即使你用的是同一个 JOB 文档也要让新固件在启动时再次上报一次当前版本号或者在业务接口里登记新的固件版本这样云端的台账才准确。5.4 OTA 用户策略的典型配置模板如前面 3.3 节提到的OTA 涉及两层权限。很多团队在排查 OTA 问题时第一反应是看设备端网络、MQTT 连接却忽略了对 IAM 策略和 IoT Policy 的梳理。这里给一个完整的 IAM 策略模板用于 OTA 任务创建方也就是你的后端服务或管理员账号{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ iot:CreateJob, iot:DescribeJob, iot:ListJobs, iot:UpdateJob, iot:CancelJob, iot:DeleteJob ], Resource: * }, { Effect: Allow, Action: [ iot:CreateStream, iot:DescribeStream, iot:DeleteStream ], Resource: * }, { Effect: Allow, Action: [ s3:GetObject, s3:GetBucketLocation ], Resource: [ arn:aws:s3:::my-iot-bucket, arn:aws:s3:::my-iot-bucket/* ] } ] }设备端 IoT Policy 模板除了常规的发布订阅主题还需要增加对 Jobs 主题的访问权限{ Statement: [ { Effect: Allow, Action: [iot:Publish, iot:Subscribe, iot:Receive], Resource: [ arn:aws:iot:us-east-1:123456789012:topic/$aws/things/${iot:Connection.Thing.ThingName}/jobs/*, arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/jobs/* ] }, { Effect: Allow, Action: [iot:GetPendingJobExecutions], Resource: arn:aws:iot:us-east-1:123456789012:thing/${iot:Connection.Thing.ThingName} } ] }这里面iot:GetPendingJobExecutions也别漏了。设备 SDK 在获取任务列表时会调用这个 Action如果缺少设备端连“发现自己有任务”都做不到更别提后续的下载和升级了。6. App 端架构与连接管理如何做到稳定且省钱做 IoT App 跟做普通业务 App 最大的区别在于App 需要长期保持对设备状态的感知。如果只是调用一次 HTTP API 拉数据那没什么复杂的但如果你想做实时状态更新、告警推送、远程控制那 App 的架构设计就很重要了。6.1 数据模型设计三种数据的分层处理物联网 App 里有三类数据我习惯分开设计。第一类是实时遥测数据比如温度、湿度、设备开关状态特点是频率高、实时性强适合用 MQTT over WebSocket 或 Server-Sent Events 推送。第二类是设备属性与配置数据比如设备名称、安装位置、固件版本、上报间隔这类数据低频更新适合通过 API 查询缓存在 App 本地。第三类是历史时序数据用于图表展示和报表分析这类数据量大适合分页查询App 端做本地缓存和预加载。在 App 的本地数据库里我会用三张表对应这三类数据realtime_metrics只保留最近几分钟的数据复用率高但量不大device_profiles存设备的静态属性historical_metrics按天分表或加时间分区避免单表数据膨胀。6.2 App 连接 AWS IoT 的四种方式与选型App 端想拿到 AWS IoT 的数据有四种常见方式。第一种纯 HTTPS API 轮询。最简单用 API Gateway 封装查询接口App 定时拉取。适合对实时性要求不高的场景。第二种MQTT over WebSocket。设备 App 可以直接用 AWS IoT 的 MQTT 端点 wss:// 前缀连接用 Cognito 身份池做认证。实现相对复杂但可以实时收到设备状态推送。第三种AppSync 作为实时 API 层。AppSync 支持订阅Subscription底层是通过 WebSocket 推送数据。AWS IoT 规则引擎把数据写入 DynamoDBDynamoDB Streams 触发 Lambda 更新 AppSync 的实时数据源。这套链路维护成本高一些但对客户端非常友好客户端只需要写 GraphQL 查询和订阅。第四种Amazon SNS / Pinpoint 做手机推送通知。适合“设备告警时给用户弹通知”的场景但只适合低频事件不适合实时数据流。我的建议是MVP 阶段用第一种产品稳定后按需引到第二种或第三种。不要一上来就上 MQTT over WebSocket连接管理、重连策略、弱网处理都会占用大量开发时间。先让业务跑起来再优化实时体验。6.3 连接管理与弱网优化经验这里分享几个实测有用的 App 端经验。第一连接状态机要设计好。App 端至少要有四个状态CONNECTING、CONNECTED、DISCONNECTED、RECONNECTING。不要简单用一个布尔值表示“已连接”否则弱网环境下你没法判断是短暂抖动还是连接彻底断了。第二WebSocket 断线重连要做指数退避。比如第一次 1 秒后重连第二次 2 秒第三次 4 秒最大间隔不超过 60 秒。同时要加随机抖动避免大量 App 同时重连打爆服务端。这个是我在线上事故里学到的有一次我们发版后服务端重启所有 App 同时断线又同时重连瞬间把网关打满后来加了退避才解决。第三前后台切换要处理。App 进入后台时建议主动断开 MQTT 连接用推送通知代替实时消息回到前台时再重新建立连接。否则系统会把 App 挂起连接处于假死状态你以为是连着的实际上服务端早把连接断掉了。6.4 App 发起控制指令时的可靠性保障App 下发控制指令最怕的是“发出去了但设备没执行”或者“执行了但 App 不知道”。对于这个我习惯用“指令 回执 状态确认”三段式。指令阶段App 调 API GatewayAPI 把请求写入 DynamoDB 的command_records表状态为 PENDING然后通过 MQTT 发布到设备主题。回执阶段设备收到指令并执行后发布回执到dev/{device_id}/cmd/ackLambda 收到后把command_records对应记录状态改为 SUCCEEDED 或 FAILED。状态确认阶段App 端定时轮询该指令记录的状态如果超时未更新则提示用户“指令可能未送达”。这个模式虽然多了一次数据库写操作但能把指令的完整生命周期串起来对排查问题非常有帮助。之前我做过一个纯 MQTT 单向控制结果设备离线时指令静默丢失用户投诉说“点了按钮没反应”。后来换成三段式至少能明确告诉用户是“指令已发送等待设备响应”还是“设备不在线”体验好了很多。7. 常见问题与坑位排查实录最后这部分我整理一下我遇到过的、以及身边朋友常问的高频问题帮你少走弯路。7.1 设备连不上 AWS IoT Core怎么自检设备连不上的原因太多了我通常按下面这个顺序查检查 Endpoint 地址是否正确。每个区域的 Endpoint 不一样在 AWS IoT Core 控制台左下角“Settings”里能看到格式类似xxxxxxxxxxxxxx-ats.iot.us-east-1.amazonaws.com。注意不要用旧版不带-ats的 Endpoint它不支持 MQTT。检查证书是否激活。AWS IoT 控制台“Security - Certificates”里能看到证书状态如果是 Inactive设备连不上。检查 IoT Policy 是否绑定到证书。证书本身就激活还不够必须把 IoT Policy 附加到证书上或者通过 Thing 的 principal 关联策略。之前我遇到过证书绑定了 Thing但策略直接挂在 Thing 上而不是证书上导致连接认证失败。检查设备时间是否正确。TLS 握手时如果设备系统时间偏差太大证书校验会失败表现为连接超时。这个坑特别容易忽略。看 AWS IoT 的日志。在 CloudWatch Logs 里开 Connect 类型的日志能看到连接失败的详细原因。7.2 消息能上报但收不到指令这种问题一般出在策略上。设备能上报说明设备身份认证已经通过但收不到指令通常是订阅权限不够。检查两个地方物联网策略是否有iot:Subscribe和iot:Receive权限以及策略的 Resource 是否覆盖了你订阅的主题。还有一个小细节MQTT 的 QoS 0 和 QoS 1 行为不同。如果设备离线期间服务端发了一条 QoS 0 消息设备重连后是收不到这条消息的。如果想保证离线消息不丢订阅时要用 QoS 1发布时也要用 QoS 1并且服务端要配置保留消息retain或者用影子方案。7.3 OTA 任务创建成功但设备不执行常见原因有三个。第一个是设备端 IoT Policy 缺少 jobs 主题的订阅权限这个前面已经说过。第二个是设备没有订阅$aws/things/{thing_name}/jobs/notify-next主题导致有任务时设备无感知。第三个是任务的目标设备选错了比如你创建任务时选的是 Device Group A但实际设备注册在 Device Group B。排查建议先用 AWS CLI 调用一下describe-job-execution看任务执行记录里设备端是否有响应。如果记录显示任务还在 QUEUED说明设备端根本没请求任务如果显示 IN_PROGRESS说明设备已开始处理但可能卡在下载固件或校验过程中这时候要结合设备端日志和 CloudWatch 一起看。7.4 设备影子一直处于 desired 和 reported 不一致状态这个通常意味着设备收到了 desired 变更但一直没有更新 reported。排查思路确认设备是否订阅了$aws/things/{thing_name}/shadow/update/delta主题确认设备处理完状态后是否正确调用了 shadow update API 更新 reported如果设备是离线状态影子更新会延迟直到设备重连并同步。一个额外经验不要在影子文档里放时间戳字段作为顶层字段因为 AWS IoT 的 shadow 有严格的保留字段限制state里的字段名不能以$开头而且state本身保留。如果你看到奇怪的报错优先检查 JSON 字段名。7.5 成本突增连接分钟数和消息数超预算我见过最夸张的一次成本激增是因为设备端 MQTT 连接心跳间隔太短。设备的 MQTT keep-alive 设置为 5 秒每次重连都产生新的连接分钟数几千台设备一个月下来费用直接爆表。建议 keep-alive 至少设置为 30 秒以上并且检查设备是否有“频繁断连重连”的异常行为比如弱网环境下 TCP 超时。另外遥测上报频率对成本影响极大。每台设备每天多报 1000 条消息一万台设备一个月就是 3 亿条消息按 AWS 的计价单位“百万条消息”一档档累加费用非常可观。做产品时数据上报频率一定要设计成可配置项远程能动态调整而不是写死在固件里。写在最后的一点个人建议我在做 IoT 项目的这些年里最大的体会是软件架构再漂亮也扛不住设备端各种不可控因素。做云端时一定要多留一手比如把设备上报的数据做冗余存储把指令下发做成可追踪的状态机把 OTA 做成可回滚的流程。AWS IoT 的工具链已经帮你解决了很多底层问题但产品级的可靠性还是要靠自己在业务层一层层补齐。如果你现在正打算从零开始做 IoT App我建议先把这篇里 4.2 和 4.3 的最小闭环跑通再逐步加复杂功能。先有能用的系统再谈优化和扩展。过程中遇到具体问题可以按第 7 节的排查思路逐项自检大部分问题都能在这些清单里找到答案。