1 前言

有人說物聯(lián)網是引領信息技術的第三次浪潮。第一次浪潮是個人電腦的出現(xiàn)，開創(chuàng)了信息時代的第一次革命，此次浪潮成就了微軟、IBM等巨頭。第二次浪潮是以信息傳輸為特征的互聯(lián)網及移動互聯(lián)網，實現(xiàn)了計算機與人的聯(lián)通，此次浪潮成就了Google、Facebook，以及國內的BAT等巨頭。第三次浪潮是以信息感知為特征的物聯(lián)網，實現(xiàn)了物與物、人與物的全面聯(lián)通，這次浪潮還沒有形成寡頭，但是隨著傳感技術、通信技術以及大數(shù)據(jù)處理技術的發(fā)展，物聯(lián)網已經在公共事務管理、公共社會服務和經濟發(fā)展建設等領域中遍地開花，涉及到的行業(yè)也越來越多，如交通管理、節(jié)能環(huán)保、物流零售等。

2 背景

萬物互聯(lián)的時代正逐步到來，據(jù)權威報告預測，2020年全球物聯(lián)網連接的終端數(shù)將達到500億，數(shù)據(jù)呈現(xiàn)爆發(fā)式增長。這個數(shù)據(jù)究竟有多大呢？舉個典型的例子：

某個工程機械集團，擁有10萬臺工程機械設備，

每臺設備上的采集終端每隔10秒上傳一次數(shù)據(jù)，每條數(shù)據(jù)大小1K，

一年的數(shù)據(jù)量為365天*8.6億=3000億，

一年占用的存儲為3000億*1K=300TB。

我們通常為了保證高可用，會對數(shù)據(jù)做3份冗余存儲，也就是說，這樣一個企業(yè)一年的數(shù)據(jù)存儲量就可以達到1PB，而1PB就相當于50個國家圖書館的總信息量。

物聯(lián)網的數(shù)據(jù)中蘊含的價值也是非常高的，比如：利用車載終端上傳的數(shù)據(jù)，可以提前預測群體出行的時間、方式和路線，可以為城市車輛調度提供決策幫助；在工業(yè)設備上安裝的傳感器，實時收集工業(yè)設備的使用狀況，可以進行設備診斷、能耗分析、質量事故分析等；通過各種環(huán)保傳感器采集的數(shù)據(jù)，可以輔助空氣質量改善、水污染控制等。

3 傳統(tǒng)架構的瓶頸

面對如此海量的物聯(lián)網數(shù)據(jù)，傳統(tǒng)技術架構已經難以應對。

首先，傳統(tǒng)架構都嚴重依賴于關系型數(shù)據(jù)庫，而關系型數(shù)據(jù)庫的索引結構基本上都是類B 樹，隨著終端數(shù)量增大，數(shù)據(jù)庫讀寫壓力劇增，讀寫延遲增大，數(shù)據(jù)庫面臨崩潰。其次，難以支持海量數(shù)據(jù)的存儲，傳統(tǒng)數(shù)據(jù)庫無法水平擴展，所以擴容成本非常高，難以滿足PB/EB級數(shù)據(jù)的讀取和寫入。最后，難以進行大規(guī)模數(shù)據(jù)處理，傳統(tǒng)情況下依賴數(shù)據(jù)庫的SQL或者存儲過程來進行數(shù)據(jù)分析的模式，無法對數(shù)據(jù)做分布式處理，經常一個SQL能把整個數(shù)據(jù)庫拖垮。

為了能夠把眾多行業(yè)的物聯(lián)網大數(shù)據(jù)價值發(fā)揮出來，視云智慧推出了一個企業(yè)級的物聯(lián)網大數(shù)據(jù)平臺。

4 SCloud IOT架構解析

那么SCloud IOT到底是什么呢？它是一個面向物聯(lián)網的開放的數(shù)據(jù)處理平臺，涵蓋了數(shù)據(jù)接入、計算、存儲、交換和管理。用戶基于這個平臺，可以很輕松地打造自己的物聯(lián)網解決方案。下圖可以展現(xiàn)出SCloud IOT的定位：

圖1 SCloud IOT的定位

SCloud IOT主要是為了解決什么問題呢？下面的這幾個都是典型的物聯(lián)網應用場景：

