微服務基礎建設: 斷路器 #1, 服務負載的控制

問題與答案 (FAQ)

Q&A 類別 A: 概念理解類

Q1: 什麼是「服務量」？

• A簡: 系統於特定時間窗內可完成之請求或任務數量，反映處理能力上限。
• A詳: 服務量是「單位時間內的處理量」，常以 RPS/吞吐量衡量，亦可依業務定義如訂單件數、訊息數。它需要可度量與可觀測，才能預測極限與觸發保護機制。掌握服務量能在接近臨界前採取節流、擴容或熔斷，避免雪崩效應。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q6, B-Q9

Q2: 為什麼微服務需要服務量管控？

• A簡: 防止單點過載、避免連鎖故障，並為熔斷、擴容與資源調度提供決策依據。
• A詳: 微服務間相依複雜，單一服務過載會引發重試風暴與連鎖延遲，造成服務雪崩。服務量管控能在「過載前」主動限制流量、平滑突發，並提供可觀測數據支持熔斷開啟、優先級通行與自動擴縮容決策，提升整體穩定性與 SLA。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, B-Q11, D-Q9

Q3: 什麼是「斷路器（Circuit Breaker）」？

• A簡: 在錯誤率或負載異常時，暫停向目標服務發送請求的保護機制。
• A詳: 斷路器監測錯誤率與延遲等健康指標，異常達閾值時「打開」以快速失敗，避免持續壓垮服務並擴大故障。穩定期會半開測試恢復。其效果仰賴前置的服務量管控與監測，兩者協同可預防雪崩、縮短恢復時間並保護整體系統。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q4, B-Q11, D-Q9

Q4: 「限流」與「斷路器」有何差異？

• A簡: 限流主動平滑與限制流量；斷路器在異常時切斷請求以快速失敗。
• A詳: 限流（Throttle/Rate Limit）在正常與高峰時透過演算法（如桶算法）控制進入速率與突發吸收；斷路器則以健康指標判斷故障面，異常時拒絕流量以自我保護。限流是預防性流量治理，斷路器是故障隔離；兩者常搭配以同時防過載與縮小故障面。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q4, B-Q5, B-Q11

Q5: 為何開發者也需懂流量管控，而非僅交由 Infra？

• A簡: 業務規則常需內嵌於程式，現成閘道難滿足客製化情境。
• A詳: API Gateway 常見限制「每秒 X 次」；但業務如「每小時某品類出貨量上限」或「匝道人次」需自訂維度、時窗與策略。開發者理解限流與熔斷原理，才能落地複合規則、動態優先級與與服務發現整合，並在無現成解法時快速自造輪子保持競爭力。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q6, C-Q7, B-Q19

Q6: 服務量常見度量指標有哪些？

• A簡: RPS、吞吐量、成功/拒絕/執行數、平均等待時間等。
• A詳: 實務上可記錄每秒總請求數、成功受理數、被限流拒絕數、實際執行數與平均等待時間（從受理到執行的延遲）。這些指標支援觀察限流效果、估算峰值吸收與等待上界、判斷是否擴容或調整策略，並作為熔斷與重試策略的依據。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, D-Q2, D-Q10

Q7: 服務量限制的兩個核心問題是什麼？

• A簡: 流量計算方式的定義與超過後的處理策略設計。
• A詳: 核心一是定義可落地的計量方法：如固定窗、滑動窗、令牌或漏桶，兼顧精準與可實作性；核心二是超限處理：拒絕、排隊、降級或熔斷。兩者需支援分散式場景與一致性，並與業務權重、優先級相結合，形成可觀測、可調控的治理機制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q1, B-Q4, B-Q5

Q8: 固定時間窗與滑動時間窗的差異？

• A簡: 固定窗簡單但邊界易突發；滑動窗平滑但較複雜。
• A詳: 固定窗每段獨立統計，窗切換點可能短瞬間累積兩窗配額而爆量；滑動窗以時間滾動統計最近區間，能平滑邊界效應、反映即時平均速率。滑動窗較精準，適合精準限流與預測負載，但實作需更嚴謹的時間索引與資料結構。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, A-Q13

Q9: 什麼是「突發流量（Burst/Peak）」？

