涯海 阿裡巴巴中間件 2023-04-27 20:01 發表于浙江
前文回顧：
基礎篇｜鍊路追蹤（Tracing）其實很簡單
使用篇｜鍊路追蹤（Tracing）其實很簡單：請求軌迹回溯與多元鍊路篩選
使用篇丨鍊路追蹤（Tracing）很簡單：鍊路實時分析、監控與告警
最近一年，小玉所在的業務部門發起了轟轟烈烈的微服務化運動，大量業務中台應用被拆分成更細粒度的微服務應用。為了迎接即将到來的雙十一大促重保活動，小玉的主管讓她在一周内梳理出訂單中心的全局關鍵上下遊依賴，提前拉通各方對齊重保方案。這個任務可愁壞了小玉，平時她隻與直接上下遊業務方打交道，現在要梳理出訂單中心完整的依賴路徑，頭發愁掉了一大把仍然不知道該如何下手。無奈之下，小玉再次求助于萬能的小明。
針對小玉的問題，小明提出了一個想法，首先調用鍊可以追蹤一次請求的完整調用路徑，但是單條調用鍊無法反映出所有的調用分支，也無法通過流量大小展現出依賴的強弱，而逐條分析調用鍊的成本又太高。那麼，是否可以通過程式将一批具有相同特征（比如經過某個應用，或者調用了某個接口）的調用鍊聚合成一顆樹，通過分析這棵樹的形态與流量，就可以快速梳理出關鍵節點與依賴路徑，而這就是鍊路拓撲功能的雛形。
如上圖所示，入口應用 A 依賴了多個不同深度的下遊應用，并且每次調用的路徑并不相同。為了梳理出應用 A 的完整調用依賴，可以将多條調用鍊聚合成一棵樹，從根節點到葉子節點的每條路徑都代表着一種流量流轉路徑，而節點的狀态反映了流量的特征，比如次數、耗時、錯誤率等。通過調用鍊聚合，綜合分析端到端流量路徑與狀态的方法就是鍊路拓撲。鍊路拓撲與調用鍊的關系就好比樣本集與離散樣本點，前者反映了整體的分布情況，可以有效避免單個樣本随機性對評估結果的影響。
01
鍊路拓撲的經典應用場景
Aliware
鍊路拓撲最核心的價值，就是通過分析節點間依賴路徑與狀态，提供強弱依賴梳理、瓶頸點分析、影響面分析、故障傳播鍊分析等能力，下面我們來深入了解下這些經典用法。
（一）強弱依賴梳理
鍊路拓撲最典型、最被人熟知的應用場景就是依賴梳理，特别是在一個大型分布式系統中，數以萬計的應用間依賴關系複雜到令運維同學懷疑人生。下圖展示了 2012 年的淘寶核心鍊路應用拓撲，密密麻麻如蛛網般的依賴關系已經遠遠超出了人工梳理的範疇，而這種情況在微服務迅猛發展的當下并不少見。
在複雜業務環境中，不僅需要梳理出依賴關系圖，還需要識别哪些是影響核心業務的強依賴，哪些是“無傷大雅”的弱依賴。針對強依賴要投入更多的人力與資源，建立更加完善的保障體系，比如電話告警，聯合壓測等。針對弱依賴，可以考慮是否能夠移除，或者建立次一級的保障措施。
區分強弱依賴的方式主要有以下幾種：
- 根據流量大小進行區分。這是一種簡單粗暴的區分方式，大于一定流量門檻值或比例的就識别為強依賴，否則視為弱依賴。這種判斷方式的好處是簡單清晰，可以由鍊路追蹤平台自動識别，無需人力幹預。缺點是不夠準确，一些特殊的關鍵依賴雖然流量不大，但是卻會直接影響業務的穩定性。
- 根據同步/異步調用類型進行區分。這種區分方式的好處也是簡單、易操作，減少了異步非阻塞（如消息）調用的幹擾。缺點是在同步調用為主的業務中篩選效果不佳，而在異步調用為主的業務（紅包、熱點推送）可能造成誤判。
- 人工标注。鑒于業務的差異性，由業務 Owner 對自身依賴的直接下遊的強弱性進行人工标注識别，可靠性會更高。但是這種方式對于人員經驗和時間成本要求很高，并且無法自适應業務的變化。
- 半人工标注。首先由鍊路追蹤平台根據流量大小、同步/異步進行初步的強弱依賴識别，再通過有經驗的同學進行人工标注修正。這樣既節省了人力成本，也能有限度的自适應未來的業務變化。
強弱依賴梳理是相對低頻的工作，通常發生在在大促或重保活動準備階段、新應用上線或老應用下線、上雲搬站等場景。比如阿裡在每年雙十一大促前，都會梳理核心業務的強弱依賴，并與往年進行對比，以便更好的進行針對性保障。
（二）瓶頸點/影響面分析
鍊路拓撲在問題診斷領域最常見的用法就是瓶頸點分析與影響面分析。前者是從目前節點向下遊尋找導緻問題發生的原因，主要用于問題定位；而後者是從問題節點向上遊分析被影響的範圍，主要用于業務風險定級。
接下來，我們通過一個資料庫異常的案例，對比下這兩種用法與視角的差別，如下圖所示。
- 某天上午，應用 A 的管理者收到使用者回報服務響應逾時，通過檢視鍊路拓撲狀态，發現 A 應用依賴的 D 應用接口變慢，而 D 應用調用資料庫接口也出現異常。是以，小 A 通知小 D 即刻排查資料庫連接配接等狀态，盡快恢複可用性。這就是一個瓶頸點分析的過程。
- 由于小 D 業務不熟練，半小時過去了還沒有完成有效的恢複動作，并且觸發了資料庫服務端異常。負責 DB 運維的同學收到資料庫服務端告警後，通過鍊路拓撲向上回溯業務影響面，發現直接依賴的 D、E 兩個應用均出現了大量慢 SQL，并導緻間接依賴的應用 A、B 出現不同程度的服務響應逾時。果斷執行了資料庫擴容，最終恢複了全部應用的正常通路。這就是通過影響面分析，輔助運維決策的過程。
瓶頸點與影響面分析主要是基于一段時間内的靜态拓撲資料，并沒有展現時間變化對拓撲節點狀态的影響，無法回溯故障傳播的過程。如上圖右側所示，如果隻看這一張拓撲，我們難以判斷出導緻資料庫服務端異常的應用到底是 D 還是 E。那麼，是否能夠動态回放鍊路拓撲的變化，更直覺的分析問題源與傳播趨勢？答案無疑是肯定的，請看下文介紹。
（三）故障傳播鍊分析
抛開時間的次元，問題源與影響面的邊界并不是很清晰。一個被影響方可能會成為新的問題源，引發更大的故障。是以，為了能夠更加真實的還原故障演變過程，我們需要觀察并對比一組時間線連續的靜态鍊路拓撲快照集，通過不同快照之間節點狀态的變化還原故障傳播鍊。這就好比通過監控視訊還原兇案發生過程，要比單獨的一張照片更加可靠。
以上一小節的資料庫故障為例，一開始應用 D 由于請求緩存未命中，進而大量請求資料庫導緻慢 SQL，進而影響上遊應用也出現響應逾時。随着情況繼續惡化，資料庫服務端也開始過載，進而影響了應用 E 的正常調用。最後，應用 A、B 均出現大量響應逾時，API 網關由于連接配接不足開始拒絕通路，引發更大面積的服務不可用。
在真實生産環境中，拓撲依賴與故障傳播的過程可能會更加複雜，為了簡化分析過程，可以根據一定規則将節點狀态提取為各類異常事件，觀察不同時刻的異常事件數量也可以輔助判斷故障發生、傳播與恢複的過程，如下圖所示。
02
鍊路拓撲聚合次元
Aliware
鍊路拓撲的聚合次元決定着拓撲節點的類型，面向不同的使用者角色，提供了差異化的分析視角。在實際應用中，最典型的三種鍊路拓撲聚合次元分别是應用、接口與自定義次元，分别對應着應用拓撲、接口拓撲和業務拓撲。
- 應用拓撲， 顧名思義就是根據應用名稱進行鍊路聚合，反映了應用間的依賴關系與總體流量狀态。由于資料聚合粒度較粗，局部異常會被平均值掩蓋，不适合精細化的問題診斷，更适合全局依賴梳理與重大故障定界，使用者角色偏向于 PE 運維或 SRE 穩定性負責人。
- 接口拓撲， 是在服務接口這一次元進行的鍊路聚合，相比于應用拓撲更貼近研發視角，因為日常疊代的對象通常是某個具體的服務接口，無論是新接口上線、老接口下線或核心接口重保，接口粒度的鍊路拓撲更符合研發測試流程與職責劃分習慣。應用與接口都是鍊路追蹤領域的基礎對象，對應的拓撲可以由鍊路追蹤平台自動生成，無需過多的人工幹預，使用起來較為友善。
- 業務拓撲， 是根據自定義次元聚合生成的偏業務視角的鍊路拓撲，通常比接口次元要更深一級，比如某個下單接口可以根據商品類目次元進一步細分為女裝或家電，如下圖所示。業務拓撲一般無法由鍊路追蹤平台自動生成，需要使用者結合業務特性定制聚合規則。此外，自定義次元的來源比較廣泛，可以是手動添加的 Attributes 自定義标簽，也可以是 HTTP 請求出入參，或者是所在機器的環境标簽。在這方面，開源社群缺乏相應的标準，而各大廠商的商業化實作差異也比較大。
綜上所述，不同聚合次元生成的鍊路拓撲具備不同功能定位與特性，如下表所示：
03
鍊路拓撲生成方式
Aliware
為了最大程度的保留鍊路資料的端到端關聯資訊，鍊路拓撲通常是基于調用鍊明細資料直接聚合生成，而不是基于名額資料的二次聚合。細心的讀者可能會發現這裡隐藏着一個頗具挑戰的技術難題，就是如何平衡海量鍊路資料聚合的實時性、準确性與靈活性。理想情況下，我們希望基于符合條件的全量調用鍊明細資料快速生成最真實的鍊路拓撲，實作“又快又準又靈活”。但在實際應用中，魚與熊掌不可兼得，我們隻能在“快”、“準”、“靈活”之間進行抉擇，也是以衍生出了不同的鍊路拓撲生成流派。
（一）實時聚合
實時聚合是根據使用者指定查詢條件，動态篩選調用鍊并生成拓撲圖的一種方式。這種方式的好處是實時性較高，使用非常靈活，可以指定任意條件，比如檢視大于 3S 的調用鍊生成的拓撲，或者僅包含異常調用的拓撲。缺點是當滿足條件的調用鍊明細資料量超過一定門檻值後，可能會打爆實時聚合計算節點，是以，通過會設定一個聚合條數上限，比如5千條，犧牲一定的資料精确度，換來極高的靈活度與實時性。
（二）離線聚合
離線聚合是根據一組事先定義好的聚合規則，周期性生成拓撲資料的一種方式。例如不包含任何篩選條件的應用、接口這種基礎拓撲資料就可以通過離線聚合生成。這種聚合方式的好處是可以利用離線計算的水準擴充性，支撐海量鍊路資料的聚合計算，生成結果會更加準确。缺點是實時性較差，聚合規則變更到新拓撲生成的周期較長。離線聚合通常用于全局拓撲資料的精确計算。
（三）預聚合
預聚合是一種理論上可行的拓撲生成方式，它的思路是從入口節點開始，不斷向下透傳全鍊路的完整調用路徑資訊，并在端側生成相應的預聚合名額。不考慮透傳資訊的長度限制與端側預聚合開銷，這種方式的好處就是節省了在服務端将明細資料轉化為拓撲資料的過程，實作又快又準的目标。但是缺陷就是不支援自定義規則，否則透傳與預聚合的開銷會直線上升，影響業務程序的性能與穩定性。預聚合的原理示意圖如下所示。
04
3D 拓撲
Aliware
流量與資源是一對“好兄弟”，二者密切相關。流量影響着資源配置設定，而資源反過來又限制着流量狀态。大部分流量異常歸根結底是資源配額不足或配置設定不合理導緻的，比如峰值流量瞬間耗盡資源，或者流量不均導緻的“熱點”等。我們在定位流量異常根因的過程中，往往需要結合相對應的資源狀态進行分析；反過來，當一個資源節點出現異常時，我們也希望知道它會影響其上運作的哪些流量？是以，在代表流量的鍊路拓撲上，關聯相對應的資源資料，形成更加完整的 3D 拓撲，貌似是個不錯的選擇。
如下圖所示，3D 拓撲不僅包含 PaaS 層的應用、接口流量節點狀态與依賴，還可以下鑽檢視相對應的 IaaS 層程序、執行個體等資源狀态。3D 拓撲為流量與資源建立了一個連接配接，幫助我們更直覺的定位資源瓶頸引發的流量異常問題。
3D 拓撲以一種巧妙的方式傳遞了更多的資訊，但是它也有一個非常緻命的缺陷，就是資訊密度過于集中。在複雜拓撲環境下，表現可能還不如 2D 拓撲來的直覺，大大降低了它的實用價值。如下圖所示，當執行個體規模達到數百，接口數量達到上千時，3D 拓撲互動上的複雜性顯著降低了診斷排查的效率，更多用于大屏展示。
為了降低 3D 拓撲的互動成本，一種可能的思路是結合智能診斷技術，自動突出異常鍊路，精準收斂展示資料範圍。不過，這對于技術與産品的要求較高，實用性還有待大量真實生産環境的檢驗。
閱讀原文