• 物聯(lián)網安全，解決了從數(shù)據(jù)接入到最終展現(xiàn)給用戶的每個環(huán)節(jié)的安全防護；
• 實時接入，解決了百萬級別的物聯(lián)網終端，以很高的頻率發(fā)送的數(shù)據(jù)能夠實時的接入到系統(tǒng)中；
• 當前狀態(tài)，解決了在百萬級別的物聯(lián)網終端中，快速地獲取到某個終端的當前的狀態(tài)；
• 歷史狀態(tài)，解決了在百萬級別的物聯(lián)網終端中，快速地獲取到某個終端在過去的某個時間段內的狀態(tài)參數(shù)；
• 下發(fā)指令，解決了如何給一個或者多個物聯(lián)網終端下發(fā)指令，從而可以實現(xiàn)遠程控制和參數(shù)調校等。

4.1架構圖

圖2 SCloud IOT架構圖

最底層是設備層，可以全部采用X86通用服務器，無需采購小型機等昂貴的計算設備和高端存儲設備，從整體上可以大幅拉低成本。

最上層是業(yè)務層，主要是物聯(lián)網的各種應用和第三方系統(tǒng)。業(yè)務層無需對數(shù)據(jù)進行處理和分析，只是通過查詢接口獲取到平臺層中已經處理過的數(shù)據(jù)并在界面進行展示。

中間的這一層就是TIZA STAR, 包含了數(shù)據(jù)接入服務、數(shù)據(jù)存儲服務、數(shù)據(jù)計算服務（包括實時計算和離線計算）、監(jiān)控報警服務、平臺管理服務、數(shù)據(jù)交換服務。下面會對每個模塊詳細介紹。

4.2數(shù)據(jù)接入

數(shù)據(jù)接入時，傳感器或者采集終端通過無線或者有線的方式發(fā)送到平臺端，平臺端通過軟負載均衡(LVS)或者硬負載均衡(F5等)將流量均勻的負載到各個可水平擴展的網關，每個網關都是基于netty實現(xiàn)的高性能的網絡接入程序。

數(shù)據(jù)接入協(xié)議分兩個層次，在通訊層次上，支持TCP、UDP、HTTP和WEBSOCKET等通訊協(xié)議；在數(shù)據(jù)協(xié)議層次上，支持MQTT、JSON、SOAP和自定義二進制協(xié)議。通過這兩個層次的互相搭配，可以輕松實現(xiàn)任何物聯(lián)網終端、任何協(xié)議的數(shù)據(jù)接入。

圖3 SCloud IOT數(shù)據(jù)接入協(xié)議

網關接收到數(shù)據(jù)，并完成解包之后，將數(shù)據(jù)包發(fā)送到消息中間件中，可以有效地應對“井噴流量”和下游服務短暫不可用的問題。在消息中間件的選擇上，我們比較了Kafka、RabbitMQ和ActiveMQ，最后選擇了Kafka，因為在分布式環(huán)境下Kafka的吞吐性能非常優(yōu)秀，并且其持久化和訂閱/發(fā)布的功能與物聯(lián)網的場景非常匹配。

4.3數(shù)據(jù)存儲

TIZA STAR綜合使用了多種存儲引擎，包括HDFS、HBase、RDBMS和Redis。其中HDFS非常適合于非結構化數(shù)據(jù)的存儲，支持數(shù)據(jù)的備份、恢復和遷移，在系統(tǒng)中主要用于存儲原始數(shù)據(jù)和需要進行離線分析的數(shù)據(jù)。

• HBase適合于存儲半結構化的數(shù)據(jù)，可以很好的支持海量物聯(lián)網終端的歷史數(shù)據(jù)的查詢，在系統(tǒng)中主要用于存儲終端的歷史軌跡和狀態(tài)等體量比較大的數(shù)據(jù)。
• RDBMS適合于存儲結構化的數(shù)據(jù)，通常根據(jù)具體的數(shù)據(jù)庫采用不同的高可用部署方案，在系統(tǒng)中主要用來存儲終端基礎數(shù)據(jù)、字典數(shù)據(jù)和數(shù)據(jù)分析的結果等。
• Redis是基于內存的KV數(shù)據(jù)庫，在系統(tǒng)中通常用來緩存需要頻繁更新和訪問的數(shù)據(jù)，比如物聯(lián)網終端的當前狀態(tài)等。在多種KV數(shù)據(jù)庫中我們最后選擇了Redis，主要是看重Redis為多種數(shù)據(jù)類型以及多種數(shù)據(jù)操作提供了很好的內嵌支持。

4.4數(shù)據(jù)處理

數(shù)據(jù)處理包括實時計算和離線計算兩種。

實時計算我們比較了Storm和Spark-streaming，最后選擇了Storm，主要考慮兩點：一方面是因為Storm的實時性更好一些，另一方面是因為在物聯(lián)網的場景中需要支持對終端數(shù)據(jù)的全局分組，而Spark-streaming只能在每個RDD中做分組。所以最后我們選擇了Storm作為我們的實時處理引擎，在它的基礎上我們包裝了自己的實時計算服務，可以支持應用層的調度和管理?；趯崟r計算服務可以很容易實現(xiàn)對物聯(lián)網數(shù)據(jù)的清洗、解析、報警等實時的處理。

