API 超時不是單一問題：重新理解結帳流程診斷

電商結帳測試中的 API 超時通常不是表面看起來那麼簡單。當測試出現超時錯誤時，開發者往往直接懷疑目標服務有問題，但實際情況複雜得多。結帳流程涉及多個服務協作，包括庫存檢查、支付閘道優惠計算庫存檢查、支付閘道優惠計算等，任何一個環節延遲都可能觸發超時。

關鍵在於：超時訊息只告訴你「某處太慢」，而不是「哪裡出問題」。本文將帶你建立系統化的診斷思維，從網路層、服務層到客戶端，全面解析結帳流程中的超時根源。

第一步：建立超時的時間上下文

當測試出現超時錯誤時，首先記錄精確的時間戳記和上下文資訊。在測試腳本中加入以下 logging 機制：

  • 請求發送時間戳
  • 每次重試的間隔時間
  • 回應收到的實際耗時
  • 當時的系統負載狀態

範例程式碼（Python requests）：

import time
import requests

start = time.time()
try:
    r = requests.get('/api/checkout', timeout=30)
    elapsed = time.time() - start
    print(f"Request completed in {elapsed:.2f}s")
except requests.Timeout as e:
    print(f"Timeout after {time.time() - start:.2f}s")

這些資料能幫助你判斷是「一直很慢」還是「突然變慢」，這兩種情況的診斷方向完全不同。

常見超時原因與對應排查策略

1. 網路延遲問題

檢查客戶端到 API 伺服器的網路路由。使用 traceroute 或 ping 測量延遲，結帳 API 的網路往返時間（RT）應低於 100ms。如果超過這個範圍，可能涉及 CDN 設定錯誤或 DNS 解析問題。

2. 資料庫查詢緩慢

庫存查詢和訂單寫入是最常見的效能瓶頸。啟用資料庫慢查詢日誌（Slow Query Log），找出執行時間超過 1 秒的查詢並進行優化。

3. 第三方支付 API 延遲

支付閘道通常有獨立的超時設定。檢查以下項目：

  • 該支付商的平均回應時間
  • 是否觸發該 API 的 rate limit
  • 重試機制是否正確實作

4. 連線池耗盡

高併發測試時，HTTP 連線池可能耗盡。確保客戶端正確設定連線池大小：

session = requests.Session()
adapter = HTTPAdapter(pool_connections=10, pool_maxsize=20)
session.mount('https://', adapter)

實用診斷工具推薦

工欲善其事，必先利其器。推薦以下診斷工具：

  • Postman / Insomnia：手動重現問題，精確控制請求參數
  • Charles Proxy / Fiddler：攔截並分析 HTTP 流量
  • New Relic / Datadog：APM 工具追蹤分散式追蹤
  • k6 / Gatling：負載測試工具，模擬真實結帳流量

在測試環境中，建議同時開啟這些工具，形成多層次的觀測視角。

建立長效的超時監控機制

解決單次超時後，應該建立持續監控防止問題復發。建議的做法包括：

  • 在 CI/CD 流程中加入結帳端到端測試
  • 設定 API 響應時間的 SLI（服務層級指標）
  • 建立 Alert 機制，當 P99 延遲超過閾值時通知團隊
  • 定期執行負載測試，驗證系統極限

記住：結帳流程的超時診斷是一個持續優化的過程，而非一次性修復。