前言
大資料一直是技術社群的熱門話題，是從事大型服務架構的攻城獅必修之課。
嶽鷹全景監控平台作為大資料應用系統，每時每刻都需要處理大量的日志流量，今天我們将通過本文，為大家介紹嶽鷹是如何打造大資料日志網關（簡稱網關），以滿足以下需求：
| QPS | 數十萬 |
|---|---|
| 日PV | 數百億 |
| 流量帶寬 | Gbps級别 |
| 日流量 | 數十TB |
| RTT | <=40ms |
| 資料安全性 | 高 |
| 服務可用性 | 99.99% |
背景
一個監控系統大緻包括四個階段：日志采集上報、日志存儲、統計與分析、資料展示，具體如下所示
而作為整個鍊路的資料入口，可以把網關想象為通往皇城前的守門将，所有的資料流入都需要經過其“把關”，才能到達下遊被處理
業務特性
概括來說，網關其核心設計要素主要有安全、高可用、大流量、高并發以及成本5大特性，如下圖：
安全性
作為一個對外暴露的服務，安全性必定是淩駕于一切之上的。除常見的實體層、網絡層、系統層的安全防禦以外，在應用層，我們通過以下手段保證資料安全性：
- Https——作用不多說，請自行Google
- Params Verify——正常的入參資訊校驗
- Time Verify——請求逾時校驗
- Sign Verify——簽名校驗，通過請求資訊、應用辨別、應用秘鑰生成
- Business Verify——業務級校驗，如App是否存在有效、資料是否被限流等
- Encrypt/Decrypt——資料加密上報，網關解密處理
- No Store——本地無存儲，防止伺服器被黑客入侵導緻資料洩漏
除此以外，還有防刷判斷、請求重複判斷、限流熔斷等一些列保障措施，這個後面會有專門文章解讀，敬請期待...^v^!
高可用
可用性決定了整個平台的資料可用性（若垮掉整個下遊都不會再有資料），是以需要有以下政策保證其服務可用性：
整個架構非常經典，各核心職責：
- 日志資料由應用端利用SDK通過網際網路上報至合适的服務節點；
- 由統一服務層，完成https資料解密、請求路由、負載均衡操作；
- 具體的業務操作由日志網關應用負載進行業務層處理；
- 過程當中需要用到的相關業務資料，通過Redis叢集加載，并利用廣播機制實作實時資料重新整理；
- 當日志完成初步處理後，會發往Kafka叢集，并供下遊服務使用；
大流量&高并發
如上文說述，網關需要
- 處理 百億級以上/日 日志上報請求（按16小時分布計算，QPS達十萬級别）。
- 接收 約數十TB/日流量（按16小時分布計算，需要帶寬Gbps級别）。
- 毫秒級請求響應能力（否則有可能影響調用端的整體性能，或丢失資料）。
偶遇極端情況，還會呈幾何級别上漲（想了解如何處理這種極端情況，請期待後面推文）。可見要解決這一問題，比“安全性”、“可用性”要困難的多。在說解決方案之前，我們不妨先大概了解下整個上報的處理流程：
核心（長耗時）的處理邏輯集中在“請求校驗”、“業務處理”兩個環節。當中又可以劃分為“CPU密集型”和“I/O密集型”（小烏龜圖示位置）操作。
CPU密集型
網關并非複雜運算形應用，針對純CPU操作的優化其實非常有限。值得注意的是，現代主流的程式設計語言（如Java、Node等），其在邏輯運算能力上的差異一般不會很大（當然不同技術有其特殊的優化手段），而在實際情況下，提升硬體性能、利用負載均衡這兩個手段效果會最為明顯。
I/O密集型
I/O操作一般都會比純CPU/記憶體操作要慢得多，當中又要細分為本地I/O和網絡I/O兩種：
解決這方面問題，我們的手段是：
- 資料壓縮上報——提高網絡傳輸速度，減少帶寬耗損。
- 合并上報——減少并發請求數，提升壓縮品質。
- 分階段請求處理——http請求處理實際上是分多個階段的（如Nginx就分了11個階段），可以把大量用于校驗的資訊（該類資訊通常比較小），通過http頭部傳輸，并在header處理階段完成校驗操作；若檢驗失敗就可以直接不處理封包體内容，這樣可以減少非必要的流量處理，節省資源&提升效率。
- 跨系統調用——利用中間件代替直接的跨系統通路，擁有更高性能同時，降低性能不穩定風險。
- 高性能中間件選型——用Redis替代傳統DB作為資料源、用Kakfa作為消息中轉替代直接的下遊系統通路。
- 多級緩存——把不常變的資料，利用本地->叢集緩存->實體存儲方式進行緩存，減少I/O操作及運算耗時。
- 資料緩沖 & 中轉——在大資料分析處理的場景，我們需要對資料進行不同類型的加工處理（如統計、聚合、篩選、過濾等），若這些操作都在一次請求中完整處理，耗時會非常長。是以我們使用異步緩沖機制，利用消息中間件對資料進行緩沖，并中轉至下遊運算，這樣可以大大降低RT，提升TPS&QPS。
- 調整日志輸出級别——上線後的應用，調整較低的日志輸出級别（如error），可以減少本地磁盤的寫入操作。
-
線性落盤——針對需要寫盤的操作，可以統一寫到全局緩沖區，然後用獨立線程/程序進行落盤操作，減少不規律I/O操作。
當然以上的方案是需要根據實際情況權衡使用，如使用緩存會導緻變化響應慢、使用線性落盤資料會有丢失風險等。
成本
作為一個如此大流量、高并發的産品，我們需要承受各類硬體、網絡、維護等的高成本投入（當然還有其它），是以在技術方案上，我們必須要考慮這個因素：
- 硬體成本——如何提升同等級别裝置下，單執行個體的運作效率。
- 網絡成本——如何在不影響（小影響）性能效果下，降低網絡資源耗損。
- 維護成本——如何通過更多DevOps工具（部署、測試、監控），減少人工成本投入。
- 人力成本——包括學習成本、實施成本、問題跟進成本。
- .....
技術選型
在選型的道路上，我們糾結了很久（也踩了很多坑）。最初我們曾用SpringBoot（Web層用原生Servlet，MVC性能很差！）實作了一個日志上報的demo，在16核8G記憶體下（并做一定配置調優），跑出單機1W+QPS的成績。但幹了Java那麼久，又好像沒怎麼聽過用Java Web來做高并發大流量網關的（Go、NodeJs：我們這方面精通！！！）。
于是我們開展了一波又一波的研讨，包括同類競品分析、各類技術調研、各種性能評測等等（有機會再分享下我們的選型經過）。最終我們綜合各方面因素，最終選型——OpenResty(Go、NodeJs：What？！)
OpenResty簡介
OpenResty是一個基于 Nginx 與 Lua 的高性能 Web 平台，其内部內建了大量精良的 Lua 庫、第三方子產品以及大多數的依賴項。用于友善地搭建能夠處理超高并發、擴充性極高的動态 Web 應用、Web 服務和動态網關。
總結特點：
- 基于 Nginx 與 Lua 的高性能 Web 平台（利用Nginx擴充機制，通過子產品方式內建Nginx運作程序）
- 部署簡單友善
- 專注超高并發、擴充性極高的動态 Web 應用、服務和動态網關
- 非堵塞I/O、協程同步模型（比較适合密集小檔案I/O請求場景）
- 支援細粒度請求事件控制（結合上文提及的分階段請求處理）
- 學習成本低，輕量級Lua腳本語言（與nodejs相像），支援JIT
- 有成功案例，也有同類應用場景案例
- 同時根據評測，在相同硬體環境、業務邏輯的前提下，OpenResty都會有比較明顯的性能優勢。
但是，它也有一些不足的地方：
- 冷門技術，學習成本高
- 文法有點不習慣，特别是數組索引是從1開始！！！
- "內建大量精良庫"，支援并不完善
- 配套的開發、測試工具不豐富
- 運作性能與編碼實作方式非常密切，一不小心就可以掉30～40%性能
- ......太多了，有機會再分享
能力擴充
正如上面說到，OpenResty原生的支援不算十分強大，為了更好的落地這個方案，我們還是做了一定擴充，包括：
- lmf-mvc——純lua編寫的mvc架構，提供多層互動模型，解決原生配置複雜且實作混亂問題
- lmf-redis——純lua編寫的Redis元件庫，支援更多redis部署模型以及更多能力特性
- lmf-commons——其它常用元件，提供如多級緩存元件、并發鎖、日志、各類方法庫等能力
- ......
技術架構
說那麼多，還是來個圖比較實際：
新的方案為我們帶來了更高的性能提升，在相同硬體情況下，新的方案QPS提升了3倍以上。同時硬體層面的提升對性能的影響也能起到更明顯的效果。
小結
由于篇幅關系，大資料日志網關的介紹就到此為止，若大家想深入了解更多内容，歡迎各位關注我們，深入讨論～（小編又要回去碼代碼了）。