• A簡: 在短時間內瞬間增大的請求量，超過平時平均水準。
• A詳: 突發是常態，如促銷、批次任務或重試洪峰。未妥善處理的突發會壓垮下游並引發雪崩。桶演算法可藉桶深吸收突發；固定窗易受邊界影響；滑動窗更能準確反映當前平均。策略選擇需兼顧吸收能力與延遲上界。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q4, B-Q5, D-Q1

Q10: Leaky Bucket 與 Token Bucket 差異是什麼？

• A簡: 漏桶控「流出速率」平滑延遲；令牌桶控「准入」即時處理。
• A詳: 漏桶以固定速率「漏出」工作，前端用有限緩衝吸收突發，保護下游但引入等待；令牌桶以固定速率發放令牌，有令牌即立即處理，能瞬時高於平均但需令牌回補時間。兩者在吸收突發能力相當，取捨在延遲上界與即時處理偏好。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q5, D-Q3

Q11: 為什麼固定計數（Counter）限流常不夠？

• A簡: 固定窗邊界易爆量，吞吐不穩，難保護下游服務。
• A詳: 固定計數在窗切換時可能短瞬間「兩窗額度」同時被用掉，造成尖峰；窗設太大波動劇烈，太小耗費資源。結果是執行速率起伏大且不可預測，難以穩定後端。改良方式包括滑動窗統計或改用桶演算法以取得更平滑與可控表現。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q1, B-Q2, B-Q3

Q12: 什麼是 AverageExecuteTime？代表什麼意義？

• A簡: 從受理到實際執行的平均等待時間，用於觀察排隊延遲。
• A詳: 當採用有緩衝的策略（如漏桶），受理的請求會排隊等候執行。AverageExecuteTime 反映排隊延遲，與 time window、桶深與入流量相關。它是延遲 SLA 的重要指標，可用來調整配額、加工人數（worker）或觸發擴容，避免長期高延遲。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, D-Q2

Q13: 為何「可觀測」是限流與熔斷的前提？

• A簡: 沒有準確數據無法正確判斷臨界、調參與觸發策略。
• A詳: 限流與熔斷的價值在於「恰到好處」；缺乏 Total/Success/Fail/Exec/延遲等關鍵度量，就難以辨識過載、突發吸收與等待上界，進而導致過度拒絕或保護不足。統計與可視化（如 CSV→圖表）是實施與迭代調參的基礎。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, D-Q10

Q14: 什麼是「服務雪崩效應」？

• A簡: 局部過載與重試蔓延，造成多服務連鎖故障與整體崩潰。
• A詳: 當下游變慢或失敗，呼叫端重試與排隊累積，進一步放大流量與延遲，連鎖影響更多服務。未限流與未熔斷會讓雪崩加速。以限流平滑前端、熔斷隔離故障面、重試加入退避抖動，可有效抑制雪崩形成。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q11, D-Q9

Q15: 為什麼需要在「過載前」行動？

• A簡: 提前降壓與調度資源，避免故障擴大與雪崩生成。
• A詳: 多數教學在服務異常後才熔斷，已屬災難發生。若事先以限流觀測接近臨界的趨勢，就能優先保護關鍵流量、啟動擴容、或暫緩非關鍵請求，將風險扼殺在早期，並縮短恢復時間與影響面積。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q11, D-Q10

Q16: 什麼是 Backpressure（背壓）？

• A簡: 系統無法承受時向上游施壓，請求減速或暫緩的機制。
• A詳: 背壓是一種從消費端反饋給生產端的節流信號。以限流/桶算法可在入口即背壓，或透過佇列深度、拒絕率與延遲告警引導上游降速，避免無限制重試。它是分散式系統穩定運行的重要模式。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q5, D-Q9

Q17: 服務發現與限流、熔斷如何關聯？

• A簡: 以標籤分組服務，按客戶/場景選組與套用對應限流策略。
• A詳: 服務註冊時打標（如 VIP-only），呼叫時依身分與策略選取服務組，為不同客戶/流量應用不同限流與優先級。當監測到拒絕增長，可結合服務發現資料自動擴容該組，或切換流量路由，達成彈性治理與 QoS。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q19, C-Q9

Q18: 什麼是 QoS（服務品質）在微服務中的含義？

