深入探索 Zenoh：对高速公路物联网中台技术架构的启示

摘要：随着智慧高速从"感知采集"迈向"实时协同"，以 MQTT + Kafka + Flink 拼接而成的传统物联网中台，正日益暴露在高并发接入、严苛实时性、弱网隧道、跨路段数据孤岛等压力之下。与此同时，一个名为 Zenoh 的协议在机器人、车联网、自动驾驶领域迅速崛起——它号称用"约 5 字节的开销"统一了动态数据、静态数据与计算，并被 ROS 2 官方选为第一个非 DDS 的 Tier 1 中间件。本文深入解析 Zenoh 的定位、架构、协议与核心特性，客观审视其性能与成熟度，并重点推演：倘若将其引入高速公路物联网中台，技术架构会如何演进。

---

一、引言：高速公路物联网中台的"成长的烦恼"

今天的智慧高速，早已不是"装几个摄像头、立几块情报板"这么简单。一条高速公路沿线，密布着摄像头（全国约 30 万路）、ETC 门架（3 万余套）、毫米波/微波雷达（2 万余套）、气象站（7000 余套）、可变情报板（6 万余套），以及隧道里的 CO/VI 检测器、亮度检测器、诱导标志、紧急电话广播等机电设备¹。以广东交通集团为例，其经营管理里程 8181 公里，接入的机电设备已超过 101 万台²。

海量设备接入背后，是一套已经运行多年的技术架构。国内智慧高速平台普遍遵循"端-边-云"一体化分层——中国公路学会《智慧高速公路系统"端-边-云"一体化架构技术指南》将其归纳为感知层 / 通信层 / 计算层 / 数据层 / 服务与应用层 / 展示层，并明确"路段云与中心云"两级运行控制³。在通信中间件这一层，主流做法几乎千篇一律：MQTT 做设备接入，Kafka 做数据总线，Flink 做实时计算，端到端时延被压在"秒级"⁴。

这套"三件套"在过去几年证明了自己，但也沉淀出四个日益尖锐的痛点：

1. 集中式 broker 的单点与绕路：所有设备必须连到中心（或路段）的 MQTT Broker，同处一条隧道内的两个设备之间交换数据，也要绕道上云再下来——这在弱网、断网场景下是致命的。
2. 实时性天花板：车路协同（V2X）要求安全类业务端到端 ≤ 50ms、非安全类 ≤ 100ms、RSU 至 MEC 单向 < 15–20ms⁵，而"MQTT → Kafka → Flink"的链路每多一跳，就多一份时延与不确定。
3. 边云协同薄弱：边缘侧往往只做"转发"，本地算力闲置，难以支撑隧道等场景的断点续传与边缘自治。
4. 数据孤岛与竖井式架构：各省标准不一、系统各异，收费、通信、机电各自为政，全国高速数据平均利用率不足 40%（交通运输部 2022 统计口径，待核实）⁶。

正是在这样的背景下，一个相对陌生的名字——Zenoh——值得被认真审视。它并非凭空出现：在机器人领域，它已被 ROS 2 官方接纳为第一个非 DDS 的 Tier 1 中间件；在汽车领域，通用汽车（GM）将其纳入 Eclipse uProtocol，国际电信联盟（ITU）早在 2022 年就推荐它用于智能交通系统（ITS）⁷。

那么问题来了：Zenoh 到底是什么？它凭什么？如果把它引入高速公路物联网中台，会带来怎样的架构级影响？ 这正是本文要回答的三个问题。

---

二、Zenoh 定位：一个"从云到微控制器"的协议

2.1 一句话定位

Zenoh（发音 /zeno/）的官方标语是：“The Zero Overhead, Pub/Sub, Store, Query, and Compute Protocol”——一个零开销的发布/订阅、存储、查询与计算协议⁸。

这句话的关键，不是"零开销"的营销式夸张，而是它把四件通常分属不同系统的事情——动态数据（data in motion）、静态数据（data at rest）、计算（computation）——用一个协议统一了起来。这是它区别于所有传统消息中间件的本质分水岭：

• MQTT / Kafka：本质是"消息管道"，只管把数据从 A 搬到 B，对"数据存在哪里、怎么查"不关心。
• DDS：擅长实时数据分发，但基本不碰"静止数据"与"按需查询"。
• Zenoh：在 Pub/Sub 之外，原生提供 Query / Queryable / Storage，让"查询一份数据"和"订阅一个话题"使用同一套命名空间与同一套网络。

