1 前言

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

2 背景

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

某個(gè)工程機(jī)械集團(tuán)，擁有10萬臺工程機(jī)械設(shè)備，

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

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

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

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

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

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

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

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

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

4 SCloud IOT架構(gòu)解析

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

圖1 SCloud IOT的定位

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

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

4.1架構(gòu)圖

圖2 SCloud IOT架構(gòu)圖

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

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

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

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

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

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

圖3 SCloud IOT數(shù)據(jù)接入?yún)f(xié)議

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

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

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

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

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

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

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

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

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

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

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

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

4.6平臺管理

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

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

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

4.7平臺SDK

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

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

4.8平臺安全

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

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

5 應(yīng)用案例

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

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

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

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

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

5.2 性能對比

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

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

表1 性能指標(biāo)對比

6 結(jié)束語

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

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

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

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

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

7 定制開發(fā)附圖

8 關(guān)注加私信 "技術(shù)大牛"