不管是從商業模式導出的業務模型，還是從技術發展的角度看，文本都傾向于將物聯網技術構架看作是互聯網技術構架的延展。而與這個觀念對立的，是傳統嵌入式軟件開發的視角。

簡單來說，目前的互聯網技術構架主流是大前端與后端兩個世界：大前端包括Web的JavaScript技術、Android和iOS技術，著眼于解決用戶交互；后端包括數據庫、服務構架、運維等，著眼于解決存儲、業務邏輯、安全與效率等。當然，現在前后端技術爭相更新，比如業務邏輯前置化、微服務構架、JavaScript全棧化等新的解決方案也開始模糊前后端的差異。

而物聯網設備端的引入，著實讓這些技術有點難以歸類，從業務性質上物聯網是另外一種前端或是前端的延伸，比如共享單車應用中，自行車端的應用顯然是跟人交互的另一個業務場景，也在為后端源源不斷地提供著數據，但是自行車又不像網頁或者App完全是在解決可視化UI的事情。

而且，現在的設備端開發技術跟前端技術太不像了，由于目前設備端的開發技術都還偏底層，一般來說計算資源如處理能力、本地存儲都非常有限，反而像后端一樣要考慮資源效率。

那么，我們只好為物聯網單獨命名一個端，不如我們暫時就叫它設備端。

2.新后端

2.1 MQTT

新后端核心問題在于加入了面向設備的接入服務，實際上在這里，除類似視頻對講或是安防監控的多媒體實時通道外，這個接入服務已經基本事實化為MQTT。

消息隊列遙感傳輸協議是在TCP/IP協議之上使用的，基于發布/訂閱的“輕量級”消息協議，目前為ISO標準（ISO/IEC PRF 20922）。它被設計用于輕量級和低帶寬的遠程連接，發布/訂閱消息傳遞模式需要消息代理，消息代理負責根據消息的主題向需要的端發布消息。

如果需要連接的設備沒有超過10萬臺，使用8GB內存的云主機跑Mosquitto就可以；如果設備量是幾十萬臺，可以考慮Mosquitto做集群負載均衡；如果設備量是大幾十萬臺乃至百萬臺以上，那你需要專業的團隊或專門的投入來維護這件事情，這個細節就不在本文討論范圍了。

2.2 OTA

固件組件在線升級是必須要做的事情，MQTT傳大文件不靠譜，所以一般傳過去一個帶Token的URL，設備端去下載就好，HTTP或者HTTPS都可以。業務比較簡單，設備端幾十萬以內沒有什么特別的地方。

2.3 數據存儲與服務

Mosquitto作為MQTT的引擎，需要后端按照業務邏輯去調用，這里按照業務需求寫好后端邏輯即可。在各種后端語言中調用Mosquitto都非常簡單。

3.設備端

設備端是物聯網領域最五花八門并且正在發展中的地方。其他領域，后端或者前端，經過十幾年的發展，已經出現每個細節的主流技術，基本沒有碎片化的情況，但是在設備端，開發技術的碎片化是應用發展還不到位的充分表現。

舉例講，選用不同的芯片，就要用不同的操作系統，不同的C庫封裝，各家IDE也不盡相同，編譯工具鏈更是從芯片原廠給出。開發起來呢，寄存器、內存分配、硬件中斷都要深入進去。這就是傳統嵌入式開發的現狀，也是物聯網設備端開發的現狀。

到目前為止，真正生產環境中用到的語言就是C/C++，極個別會在設備端用到Python，基本沒有其他語言。操作系統超過50種，主流的也有10種以上，其中嵌入式Linux份額并不大，各種實時操作系統各具特色，各有一片天地。

簡單總結一下相對于物聯網開發，傳統嵌入式開發的方式主要有以下幾個問題：

需要考慮中斷、寄存器、內存分配等過于底層的工作；

編譯、燒寫、觀察、借助調試設備進行調試的開發生命周期；

不同SoC和系統的差異過大；

缺乏代碼復用與開源的習慣；

開發者在開發環境和固件編譯上花費的時間過多。

所以我們看到設備端的開發是基于芯片選型完成的。當設備端產品面臨一個需求時，現有的流程是判斷產品的各項技術參數，從而確定一個芯片，進而使用這個芯片的一整套開發技術。這也是早期嵌入式場景使用的芯片自生技術特性所決定：計算資源（CPU主頻、存儲）、外圍接口、使用溫度、通訊協議等核心參數的不同導致芯片碎片化，芯片碎片化導致嵌入式開發碎片化。

目前這個領域的大趨勢是：物聯網芯片有望走向趨同，物聯網開發環境與技術有望趨同。

3.1 物聯網芯片

早期由于成本所限，物聯網領域使用的芯片總是表現得非常缺資源，很難找到一個各方面（計算資源、外圍接口、使用溫度、通訊協議等）都比較合適的芯片去適應普遍的場景。隨著半導體門檻逐步降低，中國半導體制造業逐步成型，芯片資源開始走向富余，其中的代表芯片是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來說有足夠的富余，并保持在同樣的價位。因此，在這類芯片上，有足夠的資源做抽象化的封裝和開發框架實施。我們看到除了這幾顆芯片原廠提供的傳統嵌入式開發包之外，社區和其他廠商已經在這幾顆芯片上加快了新開發技術的實現。

3.2 開發技術

物聯網設備端開發技術目前有兩個比較大的發展方向，一是統一化的物聯網操作系統，二是統一化的物聯網開發框架。他們共同的目的是形成“軟件定義物聯網”，與傳統從芯片選型開始的，著陸于原廠SDK中完成應用開發，與需求和產品設計匯合的流程完全相反，希望從需求和產品設計入手，通過公開統一的軟件構架完成開發，再根據開發使用到的資源去落地芯片和外圍設備。這樣做的好處主要在于提高開發效率和形成可以復用的應用代碼。

操作系統

雖然市場上存在的設備端操作系統有數十種之多，但是我們看到活躍的，明顯向“軟件定義物聯網”方向發展的有三家：

Zephyr

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

RTthread是純國產的小型操作系統，植根于中國的各種使用場景，10年來已經確立了自己的地位，在很多行業有自己的一席之地，目前社區非常活躍，核心團隊以創業公司的形式推進，非常專注。技術上的特征作為一個成熟的系統，沒有什么可以吐槽的地方。Zephyr有的技術優勢RTT都有，而且RTT在生產環境的裝機量較為可觀。

華為LiteOS

華為是全球范圍內物聯網技術的根源廠商之一，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

WRTnode是一個北京的開源硬件團隊，提供從開發到硬件交付的全流程服務。他們最近開放的node.system和noyun.io即是著眼于實現物聯網JavaScript的開發框架和開發者生態。在WRTnode的實現里，設備端的JavaScript開發已經變得像cloud9.io一樣全案在線開發，為開發者屏蔽了嵌入式開發的繁瑣編譯燒寫工作。

Ruff

Ruff是位于上海的創業公司，2015年開始一直在演進基于物聯網設備端JavaScript的開發者生態，提供了較為可行的代碼復用框架。目前他們已經開始服務商業客戶，為物聯網應用的快速實現提供了可能。

同時，Zephyr和華為LiteOS也都有各自的JavaScript runtime發布計劃。

以上我們看到了設備端開發的一些新的發展，目前這些新的設備端開發技術，已經逐步面向交付轉移了。有理由相信經過一段時間的發展，面向效率的商業模式驅動下的物聯網開發技術將迎來一大波更新，從而導向物聯網應用的真正大發展。