為了減少延遲、網絡利用率和成本，許多物聯網部署現在在邊緣節點或邊緣節點附近存儲和分析數據。但是，當涉及到數據時，“分布式”可能是一件壞事，特別是如果這意味著信息被困在整個網絡中的孤島中。

那么，當您不可避免地需要它時會發生什么？

讓我們從數據源開始。對于動態數據，圍繞發布-訂閱原則構建的技術旨在處理這種類型的環境。在 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協議版本。

它確實是從頭開始設計的，可以輕松地跨多個子網從邊緣到云進行垂直或水平擴展。

審核編輯：郭婷