背景

　　時間：1年 前的某日

　　坐標：深圳

　　在一個平常的不能再平常的周末下午，幾個小伙伴聚在了一起，一起暢想 “萬物互聯” 的物聯網未來。小伙伴中有硬件、嵌入式、軟件;有互聯網公司的全棧工程師、也有核電廠的工控系統維護者、還有路由器廠商的 wifi 協議。我們發現，世面上沒有開源且可商用的物聯網平臺或系統。這里的可商用，不是搭建幾個 demo 把硬件連上網、app 操作兩下這么簡單!

　　有以下幾點都是必須著重考慮的：

　　必須有完備的硬件、嵌入式、云端一體的協議及架構設計

　　能夠實現真正的硬件智能化，能夠基于數據學習并自主工作

　　必須有很高的性能、穩定性及擴展性

　　必須能夠適應成千上萬種不同資源的硬件設備，從 PC 到手機、從計算資源極其有限的單片機到網絡帶寬極其有限的控制器

　　必須能適應不同的網絡場景，包括有線、wifi、3g/4g、gprs 等

　　必須有很可靠的安全性

　　需要盡可能降低研發和生產成本

　　在媒體和科技工作者都抱著物聯網是未來的觀點并翹首觀望時，我們決定做點什么，而不是當看客!這個平常的不能再平常的周末下午，也許對我們不太平凡。

　　我們決定啟動全套可商用物聯網系統的設計和研發，并在不久的將來，全部開源。

　　于是大家利用業余時間，開始了協議設計及系統設計，將項目慢慢啟動了起來。幾個月后，*個商用版本的研發成功完成。這期間，好幾個小伙伴辭去了工作，全職進行研發。我們在沒有融資、沒有資源的情況下一路走到現在，其中辛酸就不多言了。謹以此文記錄我們在系統設計和研發中的走過的路，以饗同樣是物聯網愛好者的你。

　　整體設計

　　一個物聯網系統涉及硬件、軟件、云端、app 各個環節，必須從整體進行頂層設計，只倚重某個單一的環節進行設計的系統都不具備良好的適用性和擴展性。我們在設計時為了避免這種情況，使系統能夠適應zui廣泛的物聯網場景(甚至包括工業場景)，每次的架構設計討論都是所有團隊成員參與。大體的系統架構如下：

　　協議

　　在一個物聯網系統中，協議是串通上下層的關鍵紐帶。在物聯網系統中，我們將協議分為兩大層：通信層和業務層。

　　通信層基本上是傳統互聯網的網絡基礎設施，負責將數據在物聯網系統節點中的傳輸

　　業務層分為兩層，底層是負責物聯網場景下數據交換格式的規范，上層是物聯網場景需要具體傳輸的業務數據規范。

　　通信層互聯網基礎架構目前已經非常成熟且通用，但是業務層協議目前還是種類繁多。可以確定的一點是，zui終能在物聯網應用中稱霸的協議，一定也像互聯網時代的 TCP/IP 一樣是開放的、免費的。目前符合此特性并使用比較多的有 XMPP、MQTT、COAP 等。關于具體的對比，可以參考我之前的另一篇文章《物聯網通信協議介紹》。

　　文中總結如下：

　　互聯網中使用較多的 HTTP、websocket 以及 XMPP 等協議，在設計時都是根據互聯網應用場景設計的，雖然很多廠商把他們應用在物聯網系統中，但是必然會水土不服，這些協議的通病就是根本無法適用物聯網設備的多樣性，無法適用很多物聯網設備對低功耗、低成本的需求，難以在極低資源的物聯網設備中運用。

　　COAP 協議針對資源受限的嵌入式設備設計，但由于很多物聯網設備隱藏在局域網內部，COAP 設備作為服務器無法被外部設備尋址，在 *6 沒有普及之前，coap 只能適用于局域網內部(如 wifi)通信，這也很大限制了它的適用范圍。

　　MQTT 在協議設計時就考慮到不同設備的計算性能的差異，所以所有的協議都是采用二進制格式編解碼，并且編解碼格式都非常易于開發和實現。zui小的數據包只有 2 個字節，對于低功耗低速網絡也有很好的適應性。有非常完善的 QOS 機制，根據業務場景可以選擇zui多一次、至少一次、剛好一次三種消息送達模式。運行在 TCP 協議之上，同時支持 TLS(TCP+SSL)協議，并且由于所有數據通信都經過云端，安全性得到了較好地保障。

　　我們zui終選擇基于 MQTT 來作為業務傳輸層主要協議。但是 MQTT 協議本身的設計是針對開放設備，對于可商用的物聯網系統不得不保證設備的安全性和完善的*機制。所以我們在實現 MQTT 協議時進行了一些定制和限制。