用一张表把四者的"基因差异"说清楚：

维度	MQTT	DDS	Kafka	Zenoh
架构模型	集中式 Broker	纯 P2P（组播发现）	集中式 Broker + 分区日志	P2P / Brokered / Routed 可混合
核心原语	Pub/Sub	Pub/Sub + 丰富 QoS	发布-订阅日志流	Pub/Sub + Query + Storage + Eval
静态数据访问	否	否	否（仅流）	是（Query/Queryable）
位置透明	否	部分	否	是
最小资源占用	客户端轻量	较重	重（JVM）	MCU 级（~300B 起 / pico ~15KB）
官方支持传输	TCP / TLS / WS	UDP / TCP	TCP	TCP / UDP / QUIC / TLS / 串口 / SHM / 蓝牙
单机延迟（64B）*	~27 µs	~8 µs	~73 µs	~10 µs

* 数据来自 NTU 2023-03 官方基准，详见第六节。

2.2 出身：从 DDS 的"反思"中诞生

Zenoh 的设计者是 Angelo Corsaro——曾任 OMG DDS 规范组的联合主席、PrismTech（后被 ADLINK 收购）的 CTO，是 DDS 世界里数一数二的权威⁸。恰恰是这位 DDS 专家，在主导过军事、航空航天、智慧城市等超大规模分布式系统后，清醒地看到了 DDS 的边界：DDS 无法按原样"向上扩展"到互联网规模，也无法"向下裁剪"到微控制器——它依赖组播发现、有线级开销、偏向局域网⁹。

于是 Zenoh 从第一天就立下了五项"非妥协"设计目标⁹：

1. 线级开销最小（约 5 字节）；
2. 向上扩展到互联网级部署；
3. 向下裁剪到裸机微控制器（zenoh-pico 可在 2KB RAM 上运行）；
4. 拓扑自由（P2P / 代理 / 路由任意混用）；
5. 位置透明（生产与消费完全解耦）。

2.3 公司与生态位置

Zenoh 孕育于 ADLINK 的巴黎团队，2022 年随 ADLINK 分拆进入新成立的 ZettaScale Technology（获 TTTech Auto 战略投资）¹⁰。2020 年 1 月 15 日通过 Eclipse 基金会的 Creation Review，目前处于 Eclipse Incubating（孵化期） 状态，采用 EPL-2.0 与 Apache-2.0 双许可¹¹。截至本文撰写，最新稳定版本为 1.10.1（2026-09-07），核心由 Rust 编写，并提供 C、C++、Python、Java、Kotlin、Go、TypeScript、C# 及嵌入式 C（zenoh-pico）等多语言绑定¹²。

一个值得注意的信号：Zenoh 官方对自己的定位是 “Cloud to Microcontroller” 的单一协议——即"用一套协议，从数据中心一路覆盖到微控制器、覆盖极其受限的网络"，从而免去在不同技术之间桥接的代价⁸。这个野心，恰好精准命中了高速公路物联网"设备极度异构、网络极度不均衡"的现实。

2.4 为什么是现在：三重趋势的合流

Zenoh 并非凭空冒出来的"新玩具"，它的走红是三重技术趋势合流的结果，而这三重趋势恰好都在高速公路场景里汇聚：

1. 边缘计算下沉：算力正从中心云一路下沉到路段、隧道、MEC。当算力被推到"最后一公里"，就需要一种能就地、低时延、弱网可用地协同这些算力的协议，而非把所有数据都拉回中心 broker。
2. 车路协同走向规模化：C-V2X 已成为主流技术路线，中国 RSU 部署已达约 7.1 万套（占全球 57.7%，行业报告口径）¹³，五部门 2024 年起推进"车路云一体化"应用试点¹⁴。车、路、云之间的实时互通，需要的是低时延、多传输、可跨域的通信底座。
3. 软件定义车辆（SDV）与"车云一体"：GM 已将 Zenoh 纳入 Eclipse uProtocol，Eclipse SDV 的 Fleet Management 蓝图也用 Zenoh + KUKSA.val 打通车端与云端¹⁵。车端已经在用 Zenoh，路侧与云端若采用同一协议，就能实现"车—路—云"的同构互通，而不必在车/路/云三套协议之间反复转换。

