輕量級數據采集平臺架構設計探討

胡金龍 胡向濤 宋嘯天

1.江蘇運聯信息股份有限公司；2.鎮江市潤清苑管理服務中心；3.鎮江市審計局

0 引言

基礎數據采集的應用場景無處不在，雖然不同應用場景的特點各不相同，但是基本上都具有采集數據量大、并發量大、數據類型繁多等特點，因此對數據采集平臺的吞吐量、穩定性和可擴展性有著非常高的要求。也正是這些特點，使得數據采集平臺與傳統的數據上報系統在技術方案和架構上有著本質的區別。

目前市面上的數據采集方案很多，IBM、Intel等公司都早已推出自己的商業化數據采集產品，面向物聯網、大數據平臺以及其他應用場景。然而大部分成熟的產品往往部署復雜、成本較高，用來解決基礎數據的采集工作成本較高，對于維護團隊來說技術難度也較大。輕量級數據采集平臺與終端（節點）之間通過http進行數據傳輸，使其管理和接入更加方便，應用場景也更加多樣化，能夠適用于大部分常見的數據采集以及部分物聯網和大數據采集，可以快速與現有數據采集平臺進行整合。因此，設計一套適用于多種場景的輕量級數據采集平臺是十分必要的。

1 技術架構設計

1.1 整體架構設計

數據采集平臺屬于應用系統的基礎平臺，其穩定性是上層應用能夠正常運行的關鍵所在。由于采集數據的種類多、數據量大、業務處理復雜，在架構設計的過程中需要充分考慮其可靠性、擴展性和負載能力。

在技術架構設計過程中，選用API網關方式來提高平臺的可靠性，通過API網關的分布式部署以及處理節點的負載均衡可保證系統在單一（或多個）節點故障情況下能夠正常運行。在負載方面則通過處理節點的負載均衡和增加中間件緩沖來進一步提高負載能力。API網關以及中間件的應用也使得整個平臺具備良好的可擴展性（業務擴展和負載能力擴展）。

平臺整體架構可分為6個層次，分別為：數據采集層、數據傳輸控制層、數據緩沖區、業務處理層、數據存儲層和應用層，如圖1所示。

圖1 系統整體架構

（1）數據采集層

數據采集層負責基礎數據采集。數據采集點可以是平臺提供的數據采集代理（如定時數據抓取服務、心跳檢測服務等），也可以是其他系統或第三方數據采集器。數據采集層通過底層協議采集到有效數據，隨后訪問API網關，將數據傳輸至數據采集平臺。

（2）數據傳輸控制層

數據傳輸控制層向數據采集點提供數據采集API網關，用以接收各個數據采集點上傳的數據。API網關除了具備數據接收功能外，還具備節點訪問控制功能和預處理功能。由于數據采集點數量和傳輸數據量較大，API網關同時具備負載均衡能力，通過多節點配置提高數據接收的吞吐量和系統穩定性。

（3）數據緩沖區

考慮到數據采集量巨大的問題，當數據傳輸層接收到合法數據后直接存放至緩沖區，但不進行業務處理，以降低大量并發情況下的服務器負載。同時，為保證數據的可靠性，在緩沖區需要對數據進行持久化處理。

（4）業務處理層

業務處理層負責緩沖區數據處理。在業務處理層分布著針對不同類型業務數據的處理節點。處理節點監聽緩沖區數據，自動篩選出各自需要處理的業務數據并分別處理。同一種類型數據也可由多個業務數據處理節點協同處理。

（5）數據存儲層

數據存儲層主要用于存儲處理后的數據。根據業務處理層的處理規則以及數據類型，分別將數據存儲至不同類型的數據庫或存儲介質，如關系型數據庫、非關系型數據庫、Topic、HDFS等。

（6）應用層

根據實際業務需要，應用層可以訪問數據存儲層所有業務數據，實現正常的業務處理，如大數據分析、預警信息推送等。并且同一種類型的應用也可以并行訪問多種數據源。

1.2 技術選型

針對以上技術架構，在技術選型方面，遵循輕量級、開源和穩定三個基本原則，從眾多技術框架中篩選出核心技術框架。

1.2.1 數據傳輸控制層

（1）API網關

