導語
作爲鳳睛早期的接入方、後期的核心成員，筆者經歷了整個項目前後四年的變遷，看過項目的艱難開端、中期的默默積累以及後期的蓬勃發展。每一次架構的變遷都帶着技術浪潮的烙印，也看到項目成員利用有限資源來解決實際問題而持續不斷的創新
鳳睛是百度商業業務系統的性能監控系統（APM），它側重於對Java應用的監控，基本接入了百度絕大部分Java應用（覆蓋數千個業務應用，數萬個容器）。它能夠對主流中間件框架（ Spring Web、RPC、數據庫、緩存等）進行自動埋點，實現全棧式性能監控和全鏈路追蹤診斷，爲百度各業務線提供微服務系統性能指標、業務黃金指標、健康狀況、監控告警等。
鳳睛產品流程圖：
- 數據採集：鳳睛探針技術能夠自動植入到業務進程中去，採集相關性能信息，業務進程完全無感知。
- 數據計算和分析：按照類型，時序數據存儲在百度SIA智能監控平臺的時序數據庫 TSDB，用來生成可視化報表和異常報警。調用鏈數據會被存入Palo（ 開源名爲Doris） 大數據倉庫，用來拓撲分析和調用鏈檢索。
- 應用場景：如上所述，鳳睛提供穩定性報表、異常報警、錯誤堆棧分析、服務耗時分析、調用拓撲分析、業務日誌關聯分析等。
鳳睛的架構變遷時間線：
一、 鳳睛立項
項目發起在2016年，百度鳳巢廣告業務系統中間件 (分佈式RPC框架 Stargate等、配置中心、數據庫中間件等)已經完善。隨着單體服務拆分的深入，整體Java在線上部署規模逐漸變多，同時，暴露的問題也越來越多。典型的問題有：
- 核心服務問題定位週期長。多個模塊大量報錯後，花費了很長時間才定位問題。
- 集羣日誌獲取代價非常高，缺乏日誌調用鏈關係等原因導致定位代價很高，甚至有些問題無法定位。
- 異常日誌需要登錄具體的線上實例查看。而線上部署實例數目多，排錯時間長。
鳳巢業務端急需一個分佈式追蹤系統來完成整個業務端日誌的“大串聯”。所以百度商業平臺基礎架構組發起了鳳睛的項目，名曰“鳳巢之眼”。
二、鳳睛1.0
在分佈式鏈路追蹤領域，探針採集這個環節主要存在侵入式和無侵入式。1.0探針走的侵入方式。業務開發人員首先引入探針相關的依賴 jar 包，通過攔截器自動收集調用關係以及性能數據；然後，添加硬編碼補充業務數據。
編碼示例：
探針採集的數據會被打印到磁盤，通過kafka收集走。底層的數據處理和數據存儲採用了Storm、 Hbase等當時流行的數據處理系統。後端架構比較複雜。
鳳睛1.0架構示意圖：
三、鳳睛2.0
鳳睛2.0版本中，首先是降低探針接入成本。2.0版本中，探針改用java agent技術結合cglib 做AOP註解，把依賴引入的jar 包從N個降低到1個。從編寫大段的調用鏈填充代碼改爲儘量走AOP。探針端傳輸層採用了更高效的傳輸協議（protobuffer+gzip）, 直接通過 HTTP 協議發送到 kafka，大大了降低磁盤IO開銷。
2.0探針較1.0接入方便，傳輸也更快。但是仍需業務方添加AOP代碼。對於業務端數以百計的應用來說，接入仍然是大工程，推廣依然困難。
四、鳳睛3.0
鳳睛3.0架構設計中，項目組成員一直在思考兩個問題：
- 如何讓業務方快速接入，儘量少改動，甚至“無感知接入”？
- 如何降低架構運維難度，既能處理海量數據，又能低成本運維？
爲了解決問題1，探針3.0 決定完全放棄侵入式方式，改爲無侵入即字節碼增強方式。
newrelic，pinpoint，greys監控探針調研如下圖：
3.0探針參考了Greys支持運行時增強的特點以及 pinpoint、Newrelic基於插件擴展開發的設計理念。最終效果是探針能夠自動對業務進程植入監控代碼，監控具體工作交由插件體系完成，完全面向切面監控。
探針主動加載示意圖：
後端存儲系統轉而依託Doris。Doris是百度自研的基於 MPP 的交互式 SQL 數據倉庫，兼容mysql協議，學習成本低。既可以做存儲又可以做分析計算，初期避免引入spark，storm等技術，降低系統複雜度。
架構設計如圖所示：
架構升級後，作爲小團隊，也能快速批量部署探針，計算存儲能力也能滿足需求。截止2017年，鳳睛3.0上線了100多個應用，跑在1000多個容器上面。
五、鳳睛4.0
2018年，微服務和虛擬化浪潮席捲而來。隨着部署平臺的不斷升級和 springboot體系的成熟完善，單體能夠被快速拆分成了數目衆多的微服務，依託平臺進行高效的運維部署。鳳睛作爲基礎組件被微服務託管平臺集成，並得到公司級的推廣應用，整體部署應用規模從百級別激增到了千級別，部署容器從千級別變成了萬級別。
這個階段爆發了很多問題，技術核心問題主要有2點：
- 探針升級需要重啓業務應用生效，而線上應用重啓流量有損。導致難以頻繁升級探針版本，快速引入新功能。
- 每天實時寫入150億條，峯值流量 300w 條/s。數據導入容易丟失；檢索單條調用鏈性能查，大概需要100多秒。
2019年，鳳睛進行了進一步的改造升級，針對1、2兩個問題，進行了技術攻堅。
探針層面研究如何支持熱插拔，也就是探針在業務進程運行的情況下自動完成升級。起初爲了保證業務類對探針插件類的可見性，探針類統一放到了 System Classloader裏。但是System Classloader 作爲系統默認的，不支持卸載。反之，如果把探針類全部放到自定義類加載器中。探針類則對業務類完全不可見，也就無法完成字節碼增強。
探針熱插拔classloader體系如下圖：
爲了解決可見性問題，探針引入了橋接類，通過橋接類提供的代碼樁和插件類庫投影，用戶類可以訪問實際使用的探針類，完成監控改造的目的。對於不同插件，則放在不同的自定義 Classloader 裏面。這樣來插件之間互不可見。單個插件也可以完成熱插拔。具體的設計細節後面會有文章詳細解讀。毋庸置疑，鳳睛探針是業界唯一能夠熱插拔的監控探針技術，我們也申請了專利。它的功能正確性和性能是經歷過大規模線上流量驗證的。
繼續推進優化調用鏈檢索的性能。首先分析下我們的底層存儲結構：
通過對慢查詢的分析，發現檢索慢主要是兩個原因：一是大量查詢沒有走任何索引，全表掃描海量數據非常慢。二是，導入碎片過多，導致文件Compaction特別慢，典型的LSM-Tree 的讀放大。爲了解決這些問題，調用鏈存儲層重構表結構，通過大量Rollup配合基本表，優化查詢時間。Doris 此時已經具備流式導入的能力，也藉機從小批量導入切換到流式導入。
最終，調用鏈處理架構如下：
下圖是鳳睛實時構建的微服務全景拓撲圖。截止2020年1月，大概涵蓋了數十條產品線的線上流量拓撲，最細粒度的節點爲接口，即 Java 應用中的函數。從圖中可以分析出，託管全平臺非孤島接口節點大概有50w+，接口節點連線200w+ 條。
六、數據處理架構分離
架構繼續演進，鳳睛採集的數據量越來越多，業務方需求也越來越多。
主要面臨2個問題：
- 數據可視化能力依賴於前端開發，大量多維可視化分析需求難以滿足。
- 調用鏈做了採樣，導致統計數據不準確，無法滿足統計報表的需求。
這兩個問題歸根結底是時序數據如何存儲和展現。這涉及到分佈式追蹤領域兩個很基礎的概念，時序時間和調用鏈數據。所謂的時序數據是基於時間的一系列的數據，用於查看一些指標數據和指標趨勢。調用鏈數據是指記錄一個請求的全部流程，用於查看請求在哪個環節出了故障，系統的瓶頸在哪兒。時序數據不需要保存細節，只存時間、維度和指標的數據點, 可以存儲在專門的時間序列數據庫（Time Series Database）。實際場景中，鳳睛沒有專門去維護一個時序數據庫。而是對接百度SIA智能監控平臺的分佈式時序數據庫TSDB。同時，利用百度SIA平臺提供豐富的多維可視化分析報表，用以解決用戶各種可視化多維度數據分析的需求。
當前整體的架構如下圖：
七、結語
鳳睛整個項目前後持續了4年，中間經歷過無數的困難和坎坷，通過積累了項目成員們持續的付出，最終取得里程碑式的成果。本文簡要介紹了鳳睛產品的業務背景、技術架構和產品形態，後續會繼續發文介紹技術相關的實現細節，歡迎持續關注。
長按關注 百度商業平臺技術實踐 ID : cpd-jarvis
一起尋找技術中的光.....
