輕量級數(shù)據(jù)采集平臺架構(gòu)設(shè)計探討

胡金龍 胡向濤 宋嘯天

1.江蘇運聯(lián)信息股份有限公司；2.鎮(zhèn)江市潤清苑管理服務(wù)中心；3.鎮(zhèn)江市審計局

0 引言

基礎(chǔ)數(shù)據(jù)采集的應(yīng)用場景無處不在，雖然不同應(yīng)用場景的特點各不相同，但是基本上都具有采集數(shù)據(jù)量大、并發(fā)量大、數(shù)據(jù)類型繁多等特點，因此對數(shù)據(jù)采集平臺的吞吐量、穩(wěn)定性和可擴展性有著非常高的要求。也正是這些特點，使得數(shù)據(jù)采集平臺與傳統(tǒng)的數(shù)據(jù)上報系統(tǒng)在技術(shù)方案和架構(gòu)上有著本質(zhì)的區(qū)別。

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

1 技術(shù)架構(gòu)設(shè)計

1.1 整體架構(gòu)設(shè)計

數(shù)據(jù)采集平臺屬于應(yīng)用系統(tǒng)的基礎(chǔ)平臺，其穩(wěn)定性是上層應(yīng)用能夠正常運行的關(guān)鍵所在。由于采集數(shù)據(jù)的種類多、數(shù)據(jù)量大、業(yè)務(wù)處理復雜，在架構(gòu)設(shè)計的過程中需要充分考慮其可靠性、擴展性和負載能力。

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

平臺整體架構(gòu)可分為6個層次，分別為：數(shù)據(jù)采集層、數(shù)據(jù)傳輸控制層、數(shù)據(jù)緩沖區(qū)、業(yè)務(wù)處理層、數(shù)據(jù)存儲層和應(yīng)用層，如圖1所示。

圖1 系統(tǒng)整體架構(gòu)

（1）數(shù)據(jù)采集層

數(shù)據(jù)采集層負責基礎(chǔ)數(shù)據(jù)采集。數(shù)據(jù)采集點可以是平臺提供的數(shù)據(jù)采集代理（如定時數(shù)據(jù)抓取服務(wù)、心跳檢測服務(wù)等），也可以是其他系統(tǒng)或第三方數(shù)據(jù)采集器。數(shù)據(jù)采集層通過底層協(xié)議采集到有效數(shù)據(jù)，隨后訪問API網(wǎng)關(guān)，將數(shù)據(jù)傳輸至數(shù)據(jù)采集平臺。

（2）數(shù)據(jù)傳輸控制層

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

（3）數(shù)據(jù)緩沖區(qū)

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

（4）業(yè)務(wù)處理層

業(yè)務(wù)處理層負責緩沖區(qū)數(shù)據(jù)處理。在業(yè)務(wù)處理層分布著針對不同類型業(yè)務(wù)數(shù)據(jù)的處理節(jié)點。處理節(jié)點監(jiān)聽緩沖區(qū)數(shù)據(jù)，自動篩選出各自需要處理的業(yè)務(wù)數(shù)據(jù)并分別處理。同一種類型數(shù)據(jù)也可由多個業(yè)務(wù)數(shù)據(jù)處理節(jié)點協(xié)同處理。

（5）數(shù)據(jù)存儲層

數(shù)據(jù)存儲層主要用于存儲處理后的數(shù)據(jù)。根據(jù)業(yè)務(wù)處理層的處理規(guī)則以及數(shù)據(jù)類型，分別將數(shù)據(jù)存儲至不同類型的數(shù)據(jù)庫或存儲介質(zhì)，如關(guān)系型數(shù)據(jù)庫、非關(guān)系型數(shù)據(jù)庫、Topic、HDFS等。

（6）應(yīng)用層