此外，Zenoh 官方还点破了一个直指传统架构软肋的"MQTT 悖论"：两个物理上同处一地的设备，在使用 MQTT 时却被迫把消息绕道远端的云端 broker 才能互通⁹。在高速公路——尤其是隧道这种"两端近在咫尺、链路却要绕山而上"的场景——这个悖论被放到了最大。

---

三、架构解析：三类节点，三种拓扑，一张网

3.1 三类节点角色

Zenoh 把网络中的节点划分为三种角色（WhatAmI 字段）¹⁶：

• Router（路由器）：维护完整路由表，主动在会话之间转发数据，是组网的"骨干"；
• Client（客户端）：只连接一个 Router 或 Peer，完全委托路由，最轻量；
• Peer（对等体）：可以互相连接、做有限的转发，兼具端与转发能力。

关键在于，这三者是同一套协议的不同角色，而非三种不同的软件。一个设备既可以是"只发不收"的 Client，也可以是承担转发职责的 Peer。

3.2 三种拓扑，可自由混合

这是 Zenoh 与 MQTT/Kafka 最直观的差异。传统消息中间件往往是"单拓扑"：MQTT/Kafka 必须经过中心 broker，DDS 则是纯 P2P。而 Zenoh 默认即支持三种拓扑¹⁷：

• Peer-to-Peer（默认）：两个节点直接通信，没有中心 broker，也就没有单点故障。
• Brokered：类似 MQTT，Client 都挂到一个 Router（zenohd）下，由 Router 集中转发。
• Routed：多个 Router 之间网状互联，适合跨路段、跨区域的大规模组网。

更重要的是，这三种拓扑可以在同一张网里共存：隧道里的两个 Peer 直连，路段侧的 Client 挂到路段 Router，路段 Router 再与区域云、中心云的 Router 网状互联。拓扑不是"二选一"，而是"按需拼接"。

3.3 Regions 与 Gateway：规模化分层

当系统变大时，Zenoh 提供 Regions + Gateway 机制做横向切分¹⁷：把整张网划分为若干 region，每个 region 内部可采用不同的通信模型；Gateway 作为某个 south region 在 north region 中的"代表"，对外隐藏子区域的内部细节。这套机制天然对应高速公路的"路段—区域—中心"三级结构。

3.4 会话（Session）

所有数据交换都发生在两个节点之间建立的 Session 内。会话的生命周期为 INIT SYN/ACK → OPEN SYN/ACK → 数据传输/KeepAlive → CLOSE，其中 KeepAlive 以 lease/4 的周期发送心跳以维持会话¹⁸。这为"弱网下快速检测对端是否存活"提供了机制基础。

---

四、协议与 Wire 设计：5 字节背后的极简主义

4.1 四层协议栈

现行 1.0.0 规范将 Zenoh 协议重构为四层¹⁹（协议版本号为 9，0x09）：

自顶向下：数据面定义 PUT/DELETE/QUERY/REPLY 等高层语义；网络面负责路由与兴趣声明；传输面负责建链、分帧、重组与保活；侦察面负责节点发现（默认用组播地址 224.0.0.224、UDP 7446，也支持 gossip 方式）。

4.2 5 字节的开销，从何而来？

官方给出 Zenoh 的最小线级开销约为 5 字节（官网不同页面存在 4 / 4–6 字节的不同口径，本文统一采用官方 overhead 博客的"约 5 字节"口径）²⁰。这 5 字节由三个手段共同实现：

1. VLE（可变长整数）编码：类 LEB128 风格，小数值用更少字节表示；
2. declare_resource()：把长 key 表达式映射为整数 resource ID，后续消息只携带 ID 而非完整 key；
3. 自动 batching：多条消息批量打包后，每条消息的摊薄开销可进一步降到约 3 字节。

与之对照，DDS 的线级开销通常为 36–56 字节量级²¹。在"一帧报文塞满数据"的高吞吐场景下，这种开销差异会被成倍放大。

4.3 Key 表达式（keyexpr）与位置透明

Zenoh 用 / 分隔的层级 key 表达式命名一切资源，并支持通配符：

• *：匹配单个层级（chunk）；
• **：匹配任意多个层级；
• $*：匹配子 chunk。

