如何使用Zenoh协议扩展物联网过去的分布式数据孤岛

为了减少延迟、网络利用率和成本，许多 IoT 部署现在在边缘节点或边缘节点附近存储和分析数据。但是，当涉及到数据时，“分布式”可能是一件坏事，特别是如果这意味着信息被困在网络上的孤岛中。

那么，当您不可避免地需要它时会发生什么呢？

让我们从数据源开始。对于动态数据，围绕发布-订阅原则构建的技术旨在处理这种类型的环境。在 MQTT 或 DDS 等发布-订阅网络中，与给定主题相关的数据由发布者通过网络广播，网络上的节点订阅该主题以进行更新。这促进了分散的数据网络，该网络很好地映射到物联网网络的发展，以及更广泛的网络基础设施，考虑到5G网络部署了1.4-2倍的基站，而不是4G，以支持边缘工作负载的增加。

在最好的情况下，MQTT 和 DDS 等协议在同构环境中通过 TCP 或 UDP 运行，几乎没有数据包丢失和高度的端点扇出。这允许它们以最小的开销高速在节点之间传输消息。但是，作为动态数据的工具，它们没有提供的是内置的，位置感知的数据检索机制，因为它们被设计为推送一条消息并移动到下一条消息。

对于静态数据，命名数据网络 （NDN） 等技术通过允许将数据包标记为目标地址以外的其他内容来提供类似的以数据为中心。数据包（可以命名为任何名称）缓存在位置感知内容存储中，使用户有机会通过查询指定的标签在传输后访问它们。但是，NDN被设计为一种互联网技术，它不适合许多最终应用程序的延迟和资源受限的环境。

这意味着物联网开发人员必须支持多个连接堆栈，以便以性能、资源和延迟敏感的方式分发和检索数据。

统一从边缘到云的运动和静态数据

自物联网问世以来，其目标一直是将数据分发和检索架构统一在单一的企业到边缘范式下，而不是拼凑在一起的异构平台和技术堆栈。ZettaScale技术成立于今年早些时候，旨在弥合这一差距，部分原因是通过一项名为Zenoh的技术。

Zenoh 是一种通过将发布-订阅体系结构与地理位置分散的存储混合来解决传输中、使用中的数据和静态数据的协议。它可以与常见的IP传输或Zigbee，Thread或反映异构边缘到云物联网网络的对等，路由或网格拓扑中的几乎任何其他边缘数据链路一起使用。它目前是由Eclipse基金会托管的开源项目。

以下是它的工作原理。Zenoh使用“key表达式”向订阅者广播数据，该表达式本质上是一个包含资源标识符的字符串。例如，标识巴黎卢浮宫中温度传感器的关键表达式将指定楼层、房间号、资产和资产类型。针对特定资产，例如巴黎卢浮宫博物馆二楼42号房间的温度传感器，将使用以下表达式完成：

与普通数据包不同，此字符串是开发人员可以理解并可能从数据库中查询的内容。这就引出了除了出版商和订阅者之外的第三个Zenoh抽象：可查询。

可查询对象包含给定键表达式的所有值，因此协议可以将与该表达式相关的任何已发布数据保存到数据存储中。相应地，这允许网络查询与这些可查询对象相关的数据，并且Zenoh支持存储管理器和其他插件来集成文件系统，数据库等，因此也可以对历史数据运行查询。

Zenoh 支持推送、拉取和获取命令，以使用其简单而强大的语义。回到我们之前的建筑示例，开发人员需要检索卢浮宫二楼所有房间的温度信息，只需发出一个带有表达式的 get 命令：

Louvre/2/*/sensor/temp

Rust, Python, 和C APIs可用于简化应用集成。

由于 Zenoh 是发布-订阅，因此始终从包含所请求信息的最近的数据存储或计算节点检索结果。该协议还包括一个数据缓存功能，允许休眠节点在需要时从最近的基础设施节点中提取所需的任何数据，然后返回休眠状态。

数据可扩展性的代价

但是，功能几乎总是有代价的，通常当您向边缘添加企业级查询功能时，成本以性能、资源或两者的形式出现。那么，Zenoh如何与酒吧 - 子替代品相提并论呢？

该协议仅包含4至6字节的线路开销，使其与微控制器兼容，同时每秒能够传输多达400万条消息。与 MQTT 和 DDS 相比，泽诺的线架空分别减少了 75% 和 64%。根据泽塔标度的数据，它的吞吐量性能是 MQTT 的 40 倍，是 XRCE-DDS 的 10 倍。使用新协议的基准传输延迟仅为 15 μs。

这些性能指标引起了印地自主挑战赛和TTTech Auto的自动驾驶汽车开发人员的注意，后者正在与ZettaScale合作开发符合ISO 26262标准的Zenoh协议版本。

它确实从头开始设计，可以轻松地垂直或水平扩展，跨越多个子网，从边缘到云。

审核编辑：郭婷