在由兩部分組成的系列文章的第一部分中，我們將討論現(xiàn)代分布式物聯(lián)網(wǎng)和物聯(lián)網(wǎng)數(shù)據(jù)應用程序開發(fā)、部署和持續(xù)支持的挑戰(zhàn)。具體解決的是跨越我們所說的技術“孤島”的開發(fā)挑戰(zhàn)，以及跨云、霧和邊緣計算節(jié)點安全可靠部署以滿足現(xiàn)代應用程序需求的挑戰(zhàn)。

隨著物聯(lián)網(wǎng)市場的成熟，本文考慮了跨網(wǎng)絡的抽象層和計算模型的出現(xiàn)。這些可以從單一統(tǒng)一的程序員角度跨異構計算端點和通信層網(wǎng)絡進行應用程序和系統(tǒng)開發(fā)。

隨著物聯(lián)網(wǎng)的迅速崛起，以及物聯(lián)網(wǎng)設備的生產(chǎn)和多樣性的增加，我們已經(jīng)看到創(chuàng)新技術大大提高了生產(chǎn)力和/或產(chǎn)生了全新的商業(yè)模式。同時，現(xiàn)代嵌入式和物聯(lián)網(wǎng)解決方案是分布式和異構的，硬件目標包括低功耗8位MCU，輕量級但功能強大的網(wǎng)絡網(wǎng)關以及互聯(lián)網(wǎng)云服務器的近乎無限的資源。

現(xiàn)代物聯(lián)網(wǎng)解決方案需要跨不同開發(fā)平臺或“孤島”的專業(yè)知識。我們使用術語孤島來表示實現(xiàn)跨網(wǎng)絡 IoT 解決方案所需的分段開發(fā)和部署流程和工具。隨著開發(fā)從云轉(zhuǎn)移到系統(tǒng)內(nèi)的嵌入式組件，需要越來越專業(yè)化和昂貴的人才，這些人才仍然被鎖定在給定的開發(fā)孤島中。這是因為開發(fā)高效、安全和可靠的嵌入式軟件仍然需要高度專業(yè)化的知識，這些知識伴隨著陡峭且通常昂貴的學習曲線。

很多時候，云和應用程序開發(fā)人員認為理所當然的高級抽象并沒有找到嵌入式開發(fā)的方式。也就是說，在跨多個團隊、工具和目標開發(fā)和部署功能時，即使不是不可能，也很難保持敏捷性——后勤挑戰(zhàn)會減緩產(chǎn)品實施和創(chuàng)新的步伐。

該問題的真實體現(xiàn)可能是現(xiàn)代無人機平臺，包括用于數(shù)據(jù)收集的云服務器、高性能網(wǎng)絡網(wǎng)關以及本地設備上網(wǎng)絡。此外，無人機本身可能由可能運行Linux或其他操作系統(tǒng)的強大應用處理器，各種裸機8位MCU處理功能（如無刷電機控制）以及各種GPU，相機和具有不同可編程性的硬件加速器組成。

許多行業(yè)參與者已經(jīng)開始認識到這個快速增長的問題，例如英特爾公司，他最近表示，“嵌入式和物聯(lián)網(wǎng)之間的一個關鍵區(qū)別是連接性。我們正在從孤立的設備過渡到一組能夠感知周圍環(huán)境的互聯(lián)設備。

“如果你考慮所有用于分析的加速器 - CPU，圖形，視頻加速器，深度學習引擎，F(xiàn)PA - 你談論的是4-5種不同的編程環(huán)境。這與舊的工具環(huán)境不同。工具必須以一種允許開發(fā)人員盡可能無縫地在云、網(wǎng)關和設備中的所有這些加速器之間移動工作負載和加速的方式完成。1

物聯(lián)網(wǎng)和物聯(lián)網(wǎng)數(shù)據(jù)

