百度商業大規模微服務分佈式監控系統——鳳睛

導讀：做爲鳳睛早期的接入方、後期的核心成員，筆者經歷了整個項目先後四年的變遷，看過項目的艱難開端、中期的默默積累以及後期的蓬勃發展。每一次架構的變遷都帶着技術浪潮的烙印，也看到項目成員利用有限資源來解決實際問題而持續不斷的創新。

鳳睛是百度商業業務系統的性能監控系統（APM），它側重於對Java應用的監控，基本接入了百度絕大部分Java應用（覆蓋數千個業務應用，數萬個容器）。它可以對主流中間件框架（ Spring Web、RPC、數據庫、緩存等）進行自動埋點，實現全棧式性能監控和全鏈路追蹤診斷，爲百度各業務線提供微服務系統性能指標、業務黃金指標、健康情況、監控告警等。

△鳳睛產品流程圖

• 數據採集：鳳睛探針技術可以自動植入到業務進程中去，採集相關性能信息，業務進程徹底無感知。

• 數據計算和分析：按照類型，時序數據存儲在百度SIA智能監控平臺的時序數據庫 TSDB，用來生成可視化報表和異常報警。調用鏈數據會被存入Palo（ 開源名爲Doris） 大數據倉庫，用來拓撲分析和調用鏈檢索。

• 應用場景：如上所述，鳳睛提供穩定性報表、異常報警、錯誤堆棧分析、服務耗時分析、調用拓撲分析、業務日誌關聯分析等。

△鳳睛的架構變遷時間線

01  鳳睛立項

項目發起在2016年，百度鳳巢廣告業務系統中間件 (分佈式RPC框架 Stargate等、配置中心、數據庫中間件等)已經完善。隨着單體服務拆分的深刻，總體Java在線上部署規模逐漸變多，同時，暴露的問題也愈來愈多。

典型的問題有：

1. 核心服務問題定位週期長。多個模塊大量報錯後，花費了很長時間才定位問題。
2. 集羣日誌獲取代價很是高，缺少日誌調用鏈關係等緣由致使定位代價很高，甚至有些問題沒法定位。
3. 異常日誌須要登陸具體的線上實例查看。而線上部署實例數目多，排錯時間長。

鳳巢業務端急需一個分佈式追蹤系統來完成整個業務端日誌的「大串聯」。因此百度商業平臺基礎架構組發起了鳳睛的項目，名曰「鳳巢之眼」。

02  鳳睛1.0

在分佈式鏈路追蹤領域，探針採集這個環節主要存在侵入式和無侵入式。1.0探針走的侵入方式。業務開發人員首先引入探針相關的依賴 jar 包，經過攔截器自動收集調用關係以及性能數據；而後，添加硬編碼補充業務數據。

△編碼示例

探針採集的數據會被打印到磁盤，經過kafka收集走。底層的數據處理和數據存儲採用了Storm、 Hbase等當時流行的數據處理系統。後端架構比較複雜。

△鳳睛1.0架構示意圖

03  鳳睛2.0

鳳睛2.0版本中，首先是下降探針接入成本。2.0版本中，探針改用java agent技術結合cglib 作AOP註解，把依賴引入的jar 包從N個下降到1個。從編寫大段的調用鏈填充代碼改成儘可能走AOP。探針端傳輸層採用了更高效的傳輸協議（protobuffer+gzip）, 直接經過 HTTP 協議發送到 kafka，大大了下降磁盤IO開銷。

2.0探針較1.0接入方便，傳輸也更快。可是仍需業務方添加AOP代碼。對於業務端數以百計的應用來講，接入仍然是大工程，推廣依然困難。

04  鳳睛3.0

鳳睛3.0架構設計中，項目組成員一直在思考兩個問題：

1. 如何讓業務方快速接入，儘可能少改動，甚至「無感知接入」？
2. 如何下降架構運維難度，既能處理海量數據，又能低成本運維？

爲了解決問題1，探針3.0 決定徹底放棄侵入式方式，改成無侵入即字節碼加強方式。

對當時幾種流行的監控診斷工具進行了調研：

△Newrelic，pinpoint，greys監控探針調研

3.0探針參考了Greys支持運行時加強的特色以及 pinpoint、Newrelic基於插件擴展開發的設計理念。最終效果是探針可以自動對業務進程植入監控代碼，監控具體工做交由插件體系完成，徹底面向切面監控。

△探針主動加載示意圖

後端存儲系統轉而依託Doris。Doris是百度自研的基於 MPP 的交互式 SQL 數據倉庫，兼容mysql協議，學習成本低。既能夠作存儲又能夠作分析計算，初期避免引入spark，storm等技術，下降系統複雜度。

△架構設計如圖所示

