分布式日志采集系统设计

代乾坤

摘要：应用系统的分布式部署已成为应用程序高扩展、高并发性能的必然要求。分布式应用系统部署为业务系统的监控带来一定的难题。基于全国芯片印章多中心模式部署现状，在调研现有日志采集系统的基础上，结合业务流程、数据特点，设计了一套高效可行的分布式日志采集系统。

关键词：分布式文件系统;非结构化存储;面向切面编程;消息中间件;SATA

中图分类号：TP311        文献标识码：A

文章编号：1009-3044（2019）17-0009-03

开放科学（资源服务）标识码（OSID）：

Abstract： Distributed deployment of application systems has become an inevitable requirement for high scalability and concurrent performance of applications. The deployment of distributed application system brings some difficulties to the monitoring of business system. Based on the current situation of multi-center mode deployment of chip seals in China， an efficient and feasible distributed log acquisition system is designed on the basis of investigating the existing log acquisition system and combining the business process and data characteristics.

Key words： distributed file system; unstructured storage;  message oriented middleware; SATA

1 引言

隨着信息技术的快速发展，系统日志数据呈现爆炸式的增长，且分布式系统部署为系统的业务及运行监控带来了一定的难题。为提升全国印章业芯片印章系统集成应用水平，设计了全国芯片印章多中心模式日志采集系统，为芯片印章发行业务的大数据分析提供基础数据。

目前系统日志的收集方式各异，并各有优缺点，比较常见的日志系统包括facebook的scribe，apache的chukwa，linkedin的kafka和cloudera的flume等[1]。以上日志采集方式对目前业务系统来讲，不能很好地与业务系统融合，当需要将这些日志系统整合到全国芯片印章业务系统时，需要做大量的整合工作，且业务代码层面也需要做出修改，因此基于现有全国芯片印章业务系统，构建开发了分布式日志采集系统。

2 关键技术

2.1 AOP切面编程

AOP（Aspect-Oriented Programming），其实是OOP（Object-Oriented Programing）思想的补充和完善。OOP引进抽象、封装、继承、多态等概念，对多样化的实体进行抽象和封装，并建立层次分明的实体对象，它强调建立一种自上而下的实体间的关系。当需要具体到每个实体内部的情况，OOP有些捉襟见肘，比如日志功能、权限控制。此类代码往往离散的分布在所有对象当中，却与它所在对象的核心功能无关，导致了大量代码的重复，不利于各个模块的重用。

AOP技术则恰恰相反，它利用一种称为“横切”的技术，能够剖解开封装的对象内部，并将那些影响了多个类并且与具体业务无关的公共行为封装成一个独立的模块（称为切面）。更重要的是，它又能以巧夺天工的妙手将这些剖开的切面复原，不留痕迹的融入核心业务逻辑中[2]。这样，对于日后横切功能的编辑和重用都能够带来极大的方便。

2.2 ActiveMQ消息中间件

消息队列对于如今的分布式系统，具有天然的优势，并逐渐发展为独立的中间件产品，采用异步通信具有逻辑的低耦合性、消息的顺序性、消息的可靠性、缓冲业务并发等优点。服务与服务间的通信采用消息队列模式，可以实现异步通信，降低服务间的耦合性[3]。消息队列可以将大量的高峰期请求数据存储起来慢慢回调业务模块进行处理，对于抢购、秒杀等业务极为重要，并且消息队列的顺序性也保证了先进先出的业务要求[4]。

ActiveMQ是Apache公司的产品，是目前比较流行的，能力强劲的开源消息总线。ActiveMQ是一个完全支持JMS1.1和J2EE 1.4规范的JMS Provider实现，尽管JMS规范出台已经很久，但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。ActiveMQ消息队列可配置两种模式，“生产者消费者”模式和“订阅发布”模式，两种模式的业务模型见图1和图2。

ActiveMQ生产者消费者模型就是在一个系统中，存在数据的生产者和消费者两种角色，生产者和消费者共用同一存储空间，生产者向空间里写入数据，而消费者取走数据[5]。生产者消费者模型可以有多个生产者及多个消费者，消息生产后只能由一个消费者消费，基于消息队列的存储-转发机制，能够基于消息传输和异步事务处理实现应用整合与数据交换。降低系统功能耦合性、提高业务并发处理能力。

在订阅发布模型中，生产者和消费者之间含有一个发布通道，此时通道可以理解为一个消息队列，消息队列从生产者接收消息，消费者向消息队列注册，消息队列把接收到的消息向注册后的消费者发布。订阅发布模型中，一条发布信息可以被多个已注册消费者消费。

2.3 非结构化存储

NoSQL，泛指非关系型的数据库。关系型数据库中，表都是存储格式化结构的数据，每个元组字段的组成都是一样的，即使不是每个元组都需要所有的字段，但数据库会为每个元组都分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系数据库性能瓶颈的一个因素[6]。而非关系数据库以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加或减少一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。

