轻量级数据采集平台架构设计探讨

胡金龙 胡向涛 宋啸天

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 结束语

轻量级数据采集平台架构设计在满足基本数据采集的前提下解决了商业化数据采集平台（产品）普遍存在的部署和维护复杂的问题。在实际落地过程中，虽然需要技术团队逐渐完成搭建工作，但是诸多开源产品的应用已经大幅度降低了技术门槛。基础平台一旦搭建完毕，即可根据实际业务需求进行横向和纵向扩展。系统架构中的多级分层设计也为平台模块化提供了基础，可以作为从事物联网产品、大数据产品、智慧监控产品等产品研发公司的基础数据采集平台架构。