雙11 背後的全鏈路可觀測性：阿里巴巴鷹眼在「雲原生時代」的全面升級

時間 2019-12-21

原文原文鏈接

點擊下載《不同的雙11 技術：阿里巴巴經濟體雲原生實踐》

本文節選自《不同的雙11 技術：阿里巴巴經濟體雲原生實踐》一書，點擊上方圖片便可下載！html

做者：
周小帆（承嗣）阿里雲中間件技術部高級技術專家
王華鋒（水彧）  阿里雲中間件技術部技術專家
徐彤（紹寬）  阿里雲中間件技術部技術專家
夏明（涯海）  阿里雲中間件技術部技術專家git

導讀：做爲一支深耕多年鏈路追蹤技術 (Tracing) 與性能管理服務 (APM) 的團隊，阿里巴巴中間件鷹眼團隊的工程師們見證了阿里巴巴基礎架構的屢次升級，每一次的架構升級都會對系統可觀測性能力 (Observability) 帶來巨大挑戰，而此次的「雲原生」升級，給咱們帶來的新挑戰又是什麼呢？

雲原生與可觀測性

在剛剛過去的 2019 年雙11，咱們再次見證了一個技術奇蹟：這一次，咱們花了一全年的時間，讓阿里巴巴的核心電商業務全面上雲，而且利用阿里雲的技術基礎設施頂住了 54 萬筆/秒的零點交易峯值；咱們的研發、運維模式，也正式步入了雲原生時代。github

雲原生所倡導的新範式，給傳統的研發和運維模式帶來巨大沖擊：微服務、DevOps 等理念讓研發變得更高效，但帶來的倒是海量微服務的問題排查、故障定位的難度變得更大；容器化、Kubernetes 等容器編排技術的逐漸成熟讓規模化軟件交付變得容易，但帶來的挑戰是如何更精準地評估容量、調度資源，確保成本與穩定性的最好平衡。算法

今年阿里巴巴所探索的 Serverless、Service Mesh 等新技術，將來將完全地從用戶手中接管運維中間件以及 IaaS 層的工做，對於基礎設施的自動化程度來說則是一個更加巨大的挑戰。數據庫

基礎設施的自動化（Automation）是雲原生的紅利可以被充分釋放的前提，而可觀測性是一切自動化決策的基石。安全

若是每一個接口的執行效率、成敗與否都能被精準統計、每個用戶請求的前因後果都能被完整追溯、應用之間以及應用與底層資源的依賴關係能被自動梳理，那咱們就能基於這些信息自動判斷業務的異常根因在哪？是否須要對影響業務的底層資源作遷移、擴容或是摘除？咱們就能根據雙11 的峯值，自動推算出每個應用所需準備資源是否充分且不浪費。架構

可觀測性≠監控

許多人會問，「可觀測性」是否就是「監控」換了一個說法，業界對這兩件事的定義其實截然不同。併發

不一樣於「監控」，監控更加註重問題的發現與預警，而「可觀測性」的終極目標是爲一個複雜分佈式系統所發生的一切給出合理解釋。監控更注重軟件交付過程當中以及交付後（Day 1 & Day 2)，也就是咱們常說的「事中與過後」，而「可觀測性」則要爲全研發與運維的生命週期負責。框架

回到「可觀測性」自己，依舊是由老生常談的「鏈路(Tracing)」、「指標(Metric)」和「日誌(Logging)」構成，單獨拉出來看都是很是成熟的技術領域。只不過這三樣東西與雲基礎設施如何整合？它們之間如何更好地關聯、融合在一塊兒？以及它們如何更好地和雲時代的在線業務作結合？是咱們團隊這一兩年來努力探索的方向。less

咱們今年作了什麼

今年的雙11，鷹眼團隊的工程師們在四個新方向的技術探索，爲集團業務全面上雲、雙11 的自動化備戰與全局穩定性提供了強有力的保障：

面向場景化的業務可觀測性

隨着阿里巴巴電商業態不斷的複雜與多元化，大促備戰也不斷趨向於精細化與場景化。

