導讀：作為鳳睛早期的接入方、後期的核心成員，筆者經曆了整個項目前後四年的變遷，看過項目的艱難開端、中期的默默積累以及後期的蓬勃發展。每一次架構的變遷都帶着技術浪潮的烙印，也看到項目成員利用有限資源來解決實際問題而持續不斷的創新。
鳳睛是百度商業業務系統的性能監控系統（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架構設計中，項目組成員一直在思考兩個問題：
- 如何讓業務方快速接入，盡量少改動，甚至“無感覺接入”？
- 如何降低架構運維難度，既能處理海量資料，又能低成本運維？
為了解決問題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體系的成熟完善，單體能夠被快速拆分成了數目衆多的微服務，依托平台進行高效的運維部署。鳳睛作為基礎元件被微服務托管平台內建，并得到公司級的推廣應用，整體部署應用規模從百級别激增到了千級别，部署容器從千級别變成了萬級别。
這個階段爆發了很多問題，技術核心問題主要有兩點：
- 探針更新需要重新開機業務應用生效，而線上應用重新開機流量有損。導緻難以頻繁更新探針版本，快速引入新功能。
- 每天實時寫入150億條，峰值流量 300w 條/s。資料導入容易丢失；檢索單條調用鍊性能查，大概需要100多秒。
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年，中間經曆過無數的困難和坎坷，通過積累了項目成員們持續的付出，最終取得裡程碑式的成果。本文簡要介紹了鳳睛産品的業務背景、技術架構和産品形态，後續會繼續發文介紹技術相關的實作細節，歡迎持續關注。
閱讀原文
百度搜尋與推薦引擎的雲原生改造
最後歡迎各位關注我們的同名公衆号「百度Geek說」～