1 前言

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

2 背景

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

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

每臺設備上的採集終端每隔10秒上傳一次數據，每條數據大小1K，

一年的數據量為365天*8.6億=3000億，

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

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

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

3 傳統架構的瓶頸

面對如此海量的物聯網數據，傳統技術架構已經難以應對。

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

為了能夠把眾多行業的物聯網大數據價值發揮出來，視雲智慧推出了一個企業級的物聯網大數據平臺。

4 SCloud IOT架構解析

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

圖1 SCloud IOT的定位

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

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

4.1架構圖

圖2 SCloud IOT架構圖

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

最上層是業務層，主要是物聯網的各種應用和第三方系統。業務層無需對數據進行處理和分析，只是通過查詢接口獲取到平臺層中已經處理過的數據並在界面進行展示。

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

4.2數據接入

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

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

圖3 SCloud IOT數據接入協議

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

4.3數據存儲

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

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

4.4數據處理

數據處理包括實時計算和離線計算兩種。

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

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

4.5數據交換接口

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

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

數據交換的內容包括：物聯網終端的當前狀態、物聯網終端的歷史狀態/軌跡、指令下發、數據訂閱與發佈等等。

4.6平臺管理

平臺管理包括監控報警和管理UI。

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

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

4.7平臺SDK

平臺SDK是為了方便企業用戶基於TIZA STAR定製自己的物聯網應用，我們提供了三個SDK：GW-sdk、RP-sdk、OP-sdk。

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

4.8平臺安全

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

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

5 應用案例

5.1數據流

接下來我們以車聯網為例，看一下TIZA STAR的數據流。

圖4 車聯網數據流

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

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

5.2 性能對比

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

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

表1 性能指標對比

6 結束語

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

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

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

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

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

7 定製開發附圖

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

閱讀更多 大數據java架構師 的文章

關鍵字: 軟件 美好，一直在身邊 Goog