• A簡: 對不同客戶/流量提供差異化限流、優先級與保障。
• A詳: QoS 是按客戶等級或業務重要性提供差異化服務。可透過服務發現打標、限流參數與優先級佇列，讓 VIP 擁有較寬配額與更小延遲上界。此機制需與監測、熔斷與擴容聯動，確保在高壓情境下「關鍵請求先過」。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q9, B-Q19

Q19: 當應用採用漏桶時延遲會怎麼變化？

• A簡: 有緩衝即有等待，上界約受 time window/桶深限制。
• A詳: 漏桶將入流排隊以固定速率處理，平均等待時間會隨負載升高而上升，但通常受限於桶深與 time window，上界可預期。此特性可向客戶承諾延遲 SLA，但同步協定下要防連線占用，建議採非同步與後端工人模型。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, D-Q4

Q20: Token Bucket 為何常被視為更高效？

• A簡: 在保有突發吸收力下，允許即時處理並提升資源利用。
• A詳: 令牌桶先以固定速率發放處理額度，有令牌的請求可立即執行，不需等待排隊。當令牌耗盡，需回補時間。此機制讓系統在健康時充分利用空閒能力接住突發，避免不必要的延遲，整體吞吐利用率往往優於漏桶。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, D-Q3

Q21: 當應選擇「拒絕」而非「排隊」？

• A簡: 當等待將破壞 SLA、占用有限連線或造成優先級反轉時。
• A詳: 若排隊會導致延遲不可接受、連線資源被長久占用、或關鍵請求被非關鍵堵塞，則應直接拒絕低價值請求，或回應建議退避。拒絕可與熔斷、降級與重試策略配合，整體優化體驗與穩定性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q1, D-Q9

Q22: 為何僅有 CI/CD 並不等於 DevOps 能力？

• A簡: 微服務治理需跨研運：觀測、節流、熔斷、擴容與整合。
• A詳: DevOps 強調端到端的協同。限流/熔斷/健康檢測/服務發現/自動伸縮與監控告警等能力，決定了微服務在實戰下的穩定性。能跨越開發與運維設計並落地這些能力，才算具備真正的 DevOps 成熟度。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, B-Q11

Q23: 限流如何幫助自動擴縮容決策？

• A簡: 透過拒絕率、等待延遲與指標趨勢觸發擴容或回縮。
• A詳: 當 FailRequests 上升或 AverageExecuteTime 長期偏高，表示現有容量不足。可根據門檻自動擴容消費者/工作者數，或調整令牌速率。回縮時觀察穩定度與安全緩衝，避免震盪。這是閉環控制的核心訊號。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q8, D-Q10

Q24: 高速公路匝道管制與限流的類比是什麼？

• A簡: 以固定速率放行車流，避免主幹道過載與壅塞崩潰。
• A詳: 匝道管制如同漏桶/令牌桶：入口（匝道）限制流量，以固定或核定速率放車，主線（下游服務）維持穩定。突發車流在匝道排隊或被拒絕，保障整體通行。此類比有助向非技術利害關係人解釋限流價值。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q9, B-Q4, B-Q5

Q&A 類別 B: 技術原理類

Q1: 固定窗 CounterThrottle 如何運作？

• A簡: 每個時間窗內累計計數至上限即拒絕，窗到期重置。
• A詳: 原理是以固定長度的時間窗累計請求量，超過 rate×window 則拒絕。關鍵步驟：初始化窗長與上限；受理時計算累積值；定時器到期重置。核心組件：原子計數器與定時器。優點簡單，缺點是窗邊界易爆量、吞吐不穩。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q11, B-Q2

Q2: 固定窗的邊界效應為何會導致「瞬間爆量」？

• A簡: 窗交界時兩窗額度可在極短時間內被同時用盡。
• A詳: 0~5s 與 5~10s 兩窗各有額度，若交界前後瞬間高峰，等於在 0.1s 內用掉兩窗配額，產生尖峰輸出。之後長時間被拒絕造成吞吐起伏。這是固定窗統計獨立、不連續所致。改用滑動窗或桶算法可緩解。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q8, A-Q11

Q3: 滑動窗（StatisticEngineThrottle）如何平滑統計？

• A簡: 以移動時間區間計算平均，使邊界連續平滑。
• A詳: 透過隨時間滑動的窗（如最近 N 秒）持續更新平均速率，避免硬邊界。步驟：資料入列打時間戳；過期資料出列；即時計算平均。核心組件：時間序列結構與高效過期機制。優於固定窗，但仍僅「量測」平滑，不保證「輸出」穩定。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q8, A-Q11

