物聯網和邊緣計算的未來：云狀態機

　　在物聯網嵌入式設備的世界中，這種浪費部分是由于設備邊緣云模型的教條式默認設置。這種方法涉及將大量數據發送到本地邊緣計算機的IoT設備網絡。然后，邊緣要么處理該數據以將其推送到云存儲庫，要么首先將數據推送給云以進行處理。

　　這種方法旨在更好地促進跨網絡的數據通信。 但是，這并不是萬能的物聯網框架，因為它有時會對項目的成本，開發和部署造成嚴重的損害。

　　為了說明這一點，考慮一個安裝傳感器的農業物聯網農場，這些傳感器收集土壤濕度數據并相應地調整其噴水系統。如果農場采用設備邊緣云模型方法，可能會出現幾個昂貴和耗時的問題

　　邊緣計算機為整個計算存儲網絡體系結構增加了一層復雜性，并可能導致嚴重的數據延遲問題。 如果網絡太大，噴頭可能會打開太長時間，淹沒農作物

　　邊緣設備的刷新周期很多，這導致“架構設計”鎖定。 這是設計整體架構時的一個重要方面，因為它限制了環境可以適應的物理變化量，例如季節和自然災害。

　　如果該農場決定擴展其網絡，則該農場主要么必須支付大量的前端成本來安裝更多的邊緣計算機，要么要投資于功能更強大的IoT設備來承擔更大的工作量。 無論如何，可伸縮性是一場噩夢。

　　雖然邊緣計算在物聯網中確實有它的位置，但是這個框架已經被冗余過度使用。相反，工程師和開發人員必須學會以不同的方式思考如何構建他們的網絡架構。

　　隨著2020年更強大的云計算的出現，基于云的狀態機為物聯網網絡設計提供了一種極其通用和高效的解決方案。 對于那些尚未意識到在云中派生狀態機的內部機制的人，閱讀本文非常有用，因為它詳細解釋了什么是云機以及如何從頭開始構建云機。

　　本文將作為后者的配套篇，因為與其回答如何使用云機，不如回答如何著重介紹為什么。 特別是，本文將解決物聯網的三個原則：硬件，開發/部署和業務模型。

　　本文還將引用PubNub Functions作為云計算機示例。 Function能夠與通過pub-sub框架發送的任何消息一起觸發一段JavaScript代碼的功能使其成為云機器架構的理想選擇。

　　1:硬件性能

　　在PubNub函數中駐留狀態機意味著用戶可以將所有數據和計算外包給云。因此，物聯網設備至少可以通過REST API或本機SDK單獨發布和訂閱數據，這樣所有工作都可以在云中完成。

　　客戶端代碼的極簡發布訂閱框架為物聯網設備的硬件提供了許多有利的好處：

　　負擔得起使用便宜且笨拙的設備

　　減少對內存空間和處理能力的需求

　　如果網絡足夠大，即使外包給云的一點邏輯也可以節省很多錢。

　　較長的占空比

　　更快的執行時間

　　2：軟件開發和部署過程

　　在部署向邊緣服務器報告的設備網絡時，調試過程可能需要與開發本身一樣長的時間，甚至更短。 如果問題不明顯，甚至診斷問題也可能非常繁瑣。 但是，當網絡在狀態機框架下工作時，更容易發現問題。

　　例如，狀態機允許代碼非常易讀，因為可以將代碼分解為非常小的可管理的塊，其他用戶可以快速運行它們。 如果IoT設備或網絡無法正常運行，則開發人員可以從物理上識別出哪個狀態不正常，并快速修復與該狀態相關的有問題的代碼。

　　例如 具有空白狀態和4個輸入的狀態機

　　此外，無需在現場安裝Edge，即可從任何位置遠程訪問Cloud Edge。 借助PubNub函數，在嘗試遠程更新問題時，這一優勢變得更加明顯。

　　通過此UI，用戶可以使用控制臺調試器虛擬化每個IoT設備的終端屏幕。 由于所有設備需求都是互聯網連接，因此用戶基本上可以為世界任何地方的任何設備網絡編程邏輯!

　　功能模塊還帶有一系列API，可以輕松將它們導入云代碼，而無需設備需要更多硬件。 這意味著即使最小的IoT設備現在也可以與任何API進行交互，無論大小。

　　3：商業模式和策略

　　在業務端，云狀態機與傳統的基于云的網絡共享許多相同的優勢。

　　云系統的最大好處涉及項目的可擴展性。 隨著項目業務的開始擴展，向網絡中添加更多設備對網絡基礎設施幾乎沒有影響。 僅需對設備進行預編程即可發布和訂閱網絡，只需要來自服務器的訪問令牌即可。

　　然后，企業的服務器端可以遵循“按需購買，按需購買”的業務模型，在該模型中，客戶可以為動態增長的網絡調整付款。 這與邊緣模型相反，在邊緣模型中，客戶端需要為可能永遠不會使用的其他服務器支付前期費用。

　　此外，企業可以將自己制造成平臺即服務(PaaS); 該公司可以提供其云服務器作為其他設備網絡使用的平臺。 例如，如果一家公司要構建針對特定IoT智能服務器場優化的強大的PubNub Function，則其他公司可以付費使用該功能來部署自己的IoT智能服務器場。如果本文引誘您進入云機器的世界，請自己動手親身體驗一下強大的功能!