📚 课程目录第1章课程导入与工程全景

1. 课程导入与工程全景

在工业设备远程运维、智慧楼宇能耗采集、冷链物流温控追踪等场景中，现场往往分布着成百上千台传感器、PLC、网关或嵌入式终端。这些设备产生的数据如果只停留在本地，就无法支撑集中监控、预测性维护和跨地域协同。Azure IoT Hub 正是为解决"海量设备如何安全、可靠、可管理地接入云端"这一问题而设计的托管服务。它不是一个简单的消息中转站，而是设备身份、双向通信、消息路由、状态管理和安全策略的统一入口。

理解 IoT Hub 的价值，可以从三个层面展开。第一是身份与安全：每台设备在 Hub 中拥有独立身份，通过对称密钥、X.509 证书或 TPM 等方式完成认证，避免"一个密钥通吃全场"的风险。第二是双向通信：设备到云（D2C）用于上报遥测，云到设备（C2D）用于下发指令，设备孪生（Device Twin）和直接方法（Direct Method）则支撑配置同步与远程调用。第三是规模化与可管理性：IoT Hub 支持每单位数百万级设备连接，并提供配额、限流、路由和监控能力，使工程团队能够按 SLA 运营，而不是靠人工盯守。

典型工程场景可以归纳为四类。其一是遥测采集与可视化：现场温湿度、振动、电流等信号按固定周期上报，经 IoT Hub 路由到 Event Hubs、Blob Storage 或 Stream Analytics，最终进入 Power BI 或自建看板。其二是远程指令与配置下发：运维人员在云端修改采样频率或阈值，通过设备孪生期望属性或直接方法下发，设备确认后回传结果。其三是固件与文件传输：设备通过文件上传通道将日志或升级包传到存储账户，Hub 负责通知与状态跟踪。其四是边缘协同：现场网关运行 IoT Edge，在本地完成过滤、聚合和断网缓存，再与云端同步，降低带宽成本并提升实时性。

本课程的学习路径遵循"先通链路、再控设备、后做运维"的顺序。第一阶段建立最小可运行链路：创建 IoT Hub、注册设备、用示例代码完成 D2C 上报并在云端观察。第二阶段掌握双向控制：设备孪生读写、直接方法调用、C2D 消息接收与反馈。第三阶段进入工程化：消息路由、配额与限流、安全策略、监控告警、批量注册与自动化部署。第四阶段结合边缘与真实协议：MQTT/AMQP 细节、网关模式、离线缓存与断点续传。每一阶段都以可验证的结果收尾，而不是停留在概念记忆。

实验环境准备是本章最需要动手的部分。建议使用独立的 Azure 订阅或资源组，避免与生产资源混用。核心资源包括：一个 IoT Hub（开发阶段可选 S1 标准层，便于使用设备孪生和直接方法；免费层适合初步验证但功能受限）、一个存储账户（用于文件上传和路由落盘）、一个 Event Hubs 命名空间（用于路由目标）、以及可选的 Stream Analytics 作业。本地环境需要安装 Azure CLI、Azure IoT 扩展、.NET 或 Python SDK，以及一个 MQTT 客户端工具（如 mosquitto_pub/sub）用于手工验证。

下面给出一个可直接参考的环境准备清单，字段和取值按开发实验场景设定，实际使用时请替换为你的订阅与区域。

项目	示例值	说明
资源组	rg-iot-lab-eastus	与生产隔离，便于整体删除
IoT Hub 名称	iothub-lab-001	全局唯一，小写字母与数字
定价层	S1	支持孪生、方法、路由
设备 ID	dev-sensor-001	认证方式先用对称密钥
遥测周期	5 秒	便于观察消息计数
路由目标	Event Hubs / Storage	验证消息分发

创建 Hub 与注册设备可以用 CLI 完成，关键命令如下，注意把名称和资源组替换成自己的值：

az iot hub create --name iothub-lab-001 \
  --resource-group rg-iot-lab-eastus \
  --sku S1 --location eastus

az iot hub device-identity create \
  --hub-name iothub-lab-001 \
  --device-id dev-sensor-001

az iot hub device-identity connection-string show \
  --hub-name iothub-lab-001 \
  --device-id dev-sensor-001

拿到连接字符串后，可以用 Python SDK 发送一条遥测，验证链路是否打通。示例代码如下，运行后应在 Azure 门户的"消息数"指标中看到增长：

from azure.iot.device import IoTHubDeviceClient, Message
import json, time

conn = "HostName=iothub-lab-001.azure-devices.net;DeviceId=dev-sensor-001;SharedAccessKey=..."
client = IoTHubDeviceClient.create_from_connection_string(conn)

for i in range(5):
    payload = {"seq": i, "temp": 22.5 + i * 0.1, "ts": time.time()}
    client.send_message(Message(json.dumps(payload)))
    time.sleep(5)
client.shutdown()

判断接入是否成功，不能只看代码有没有报错。建议同时观察三个信号：设备端是否收到发送确认、门户指标中"遥测消息数"是否上升、以及路由目标（如 Event Hubs）是否收到对应记录。如果设备端成功但云端无数据，优先检查路由查询条件、目标是否启用以及消息是否被限流。如果连接被拒绝，检查连接字符串、设备状态是否被禁用、以及系统时间是否偏差过大导致 SAS 令牌失效。

开发阶段建议为每台设备单独注册身份，不要多台设备共用同一连接字符串。共用身份会导致无法按设备追踪、无法单独禁用，也会让孪生和方法调用失去意义。

IoT Hub 的免费层和标准层在功能上差异明显：免费层不支持设备孪生、直接方法和云到设备消息的完整能力。如果课程后续要做双向控制实验，请直接使用 S1 或更高层，避免中途迁移。

为了把本节的核心关系一次看清，下面用一张结构图串联"设备侧—接入层—云端服务—运维面"四个区域，并标出本课程后续会反复使用的关键对象与数据流向。

这张图把本课程后续会反复出现的对象一次摆清：左侧是设备与认证方式，中间是 IoT Hub 的四类核心能力，右侧是路由目标与下游应用，最右是运维面。箭头方向表示数据或控制流的走向，虚线表示监控与诊断信息的回流。建议在后续每完成一个实验后，回到这张图上标记自己已经打通了哪条路径，这样能清楚知道当前处于学习路径的哪个阶段。

最后需要强调一个工程习惯：接入不是"连上就完事"，而是"连上、可观测、可控制、可恢复"。在实验环境里，请从一开始就打开 IoT Hub 的诊断日志，把连接、路由、方法调用等事件送到 Log Analytics 或存储账户。这样当设备数量从 1 台增加到 100 台时，你仍然能通过查询定位问题，而不是靠逐台登录排查。下一阶段的所有实验，都会建立在本节创建的资源与这条最小链路上。