代乾坤

摘要：應用系統(tǒng)的分布式部署已成為應用程序高擴展、高并發(fā)性能的必然要求。分布式應用系統(tǒng)部署為業(yè)務系統(tǒng)的監(jiān)控帶來一定的難題?；谌珖酒≌露嘀行哪Ｊ讲渴瓞F(xiàn)狀，在調研現(xiàn)有日志采集系統(tǒng)的基礎上，結合業(yè)務流程、數(shù)據(jù)特點，設計了一套高效可行的分布式日志采集系統(tǒng)。

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

隨著信息技術的快速發(fā)展，系統(tǒng)日志數(shù)據(jù)呈現(xiàn)爆炸式的增長，且分布式系統(tǒng)部署為系統(tǒng)的業(yè)務及運行監(jiān)控帶來了一定的難題。為提升全國印章業(yè)芯片印章系統(tǒng)集成應用水平，設計了全國芯片印章多中心模式日志采集系統(tǒng)，為芯片印章發(fā)行業(yè)務的大數(shù)據(jù)分析提供基礎數(shù)據(jù)。

目前系統(tǒng)日志的收集方式各異，并各有優(yōu)缺點，比較常見的日志系統(tǒng)包括facebook的scribe，apache的chukwa，linkedin的kafka和cloudera的flume等[1]。以上日志采集方式對目前業(yè)務系統(tǒng)來講，不能很好地與業(yè)務系統(tǒng)融合，當需要將這些日志系統(tǒng)整合到全國芯片印章業(yè)務系統(tǒng)時，需要做大量的整合工作，且業(yè)務代碼層面也需要做出修改，因此基于現(xiàn)有全國芯片印章業(yè)務系統(tǒng)，構建開發(fā)了分布式日志采集系統(tǒng)。

2 關鍵技術

2.1 AOP切面編程

AOP（Aspect-Oriented Programming），其實是OOP（Object-Oriented Programing）思想的補充和完善。OOP引進抽象、封裝、繼承、多態(tài)等概念，對多樣化的實體進行抽象和封裝，并建立層次分明的實體對象，它強調建立一種自上而下的實體間的關系。當需要具體到每個實體內(nèi)部的情況，OOP有些捉襟見肘，比如日志功能、權限控制。此類代碼往往離散的分布在所有對象當中，卻與它所在對象的核心功能無關，導致了大量代碼的重復，不利于各個模塊的重用。

AOP技術則恰恰相反，它利用一種稱為“橫切”的技術，能夠剖解開封裝的對象內(nèi)部，并將那些影響了多個類并且與具體業(yè)務無關的公共行為封裝成一個獨立的模塊（稱為切面）。更重要的是，它又能以巧奪天工的妙手將這些剖開的切面復原，不留痕跡的融入核心業(yè)務邏輯中[2]。這樣，對于日后橫切功能的編輯和重用都能夠帶來極大的方便。

2.2 ActiveMQ消息中間件

消息隊列對于如今的分布式系統(tǒng)，具有天然的優(yōu)勢，并逐漸發(fā)展為獨立的中間件產(chǎn)品，采用異步通信具有邏輯的低耦合性、消息的順序性、消息的可靠性、緩沖業(yè)務并發(fā)等優(yōu)點。服務與服務間的通信采用消息隊列模式，可以實現(xiàn)異步通信，降低服務間的耦合性[3]。消息隊列可以將大量的高峰期請求數(shù)據(jù)存儲起來慢慢回調業(yè)務模塊進行處理，對于搶購、秒殺等業(yè)務極為重要，并且消息隊列的順序性也保證了先進先出的業(yè)務要求[4]。

ActiveMQ是Apache公司的產(chǎn)品，是目前比較流行的，能力強勁的開源消息總線。ActiveMQ是一個完全支持JMS1.1和J2EE 1.4規(guī)范的JMS Provider實現(xiàn)，盡管JMS規(guī)范出臺已經(jīng)很久，但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。ActiveMQ消息隊列可配置兩種模式，“生產(chǎn)者消費者”模式和“訂閱發(fā)布”模式，兩種模式的業(yè)務模型見圖1和圖2。

ActiveMQ生產(chǎn)者消費者模型就是在一個系統(tǒng)中，存在數(shù)據(jù)的生產(chǎn)者和消費者兩種角色，生產(chǎn)者和消費者共用同一存儲空間，生產(chǎn)者向空間里寫入數(shù)據(jù)，而消費者取走數(shù)據(jù)[5]。生產(chǎn)者消費者模型可以有多個生產(chǎn)者及多個消費者，消息生產(chǎn)后只能由一個消費者消費，基于消息隊列的存儲-轉發(fā)機制，能夠基于消息傳輸和異步事務處理實現(xiàn)應用整合與數(shù)據(jù)交換。降低系統(tǒng)功能耦合性、提高業(yè)務并發(fā)處理能力。

