實時日誌分析系統的基本架構

這段時間的文章，主要關注在團隊的成長和流程的梳理，缺少真正的技術」乾貨「。因此，今天打算分享一下構造日誌分析系統的思路，來圍繞技術話題多講一講，感受本身仍是適合多講講技術。言歸正傳，作這個系統的出發點很簡單，就是在作大促活動期間，運營的同事但願能實時看到用戶的行爲數據和訂單的狀況，從而根據數據能及時有效的調整運營策略。雖然互金產品的用戶量還遠不能和國內龍頭電商的大促期相比，可是活動期間的日誌的量仍是普通的架構難以招架的，因此作了一些調研後，實時日誌分析系統的架構以下：

引入了Flume+Kafka+Storm來作做爲班底，並繼續經過Redis+Mysql的「經典」組合來作好日誌數據處理後的存儲。下面會分開討論一下，選擇這組班底的緣由和過程當中的思考。

經過Flume收集日誌數據

最初的時候，有兩套收集日誌的思路，一是考慮經過shell腳原本批量處理日誌文本，二是在程序中將要收集的日誌數據直接經過一組特定的API來收集。不過這兩種方案很快就被否認了，方案一的問題是工做量大，腳本不方便維護，維護成本至關高。方案二的問題是業務代碼侵入性大，很難及時對API進行調整或者更新，最重要的一點在於，這個方案對業務服務的性能也是有必定的影響。

通過調研後，決定採用第三方框架Flume進行日誌採集，Flume是一個分佈式的高效的日誌採集系統，它能把分佈在不一樣服務器上的海量日誌文件數據統一收集到一個集中的存儲資源中，與Kafka也有很好的兼容性。

爲何不使用Logstash?

坦白的說，在這個項目前，我對Flume一無所知。我在順豐的時候，對日誌進行處理，用的是ELK組合（ElasticSearch、Logstash、Kibana），因此我對Logstash更加熟悉。之因此考慮Flume有兩個緣由：

1. Flume + Kafka的組合的方案更加成熟，因爲考慮Kafka來作消息系統，會考慮反推使用Flume。

1. Flume的優點，在於傳輸的穩定性，因此既然是業務數據的分析，穩定性天然是重點考慮的一點。Flume的agent是運行在JVM上的，每個Flume agent部署在一臺服務器上，Flume會收集應用服務產生的日誌數據，並封裝成一個個的事件發送給Flume Agent的Source。Flume提供了點對點的高可用的保障，某個服務器上的Flume Agent Channel中的數據只有確保傳輸到了另外一個服務器上的Flume Agent Channel裏或者正確保存到了本地的文件存儲系統中，纔會被移除。

搭建消息處理系統

Kafka提供了相似於JMS的特性，可是在設計實現上徹底不一樣，此外它並非JMS規範的實現。kafka對消息保存時根據Topic進行歸類，發送消息者成爲Producer,消息接受者成爲Consumer,此外kafka集羣有多個kafka實例組成，每一個實例(server)成爲broker。不管是kafka集羣，仍是producer和consumer都依賴於zookeeper來保證系統可用性集羣保存一些meta信息。

（圖片摘自Kafka官網）

kafka在日誌分析系統中實際上就至關於起到一個數據緩衝池的做用, 由於是基於log File的消息系統，數據不容易丟失，以及能記錄數據的消費位置而且用戶還能夠自定義消息消費的起始位置，這就使得重複消費消息也能夠得以實現，並且同時具備隊列和發佈訂閱兩種消息消費模式，十分靈活，而且與Storm的契合度很高，充分利用Linux系統的I/O提升讀寫速度。

經過Storm進行Steaming Computing

Storm是一個開源的分佈式實時計算系統，常被稱爲流式計算框架。什麼是流式計算呢？通俗來說，流式計算顧名思義：數據流源源不斷的來，一邊來，一邊計算結果，再進入下一個流。例如,一個理財產品一直不間斷的運行，會持續進行金融產品交易、用戶的全部行爲都記錄進日誌裏；海量數據使得單節點處理不過來，因此就用到分佈式計算機型，Storm 是其中的典型表明之一，通常應用場景是：中間使用一個消息隊列系統如kafka，先將消息緩存起來，Storm 中有不少的節點，分佈式並行運行處理程序，進行數據處理。

從Kafka comsumer到Storm的流程以下：

根據Storm的編程模型，實現這個數據處理需求須要創建1個數據源Spout組件，2個業務邏輯組件Bolt，以及一個Topology結構，將這3個組件加入到這個topology結構中。 Spout用於產生數據或者從外部接收數據，它至關於數據源；Bolt用於消費從Spout發送出來的數據流並實現用戶自定義的數據處理邏輯；對於複雜的數據處理，能夠定義多個連續的Bolt去協同處理。tuples是Storm的數據模型,由值和其所對應的field所組成。

在Storm中提出了Stream Group的概念，它用來決定從Spout或Bolt組件中發出的tuples接下來應該傳到哪個組件，明確了在程序裏設置某個組件應該接收來自哪個組件的tuples; 而且在Storm中提供了多個用於數據流分組的機制，好比說shuffleGrouping，隨機分組，隨機派發stream裏面的tuple，保證每一個bolt task接收到的tuple數目大體相同。最後在程序中經過Spout和Bolt生成Topology對象並提交到Storm集羣上執行。Topology類便將以前編寫的1個spout 和2個bolt組裝到一個topology中，並經過追加shuffleGrouping方法設置了他們之間的數據傳遞方向，以及進程個數。

最後一點總結

基於以上的FKS組合的討論，實時日誌分析系統的運行流程以下:

1. 經過Flume去監聽業務系統產生的日誌，並實時把每一條日誌信息抓取下來並存進Kafka消息系統中；

2. 接着由Storm系統消費Kafka中的消息，使用用戶定義好的Storm Topology去進行日誌信息的分析並輸出到Redis緩存數據庫中；

3. 同時將redis緩存的數據，按期同步到MySQL中；

4. 爲了服務各個前端系統，創建了一套API服務，方便得到各個維度的數據。

掃描二維碼或手動搜索微信公衆號【架構棧】： ForestNotes

歡迎轉載，帶上如下二維碼便可