以往的備戰方式，是各個微服務系統的負責人根據所負責系統的自身以及上下游狀況，各自爲戰。這樣分而治之的作法雖然足夠高效，卻不免有疏漏，根本緣由在於中臺應用與實際業務場景的錯位關係。以交易系統爲例，一個交易系統會同時承載天貓、盒馬、大麥、飛豬等多種類型的業務，而每種業務的預期調用量、下游依賴路徑等均不相同，做爲交易系統的負責人，很難梳理清楚每種業務的上下游細節邏輯對自身系統的影響。

今年鷹眼團隊推出了一種場景化鏈路的能力，結合業務元數據字典，經過無侵入自動打標的手段實現流量染色，將實際的流量業務化，打通了業務與下游各中間件的數據，從以往以應用爲中心的視圖，轉變成了以業務場景爲中心，也所以更加貼近於真實的大促模型。

如上圖所示，這是一個查詢商品的案例，四個系統 A、B、C、D 分別提供「商品詳情」、「商品類型」、「價格詳情」和「優惠詳情」的查詢能力。入口應用 A 提供了一個商品查詢的接口 S1，經過鷹眼，咱們能夠很快地發現應用 B、C、D 屬於應用 A 的依賴，同時也是接口 S1 的下游，對於系統穩定性的治理而言，有這樣一份鏈路數據已經足夠。

但其實這樣的視角並不具有業務的可觀測性，由於在這樣的一個依賴結構中包含着兩種業務場景，這兩種場景所對應的鏈路也是徹底不一樣的：甲類商品所對應的鏈路是 A->B->C-D，而乙類商品對應的鏈路是A->B->C。假設平常態這兩類商品的佔比是 1:1，而大促態的佔比是 1:9，那麼僅從系統的角度或者業務的角度去梳理鏈路，是沒法獲得一個合理的流量預估模型的。

因此，若是咱們能在系統層經過打標的方式把兩種流量染色，就能很方便地梳理出兩種業務場景所對應的的鏈路，這樣一份更加精細化的視角對於保證業務的穩定性、以及更加合理的依賴梳理和限流降級策略的配置顯得尤其重要。

這樣的業務場景化能力在今年的雙11 備戰中發揮了巨大的價值，不少業務系統都基於這樣的能力梳理出了本身核心的業務鏈路，備戰更加從容且不會有遺漏；同時，一系列的服務治理工具，在鷹眼的賦能下，進行了全面的場景化升級，例如針對場景化的流量錄製和回放、場景化的故障演練工具、場景化的精準測試迴歸等等。配合這些更加貼合業務場景的服務治理工具，幫助整個雙11 備戰的可觀測性顆粒度走進了「高清時代」。

基於可觀測性數據的智能根因定位

雲原生時代，隨着微服務等技術的引入，業務規模的增加，應用的實例數規模不斷增加，核心業務的依賴也變得越發複雜。一方面咱們享受着開發效率的指數提高的紅利，同時也在承受着故障定位成本居高不下的痛苦。特別是當業務出現問題的時候，如何快速發現問題和止血變得很是困難。鷹眼團隊做爲集團內應用性能的「守護神」，如何幫助用戶快速完成故障定位成爲今年的新挑戰。

要完成故障定位，首先要回答，什麼是你認爲的故障？這背後須要運維人員對業務深層次的理解，不少維護人員喜歡使用窮舉式的手段配上全部可觀測性的指標，各類告警加上，顯得有「安全感」，實際上當故障來臨時，滿屏出現指標異常、不斷增長的告警短信，這樣的「可觀測性」看上去功能強大，實際效果卻拔苗助長。

團隊對集團內的歷年故障作了一次仔細梳理，集團內的核心應用一般有四類故障(非業務自身邏輯問題)：資源類、流量類、時延類、錯誤類。

再往下細分：

資源類: 好比 cpu、load、mem、線程數、鏈接池；
流量類：業務流量跌零 OR 不正常大幅度上漲下跌，中間件流量如消息提供的服務跌零等；
時延類：系統提供的服務 OR 系統依賴的服務，時延忽然大幅度飆高了，基本都是系統有問題的前兆；
錯誤類：服務返回的錯誤的總數量，系統提供服務 OR 依賴服務的成功率。

有了上面這些故障分類做爲抓手後，後面要作的就是「順藤摸瓜」，惋惜隨着業務的複雜性，這根「藤」也來越長，以時延突增這個故障爲例，其背後就隱藏着不少可能的根因：有多是上游業務促銷致使請求量突增致使，有多是應用自身頻繁 GC 致使應用總體變慢，還有多是下游數據庫負載過大致使響應變慢，以及數不勝數的其它各類緣由。

