拓冰网站定制 
云服务模型与 IoT 选型实战解读 IoT-For-Beginners 农场项目第四课作业IaaS / PaaS / Serverless / SaaS【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners本篇文章围绕 2-farm/lessons/4-migrate-your-plant-to-the-cloud/assignment.md本仓库translations/bn/下的孟加拉语译本为同一内容展开课程要求学习者掌握云服务的四种主要形态——IaaS、PaaS、Serverless 与 SaaS——并解释它们之间的区别以及哪些服务对 IoT 开发者最相关。文章将以该作业为骨架结合本课 README.md 与仓库中的真实代码讲解把植物传感器从公共 MQTT broker 迁移到 Azure IoT Hub的完整过程。读完本文你将能够准确说出四种云服务模型的定义与差异、判断 IoT 场景下应优先选用哪类服务并通过 Azure CLI 从零创建 IoT Hub、注册设备、发送遥测与调用直接方法。本课作业解读要学什么、如何被评估作业原文assignment.md指出微软 Azure 这类云服务不只是出租计算能力其主流服务形态包括Infrastructure as a serviceIaaS基础设施即服务Platform as a servicePaaS平台即服务Serverless无服务器Software as a serviceSaaS软件即服务作业要求学习者调研这几种服务形态解释它们分别是什么、彼此有何不同并进一步说明哪些服务与 IoT 开发者相关。作业还给出了明确的评分标准Rubric分为两个维度标准优秀Exemplary合格Adequate需改进Needs Improvement解释不同的云服务形态对全部 4 种服务给出了清晰解释能解释其中 3 种只能解释 12 种解释哪些服务与 IoT 相关说明了哪些服务与 IoT 开发者相关并解释原因说明了相关服务但未解释原因未能说明哪些服务与 IoT 开发者相关可见这份作业考察的不是背名词而是理解每种服务形态的本质差异并能够把抽象的服务模型映射到 IoT 开发的具体需求上。下面各节将给出可以直接用于完成作业的完整论述。云是什么从自建数据中心到别人的电脑在理解四种服务形态之前先要理解云本身。课程 README 用一句话概括了云的本质——别人的电脑someone elses computer。在云计算出现之前企业若想为员工或公众提供数据库、文件存储、网站等服务必须自建并运营数据中心。这意味着企业要自己承担采购计算机硬件硬件维护供电与散热网络设施安全既包括机房安保也包括服务器软件安全软件安装与更新这种模式成本高昂、需要多种技能员工而且扩容极慢。课程给出了一个生动的例子如果一家线上商店要为节日旺季备货必须提前数月采购、配置、安装硬件与软件旺季结束后这些花了大价钱买来的机器只能闲置到下一个旺季。换言之自建数据中心在需求尖峰面前既不灵活也不经济。云计算的思路则完全不同由云服务商如微软 Azure、Google GCP在全球各地运营超大规模数据中心负责硬件采购安装、供电散热、网络、安保、软硬件更新等一切事务客户按需租用计算资源需求上涨时多租、需求下降时少租。课程指出这类数据中心占地面积可达数平方公里部分甚至拥有自建电厂并因规模效应在能效与可再生能源利用上优于大量小型数据中心。对企业而言使用云服务的价值在于把云基础设施的运维复杂度交给服务商用一张月度账单换取聚焦自身业务的能力而服务商则利用规模经济批量采购、自研工具与硬件进一步压低成本。本课程选用的云是微软 Azure后续所有实操命令均基于 Azure CLI 与 Azure IoT Hub。四种云服务模型详解这是作业的主体部分。下面逐一定义四种服务形态并说明它们的关键差异。IaaS基础设施即服务IaaS 提供最底层的云资源——虚拟机、存储、网络等基础设施级别的组件。你租到的是计算、存储和网络的原始能力而操作系统之上的环境搭建、运行时安装、应用部署与运维仍需自己负责。典型特征按需弹性分配虚拟机与磁盘客户拥有对操作系统和应用的完全控制权适合需要自定义底层环境、迁移传统应用直接搬上云的 lift-and-shift的场景。PaaS平台即服务PaaS 在基础设施之上进一步提供应用运行平台——例如托管数据库、消息队列、应用托管运行时、开发框架与中间件。你只需要提交代码或配置由平台负责底层资源的分配、伸缩、补丁与高可用。典型特征屏蔽服务器与操作系统细节显著减少运维负担内置横向扩展能力适合以应用开发为核心的团队。Serverless无服务器Serverless 是 PaaS 的进一步演进以事件/函数为粒度计费与调度。你编写的函数仅在事件触发时执行执行期间由平台分配资源空闲时不产生费用因此无需预留任何容量。典型的例子包括云函数Function as a Service以及托管的数据库、消息服务等完全托管组件。典型特征按调用次数与执行时长计费天然应对突发流量开发者只关心业务逻辑不关心服务器适合事件驱动型工作负载例如一条遥测消息到达 → 触发函数 → 写入数据库。SaaS软件即服务SaaS 是面向最终用户的完整软件产品通过浏览器或客户端按订阅提供。你不需要关心任何底层基础设施、平台甚至应用本身的维护——例如企业邮箱、在线办公套件、CRM 系统。典型特征即开即用、零部署通常按用户数/月订阅扩展性与升级由服务商负责。四种模型对比一览维度IaaSPaaSServerlessSaaS你管理的内容操作系统、运行时、应用、数据应用与数据仅业务函数与数据几乎只负责使用服务商管理的内容虚拟机、存储、网络、机房底层平台、运行时、伸缩资源调度、运行时、伸缩整个软件产品计费粒度按租用的资源vCPU/内存/磁盘按平台用量/托管实例按调用次数与执行时长按订阅用户/席位弹性程度手动/自动扩缩容需配置平台自动伸缩自动、瞬时伸缩由服务商承担典型使用方平台/系统工程师应用开发团队事件驱动开发终端用户/业务部门IoT 开发者视角哪些服务相关为什么作业的第二问是哪些服务与 IoT 开发者相关。要回答这个问题需要先理解 IoT 场景在公共 MQTT broker上的痛点再看云 IoT 服务如何解决它们。公共 MQTT broker 的四个短板课程在之前一课用公共 MQTT broker 演示了遥测上报与继电器控制但它并不适合商用场景原因有四可靠性免费公共服务没有 SLA随时可能被关闭安全性完全公开任何人都可以监听你的遥测数据或向你的硬件发送恶意控制指令性能仅面向少量测试消息设计无法承载大规模消息量可发现性无法得知当前有哪些设备已连接。云 IoT 服务为设备接入而生的 PaaS云服务商提供的IoT 平台服务如 Azure IoT Hub在本质上是面向物联网的 PaaS它托管设备接入、消息路由、身份认证、设备管理等平台级能力这正是 IoT 开发者最需要开箱即用的部分。课程归纳了云 IoT 服务的核心价值可靠由投入大量可靠性资源的大型云服务商运维安全内置身份与密钥机制阻止黑客读取数据或发送非法命令高性能可承载每天数百万条消息并借助云弹性按需伸缩。在接入方式上IoT 设备可通过设备 SDK封装了主题、安全等细节的库连接也可直接用 MQTT/HTTP 等协议连接服务端应用则通过服务 SDK从服务读取设备消息或向设备下发指令安全机制方面云 IoT 服务维护一份可连接设备清单设备要么预先注册要么携带密钥/证书在首次连接时自助注册。未注册的陌生设备连接请求会被拒绝、其消息被忽略以 Azure IoT Hub 为例它提供了四类设备与云之间的通信通道这也是从 MQTT 主题迁移到云服务后需要掌握的核心概念通信类型方向用途说明设备到云D2C消息设备 → 云遥测上报应用代码可从 Hub 读取底层基于 Azure Event Hubs读取时通常称为事件云到设备C2D消息云 → 设备下发指令/通知由应用代码经 Hub 发送给指定设备直接方法Direct method云 → 设备请求设备执行动作如控制执行器必须返回响应调用方据此判断是否执行成功设备孪生Device twin双向同步属性/设置JSON 文档设备上报属性reported、云侧设置期望属性desired永久保存IoT Hub 还提供消息留存能力D2C 消息与直接方法请求可配置保留时长默认 1 天设备或应用断线重连后仍可读取离线期间的消息设备孪生则永久保存在 Hub 中设备随时重连都能取到最新状态。给作业的结论综合来看对 IoT 开发者相关性最高的是 PaaS 形态的 IoT 平台服务IoT Hub 类原因在于IoT 开发的核心工作量在于设备端固件/应用与设备管理而连接管理、身份认证、消息路由、设备注册与伸缩扩容恰好是平台已封装好的能力。IaaS在需要自定义网关、边缘节点运行环境时也会用到后续课程迁移应用到云中会涉及将代码容器化部署到边缘/云端Serverless则非常适合编写遥测消息 → 触发函数 → 入库/告警这类事件驱动的后端处理逻辑SaaS一般不是 IoT 开发者需要自建的部分但可作为现成的可视化、告警、报表工具来集成。实战落地把植物传感器迁移到 Azure IoT Hub理解了模型之后作业还隐含了一个任务背景——把本课之前的土壤湿度 继电器项目从公共 MQTT broker 迁移到 Azure IoT Hub。以下 CLI 流程与代码均来自课程 README.md 及code/目录。第一步准备 Azure 订阅课程提供了两种免费订阅方案Azure for Students面向 18 岁以上学生无需信用卡用学校邮箱验证身份可获得 100 美元信用额度及免费服务含免费 IoT 服务有效期 12 个月在读期间每年可续Azure 免费订阅面向非学生注册需信用卡但不会扣费仅用于验证真人身份首 30 天可用 200 美元信用额度另有各服务的免费层级。注意面向 18 岁以下学生的 Starter 订阅在课程编写时不支持 IoT 服务。第二步安装并配置 Azure CLI# 安装 IoT 扩展管理 Azure IoT 服务 az extension add --name azure-iot # 登录你的 Azure 订阅会打开浏览器完成认证 az login # 如果拥有多个订阅如学校订阅 个人订阅先列出全部订阅 az account list --output table # 选定要使用的订阅 az account set --subscription SubscriptionId第三步创建资源组与 IoT HubAzure 中每个资源都必须归属一个资源组Resource Group便于统一管理与批量删除。先查询可用区域课程编写时约有 65 个区域再创建资源组az account list-locations --output table az group create --name soil-moisture-sensor \ --location location随后创建 IoT Hub。--sku F1表示免费层级——每个订阅只能创建一个免费层 IoT Hub免费层每天支持 8000 条消息且包含大部分付费层功能--partition-count 2定义数据分区数免费层必须显式设置az iot hub create --resource-group soil-moisture-sensor \ --sku F1 \ --partition-count 2 \ --name hub_namehub_name必须是全局唯一的名称会出现在 Hub 的 URL 中建议使用soil-moisture-sensor-加随机单词或你的名字作后缀。第四步注册设备并获取连接字符串只有注册过的设备才能连接 IoT Hub。注册后返回的连接字符串包含 Hub 地址、设备 ID 和密钥# 注册设备设备 ID 为 soil-moisture-sensor az iot hub device-identity create --device-id soil-moisture-sensor \ --hub-name hub_name # 获取该设备的连接字符串 az iot hub device-identity connection-string show --device-id soil-moisture-sensor \ --output table \ --hub-name hub_name课程特别强调连接字符串必须妥善保管安全主题会在后续课程深入实际项目中不应硬编码进源码而应使用环境变量配合python-dotenv之类的工具。第五步设备端代码改造Python / Raspberry Pi / 虚拟设备安装 SDK 并替换原 MQTT 代码pip3 install azure-iot-device课程给出的核心代码完整实现见 code/pi/soil-moisture-sensor/app.py 与 code/virtual-device/soil-moisture-sensor/app.py要点如下from azure.iot.device import IoTHubDeviceClient, Message, MethodResponse connection_string connection string # 基于连接字符串创建设备客户端并连接 device_client IoTHubDeviceClient.create_from_connection_string(connection_string) device_client.connect() # 处理直接方法请求relay_on / relay_off 控制继电器 def handle_method_request(request): print(Direct method received - , request.name) if request.name relay_on: relay.on() elif request.name relay_off: relay.off() method_response MethodResponse.create_from_method_request(request, 200) device_client.send_method_response(method_response) device_client.on_method_request_received handle_method_request while True: soil_moisture adc.read(0) print(Soil moisture:, soil_moisture) # 遥测作为 D2C 消息发送 message Message(json.dumps({ soil_moisture: soil_moisture })) device_client.send_message(message) time.sleep(10)要点Message承载 JSON 遥测并作为设备到云消息发送handle_method_request处理云侧下发的直接方法MethodResponse.create_from_method_request(request, 200)用 HTTP 200 状态码回执告知调用方处理成功。设备每 10 秒上报一次土壤湿度读数。第六步设备端代码改造Wio Terminal / ArduinoWio Terminal 的改造更复杂核心在于微控制器不像 PC 会自动同步时钟而 IoT Hub 的连接令牌基于时间因此必须先通过 NTP 获取当前时间。课程方案见 wio-terminal-connect-hub.md在 platformio.ini 中移除knolleary/PubSubClient加入 Azure IoT 相关库AzureIoTHub、AzureIoTUtility、AzureIoTProtocol_MQTT、AzureIoTProtocol_HTTP、AzureIoTSocket_WiFi与 Seeed Arduino RTC并追加build_flags -DDONT_USE_UPLOADTOBLOB在 config.h 中定义CONNECTION_STRING新增ntp.h实现initTime()——从0.pool.ntp.org获取 epoch 时间并写入系统时钟失败则每 2 秒重试在 main.cpp 中通过IoTHubDeviceClient_LL_CreateFromConnectionString(CONNECTION_STRING, MQTT_Protocol)建立连接底层即 MQTT注册连接状态回调与直接方法回调由于单线程模型loop中必须周期性调用IoTHubDeviceClient_LL_DoWork处理收发消息——课程用work_delay(10000)将 10 秒延时拆成每 100ms 一次的 DoWork 循环保证直接方法最多 100ms 内被响应。第七步用 CLI 监控遥测与调用直接方法设备运行后无需先编写服务端代码直接用 CLI 即可验证云端链路# 监控设备发往 Hub 的事件ctrl-c 停止 az iot hub monitor-events --hub-name hub_name # 查看消息的全部注解annotations含时间戳、来源等元数据 az iot hub monitor-events --properties anno --hub-name hub_name监控输出示例payload 与设备端发送的 JSON 一致{ event: { origin: soil-moisture-sensor, module: , interface: , component: , payload: {\soil_moisture\: 381} } }开启--properties anno后每条消息还会附带iothub-connection-device-id、iothub-connection-auth-method、iothub-enqueuedtime、x-opt-sequence-number等注解时间字段为 UNIX 时间1970 年 1 月 1 日午夜起经过的秒数。向设备下发直接方法控制继电器az iot hub invoke-device-method --device-id soil-moisture-sensor \ --method-name relay_on \ --method-payload {} \ --hub-name hub_name设备端串口/终端会打印Direct method received - relay_on继电器随之打开把--method-name换成relay_off即可关闭。提示课程编写时az iot扩展在 Apple SiliconM 系列芯片上尚未完全可用Mac 用户可用 VS Code 的 Azure IoT Tools 插件替代事件监控。挑战题免费层配额与采样频率设计课程为这一课预留了一道开放挑战见 README.md 的 Challenge 一节也可以作为作业的延伸思考IoT Hub 免费层每天允许 8000 条消息。当前代码每 10 秒发送一条遥测请计算每天会产生多少条消息土壤湿度该多久测一次才合理如何修改代码在免费层配额内既满足监测频率又不浪费配额如果要接入第二台设备呢简单计算每 10 秒一条 每分钟 6 条 每小时 360 条 每天 8640 条已经超出免费层 8000 条/天的上限。因此面向实际部署需要考虑加大上报间隔、按需上报仅在读数明显变化时发送、或为多设备分别估算配额。这也呼应了作业中理解服务形态差异的目标——在真实项目中服务的能力边界配额、计费粒度直接影响系统设计决策。用评分标准自测你的作业最后可以用作业的 Rubric 自查是否达到优秀标准能否清晰解释全部 4 种服务形态不仅要各自定义还要能说清差异管理边界、计费粒度、弹性方式能否说明哪些服务与 IoT 开发者相关并给出理由建议的论述主线是IoT 平台服务本质上是 PaaS它解决了公共 MQTT broker 在可靠性、安全、性能、可发现性上的短板IaaS/Serverless/SaaS 在 IoT 架构中的定位分别是边缘与自定义环境、事件驱动的后端处理、现成业务工具。完成上述分析后把结论与 assignment.md 的评分标准逐条对照即可形成一份结构完整、论据充分的作业答案。如果你想继续深入可以进一步阅读本课的两个实操指南 single-board-computer-connect-hub.md 与 wio-terminal-connect-hub.md以及仓库中对应的 Python 代码 和 Wio Terminal 工程 做逐行研读。【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 云服务模型与 IoT 选型实战：解读 IoT-For-Beginners 农场项目第四课作业（IaaS / PaaS / Serverless / SaaS）
云服务模型与 IoT 选型实战解读 IoT-For-Beginners 农场项目第四课作业IaaS / PaaS / Serverless / SaaS【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners本篇文章围绕 2-farm/lessons/4-migrate-your-plant-to-the-cloud/assignment.md本仓库translations/bn/下的孟加拉语译本为同一内容展开课程要求学习者掌握云服务的四种主要形态——IaaS、PaaS、Serverless 与 SaaS——并解释它们之间的区别以及哪些服务对 IoT 开发者最相关。文章将以该作业为骨架结合本课 README.md 与仓库中的真实代码讲解把植物传感器从公共 MQTT broker 迁移到 Azure IoT Hub的完整过程。读完本文你将能够准确说出四种云服务模型的定义与差异、判断 IoT 场景下应优先选用哪类服务并通过 Azure CLI 从零创建 IoT Hub、注册设备、发送遥测与调用直接方法。本课作业解读要学什么、如何被评估作业原文assignment.md指出微软 Azure 这类云服务不只是出租计算能力其主流服务形态包括Infrastructure as a serviceIaaS基础设施即服务Platform as a servicePaaS平台即服务Serverless无服务器Software as a serviceSaaS软件即服务作业要求学习者调研这几种服务形态解释它们分别是什么、彼此有何不同并进一步说明哪些服务与 IoT 开发者相关。作业还给出了明确的评分标准Rubric分为两个维度标准优秀Exemplary合格Adequate需改进Needs Improvement解释不同的云服务形态对全部 4 种服务给出了清晰解释能解释其中 3 种只能解释 12 种解释哪些服务与 IoT 相关说明了哪些服务与 IoT 开发者相关并解释原因说明了相关服务但未解释原因未能说明哪些服务与 IoT 开发者相关可见这份作业考察的不是背名词而是理解每种服务形态的本质差异并能够把抽象的服务模型映射到 IoT 开发的具体需求上。下面各节将给出可以直接用于完成作业的完整论述。云是什么从自建数据中心到别人的电脑在理解四种服务形态之前先要理解云本身。课程 README 用一句话概括了云的本质——别人的电脑someone elses computer。在云计算出现之前企业若想为员工或公众提供数据库、文件存储、网站等服务必须自建并运营数据中心。这意味着企业要自己承担采购计算机硬件硬件维护供电与散热网络设施安全既包括机房安保也包括服务器软件安全软件安装与更新这种模式成本高昂、需要多种技能员工而且扩容极慢。课程给出了一个生动的例子如果一家线上商店要为节日旺季备货必须提前数月采购、配置、安装硬件与软件旺季结束后这些花了大价钱买来的机器只能闲置到下一个旺季。换言之自建数据中心在需求尖峰面前既不灵活也不经济。云计算的思路则完全不同由云服务商如微软 Azure、Google GCP在全球各地运营超大规模数据中心负责硬件采购安装、供电散热、网络、安保、软硬件更新等一切事务客户按需租用计算资源需求上涨时多租、需求下降时少租。课程指出这类数据中心占地面积可达数平方公里部分甚至拥有自建电厂并因规模效应在能效与可再生能源利用上优于大量小型数据中心。对企业而言使用云服务的价值在于把云基础设施的运维复杂度交给服务商用一张月度账单换取聚焦自身业务的能力而服务商则利用规模经济批量采购、自研工具与硬件进一步压低成本。本课程选用的云是微软 Azure后续所有实操命令均基于 Azure CLI 与 Azure IoT Hub。四种云服务模型详解这是作业的主体部分。下面逐一定义四种服务形态并说明它们的关键差异。IaaS基础设施即服务IaaS 提供最底层的云资源——虚拟机、存储、网络等基础设施级别的组件。你租到的是计算、存储和网络的原始能力而操作系统之上的环境搭建、运行时安装、应用部署与运维仍需自己负责。典型特征按需弹性分配虚拟机与磁盘客户拥有对操作系统和应用的完全控制权适合需要自定义底层环境、迁移传统应用直接搬上云的 lift-and-shift的场景。PaaS平台即服务PaaS 在基础设施之上进一步提供应用运行平台——例如托管数据库、消息队列、应用托管运行时、开发框架与中间件。你只需要提交代码或配置由平台负责底层资源的分配、伸缩、补丁与高可用。典型特征屏蔽服务器与操作系统细节显著减少运维负担内置横向扩展能力适合以应用开发为核心的团队。Serverless无服务器Serverless 是 PaaS 的进一步演进以事件/函数为粒度计费与调度。你编写的函数仅在事件触发时执行执行期间由平台分配资源空闲时不产生费用因此无需预留任何容量。典型的例子包括云函数Function as a Service以及托管的数据库、消息服务等完全托管组件。典型特征按调用次数与执行时长计费天然应对突发流量开发者只关心业务逻辑不关心服务器适合事件驱动型工作负载例如一条遥测消息到达 → 触发函数 → 写入数据库。SaaS软件即服务SaaS 是面向最终用户的完整软件产品通过浏览器或客户端按订阅提供。你不需要关心任何底层基础设施、平台甚至应用本身的维护——例如企业邮箱、在线办公套件、CRM 系统。典型特征即开即用、零部署通常按用户数/月订阅扩展性与升级由服务商负责。四种模型对比一览维度IaaSPaaSServerlessSaaS你管理的内容操作系统、运行时、应用、数据应用与数据仅业务函数与数据几乎只负责使用服务商管理的内容虚拟机、存储、网络、机房底层平台、运行时、伸缩资源调度、运行时、伸缩整个软件产品计费粒度按租用的资源vCPU/内存/磁盘按平台用量/托管实例按调用次数与执行时长按订阅用户/席位弹性程度手动/自动扩缩容需配置平台自动伸缩自动、瞬时伸缩由服务商承担典型使用方平台/系统工程师应用开发团队事件驱动开发终端用户/业务部门IoT 开发者视角哪些服务相关为什么作业的第二问是哪些服务与 IoT 开发者相关。要回答这个问题需要先理解 IoT 场景在公共 MQTT broker上的痛点再看云 IoT 服务如何解决它们。公共 MQTT broker 的四个短板课程在之前一课用公共 MQTT broker 演示了遥测上报与继电器控制但它并不适合商用场景原因有四可靠性免费公共服务没有 SLA随时可能被关闭安全性完全公开任何人都可以监听你的遥测数据或向你的硬件发送恶意控制指令性能仅面向少量测试消息设计无法承载大规模消息量可发现性无法得知当前有哪些设备已连接。云 IoT 服务为设备接入而生的 PaaS云服务商提供的IoT 平台服务如 Azure IoT Hub在本质上是面向物联网的 PaaS它托管设备接入、消息路由、身份认证、设备管理等平台级能力这正是 IoT 开发者最需要开箱即用的部分。课程归纳了云 IoT 服务的核心价值可靠由投入大量可靠性资源的大型云服务商运维安全内置身份与密钥机制阻止黑客读取数据或发送非法命令高性能可承载每天数百万条消息并借助云弹性按需伸缩。在接入方式上IoT 设备可通过设备 SDK封装了主题、安全等细节的库连接也可直接用 MQTT/HTTP 等协议连接服务端应用则通过服务 SDK从服务读取设备消息或向设备下发指令安全机制方面云 IoT 服务维护一份可连接设备清单设备要么预先注册要么携带密钥/证书在首次连接时自助注册。未注册的陌生设备连接请求会被拒绝、其消息被忽略以 Azure IoT Hub 为例它提供了四类设备与云之间的通信通道这也是从 MQTT 主题迁移到云服务后需要掌握的核心概念通信类型方向用途说明设备到云D2C消息设备 → 云遥测上报应用代码可从 Hub 读取底层基于 Azure Event Hubs读取时通常称为事件云到设备C2D消息云 → 设备下发指令/通知由应用代码经 Hub 发送给指定设备直接方法Direct method云 → 设备请求设备执行动作如控制执行器必须返回响应调用方据此判断是否执行成功设备孪生Device twin双向同步属性/设置JSON 文档设备上报属性reported、云侧设置期望属性desired永久保存IoT Hub 还提供消息留存能力D2C 消息与直接方法请求可配置保留时长默认 1 天设备或应用断线重连后仍可读取离线期间的消息设备孪生则永久保存在 Hub 中设备随时重连都能取到最新状态。给作业的结论综合来看对 IoT 开发者相关性最高的是 PaaS 形态的 IoT 平台服务IoT Hub 类原因在于IoT 开发的核心工作量在于设备端固件/应用与设备管理而连接管理、身份认证、消息路由、设备注册与伸缩扩容恰好是平台已封装好的能力。IaaS在需要自定义网关、边缘节点运行环境时也会用到后续课程迁移应用到云中会涉及将代码容器化部署到边缘/云端Serverless则非常适合编写遥测消息 → 触发函数 → 入库/告警这类事件驱动的后端处理逻辑SaaS一般不是 IoT 开发者需要自建的部分但可作为现成的可视化、告警、报表工具来集成。实战落地把植物传感器迁移到 Azure IoT Hub理解了模型之后作业还隐含了一个任务背景——把本课之前的土壤湿度 继电器项目从公共 MQTT broker 迁移到 Azure IoT Hub。以下 CLI 流程与代码均来自课程 README.md 及code/目录。第一步准备 Azure 订阅课程提供了两种免费订阅方案Azure for Students面向 18 岁以上学生无需信用卡用学校邮箱验证身份可获得 100 美元信用额度及免费服务含免费 IoT 服务有效期 12 个月在读期间每年可续Azure 免费订阅面向非学生注册需信用卡但不会扣费仅用于验证真人身份首 30 天可用 200 美元信用额度另有各服务的免费层级。注意面向 18 岁以下学生的 Starter 订阅在课程编写时不支持 IoT 服务。第二步安装并配置 Azure CLI# 安装 IoT 扩展管理 Azure IoT 服务 az extension add --name azure-iot # 登录你的 Azure 订阅会打开浏览器完成认证 az login # 如果拥有多个订阅如学校订阅 个人订阅先列出全部订阅 az account list --output table # 选定要使用的订阅 az account set --subscription SubscriptionId第三步创建资源组与 IoT HubAzure 中每个资源都必须归属一个资源组Resource Group便于统一管理与批量删除。先查询可用区域课程编写时约有 65 个区域再创建资源组az account list-locations --output table az group create --name soil-moisture-sensor \ --location location随后创建 IoT Hub。--sku F1表示免费层级——每个订阅只能创建一个免费层 IoT Hub免费层每天支持 8000 条消息且包含大部分付费层功能--partition-count 2定义数据分区数免费层必须显式设置az iot hub create --resource-group soil-moisture-sensor \ --sku F1 \ --partition-count 2 \ --name hub_namehub_name必须是全局唯一的名称会出现在 Hub 的 URL 中建议使用soil-moisture-sensor-加随机单词或你的名字作后缀。第四步注册设备并获取连接字符串只有注册过的设备才能连接 IoT Hub。注册后返回的连接字符串包含 Hub 地址、设备 ID 和密钥# 注册设备设备 ID 为 soil-moisture-sensor az iot hub device-identity create --device-id soil-moisture-sensor \ --hub-name hub_name # 获取该设备的连接字符串 az iot hub device-identity connection-string show --device-id soil-moisture-sensor \ --output table \ --hub-name hub_name课程特别强调连接字符串必须妥善保管安全主题会在后续课程深入实际项目中不应硬编码进源码而应使用环境变量配合python-dotenv之类的工具。第五步设备端代码改造Python / Raspberry Pi / 虚拟设备安装 SDK 并替换原 MQTT 代码pip3 install azure-iot-device课程给出的核心代码完整实现见 code/pi/soil-moisture-sensor/app.py 与 code/virtual-device/soil-moisture-sensor/app.py要点如下from azure.iot.device import IoTHubDeviceClient, Message, MethodResponse connection_string connection string # 基于连接字符串创建设备客户端并连接 device_client IoTHubDeviceClient.create_from_connection_string(connection_string) device_client.connect() # 处理直接方法请求relay_on / relay_off 控制继电器 def handle_method_request(request): print(Direct method received - , request.name) if request.name relay_on: relay.on() elif request.name relay_off: relay.off() method_response MethodResponse.create_from_method_request(request, 200) device_client.send_method_response(method_response) device_client.on_method_request_received handle_method_request while True: soil_moisture adc.read(0) print(Soil moisture:, soil_moisture) # 遥测作为 D2C 消息发送 message Message(json.dumps({ soil_moisture: soil_moisture })) device_client.send_message(message) time.sleep(10)要点Message承载 JSON 遥测并作为设备到云消息发送handle_method_request处理云侧下发的直接方法MethodResponse.create_from_method_request(request, 200)用 HTTP 200 状态码回执告知调用方处理成功。设备每 10 秒上报一次土壤湿度读数。第六步设备端代码改造Wio Terminal / ArduinoWio Terminal 的改造更复杂核心在于微控制器不像 PC 会自动同步时钟而 IoT Hub 的连接令牌基于时间因此必须先通过 NTP 获取当前时间。课程方案见 wio-terminal-connect-hub.md在 platformio.ini 中移除knolleary/PubSubClient加入 Azure IoT 相关库AzureIoTHub、AzureIoTUtility、AzureIoTProtocol_MQTT、AzureIoTProtocol_HTTP、AzureIoTSocket_WiFi与 Seeed Arduino RTC并追加build_flags -DDONT_USE_UPLOADTOBLOB在 config.h 中定义CONNECTION_STRING新增ntp.h实现initTime()——从0.pool.ntp.org获取 epoch 时间并写入系统时钟失败则每 2 秒重试在 main.cpp 中通过IoTHubDeviceClient_LL_CreateFromConnectionString(CONNECTION_STRING, MQTT_Protocol)建立连接底层即 MQTT注册连接状态回调与直接方法回调由于单线程模型loop中必须周期性调用IoTHubDeviceClient_LL_DoWork处理收发消息——课程用work_delay(10000)将 10 秒延时拆成每 100ms 一次的 DoWork 循环保证直接方法最多 100ms 内被响应。第七步用 CLI 监控遥测与调用直接方法设备运行后无需先编写服务端代码直接用 CLI 即可验证云端链路# 监控设备发往 Hub 的事件ctrl-c 停止 az iot hub monitor-events --hub-name hub_name # 查看消息的全部注解annotations含时间戳、来源等元数据 az iot hub monitor-events --properties anno --hub-name hub_name监控输出示例payload 与设备端发送的 JSON 一致{ event: { origin: soil-moisture-sensor, module: , interface: , component: , payload: {\soil_moisture\: 381} } }开启--properties anno后每条消息还会附带iothub-connection-device-id、iothub-connection-auth-method、iothub-enqueuedtime、x-opt-sequence-number等注解时间字段为 UNIX 时间1970 年 1 月 1 日午夜起经过的秒数。向设备下发直接方法控制继电器az iot hub invoke-device-method --device-id soil-moisture-sensor \ --method-name relay_on \ --method-payload {} \ --hub-name hub_name设备端串口/终端会打印Direct method received - relay_on继电器随之打开把--method-name换成relay_off即可关闭。提示课程编写时az iot扩展在 Apple SiliconM 系列芯片上尚未完全可用Mac 用户可用 VS Code 的 Azure IoT Tools 插件替代事件监控。挑战题免费层配额与采样频率设计课程为这一课预留了一道开放挑战见 README.md 的 Challenge 一节也可以作为作业的延伸思考IoT Hub 免费层每天允许 8000 条消息。当前代码每 10 秒发送一条遥测请计算每天会产生多少条消息土壤湿度该多久测一次才合理如何修改代码在免费层配额内既满足监测频率又不浪费配额如果要接入第二台设备呢简单计算每 10 秒一条 每分钟 6 条 每小时 360 条 每天 8640 条已经超出免费层 8000 条/天的上限。因此面向实际部署需要考虑加大上报间隔、按需上报仅在读数明显变化时发送、或为多设备分别估算配额。这也呼应了作业中理解服务形态差异的目标——在真实项目中服务的能力边界配额、计费粒度直接影响系统设计决策。用评分标准自测你的作业最后可以用作业的 Rubric 自查是否达到优秀标准能否清晰解释全部 4 种服务形态不仅要各自定义还要能说清差异管理边界、计费粒度、弹性方式能否说明哪些服务与 IoT 开发者相关并给出理由建议的论述主线是IoT 平台服务本质上是 PaaS它解决了公共 MQTT broker 在可靠性、安全、性能、可发现性上的短板IaaS/Serverless/SaaS 在 IoT 架构中的定位分别是边缘与自定义环境、事件驱动的后端处理、现成业务工具。完成上述分析后把结论与 assignment.md 的评分标准逐条对照即可形成一份结构完整、论据充分的作业答案。如果你想继续深入可以进一步阅读本课的两个实操指南 single-board-computer-connect-hub.md 与 wio-terminal-connect-hub.md以及仓库中对应的 Python 代码 和 Wio Terminal 工程 做逐行研读。【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考