這段時間的文章，主要關注在團隊的成長和流程的梳理，缺乏真正的技術”乾貨“。所以，今天打算分享一下構造日誌分析系統的思路，來圍繞技術話題多講一講，感覺自己還是適合多講講技術。言歸正傳，做這個系統的出發點很簡單，就是在做大促活動期間，運營的同事希望能實時看到使用者的行為資料和訂單的情況，從而根據資料能及時有效的調整運營策略。雖然互金產品的使用者量還遠不能和國內龍頭電商的大促期相比，但是活動期間的日誌的量還是普通的架構難以招架的，所以做了一些調研後，實時日誌分析系統的架構如下：
引入了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組合的討論，實時日誌分析系統的執行流程如下:
通過Flume去監聽業務系統產生的日誌，並實時把每一條日誌資訊抓取下來並存進Kafka訊息系統中；
接著由Storm系統消費Kafka中的訊息，使用使用者定義好的Storm Topology去進行日誌資訊的分析並輸出到Redis快取資料庫中；
同時將redis快取的資料，定期同步到MySQL中；
為了服務各個前端系統，建立了一套API服務，方便獲得各個維度的資料。
掃描二維碼或手動搜尋微信公眾號【架構棧】： ForestNotes
歡迎轉載，帶上以下二維碼即可
