做IoT开发这些年，最常被问到的问题就是：设备端的数据到底怎么传？直连云端、设备之间互发，还是先汇聚到网关再统一上云？这背后其实就是D2C、D2D、D2G这三种通信模型的选择。再加上MQTT这类基于Pub/Sub发布订阅模式的协议，很多新手一上来就被这些术语绕晕了。这篇文章我想把这张IoT通信模型的全景图摊开，结合我自己实际项目中踩过的坑，把D2C、D2D、D2G和Pub/Sub模型从原理到选型再到落地，一次讲透。适合刚入门的嵌入式工程师、IoT平台开发者和正在做架构选型的朋友。
1. 三种经典通信模型：D2C / D2D / D2G 的全景拆解
先给这三兄弟定性：它们描述的是“谁跟谁直接说话”的通信拓扑关系，也就是数据从源头到目的地的路径形态。这个维度很关键，因为不同的拓扑直接决定了网络的可靠性、功耗、时延和部署成本。
1.1 D2C：设备直连云端的简单与代价
D2C（Device to Cloud），设备直连云，是最直观的一种模型。设备端通过Wi-Fi、以太网、4G/5G蜂窝网络、NB-IoT等方式，直接与云平台建立连接，最常见的承载协议是MQTT over TLS，或者HTTPS。
为什么很多项目一开始都选D2C？因为简单。没有中间节点，没有网关的部署和运维成本，设备上电就能连，云端下发指令能直达设备。我第一次做共享充电桩项目时，用的就是纯D2C：每个充电桩内置一张4G SIM卡，走MQTT直接连到云端，远程开关、计费上报都靠这条链路。
但D2C的代价也很明显。第一，设备端直接接入公网，安全边界需要自己守好。设备证书管理、一机一密的鉴权、TLS握手建立，这些环节一个都不能少。特别是一些SPA厂商在出厂时预置了相同的密钥，一旦泄露，整个产品线的设备都会被接管，这种事故我真实见过。第二，功耗高。Wi-Fi和蜂窝模块一直是耗电大户，对电池供电的设备非常不友好。一颗18650电池供一个常联Wi-Fi的传感器，可能撑不了几个月；换成NB-IoT虽然好一些，但也要考虑PSM模式下的唤醒周期。第三，海量设备同时在线时，云端连接管理压力巨大。每台设备都要维护长连接和心跳，一旦规模到十万级，连接网关和Broker集群的投入会非常可观。
所以我的经验是，D2C适合连接数量可控、供电稳定、需要广域覆盖的设备，比如充电桩、共享单车、远程监控摄像头。如果设备数量上了十万级，又是电池供电，纯D2C就很吃力了。此外，设备直连云意味着设备侧的软件栈要自己处理OTA、日志采集、远程调试，这些功能在D2C模型下往往要额外开发，不能指望网关替你做。
1.2 D2D：设备间直连的低时延与拓扑限制
D2D（Device to Device）描述的是设备之间直接通信，不依赖云端或中央网关。这里的典型代表是Zigbee、Z-Wave、BLE Mesh、Thread这些短距离无线Mesh技术，也包括LoRa这种长距离低功耗的星型网络，以及蜂窝网络里的直通技术。
D2D最大的价值是低时延和本地自治。智能家居里，开关按下，灯泡亮起，这条链路完全走的是本地Zigbee网络，几十毫秒内完成。如果所有指令都要绕一圈云端再回来，网络一抖动，灯就延迟，体验极差。在工业现场，传感器和设备之间的联锁控制同样依赖D2D。比如两个辊道之间距离只有两米，前一个辊道要停，信号如果走云端再回来，可能已经撞上了。
实操中D2D的一个关键在于Mesh组网的可靠性。Zigbee、BLE Mesh节点之间需要互相中继，任何一个节点掉线，网络会自动寻找新路径，但前提是你选用的协议栈和部署节点的密度要合理。我在一个办公楼照明项目里调试BLE Mesh，节点间距拉得太大，中间路径不稳定，指令经常隔几秒才到。后来把节点间距压缩到20米以内，网络就稳了。另一个重点是要理解不同D2D技术的差异：Zigbee的鲁棒性更好，但需要专用协调器；BLE Mesh的手机生态集成方便，但大规模组网的协议栈复杂度高；Thread基于IPv6，应用层接入更标准化，但普及度还一般。
D2D的局限在于：它本身不产生“全局数据视图”。设备之间在本地通信得很欢，但这些消息如果没有人汇总，云端就拿不到数据。所以现实项目中，D2D几乎总是和网关或云端叠加使用，本地走D2D，汇聚层再走D2G或D2C。还有一点要注意，D2D在蜂窝网络语境下有特殊含义，比如LTE直通技术，可以让两个相距很近的终端不经过基站直接通信，这在车队协同、应急通信里有价值，但在消费IoT里还远不如Zigbee/BLE普及。
1.3 D2G：通过网关汇聚的规模与稳定性
D2G（Device to Gateway）是我个人在大型项目里最依赖的模型，也是大规模IoT系统的“正规军”做法。末梢设备先接入局域网络中的网关设备，再统一由网关通过广域网（以太网、4G/5G、光纤）连到云端。
为什么需要网关？第一，协议转换。Zigbee、Z-Wave、Modbus、CAN、BACnet这些协议五花八门，云端不可能直接对接所有协议，网关负责把各种协议统一转换为MQTT、CoAP这类云端能理解的标准协议。第二，本地自治。网关能跑本地规则引擎，家里网关在断网时依然能执行“离家关灯”这类本地联动；工业网关能在断网时把生产数据缓存到本地，网络恢复后再补传。第三，安全隔离。末梢设备不直接暴露公网，出错的边界被控制在局域网内，即使单个传感器被攻破，攻击面也不会直接延伸到云端。
D2G的另一个价值是扩展性。一千个传感器如果全部直连云，云端要维护一千个连接；但如果分成20个网关，每个网关挂50个设备，云端只需要维护20个连接，整体稳定性完全不是一个量级。我做过一个智慧养殖项目，首批只部署了20个网关，每个网关挂了大约120个传感器节点，云端Broker的负载非常低，这要是全部直连，光是连接数就已经把消息层打满了。
适用场景非常广泛：智能家居、楼宇自控、工业数据采集、养殖场环境监控，基本都是D2G的典型代表。网关设备的选型要注意几点：一是算力，要能跑得动协议转换和规则引擎，至少要能流畅运行Linux和MQTT Broker；二是存储，要给离线数据留够缓存空间，建议使用带掉电保护的存储方案，比如eMMC或工业级TF卡；三是硬件看门狗，工业现场网关死机是大忌，软硬件看门狗必须同时具备。
1.4 三者的核心差异与选型边界一表看懂
我把三个模型放在一张表里对比，这个每次做技术评审我都会贴出来。
| 维度 | D2C 设备直连云 | D2D 设备间直连 | D2G 设备经网关接入 |
|---|---|---|---|
| 通信拓扑 | 设备-云，一跳 | 设备-设备，多跳/网状 | 设备-网关-云，两级 |
| 典型时延 | 取决于网络，通常100ms以上 | 最低，毫秒级 | 局域网内低，上云有网络开销 |
| 设备功耗 | 高（Wi-Fi/蜂窝） | 低（Zigbee/BLE等） | 低（末梢设备），网关需供电 |
| 部署成本 | 无网关成本，但需网络连接 | 无需云/网关，但需组网 | 网关成本高，但云端压力小 |
| 云端视角 | 每设备一连接 | 云端看不到设备间消息 | 每网关一连接 |
| 典型场景 | 充电桩、共享单车、摄像头 | 灯控、工业联锁、V2V | 智能家居、楼宇自控、工业采集 |
| 核心风险 | 功耗高、连接管理难、安全面大 | 无全局数据、范围有限 | 网关单点、需维护网关集群 |
选型边界我的判断标准是这样的：如果设备是电池供电的，优先考虑D2G，把通信大头压在网关；如果场景对时延要求是毫秒级，优先考虑D2D；如果设备是移动的、分布在广域范围，D2C几乎不可避免。实际项目里，模型不是二选一，一个系统完全可以混用，比如D2D做感知和控制，D2G做汇聚，云端再看D2C的最终结果，这个在后面我会给一个完整示例。
2. Pub/Sub 发布订阅模型：IoT 消息中枢的解耦哲学
把D2C/D2D/D2G弄明白之后，Pub/Sub模型就没那么玄乎了。它和前面三个不是同一个维度的概念。打个比方：前面三种模型定义了“地图上的路怎么走”，Pub/Sub定义的是“路上的信怎么寄”。两者可以自由组合。
2.1 从请求/响应到发布/订阅：IoT为什么要解耦
在传统HTTP世界里，客户端和服务器之间的交互是请求/响应模型：客户端请求，服务器响应，双方必须直接知道对方的存在，通信是一对一的。这对Web应用没问题，但放到IoT场景里就特别别扭。
IoT里设备数量极其庞大，动不动成千上万，而且连接不稳定、时常断网重连。如果每个设备都要和服务器保持“一对一请求-响应”，第一，服务器扛不住，连接数就是天花板；第二，设备一离线，消息就丢了；第三，根本无法实现“多个设备同时关心同一个数据”的需求。举个例子，一个车间的所有看板大屏都要显示同一个温度值，走请求/响应模式，每个屏幕得轮询问服务器，效率极低，而Pub/Sub只需要让它们订阅同一个主题，温度一更新，所有屏幕同时收到。
发布/订阅模型彻底改变了这个逻辑。消息的发送方（发布者）把消息发到一个称为Broker（消息代理）的中间件里，消息的接收方（订阅者）提前向Broker表达“我想接收哪些消息”，然后Broker在两者之间完成路由和分发。
这个“中间人”带来三个巨大的好处：
- 空间解耦：发布者不需要知道订阅读者是谁、有多少个、在哪里，订阅者也不需要知道发布者是谁。
- 时间解耦：发布者发出消息时，订阅者不必在线，Broker可以先存起来，等订阅者上线后再重投。
- 同步解耦：发布者发出消息后不必阻塞等待响应，异步处理，生产效率完全不同。
2.2 MQTT 的 Topic 设计与通配符：规划订阅关系
MQTT是目前IoT领域最主流的Pub/Sub实现之一，它的核心是主题（Topic）。Topic是一串带层级结构的字符串，用斜杠分隔，例如：
factory/line01/press01/temperature
这条主题可以理解为：工厂01号产线的压力机01的温度。主题中的每一级都可以包含字母、数字、下划线，尽量用英文，不要带中文和特殊字符，编码和跨平台兼容都会省掉很多麻烦。
订阅时，MQTT支持两个通配符：
+代表匹配任意单个层级。订阅factory/+/press01/temperature，就能收到任何产线的press01温度。#代表匹配任意多层级。订阅factory/#，就能收到该工厂下所有子主题的消息。
我用过的实践中，主题设计有几个原则特别重要。
第一，主题层级应该体现“数据的组织维度”，而不是“设备的组织维度”。什么意思？就是不要用设备ID作为顶层，比如device_123456/temperature。虽然这样每个设备能隔离开，但当你要订阅“所有温度传感器”时，就会发现主题层级没有统一的第二层，写起来非常痛苦。我的经验是，用“场所/类别/设备/数据点”的结构，例如site/beijing/factoryA/sensor05/temperature，这样区域、类别、粒度都能灵活订阅。
第二，为了权限管理，主题的顶层通常要预留一个“命名空间”，比如基于租户或者项目ID的目录。云端或网关的鉴权策略将来可以细致到某一层主题，给设备配置不同的读写权限。比如生产设备只允许发布到site/factoryA/device01/sensor/#，只允许订阅site/factoryA/device01/cmd/#，双向隔离，比整条链路粗粒度授权安全得多。
第三，消息体要精简。很多人把主题写得非常详细，而消息体放了一个很大的JSON，这没问题，但反过来也有很多人把设备ID、时间戳都堆在主题里，消息体反而空着。我更推荐把变化频繁、内容结构化强的数据放在消息体，把相对稳定的分类信息放在主题里，这样订阅和过滤的压力都在Broker端，设备端要保持简洁。
2.3 QoS 等级选择与消息可靠性保障
MQTT中，QoS（Quality of Service，服务质量）定义了消息投递的保障级别，它直接影响消息是否会丢、是否会重复。
QoS 0 最多一次：发布者发一次消息，不管订阅者是否收到，常用于高频传感器数据，丢了也无所谓，因为马上有下一次。 QoS 1 至少一次：消息一定会被送达，但可能重复，需要订阅者做幂等处理，也就是同样的消息处理两次，结果也要一致。 QoS 2 恰好一次：协议做了多次握手，保证消息既不丢也不重，但开销也最大。
很多人看到这里，会觉得QoS 2最完美，上来就全部用QoS 2。实际这个想法是错误且危险的。QoS 2的协议交互明显更复杂，Broker端的处理开销也更大，消息吞吐量会暴跌。我们做一套温湿度采集系统时，初期统一配置了QoS 2，Broker是EMQX，跑到每秒几千条消息时CPU直接飙到60%以上。后来把上报类消息改成QoS 0，控制类指令用QoS 1，系统一下就轻了。
还有两个MQTT特性必须搞懂。 保留消息（Retained Message）：发布者发一条消息时标记retain标志，Broker会保存这份消息，新订阅者订阅时立即能收到这条最新消息。非常适合设备上报当前状态，比如“这个插座的开关是关的”，新设备或新客户端连上后不用等设备再上报一次就能知道当前状态。 遗嘱消息（LWT，Last Will and Testament）：设备在连接时声明一条遗嘱消息，如果设备非正常断开连接，Broker会代发这条遗嘱消息，通知其他订阅者“这台设备掉线了”。在做设备在线状态监控时，这是必须的。
2.4 Pub/Sub 与 D2C/D2D/D2G 的关系：同一张地图上的坐标与路网
这一节我想强调一个特别容易混淆的点。D2C、D2D、D2G描述的是“谁与谁直接连接”的拓扑结构，而Pub/Sub描述的是“消息如何在多个角色之间分发”的模式。它们是两个完全正交的维度。
举例来说：
- 一台设备通过MQTT直连云端Broker，这是D2C拓扑，通信的消息模式是Pub/Sub。
- 两台设备在本地Zigbee网络里通信，这是D2D拓扑，但消息模式可能是直接的请求/响应，也可能在网关侧被提升为Pub/Sub。
- 设备接入本地网关，网关再把消息换成MQTT发到云端Broker，这是D2G拓扑，消息全程可以走Pub/Sub（网关作为代理消费者和再发布者）。
所以，当你用MQTT时，无论底层是D2C还是D2G，你都在用Pub/Sub模式。反过来，如果你用的是HTTP直连云端，那是D2C拓扑加请求/响应模式。理解这一点，是看懂很多IoT架构图的关键。我自己有个习惯：看图先找Broker，找到Broker就意味着消息中枢在这里，然后再看设备是直连Broker还是经网关再到Broker，架构意图立马清晰。
3. 实操落地：从模型到协议的选型方法与端到端架构参考
理论讲再多，不如上手。这一章我讲真正做项目时要考虑的决策路径，以及一个完整可参考的架构示例。
3.1 场景驱动的选型方法论：先看约束，再选模型和协议
我的选型方法论永远是“先列约束，再画架构，最后选协议”。约束包括：
- 功耗预算：设备是多少年不换电池，还是一直连接市电？
- 通信距离与覆盖：设备在室内还是广域分散？有没有4G信号？
- 时延要求：控制回路能不能容忍去云端转一圈？
- 带宽与消息量：一条消息多大？每秒多少条？
- 成本边界：允许不允许买网关？云接入费怎么算？
- 安全合规：数据要不要本地留存？敏感吗？
按约束走决策路径：
- 如果设备固定、距离近、需要毫秒级联动：选D2D，本地协议考虑Zigbee、BLE Mesh、Thread。
- 如果设备固定或半固定、要上云、数量几百台以上：选D2G，加边缘网关。
- 如果设备移动、广域分布、数量可控：选D2C，网络用蜂窝或NB-IoT。
- 无论选哪种，只要消息异步分发需求明显，协议栈优先考虑MQTT（Pub/Sub）。如果是极低功耗的CoAP也是不错的选择，但CoAP本质是请求/响应模型，往往和Pub/Sub不直接等价。
协议选型时，我最常用的三个是：
- MQTT：几乎适合80%的IoT接入场景，轻量、支持Pub/Sub、QoS、遗嘱等。
- CoAP：面向资源受限的设备，基于UDP，和HTTP类似但更轻，但Pub/Sub能力有限，有观察模式但不是完整的发布订阅。
- AMQP：适合企业级后端服务之间的消息通信，支持复杂的路由和事务，但设备端负担过重，通常在云内使用。
3.2 常见IoT平台的模型映射与协议适配
这里我列举几个主流平台，帮大家在日常业务中快速对应。
| 平台 | 支持的通信模型 | 常用接入协议 | 备注 |
|---|---|---|---|
| AWS IoT Core | D2C为主，配合Greengrass可实现D2G | MQTT、HTTPS、MQTT over WSS | 设备证书管理完善 |
| Azure IoT Hub | D2C/D2G | MQTT、AMQP、HTTPS | 有IoT Edge作为网关 |
| 阿里云 IoT 平台 | D2C/D2G | MQTT、CoAP、HTTPS | 支持边缘网关接入 |
| EMQX/Mosquitto 自建 | D2C/D2G均可（作为Broker） | MQTT | 常部署在云端或网关侧 |
以上平台无论哪种，其本质上都是将一个Broker或消息服务暴露给设备侧。如果你看到架构图里设备画了个箭头指向云端的一个消息节点，那绝大多数都是D2C加Pub/Sub的组合。
用自建Broker做D2G的场景也很多。我们在工业项目里，常常会在边缘网关里嵌入一个Mosquitto，对下接收Modbus数据并转换成MQTT，对上把关键消息转发到云端EMQX集群。这样，本地设备之间可以通过网关完成低时延联动，同时云端数据中心也能拿到全局指标，这就是D2G、D2D、Pub/Sub“三合一”的典型结构。
3.3 一个完整示例：智能家居与工业数据采集的通信架构
我拿一个具体的智能家居子系统来串一下全流程。
场景：一栋100平米的家庭，有智能灯、温湿度传感器、人体红外传感器、空调面板、一部中控网关（可以是一台树莓派或ARM开发板，也可以直接装Windows 10 IoT Enterprise LTSC 2021这类系统做网关），外加云端的MQTT Broker和手机APP。
通信结构：
- 温湿度传感器、人体红外传感器、智能灯这些末端节点，通过Zigbee或BLE Mesh组网，互相之间可以依托D2D完成“如果检测到人体经过，就通知灯打开”的本地联动。这就是D2D。
- 各节点同时把状态通过Zigbee协调器/BLE Mesh网关模块上报到中控网关，中控网关内部运行一个本地MQTT Broker（比如Mosquitto），节点消息统一落在本地主题里。这是D2G中的“设备到网关”环节。
- 中控网关再通过家庭宽带，把本地Broker中需要上云的主题，通过桥接或转发到云端MQTT Broker（D2G中的“网关到云”环节），云端的规则引擎可以处理数据，并向APP推送通知。这就是云端视角的D2C形态。
- 手机APP订阅云端Broker的
device/down/cmd主题，发布指令；云端Broker把指令推给中控网关，网关再将指令转成Zigbee命令下发。全程Pub/Sub。
这里贴一段网关侧的核心订阅逻辑，用Python演示，方便你直接理解：
import paho.mqtt.client as mqtt def on_connect(client, userdata, flags, rc): print(f"connect result: {rc}") # 订阅下行控制主题 client.subscribe("site/home01/gateway/cmd/#") def on_message(client, userdata, msg): print(f"topic: {msg.topic}, payload: {msg.payload.decode()}") # 这里做本地联动逻辑：解析指令，操作Zigbee/BLE执行器 # 同时可以发布设备状态到云端 client = mqtt.Client("home_gateway") client.username_pw_set("gateway_user", "password") client.on_connect = on_connect client.on_message = on_message client.connect("127.0.0.1", 1883, 60) client.loop_forever()这样设计的核心价值是：断网不影响本地联动；云端只保持一个长连接，不维护几十个末梢设备的连接状态；新增设备只需加入局域网Mesh网络，不用改云端配置。
如果把这个模式换成工业场景，比如一个车间有1000个振动传感器，末端通过Modbus RS485挂到边缘采集网关，网关内部把Modbus寄存器地址映射成MQTT主题，再把数据以聚合方式上云，逻辑是一模一样的。可以说，D2G加Pub/Sub就是工业IoT的万能范式。
4. 常见问题与排查技巧实录
4.1 问题速查表
| 症状 | 可能原因 | 排查思路与对策 |
|---|---|---|
| 设备频繁断线重连 | 网络抖动、心跳配置过短、TLS握手开销大 | 检查心跳间隔，常规设为30-60秒；用MQTT持久会话（CleanSession=false）；优化TLS会话复用 |
| 消息订阅不到 | Topic不一致、通配符不匹配、权限不足 | 用本地Broker的调试终端先手动发布一条消息，观察订阅端是否收到；逐级检查Topic层级 |
| QoS 1 收到重复消息 | 消息重投机制导致的正常现象 | 消费端增加唯一消息ID去重，或者设计幂等消费逻辑 |
| 设备离线但显示在线 | 未正确处理遗嘱消息 | 确认遗嘱消息发送成功；检查Broker的Keep Alive机制 |
| 本地联动延迟高 | Zigbee/BLE Mesh网络拓扑不稳定、节点密度不足 | 检查节点RSSI，压缩通信距离；开启Mesh网络的偏离路由优化 |
| 网关死机后数据丢失 | 本地缓存不足、无掉电保护 | 网关选用带写保护的文件系统方案；设计断网续传机制，重启后从缓存文件恢复 |
4.2 我踩过的坑与独家避坑技巧
第一个坑：主题设计反人类。我们早期一个项目，主题直接用了device_mac/cmd，刚开始一百台设备都挺好，但后来要做一个总监控页面，发现它根本没法写一条通用的订阅语句去接收所有设备的状态。最后经过痛苦重构，把所有主题改成site/area/device_type/device_id/status这种形态。教训就是：一上来就把主题层级规划成“分类优先，设备标识放末端”，而不是反过来。
第二个坑：盲目追求QoS 2。前面提过，QoS 2会让Broker压力暴涨。在测试环境感觉不明显，一上线几千个设备就会暴露。控制类和低频状态用QoS 1，传感器上报类用QoS 0，是很多生产环境的默认策略。如果你的业务真的需要“至少一次且不重复”，可以优先考虑在消费端做幂等，而不是直接升级QoS级别。
第三个坑：把网关当成纯转发器。D2G的网关如果只是“收到Zigbee就转发MQTT”，那基本没发挥D2G模型的优势。我在一个冷链监控项目里，把网关的断点续传、本地阈值告警、传感器校准数据处理都放到边缘端，云端只做可视化和统计，整个系统在弱网环境下（经常断网）的可靠性立刻上了一个台阶。记住，网关存在的意义是分担云端压力和提升本地自治，不是多一个网络跳数。
第四个坑：使用 Windows 10 IoT Enterprise LTSC 2021 这类系统做网关时的维护意识。它的优势是长期服务分支、补丁策略稳定，很适合设备端；但正因为它是LTSC，系统组件更新频率低，有些新协议栈不会自动带着补丁过来，启动应用时要格外注意依赖手动管理，并且要定期审查CVE补丁状态，否则网关安全性会滞后。
第五个坑：Pub/Sub模型不等于无限派发。很多人在Broker里把一组传感器数据订阅给十几个服务，结果Broker扇出压力巨大。正确做法是给消息分类：数据类消息只发给持久化存储服务；控制类消息只发给规则引擎；报表类任务直接去做流式计算管道，不要在Broker扇出层堆积。
最后再说一个小技巧。如果你让我给第一次做IoT系统的人一条最值得投入时间的建议，我会说：花半天时间把Topic命名规范定下来，并写成一页文档挂在团队Wiki里。这件事看起来不起眼，但它决定了未来一年你排查消息问题时的痛苦程度。通信模型的选型也同理，没有标准答案，只有“在这个约束下最合理的组合”。把D2C、D2D、D2G当成三种拓扑工具，把Pub/Sub当成一种消息分发思维，你才能在纷繁的IoT架构图里看清本质，也才能在真实项目中少踩几个坑。