鷹眼之前僅僅提供了這些指標信息，維護人員光看單條調用鏈數據，鼠標就要滾上好幾番才能看完一條完整的 tracing 數據，更別說跨多個系統之間來回切換排查問題，效率也就無從談起。

故障定位的本質就是一個不斷排查、否認、再排查的過程，是一個「排除掉全部的不可能，剩下的就是真相」的過程。仔細想一想可枚舉的可能+可循環迭代的過程，這個不就是計算機最擅長的處理動做嗎？故障定位智能化項目在這樣的背景下誕生了。

提起智能化，不少人第一反應是把算法關聯在一塊兒，把算法過分妖魔化。其實瞭解機器學習的同窗應該都知道：數據質量排第一，模型排第二，最後纔是算法。數據採集的可靠性、完整性與領域模型建模纔是核心競爭力，只有把數據化這條路走準確後，纔有可能走智能化。

故障定位智能化的演進路線也是按照上面的思路來逐步完成的，但在這以前咱們先得保障數據的質量：得益於鷹眼團隊在大數據處理上深耕多年，數據的可靠性已經能獲得很是高質量的保障，不然出現故障還得先懷疑是否是本身指標的問題。

接下來就是數據的完備性和診斷模型的建模，這兩部分是智能化診斷的基石，決定了故障定位的層級，同時這兩部分也是相輔相成的，經過診斷模型的構建能夠對可觀測性指標查漏補缺，經過補齊指標也能夠增長診斷模型的深度。

主要經過如下 3 方面結合來不斷地完善：

第一，歷史故障推演，歷史故障至關於已經知道標準答案的考卷，經過部分歷史故障+人工經驗來構建最初的診斷模型，而後迭代推演其他的歷史故障，可是這一步出來的模型容易出現過擬合現象；
第二，利用混沌工程模擬常見的異常，不斷修正模型；
第三，線上人爲打標的方式，來繼續補齊可觀測性指標、修正診斷模型。

通過以上三個階段以後，這塊基石基本創建完成了。接下來就要解決效率問題，從上面幾步迭代出來的模型其實並非最高效的，由於人的經驗和思惟是線性思惟，團隊內部針對現有模型作了兩方面的工做：邊緣診斷和智能剪枝。將定位的過程部分下沉到各個代理節點，對於一些可能對系統形成影響的現象自動保存事發現場關鍵信息同時上報關鍵事件，診斷系統自動根據各個事件權重進行定位路徑智能調整。

智能根因定位上線後，累計幫助數千個應用完成故障根因定位，並取得了很高的客戶滿意度，基於根因定位結論爲抓手，可觀測性爲基石，基礎設施的自動化能力會獲得大大提高。今年的雙11 大促備戰期間，有了這樣的快速故障定位功能，爲應用穩定性負責人提供了更加自動化的手段。咱們也相信在雲原生時代，企業應用追求的運行的質量、成本、效率動態平衡再也不是高不可攀，將來可期！

最後一千米問題定位能力

什麼是「最後一千米」的問題定位？「最後一千米」的問題有哪些特色？爲何不是「最後一百米」、「最後一米」？

首先，咱們來對齊一個概念，什麼是「最後一千米」？在平常生活中，它具有如下特色：

走路有點遠，坐車又太近，不近不遠的距離很難受；
最後一千米的路況很是複雜，多是寬闊大道，也多是崎嶇小路，甚至是宛如迷宮的室內路程（這點外賣小哥應該體會最深）。

那麼分佈式問題診斷領域的最後一千米又是指什麼呢，它又具有哪些特徵？

在診斷流程上，此時已經離根因不會太遠，基本是定位到了具體的應用、服務或節點，可是又沒法肯定具體的異常代碼片斷；
可以定位根因的數據類型比較豐富，多是內存佔用分析，也多是 CPU 佔用分析，還多是特定的業務日誌/錯誤碼，甚至只是單純的從問題表象，結合診斷經驗快速肯定結論。

經過上面的分析，咱們如今已經對最後一千米的概念有了一些共識。下面，咱們就來詳細介紹：如何實現最後一千米的問題定位？