Q4: Leaky Bucket 的技術機制是什麼？

• A簡: 請求入桶排隊，以固定速率漏出執行，桶滿則拒絕。
• A詳: 入流先進有限佇列（桶），漏出端以 rate 定時釋放處理額度。步驟：受理時檢查桶容量→入列；漏出執行：定時取出可處理數執行；桶滿則拒絕。核心組件：佇列、定時器、臨界區同步。輸出穩定、可吸收突發，但引入等待。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, A-Q19

Q5: Token Bucket 的技術機制是什麼？

• A簡: 以固定速率補充令牌，有令牌者即刻執行，令牌不足拒絕。
• A詳: 按 rate 定時向桶中加入令牌至上限，請求來時消耗令牌；不足則拒絕或延後。步驟：定時加令牌→受理時原子扣除→執行請求。核心組件：令牌計數、定時器、臨界區同步。能即時處理並提供突發容忍，但需回補時間。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, A-Q20

Q6: 如何計算每個間隔補充量（step）？

• A簡: step = rate × interval(ms) / 1000，控制平滑度與精度。
• A詳: 將每秒配額拆成更細間隔補充，可降低抖動。舉例 interval=100ms、rate=500rps，則每次補 50 令牌/可執行 50 單位。間隔越小越平滑但成本增加；需用單調時鐘（Stopwatch）減少時鐘漂移影響。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q4, D-Q6

Q7: 如何選擇 time window 與 interval？

• A簡: window 決定突發吸收與等待上界；interval 影響平滑與成本。
• A詳: 大 window/桶深提升突發吸收力，但增加等待與連線占用風險；小 window 平滑不足。interval 小平滑但耗 CPU，過大則步進粗糙。建議以延遲 SLA、突發特徵與硬體資源綜合調參，並以觀測數據迭代。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q2, C-Q8

Q8: ProcessRequest(amount, exec) 的語意與設計要點？

• A簡: 受理檢查、預留或排隊、返回可否；執行可能延遲觸發。
• A詳: 語意：若可受理則預留資源（令牌/入列）並回 true；不可則回 false。exec 非必定即刻執行，可能由漏出循環觸發。要點：線程安全、最小臨界區、非同步執行與可度量。amount 支持可加權的請求成本。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q1, C-Q3, C-Q4

Q9: 本文統計與輸出的流程為何？

• A簡: 多執行緒造流→每秒匯總 Success/Fail/Exec/延遲→輸出 CSV。
• A詳: 以多執行緒隨機間隔產生基礎流量，周期性製造尖峰與離峰；統計執行緒每秒原子交換計數，計算平均等待時間後輸出 CSV。核心組件：原子變數、Stopwatch、定時器與簡報圖表，用於直觀評估策略效果。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q6, C-Q5

Q10: 如何模擬突發與離峰流量？

• A簡: 以定時器控制高頻區段與靜默區段，交替施壓與恢復。
• A詳: 範例每 17s 注入 2s 高峰（近 500RPS），每 21s 注入 3s 靜默，以驗證突發吸收、穩態輸出與回復行為。搭配基礎 30 執行緒隨機間隔產流，逼近真實場景。可據此觀察拒絕、延遲與穩定度。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, D-Q1

Q11: 限流與熔斷要如何協同運作？

• A簡: 限流控進口，熔斷隔離故障；以健康與負載指標互相驅動。
• A詳: 限流平滑與守門，當延遲與拒絕率上升，熔斷可提前保護下游；熔斷開啟時可同時收緊限流或降級非關鍵流量。半開階段逐步放量並監測，若恢復則解除。需有穩健監測與動態參數調整機制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q4, D-Q9

Q12: 重試與限流的關係與風險？

• A簡: 無背壓的重試會放大負載，需退避與抖動避免重試風暴。
• A詳: 當下游慢/錯誤，盲目重試疊加流量與佇列深度造成雪崩。應與限流協作：拒絕或回應建議退避，並採指數退避+抖動；熔斷期間禁重試或極限控。對冪等操作重試才安全，非冪等需特殊處理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q9, A-Q14