選用KONG作為數據采集平臺的API網關。KONG是一個可擴展的開源API層（也稱為API網關或API中間件）。KONG運行在RESTful API之前，并可通過官方提供的第三方插件進行擴展，也可自定義插件進行用戶定制的功能擴展。通過插件可使其提供核心平臺以外的功能和服務，如數據統計、用戶身份驗證，API授權等。除此之外，KONGA（第三方開源框架）提供了一套用以配置和管理KONG的輕量級管理系統，尤其是其提供的dashboardDASH功能，更是提供了一個監控KONG運行狀態的工具。KONGA的配置管理界面如圖2所示。

圖2 KONGA管理頁面

（2）預處理節點

數據預處理節點選擇SpringBoot，快速搭建數據預處理RESTful API接口。SpringBoot可以與KONG完美結合，同時可以結合swagger，提供API查看及測試功能，提高接口文檔的可維護性，如圖3所示。

圖3 swagger API查看頁面

1.2.2 數據緩沖區

數據緩沖區選用ActiveMQ作為消息中間件。ActiveMQ是Apache下的開源消息中間件，除了基本的Queue（點對點模式）和Topic（發布/訂閱模式）功能外，還具備負載均衡和多種方式的持久化功能，保證其負載能力和可靠性。

1.2.3 數據存儲層

根據實際業務數據特點，數據存儲層采用多種結構的數據存儲方式。其中：

（1）關系型數據

采用MYSQLmysq數據庫存儲關系型數據。

（2）基礎數據

采用MongoDB、Hive存儲基礎數據，MongoDB和Hive均為NoSql數據庫。

（3）Topic數據

采用ActiveMQ作為消息中間件，與緩沖區技術選型相同。

（4）其他類型數據

其他類型數據均存放在HDFS上，以便進行數據訪問和數據分析。

1.3 部署方案

基于上述技術架構和技術選型，在整體平臺部署過程中，除數據采集節點和API網關必須置于互聯網外，其他各層、組件均可部署至內網，但是相鄰層組件之間需要保持網絡的連通性。

平臺架構中各組件基本部署結構如圖4所示。

圖4 部署結構示意

（1）數據采集代理

數據采集代理部署于具備訪問采集對象能力的網絡環境中，并且能夠通過互聯網方式訪問API網關，數據采集節點的部署數量根據實際采集對象的數量確定。

（2）KONG集群

KONG部署于防火墻內部，集群節點數量根據實際平臺負載確定，原則上應不少于2個節點。同時，不同節點需要分別部署在不同的服務器中。

（3）KONGA

KONGA僅需單機部署，用于管理KONG以及相關API。

（4）處理節點集群

處理節點集群中節點數量原則上不少于2個，可分別部署于不同的服務器中，具體數量依據實際采集負載和配備服務器處理能力確定。集群中不同節點通過KONG實現負載均衡。

（5）MQ集群

MQ集群與處理節點集群保持連通，集群節點數量原則上不少于2個。

（6）業務處理層

業務處理層不同節點負責處理不同類型的業務數據。業務處理層需要保持與MQ集群以及持久層的網絡連通。根據實際情況，業務處理層不同節點可部署于相同服務器，也可以部署于不同服務器。

（7）持久層

持久層中持久化的類型以及集群部署的方案根據實際業務需求確定。

（8）應用層

根據實際情況部署，應用層直接訪問持久層和MQ集群，原則上不直接與其他組件通信。

2 數據交換協議設計

為了使數據采集平臺具有較高的可擴展性，在數據交換協議設計方面，采用較松散和易于擴展的數據交換協議，基本流程如圖5所示。

“數據上傳”和“TOKEN獲取”是數據交換流程中最重要的兩個環節。當數據采集點向數據采集平臺發送數據時，除了封裝基礎的數據包外，還需要攜帶特定的TOKEN信息，以實現對合法數據采集點的識別和特殊處理。在交互接口方面，本文僅對“數據上傳”和“TOKEN獲取”接口進行描述。

圖5 數據交換流程

2.1 傳輸方式約定

（1）數據傳輸方式：統一采用HTTP方式；

（2）數據格式：響應結果統一使用JSON；

（3）編碼格式：統一使用“UTF-8”。

2.2 數據請求規則

（1）攜帶COOKIE

除TOKEN獲取請求外的任意請求都必須在HTTP請求頭中加入認證信息，關鍵字為“Authorization”，并在內容中注明認證方式為“Basic”。

（2）數據校驗

數據上傳時，需要對有效數據包進行校驗，以防止數據傳輸過程中出現丟包，避免出現不完整數據處理異常和篡改數據等問題。

（3）數據格式

為使平臺數據采集類型具備較高的可擴展性，在數據上傳過程中需使用統一的數據格式，其中“devtype”和“msgtype”可作為業務擴展的關鍵，基本結構如圖6所示。