MongoDB是NoSql的一种，属于NoSql中的基于分布式文件存储的文档型数据库。由C++语言编写，旨在为WEB应用提供可扩展的高性能数据存储解决方案[6][7]。MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似json的BSON（类json的二进制形式的存储格式，简称Binary JSON）格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引[7][8]。

3 系统设计

分布式日志采集系統整体架构分为数据生产、数据缓存、数据消费、数据存储，由全国芯片印章业务系统输出日志数据，日志数据在业务系统中存储在消息中间件ActiveMQ中，ActiveMQ驱动消息服务发送消息到日志采集系统。日志采集系统提供数据接收接口，接收到的数据缓存到ActiveMQ中，可以提高日志接收能力。ActiveMQ驱动消息服务集群完成数据的转换、清洗并保存到非结构化数据库MongoDB中。

3.1 数据生产

分布式日志采集系统日志由业务系统的JBOSS产生，为了业务系统的最小代码改造，系统采用Spring的AOP对日志业务进行切面编程，采集到的日志数据发送给消息中间件进行存储。AOP切面的使用，简化了业务系统的改到难度，降低了系统的耦合性，对分布式日志采集系统的顺利部署上线提供了很大的帮助。

3.2 数据缓存

为了解决大量业务日志的输出对系统业务并发能力的影响，在业务系统将日志数据生产者产生的日志，发送到消息中间件进行缓存。采用消息队列的技术实现，提高了日志采集的性能和可靠性。消息中间件的使用，极大地降低了日志采集对主业务并发性能的影响。

当多个业务系统采集到的数据并发发送到日志采集系统后，大量的日志数据势必会对数据接收的吞吐量提出更高的要求，并可能造成来数据丢失。为了提高日志采集系统日志接收接口的性能，采用缓存层对接收到的数据进行缓存。缓存层采用开源消息队列中间件ActiveMQ实现。日志采集接收接口接收到的数据直接放入ActiveMQ中，提高了日志采集系统的数据接收能力。

3.3 数据消费

当ActiveMQ中有新的日志消息存储时，消息驱动Bean被调用，由消息驱动Bean完成对数据的发送，发送成功的数据由消息驱动Bean发送ACK给ActiveMQ，消息队列把数据标记为已发送状态，完成数据的发送。日志采集系统完成分布式日志的接收，接收到的数据首先缓存在ActiveMQ中，进一步由消息驱动Bean主动处理接收到的数据。

3.4 数据存储

日志数据为低价值的数据，使用传统的关系型数据库存储成本较高，并且随着日志数据的累计，性能会急剧下降。Mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。且MongoDB已经包含对大数据计算MapReduce引擎的内置支持，为日志的大数据分析计算提供便利。MongoDB的分片部署，非常适合服务器的横向伸缩，且分布式文件系统自身的安全机制，可以采用较为廉价的SATA硬盘存储数据，节约了存储本。

消息驱动服务在完成数据的读取后，经过相应逻辑的转换、清洗，保存到分布式文件服务系统中，此处因为无事务性，故采用非结构化数据库MongoDB作为日志数据的存储数据库。

4 结论

全国芯片印章系统多中心模式部署，业务系统分散，业务系统的运行日志的收集为系统运行行为分析提供基础数据。采用AOP切面技术，对业务系统的改造最小，完成了日志收集与业务系统的低耦合。采用消息中间件对收集到的日志数据进行缓存，降低了对业务系统并发性能的影响。采用非结构化数据库存储技术，提高了日志采集系统日志接收处理能力，且MongoDB的分片部署，数据的分布存储，数据安全性交由MongoDB分布式文件系统管理，存储设备采用廉价的SATA机械盘即可，极大节约了存储成本。

参考文献：

[1] 罗东锋，李芳，郝汪洋，等.基于Docker的大规模日志采集与分析系统[J].计算机系统应用，2017，26（10）：82-88.

[2] 王萌.一种高可用Web服务平台的研究与实现[D].西安电子科技大学，2012.

[3] 吴一男.分布式交易系统平台中消息中间件的设计与实现[D].浙江大学，2006.

[4] 于曦，李丹.面向消息的中间件概述[J].成都大学学报（自然科学版），2002（4）：34-36.

[5] 方瑜庆.高速公路收费及管理系统中分布式消息系统的应用[J].中国交通信息化，2016（1）：98-106.

[6] 陈卫卫，王艳.基于NoSQL数据库的通用数据存储结构的设计方案[J].价值工程，2012，31（26）：191-192.

[7] 白长清，刘敏.MongoDB在气象传感器数据处理中的应用[J].软件，2015，36（11）：34-37.

[8] 徐旭平，李小勇.基于MongoDB的元数据管理研究[J].信息技术，2018，42（8）：87-93.

【通联编辑：王力】