首先，咱們須要一種方法，能夠準確的到達最後一千米的起點，也就是問題根因所在的應用、服務或是機器節點。這樣能夠避免根源上的無效分析，就像送外賣接錯了訂單。那麼，如何在錯綜複雜的鏈路中，準確的定界根因範圍？這裏，咱們須要使用 APM 領域較爲經常使用的鏈路追蹤（Tracing）的能力。經過鏈路追蹤可以準確的識別、分析異常的應用、服務或機器，爲咱們最後一千米的定位指明方向。

而後，咱們經過在鏈路數據上關聯更多的細節信息，例如本地方法棧、業務日誌、機器狀態、SQL 參數等，從而實現最後一千米的問題定位，以下圖所示：

核心接口埋點： 經過在接口執行先後插樁埋點，記錄的基礎鏈路信息，包括 TraceId、RpcId（SpanId）、時間、狀態、IP、接口名稱等。上述信息能夠還原最基礎的鏈路形態；
自動關聯數據： 在調用生命週期內，能夠自動記錄的關聯信息，包括 SQL、請求出入參數、異常堆棧等。此類信息不影響鏈路形態，但倒是某些場景下，精準定位問題的必要條件；
主動關聯數據： 在調用生命週期內，須要人爲主動記錄的關聯數據，一般是業務數據，好比業務日誌、業務標識等。因爲業務數據是很是個性化的，沒法統一配置，但與鏈路數據主動關聯後，能夠大幅提高業務問題診斷效率；
本地方法棧： 因爲性能與成本限制，沒法對全部方法添加鏈路埋點。此時，咱們能夠經過方法採樣或在線插樁等手段實現精準的本地慢方法定位。

經過最後一千米的問題定位，可以在平常和大促備戰態深度排查系統隱患，快速定位根因，下面舉兩個實際的應用案例：

某應用在總體流量峯值時出現偶發性的 RPC 調用超時，經過分析自動記錄的本地方法棧快照，發現實際耗時都是消耗在日誌輸出語句上，緣由是 LogBack 1.2.x 如下的版本在高併發同步調用場景容易出現「熱鎖」，經過升級版本或調整爲異步日誌輸出就完全解決了該問題；
某用戶反饋訂單異常，業務同窗首先經過該用戶的 UserId 檢索出下單入口的業務日誌，而後根據該日誌中關聯的鏈路標識 TraceId 將下游依賴的全部業務流程、狀態與事件按實際調用順序進行排列，快速定位了訂單異常的緣由（UID 沒法自動透傳到下游全部鏈路，但 TraceId 能夠）。

監控告警每每只能反映問題的表象，最終問題的根因還須要深刻到源碼中去尋找答案。鷹眼今年在診斷數據的「精細採樣」上取得了比較大的突破，在控制成本不膨脹的前提下，大幅提高了最後一千米定位所需數據的精細度與含金量。在整個雙11 漫長的備戰期中，幫助用戶排除了一個又一個的系統風險源頭，從而保障了大促當天的「絲般順滑」。

全面擁抱雲原生開源技術

過去一年，鷹眼團隊擁抱開源技術，對業界主流的可觀測性技術框架作了全面集成。咱們在阿里雲上發佈了鏈路追蹤（Tracing Analysis）服務，兼容 Jaeger(OpenTracing)、Zipkin、Skywalking 等主流的開源 Tracing 框架，已經使用了這些框架的程序，能夠不用修改一行代碼，只須要修改數據上報地址的配置文件，就可以以比開源自建低出許多的成本得到比開源 Tracing 產品強大許多的鏈路數據分析能力。

鷹眼團隊同時也發佈了全託管版的 Prometheus 服務，解決了開源版本部署資源佔用過大、監控節點數過多時的寫入性能問題，對於長範圍、多維度查詢時查詢速度過慢的問題也作了優化。優化後的 Prometheus 託管集羣在阿里巴巴內全面支持了 Service Mesh 的監控以及幾個重量級的阿里雲客戶，咱們也將許多優化點反哺回了社區。一樣，託管版的 Prometheus 兼容開源版本，在阿里雲的容器服務上也能夠作到一鍵遷移到託管版。

可觀測性與穩定性密不可分，鷹眼的工程師們今年將這些年來可觀測性、穩定性建設等相關一系列的文章、工具作了整理，收錄在了 Github 上，歡迎你們一塊兒來進行共建。