例如，一条高速公路上，隧道 A 的 CO 检测器数据可以命名为 高速/路段1/隧道A/co，而路段云只需订阅 高速/路段1/**/co，即可收到该路段所有隧道的 CO 数据。更进一步的 Selector 形式为 keyexpr?arg1=val1，可在查询时携带参数。

位置透明的核心在于：订阅方不需要知道数据来自哪个具体节点，甚至不需要知道它是"正在产生的动态数据"还是"存储中的静态数据"。这为后文"中台按需查询边端"打下了地基。

4.4 传输多样性

Zenoh 支持的底层传输极为丰富：TCP、UDP（单播+组播）、QUIC、TLS、串口（Serial）、共享内存（SHM），TypeScript 绑定经 remote-api 插件使用 WebSocket，嵌入式 zenoh-pico 还支持蓝牙、Thread、6LoWPAN、USB CDC 等²²。这意味着从"中心云的光纤骨干"到"隧道里的串口机电设备"，可以用同一套协议贯通，而不必在每一跳做协议转换。

---

五、核心特性：不止于消息

5.1 Pub/Sub 之外的"查询与存储"

这是 Zenoh 最值得高速公路场景关注的能力。除了传统的 Pub/Sub（PUT 写入、DEL 删除），它还原生提供：

• Query / Queryable：get 查询会沿 key 表达式路由到所有匹配的 Queryable，由后者返回结果，并支持 consolidation（聚合）——none（返回全部）/ monotonic / latest-per-key（每个 key 只返回最新值）。
• Storage：既是一个 Queryable、又是一个 Subscriber——它订阅并持久化数据，查询时返回最新值。存储后端可动态加载，官方提供 S3、InfluxDB、RocksDB、文件系统、SQL（SQLite3/MySQL） 等 backend²³。
• Eval（按需计算）：Queryable 的"计算"语义——一次 get 可以触发远端一次函数执行，官方称之为可实现 RPC、map-reduce 等模式。
• Liveliness（存活令牌）：通过 Liveliness Token 断言某个命名实体在 key 表达式上的存活状态，配合会话级心跳（lease/KeepAlive），可快速感知设备/服务的上下线——对"机电设备是否掉线"这类场景尤其有用。

我们用一个高速公路的具体场景，来直观感受"推式"与"拉式"的差别。假设中台值班人员要立刻知道"某隧道当前的 CO 浓度是否超标"：

• 传统推式链路：设备以固定频率持续上报 → MQTT Broker → Kafka → 落库 → 中台应用查库。为了"可能被查询一次"的数据，系统要 7×24 小时地搬运、存储、索引它。
• Zenoh 拉式链路：中台直接发起一次 get 高速/路段1/隧道A/co，查询沿 key 表达式路由到隧道侧的 Queryable（或 Storage），边端即时应答；若数据尚未采集，还可以通过 Eval 触发边端"现场算一次再返回"。

结果是：数据访问从"推式沉淀"变成了"拉式按需"——无效上行与存储压力大幅下降，算力留在最靠近数据的地方。这正是"数据利用率不足 40%"的结构性解药之一。

5.2 时序与时间戳：HLC

Zenoh 的每条数据都带 HLC（Hybrid Logical Clock）时间戳——64 位、理论分辨率约 3.5ns，可在分布式场景下做全局排序²⁴。配合 Storage 与 InfluxDB 等时序后端，可以自然构建时序能力。需要注意的是：官方协议并未把 “history/time-series” 定义为一等原语（不同于 DDS 的 History QoS），时序能力是"时间戳 + 存储 + 后端"的组合结果，而非协议内建——这是引用时应避免过度断言的一点。

5.3 零拷贝与共享内存

Zenoh 的固定布局字段与自定界 VLE 编码支持 zero-copy parsing；Rust 实现还提供了 SHM（共享内存）传输，1.5.0 起 SHM 吞吐进一步提升约 25%（约 2.4M → 3M msg/s）²⁵。对于视频、雷达点云等大负载数据，这直接关系到吞吐上限。

5.4 插件生态：与存量系统"和平共处"

Zenoh 通过插件体系实现了对既有生态的桥接²⁶：

