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