離線計算目前支持MapReduce和Hive，對Spark的支持也正在進行中，主要用于對物聯(lián)網數(shù)據(jù)做日/周/月/年等多個時間維度做報表分析和數(shù)據(jù)挖掘，并將結果輸出到關系數(shù)據(jù)庫中。

4.5數(shù)據(jù)交換接口

數(shù)據(jù)交換接口主要是為了簡化應用層與平臺層之間的數(shù)據(jù)訪問而抽象了一層訪問接口，有了這層接口，應用層就不需要直接調用Hadoop、HBase等原生API，可以快速地進行應用開發(fā)。

目前數(shù)據(jù)交換接口支持：SQL、Restful、Thrift和Java API，用戶可以根據(jù)實際情況靈活選擇數(shù)據(jù)交換的方式。

數(shù)據(jù)交換的內容包括：物聯(lián)網終端的當前狀態(tài)、物聯(lián)網終端的歷史狀態(tài)/軌跡、指令下發(fā)、數(shù)據(jù)訂閱與發(fā)布等等。

4.6平臺管理

平臺管理包括監(jiān)控報警和管理UI。

監(jiān)控報警我們是用Ganglia和Nagios配合來做的，從三個級別來做：硬件級別（服務器、cpu、內存、磁盤等）、進程級別（進程不存在、端口監(jiān)聽異常等）、關鍵業(yè)務指標（中間隊列的元素數(shù)、網關建立的tcp連接數(shù)等）

管理UI包括界面化安裝部署、用戶管理、終端管理、集群管理、數(shù)據(jù)接入管理、實時和離線計算任務界面化管理。

4.7平臺SDK

平臺SDK是為了方便企業(yè)用戶基于TIZA STAR定制自己的物聯(lián)網應用，我們提供了三個SDK：GW-sdk、RP-sdk、OP-sdk。

• 其中基于GW-sdk可以快速新增一種新的物聯(lián)網終端協(xié)議的接入。
• 基于RP-sdk可以快速開發(fā)一整條實時處理鏈，也可以快速開發(fā)處理鏈中的某個模塊。
• 基于OP-sdk可以快速開發(fā)一個可周期性調度的MapReduce/Spark任務。

4.8平臺安全

物聯(lián)網安全也日益重要，前段時間發(fā)生的私家車被惡意遠程控制的事件就體現(xiàn)出了物聯(lián)網安全的重要性。TIZA STAR從鏈路安全、接入安全、網絡安全、存儲安全和數(shù)據(jù)防篡改這幾個方面來保證物聯(lián)網安全。

• 通過SSL和TLS保證鏈路安全；
• 通過秘鑰鑒權對數(shù)據(jù)的訪問有效進行控制；
• 通過防火墻等硬件設備防止網絡攻擊；
• 通過副本冗余保證數(shù)據(jù)的存儲安全；
• 通過每512字節(jié)進行CRC校驗的機制保證數(shù)據(jù)的防篡改。

5 應用案例

5.1數(shù)據(jù)流

接下來我們以車聯(lián)網為例，看一下TIZA STAR的數(shù)據(jù)流。

圖4 車聯(lián)網數(shù)據(jù)流

如圖4所示，物聯(lián)網終端通過無線/有線網絡發(fā)送到SCloud IOT平臺，經過一系列的處理后存入到各種存儲引擎中，業(yè)務可以通過數(shù)據(jù)交換接口來訪問處理后的數(shù)據(jù)。具體流程如下：

1. 車載設備或者傳感器設備通過網絡經過LVS/F5負載均衡將數(shù)據(jù)發(fā)送至網關；
2. 網關接收到數(shù)據(jù)后進行公共協(xié)議解析，然后把解析后的數(shù)據(jù)發(fā)給Kafka，存放在原始數(shù)據(jù)Topic；
3. 實時計算任務從原始數(shù)據(jù)Topic中讀取數(shù)據(jù)經過數(shù)據(jù)清洗后發(fā)送至原始數(shù)據(jù)解析模塊；
4. 原始數(shù)據(jù)解析模塊將解析出來的車輛的參數(shù)發(fā)送至Kafka解析數(shù)據(jù)Topic。然后將解析后的數(shù)據(jù)發(fā)送至報警判斷模塊；
5. 報警判斷模塊根據(jù)已有規(guī)則進行預警，并將產生的結果分別發(fā)送至Kafka的報警數(shù)據(jù)Topic，同時把解析后的數(shù)據(jù)發(fā)送至當前狀態(tài)分析模塊；
6. 當前狀態(tài)分析模塊對車輛當前狀態(tài)進行分析，如果狀態(tài)有變化則更新至Redis；
7. 數(shù)據(jù)導入模塊異步的將Kafka中的數(shù)據(jù)分別導入HBase和HDFS；
8. 離線計算則周期性地從HDFS中讀取數(shù)據(jù)進行各種報表分析和數(shù)據(jù)挖掘；
9. 用戶業(yè)務平臺和管理平臺可通過數(shù)據(jù)交換接口訪問SCloud IOT平臺數(shù)據(jù)。