• zenoh-plugin-mqtt：把存量 MQTT 设备透明桥入 Zenoh，支持跨 NAT、edge-to-cloud；
• zenoh-plugin-dds / zenoh-bridge-ros2dds：DDS 应用与 ROS 2 主题透明映射；
• zenoh-plugin-rest / WebServer：把 URL 映射到 Zenoh path，提供 HTTP API；
• rmw_zenoh / rmw_zenoh_cpp：ROS 2 的原生 RMW（非桥接），自 ROS 2 Kilted Kaiju 起成为 首个非 DDS 的 Tier 1 中间件，并回移植到 Jazzy 与 Humble²⁷。

这个插件体系的意义在于：引入 Zenoh 不等于推翻存量。存量 MQTT 设备可以先通过桥接插件共存，再逐步迁移。

---

六、性能与成熟度：接近一骑绝尘，但并非银弹

6.1 官方 NTU 基准：吞吐与延迟

Zenoh 官方最常引用的，是台湾大学团队 2023 年 3 月发布的评测（完整论文见 arXiv:2303.09419），环境为 Ubuntu 20.04、AMD Ryzen 7 5800X、100GbE，软件版本为 Zenoh 0.7.0-rc / Mosquitto 2.0.15 / Kafka 3.2.1 / Cyclone DDS²⁸。关键结果：

指标	Zenoh P2P	Cyclone DDS	MQTT	Kafka
单机峰值吞吐	~67 Gbps	~26 Gbps	~9 Gbps	~4–5 Gbps
多机吞吐（100GbE）	~50 Gbps	~14 Gbps	~9 Gbps	~5 Gbps
单机延迟（64B，µs）	~10	~8	~27	~73
多机延迟（64B，µs）	~16	~37	~45	~81

两个值得注意的细节：

• 单机延迟 DDS 反而更优（8µs），原因是 Cyclone DDS 当时使用 UDP 组播；而彼时 Rust 版 Zenoh 尚未实现 UDP 组播，反倒是轻量的 zenoh-pico 以 5µs 拿下全场最快。这提示我们："Zenoh 全面碾压"并不成立，真实差距高度依赖传输与场景。
• 官方（ZettaScale ROSCon 2024 演讲）另有一套更激进的营销口径——“~70 Gbps@8KB、吞吐为 DDS 的 3.3×、Kafka 的 23×、MQTT 的 35×、延迟 ~10µs”²⁹。由于环境未详述，引用时应与 NTU 实测口径区分开。

6.2 客观的"另一面"

深度文不应回避局限。综合官方规范、GitHub Issue 与第三方评测，Zenoh 目前存在以下需要正视的短板：

1. 仍处 Eclipse 孵化期：尚未"毕业"（graduate），是生态成熟度的一个信号¹¹。
2. 安全/授权尚未"协议化"：访问控制（ACL）是逐节点本地、带外（out-of-band）配置，线协议本身不定义可移植的 ACL 语法或策略分发机制；PKI/密钥管理、侧信道、DoS 均列为规范范围外³⁰。此外，QUIC 上的 mTLS 曾未实现（GitHub Issue #771）。
3. 高可用需外部组件：共享订阅的 Active/Standby 路由器切换依赖外部 Raft 控制器，HA 并非内核能力。
4. 资源占用：第三方实测（机器人 ROS2 场景）中，Zenoh RMW 相比参考实现多用约 2–3× CPU、约 4× 内存，对资源受限设备可能构成压力。
5. 大消息 + 退化网络吃力：第三方 Digital Twin 同步评测指出，在重消息与高频故障注入下，Zenoh 与 DDS 的投递率都会下降，此时 TCP broker 型（MQTT/AMQP）反而更稳³¹。

结论是清晰的：Zenoh 在"低时延、高吞吐、异构网络"上优势明显，但在"安全生态、高可用开箱即用、超大消息弱网、学习曲线"上仍是后来者。它对高速公路中台是"值得试点的演进方向"，而非"即插即用的银弹"。

---

七、启示：Zenoh 将如何重塑高速公路物联网中台架构

这是本文的核心。基于前述现状痛点与 Zenoh 的能力，如果把 Zenoh 引入高速公路物联网中台，技术架构将沿着以下五个方向演进——主线是"架构升级路径"，即从集中式拼接走向统一协议下的边云协同。

先看今天的"三件套"长什么样：

问题一目了然：所有设备都指向同一个集中式 Broker，所有数据都汇入同一条总线——单点、绕路、时延、无效搬运都源于这个"汇聚"的拓扑本身。而 Zenoh 要改的，恰恰是这个拓扑。