有人可能會說，物聯(lián)網(wǎng)的革命也可以被認為是由DoT或物聯(lián)網(wǎng)數(shù)據(jù)驅(qū)動的。因此，收集、過濾、規(guī)范化、處理和存儲數(shù)據(jù)的高效且經(jīng)濟的基礎設施應該是任何物聯(lián)網(wǎng)部署的核心。

對于許多企業(yè)來說，云已成為分析、存儲和可視化物聯(lián)網(wǎng)數(shù)據(jù)的主要選擇。然而，由于延遲、可用性、成本和隱私等明顯原因，大多數(shù)人會同意某些處理需要在數(shù)據(jù)源（即物聯(lián)網(wǎng)設備）附近完成，其中包括邊緣和霧計算。結果是，在許多情況下，構建、部署和支持端到端物聯(lián)網(wǎng)數(shù)據(jù)管道是一種平衡行為，即決定應該在云中做什么，應該在邊緣或其他地方做什么，跨越多個開發(fā)目標、生態(tài)系統(tǒng)和開發(fā)人員資源。

這部分是由于云中的部署是眾所周知的，特別是像AWS這樣的云供應商已經(jīng)使用各種工具和服務進行了大規(guī)模的數(shù)據(jù)分析和渲染。對于大多數(shù)幾乎沒有指導或誤導原則的企業(yè)來說，如何在邊緣最好地構建、部署和支持數(shù)據(jù)驅(qū)動的計算基礎設施仍然是最佳實踐。這在一定程度上與物聯(lián)網(wǎng)系統(tǒng)的異構性質(zhì)有關，物聯(lián)網(wǎng)系統(tǒng)的硬件和軟件架構、軟件打包和安全功能可能大不相同。

同樣重要且當今該領域缺少的一大部分是以數(shù)據(jù)為中心的邊緣計算基礎設施。此類基礎設施需要能夠：

？標準化 IoT 數(shù)據(jù)的攝取和規(guī)范化方式

？提供劃分和分配數(shù)據(jù)處理工作負載的系統(tǒng)方法

？自動擴展數(shù)據(jù)處理任務，以適應各種數(shù)據(jù)復雜性和數(shù)據(jù)量

？簡化 AI/ML 推理函數(shù)的構建和部署到邊緣的方式

開發(fā)和部署挑戰(zhàn)

市場上有一些袖珍解決方案解決了其中的一兩個挑戰(zhàn)。例如，AWS Greengrass 服務允許您在嵌入式邊緣網(wǎng)關上運行微服務（以 Lambda 函數(shù)的形式）;Azure IoT Edge 提供類似功能，但以顯式容器化應用的形式除外。

然而，在撰寫本文時，這些服務包括一個過于簡化的物聯(lián)網(wǎng)和邊緣部署模型，目前無法在將聚合數(shù)據(jù)發(fā)送到云之前通過大型物聯(lián)網(wǎng)邊緣設備網(wǎng)絡實現(xiàn)復雜的數(shù)據(jù)處理功能。

這部分是由于這些開發(fā)人員強烈接受用于構建安全的云支持的Web應用程序的復雜，敏捷的開發(fā)方法，而嵌入式世界在很大程度上已經(jīng)落后。云和應用程序開發(fā)人員認為理所當然的高級抽象在很大程度上沒有找到嵌入式開發(fā)的方式，這通常使其成為開發(fā)完整解決方案中最慢最痛苦的方面。

O‘Reilly最近的一份出版物很好地總結了這一挑戰(zhàn)的各個方面。《重新思考編程》一文指出，“編程世界將越來越多地分為訓練有素的專業(yè)人士和沒有深厚背景但擁有大量構建經(jīng)驗的人。前者構建工具、框架、語言和平臺;后者連接事物并構建網(wǎng)站、移動應用程序等。2

因此，我們不僅要解決系統(tǒng)架構中各種孤島（云、霧、設備/嵌入式）的開發(fā)挑戰(zhàn)，還要解決如何促進構建者以務實的方式部署、配置、重新配置和支持這些健壯的系統(tǒng)，而不需要深入了解底層硬件架構等。