圖6 統一的請求格式示例

2.3 響應結果格式

響應結果均以JSON的形式返回，主要包括處理狀態和響應碼信息，以便使采集代理能夠對數據上傳成功情況進行判斷。若有具體響應內容，則需要將其統一存放在某一數據節點，如圖7所示。

2.4 示例

2.4.1 數據采集示例

圖7 統一請求響應格式示例

TOKEN獲取接口請求示例如圖8所示。

圖8 TOKEN獲取接口示例

數據上傳接口示例如圖9所示。

圖9 數據上傳接口示例

2.4.2 業務擴展示例

通過上述技術架構和數據交換協議約定，當平臺需要進行業務擴展時，只需在以下兩個環節進行配置。

（1）數據采集代理

在數據采集代理上傳數據時，根據實際數據類型以及業務類型設置“devtype”和“msgtype”。當預處理節點接收到上傳的數據后，根據“devtype”確定將收集到的消息存放至預制對應的Queue中，同時為消息設置“msgtype”屬性。例如：將 “devtype”設置為 “gate”，將 “msgtype”設置為 “info”。

（2）業務數據處理

在業務處理層重新創建一個業務處理，監聽MQ集群 中 名 稱 為 “gate”的 Queue， 并 且 設 置 “selector”為“msgtype=info”，業務處理節點即可接收到所有符合條件的消息，按照業務規則進行處理。

3 架構特點概述

（1）輕量級、低成本

數據采集平臺采用較松散的技術架構，所有技術選型均使用開源技術，開發及部署方式簡單，可以直接部署在物理機、虛擬機以及Docker容器中，研發人員可以快速適應開發，搭建整套集成開發平臺的成本相對較低。

（2）協議簡單、靈活

數據傳輸協議采用簡單的HTTP協議，數據采集過程中僅用到“TOKEN獲取”和“數據上傳”兩個接口，避免了大量的開發工作。靈活的數據交換協議足以支持所有類型的基礎數據采集，也可以為不同類型的數據分別定義不同的數據上傳接口，使其數據處理和解析難度大幅度降低。

（3）高內聚、低耦合

模塊（層）間功能及職能聚合程度較高，不同模塊（層）之間通過中間件或松散協議、介質進行交互，保持較高的獨立性，降低耦合性，從而降低維護的復雜程度。

（4）易于擴展

松散的架構設計使其具備較高的可擴展性。擴展主要包含兩個方面：一是吞吐量。吞吐量的擴展可以通過增加API網關后的預處理節點以及API網關自身負載均衡實現。同時，隊列、Topic、數據庫以及應用處理節點也可以通過增加節點的方式提高負載能力。二是業務類型。業務類型的擴展可以通過擴展數據采集節點和業務處理層節點實現。根據需要采集數據的節點特點，定制數據采集代理，將其封裝成符合數據上傳接口協議的數據包，并由特定的業務處理模塊處理。

4 應用場景

（1）物聯網數據采集

適用于大部分雙向交互較少的物聯網數據采集場景，如環境監測、傳感器狀態監測等。物聯網采集終端與服務端之間網絡連接時間較短，數據交互協議簡單，開發成本較低，終端自身資源消耗也較少。

（2）互聯網設備監控數據采集

大部分互聯網設備都提供了標準的數據采集接口，如SNMP、ICMP等協議。在數據采集平臺中，根據設備提供的協議標準開發特定的數據采集代理，并通過API網關實現數據上傳，即可快速實現互聯網設備監控數據的采集。

（3）大數據采集

大數據分析過程包含數據抓取和數據清洗的過程，在此過程中，數據抓取或數據清洗可以看作是數據采集平臺中的數據采集代理。尤其是通過網絡爬蟲或其他途徑抓取的數據，可以為其定義獨立的業務數據處理節點，并將處理結果存放至特定存儲介質中。

5 結束語

輕量級數據采集平臺架構設計在滿足基本數據采集的前提下解決了商業化數據采集平臺（產品）普遍存在的部署和維護復雜的問題。在實際落地過程中，雖然需要技術團隊逐漸完成搭建工作，但是諸多開源產品的應用已經大幅度降低了技術門檻。基礎平臺一旦搭建完畢，即可根據實際業務需求進行橫向和縱向擴展。系統架構中的多級分層設計也為平臺模塊化提供了基礎，可以作為從事物聯網產品、大數據產品、智慧監控產品等產品研發公司的基礎數據采集平臺架構。