下表把前文的痛点与 Zenoh 的能力一一对应，作为本节推演的地图：

高速中台痛点	Zenoh 对应能力
异构协议、设备接入难	多传输 + MQTT/DDS/REST 桥接插件
高并发海量接入、消息堆积	高吞吐低开销、P2P 去中心化分散负载
边缘计算薄弱	edge-to-cloud 无缝、边端自治、Eval 触发边端计算
实时性（V2X ≤ 50ms）	微秒级延迟、零拷贝 / 共享内存
隧道 / 弱网 / 长隧道	P2P 断点自治、QUIC / 多传输、弱网恢复后同步
跨路段 / 跨区域数据孤岛	Router 网状互联、位置透明、声明式路由
竖井式架构	单一协议统一 data in motion / at rest / computation
数据利用率低（< 40%）	Storage / Queryable 按需查询、HLC 时序

7.1 影响一：接入层——从"集中式 broker"走向"边端直连 + 可选路由"

传统架构里，所有设备必须连到 MQTT Broker，形成事实上的集中式接入与单点。Zenoh 默认的 P2P 拓扑意味着：隧道内的两个机电设备可以直连交换数据，无需绕道云端；只有当需要跨路段、跨区域时，才引入 Router 做路由。

对隧道、长隧道等弱网场景，这带来质变：设备可以在本地自治运行、断点续传，网络恢复后再与上游同步——这恰好回应了行业对"边缘自治 + 集中管控"的诉求。接入层从"必须汇聚"变成了"就地协同、按需汇聚"。

7.2 影响二：消息/数据层——用"一个协议"替代"三件套拼接"

"MQTT（接入）→ Kafka（总线）→ Flink（计算）"是三套不同系统、三套运维、三套数据模型的拼接，每一跳都引入时延与一致性成本。Zenoh 以统一协议同时覆盖 data in motion（Pub/Sub）、data at rest（Storage）、computation（Queryable/Eval），让"采集、传输、落库、查询、计算"共用一套命名空间与路由。

这并非主张"立刻下线 Kafka 和 Flink"，而是指出一条简化中台数据链路的路径：许多原本需要"先落 Kafka、再让 Flink 消费"的轻量实时场景，可以由 Zenoh 的订阅与查询直接完成，Kafka/Flink 退回到真正需要"重流批处理"的场景。

7.3 影响三：边云协同——位置透明 + 零拷贝 + 低时延

Zenoh 的位置透明意味着中台应用无需关心"这条数据来自哪个路段、是实时产生还是已落库"。配合零拷贝/共享内存与微秒级延迟，路段侧可以真正承担实时决策——例如隧道内的本地联动控制——而把聚合后的结果上云。

结合 Zenoh 的 Regions/Gateway 分层，高速公路"路段云—区域云—中心云"三级结构可以被原生地映射为 Zenoh 的三级路由：路段侧 Peer/Router 负责本地实时，区域云 Router 负责路段间，中心云 Router 负责全局。这比"每级都堆一套 broker + 总线"要简洁得多。

7.4 影响四：车路协同 V2X——RSU/OBU 的统一协议

这是 Zenoh 与高速公路场景最直接的交集。官方 Use Cases 页明确将 V2X communication、软件定义车辆（SDV）、高速自动驾驶列为应用方向，并称 CARMA、Indy Autonomous Challenge 等项目已采用 Zenoh 做 V2X 通信，“在越来越多场景下是车上+车外通信的唯一协议”⁸³²。ITU 亦推荐其用于 ITS。

当前车路协同的痛点之一，正是 RSU 与中心平台之间通信协议不统一、链路冗长。Zenoh 的多传输（含 QUIC、UDP）与低延迟，天然契合"RSU 至 MEC 单向 < 15–20ms"的严苛要求，并有望让 RSU、OBU、路侧 MEC、中心云共用一套协议——再叠加前面提到的"车端已在用 Zenoh"，"车—路—云"同构的技术底座便有了现实支点。

7.5 影响五：数据中台——从"推式沉淀"到"按需查询边端"

