測試小姐姐正在對雲原生的電商應用進行壓測，但是如何對壓測結果進行持續的觀測呢？這一直是比較頭痛的事情，本文将介紹如何利用 DeepFlow 的全景拓撲幫助小姐姐快速找到瓶頸點。DeepFlow 全景拓撲無需業務修改代碼、配置或者重新開機服務，利用 BPF/eBPF 技術通過對業務零侵擾的方式建構而來，這是一種很便捷且低成本的方式來觀測全鍊路壓測的結果。
01｜背景介紹
DeepFlow 線上的 Sandbox 環境中部署了一個雲原生的電商應用，此電商應用來源于 GitHub[1]，此應用覆寫 Go/Java/.NET/PHP/Python 等多種語言，且涵蓋 Redis/Kafka/PostgreSQL 等中間件，所有的這些服務都部署在 K8s 環境中。在做全鍊路壓測時，目前通常的方式需要對應用進行代碼級别的改造，這對于僅負責測試的小姐姐來說又很難推動，接下來将詳細介紹 DeepFlow 的全景拓撲如何輕松解決小姐姐的苦惱。
以下是電商應用微服務的調用關系圖，提供了外網和内網通路的兩種方式。
調用關系
DeepFlow 的 Sandbox 考慮到安全性的問題，僅支援了内網的通路方式，以下是 DeepFlow 的全景拓撲自動繪制的調用關系，接下來的整個過程都将基于此拓撲進行。
全景拓撲
DeepFlow 的全景拓撲可以與多名額進行結合，當名額量超過門檻值時，則将通過标紅的形式可視化出來。在開始接下來壓測及調優過程之前，需要對本次過程中使用到的名額有一個了解。
名額 說明 觀測目标 流量速率 作為主名額，建構全景拓撲 -- 應用請求速率 統計服務的請求速率，主要用于觀測壓測過程中請求量是否符合壓測預期 符合測試壓測的速率 應用異常個數 統計服務的異常個數，主要用于觀測壓測過程中是否存在服務異常的情況 0 應用響應時延 統計服務的響應時延，主要用于觀測壓測過程中響應時延是否超過預期 1s 以内 TCP 建連時延 統計 TCP 建連時延，主要用于觀測壓測過程中網絡是否存在波動 10ms 以内 TCP 建連失敗 統計 TCP 建連失敗，主要用于觀測壓測過程中系統性能是否穩定 0
02｜逐個擊破性能瓶頸
在 loadgenerator 所在的 node，通過腳本模拟 1.5k 的并發通路量，觀測全景拓撲，一片紅（在目前并發量的情況下，觀測的名額量都超過門檻值了），說明了目前這個系統在目前資源配置設定情況下，是扛不住 1.5k 的并發通路量的。檢視名額量，應用響應時延、異常數和網絡建連時延、建連失敗的名額量都遠超門檻值了。
壓測開始
找一個名額量（服務響應時延）來層層追蹤拓撲圖，loadgenerator 通路 frontend 響應時延達到 15s，而 frontend 通路後端服務中，其中通路 productcatalog 及 recommendation 分别都消耗了大概 11s、5s 的時延，其中 productcatalog 沒有繼續往後的通路了，可繼續追蹤 recommendation 通路的後端，其中也是通路 productcatalog 消耗了大概 4s 的時延，到此基本能确定目前應用的性能瓶頸就在 productcatalog 上。
分析拓撲
接下來先直接對 productcatalog 擴容，增加 pod 數量到之前的 1 倍，然後再觀測下全景拓撲，可以看出來拓撲圖上的紅變少一些了，同時觀測下名額量，發現應用的響應時延及異常數都降下來了。
擴容_01
沿着前面的思路，依然使用服務響應時延來層層追蹤拓撲圖，發現通過擴容 1 倍的 POD 數，雖然緩解了 productcatalog 性能壓力，但是還是沒徹底解決。
分析拓撲_01
接下來繼續對 productcatalog 擴容，這次擴容到 2 倍，再觀測全景拓撲，紅色部分更少了，名額量也更接近預期了。不過這次發現解決了 productcatalog 的性能問題後，cart 的性能問題冒出來了。
擴容_02
繼續對 cart 服務的 POD 的數量擴容 1 倍，觀測全景拓撲，發現紅色部分都沒了。到此基本上可以出壓測結果了，針對目前電商應用在 1.5k 的并發通路量的情況下，productcatalog 需要是比其他服務（除 cart 外） 2 倍的資源配置設定，cart 需要比其他服務（除 productcatalog 外） 多 1 倍的資源配置設定才能應對。
擴容_03
03｜名額量分析
再結合曆史曲線圖，來詳細分析下名額量的變化，讓大家能更好的了解為什麼應用的性能問題除了帶來應用名額量的波動，為什麼還會帶了網絡名額量的變化。明顯在 17:48 分後端服務是整個處理不過來的，這時多個名額都能反應此情況。建連失敗很多，在失敗的過程中還不停的重傳 SYN 封包，同時建連失敗的都是因為服務端直接回 RST 導緻，此時僅看這部分名額量已經能清楚是後端系統對連接配接處理不過來了。再繼續結合應用名額量分析，在建連失敗多的情況下，請求量反而下降了，這是因為建連都沒成功，根本發不了請求，此時後端的異常數及響應時延也都是挺高，也是直接反應了後端對請求處理不過來了。
曆史曲線
04｜什麼是 DeepFlow
DeepFlow[2] 是一款開源的高度自動化的可觀測性平台，是為雲原生應用開發者建設可觀測性能力而量身打造的全棧、全鍊路、高性能資料引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技術，創新的實作了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心機制，幫助開發者提升埋點插碼的自動化水準，降低可觀測性平台的運維複雜度。利用 DeepFlow 的可程式設計能力和開放接口，開發者可以快速将其融入到自己的可觀測性技術棧中。
GitHub 位址：https://github.com/deepflowio/deepflow
通路 DeepFlow Demo[3]，體驗高度自動化的可觀測性新時代。
參考資料
[1]GitHub: https://github.com/open-telemetry/opentelemetry-demo
[2]DeepFlow: https://github.com/deepflowio/deepflow
[3]DeepFlow Demo: https://deepflow.io/docs/zh/install/overview/