例如，考慮部署包含圖 1 中體系結構的應用程序。嵌入式節(jié)點可能是低功耗 8、16 或 32 位 MCU 或 DSP 目標，需要深入了解底層硬件架構，并且通常需要牢牢掌握 C 編程語言。該器件可以與各種致動器、傳感器和串行通信協(xié)議（如 I2C、UART 等）接口。

圖1.嵌入式設備直接與云計算通信的示例。

相反，圖 1 右側(cè)的云數(shù)據(jù)存儲通常是具有 GB 內(nèi)存的高度配置的多核服務器，可能運行強大的虛擬化操作系統(tǒng)并執(zhí)行在具有更高級編程語言的抽象框架中構建的應用程序。

云存儲可以執(zhí)行數(shù)據(jù)記錄、事件處理和類似功能。

正如人們所期望的那樣，為每個設備編程邏輯需要不同程度的底層架構知識（或者在云設備的情況下，可能根本沒有知識），使用截然不同的框架、編程語言和操作系統(tǒng)支持級別（或者在嵌入式節(jié)點的情況下根本沒有操作系統(tǒng)）。

現(xiàn)在考慮相同的應用程序，但部署在圖 2 所示的體系結構上。雖然該架構仍然包括嵌入式節(jié)點和云節(jié)點，但集成了用于記錄、分析、推理或其他邏輯的霧網(wǎng)關。此節(jié)點可能是預配良好的多核 Linux 體系結構，可在 C++ 等中編程。

圖2.將霧與云計算相結合的嵌入式設備通信示例。

這當然提出了許多問題：

如何在這個不斷發(fā)展的體系結構中遷移現(xiàn)有應用程序？

如果有多個嵌入式節(jié)點和/或多個霧節(jié)點怎么辦？

跨不同硬件目標（包括不同級別的計算資源、操作系統(tǒng)支持、帶寬和連接）遷移應用程序的系統(tǒng)方法是什么？

此外，還必須考慮從頭開始支持安全、不同類型的通信鏈接和發(fā)展范式。

顯然，開發(fā)、部署和持續(xù)支持的問題很快就會在孤立的架構中以及組織中的孤立開發(fā)和部署團隊中變得棘手！

期待

隨著物聯(lián)網(wǎng)和 DoT 應用的未來需要嵌入式計算、霧計算和云計算協(xié)同運行，項目經(jīng)理和開發(fā)人員都必須注意構建和部署這些解決方案所需的人力資源和資本。

高級云開發(fā)人員可能不具備嵌入式硬件的復雜知識，并且很多時候不具備這些系統(tǒng)所需的系統(tǒng)級理解和編程技能。同樣，嵌入式開發(fā)人員很可能不知道云開發(fā)中迅速出現(xiàn)的高級開發(fā)框架和工具。

必須注意協(xié)調(diào)許多移動部件，以便對這些系統(tǒng)進行統(tǒng)一和異構的開發(fā)、部署和持續(xù)支持。

然而，與此同時，孤島的集成遠遠超出了給定目標節(jié)點的開發(fā)。必須考慮設備之間的各種通信通道，以及部署給定物聯(lián)網(wǎng)應用程序的基礎設施的維護。此外，必須在應用程序部署的整個生命周期中持續(xù)維護安全配置信息的部署和安全層本身。當物聯(lián)網(wǎng)應用程序中一個計算節(jié)點的應用程序代碼、安全層或配置更新時，不僅需要針對支持該應用程序的其他軟件和系統(tǒng)進行測試和驗證，還需要同時部署。這種迭代部署周期通常由多個互連的軟件模塊和層（請注意，一些專有和一些第三方或開源）組成，必須跨開發(fā)團隊和企業(yè)加以考慮。

在本文的第 2 部分中，我們將解決給定 IoT 部署孤島中的特定開發(fā)挑戰(zhàn)。然后，我們進一步深入研究潛在的面向未來的解決方案，以促進構建這些類型的孤島跨越系統(tǒng)，考慮給定組織內(nèi)的語言和部署方案。

審核編輯：郭婷