传统中台依赖"设备持续上报 → Kafka → 数仓 → 应用读库"的推式链路，这也是"数据利用率不足 40%"的结构性原因之一：大量数据被无差别地推上来、存起来，却很少被真正消费。Zenoh 的 Query / Queryable / Storage 支持拉式按需：中台只在需要时查询特定 key（如某隧道当前 CO 浓度），由边端即时应答，从而显著降低无效上行与存储压力，并把算力留在最靠近数据的地方。

7.6 演进路线图：渐进式引入，而非大拆大建

综合以上，一个现实可行的引入路径是"三步走"，核心原则是用桥接插件保障与存量的共存，避免推倒重来：

• 阶段一（桥接共存）：在隧道、车路协同等对实时性/弱网敏感的局部场景试点 Zenoh，通过 zenoh-plugin-mqtt 与存量 MQTT 系统互通，风险可控。
• 阶段二（边侧替换）：把路段侧的边端接入逐步替换为 Zenoh P2P，实现边缘自治与断点续传；中心侧暂不动作。
• 阶段三（中心重构）：以 Zenoh Router 组建"路段—区域—中心"三级路由网，用 Query/Storage 重构数据中台的数据访问范式，Kafka/Flink 保留给重流批处理。

---

八、落地建议与风险：把"启示"变成"可执行"

技术判断之外，落地还需要直面四个现实约束：

1. 孵化期与安全成熟度：Zenoh 仍处 Eclipse 孵化期，ACL 为带外配置、QUIC-mTLS 等安全能力尚在补齐。生产引入应叠加现有的安全网关/国密链路，而非依赖 Zenoh 自身的安全特性。
2. 高可用需自建：HA 依赖外部 Raft 控制器，中台侧需把 Zenoh 路由器的可用性纳入既有的高可用体系。
3. 生态与人才：相对 MQTT（EMQX/HiveMQ/AWS IoT 等庞大工具链）与 DDS，Zenoh 的中文资料、运维工具、人才储备都还薄弱，需配套培训与观测体系（指标、日志、链路追踪）。
4. 性能口径要"擦亮眼睛"：引用官方性能数字时务必注明基准口径（版本、负载、网络、测试方），避免把营销数字当工程结论。

建议的落地节奏：以"隧道机电联动 / 车路协同 V2X"这类痛点最痛、收益最直接、且与 Zenoh 能力最匹配的场景为试点切口，用阶段一"桥接共存"验证其在真实弱网与异构设备环境下的表现，再决定是否向边侧与中心推进。

---

结语

Zenoh 的价值，不在于它多了一个"比 MQTT 快"的协议，而在于它提供了一种统一的抽象——把动态数据、静态数据与计算收拢到同一套命名、同一套路由、同一套网络里，并以"约 5 字节"的开销贯穿"云到微控制器"。

对高速公路物联网中台而言，这恰好对准了它最深的结构性矛盾：设备极度异构、网络极度不均衡，却被一套集中式拼接架构所约束。Zenoh 让"边端直连、边缘自治、按需查询、跨路段互联"从理想变为可行的工程选项。当然，它仍在孵化期、安全与生态尚在补课，正确的姿态是以桥接共存起步、在隧道与 V2X 场景试点、沿着"接入层—边云协同—中心重构"的路径渐进演进，而非把它当作一夜之间替换一切的银弹。

这，就是 Zenoh 带给高速公路物联网中台的"启示"。

---

参考资料

---

1. 李斌《对高速公路信息化发展的观察与思考》（设备规模数据）— https://mp.weixin.qq.com/s?__biz=Mzg5MDkxMjE3Nw==&idx=1&mid=2247557085&sn=dc4213534c11ba69d41b5503345f7c59 ↩︎

2. 广东交通集团接入 101 万台机电设备 — https://www.sohu.com/a/907612407_649849 ↩︎

3. 中国公路学会《智慧高速公路系统"端-边-云"一体化架构技术指南》(征求意见稿) — http://www.chts.cn/cms_files/filemanager/1389253025/attach/202412/f6b70c2d281241a28cb9ebd5b085ce54.pdf ↩︎

4. CSDN《数字底座数据流动机制》(MQTT/CoAP/Modbus+Kafka+Flink 技术栈与时延) — https://blog.csdn.net/zero_forever_lzm/article/details/158009815 ↩︎

5. 车路协同时延要求（安全类 ≤50ms、RSU 至 MEC <15–20ms）— https://www.ttbz.org.cn/upload/file/20241009/6386409918950850543259597.pdf ↩︎

