應用異常時，基本可以分為服務通路不通和服務響應慢兩個大類。其中服務響應慢的問題定位非常棘手，很多無頭案。應用團隊有日志和追蹤，對于自認為的不可能不合理的事情都會甩給基礎設施團隊，又由于基礎設施團隊現有的監控資料缺乏應用的觀測視角，通常成為一切「不是我的問題」超自然現象的終極背鍋俠，其中以網絡團隊尤為嚴重。
01｜響應時延
服務為什麼響應慢？？？首先，我們需要一種方式來度量何為響應慢，參考 Google 在 SRE Handbook 中提到過4 個黃金信号及 Weave Cloud 提出來的 RED 方法，都存在度量的名額（Latency/Duration），後文統稱為響應時延。
- Latency 表達的是服務處理某個請求所需要的時間，站在的是服務端視角
- Duration 表達的是每個請求所花費的時間，站在的是用戶端視角
總結下來，不論站在什麼視角，響應時延表達的都是處理一個請求所花費的時間，可以用來表征服務響應慢的度量名額，但若要定位為什麼響應慢還需要進一步剖解響應時延：
- 系統時延：系統轉發請求/響應的時延消耗
- 網絡時延：包含查詢 DNS 時延及網絡處理的時延
- 應用時延：從不同視角來看，包含用戶端應用處理時延 + 服務端應用處理時延
響應時延拆解
确定度量名額後，接下就可以分析服務響應慢的原因，此時可以利用分布式鍊路追蹤能力來快速來定界瓶頸點，例如可利用 DeepFlow 的分布式追蹤能力來快速定界瓶頸點在應用、系統還是網絡。
分布式鍊路追蹤-火焰圖
完成瓶頸點定界後，則需要去查找根因。對于應用或者系統的問題，可以利用性能剖析（profile）繼續追查根因，而對應網絡時延的分析，其中 DNS 時延分析是相對簡單的，隻需要關注請求的響應時延即可，但網絡處理時延瓶頸的定位卻缺少了分析的工具，接下來将主要聚焦讨論網絡傳輸時延如何分析。
性能剖析-火焰圖
02｜網絡時延
參考 AWS 中的定義網絡時延是指網絡通信中的延時，網絡時延顯示了資料通過網絡傳輸所需的時間。讨論網絡時延如何，也是需要可度量的名額，AWS 也指定了使用“首位元組時間”和“往返時間”等名額來衡量網絡時延，這兩個名額是可以适用于所有網絡協定的傳輸時延的度量，但實際應用 80% 都使用的 TCP 協定，對于 TCP 協定是需要更細粒度的度量名額，下文通過圖文的形式，詳細的介紹目前可用的度量名額及用法。
TCP 協定是面向連接配接的傳輸層通信協定，對其詳細的通信過程分析，時延可分為三大類：
1) 建連時産生的時延
- [1] 完整的建連時延包含用戶端發出 SYN 包到收到服務端回複的 SYN+ACK 包，并再次回複 ACK 包的整個時間。建連時延拆解開又可分為用戶端建連時延與服務端建連時延
- [2] 用戶端建連時延為用戶端收到 SYN+ACK 包後，回複 ACK 包的時間
- [3] 服務端建連時延為服務端收到 SYN 包後，回複 SYN+ACK 包的時間
2) 資料通信時産生的時延，可拆解為用戶端等待時延+資料傳輸時延
- [1] 用戶端等待時延為建連成功後，用戶端首次發送請求的時間；為收到服務端的資料包後，用戶端再發起資料包的時間
- [2] 資料傳輸時延為用戶端發送資料包到收到服務端回複資料包的時間
- [3] 在資料傳輸時延中還會産生系統協定棧的處理時延，稱為系統時延
3) 斷連時産生的時延：因為斷連的時延并不影響到應用的響應時延，是以并不會單獨統計此部分使用
TCP 網絡時延解剖
度量的網絡時延的名額已經拆解好了，接下來讨論在哪裡采集名額，網絡的封包将在用戶端，各種虛拟和實體網絡與服務端之間穿梭，是以可封包穿梭的位置點來采集，後續統稱為統計位置。當然統計位置越多，定位網絡的瓶頸路徑越快，但是統計位置多則随之帶來的計算量也是成倍增加，企業在有成本壓力時，建議在重要節點進行采集即可，比如 K8s Pod 虛拟網卡、K8s Node 網卡、雲伺服器網卡、網關（如 LVS/Nginx 等）網卡、硬體防火牆/負載均衡器前後......
統計位置
分析到這，基本已經清晰網絡時延的詳細的度量名額了，回過頭結合響應時延再讨論下如何檢視網絡時延對其的影響，基本可以分兩種情況讨論:
a) 應用發起請求為短連接配接：此時分析網絡時延需要檢視 DNS 時延 + 建連時延 + 用戶端等待時延 + 資料傳輸時延 + 系統時延，則可快速定位時延發生的具體原因了。
- DNS 時延高，結合統計位置，則可回答是網絡傳輸時延高還是DNS 服務響應慢
- 建連時延高，結合用戶端建連時延 + 服務端建連時延 + 統計位置，則可回答是網絡傳輸時延高還是用戶端系統回複慢還是服務端處理建連響應慢
- 用戶端等待時延高，結合統計位置，則可回答是網絡傳輸時延高還是用戶端請求發送延遲
- 資料傳輸時延高，結合統計位置，則可回答是網絡傳輸時延高還是服務端響應慢
- 系統時延高，結合統計位置，則可回答網絡傳輸時延高還是服務端協定棧處理慢
b) 應用發起請求為長連接配接：因為長連接配接是保持長期活動的 HTTP 連接配接，不需要考慮 DNS 查詢與建連的時延消耗，隻需要關注用戶端等待時延 + 資料傳輸時延 + 系統時延即可
03｜案例分析
限于筆者時間限制又想早點将應用響應時延背後深藏的網絡時延剖解分享給大家，本文不繼續補充實際案例，将在一周後分享在某xx智能終端公司的如何結合 DeepFlow 在服務響應慢時，網絡團隊在存在可觀測性的時延資料時，如何硬氣回怼。
04｜什麼是 DeepFlow
DeepFlow[1] 是一款開源的高度自動化的可觀測性平台，是為雲原生應用開發者建設可觀測性能力而量身打造的全棧、全鍊路、高性能資料引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技術，創新的實作了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心機制，幫助開發者提升埋點插碼的自動化水準，降低可觀測性平台的運維複雜度。利用 DeepFlow 的可程式設計能力和開放接口，開發者可以快速将其融入到自己的可觀測性技術棧中。
GitHub 位址：https://github.com/deepflowys/deepflow
通路 DeepFlow Demo[2]，體驗高度自動化的可觀測性新時代。
05｜參考文檔
- https://aws.amazon.com/cn/what-is/latency/
- https://baike.baidu.com/item/%E7%B3%BB%E7%BB%9F%E5%93%8D%E5%BA%94%E6%97%B6%E9%97%B4/22026261
- https://dev.to/aws/why-are-services-slow-sometimes-mn3
- https://yunlzheng.gitbook.io/prometheus-book/parti-prometheus-ji-chu/promql/prometheus-promql-best-praticase
- https://www.weave.works/blog/the-red-method-key-metrics-for-microservices-architecture/
- https://aws.amazon.com/what-is/latency/
引用資料
[1]DeepFlow: https://github.com/deepflowys/deepflow
[2]DeepFlow Demo: https://deepflow.yunshan.net/docs/zh/install/overview/