Q13: 為何 Leaky 與 Token 的 Success 曲線相似？

• A簡: 兩者皆具桶深突發吸收能力，差在執行時機與延遲。
• A詳: 成功受理關鍵在「桶深」能暫存多少入流。兩者均能在短期突發時接住相近數量；差異在輸出端：漏桶延後執行（固定速率），令牌桶可即時執行（令牌可用）。因此在突發期 Success 接近，但 Exec 與延遲行為不同。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, A-Q20

Q14: 為何同步請求搭配漏桶會有連線耗盡風險？

• A簡: 排隊期間連線被占用，time window 大時易耗盡前端資源。
• A詳: 若採同步 RPC 且在入口排隊，請求在等待期間占住連線/執行緒，當等待上界較大或突發連續來臨，易用盡前端連線池、導致上游也受影響。建議入口快速接受後轉非同步佇列，或直接拒絕並引導重試退避。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q4, A-Q19

Q15: 佇列+工人（Worker）模型如何映射到 RPS？

• A簡: 每工人處理能力×工人數≈可提供的穩態 RPS。
• A詳: 若單工人穩態 100RPS、5 工人則約 500RPS。漏桶輸出即對應工人可消化速率。當拒絕上升可動態擴增工人或調整桶深。需校準工人單價值、監測長尾與延遲 SLA，避免飽和或震盪。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q8, D-Q10

Q16: 桶深（Bucket Size）如何影響突發吸收？

• A簡: 桶越深可吸收越大突發，但會增加等待與資源占用。
• A詳: 漏桶的桶深為佇列長度上界；令牌桶的桶深為最大可瞬放的令牌數。更深提升成功受理率但延長等待（漏桶）或拉長回補時間（令牌桶）。需以突發統計、SLA 與資源平衡選定。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, A-Q19

Q17: 如何估算漏桶的平均等待上界？

• A簡: 近似受 time window 與桶深限制，突發期會逼近上界。
• A詳: 在穩態下等待≈佇列長/漏出速率；極端突發期，等待將上探 time window 或對應桶深容量/速率比。觀測 AverageExecuteTime 的峰值可驗證是否達邊界，用於調整參數或擴容。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, D-Q2

Q18: 如何判斷接近臨界並提前保護？

• A簡: 監測拒絕率、延遲趨勢與佇列深度，接近門檻即降壓。
• A詳: 設門檻與回滯：如 FailRequests 比例上升、AverageExecuteTime 超過 P95 基準、佇列深度逼近上限，則收緊限流、觸發降級或擴容。搭配預測性監測（滑動平均）可在過載前行動，降低風險。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q10, A-Q15

Q19: 如何以服務發現與標籤實作 QoS？

• A簡: 註冊服務打標，依客戶選組，套差異化限流與優先級。
• A詳: 在註冊中心為實例加上標籤（如 tier=vip），呼叫端以身分選定實例集群，對不同集群配置不同限流策略與配額。遇壓力時可優先保護 VIP 組，並對一般組收緊或降級，確保 SLA 差異化。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q18, C-Q9

Q20: 分散式架構中如何一致地限流？

• A簡: 可集中於閘道實施，或分散到實例並協調配額。
• A詳: 方案一：集中於 API Gateway，簡單一致；方案二：每實例本地限流，需以全域配額/一致雜湊/分散計數協調，避免總量失控。選擇取決於延遲、可靠性與單點風險。需結合觀測與回滯避免抖動。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: C-Q7, D-Q5

Q&A 類別 C: 實作應用類

Q1: 如何以 ThrottleBase 實作 CounterThrottle？

• A簡: 使用固定窗計數與重置；受理時檢查累計是否超額。
• A詳: 步驟：1) 於建構子設定 rate 與 window；2) 背景執行緒每 window 重置 counter；3) ProcessRequest 檢查 amount+counter<=rate×window，通過則累加並非同步執行 exec。範例程式碼： public override bool ProcessRequest(int a, Action exec){ if(a+_counter>_rate_limit*_window.TotalSeconds)return false; _counter+=a; Task.Run(exec); return true; } 注意：計數器需原子操作；固定窗邊界有爆量風險。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q1, B-Q2

Q2: 如何用滑動窗統計改善固定窗？

