不管是從商業模式導出的業務模型，還是從技術發展的角度看，文本都傾向于將物聯網技術構架看作是互聯網技術構架的延展。而與這個觀念對立的，是傳統嵌入式軟件開發的視角。
簡單來說，目前的互聯網技術構架主流是大前端與后端兩個世界：大前端包括 Web 的 JavaScript 技術、Android 和 iOS 技術，著眼于解決用戶交互；后端包括數據庫、服務構架、運維等，著眼于解決存儲、業務邏輯、安全與效率等。當然，現在前后端技術爭相更新，比如業務邏輯前置化、微服務構架、javascript 全棧化等新的解決方案也開始模糊前后端的差異。而物聯網設備端的引入，著實讓這些技術有點難以歸類，從業務性質上物聯網是另外一種前端或是前端的延伸，比如共享單車應用中，自行車端的應用顯然是跟人交互的另一個業務場景，也在為后端源源不斷地提供著數據，但是自行車又不像網頁或者 App 完全是在解決可視化 UI 的事情。而且，現在的設備端開發技術跟前端技術太不像了，由于目前設備端的開發技術都還偏底層，一般來說計算資源如處理能力、本地存儲都非常有限，反而像后端一樣要考慮資源效率。
那么，我們只好為物聯網單獨命名一個端，不如我們暫時就叫它設備端。
新后端核心問題在于加入了面向設備的接入服務，實際上在這里，除類似視頻對講或是安防監控的多媒體實時通道外，這個接入服務已經基本事實化為 MQTT。
消息隊列遙感傳輸協議是在 TCP/IP 協議之上使用的，基于發布/訂閱的“輕量級”消息協議，目前為 ISO 標準（ISO/IEC PRF 20922）。它被設計用于輕量級和低帶寬的遠程連接，發布/訂閱消息傳遞模式需要消息代理，消息代理負責根據消息的主題向需要的端發布消息。
如果需要連接的設備沒有超過 10 萬臺，使用 8GB 內存的云主機跑 Mosquitto 就可以；如果設備量是幾十萬臺，可以考慮 Mosquitto 做集群負載均衡；如果設備量是大幾十萬臺乃至百萬臺以上，那你需要專業的團隊或專門的投入來維護這件事情，這個細節就不在本文討論范圍了。
固件組件在線升級是必須要做的事情，MQTT 傳大文件不靠譜，所以一般傳過去一個帶 Token 的 URL，設備端去下載就好，HTTP 或者 HTTPS 都可以。業務比較簡單，設備端幾十萬以內沒有什么特別的地方。
Mosquitto 作為 MQTT 的引擎，需要后端按照業務邏輯去調用，這里按照業務需求寫好后端邏輯即可。在各種后端語言中調用 Mosquitto 都非常簡單。
設備端是物聯網領域五花八門并且正在發展中的地方。其他領域，后端或者前端，經過十幾年的發展，已經出現每個細節的主流技術，基本沒有碎片化的情況，但是在設備端，開發技術的碎片化是應用發展還不到位的充分表現。舉例講，選用不同的芯片，就要用不同的操作系統，不同的 C 庫封裝，各家 IDE 也不盡相同，編譯工具鏈更是從芯片原廠給出。開發起來呢，寄存器、內存分配、硬件中斷都要深入進去。這就是傳統嵌入式開發的現狀，也是物聯網設備端開發的現狀。
到目前為止，真正生產環境中用到的語言就是 C/C++，極個別會在設備端用到 Python，基本沒有其他語言。操作系統超過 50 種，主流的也有 10 種以上，其中嵌入式 Linux 份額并不大，各種實時操作系統各具特色，各有一片天地。
簡單總結一下相對于物聯網開發，傳統嵌入式開發的方式主要有以下幾個問題：
所以我們看到設備端的開發是基于芯片選型完成的。當設備端產品面臨一個需求時，現有的流程是判斷產品的各項技術參數，從而確定一個芯片，進而使用這個芯片的一整套開發技術。這也是早期嵌入式場景使用的芯片自生技術特性所決定：計算資源（CPU 主頻、存儲）、外圍接口、使用溫度、通訊協議等核心參數的不同導致芯片碎片化，芯片碎片化導致嵌入式開發碎片化。
目前這個領域的大趨勢是：物聯網芯片有望走向趨同，物聯網開發環境與技術有望趨同。
早期由于成本所限，物聯網領域使用的芯片總是表現得非常缺資源，很難找到一個各方面（計算資源、外圍接口、使用溫度、通訊協議等）都比較合適的芯片去適應普遍的場景。隨著半導體門檻逐步降低，中國半導體制造業逐步成型，芯片資源開始走向富余，其中的代表芯片是 MTK 的 MT7697、MT7688 和樂鑫的 ESP32。
MT7697 主要參數為：ARM Cortex M4 CPU，帶浮點單元，大主頻 192Mhz，內存為 256KB SRAM，可配置 4MB 以上的存儲空間，芯片內嵌 WiFi 和 BLE 4.2，有足夠的外圍接口，并能夠適應工業級的使用溫度。
MT7688 主要參數為：MIPS 580Mhz CPU，內存大支持 256MB，可配置 16GB 級別的存儲空間，芯片內嵌 WiFi，接口除模擬接口之外數字接口豐富，價格在幾十元人民幣，功耗較高不適于電池長期使用。但是非常有優勢的是其提供的 linux 開發環境，能夠讓開發者有一種在普通 x86 機器上使用 linux CLI 的體驗，Node.js、MySQL、OpenCV、Nginx 等等在阿里云上怎么用，在這個幾十塊的物聯網小模塊上也怎么用。穩定性超強，幾年不死機也是正常的。
ESP32 的主要參數為：Tensilica LX6 CP，主頻 240 MHz，內存為 520KB SRAM，可配置 4MB 以上的存儲空間，芯片內嵌 WiFi 和藍牙以及 BLE，有足夠的外圍接口，并能夠適應工業級的使用溫度。
這幾顆芯片共同的特征是計算資源和通訊能力以及接口資源相對于傳統 MCU 來說有足夠的富余，并保持在同樣的價位。因此，在這類芯片上，有足夠的資源做抽象化的封裝和開發框架實施。我們看到除了這幾顆芯片原廠提供的傳統嵌入式開發包之外，社區和其他廠商已經在這幾顆芯片上加快了新開發技術的實現。
物聯網設備端開發技術目前有兩個比較大的發展方向，一是統一化的物聯網操作系統，二是統一化的物聯網開發框架。他們共同的目的是形成“軟件定義物聯網”，與傳統從芯片選型開始的，著陸于原廠 SDK 中完成應用開發，與需求和產品設計匯合的流程完全相反，希望從需求和產品設計入手，通過公開統一的軟件構架完成開發，再根據開發使用到的資源去落地芯片和外圍設備。這樣做的好處主要在于提高開發效率和形成可以復用的應用代碼。
雖然市場上存在的設備端操作系統有數十種之多，但是我們看到活躍的，明顯向“軟件定義物聯網”方向發展的有三家：
Zephyr 是 Linux 基金會于 2016 年 2 月發布的物聯網操作系統，背后主要的支持力量來自于 ARM 和 Linaro，具有目前嵌入式小型實時操作系統的普遍特征，比如：輕量到 KB 級的小系統內存占用，支持多種芯片構架：從 ARM Cortex-M、Intel x86、ARC(DSP 內核)、NIOS II（FPGA 軟核）到開源的 RISC V 等，跟 Linux 一樣的模塊化內核組織方式，如圖 2 所示。
Zephyr 目前已經升級到 V1.7 版本，逐步向一個可以用到生產環境的系統靠攏了。Zephyr 大的特色并不在于其完備性而在于其開發理念完全來自于“軟件定義物聯網”，并且有很好的資源支持，在未來應該會有自己的位置。
RTthread 是純國產的小型操作系統，植根于中國的各種使用場景，10 年來已經確立了自己的地位，在很多行業有自己的一席之地，目前社區非常活躍，核心團隊以創業公司的形式推進，非常專注。技術上的特征作為一個成熟的系統，沒有什么可以吐槽的地方。Zephyr 有的技術優勢 RTT 都有，而且 RTT 在生產環境的裝機量較為可觀。
華為是全球范圍內物聯網技術的根源廠商之一，LiteOS 是一個華為內部很多產品都在用的系統，目前也以開源的形式在全力推廣。LiteOS 大的優勢在于華為很多根源技術將利用 LiteOS 進行輸出，目前大的例子就是即將全面商用的 NB-IoT 技術，設備端的開發包將會用 LiteOS 輸出。
以上幾個系統一致的特點包括小型化、芯片適應范圍廣、通信協議適配比較廣泛等，他們也都是開源的系統，研發或推動力量比較活躍。有可能在物聯網領域里的類似 Linux 地位的主流操作系統會是其中某個，也或許會一直都存在下去但是在技術上越來越趨同。
首先解釋一下開發框架，開發框架可以小到是一個細節的工具，也可以大到規定開發的全部邊界。典型的例子是 android，純粹操作系統意義上，Android 是 Linux 的一個分支，但是從 App 開發角度，除 NDK 之外，沒有任何與 Linux 打交道的地方，所以也把 Android 叫做操作系統。再廣泛地看，Android 除了面向手機應用的開發框架，還準備了 Google play 這樣的應用分發渠道，這是開發者生態建設。同理，我們看 node.js 在后端的種種開發模式，也是將所有后端資源都封裝到 JavaScript 里，開發時可以隨時 npm install 各種包來 require，解決了代碼復用問題。
因此我的觀點是，開發框架以及背后的代碼復用和開發者生態才是真正的操作系統。
目前在物聯網領域，正在嘗試向生產環境演進的開發框架基本都基于 JavaScript，而在小型實時操作系統上使用的 JavaScript runtime 目前也基本集中到了 JerryScript 上。JerryScript 是三星開發和開源的一個小資源占用的引擎，內存需要 64KB，存儲需要 200KB 即可，能夠實現完整的事件驅動，符合 ECMAScript 5.1。
如同前文所說，開發框架或是操作系統在當下需要包括以代碼復用為目的的開發者生態，甚至需要包括應用分發，所以我們看到在 JerryScript 的基礎上，有兩家做這類工作的團隊值得關注：
WRTnode 是一個北京的開源硬件團隊，提供從開發到硬件交付的全流程服務。他們近開放的 node.system 和 noyun.io 即是著眼于實現物聯網 JavaScript 的開發框架和開發者生態。在 WRTnode 的實現里，設備端的 JavaScript 開發已經變得像 cloud9.io 一樣全案在線開發，為開發者屏蔽了嵌入式開發的繁瑣編譯燒寫工作。
Ruff 是位于上海的創業公司，2015 年開始一直在演進基于物聯網設備端 JavaScript 的開發者生態，提供了較為可行的代碼復用框架。目前他們已經開始服務商業客戶，為物聯網應用的快速實現提供了可能。
同時，Zephyr 和華為 LiteOS 也都有各自的 JavaScript runtime 發布計劃。
以上我們看到了設備端開發的一些新的發展，目前這些新的設備端開發技術，已經逐步面向交付轉移了。有理由相信經過一段時間的發展，面向效率的商業模式驅動下的物聯網開發技術將迎來一大波更新，從而導向物聯網應用的真正大發展。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
