一個完整的流量模型至少量五個維度：平均與峰值的比值、時間上的分布、用戶的分布、操作的分布、以及突發的型態。少量任何一維，模型就會在某個情境下失準——最常見的失準是「模型撐得住、production 撐不住」，那幾乎都是漏了某個維度。

峰均比是工程意義最大的單一指標

峰均比（peak/average ratio）是峰值流量除以平均流量，它一個數字就決定了容量要按平均規劃還是按峰值規劃。峰均比 1.5 左右的服務流量平緩，容量可以接近平均值來配、不必大幅超額；峰均比 3 到 5 的服務是 bursty 的，必須按峰值規劃，代價是平日大幅超額配置、多數時間資源閒置。

這兩種型態的差距在真實服務裡很極端。一個大型電商的公開大促案例，當天 24 小時收 1.67 億請求、峰值 3500 RPS，峰均比約 1.8——算溫和型，按峰值配一點超額就穩。搶票型服務則是另一個極端：整批票 5 分鐘賣完，峰值全集中在開賣的瞬間，峰均比比平緩型高出一個數量級以上，這種流量沒辦法靠「平均值加係數」規劃，得專門為那 5 分鐘設計。峰均比先算出來，才知道自己在哪一端。

同一秒內怎麼到達，比每秒平均更決定壓力

平均 RPS 只說了「每秒幾個請求」，沒說這些請求在那一秒內怎麼分布。同樣是每秒 1000 個請求，均勻到達（接近 Poisson）跟集中在幾十毫秒內爆發（bursty）對系統的壓力完全不同——bursty 的到達會在瞬間打滿連線池、塞爆佇列，即使每秒平均看起來還在容量內。

所以流量模型要標到達型態，不能只記平均 RPS。bursty 的來源在真實服務裡很具體：一則推播同時喚醒幾百萬 app、一個 KOL 的推廣連結、一部新片上架、一則突發新聞。這些都會製造「平均看起來沒事、瞬間打爆」的流量。模型漏掉到達型態，壓測時用均勻流量測、上線遇到 bursty 就垮。

操作分布決定容量往哪裡堆

讀寫比直接改變容量該往哪個資源堆。90% 讀的服務跟 50% 讀的服務，容量設計完全不同——讀重的可以靠快取擋掉大部分負載，寫重的擋不了快取、壓力直接落在儲存層的 IOPS。同樣的總 RPS，讀重的瓶頸在快取容量、寫重的瓶頸在磁碟寫入，規劃的方向相反。

操作分布還要看端點的組合（endpoint mix）跟請求大小的分布。不同端點的成本差幾個數量級，把它們當成等重的請求來估容量會嚴重失準；請求大小（payload size）的分布則影響網路頻寬與序列化成本，要按端點、按用戶分層各自算 percentile，而不是用一個平均值蓋過去。

從 production log 抽出可信的模型

流量模型的來源是真實流量，不是憑感覺估的。從 production 抽模型分四步：先蒐集資料（從 access log、APM trace、metric 系統採樣，涵蓋至少一個完整的週期——含平日、週末、峰谷），再分組統計（按端點、按租戶分組，各算 percentile、標到達型態、算 payload 分布），接著做序列重播（保留請求之間的到達間隔，讓 burst 在壓測時能重現，而不只是灌一個平均 RPS），最後脫敏（雜湊加鹽、但保持資料的 cardinality——不同值的數量、例如有幾個不同的用戶 ID——跟 production 一致，否則快取命中率會失真）。

抽出來的模型要驗證。拿模型去壓測，比對四類指標跟 production 是否吻合：吞吐型態（總 RPS 加端點組合）、延遲分布（p50/p95/p99）、資源使用率、錯誤與重試型態。若模型在測試環境撐得住、production 卻撐不住，代表漏了維度，要回到蒐集階段補——這個「模型過關但實境失守」的偏差，是流量模型最該防的失準。

用 Little’s Law 把流量翻成並發

流量模型的一個直接用途是反推系統要準備多少並發容量，工具是 Little’s Law：L = λ × W，並發數等於到達率乘以每個請求停留的時間。這條關係在穩態下恆成立、不需要任何分布假設。舉例：到達率 1000 RPS、每個請求平均停留 200 毫秒，穩態並發就是 1000 × 0.2 = 200——這個 200 直接對應要準備多大的連線池、執行緒池或非同步 worker 數。

反過來用也成立：一個卡在固定大小的連線池（L）加上已知的處理延遲（W），可以算出它最多支撐多少 RPS。Little’s Law 讓「流量」跟「資源規格」之間有一條可計算的橋，不必靠猜。

模型會過時，要定期重抽

流量模型是某個時間點的快照，會隨服務演進失效。失效的訊號很具體：新功能改變了用戶動線、進入新市場改變了用戶組成（例如打進行動優先的市場、mobile 佔比大增）、一場行銷活動改變了 burst 型態、或用戶習慣的長期轉變（遠距工作改變了平日與週末的比例）。

最劇烈的失效是結構性的流量位移——一個視訊服務在疫情期間流量漲到平時的 30 倍，且不會回落，baseline 永久上移。這種情況舊模型整個作廢，要以新的 baseline 重抽，而不是在舊模型上加係數。維護的節奏是每季 review 一次、遇到重大改動立即重抽。模型不維護，容量規劃就是拿過期的流量在算未來的資源。

下一步路由

• 把峰值從模型推出來、加多少安全係數 → 峰值估算
• 用壓測工具驗證這個模型撐不撐得住 → 壓力測試工具與方法
• 上游的效能理論與 workload modeling 完整方法 → backend 效能容量