容量估算器

你到底需要多少台伺服器？用算術而不是感覺來回答：把你的請求速率、每個請求消耗的 CPU 時間和使用者看到的回應時間告訴估算器，它會返回流量佔用的核心數、應配置的整台伺服器數——已套用你的冗餘策略——你的連線池必須扛住的併發數，以及同一服務在兩倍、五倍和十倍流量下的樣子。

公式，用直白的話講

核心數。把請求速率乘以每個請求消耗的 CPU 秒數：那就是流量在 100% 時佔用的核心數。然後除以你的目標利用率——在 70% 時，你配置的每個核心在規劃中只算 0.7 個核心，另外 0.3 是在流量波動時讓佇列保持短的餘裕。所需核心數 = 請求/秒 × 每個請求的 CPU 秒數 ÷ 目標利用率。

伺服器數。把核心數除以每台伺服器的核心數並向上取整——不存在 0.4 台伺服器這回事，向下取整正是「平均能跑」的規劃在峰值時失敗的原因。冗餘在取整之後套用：N+1 在取整後的數量上加一台備用；2N 把整個機群翻倍。併發數是另一個來自 Little's law 的數字：在途請求數 = 請求/秒 × 以秒計的回應時間。它決定執行緒池、資料庫連線和檔案描述符的規模——這些才是服務在 CPU 還在閒晃時真正撞上的上限。給出回應大小時，出口流量 = 請求/秒 × 大小 × 8，那就是你網路帳單的構成。配套文章你到底需要多少台伺服器說明每個輸入的來源，以及為什麼廠商基準測試與這一切都對不上。

規劃姊妹工具：SLA 錯誤預算計算器把這份容量所守護的可用性目標換算成分鐘數，備份保留計算器則計算同一系統的儲存一側。

常見問題

為什麼按 70% 利用率規劃，而不是 100%？

因為佇列在飽和之前就爆炸了，而不是在飽和那一刻。平均忙碌 95% 的 CPU，是一個每次流量波動佇列都會無界成長的 CPU——而流量總會波動。利用率目標就是吸收峰值、發布、重試和一個慢相依性的餘裕。70% 是延遲敏感型服務的業界預設值；能容忍延遲的批次處理工作程序可以跑得更熱，而任何面向使用者且尖峰明顯的服務都應該跑得更涼。

核心數和在途請求數有什麼區別？

它們回答的是不同的問題。核心數來自 CPU 服務時間：每個請求消耗多少處理器。在途請求數來自 Little's law：速率乘以回應時間，它們度量的是併發——連線、執行緒、保持開啟的記憶體——而不是處理器負載。一個下游呼叫很慢的服務可以同時持有 500 個在途請求，卻只用兩個核心，它會先耗盡連線池，遠在耗盡 CPU 之前。兩者都要算，否則你忽略的那個就會變成事故。

我的負載測試說一台伺服器能處理每秒 2,000 個請求。這個估算器為什麼不同意？

負載測試通常測的是一個已預熱、穩定、快取全熱的服務，它從一個大方的用戶端回答一種請求形狀。生產環境會加上冷啟動、TLS 交握、重試、長尾的慢請求、吵鬧的鄰居，以及讓容量減半十分鐘的那次發布。這個估算器是故意保守的——平均 CPU 時間、利用率上限、整台伺服器、再加上冗餘。把負載測試當作可能性的上限，把這個數字當作應配置的下限；對規劃而言，真相是下限。

N+1 實際上防的是什麼？

一次故障：一台死掉的主機、一次被撤出輪換的壞發布、一個讓單個實例下線的可用區事件。有了 N+1，剩下的 N 台伺服器仍然能達到目標——這正是先按流量算出 N、再加上備用的意義。2N 是另一種承諾：兩份完整副本，通常跨區域部署，為那些必須在失去整份副本後仍存活的服務而設。它讓帳單翻倍，所以只為那些缺席要用頭條新聞來衡量的服務購買。

我怎麼得到每個請求的 CPU 服務時間？

測出來，不要猜。在運行中的服務上：一個時間窗內消耗的 CPU 總秒數，除以同一時間窗內服務的請求數。應用效能監控工具會直接以每個請求的 CPU 形式報告；在 Linux 上，你可以從 /proc 中的程序 CPU 時間或容器指標推導。使用你最繁忙的真實一小時的數字，而不是全天平均值——用平均值規劃的容量，恰恰會在它為之購買的那個峰值上失敗。