在訂閱發(fā)布模型中，生產(chǎn)者和消費者之間含有一個發(fā)布通道，此時通道可以理解為一個消息隊列，消息隊列從生產(chǎn)者接收消息，消費者向消息隊列注冊，消息隊列把接收到的消息向注冊后的消費者發(fā)布。訂閱發(fā)布模型中，一條發(fā)布信息可以被多個已注冊消費者消費。

2.3 非結構化存儲

NoSQL，泛指非關系型的數(shù)據(jù)庫。關系型數(shù)據(jù)庫中，表都是存儲格式化結構的數(shù)據(jù)，每個元組字段的組成都是一樣的，即使不是每個元組都需要所有的字段，但數(shù)據(jù)庫會為每個元組都分配所有的字段，這樣的結構可以便于表與表之間進行連接等操作，但從另一個角度來說它也是關系數(shù)據(jù)庫性能瓶頸的一個因素[6]。而非關系數(shù)據(jù)庫以鍵值對存儲，它的結構不固定，每一個元組可以有不一樣的字段，每個元組可以根據(jù)需要增加或減少一些自己的鍵值對，這樣就不會局限于固定的結構，可以減少一些時間和空間的開銷。

MongoDB是NoSql的一種，屬于NoSql中的基于分布式文件存儲的文檔型數(shù)據(jù)庫。由C++語言編寫，旨在為WEB應用提供可擴展的高性能數(shù)據(jù)存儲解決方案[6][7]。MongoDB是一個介于關系數(shù)據(jù)庫和非關系數(shù)據(jù)庫之間的產(chǎn)品，是非關系數(shù)據(jù)庫當中功能最豐富，最像關系數(shù)據(jù)庫的。它支持的數(shù)據(jù)結構非常松散，是類似json的BSON（類json的二進制形式的存儲格式，簡稱Binary JSON）格式，因此可以存儲比較復雜的數(shù)據(jù)類型。Mongo最大的特點是他支持的查詢語言非常強大，其語法有點類似于面向對象的查詢語言，幾乎可以實現(xiàn)類似關系數(shù)據(jù)庫單表查詢的絕大部分功能，而且還支持對數(shù)據(jù)建立索引[7][8]。

3 系統(tǒng)設計

分布式日志采集系統(tǒng)整體架構分為數(shù)據(jù)生產(chǎn)、數(shù)據(jù)緩存、數(shù)據(jù)消費、數(shù)據(jù)存儲，由全國芯片印章業(yè)務系統(tǒng)輸出日志數(shù)據(jù)，日志數(shù)據(jù)在業(yè)務系統(tǒng)中存儲在消息中間件ActiveMQ中，ActiveMQ驅動消息服務發(fā)送消息到日志采集系統(tǒng)。日志采集系統(tǒng)提供數(shù)據(jù)接收接口，接收到的數(shù)據(jù)緩存到ActiveMQ中，可以提高日志接收能力。ActiveMQ驅動消息服務集群完成數(shù)據(jù)的轉換、清洗并保存到非結構化數(shù)據(jù)庫MongoDB中。

3.1 數(shù)據(jù)生產(chǎn)

分布式日志采集系統(tǒng)日志由業(yè)務系統(tǒng)的JBOSS產(chǎn)生，為了業(yè)務系統(tǒng)的最小代碼改造，系統(tǒng)采用Spring的AOP對日志業(yè)務進行切面編程，采集到的日志數(shù)據(jù)發(fā)送給消息中間件進行存儲。AOP切面的使用，簡化了業(yè)務系統(tǒng)的改到難度，降低了系統(tǒng)的耦合性，對分布式日志采集系統(tǒng)的順利部署上線提供了很大的幫助。

3.2 數(shù)據(jù)緩存

為了解決大量業(yè)務日志的輸出對系統(tǒng)業(yè)務并發(fā)能力的影響，在業(yè)務系統(tǒng)將日志數(shù)據(jù)生產(chǎn)者產(chǎn)生的日志，發(fā)送到消息中間件進行緩存。采用消息隊列的技術實現(xiàn)，提高了日志采集的性能和可靠性。消息中間件的使用，極大地降低了日志采集對主業(yè)務并發(fā)性能的影響。

