API 請求生命週期——一個請求所走的每一跳

在一張互動畫布上呈現 API 請求的生命週期：DNS、TCP 與 TLS 的建立、經負載平衡器的路由、伺服器處理，以及回應的路徑。

一個 API 請求並不是一跳——它是一條鏈：DNS 解析、連線建立、加密、路由、處理與回應，而每一個階段都由不同的一層擁有。

API 請求生命週期——一個請求所走的每一跳

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

  • 先讀「請求之前」這一欄：DNS、TCP、TLS——在任何 HTTP 送出之前發生的三趟來回。
  • 然後跟著請求進入「伺服器處理」：負載平衡器、處理程式、資料庫、序列化。
  • 把「回應」這一欄當成倒影來讀——回應會沿著同一條路徑折返用戶端。

請求之前

「瀏覽器透過 DNS 解析域名」是第一趟來回——域名變成一個 IP 位址（那是 DNS 那張圖解的主題）。「建立一條 TCP 連線」開出一條可靠的位元組管道，而「TLS 握手為連線加密」把它加密（那是 HTTPS 那張圖解的主題）。到此之後，「HTTP 請求送出」才會發生。開頭這三個方框，正是為甚麼一次冷啟動的 API 呼叫明顯比一次熱的慢。

伺服器處理

「負載平衡器路由到一部應用伺服器」把請求分配到各個健康的執行個體之上。「處理程式驗證並處理該請求」是應用程式的程式碼執行的地方，「伺服器查詢資料庫」是資料那一跳——通常也是最慢的一跳——而「伺服器把回應序列化」則是回程的格式化。泳道的切分令網絡邊緣、應用程式與資料儲存在視覺上保持分開，因為它們有不同的故障模式與不同的延遲預算。

回應的路徑

「回應沿同一條路徑傳回」與「用戶端解析並呈現回應」把整個回路收結。回應並不會憑空返回——它要跨越承載過請求的同一個負載平衡器、同一個網絡與同一條連線。明白這條路徑是共用的，才解釋得到為甚麼請求逾時與回應逾時其實是同一個問題，以及為甚麼那兩條直欄互為倒影。

Key relationships and takeaways

  • DNS、TCP 與 TLS 都排在 HTTP 請求之前——在任何應用程式的程式碼執行之前，已經有三趟來回。
  • 負載平衡器令多部伺服器看起來像同一個位址；用戶端永遠不會見到真正的那一部伺服器。
  • 在大多數 API 呼叫裡，資料庫查詢是最慢的一跳，這就是為甚麼快取與索引重要。
  • 回應會沿著請求的路徑折返——兩個方向跨越的是同一個網絡與同一個負載平衡器。
  • 這個生命週期把其他圖解組合起來：DNS、HTTPS 與 REST 都是這一趟旅程裡的階段。

When to use this visual

  • 向新的工程師講解，為甚麼 API 延遲不只是伺服器程式碼——網絡與建立連線那幾個階段是實實在在的。
  • 診斷緩慢：畫布點名了要量度的那幾跳——DNS 時間、TTFB、伺服器時間、傳輸時間。
  • 把關於負載平衡與快取的討論，落到它們各自在這趟旅程中的位置之上。

運作方式

  1. 把你真實的基礎設施畫上去

    把通用的負載平衡器、應用伺服器與資料庫，換成你實際的元件——你的 CDN、你的執行個體、你的資料儲存——並維持一跳一個方框。

  2. 標註延遲預算

    在每一跳加上一則備註，記下它在你的系統裡的典型時間——網域查詢、建立連線、TLS、伺服器時間、資料庫——令這張畫布變成一份延遲剖析。

  3. 加入快取層

    在負載平衡器與處理程式之間插入一個快取方框，並為命中快取與未命中各設一條分支，因為那是大多數團隊最先動的一根槓桿。

  4. 把失敗分支畫出來

    加入真實的失敗終點——DNS 逾時、TLS 錯誤、負載平衡器傳回的 502、資料庫中斷——每一條都以一個明確的結果收結。

常見問題

一個 API 請求有哪些階段？

在任何 HTTP 送出之前，用戶端會先透過 DNS 解析域名、開啟一條 TCP 連線，並完成一次 TLS 握手。然後請求前往負載平衡器，由它路由到一部應用伺服器；伺服器驗證並處理它、查詢資料庫，再把一個回應序列化；而回應會沿同一條路徑返回。圖解的三條直欄，正正就是這三組階段。

為甚麼伺服器還未做任何事，一次 API 呼叫就已經很慢？

因為 DNS 解析、TCP 連線與 TLS 握手全都是真實的來回，而且都發生在第一個 HTTP 位元組送出之前。在一條冷連線上，它們花的時間可以比實際的請求處理還要長。這就是為甚麼圖解要由「請求之前」這一欄開始——第一個請求的延遲大部分是建立連線，而不是伺服器程式碼。

負載平衡器在請求生命週期裡扮演甚麼角色？

負載平衡器是那道穩定的前門，真正的伺服器住在它背後。它接下請求、挑選一個健康的執行個體，再把流量轉發過去；健康檢查與 TLS 亦經常在這裡終結。用戶端永遠不會知道是哪一部伺服器處理了自己，正是這一點，令伺服器可以在不改動用戶端的情況下增減。

為甚麼回應要沿同一條路徑折返？

因為連線就是路徑：回應是經由承載過請求的同一條 TCP/TLS 連線，穿過同一個網絡與同一個負載平衡器傳回的。這種對稱在營運上很重要——一跳變慢或壞掉，兩個方向都會受影響，這就是為甚麼圖解把回應那一欄畫成請求那一欄的倒影，而不是假設回程是免費的。

用 QueryChart（FlowJam）編輯這張圖解

把上面這張生命週期畫布開啟為你自己的圖表——把每一跳改名成你的基礎設施，然後追蹤你真實的請求。

用 QueryChart（FlowJam）編輯這張圖解

互動圖解的更多內容