張嵩， 廈門大學電腦碩士畢業， 現于他趣任首席架構師， 主要負責微服務體系健全及持續交付體系建設。 Go語言愛好者及contributor， 近期專注於k8s在他趣的第二版落地及探尋 Machine Learning 在社區的應用。
在各種 RDB 的支撐下， 通過埋點等我們已經能夠實現各種業務統計、監控、分析等方面的需求， 但是我們會最先觸碰到哪些瓶頸呢？而碰到瓶頸後又要如何通過大資料應用來解決呢？這是本文想要著重探討的地方。
探索三步曲 步步簡化
圖 1 是一個常見的情況， 在每一台伺服器日誌上去部署一些資料分析， 簡單分析後會上報到RDB Redis上， 之後會進行二次運算， 緊接著到達展示層；在這個過程中， 查詢日誌可以在ELK上進行。 這算是比較簡單的一個方案， 基本可以滿足大家的需求。 但是這樣做也會產生一些問題：
新增不易；
直接統計出結果資料集過於龐大， 二次運算的複雜度取決於空間的維度；
可接受的時間複雜度
集群維護複雜度
鑒於這幾個問題， 我們將需求重新整理， 如圖 2 所示， 最開始（從左至右）是資料來源， 資料來源包含很多， 比如日誌；第二步是資料處理清洗， 主要的目的是將一些不需要的資料清除掉；第三步是落存儲， 有很多方法， 比如HBase；最後一步就是資料應用， 比如做一些統計報表、進行報警之類的應用。
圖 5 是一代的流程圖。 從資料來源， 也就是伺服器上日誌開始， 資料流程經 Flume， 到達 Kafka後， 分成兩路流（即時流與非即時流）， 一路推入HDFS、一路經過 Storm 進行處理；非即時流主要是用 MR 和 Spark， 進行清洗加工後將資料存儲到 HBase；即時流則經過 Spark Streaming 、Storm處理， 最終也是存儲到 HBase。 這些是早期比較常見的結構。
這種結構下， 元件之間相容問題很多；人力成本消耗大；batchjob、streaming資源、核心非核心資源的競爭難以隔離；由於作業之間依賴關係會導致作業管理複雜；
圖 7 是二代的流程圖。 我們使用了阿裡的 EMR、MAXComputer 等產品， 此時， 伺服器則使用的是 LogStash， 日誌服務則使用 LogHub， 存儲則採用OSS。 這裡也產生一些新的問題。 首先， 日誌服務相對自己搭建ELK要簡易很多， 但是索引按照欄位大小收費， 價格較高；其次， 不同元件間集成異常繁瑣；第三雖然擴容方便， 但是人力並未得到釋放；第四記憶體型計算服務可以實現准即時分析出資料，但是價格偏高；第五是資源競爭問題難以隔離的問題依然存在；第六就是產品變更太快，有時候產品會突然下線或者功能遷移到新的產品中。
圖 8 是我們最新的結構圖。在第三代中我們採用了七牛雲的大資料產品，他們會把一些不屬於我們應該做的操作直接放在他們自己的平臺上，由他們進行維護，這個產品就是他們的大資料產品Pandora。
圖 9 也是我們最新的一個流程圖。最開始還是伺服器，然後是Logkit，當搜集到資料來源之後，將非即時資料打到物件存儲上，利用離線計算去處理這些工作流，經過離線計算的工作流，如果需要做二次計算或存儲就再次返回到物件存儲，如果需要直接計算出結果的話，就直接寫入到J16元件上，J16是我們自己寫的接收http結果的元件，實心箭頭代表現在這塊還未完善，我們是通過額外的腳本進行結果收集到J16的操作；即時資料也採用類似於離線處理的方式，後面步驟與離線計算一致，處理之後的資料，可以用於展示報表和資料採擷。
類似於saas的最後一種流程，可以讓我們的人力接近完全解放。同時元件不存在集成與相容的問題。因為上面設計的離線工作流和線上工作流是完全分離的，所以資源可以完全隔離。
實戰分享 少走彎路
【資料方面】
【業務】
如圖 10 所示，我們的業務和資料處理之間其實是相互交叉的。
為了減少大家在實際過程中碰到的彎路，所以我會分享一些實踐上的經驗，供大家參考。
從資料來源開始，資料來源常見的是nginx、tomcat、fpm、閘道、業務、資料庫日誌、上報異常、Sla日誌等用戶端統計資料。
圖 11 是 nginx 的日誌，涵蓋的內容很多，比如設備號、跟蹤IP、UA頭；微服務存在一個很大的問題，就是如何處理使用者日誌追蹤；處理方式就是當用戶端進行訪問時，帶一個唯一的ID號，最終通過這個ID號可以直接抓出這次所有落在不同服務的請求資料。
圖 13 是日誌查詢介面，為服務端人員提供查詢功能。可以通過設備號，唯一請求ID等，得到用戶端的請求日誌，也可以支援高級的自訂查詢功能。
圖 14 是時序圖，通過這張圖，可以判斷到底是自己調用其他系統服務時耗費時間長還是自己進行查詢時耗費時間長，以及慢查詢發生在何處，是因為查詢資料庫慢了還是其它的原因。
圖 16 是業務在伺服器上運行的時間，這邊可以反映出代碼的品質問題。比如兩秒以上的介面幾乎都是比較複雜的介面，例如下單操作或者調用協力廠商介面。
有分析的話，就可以統計處哪些版本訪問量對高，哪些版本訪問量最低，這樣我們就可以不斷地根據訪問情況下掉舊版本的系統，少維護一些系統。然後也可以知道使用這些API的用戶端到底是哪些版本，有沒有包括當前最新的版本，有的話就不能下架，需要安排逐步修改。例如今年我們就下掉了六七個版本。
也可以通過歷史資料來做一些運維方面的自動化，例如通過前一七天頻寬等的分析來做到頻寬的自動增減，以及類似推送高峰期前自動擴容等的各種操作。
我們每天都要應對不同的攻擊，例如CC攻擊這一塊，我們有做一些WAF的防禦，還有閘道的限流，但是因為閾值的關係，也很難說完全限制住。這個時候我們可以即時的統計當前有哪些用戶端訪問的數目是異常偏高的，例如圖18，我們看最高都是在上面那五條線，每秒鐘可能都有幾十萬人訪問，這五個設備訪問頻率在裡面出現次數最高，就說明有異常。這種就可以做一些特殊處理，針對異常設備進行限流。因為你很難說對所有的設備進行限流，有時候用戶端的訪問確實會很高，比如搶紅包之類的。
七牛雲技術總監陳超、鏈家網大資料部負責人呂毅連袂出品，精選乾貨內容：
鏈家網資深大資料研發工程師鄧鈁元，分享如何運用“開源＋自身業務定制”解決大資料多維分析痛點
七牛雲大資料高級工程師党合萱，全面揭秘七牛自主研發千億級大資料平臺的實踐之路
螞蜂窩大資料平臺負責人汪木鈴帶來螞蜂窩作為國內最早一批使用 Druid 的公司，在實戰過程中踩過的“坑”和優化經驗
高可用架構粉絲福利：
點擊“閱讀原文”即可享免費報名
但是人力並未得到釋放；第四記憶體型計算服務可以實現准即時分析出資料，但是價格偏高；第五是資源競爭問題難以隔離的問題依然存在；第六就是產品變更太快，有時候產品會突然下線或者功能遷移到新的產品中。圖 8 是我們最新的結構圖。在第三代中我們採用了七牛雲的大資料產品，他們會把一些不屬於我們應該做的操作直接放在他們自己的平臺上，由他們進行維護，這個產品就是他們的大資料產品Pandora。
圖 9 也是我們最新的一個流程圖。最開始還是伺服器，然後是Logkit，當搜集到資料來源之後，將非即時資料打到物件存儲上，利用離線計算去處理這些工作流，經過離線計算的工作流，如果需要做二次計算或存儲就再次返回到物件存儲，如果需要直接計算出結果的話，就直接寫入到J16元件上，J16是我們自己寫的接收http結果的元件，實心箭頭代表現在這塊還未完善，我們是通過額外的腳本進行結果收集到J16的操作；即時資料也採用類似於離線處理的方式，後面步驟與離線計算一致，處理之後的資料，可以用於展示報表和資料採擷。
類似於saas的最後一種流程，可以讓我們的人力接近完全解放。同時元件不存在集成與相容的問題。因為上面設計的離線工作流和線上工作流是完全分離的，所以資源可以完全隔離。
實戰分享 少走彎路
【資料方面】
【業務】
如圖 10 所示，我們的業務和資料處理之間其實是相互交叉的。
為了減少大家在實際過程中碰到的彎路，所以我會分享一些實踐上的經驗，供大家參考。
從資料來源開始，資料來源常見的是nginx、tomcat、fpm、閘道、業務、資料庫日誌、上報異常、Sla日誌等用戶端統計資料。
圖 11 是 nginx 的日誌，涵蓋的內容很多，比如設備號、跟蹤IP、UA頭；微服務存在一個很大的問題，就是如何處理使用者日誌追蹤；處理方式就是當用戶端進行訪問時，帶一個唯一的ID號，最終通過這個ID號可以直接抓出這次所有落在不同服務的請求資料。
圖 13 是日誌查詢介面，為服務端人員提供查詢功能。可以通過設備號，唯一請求ID等，得到用戶端的請求日誌，也可以支援高級的自訂查詢功能。
圖 14 是時序圖，通過這張圖，可以判斷到底是自己調用其他系統服務時耗費時間長還是自己進行查詢時耗費時間長，以及慢查詢發生在何處，是因為查詢資料庫慢了還是其它的原因。
圖 16 是業務在伺服器上運行的時間，這邊可以反映出代碼的品質問題。比如兩秒以上的介面幾乎都是比較複雜的介面，例如下單操作或者調用協力廠商介面。
有分析的話，就可以統計處哪些版本訪問量對高，哪些版本訪問量最低，這樣我們就可以不斷地根據訪問情況下掉舊版本的系統，少維護一些系統。然後也可以知道使用這些API的用戶端到底是哪些版本，有沒有包括當前最新的版本，有的話就不能下架，需要安排逐步修改。例如今年我們就下掉了六七個版本。
也可以通過歷史資料來做一些運維方面的自動化，例如通過前一七天頻寬等的分析來做到頻寬的自動增減，以及類似推送高峰期前自動擴容等的各種操作。
我們每天都要應對不同的攻擊，例如CC攻擊這一塊，我們有做一些WAF的防禦，還有閘道的限流，但是因為閾值的關係，也很難說完全限制住。這個時候我們可以即時的統計當前有哪些用戶端訪問的數目是異常偏高的，例如圖18，我們看最高都是在上面那五條線，每秒鐘可能都有幾十萬人訪問，這五個設備訪問頻率在裡面出現次數最高，就說明有異常。這種就可以做一些特殊處理，針對異常設備進行限流。因為你很難說對所有的設備進行限流，有時候用戶端的訪問確實會很高，比如搶紅包之類的。
七牛雲技術總監陳超、鏈家網大資料部負責人呂毅連袂出品，精選乾貨內容：
鏈家網資深大資料研發工程師鄧鈁元，分享如何運用“開源＋自身業務定制”解決大資料多維分析痛點
七牛雲大資料高級工程師党合萱，全面揭秘七牛自主研發千億級大資料平臺的實踐之路
螞蜂窩大資料平臺負責人汪木鈴帶來螞蜂窩作為國內最早一批使用 Druid 的公司，在實戰過程中踩過的“坑”和優化經驗
高可用架構粉絲福利：
點擊“閱讀原文”即可享免費報名