分布式日志采集系統設計

代乾坤

摘要：應用系統的分布式部署已成為應用程序高擴展、高并發性能的必然要求。分布式應用系統部署為業務系統的監控帶來一定的難題。基于全國芯片印章多中心模式部署現狀，在調研現有日志采集系統的基礎上，結合業務流程、數據特點，設計了一套高效可行的分布式日志采集系統。

關鍵詞：分布式文件系統;非結構化存儲;面向切面編程;消息中間件;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.

【通聯編輯：王力】