5.2 性能對比

表1是視云智慧為某個大型工程機械集團做的平臺升級前后的性能指標對比情況，其中老平臺是傳統(tǒng)的基于IOE的解決方案，硬件環(huán)境包括IBM的小型機、EMC的存儲和Oracle RAC，新平臺是基于SCloud IOT的解決方案，使用的硬件是30臺左右X86架構服務器，服務器中自帶存儲。

該工程機械集團注冊終端數(shù)接近15萬，每個終端分布在全國各地，每隔30秒發(fā)送一條數(shù)據(jù)到平臺，上傳的數(shù)據(jù)包含工程機械設備的位置、工況等信息，該企業(yè)會對上報的數(shù)據(jù)進行分析，用于生產、經營的改善。

表1 性能指標對比

6 結束語

從研發(fā)到正式商用，耗時一年半， SCloud IOT經歷了三個階段：

第一個階段是封閉研發(fā)階段。SCloud IOT平臺最初的研發(fā)緣于公司一個客戶的迫切需求，原有的數(shù)據(jù)平臺隨著業(yè)務量擴大，性能捉襟見肘，經常出現(xiàn)宕機的情況，已經無法支撐正常的業(yè)務需求。為了更好的為客戶服務，我們決定對老平臺進行升級，目標是用業(yè)界最新的大數(shù)據(jù)技術來解決老平臺的性能問題。經過半年多的時間，我們發(fā)布了新平臺，為了不影響客戶業(yè)務的正常開展，決定新老平臺同時運行。幾個月后，經過對比，新平臺在性能、高可用性、可運維性等方面都完勝老平臺。

第二個階段是拓展階段。SCloud IOT平臺在第一個客戶成功上線后，公司開始在物聯(lián)網的諸多領域推廣這個產品，但推廣的過程不是很順利。一方面，由于目前物聯(lián)網領域還沒有一個統(tǒng)一的標準，不同企業(yè)、不同物聯(lián)網終端都有自己的非標協(xié)議，我們在數(shù)據(jù)接入、協(xié)議解析、存儲方面都要進行不同程度的定制。另一方面，隨著上線的案例越來越多，我們原來的平臺架構也暴露出很多問題，針對這些問題，我們做了很多調整，比如將網絡通訊組件由Mina替換成Netty，引入了KV數(shù)據(jù)庫，對Hadoop、Hbase和Kafka等進行了大版本的升級。在這個階段，雖然SCloud IOT平臺在不同的行業(yè)都有成功案例，但團隊做的還是很辛苦。于是把物聯(lián)網平臺進行封裝以滿足大多數(shù)場景的需求就顯得迫在眉睫，SCloud IOT的產品化就此應需而生。

第三個階段是產品化階段。在此階段，我們對數(shù)據(jù)接入、計算、存儲、交換等各個環(huán)節(jié)進行了封裝；累計開發(fā)了超過100種行業(yè)協(xié)議；抽象出了3個SDK，便于用戶基于平臺定制自己的新協(xié)議和業(yè)務處理模塊；完善了監(jiān)控和報警，形成一個完整的運維閉環(huán)；實現(xiàn)了安裝部署、管理和運維的界面化操作；提供了標準版和簡化版來滿足不同規(guī)模的客戶需求。經歷了半年多努力，SCloud IOT平臺終于實現(xiàn)了產品化。

在產品迭代的過程中，我們經歷過產品初次上線成功的喜悅，也經歷過產品拓展過程中的迷茫。項目組也從最初的五六人，到幾十個人初具規(guī)模的研發(fā)團隊。目前，SCloud IOT平臺正式注冊了商標，申請了軟件著作權和四項物聯(lián)網大數(shù)據(jù)領域的發(fā)明專利，產品在各個方面都有非常大的提升，希望今后可以給更多的企業(yè)提供物聯(lián)網平臺端解決方案。

7 定制開發(fā)附圖

8 關注加私信 "技術大牛"