The post Zenoh及2024展望 appeared first on ZettaScale.

3. 我们通过将 ROS 2 和 MQTT

ROS 2 集成

字体 用于路由 DDS 流量的 Zenoh 路由器

ROS 字体 用于路由 DDS 流量的 Zenoh 路由器是一套允许构建机器人应用程序的软件库和工具。ROS 2 主要依赖 O.M.G. DDS 作为通信中间件。

虽然用于 DDS 的 Zenoh 桥接器已经存在，并帮助许多机器人用例克服了一些无线连接、带宽和集成问题，但使用专用于 ROS2 的桥接器可以更好地集成 ROS 图形、ROS 工具和 ROS2。 (ROS2、RVIZ2……）。它还带来了 更容易与 Zenoh 本地应用程序集成，桥接器之间的发现信息交换更紧凑。

您想知道如何在您的生态系统中应用我们的 ROS 2 Zenoh 插件吗？Julien Enoch（我们的高级解决方案架构师）将在我们的网络研讨会上为您讲解。

MQTT 集成

字体 MQTT 代理商上的 Zenoh 集成

我们在 2023 年添加了 Zenoh 的 MQTT 插件！

这种战略整合使 Zenoh 能够充当 MQTT 代理，接受来自 MQTT 客户端（V3 和 V5）的连接，并将 MQTT 的 pub/sub 转换为 Zenoh 的 pub/sub。这使得任何 MQTT 系统都能与 Zenoh 紧密集成，同时也为 MQTT 系统带来了 Zenoh 路由基础设施的优势.

例如，它可以使用 NAT 穿越将消息从设备通过边缘路由到云，使用 NAT 穿越在互联网上桥接两个独立的 MQTT 实例，通过 Zenoh RES API 向 MQTT 发布子消息，以及启用 MQTT/ROS 2（机器人）通信。

此外，它还能在 RocksDB、InfluxDB 或文件系统中保存所有或选定的 MQTT 发布，或使用 InfluxDB 存储执行 MQTT 数据的记录和重放。

The post 2023年Zehoh推出的顶级功能 appeared first on ZettaScale.

网络研讨会：Zetta平台入门

地点：在哔哩哔哩上观看

人物：Angelo Corsaro和Gabriele Baldoni

网络研讨会：了解Zenoh

地点：在哔哩哔哩上观看

人物：Angelo Corsaro

网络研讨会：ROS2和Zenoh——从零到部署

地点：在哔哩哔哩上观看

人物：Julien Enoch

The post 掌握Zetta平台 appeared first on ZettaScale.

在8号和9号展位，您将能够与以下人士（从左上到右）交谈:

• Angelo Corsaro，我们的首席执行官兼首席技术官（LinkedIn）
• Julien Enoch，高级解决方案架构师（LinkedIn）
• Steven Palma，软件工程师（LinkedIn）
• Luca Cominardi，技术主管 (Linkedin)

TIERS 实验室： 分布式 ROS 2 系统边缘到边缘和边缘到云通信中 DDS、MQTT 和 Zenoh 的比较.

FLECS： 我们如何利用龙的力量获得额外性能

The post ZettaScale x ROSCon 2023 appeared first on ZettaScale.

这源自我们Discord社区中所要求的功能，很快就进入了产品路线图。

可从https://download.eclipse.org/zenoh/zenoh-backend-s3/latest/ 下载软件包安装 S3 后端。 源代码可在我们的 eclipse-zenoh 代码库中找到：https://github.com/eclipse-zenoh/zenoh-backend-s3。 您将在 README 中找到如何为 Amazon S3 和 MinIO 设置该后台的详细说明。

目录

在这篇博文中，我们将介绍 S3 后端，解释后端背后的概念、S3 后端如何融入后端、如何配置后端、后端有哪些限制以及使用后端时的注意事项。

目录

1. 芝诺后端
2. 特点
3. 配置
4. 考虑因素

芝诺后端

你可能会问自己 “什么是后台？ 在 Zenoh 中，后台是一种存储技术，可以存储通过 Zenoh 发布的密钥/值，并在查询时返回。 不同的存储技术可根据不同的使用情况存储密钥/值。

目前，我们有三个后台系统：

• InfluxDB：面向开发人员的时间序列数据平台，用于构建物联网、分析和云应用程序
  • 存储库：https://github.com/eclipse-zenoh/zenoh-backend-influxdb
• RocksDB：适用于快速存储环境的高性能持久键值存储库
  • 存储库：https://github.com/eclipse-zenoh/zenoh-backend-rocksdb
• 文件系统：该后端依赖主机的文件系统来实现存储。
  • 存储库：https://github.com/eclipse-zenoh/zenoh-backend-filesystem

AmazonS3 也能将数据存储在云存储服务中。

它将提高我们的存储能力，尤其是在面向对象存储方面。 到目前为止，使用对象存储的唯一方法是使用 FileSystem 后端，它被设计为受限于主机文件系统的简单存储选项。 在安全性、数据可用性和性能方面，它也缺乏云存储所提供的许多机制，而且可扩展性也不强。

我们的用户需要与对象存储技术进行交互，这种技术可以很容易地在云上进行设置，提供性能、安全性和数据可用性，并且可以扩展。 亚马逊 S3 满足了所有这些条件，并立即被提出，因为到目前为止，它已经是一项成熟的技术，在系统行业得到了广泛采用。

特点

S3 存储

Amazon S3（代表简单存储服务）通过Amazon Web Services提供对象存储功能，提供“业界领先的可扩展性、数据可用性、安全性和性能”。

通过该后台，我们可以

• 将值作为文件/对象存储在 S3 存储桶中
• 创建一个水桶
• 重用现有水桶
• 在存储区中放置值，即在存储区中创建或更新一个文件，并在键表达式提供的路径下放置指定的值
• 查询值/文件：
  • 具体关键表达
  • 包含通配符（’\*‘ 和 ‘\*\*‘ ）的关键表达式（将返回路径与关键表达式相匹配的文件值）
• 删除文件
• 删除存储

与 MinIO 兼容

MinIO是一种开源多云对象存储，可提供高性能，是与 S3 兼容的对象存储。 我们开发后台的目的是让您可以根据使用情况选择 AmazonS3 或 MinIO。 您可能需要考虑很多因素才能决定选择其中一种还是另一种。 其中一个要考虑的因素是与存储的交互量，如使用 Zenoh，您可能会收到成千上万个从存储中放入或检索数据的请求，如果使用 Amazon S3，这可能会影响存储的定价。

支持 TLS

AmazonS3 本身提供 HTTPS 支持，但如果使用 MinIO 建立自己的 S3 实例，则可能需要使用 TLS 确保连接安全。 为此，您需要指定允许您验证服务器的证书。 可在配置文件中指定证书颁发机构颁发的证书。

配置

下面的示例配置文件也可以在我们的资源库中找到。 其中有 “卷 “和 “存储 “的参数。

{
  "plugins": {
    "storage_manager": {
      "volumes": {
        "s3": {
          // This field is mandatory if you are going to communicate with an AWS S3 server and
          // optional in case you are working with a MinIO S3 server.
          "region": "eu-west-1",

          // Endpoint where the S3 server is located.
          // This parameter allows you to specify a custom endpoint when working with a MinIO S3
          // server.
          // This field is mandatory if you are working with a MinIO server and optional in case
          // you are working with an AWS S3 server as long as you specified the region, in which
          // case the endpoint will be resolved automatically.
          "url": "https://s3.eu-west-1.amazonaws.com",

          // Optional TLS specific parameters to enable HTTPS with MinIO. Configuration shared by
          // all the associated storages.
          "tls": {
            // Certificate authority to authenticate the server.
            "root_ca_certificate": "./certificates/minio/ca.pem"
          }
        }
      },
      "storages": {
        // Configuration of a "demo" storage using the S3 volume. Each storage is associated to a
        // single S3 bucket.
        "s3_storage": {
          // The key expression this storage will subscribes to
          "key_expr": "s3/example/*",

          // this prefix will be stripped from the received key when converting to database key.
          // i.e.: "demo/example/a/b" will be stored as "a/b"
          "strip_prefix": "s3/example",

          "volume": {
            // Id of the volume this storage is associated to
            "id": "s3",

            // Bucket to which this storage is associated to
            "bucket": "zenoh-bucket",

            // The storage attempts to create the bucket, but if the bucket already exists and is
            // owned by you, then with 'reuse_bucket' you can associate that preexisting bucket to
            // the storage, otherwise it will fail.
            "reuse_bucket": true,

            // If the storage is read only, it will only handle GET requests
            "read_only": false,

            // strategy on storage closure, either `destroy_bucket` or `do_nothing`
            "on_closure": "destroy_bucket",

            "private": {
              // Credentials for interacting with the S3 bucket
              "access_key": "AKIAIOSFODNN7EXAMPLE",
              "secret_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
            }
          }
        }
      }
    },
    // Optionally, add the REST plugin
    "rest": { "http_port": 8000 }
  }
}

在我们的 S3 存储概念中，每个存储都与一个 S3 存储桶相关联，而卷则与服务器相关联。 一个卷可以与多个存储相关联，这意味着所有 s3 存储桶都将存储在同一台服务器上。

所需的卷配置仅限于指定服务器的位置（如果使用 Amazon S3，则只需指定区域，而使用 MinIO 时则需提供 URL）以及 TLS 证书路径。 与之关联的所有存储将共享相同的配置。

在存储配置中，我们指定了密钥表达式、存储桶的名称、访问存储桶所需的凭证、与创建存储及其读写权限相关的一些策略等……更多详情请参见示例配置文件。

考虑因素

请记住，S3 后端仍在开发中，预计会有一些额外的工作要做。

在现阶段使用该后端有几件事需要考虑，有些与 MinIO 和 AmazonS3 的工作方式有关，有些与该后端的开发状况有关。

同名文件和目录

关于 MinIO 和 AmazonS3 之间的区别，MinIO 是 “兼容 S3 “的，但这并不意味着它的工作方式完全相同。

我们在开发过程中注意到的一个不同点来自这样一个问题：如果我们在 “a/b “键下输入一个值，然后在a/b/c 下输入另一个值，会怎么样？ Zenoh 允许您在a/b/c 或a/b 下发布一个值，例如，订阅a/\*\* 的接收器应该能够同时接收这两个事件，而不管监听器是否是存储设备。

那么，系统在处理这种情况时是如何表现的呢？

└── a
    ├── b
    │   └── c
    └── b

在a/b 下进行发布，之后在a/b/c 下进行发布（或相反），这意味着我们将在/a 下的同一位置拥有一个与文件同名的目录！
MinIO 不允许这样的行为，当尝试执行这样的操作时会抛出错误信息。 不过，亚马逊 S3 完全没有抱怨！ 这是因为 Amazon S3 使用扁平命名空间来组织文件和目录，而 MinIO 使用文件系统层次结构来存储（更多信息请参阅本讨论）。 在文件系统中，我们不能让文件与同一位置的目录同名。 事实上，我们在前段时间开发文件系统后台时就曾遇到过这个问题，不得不开发一种机制来允许这种行为，并存储这两个事件的值。 不过，在新的 S3 后端中，暂时还没有实现这种机制，因此在现阶段使用 MinIO 的同时使用该后端时需要考虑到这一点。

时间戳样本

我们还没有考虑样本的时间戳，这可能会在某些边缘情况下造成问题，例如，如果我们在发送 PUT 之后紧接着又对同一个键表达式发送了 DELETE，那么 DELETE 操作可能会比 PUT 操作更早到达存储区，这将导致文件被继续存储，而不是按照预期删除，原因是顺序问题。 在本例中，如果考虑到时间戳，我们就可以放弃 PUT 操作，避免损坏存储。 这一点尚未实施，但已为此开辟了一个议题。

支持复制

Zenoh 方面尚不支持复制。 如果我们有两个订阅了相同关键表达式的 S3 后端，其中一个瞬间宕机，当它重生时，需要从另一个后端获取它错过的数据来同步。 目前尚未实施。 不过，我们可以从 Amazon S3 和 MinIO 提供的复制机制中获益。

另一个复制问题是，当我们想使用多个不同的后端，例如 S3 和 RocksDB 时。 目前还没有解决这个问题的办法，需要用户手动进行同步。

Aws-sdk-s3 库

最后，该实现依赖于亚马逊的aws-sdk-s3 Rust crate，而 aws-sdk-s3 Rust crate 本身还在开发中，并明确指出：”请注意：SDK 目前处于开发人员预览版，仅供反馈之用。 请勿将此 SDK 用于生产工作负载。“因此，在进行生产发布之前，你需要充分考虑到这一点。

截至目前，亚马逊开发该板条箱的工程团队正在定期发布新版本。 因此，为了更新依赖版本，预计该后台将在未来推出新版本。

下一步是什么？

关于如何使用 S3 作为 Zenoh 的存储空间的文章到此结束，这要归功于我们最近实施的 S3 后端。

虽然它还在开发中，但它的第一个版本已经为我们提供了许多功能。 我们可以

• 利用 Zenoh 的优势，例如使用关键表达式从 S3 存储器中查询数据
• 使用 TLS 确保我们与 S3 存储的通信安全
• 使用 MinIO 替代亚马逊 S3

尽管如此，我们仍希望在不久的将来解决一些局限性问题。

请继续关注我们的更新，同时不要忘记在Discord上与 Zenoh 团队保持联系，并就路线图上的新功能提出建议。

The post Zenoh 存储获得提升：通过S3 集成增强存储能力 appeared first on ZettaScale.

The post TTTech Auto和ZettaScale扩大合作，推出Zetta Auto appeared first on ZettaScale.

The post ZettaScale宣布推出其云到微控制器平台Zetta appeared first on ZettaScale.

序言

这一期的博客由著名的台湾大学（NTU）的一组研究人员撰写。该团队在R2X和V2X研发项目中使用Zenoh已经有一段时间了，最近对我们的Blue Dragon 协议、MQTT、Kafka和DDS进行了有趣的性能比较。我要代表Zenoh社区感谢台湾大学的团队，因为这次评估回答了我们经常被问到的几个问题。

-kydos

介绍

高性能一直是泽诺的主要目标之一。虽然每个版本都提供了Zenoh的性能（请参阅此处、此处和此处），但到目前为止，还没有将Zenoh与其他技术进行比较的性能评估。然而，这是在 Zenoh 的 Discord 和Github上很常被问到的问题。在这个博客中，我们将基台湾大学所发表的这篇论文，并进一步做出探讨和分析。

 

通信模型

MQTT和Kafka采用了一种代理通信模型，其中每条消息都必须通过一个代理。不同的是，DDS采用了对等通信模型，在该模型中，消息在发布者和订阅者之间直接交换，而不需要任何中间人。Zenoh同时支持代理和对等通信模式，以及路由基础设施模式。图1展示了具有混合拓扑的模型，其中Mesh和Clique是对等模型。有关详细信息，请参阅各种部署模型。为了与MQTT、Kafka和DDS进行公平的比较，Zenoh中同时使用了代理和对等模式。

图 1 杰诺提供的拓扑结构

测试的性能指标

对于此性能评估，我们感兴趣的是评估两个关键性能指标，即吞吐量和延迟。图2显示了吞吐量测量的通信图。对于Zenoh、MQTT和Kafka之间的比较，所有数据都通过“代理”或“Zenoh 路由器”流到订阅者。对于Zenoh对等模式和DDS测试，数据直接从发布者传递到订阅者。

图 2 吞吐量测试配置图

图3显示了延迟测量的通信图。与吞吐量测试类似，对于MQTT、Kafka和Zenoh客户端模式，消息将由代理或路由器转发，对于Zenoh对等模式和DDS，数据将直接在ping和pong节点之间传递。

图 2 延迟测试配置图

试验台配置

实验准备了两种场景：在一台单机上和在通过以太网连接的多台机器上。对于多机器场景，测试的程序和代理（或Zenoh路由器）将在不同的机器上运行。表1显示了每台使用过的机器的配置。

表1试验机配置

类型	规格
OS	Ubuntu 20.04.3 LTS
CPU	AMD Ryzen 7 5800X运行在固定频率4.0 GHz 8核处理器，16线程
RAM	32GB DDR4 3200MHz
网络	100Gb以太网（适用于多机场景）

所有Zenoh、DDS、MQTT和Kafka的测试过程都是相同的。它们的版本和设置如下所述。这些程序是根据准确测量指南中的建议设计的。所有的基准测试程序都可以在Zenoh性能测试项目下找到。

对于Zenoh，测试程序使用0.7.0-rc 版本，Zenoh 路由器zenohd 可按照本指南构建。 其可靠性被设为 “可靠”，发布方的拥塞控制选项被设为 “阻止”。 对于延迟测量，其可靠性被设置为 “BestEffort”，以便与 Kafka 和 MQTT 的行为保持一致。

对于MQTT，测试程序使用Eclipse Mosquitto 2.0.15 版本。 MQTT客户端是用Eclipse Paho MQTT C 客户端库 v.1.3.11 实现的。对于所有MQTT客户端，通信QoS级别都设置为0以实现最佳性能。

对于Kafka，测试程序中的代理端和客戶端分別使用了官方的 3.2.1版和 rdkafka 库 0.28.0版。

为了获得更好的结果，根据在线文档和实际实验的建议，选择了以下参数：吞吐量为linger.ms=0，吞吐量为batch.size=400KB，延迟为1；compression.type=none，acks=0，fetch.min.bytes=1（仅用于延迟测试）。

对于DDS，测试程序使用Eclipse Cyclone DDS作为目标实现。它们基于官方DDS示例。对于可靠性QoS，采用了RELABLE。对于历史QoS，KEEP_LAST用于延迟测试，KEEP_ALL用于吞吐量测试。

吞吐量比较

在吞吐量测试中，发布程序背靠背地发布消息。订阅同一主题的使用者程序收集一组消息并计算消息速率（msg/s）。对于每个有效载荷大小，该过程将重复多次，并且从样本中选择中间数作为结果，其中超过第1和第99百分位数的样本将视为异常值并从中排除。同样的过程也适用于Zenoh、Cyclone DDS（以下简称为DDS）、MQTT和Kafka。比特率（bit/s）也是基于消息速率和有效载荷大小来计算的。此外，iperf实用程序还用于测量两个对等点之间应用层的理想数据速率。为查看吞吐量的趋势，从8字节到512MB的各种有效载荷大小都有被测试。我們在下面的图表中Y轴的对数刻度，分別显示了消息速率和比特率。统计数据可以在点击此处。找到。以下各段将报告其中一些数字，以供讨论。

图 4 以毫秒/秒为单位的单机方案吞吐量数据

图4显示了单机场景的结果。从图中可以看出，对于较小的有效载荷大小，Zenoh可以达到4M msg/s以上。在Zenoh的两条线中，对等模式（由Zenoh P2P表示）比客户端模式（由Zenoh brokered表示）提供了更好的结果，因为数据传输不需要由Zenoh路由器中继。DDS虽然速度较慢，但相对接近Zenoh，仍然可以达到2M msg/s。请注意在图表中，Y轴是日志刻度。

至于Kafka，对于小于2KB的有效载荷大小，它保持56K到63K msg/s之间的稳定消息速率，并开始降低，直到最后一个数据被成功测量出512KB的有效载荷尺寸。另一方面，MQTT在负载大小为32KB之前，33K到38K msg/s之间的吞吐量稍低。然而它随后开始大幅减少，并显示出最差的性能数字。尽管与Kafka相比，它支持更大的有效负载大小。然而原则上Kafka应该能够支持更多的有效负载大小。观察到的限制背后的原因是，我们使用的Kafka绑定无法将消息大小扩展到1MB以上。

图 5 以比特/秒为单位的单机方案吞吐量数据

图5提供了以比特每秒（bit/s或bps）为单位的吞吐量。它表明对等于或大于4KB的有效载荷大小，Zenoh开始向iperf测量的理想吞吐量饱和（76Gpbs）。对等模式的Zenoh P2P最高可达67Gbps。对于DDS，实现的最高吞吐量约为26Gpbs。当有效负载大小大于16KB时，Kafka似乎在大约4~5Gbps时饱和。对于MQTT，它在32  KB的有效负载大小下可达到约9 Gbps。MQTT的性能下降现象在测试中不断出现。这背后的原因仍然未知，未来值得进一步研究。

总体在这种单机场景中，以比特率数字进行吞吐量比较，考虑到从Zenoh、DDS、Kafka和MQTT获得的最佳数值，Zenoh对等模式在8字节的有效负载大小下，实现了比DDS的65x和Kafka与MQTT的130x，高约2倍的性能，。Zenoh在8KB时实现了峰值性能，吞吐量是DDS的4倍以上，是Kafka的24倍，是MQTT的27倍。最后，对于32KB的有效负载，Zenoh实现了比DDS高2倍多的吞吐量，比MQTT高5倍，比Kafka高10倍。

100 Gb以太网上多台机器的吞吐量如图6和图7所示。我们将在这里主要关注比特率结果。

图 6 以毫秒/秒为单位的多机方案吞吐量数据

图 7 多机方案的吞吐量数据（比特/秒

在图中，iperf显示目标网络的理想吞吐量为44Gpbs。Zenoh代理的最大比特率约为34Gbps，Zenoh P2P的最大比特速率约为50Gbps。对于Cyclone DDS，其吞吐量排名仍保持在排行榜的第三位，为14Gbps。另一方面，MQTT的比特率可以在32KB的有效负载大小下达到9Gbps，然后下降，类似于单机场景。对于Kafka来说，它的最佳比特率是5Gbps，有效负载大小也是32KB。

作为比较的总结，从多机场景中观察到的结果与单机结果保持着相似的性能趋势，表明Zenoh的性能改进比DDS、Kafka和MQTT高出几到几十倍。

延迟比较

在延迟测试中，ping程序发布ping消息，并且pong程序在接收到ping时用相同的消息进行回复。测试的有效载荷大小固定为64字节（与ICMP回显/回复对齐），并且以背靠背的方式执行测试，以减少底层操作系统引起的进程调度和上下文切换的影响。延迟被定义为覆盖ping和pong操作的中值往返时间的一半。类似地，我们去除了超过第1和第99个百分位数的异常值。统计数据也可以在这里找到。表2显示了测试结果。并且我们使用Linux Ping 程序作为可达到最小延迟的基线。

表2 单机和多机情况下的延迟数据，单位为µs（微秒）

目标	单机	多机
Kafka	73	81
MQTT	27	45
Cyclone DDS	8	37
Zenoh代理	21	41
Zenoh P2P	10	16
Zenoh-pico	5	13
ping	1	7

对于单机环境，通过ping获得的理想延迟值为1µs。MQTT和Kafka的延迟分别为73µs和27µs。至于Zenoh，虽然Zenoh代理的客户端模式的延迟为21µs，主要是由于通过中间人路由数据，但Zenoh P2P显示它可以进一步降低到10µs。对于Cyclone DDS，延迟甚至低于Zenoh，可达到8µs。原因是它使用UDP Multicast。尽管Zenoh目前还没有实现相同的数据传输，但Zenoh的微控制器实现——Zenoh pico——已经实现了这一点。因此如上Zenoh pico所示，它的延迟可以來到5µs，甚至低于Cyclone DDS，主要是因为Zenoh协议及其实现可以比OMG DDSI-RTPS协议（由所有符合DDS的工具实现）更轻、更高效。

对于具有100Gb以太网的真实网络上的多机场景，Zenoh代理的延迟约为41µs，对等模式下的Zenoh P2P数量为16µs，低于Kafka的81µs、MQTT的45µs和Cyclone DDS的37µs。对于Zenoh pico，它在13µs时仍然是最好的，最接近ping实用程序在7µs时获得的基线。

总体来说，Zenoh的延迟较低。与MQTT和Kafka（以及用于多机场景的DDS）相比，具有默认对等模式的Zenoh具有最短的延迟。当Zenoh支持UDP Multicaset传输时，正如Zenoh pico所显示的结果，预计Zenoh可以实现所有软件中最低的数值。

结论

在这个博客中，我们比较了Zenoh、MQTT、Kafka和DDS的性能。Zenoh的表现一直优于MQTT和Kafka。结果表明，由于Zenoh的实现中嵌入了低开销设计和多种优化技术，Zenoh相对更接近经典基线工具iperf和ping从应用层获得的吞吐量和延迟评估的理想数值。

在我们的评估中，当使用默认对等模式时，Zenoh在100GbE网络的单机和多机测试里，分别实现了高达67Gbps和51Gbps的吞吐量。它可以在MQTT和Kafka的基础上提高1~2个数量级，并可以使DDS的吞吐量翻倍。值得注意的是，Cyclone DDS在单机场景的延迟测试中表现最好，因为它使用了UDP Multicast传输机制。然而当Zenoh的微控制器实现Zenoh pico也实现了UDP Multicas传输时，它在所有情况下都达到了最低的延迟。此功能稍后将得到所有Zenoh实现的支持。

Zenoh的目标是提供一个具有无与伦比的性能和可扩展性的下一代通信框架。除了令人难以置信的性能外，Zenoh还是颇为简单的API和颇短学习曲线的技术。我们相信，Zenoh是工业、物联网、机器人和汽车应用程序的优先选择，可以无缝支持云到边缘和物到物的连续性。

希望您喜欢，

– William , Circle 和 Jerry

---

1. 在arXiv版本中，没有显示平均数（带标准差），而是在这个博客中使用中值来增加比较的公平性。

The post Zenoh、MQTT、Kafka和DDS的性能比较 appeared first on ZettaScale.