• A簡: 以時間戳佇列維護最近 N 秒資料，動態滾動計算平均。
• A詳: 步驟：1) 設計 InMemoryEngine：入列(amount,timestamp)；2) 清除過期資料；3) 計算最近 window 的加總/平均；4) Throttle 受理時檢查平均<rate 再入列與執行。關鍵：高效移除過期、單調時鐘、原子更新。能平滑統計但無法保證輸出穩定。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, A-Q8

Q3: 如何實作 LeakyBucketThrottle？

• A簡: 入列排隊，定時漏出固定步長，桶滿拒絕並非同步執行。
• A詳: 步驟：1) 設 _max_bucket=rate×window；2) ProcessRequest：檢 _current+amount<=_max→_current+=amount，入列；3) 背景執行緒每 interval 取 step=rate×interval/1000，從佇列漏出並 Task.Run(exec)；4) 臨界區 lock。注意：避免同步阻塞、控制 interval 與桶深平衡延遲。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q6

Q4: 如何實作 TokenBucketThrottle？

• A簡: 以固定步長補令牌，有足量則扣減並立即執行，否則拒絕。
• A詳: 步驟：1) 設 _max_bucket=rate×window；2) 背景執行緒每 interval 補 step；3) ProcessRequest：若 _current>=amount，扣減並 Task.Run(exec)；4) 以 lock 或 Interlocked 確保原子性。注意：正確計算 step 與使用單調時鐘，避免時間漂移。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q6

Q5: 如何建立測試主控台並輸出 CSV？

• A簡: 造流→定期尖峰/離峰→每秒統計交換→輸出列印。
• A詳: 步驟：1) 多執行緒隨機 Sleep 造平均流量；2) 另一執行緒每 17s 注入 2s 尖峰，每 21s 注入 3s 靜默；3) 使用 Interlocked 統計 success/fail/exec/execTime；4) 每秒 Exchange 歸零並輸出「Total,Success,Fail,Executed,AvgTime」。以圖表分析策略效果。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, B-Q10

Q6: 如何在 ASP.NET Core 中套用 Throttle 中介軟體？

• A簡: 於中介管線檢查准入並執行或拒絕回應 429。
• A詳: 步驟：1) 註冊 IThrottle 實作（如 TokenBucket）；2) 在 middleware 讀取 amount（可=1或依成本）；3) ProcessRequest 成功則調用 next；否則回 429 與 Retry-After。程式碼略： if(!throttle.ProcessRequest(1)) { ctx.Response.StatusCode=429; return; } await next(); 注意：避免同步阻塞、加入觀測標頭與記錄。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q5, B-Q8

Q7: 如何用 NGINX 快速設定固定窗限流？

• A簡: 使用 limit_req_zone 與 limit_req，在閘道集中控流量。
• A詳: 設定： http { limit_req_zone $binary_remote_addr zone=perip:10m rate=60r/s; } server { location /api { limit_req zone=perip burst=120 nodelay; proxy_pass …; } } 說明：rate 每秒配額、burst 容忍突發、nodelay 立即處理至 burst。注意：此為 per key 限流，複雜業務規則需應用層補強。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, B-Q20

Q8: 如何根據拒絕率與延遲自動擴容工人？

• A簡: 設門檻觀測 Fail/AvgDelay，觸發增加執行節點或工數。
• A詳: 步驟：1) 監測每分鐘 Fail% 與 AvgExecuteTime；2) 超過門檻連續 N 個區段觸發 scale-out（+worker 或 +副本）；3) 恢復後以回滯策略回縮；4) 記錄事件避免震盪。可藉 Kubernetes HPA 或自製控制迴路實現。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q23, B-Q15

Q9: 如何以服務發現標籤實作 VIP QoS？

• A簡: 註冊時打標，路由選 VIP 群組，套較寬限流與優先隊列。
• A詳: 步驟：1) 服務註冊加 tag：tier=vip/standard；2) 呼叫端依客戶挑選對應群組；3) 建立兩套 Throttle 參數；4) 於高壓時保護 VIP，對一般流量降級或收緊。可延伸權重路由與佇列優先級。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q18, B-Q19

Q10: 如何與熔斷器整合（以 .NET Polly 範例）？

