本文節選自《不一樣的 雙11 技術：阿裡巴巴經濟體雲原生實踐》一書
作者：
周小帆（承嗣） 阿裡雲中間件技術部進階技術專家
王華鋒（水彧） 阿裡雲中間件技術部技術專家
徐彤（紹寬） 阿裡雲中間件技術部技術專家
夏明（涯海） 阿裡雲中間件技術部技術專家
導讀：作為一支深耕多年鍊路追蹤技術 (Tracing) 與性能管理服務 (APM) 的團隊，阿裡巴巴中間件鷹眼團隊的工程師們見證了阿裡巴巴基礎架構的多次更新，每一次的架構更新都會對系統可觀測性能力 (Observability) 帶來巨大挑戰，而這次的“雲原生”更新，給我們帶來的新挑戰又是什麼呢？
雲原生與可觀測性
在剛剛過去的 2019 年 雙11，我們再次見證了一個技術奇迹：這一次，我們花了一整年的時間，讓阿裡巴巴的核心電商業務全面上雲，并且利用阿裡雲的技術基礎設施頂住了 54 萬筆/秒的零點交易峰值；我們的研發、運維模式，也正式步入了雲原生時代。
雲原生所倡導的新範式，給傳統的研發和運維模式帶來巨大沖擊：微服務、DevOps 等理念讓研發變得更高效，但帶來的卻是海量微服務的問題排查、故障定位的難度變得更大；容器化、Kubernetes 等容器編排技術的逐漸成熟讓規模化軟體傳遞變得容易，但帶來的挑戰是如何更精準地評估容量、排程資源，確定成本與穩定性的最好平衡。
今年阿裡巴巴所探索的 Serverless、Service Mesh 等新技術，未來将徹底地從使用者手中接管運維中間件以及 IaaS 層的工作，對于基礎設施的自動化程度來講則是一個更加巨大的挑戰。
基礎設施的自動化（Automation）是雲原生的紅利能夠被充分釋放的前提，而可觀測性是一切自動化決策的基石。
如果每個接口的執行效率、成敗與否都能被精準統計、每一個使用者請求的來龍去脈都能被完整追溯、應用之間以及應用與底層資源的依賴關系能被自動梳理，那我們就能基于這些資訊自動判斷業務的異常根因在哪？是否需要對影響業務的底層資源做遷移、擴容或是摘除？我們就能根據 雙11 的峰值，自動推算出每一個應用所需準備資源是否充分且不浪費。
可觀測性≠監控
許多人會問，“可觀測性”是否就是“監控”換了一個說法，業界對這兩件事的定義其實大相徑庭。
不同于“監控”，監控更加注重問題的發現與預警，而“可觀測性”的終極目标是為一個複雜分布式系統所發生的一切給出合了解釋。監控更注重軟體傳遞過程中以及傳遞後（Day 1 & Day 2)，也就是我們常說的“事中與事後”，而“可觀測性”則要為全研發與運維的生命周期負責。
回到“可觀測性”本身，依舊是由老生常談的“鍊路(Tracing)”、“名額(Metric)”和“日志(Logging)”構成，單獨拉出來看都是非常成熟的技術領域。隻不過這三樣東西與雲基礎設施如何整合？它們之間如何更好地關聯、融合在一起？以及它們如何更好地和雲時代的線上業務做結合？是我們團隊這一兩年來努力探索的方向。
我們今年做了什麼
今年的 雙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上，歡迎大家一起來進行共建。
本書亮點
- 雙11 超大規模 K8s 叢集實踐中，遇到的問題及解決方法詳述
- 雲原生化最佳組合：Kubernetes+容器+神龍，實作核心系統 100% 上雲的技術細節
- 雙 11 Service Mesh 超大規模落地解決方案
“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”