2015年10月28日 星期三

‧ 商用物聯網系統的開源之路


1年前的某日,在深圳的一個平常的不能再平常的週末下午,我們幾個小夥伴聚在了一起,一起暢想萬物互聯物聯網未來。小夥伴中有硬體開發者、嵌入式開發者、軟體發展者;有互聯網公司的全棧工程師、也有核電廠的工控系統維護者、還有路由器廠商的wifi協議開發者。

我們發現,世面上沒有開源且可商用的物聯網平臺或系統。這裡的可商用,不是搭建幾個demo把硬體連上網、app操作兩下這麼簡單。

有以下幾點都是必須著重考慮的:
  必須有完備的硬體、嵌入式、雲端一體的協議及架構設計;
  • 能夠實現真正的硬體智慧化,能夠基於資料學習並自主工作;
  • 必須有很高的性能、穩定性及擴展性;
  • 必須能夠適應成千上萬種不同資源的硬體設備,從PC到手機、從計算資源極其有限的單片機到網路頻寬極其有限的控制器;
  • 必須能適應不同的網路場景,包括有線、wifi3g/4ggprs等;
  • 必須有很可靠的安全性;
  • 需要盡可能降低研發和生產成本。

在媒體和科技工作者都抱著物聯網是未來的觀點並翹首觀望時,我們決定啟動全套可商用物聯網系統的設計和研發,並在不久的將來,全部開源


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

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

協議
在一個物聯網系統中,協定是串通上下層的關鍵紐帶。在物聯網系統中,我們將協定分為兩大層:通信層和業務層。
通信層基本上是傳統網際網路的基礎設施,負責將資料在物聯網系統節點中的傳輸;
業務層分為兩層,底層是負責物聯網場景下資料交換格式的規範,上層是物聯網場景需要具體傳輸的業務資料規範。

通信層網路基礎架構目前已經非常成熟且通用,但是業務層協議目前還是種類繁多。可以確定的一點是,最終能在物聯網應用中稱霸的協議,一定也像網際網路時代的TCP/IP一樣是開放的、免費的。目前符合此特性並使用比較多的有XMPPMQTTCOAP等。

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

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

MQTT在協定設計時就考慮到不同設備的運算性能的差異,所以所有的協定都是採用二進位格式編解碼,並且編解碼格式都非常易於開發和實現。最小的資料包只有2個位元組,對於低功耗低速網路也有很好的適應性。有非常完善的QOS機制,根據業務場景可以選擇最多一次、至少一次、剛好一次三種消息送達模式。運行在TCP協定之上,同時支援TLSTCP+SSL)協議,並且由於所有資料通信都經過雲端,安全性得到了較好地保障。

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

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

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

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

在進行技術選型和架構設計時,我們也綜合考慮以上因素進行設計和實現:
採用go語言作為主要開發語言。go語言有著簡潔的語法,並且能夠很方便地進行高併發程式的開發,在高性能雲端運算系統的開發中有著得天獨厚的優勢。
採用microservice分散式架構。microservice架構能夠構建出更穩定、擴展性更好的分散式系統,也是目前分散式系統中最流行的架構方式。
使用docker降低運維成本。docker能夠方便地對系統就行升級和出錯回滾,保證了系統發佈時的穩定性。
對外介面採用REST風格進行設計。REST風格的介面便於升級和相容,並擁有非常易於理解的語義,降低開發者的學習門檻。
多副本部署。任何服務模組我們都保證同時至少有兩個運行實例,並根據服務發現機制自動進行負載和調度,以增加系統可用性。

大體的雲端架構如下圖:
目前我們的系統已經發佈到0.8.0版本,後續會在安裝和運維的便捷性上進行優化,並計畫在1.0版本時開源發佈。

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

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

安全
近些日子,各種廠商的物聯網設備紛紛傳出被黑的消息。從TCL到特斯拉,駭客都成功實現破解和隨意操控。和互聯網時代一樣,安全在物聯網目前的早期階段註定是容易被忽略的問題。為此我們也在設計系統時也沒有掉以輕心:
  • 所有接入層通信都採用tls進行加密,包括對app、業務伺服器的開放介面;
  • 使用者、設備關鍵資訊進行加密保存;
  • 針對設備有完善的使用者鑒權機制;
  • 針對互聯網安全場景的其他安全措施。

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

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

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

後續我們會逐漸開源發佈所有的系統設計和專案。我們希望更多的小夥伴一起為項目做貢獻,無論是提交issue,還是貢獻代碼。如果你對物聯網和開源技術有著和我們一樣的執著和愛好,歡迎關注或加入我們的開源項目

Hope we are not alone.


【作者介紹】文本由@攀多物聯 原創,攀多物聯致力於打造物聯網產品開發工具,提供一體化物聯網解決方案。歡迎參與Pando開源物聯網系統討論,QQ群:488074716

                                                                                                                                                                                                                            

沒有留言:

張貼留言