根據(jù)實際業(yè)務(wù)需要，應(yīng)用層可以訪問數(shù)據(jù)存儲層所有業(yè)務(wù)數(shù)據(jù)，實現(xiàn)正常的業(yè)務(wù)處理，如大數(shù)據(jù)分析、預警信息推送等。并且同一種類型的應(yīng)用也可以并行訪問多種數(shù)據(jù)源。

1.2 技術(shù)選型

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

1.2.1 數(shù)據(jù)傳輸控制層

（1）API網(wǎng)關(guān)

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

圖2 KONGA管理頁面

（2）預處理節(jié)點

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

圖3 swagger API查看頁面

1.2.2 數(shù)據(jù)緩沖區(qū)

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

1.2.3 數(shù)據(jù)存儲層

根據(jù)實際業(yè)務(wù)數(shù)據(jù)特點，數(shù)據(jù)存儲層采用多種結(jié)構(gòu)的數(shù)據(jù)存儲方式。其中：

（1）關(guān)系型數(shù)據(jù)

采用MYSQLmysq數(shù)據(jù)庫存儲關(guān)系型數(shù)據(jù)。

（2）基礎(chǔ)數(shù)據(jù)

采用MongoDB、Hive存儲基礎(chǔ)數(shù)據(jù)，MongoDB和Hive均為NoSql數(shù)據(jù)庫。

（3）Topic數(shù)據(jù)

采用ActiveMQ作為消息中間件，與緩沖區(qū)技術(shù)選型相同。

（4）其他類型數(shù)據(jù)

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

1.3 部署方案

基于上述技術(shù)架構(gòu)和技術(shù)選型，在整體平臺部署過程中，除數(shù)據(jù)采集節(jié)點和API網(wǎng)關(guān)必須置于互聯(lián)網(wǎng)外，其他各層、組件均可部署至內(nèi)網(wǎng)，但是相鄰層組件之間需要保持網(wǎng)絡(luò)的連通性。

平臺架構(gòu)中各組件基本部署結(jié)構(gòu)如圖4所示。

圖4 部署結(jié)構(gòu)示意

（1）數(shù)據(jù)采集代理

數(shù)據(jù)采集代理部署于具備訪問采集對象能力的網(wǎng)絡(luò)環(huán)境中，并且能夠通過互聯(lián)網(wǎng)方式訪問API網(wǎng)關(guān)，數(shù)據(jù)采集節(jié)點的部署數(shù)量根據(jù)實際采集對象的數(shù)量確定。

（2）KONG集群

KONG部署于防火墻內(nèi)部，集群節(jié)點數(shù)量根據(jù)實際平臺負載確定，原則上應(yīng)不少于2個節(jié)點。同時，不同節(jié)點需要分別部署在不同的服務(wù)器中。

（3）KONGA

KONGA僅需單機部署，用于管理KONG以及相關(guān)API。

（4）處理節(jié)點集群

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

（5）MQ集群

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

（6）業(yè)務(wù)處理層

業(yè)務(wù)處理層不同節(jié)點負責處理不同類型的業(yè)務(wù)數(shù)據(jù)。業(yè)務(wù)處理層需要保持與MQ集群以及持久層的網(wǎng)絡(luò)連通。根據(jù)實際情況，業(yè)務(wù)處理層不同節(jié)點可部署于相同服務(wù)器，也可以部署于不同服務(wù)器。

（7）持久層

持久層中持久化的類型以及集群部署的方案根據(jù)實際業(yè)務(wù)需求確定。

（8）應(yīng)用層

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

2 數(shù)據(jù)交換協(xié)議設(shè)計

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

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

圖5 數(shù)據(jù)交換流程

2.1 傳輸方式約定

（1）數(shù)據(jù)傳輸方式：統(tǒng)一采用HTTP方式；

（2）數(shù)據(jù)格式：響應(yīng)結(jié)果統(tǒng)一使用JSON；

（3）編碼格式：統(tǒng)一使用“UTF-8”。

2.2 數(shù)據(jù)請求規(guī)則

（1）攜帶COOKIE

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

（2）數(shù)據(jù)校驗

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

（3）數(shù)據(jù)格式

