2.3 通信范式与消息模式

2.3 通信范式与消息模式

数据在设备之间是按"主动索取"还是"钉到墙上"的方式流动？本节拆解请求响应、发布订阅、点对点三种通信范式，配合消息队列的中转作用，为第六章的 MQTT、CoAP、HTTP 等协议选型提供范式层面的判据。

学习目标

阅读完本节，你应当能够：

1. 用一句话区分请求响应与发布订阅的"主动权"差异。
2. 说明消息队列 / broker 作为"中转站"解决了解耦与异步两个问题。
3. 为"一台设备要实时被多台设备订阅"这类需求选出合适的范式。

一、两种截然相反的"说话方式"

看过拓扑，再看数据流动的方向。通信范式问的是：发起讲话的那一端是谁？世界上有两种典型答法。

请求响应（Request-Response）像你打电话下单：你发起，对方应答，一问一答严格对齐。客户端开一个请求，服务端必须回一个响应，谁请求谁等待。它直白、可靠、容易想到，HTTP 就是这个范式的代表。它的软肋在"主动方必须是发起请求那端"——假如平台想主动往十万台设备推一条配置，而设备从不主动开口，请求响应就施展不开。

发布订阅（Publish-Subscribe）像广播电台：发行者只管把消息"钉"到公共空间，订阅者各取所需，发行者既不知道也不管谁在听。主动权在"我不知道你是否存在也能把话说出去"。它天然解耦、天然一对多、天然异步。代价是要有"公共空间"——这个空间载体常是一个 broker 或消息队列，而它自己就成为一个要维护的组件。

这两者不是新概念，但物联网的大量设备天然契合发布订阅：大量终端低频上报、多个后端同时消费、谁新接入都不影响现有发布，这简直是发布订阅的经典用武之地。反过来，一次性的"设置某个参数并等我确认"，则更贴近请求响应。

两种范式用一张对照图看得更清楚——请求响应里"提问者"固定是客户端，发布订阅里"发话者"和"听话者"完全解耦：

二、消息队列的"中转哲学"

发布订阅里那个"公共空间"，最常见的承载是消息队列 / broker。它把消息先存起再转发，带来两个被严重低估的好处：解耦与异步。

解耦——生产者和消费者互不依赖。今天有 3 个消费者，明天加到 10 个，生产者代码一行不用改；消费者出故障回补消息，也不会打爆生产者。

异步——生产者发完就干别的，不用被消费者慢速拖住。对速度不均衡的物联网上下游，这是极大的吞吐解放。

用一句话记忆：broker 是"中间人"，消息到了先排队，再按订阅规则分发，发的人不等人收，收的人不追着发。这就是 MQTT、AMQP 这类协议骨子里的设计哲学。

三、点对点与幽灵模式

除了上两种，还有几个需要睁大眼睛的模式：

• 点对点（Point-to-Point）：两个节点一对一直连，最简单也最省，适合轻量的一对一传感链路，但不是多对多场景的主流。
• 多播/广播（Multicast/Broadcast）：一个源同时发给多个接收者，BLE、部分无线技术用来做组播与信标告知，代价是功耗与网络流量。

也就是说，通信范式不是"二选一"，而是"按需组合"的调色板。比如智能路灯：路灯节点白天低频上报（发布订阅，一报多收），晚上收到后端命令去开关灯（这又像请求响应或指令下发）。同一个系统里两种范式共存太常见了。

四、一个选型案例：冷链运输温度监控

拿冷链运输做一个完整练习。一辆冷藏车上有十来个温度传感器，它们要：每分钟上报一次车里温度；三个不同的后台（实时告警、历史分析、司机App）都要看数据；司机手里有个平板想实时读当前值。

这个需求亮出了四个信号：上报方是大量低功耗终端；接收方是多个、分散、可能随时增减的业务系统；通信天然低频异步；还有一方（司机）需要主动查询。答案是分层组合——传感器用轻量发布订阅协议（如 MQTT）把温度发布给 broker；三个后台订阅相应主题各取所需；司机平板的"我要当前值"走请求响应向另一个服务索取。一个故障的告警分析服务，绝不会连带温度上报崩溃——解耦的价值立刻可见。

五、范式选型的快捷判据

把前面沉淀成三条便可速查：

• 要一问一答、要确认结果 → 请求响应（HTTP/CoAP）。
• 要一对多分发、要解耦、要异步 → 发布订阅（MQTT/AMQP）。
• 单条对单条、极简单 → 点对点，少绕一层 broker。

判断时先看业务里"谁会发话、谁会回应、接话的有几个"。接话方很多且不稳定，就偏向发布订阅；双方明确对等、必须得到应答，就偏向请求响应。这是第六章选协议前最后一块拼图。

一个系统里混用范式，是常态不是例外

很多人误以为一个项目只能"选定一种范式"，实际上高明设计都是混搭。拿前面冷链车的例子，把两条消息路线落到同一套后端，范式是维不了二的：

设备经常报  温度 / 位置        → 发布订阅(MQTT)，一报多收
                平台告警引擎     ← 订阅主题 temp/car01
                历史存储         ← 订阅同一主题，各取所需
司机按一下   "我要现在车上温度"  → 请求响应，向读值服务索取，一问一答

同一辆车、同一条温度数据，既走"钉到墙上"的发布订阅，也走"我点你答"的请求响应——
它俩服务的是两个不同的"谁先开口"的业务。
​

这个混用能成立的关键，是把"广播性数据"和"确认性指令"分开走：持续产生、多点消费的，走订阅；临时、要结果、排队等的，走请求。大部分物联网平台终归是这两条腿走路，明白这一点，你就不会端着"只能用一种范式"的架子把架构做僵。

六、翻车常发的两个小角落

除了范式本身，落地时还有两个"看着没事、出事才疼"的点：

• 顺序与积压：broker 默认不保证顺序，也不限积压量。传感器一拥而上、或消费端慢下来时，消息会在队列里堆多、乱序。设计要考虑"谁在乎顺序、谁可真丢旧消息"，给关键订阅做幂等与时间戳，而不是无脑指望队列公平。
• 失联与善后：设备一旦断线、系统怎么知道？这一层常靠"连上时就预埋的一段离线告警"来实现，预埋了却不去处理它的广播，等于给"设备猝死"留了盲区。排查故障时，先看 broker 是否真的把这条预埋消息在设备失联时广播了出去。

两个角落都不挑具体协议（MQTT/AMQP 都适用），本质是同一句提醒：范式给出的是"怎么动"的大方向，动起来之后的细枝末节（顺序、积压、善后）才是工程真正费心的地方。

本节要点回顾

• 两大范式：请求响应"一问一答"，发布订阅"一报多收、相互不知"。
• broker 双妙：解耦与异步，消息队列带来的两个核心价值。
• 调色板思维：一个真实系统常是多种范式的组合，而非单选。
• 三判据：要确认走请求响应，要一对多解耦走发布订阅，要极简单走点对点。
• 为第六章铺路：MQTT/AMQP 属发布订阅，HTTP/CoAP 属请求响应，读到时自然对号。

结构都装好了——分层、拓扑、范式。下一章开始真正走进无线技术：先从十几米的短距离丛林看起。