• A簡: 先限流再套熔斷；依錯誤率與延遲動態開關並回退策略。
• A詳: 步驟：1) Pipeline：Throttle→CircuitBreaker→Handler；2) Polly 定義熔斷條件如 Handle().CircuitBreakerAsync(…); 3) 熔斷開啟時可收緊 Throttle 或直接短路；4) 半開測試通行比例。注意：指標上報與動態參數配置。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q11, D-Q9

Q&A 類別 D: 問題解決類

Q1: 突發期間大量 429/拒絕，如何改善？

• A簡: 增加桶深/放寬 burst，或改用桶算法與調整 window。
• A詳: 症狀：短時間尖峰伴隨 FailRequests 飆升。原因：固定窗邊界爆量、桶深不足、令牌回補太慢。解法：改用漏桶/令牌桶、加大桶深、縮短 interval 或提升 rate；關鍵流量分級優先。預防：依突發統計預先調參與壓測。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q5

Q2: AverageExecuteTime 長期偏高怎麼辦？

• A簡: 代表排隊過深；加工人/提高 rate 或縮桶深與調整 SLA。
• A詳: 症狀：平均等待逼近 window 上界。原因：漏桶輸出不足、容量不匹配。解法：擴容工人、提高漏出速率、減少入流或分流；必要時縮小桶深避免連線占用。預防：設延遲告警與自動擴容，定期容量測試。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q15, A-Q12

Q3: Token Bucket 下吞吐起伏、常「卡住」？

• A簡: 回補太慢或步長不當；調整 interval/step 與桶深。
• A詳: 症狀：突發後需要較長恢復時間，間歇性拒絕。原因：令牌回補速率或桶深不匹配突發。解法：提高 rate 或減少 interval；核算 step=rate×interval/1000；增加桶深。預防：依突發分佈與回補需求壓測調參。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q6

Q4: 使用漏桶時前端連線被耗盡怎麼辦？

• A簡: 改入口非同步、縮短等待上界、或改採拒絕策略。
• A詳: 症狀：連線池耗盡、前端掛起。原因：排隊等待期間占用連線/執行緒。解法：快速接單→進佇列→立即回應，處理完成再通知；縮小桶深/等待上界；對低優先級直接拒絕。預防：非同步設計與限時等待。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q14, A-Q19

Q5: 多實例下總量超限或不一致的限流怎麼診斷？

• A簡: 分散式協調不足；需集中或協同配額與一致 hash。
• A詳: 症狀：整體流量超過預期、部分節點過載。原因：每實例各自限流，總量未協調。解法：改在閘道集中限流，或採分散計數器、共享配額、或一致哈希固定客戶至同實例。預防：設計全域門檻與觀測。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q20, C-Q7

Q6: 限流計時不準導致策略失靈，如何處理？

• A簡: 使用單調時鐘、校正 interval 與避免 Thread.Sleep 誤差。
• A詳: 症狀：步長補充忽快忽慢、吞吐抖動。原因：系統時鐘漂移、計時精度不足。解法：用 Stopwatch（單調時鐘）、以 SpinWait 或 timer 避免 Sleep 不精準；在負載下校驗實際間隔。預防：監測步進誤差。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, C-Q4

Q7: 固定窗下吞吐劇烈波動，如何快速止血？

• A簡: 先縮短窗長或改滑動窗，再過渡到桶算法。
• A詳: 症狀：執行速率 0~高值跳動。原因：窗邊界效應。解法：縮短 window 減少爆量影響、臨時降總配額；替換為滑動窗統計；最終改用漏桶/令牌桶以穩定輸出。預防：避免固定窗作為主要控流策略。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q2, B-Q3

Q8: 高價值與低價值流量互相干擾時怎麼做？

• A簡: 實施 QoS 與優先佇列，隔離配額並差異化限流。
• A詳: 症狀：低價值流量佔滿資源，關鍵請求受阻。原因：單池競爭無優先級。解法：分組（VIP/一般）與獨立限流；或採加權令牌/多佇列優先級處理。預防：事先標籤化服務與路由策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q18, C-Q9

Q9: 重試風暴引發雪崩，如何抑制？

• A簡: 搭配限流、熔斷、退避與抖動，並區分冪等操作。
• A詳: 症狀：錯誤後流量倍增、延遲飆升。原因：無控制的同步重試。解法：拒絕/限速入口、熔斷快速失敗、重試採指數退避+抖動；非冪等慎重重試或採補償流程。預防：壓測與保護策略預先部署。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q11, B-Q12