為使平臺數(shù)據(jù)采集類型具備較高的可擴展性，在數(shù)據(jù)上傳過程中需使用統(tǒng)一的數(shù)據(jù)格式，其中“devtype”和“msgtype”可作為業(yè)務(wù)擴展的關(guān)鍵，基本結(jié)構(gòu)如圖6所示。

圖6 統(tǒng)一的請求格式示例

2.3 響應(yīng)結(jié)果格式

響應(yīng)結(jié)果均以JSON的形式返回，主要包括處理狀態(tài)和響應(yīng)碼信息，以便使采集代理能夠?qū)?shù)據(jù)上傳成功情況進行判斷。若有具體響應(yīng)內(nèi)容，則需要將其統(tǒng)一存放在某一數(shù)據(jù)節(jié)點，如圖7所示。

2.4 示例

2.4.1 數(shù)據(jù)采集示例

圖7 統(tǒng)一請求響應(yīng)格式示例

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

圖8 TOKEN獲取接口示例

數(shù)據(jù)上傳接口示例如圖9所示。

圖9 數(shù)據(jù)上傳接口示例

2.4.2 業(yè)務(wù)擴展示例

通過上述技術(shù)架構(gòu)和數(shù)據(jù)交換協(xié)議約定，當平臺需要進行業(yè)務(wù)擴展時，只需在以下兩個環(huán)節(jié)進行配置。

（1）數(shù)據(jù)采集代理

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

（2）業(yè)務(wù)數(shù)據(jù)處理

在業(yè)務(wù)處理層重新創(chuàng)建一個業(yè)務(wù)處理，監(jiān)聽MQ集群 中 名 稱 為 “gate”的 Queue， 并 且 設(shè) 置 “selector”為“msgtype=info”，業(yè)務(wù)處理節(jié)點即可接收到所有符合條件的消息，按照業(yè)務(wù)規(guī)則進行處理。

3 架構(gòu)特點概述

（1）輕量級、低成本

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

（2）協(xié)議簡單、靈活

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

（3）高內(nèi)聚、低耦合

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

（4）易于擴展

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

4 應(yīng)用場景

（1）物聯(lián)網(wǎng)數(shù)據(jù)采集

適用于大部分雙向交互較少的物聯(lián)網(wǎng)數(shù)據(jù)采集場景，如環(huán)境監(jiān)測、傳感器狀態(tài)監(jiān)測等。物聯(lián)網(wǎng)采集終端與服務(wù)端之間網(wǎng)絡(luò)連接時間較短，數(shù)據(jù)交互協(xié)議簡單，開發(fā)成本較低，終端自身資源消耗也較少。

（2）互聯(lián)網(wǎng)設(shè)備監(jiān)控數(shù)據(jù)采集

大部分互聯(lián)網(wǎng)設(shè)備都提供了標準的數(shù)據(jù)采集接口，如SNMP、ICMP等協(xié)議。在數(shù)據(jù)采集平臺中，根據(jù)設(shè)備提供的協(xié)議標準開發(fā)特定的數(shù)據(jù)采集代理，并通過API網(wǎng)關(guān)實現(xiàn)數(shù)據(jù)上傳，即可快速實現(xiàn)互聯(lián)網(wǎng)設(shè)備監(jiān)控數(shù)據(jù)的采集。

（3）大數(shù)據(jù)采集

大數(shù)據(jù)分析過程包含數(shù)據(jù)抓取和數(shù)據(jù)清洗的過程，在此過程中，數(shù)據(jù)抓取或數(shù)據(jù)清洗可以看作是數(shù)據(jù)采集平臺中的數(shù)據(jù)采集代理。尤其是通過網(wǎng)絡(luò)爬蟲或其他途徑抓取的數(shù)據(jù)，可以為其定義獨立的業(yè)務(wù)數(shù)據(jù)處理節(jié)點，并將處理結(jié)果存放至特定存儲介質(zhì)中。

5 結(jié)束語

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