百度商业大规模微服务分布式监控系统-凤睛
導讀：作為鳳睛早期的接入方、后期的核心成員，筆者經歷了整個項目前后四年的變遷，看過項目的艱難開端、中期的默默積累以及后期的蓬勃發展。每一次架構的變遷都帶著技術浪潮的烙印，也看到項目成員利用有限資源來解決實際問題而持續不斷的創新。
鳳睛是百度商業業務系統的性能監控系統（APM），它側重于對Java應用的監控，基本接入了百度絕大部分Java應用（覆蓋數千個業務應用，數萬個容器）。它能夠對主流中間件框架（ Spring Web、RPC、數據庫、緩存等）進行自動埋點，實現全棧式性能監控和全鏈路追蹤診斷，為百度各業務線提供微服務系統性能指標、業務黃金指標、健康狀況、監控告警等。
△鳳睛產品流程圖
- 數據采集：鳳睛探針技術能夠自動植入到業務進程中去，采集相關性能信息，業務進程完全無感知。
- 數據計算和分析：按照類型，時序數據存儲在百度SIA智能監控平臺的時序數據庫TSDB，用來生成可視化報表和異常報警。調用鏈數據會被存入Palo（ 開源名為Doris） 大數據倉庫，用來拓撲分析和調用鏈檢索。
- 應用場景：如上所述，鳳睛提供穩定性報表、異常報警、錯誤堆棧分析、服務耗時分析、調用拓撲分析、業務日志關聯分析等。
△鳳睛的架構變遷時間線
01 鳳睛立項
項目發起在2016年，百度鳳巢廣告業務系統中間件 (分布式RPC框架 Stargate等、配置中心、數據庫中間件等)已經完善。隨著單體服務拆分的深入，整體Java在線上部署規模逐漸變多，同時，暴露的問題也越來越多。
典型的問題有：
- 核心服務問題定位周期長。多個模塊大量報錯后，花費了很長時間才定位問題。
- 集群日志獲取代價非常高，缺乏日志調用鏈關系等原因導致定位代價很高，甚至有些問題無法定位。
- 異常日志需要登錄具體的線上實例查看。而線上部署實例數目多，排錯時間長。
鳳巢業務端急需一個分布式追蹤系統來完成整個業務端日志的“大串聯”。所以百度商業平臺基礎架構組發起了鳳睛的項目，名曰“鳳巢之眼”。
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架構設計中，項目組成員一直在思考兩個問題：
對當時幾種流行的監控診斷工具進行了調研：
△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體系的成熟完善，單體能夠被快速拆分成了數目眾多的微服務，依托平臺進行高效的運維部署。鳳睛作為基礎組件被微服務托管平臺集成，并得到公司級的推廣應用，整體部署應用規模從百級別激增到了千級別，部署容器從千級別變成了萬級別。
這個階段爆發了很多問題，技術核心問題主要有兩點：
2019年，鳳睛進行了進一步的改造升級，針對1、2兩個問題，進行了技術攻堅。
探針層面研究如何支持熱插拔，也就是探針在業務進程運行的情況下自動完成升級。起初為了保證業務類對探針插件類的可見性，探針類統一放到了 System Classloader里。但是System Classloader 作為系統默認的，不支持卸載。反之，如果把探針類全部放到自定義類加載器中。探針類則對業務類完全不可見，也就無法完成字節碼增強。
△探針熱插拔classloader體系
為了解決可見性問題，探針引入了橋接類，通過橋接類提供的代碼樁和插件類庫投影，用戶類可以訪問實際使用的探針類，完成監控改造的目的。對于不同插件，則放在不同的自定義 Classloader 里面。這樣來插件之間互不可見。單個插件也可以完成熱插拔。具體的設計細節后面會有文章詳細解讀。
毋庸置疑，鳳睛探針是業界唯一能夠熱插拔的監控探針技術，我們也申請了專利。它的功能正確性和性能是經歷過大規模線上流量驗證的。
繼續推進優化調用鏈檢索的性能。
首先分析下我們的底層存儲結構：
通過對慢查詢的分析，發現檢索慢主要是兩個原因：一是大量查詢沒有走任何索引，全表掃描海量數據非常慢。二是，導入碎片過多，導致文件Compaction特別慢，典型的LSM-Tree 的讀放大。為了解決這些問題，調用鏈存儲層重構表結構，通過大量Rollup配合基本表，優化查詢時間。Doris 此時已經具備流式導入的能力，也借機從小批量導入切換到流式導入。
△調用鏈處理架構
△上圖是鳳睛實時構建的微服務全景拓撲圖。截止2020年1月，大概涵蓋了數十條產品線的線上流量拓撲，最細粒度的節點為接口，即 Java 應用中的函數。從圖中可以分析出，托管全平臺非孤島接口節點大概有50w+，接口節點連線200w+ 條。
06 數據處理架構分離
架構繼續演進，鳳睛采集的數據量越來越多，業務方需求也越來越多。
主要面臨兩個問題：
這兩個問題歸根結底是時序數據如何存儲和展現。這涉及到分布式追蹤領域兩個很基礎的概念，時序時間和調用鏈數據。所謂的時序數據是基于時間的一系列的數據，用于查看一些指標數據和指標趨勢。調用鏈數據是指記錄一個請求的全部流程，用于查看請求在哪個環節出了故障，系統的瓶頸在哪兒。
時序數據不需要保存細節，只存時間、維度和指標的數據點, 可以存儲在專門的時間序列數據庫（Time Series Database）。實際場景中，鳳睛沒有專門去維護一個時序數據庫。而是對接百度SIA智能監控平臺的分布式時序數據庫TSDB。同時，利用百度SIA平臺提供豐富的多維可視化分析報表，用以解決用戶各種可視化多維度數據分析的需求。
?△當前整體的架構
07 結語
鳳睛整個項目前后持續了4年，中間經歷過無數的困難和坎坷，通過積累了項目成員們持續的付出，最終取得里程碑式的成果。本文簡要介紹了鳳睛產品的業務背景、技術架構和產品形態，后續會繼續發文介紹技術相關的實現細節，歡迎持續關注。
推薦閱讀：
百度世界2021：百度大腦升級、昆侖芯2量產、智能云加速AI落地爆發
總結
以上是生活随笔為你收集整理的百度商业大规模微服务分布式监控系统-凤睛的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 如何快速定位程序Core？
- 下一篇： 百度智能云人脸活体检测系统获得公安部一所