當多個業(yè)務系統(tǒng)采集到的數(shù)據(jù)并發(fā)發(fā)送到日志采集系統(tǒng)后，大量的日志數(shù)據(jù)勢必會對數(shù)據(jù)接收的吞吐量提出更高的要求，并可能造成來數(shù)據(jù)丟失。為了提高日志采集系統(tǒng)日志接收接口的性能，采用緩存層對接收到的數(shù)據(jù)進行緩存。緩存層采用開源消息隊列中間件ActiveMQ實現(xiàn)。日志采集接收接口接收到的數(shù)據(jù)直接放入ActiveMQ中，提高了日志采集系統(tǒng)的數(shù)據(jù)接收能力。

3.3 數(shù)據(jù)消費

當ActiveMQ中有新的日志消息存儲時，消息驅動Bean被調用，由消息驅動Bean完成對數(shù)據(jù)的發(fā)送，發(fā)送成功的數(shù)據(jù)由消息驅動Bean發(fā)送ACK給ActiveMQ，消息隊列把數(shù)據(jù)標記為已發(fā)送狀態(tài)，完成數(shù)據(jù)的發(fā)送。日志采集系統(tǒng)完成分布式日志的接收，接收到的數(shù)據(jù)首先緩存在ActiveMQ中，進一步由消息驅動Bean主動處理接收到的數(shù)據(jù)。

3.4 數(shù)據(jù)存儲

日志數(shù)據(jù)為低價值的數(shù)據(jù)，使用傳統(tǒng)的關系型數(shù)據(jù)庫存儲成本較高，并且隨著日志數(shù)據(jù)的累計，性能會急劇下降。Mongo非常適合實時的插入，更新與查詢，并具備網(wǎng)站實時數(shù)據(jù)存儲所需的復制及高度伸縮性。且MongoDB已經(jīng)包含對大數(shù)據(jù)計算MapReduce引擎的內(nèi)置支持，為日志的大數(shù)據(jù)分析計算提供便利。MongoDB的分片部署，非常適合服務器的橫向伸縮，且分布式文件系統(tǒng)自身的安全機制，可以采用較為廉價的SATA硬盤存儲數(shù)據(jù)，節(jié)約了存儲本。

消息驅動服務在完成數(shù)據(jù)的讀取后，經(jīng)過相應邏輯的轉換、清洗，保存到分布式文件服務系統(tǒng)中，此處因為無事務性，故采用非結構化數(shù)據(jù)庫MongoDB作為日志數(shù)據(jù)的存儲數(shù)據(jù)庫。

4 結論

全國芯片印章系統(tǒng)多中心模式部署，業(yè)務系統(tǒng)分散，業(yè)務系統(tǒng)的運行日志的收集為系統(tǒng)運行行為分析提供基礎數(shù)據(jù)。采用AOP切面技術，對業(yè)務系統(tǒng)的改造最小，完成了日志收集與業(yè)務系統(tǒng)的低耦合。采用消息中間件對收集到的日志數(shù)據(jù)進行緩存，降低了對業(yè)務系統(tǒng)并發(fā)性能的影響。采用非結構化數(shù)據(jù)庫存儲技術，提高了日志采集系統(tǒng)日志接收處理能力，且MongoDB的分片部署，數(shù)據(jù)的分布存儲，數(shù)據(jù)安全性交由MongoDB分布式文件系統(tǒng)管理，存儲設備采用廉價的SATA機械盤即可，極大節(jié)約了存儲成本。

參考文獻：

[1] 羅東鋒，李芳，郝汪洋，等.基于Docker的大規(guī)模日志采集與分析系統(tǒng)[J].計算機系統(tǒng)應用，2017，26（10）：82-88.

[2] 王萌.一種高可用Web服務平臺的研究與實現(xiàn)[D].西安電子科技大學，2012.

[3] 吳一男.分布式交易系統(tǒng)平臺中消息中間件的設計與實現(xiàn)[D].浙江大學，2006.

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

[5] 方瑜慶.高速公路收費及管理系統(tǒng)中分布式消息系統(tǒng)的應用[J].中國交通信息化，2016（1）：98-106.

[6] 陳衛(wèi)衛(wèi)，王艷.基于NoSQL數(shù)據(jù)庫的通用數(shù)據(jù)存儲結構的設計方案[J].價值工程，2012，31（26）：191-192.

[7] 白長清，劉敏.MongoDB在氣象傳感器數(shù)據(jù)處理中的應用[J].軟件，2015，36（11）：34-37.

[8] 徐旭平，李小勇.基于MongoDB的元數(shù)據(jù)管理研究[J].信息技術，2018，42（8）：87-93.

【通聯(lián)編輯：王力】