6. 数据利用率不足 40%（交通运输部 2022 统计口径，待核实）— http://jtdh.rmjtxw.com/anli/3/557.html ↩︎

7. GM 采用 uProtocol、ITU 推荐 ITS — Zenoh Book 引言：https://corsaro.me/zenoh/book/introduction/ ↩︎

8. Zenoh 官方定位/起源/what-is-zenoh — https://zenoh.io/docs/overview/what-is-zenoh/ ↩︎ ↩︎ ↩︎ ↩︎

9. Zenoh 五项非妥协设计目标与 MQTT 悖论 — https://corsaro.me/zenoh/book/introduction/ ↩︎ ↩︎ ↩︎

10. ADLINK 分拆 ZettaScale、TTTech Auto 投资 — https://www.adlinktech.com/en/news/tttech-investment-into-zettascale-spinout ↩︎

11. Eclipse 项目状态（Incubating、许可证、进入时间）— https://projects.eclipse.org/projects/iot.zenoh ↩︎ ↩︎

12. 最新版本 v1.10.1（2026-09-07）— https://github.com/eclipse-zenoh/zenoh/releases ↩︎

13. C-V2X 规模（中国 RSU 约 7.1 万套、占全球 57.7%）— https://www.7its.com/?m=home&c=View&a=index&aid=27992 ↩︎

14. 车路云一体化试点（五部门 2024 年通知）— https://www.gov.cn/zhengce/zhengceku/202401/content_6926711.htm ↩︎

15. Eclipse SDV Fleet Management 蓝图（Zenoh + KUKSA.val）— https://zettascale.tech/news/advancing-automotive-technologies-for-the-future-with-eclipse-zenoh/ ↩︎

16. Router/Peer/Client 节点角色 — https://spec.zenoh.io/spec/1.0.0/architecture/roles.html ↩︎

17. 三种拓扑 + Regions/Gateway — https://zenoh.io/docs/getting-started/deployment/ ↩︎ ↩︎

18. 会话与生命周期 — https://spec.zenoh.io/spec/1.0.0/session/index.html ↩︎

19. 四层协议栈与协议版本 — https://spec.zenoh.io/spec/1.0.0/introduction.html ↩︎

20. 5 字节开销的逐字节拆解 — https://zenoh.io/blog/2021-07-05-zenoh-overhead/ ↩︎

21. DDS 线级开销 36–56 字节 — https://www.therobotreport.com/zettascale-designs-zenoh-to-transcend-dds-for-automotive-ros-communications/ ↩︎

22. 传输与 key 表达式 — https://spec.zenoh.io/spec/1.0.0/concepts/key-expressions.html ↩︎

23. Storage/Queryable 与存储 backend — https://zenoh.io/docs/manual/abstractions/ ↩︎

24. HLC 时间戳 — https://spec.zenoh.io/spec/1.0.0/appendix/glossary.html ↩︎

25. SHM 传输与 1.5.0 吞吐提升 — https://zenoh.io/blog/2025-07-28-zenoh-hong/ ↩︎

26. 插件（MQTT/DDS/REST/Storage）— https://zenoh.io/docs/manual/plugins/ ↩︎

27. ROS 2 Kilted Kaiju 发布、rmw_zenoh Tier 1 — https://www.openrobotics.org/blog/2025/5/23/ros-2-kilted-kaiju-released ↩︎

28. NTU 官方基准（Zenoh/MQTT/Kafka/DDS 对比）— https://zenoh.io/blog/2023-03-21-zenoh-vs-mqtt-kafka-dds/ ；完整论文 https://arxiv.org/abs/2303.09419 ↩︎

29. ZettaScale ROSCon 2024 营销口径 — https://github.com/ZettaScaleLabs/roscon2024_workshop/blob/main/Introduction_slides.pdf ↩︎

30. Zenoh 安全规范（ACL 带外、威胁模型）— https://spec.zenoh.io/spec/1.0.0/security/ ↩︎

31. 第三方 Digital Twin 同步评测（“没有单一协议满足所有需求”）— https://sol.sbc.org.br/index.php/wgrs/article/view/42569 ↩︎

32. Zenoh 官方 Use Cases（V2X/自动驾驶）— https://zenoh.io/usecases/ ↩︎