架構升級後，做爲小團隊，也能快速批量部署探針，計算存儲能力也能知足需求。截止2017年，鳳睛3.0上線了100多個應用，跑在1000多個容器上面。

05  鳳睛4.0

2018年，微服務和虛擬化浪潮席捲而來。隨着部署平臺的不斷升級和 springboot體系的成熟完善，單體可以被快速拆分紅了數目衆多的微服務，依託平臺進行高效的運維部署。鳳睛做爲基礎組件被微服務託管平臺集成，並獲得公司級的推廣應用，總體部署應用規模從百級別激增到了千級別，部署容器從千級別變成了萬級別。

這個階段爆發了不少問題，技術核心問題主要有兩點：

1. 探針升級須要重啓業務應用生效，而線上應用重啓流量有損。致使難以頻繁升級探針版本，快速引入新功能。
2. 天天實時寫入150億條，峯值流量 300w 條/s。數據導入容易丟失；檢索單條調用鏈性能查，大概須要100多秒。

2019年，鳳睛進行了進一步的改造升級，針對一、2兩個問題，進行了技術攻堅。

探針層面研究如何支持熱插拔，也就是探針在業務進程運行的狀況下自動完成升級。起初爲了保證業務類對探針插件類的可見性，探針類統一放到了 System Classloader裏。可是System Classloader 做爲系統默認的，不支持卸載。反之，若是把探針類所有放到自定義類加載器中。探針類則對業務類徹底不可見，也就沒法完成字節碼加強。

△探針熱插拔classloader體系

爲了解決可見性問題，探針引入了橋接類，經過橋接類提供的代碼樁和插件類庫投影，用戶類能夠訪問實際使用的探針類，完成監控改造的目的。對於不一樣插件，則放在不一樣的自定義 Classloader 裏面。這樣來插件之間互不可見。單個插件也能夠完成熱插拔。具體的設計細節後面會有文章詳細解讀。

毋庸置疑，鳳睛探針是業界惟一可以熱插拔的監控探針技術，咱們也申請了專利。它的功能正確性和性能是經歷過大規模線上流量驗證的。

繼續推動優化調用鏈檢索的性能。

首先分析下咱們的底層存儲結構：

經過對慢查詢的分析，發現檢索慢主要是兩個緣由：一是大量查詢沒有走任何索引，全表掃描海量數據很是慢。二是，導入碎片過多，致使文件Compaction特別慢，典型的LSM-Tree 的讀放大。爲了解決這些問題，調用鏈存儲層重構表結構，經過大量Rollup配合基本表，優化查詢時間。Doris 此時已經具有流式導入的能力，也藉機從小批量導入切換到流式導入。

△調用鏈處理架構

△上圖是鳳睛實時構建的微服務全景拓撲圖。截止2020年1月，大概涵蓋了數十條產品線的線上流量拓撲，最細粒度的節點爲接口，即 Java 應用中的函數。從圖中能夠分析出，託管全平臺非孤島接口節點大概有50w+，接口節點連線200w+ 條。

06  數據處理架構分離

架構繼續演進，鳳睛採集的數據量愈來愈多，業務方需求也愈來愈多。

主要面臨兩個問題：

1. 數據可視化能力依賴於前端開發，大量多維可視化分析需求難以知足。
2. 調用鏈作了採樣，致使統計數據不許確，沒法知足統計報表的需求。

這兩個問題歸根結底是時序數據如何存儲和展示。這涉及到分佈式追蹤領域兩個很基礎的概念，時序時間和調用鏈數據。所謂的時序數據是基於時間的一系列的數據，用於查看一些指標數據和指標趨勢。調用鏈數據是指記錄一個請求的所有流程，用於查看請求在哪一個環節出了故障，系統的瓶頸在哪兒。

時序數據不須要保存細節，只存時間、維度和指標的數據點, 能夠存儲在專門的時間序列數據庫（Time Series Database）。實際場景中，鳳睛沒有專門去維護一個時序數據庫。而是對接百度SIA智能監控平臺的分佈式時序數據庫TSDB。同時，利用百度SIA平臺提供豐富的多維可視化分析報表，用以解決用戶各類可視化多維度數據分析的需求。

‍△當前總體的架構

07  結語

鳳睛整個項目先後持續了4年，中間經歷過無數的困難和坎坷，經過積累了項目成員們持續的付出，最終取得里程碑式的成果。本文簡要介紹了鳳睛產品的業務背景、技術架構和產品形態，後續會繼續發文介紹技術相關的實現細節，歡迎持續關注。

閱讀原文
百度商業大規模微服務分佈式監控系統——鳳睛

推薦閱讀

｜百度搜索與推薦引擎的雲原生改造

最後歡迎各位關注咱們的同名公衆號「百度Geek說」～