Q10: 如何系統化選定 rate、window 與桶深？

• A簡: 以指標驅動：觀察拒絕率、延遲與突發，反覆調參驗證。
• A詳: 步驟：1) 基於穩態容量設定初值；2) 用壓測與真實流量觀察 Fail%、AvgDelay 與突發吸收；3) 調整 rate/window/bucket 以達 SLA（延遲上界、成功率）；4) 設告警與自動擴容回路。預防：定期容量回顧與演練。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q23, C-Q8

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是「服務量」？
  • A-Q2: 為什麼微服務需要服務量管控？
  • A-Q3: 什麼是「斷路器（Circuit Breaker）」？
  • A-Q4: 「限流」與「斷路器」有何差異？
  • A-Q6: 服務量常見度量指標有哪些？
  • A-Q9: 什麼是「突發流量（Burst/Peak）」？
  • A-Q12: 什麼是 AverageExecuteTime？代表什麼意義？
  • A-Q14: 什麼是「服務雪崩效應」？
  • B-Q1: 固定窗 CounterThrottle 如何運作？
  • B-Q2: 固定窗的邊界效應為何會導致「瞬間爆量」？
  • B-Q4: Leaky Bucket 的技術機制是什麼？
  • B-Q5: Token Bucket 的技術機制是什麼？
  • B-Q9: 本文統計與輸出的流程為何？
  • C-Q5: 如何建立測試主控台並輸出 CSV？
  • D-Q7: 固定窗下吞吐劇烈波動，如何快速止血？
• 中級者：建議學習哪 20 題
  • A-Q5: 為何開發者也需懂流量管控，而非僅交由 Infra？
  • A-Q7: 服務量限制的兩個核心問題是什麼？
  • A-Q8: 固定時間窗與滑動時間窗的差異？
  • A-Q10: Leaky Bucket 與 Token Bucket 差異是什麼？
  • A-Q11: 為什麼固定計數（Counter）限流常不夠？
  • A-Q15: 為什麼需要在「過載前」行動？
  • A-Q16: 什麼是 Backpressure（背壓）？
  • A-Q17: 服務發現與限流、熔斷如何關聯？
  • A-Q18: 什麼是 QoS（服務品質）在微服務中的含義？
  • B-Q3: 滑動窗（StatisticEngineThrottle）如何平滑統計？
  • B-Q6: 如何計算每個間隔補充量（step）？
  • B-Q7: 如何選擇 time window 與 interval？
  • B-Q8: ProcessRequest 的語意與設計要點？
  • B-Q11: 限流與熔斷要如何協同運作？
  • B-Q12: 重試與限流的關係與風險？
  • B-Q15: 佇列+工人（Worker）模型如何映射到 RPS？
  • C-Q1: 如何以 ThrottleBase 實作 CounterThrottle？
  • C-Q3: 如何實作 LeakyBucketThrottle？
  • C-Q4: 如何實作 TokenBucketThrottle？
  • D-Q1: 突發期間大量 429/拒絕，如何改善？
• 高級者：建議關注哪 15 題
  • A-Q20: Token Bucket 為何常被視為更高效？
  • A-Q21: 當應選擇「拒絕」而非「排隊」？
  • A-Q23: 限流如何幫助自動擴縮容決策？
  • B-Q13: 為何 Leaky 與 Token 的 Success 曲線相似？
  • B-Q14: 為何同步請求搭配漏桶會有連線耗盡風險？
  • B-Q16: 桶深（Bucket Size）如何影響突發吸收？
  • B-Q17: 如何估算漏桶的平均等待上界？
  • B-Q18: 如何判斷接近臨界並提前保護？
  • B-Q19: 如何以服務發現與標籤實作 QoS？
  • B-Q20: 分散式架構中如何一致地限流？
  • C-Q6: 如何在 ASP.NET Core 中套用 Throttle 中介軟體？
  • C-Q7: 如何用 NGINX 快速設定固定窗限流？
  • C-Q8: 如何根據拒絕率與延遲自動擴容工人？
  • D-Q5: 多實例下總量超限或不一致的限流怎麼診斷？
  • D-Q9: 重試風暴引發雪崩，如何抑制？