綜述
阿里巴巴電子商務平臺現在是一個由很多個應用集羣組成的非常複雜的分佈式系統。這些應用裏面主要有處理用戶請求的前端系統和有提供服務的後端系統等，各個應用之間一般有RPC調用和異步消息通訊兩種手段，RPC 調用會產生一層調一層的嵌套，一個消息發佈出來更會被多個應用消費。另外，應用還會訪問分庫分表的數據庫、緩存、存儲等後端，以及調用其他外部系統如支付、物流、機彩票等。
請試想一下，現在淘寶一個買家點擊下單按鈕所產生的網絡請求到達淘寶服務器之後，就會觸發淘寶內網數百次的網絡調用。這些調用中有哪些出問題會影響這次交易，有哪些步驟會拖慢整個處理流程，雙十一的交易高峯需要給應用集羣分配多少臺機器，這些都是支撐雙十一需要考慮的。但是調用環境的複雜度，已經很難用人力去做準確的分析和評估了，這時候EagleEye就派上了用場。
4.1、EagleEye
EagleEye （鷹眼）是Google 的分佈式調用跟蹤系統 Dapper 在淘寶的實現。分佈式調用跟蹤的意思，就是對一次前端請求產生的分佈式調用都彙總起來做分析。同一次請求的所有相關調用的情況，在EagleEye裏稱作調用鏈。同一個時刻某一臺服務器並行發起的網絡調用有很多，怎麼識別這個調用是屬於哪個調用鏈的呢？我們可以在各個發起網絡調用的中間件上下手。
在前端請求到達服務器時，應用容器在執行實際業務處理之前，會先執行EagleEye的埋點邏輯（類似Filter的機制），埋點邏輯爲這個前端請求分配一個全局唯一的調用鏈ID。這個ID在EagleEye 裏面被稱爲 TraceId，埋點邏輯把TraceId 放在一個調用上下文對象裏面，而調用上下文對象會存儲在ThreadLocal裏面。調用上下文裏還有一個ID非常重要，在EagleEye裏面被稱作RpcId。RpcId用於區分同一個調用鏈下的多個網絡調用的發生順序和嵌套層次關係。對於前端收到請求，生成的RpcId固定都是0。
當這個前端執行業務處理需要發起RPC調用時，淘寶的RPC調用客戶端HSF會首先從當前線程ThreadLocal上面獲取之前EagleEye設置的調用上下文。然後，把RpcId遞增一個序號。在EagleEye裏使用多級序號來表示RpcId，比如前端剛接到請求之後的RpcId是0，那麼它第一次調用RPC服務A時，會把RpcId改成0.1。之後，調用上下文會作爲附件隨這次請求一起發送到遠程的HSF服務器。
HSF服務端收到這個請求之後，會從請求附件裏取出調用上下文，並放到當前線程ThreadLocal上面。如果服務A在處理時，需要調用另一個服務，這個時候它會重複之前提到的操作，唯一的差別就是RpcId會先改成0.1.1再傳過去。服務A的邏輯全部處理完畢之後，HSF在返回響應對象之前，會把這次調用情況以及TraceId、RpcId都打印到它的訪問日誌之中，同時，會從ThreadLocal清理掉調用上下文。如圖4-1展示了一個瀏覽器請求可能觸發的系統間調用。
圖4-1-一個瀏覽器請求可能觸發的系統間調用
圖4-1描述了EagleEye在一個非常簡單的分佈式調用場景裏做的事情，就是爲每次調用分配TraceId、RpcId，放在ThreadLocal的調用上下文上面，調用結束的時候，把TraceId、RpcId打印到訪問日誌。類似的其他網絡調用中間件的調用過程也都比較類似，這裏不再贅述了。訪問日誌裏面，一般會記錄調用時間、遠端IP地址、結果狀態碼、調用耗時之類，也會記錄與這次調用類型相關的一些信息，如URL、服務名、消息topic等。很多調用場景會比上面說的完全同步的調用更爲複雜，比如會遇到異步、單向、廣播、併發、批處理等等，這時候需要妥善處理好ThreadLocal上的調用上下文，避免調用上下文混亂和無法正確釋放。另外，採用多級序號的RpcId設計方案會比單級序號遞增更容易準確還原當時的調用情況。
最後，EagleEye分析系統把調用鏈相關的所有訪問日誌都收集上來，按TraceId彙總在一起之後，就可以準確還原調用當時的情況了。
圖4-2-一個典型的調用鏈
如圖4-2所示，就是採集自淘寶線上環境的某一條實際調用鏈。調用鏈通過樹形展現了調用情況。調用鏈可以清晰的看到當前請求的調用情況，幫助問題定位。如上圖，mtop應用發生錯誤時，在調用鏈上可以直接看出這是因爲第四層的一個(tair@1)請求導致網絡超時，使最上層頁面出現超時問題。這種調用鏈，可以在EagleEye系統監測到包含異常的訪問日誌後，把當前的錯誤與整個調用鏈關聯起來。問題排查人員在發現入口錯誤量上漲或耗時上升時，通過EagleEye查找出這種包含錯誤的調用鏈採樣，提高故障定位速度。
調用鏈數據在容量規劃和穩定性方面的分析
如果對同一個前端入口的多條調用鏈做彙總統計，也就是說，把這個入口URL下面的所有調用按照調用鏈的樹形結構全部疊加在一起，就可以得到一個新的樹結構（如圖4-3所示）。這就是入口下面的所有依賴的調用路徑情況。
圖4-3-對某個入口的調用鏈做統計之後得到的依賴分析
這種分析能力對於複雜的分佈式環境的調用關係梳理尤爲重要。傳統的調用統計日誌是按固定時間窗口預先做了統計的日誌，上面缺少了鏈路細節導致沒辦法對超過兩層以上的調用情況進行分析。例如，後端數據庫就無法評估數據庫訪問是來源於最上層的哪些入口；每個前端系統也無法清楚確定當前入口由於雙十一活動流量翻倍，會對後端哪些系統造成多大的壓力，需要分別準備多少機器。有了EagleEye的數據，這些問題就迎刃而解了。
EagleEye還能得出一些特有的統計數據，幫助各個業務系統評估依賴上的一些潛在風險。我們知道，在正常的分佈式系統裏，異常的發生概率是很低的，長期運行的調用超過千億次，發生錯誤也只會寥寥可數，錯誤信息可能只在日誌中一閃而過就被其他信息湮沒。EagleEye可以抓住線上真實環境“稍縱即逝”的錯誤機會，分析到調用路徑上幾乎每個依賴發生錯誤時對調用鏈整體的影響情況。
圖4-4-弱依賴發生錯誤時的調用鏈
如圖4-4所示，應用 tee由於存在調用錯誤，在 EagleEye 的調用鏈裏被標記爲紅色，但是它的異常並沒有影響調用鏈繼續往下執行。EagleEye裏面把這種依賴識別爲弱依賴。那麼強依賴又是怎樣的呢？如圖4-5所示，tradeplatform的這個調用出現了錯誤，導致當前的入口請求被直接中斷（讀者可以對比上圖的弱依賴裏面，tradeplatform調用正常返回之後還有很多其他的調用會發生），EagleEye把這種類型的依賴標識作強依賴。在雙十一大併發的高壓之下，任何錯誤出現的可能都會被成倍放大。對於系統內的依賴情況我們需要提前做好甄別，儘量降低在關鍵路徑上的強依賴發生錯誤的機會，並把非關鍵依賴降級爲弱依賴。
圖4-5-強依賴發生錯誤時的調用鏈
對於弱依賴，我們也不能掉以輕心。EagleEye識別了另外一種潛在的問題模式。請看下圖的調用鏈，delivery應用發生錯誤時，從調用鏈來看，儘管它是弱依賴，但是因爲它的錯誤佔用了3秒時間，導致整個頁面的響應也長達3秒。從用戶角度看，這是非常不好的體驗；從系統層面看，一個弱依賴錯誤導致系統一個處理線程無法釋放，意味着如果這個弱依賴真的掛了，系統此刻大部分處理線程會有可能都堵塞在這個服務調用上，從而整個系統的吞吐量會降低很多。
圖4-6-弱依賴的超時異常導致線程堵塞
EagleEye可以得到相關的依賴列表，並且對依賴的錯誤影響作了一定判別，通過這份數據，可以再人爲模擬出問題場景來驗證這個異常是否確實存在，處理後再驗證是否徹底修復。相關的內容可以利用後面提到的穩定性平臺做檢測。
4.2、EagleEye雙11準備與優化
- 應對雙十一的日誌輸出問題
EagleEye 的調用日誌是每次網絡調用都會打印一條，在雙十一高峯期日誌的打印量會非常大，如何降低 EagleEye 的日誌輸出對應用的影響呢？
採用通用日誌框架會引入很多不需要的特性，帶了更多性能損耗，爲了提高性能和對寫日誌底層做更細緻的控制，EagleEye 自己實現了日誌輸出：利用無鎖環形隊列做日誌異步寫入來避免hang住業務線程，調節日誌輸出緩衝大小，控制每秒寫日誌的IO次數等。
另外還有很重要的一點就是設置全局採樣開關，用來在運行期控制調用鏈的採樣率。所謂調用鏈採樣，就是根據TraceId來決定當前的這一次訪問日誌是否輸出。比如採樣率被設置爲10時，只有hash(traceId) mod 10的值等於0的日誌纔會輸出，這樣可以保證有一部分調用鏈日誌完全不輸出，有一部分調用鏈會完整輸出。由於核心入口的調用量都在每日百萬次以上級別，樣本空間足夠大，實測開啓1/10的採樣下，調用量統計誤差在0.1%左右，大於10萬以上的調用統計點，誤差超過5% 的概率爲2% 左右，是可以接受的，因此採樣會作爲常態化的配置存在。
小結
EagleEye是基於網絡調用日誌的分佈式跟蹤系統，它可以分析網絡請求在各個分佈式系統之間的調用情況，從而得到處理請求的調用鏈上的入口URL、應用、服務的調用關係，從而找到請求處理瓶頸，定位錯誤異常的根源位置。同時，業務方也可以在調用鏈上添加自己的業務埋點日誌，使各個系統的網絡調用與實際業務內容得到關聯。
系列文章：
《中間件技術及雙十一實踐之中間件總體介紹》http://jm-blog.aliapp.com/?p=3359
《中間件技術及雙十一實踐之軟負載篇》http://jm-blog.aliapp.com/?p=3450
《中間件技術及雙十一實踐·服務框架篇》http://jm-blog.aliapp.com/?p=3462
《中間件技術及雙十一實踐·EagleEye篇》http://jm-blog.aliapp.com/?p=3465
如果覺得內容還行，請分享給更多的人...