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

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

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

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

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

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

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

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

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

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

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

Louvre/2/42/sensor/temp

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

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

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

Louvre/2/*/sensor/temp

Rust、Python 和 C API可用于简化应用程序集成。

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

数据可扩展性的成本

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

该协议的线路开销仅在 4 到 6 字节之间，使其与微控制器兼容，同时每秒能够传输多达 400 万条消息。与MQTT和DDS相比，Zenoh的电线开销分别减少了75%和64%。根据ZettaScale的数据，它还表现出MQTT的40倍和XRCE-DDS的10倍的吞吐量性能。新协议的基准传输延迟仅为 15 μs。

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

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

审核编辑：郭婷