　　在業務層的上層(business 層)，目前的物聯網系統都是各自針對自己的業務場景設計協議規范。有沒有可能根據物聯網場景統一業務數據的規范呢?我們認為是可行的，并且也是必要的。如果把通信協議比作聲音，光有通信協議，任何人之間還是無法交流。只有統一語言，大家才能順暢溝通。所以我們抽象出物聯網節點中傳感器和執行器的業務場景，并設計出含有物聯網業務數據語義的業務層協議。目前已經將業務層協議開源，希望對廣大愛好者和從業者帶來一定參考價值。

　　云端平臺

　　互聯網時代的用戶上網終端主要是 PC 和手機等設備，可以想象，物聯網時代，上網終端會呈多樣化、海量化趨勢。保守估計每人擁有數十套聯網設備，數據規模必然也是幾何倍增長。所以物聯網云端平臺注定是一個大規模的海量分布式系統。

　　目前很多愛好者或者廠商通過搭建簡單的 web 系統(如 php、nodejs、python 實現的 web 接口)可以實現設備的聯網，但是可以想象，在真正的商用場景中，穩定性、性能、擴展性都必然遭受沖擊，無法應對。

　　在進行技術選型和架構設計時，我們也綜合考慮以上因素進行設計和實現：

　　采用 go 語言作為主要開發語言。go 語言有著簡潔的語法，并且能夠很方便地進行高并發程序的開發，在高性能云計算系統的開發中有著得天獨厚的優勢。

　　采用 microservice 分布式架構。microservice 架構能夠構建出更穩定、擴展性更好的分布式系統，也是目前分布式系統中zui流行的架構方式。

　　使用 docker 降低運維成本。docker 能夠方便地對系統就行升級和出錯回滾，保證了系統發布時的穩定性。

　　對外接口采用 REST 風格進行設計。REST 風格的接口便于升級和兼容，并擁有非常易于理解的語義，降低的學習門檻。

　　多副本部署。任何服務模塊我們都保證同時至少有兩個運行實例，并根據服務發現機制自動進行負載和調度，以增加系統可用性。

　　大體的云端架構如下圖

　　目前我們的系統已經發布到 0.8.0 版本，后續會在安裝和運維的便捷性上進行優化，并計劃在 1.0 版本時開源發布。

　　嵌入式

　　物聯網硬件的嵌入式軟件除了傳統部分，必須加入聯網邏輯以及傳感器、控制器的管理。為了提高開發效率、方便復用，我們設計并開發了輕量級的物聯網嵌入式開發框架，并對物聯網業務進行了抽象，以便移植到不同的硬件平臺。我們希望做到的是，在不需要更改任何業務層代碼的情況下，一個物聯網嵌入式應用可以在不同的硬件平臺運行。

　　當前很多大企業(華為、惠普、google 等)都紛紛推出了物聯網操作系統，后續物聯網領域會出現多種操作系統共存的局面。不同的操作系統能運行的zui低系統資源以及具體應用場景都不盡相同，但我們相信，物聯網的上層業務是通用的，這也是我們設計物聯網嵌入式開發框架的原因。

　　安全

　　近些日子，各種廠商的物聯網設備紛紛傳出被黑的消息。從 TCL 到特斯拉，黑客都成功實現破解和隨意操控。和互聯網時代一樣，安全在物聯網目前的早期階段注定是容易被忽略的問題。為此我們也在設計系統時也沒有掉以輕心：

　　所有接入層通信都采用 tls 進行加密，包括對 app、業務服務器的開放接口。

　　用戶、設備關鍵信息進行加密保存

　　針對設備有完善的用戶鑒權機制

　　針對互聯網安全場景的其他安全措施

　　安全不是一朝一夕的事情，需要從系統開始構建時就考慮，并不斷完善安全手段和規則。

　　開發板

　　為了降低物聯網硬件的開發成本，我們基于 esp8266 設計了物聯網開發板 Tisan，并在 Tisan 實現了我們的嵌入式開發框架及物聯網協議。我們希望 Tisan 成為大家相互學習、交流和沉淀技術的工具，也希望更多的愛好者能一起做出好產品

　　以開源之名

　　光陰荏苒，白駒過隙。一路走來，我們執著地將所有設計慢慢付諸實現，為未來的物聯網技術貢獻自己的力量。物聯網技術涉及的方向眾多，我們的力量畢竟是有限的，這也是我們從一開始就以開源形式開發項目的原因。

　　本文來自攀多物聯科技的投稿。攀多物聯是深圳一家物聯網創業公司，致力于打造物聯網產品開發工具，提供縱向物聯網解決方案。