云服务模型与 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 service（IaaS，基础设施即服务）
- Platform as a service（PaaS，平台即服务）
- Serverless（无服务器）
- Software as a service（SaaS，软件即服务）
作业要求学习者调研这几种服务形态，解释它们分别是什么、彼此有何不同，并进一步说明哪些服务与 IoT 开发者相关。
作业还给出了明确的评分标准（Rubric），分为两个维度：
| 标准 | 优秀（Exemplary） | 合格（Adequate） | 需改进（Needs Improvement） |
|---|---|---|---|
| 解释不同的云服务形态 | 对全部 4 种服务给出了清晰解释 | 能解释其中 3 种 | 只能解释 1～2 种 |
| 解释哪些服务与 IoT 相关 | 说明了哪些服务与 IoT 开发者相关并解释原因 | 说明了相关服务但未解释原因 | 未能说明哪些服务与 IoT 开发者相关 |
可见，这份作业考察的不是"背名词"，而是"理解每种服务形态的本质差异，并能够把抽象的服务模型映射到 IoT 开发的具体需求上"。下面各节将给出可以直接用于完成作业的完整论述。
云是什么：从自建数据中心到"别人的电脑"
在理解四种服务形态之前，先要理解"云"本身。课程 README 用一句话概括了云的本质——"别人的电脑"（someone else's 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 系统。
典型特征：即开即用、零部署；通常按用户数/月订阅；扩展性与升级由服务商负责。
四种模型对比一览
| 维度 | IaaS | PaaS | Serverless | SaaS |
|---|---|---|---|---|
| 你管理的内容 | 操作系统、运行时、应用、数据 | 应用与数据 | 仅业务函数与数据 | 几乎只负责使用 |
| 服务商管理的内容 | 虚拟机、存储、网络、机房 | 底层平台、运行时、伸缩 | 资源调度、运行时、伸缩 | 整个软件产品 |
| 计费粒度 | 按租用的资源（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 Hub
Azure 中每个资源都必须归属一个资源组（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_name><hub_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 / Arduino）
Wio 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 Silicon（M 系列芯片）上尚未完全可用，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），仅供参考
