High Availability 的致命陷阱：當台灣海纜斷線，為何你的微服務「重試機制」會演變成自我毀滅的 DDoS 攻擊？

本文從分散式系統架構的角度，剖析當實體層（如台灣海纜）發生故障導致高延遲時，軟體層常見的「自動重試」策略如何引發災難性的「重試風暴（Retry Storm）」。我們將探討排隊理論、Little 定律以及 CAP 定理中的權衡，解釋為何在特定網路條件下，追求高可用性的配置反而會成為系統自我毀滅的 DDoS 攻擊源，並提出基於指數退避與斷路器的解決方案。

摘要 (Abstract)

在軟體工程領域，高可用性（High Availability, HA）往往被奉為圭臬。微服務架構中，開發者習慣依賴自動重試（Automatic Retry）機制來掩蓋暫時性的網路抖動。然而，當面對台灣周邊海纜斷裂這類「實體層」的巨變時，這些旨在提升韌性的策略，卻可能轉化為摧毀系統的毒藥。本文將以系統架構師的視角，解析為何在頻寬受限與高延遲場景下，標準的重試邏輯會演變成一場自我施加的阻斷服務攻擊（Self-inflicted DDoS），導致系統陷入「亞穩態故障（Metastable Failure）」。

深入剖析 (Deep Dive)

1. 物理層的現實：當光子延遲遇上逾時設定 (The Physics of Latency vs. Timeouts)

首先，我們必須認知到底層硬體的限制。台灣作為亞太數據樞紐，一旦發生海纜事故（無論是地質活動或人為因素），流量被迫繞道，RTT（來回通訊延遲）可能瞬間從 20ms 飆升至 200ms 甚至更高。

從 TCP/IP 協定來看，這意味著 TCP Window Size 的填充效率下降，頻寬利用率受物理光速限制而降低。然而，上層應用程式的 HTTP Client 往往配置了嚴格的 timeout（例如 500ms）。當實體鏈路的延遲逼近或超過這個閾值，請求並非失敗，而是「還在路上」。此時，應用層的悲劇開始了。

2. 重試風暴的數學模型 (The Mathematics of Retry Storms)

假設一個微服務調用鏈長度為 3（Service A -> B -> C）。若開發者為每一層都設定了「重試 3 次」的預設值：

當 Service C 因海纜擁塞而回應緩慢，Service B 在逾時後發起重試。
Service B 對 C 的請求量瞬間變成原本的 1 + 3 = 4 倍。
Service A 看到 Service B 沒有回應，也開始重試 B。
系統的總流量負載呈現幾何級數增長：$Total Requests \approx R^N$。

這在控制理論中被稱為「正回授迴圈（Positive Feedback Loop）」。原本只是 30% 的封包遺失或延遲，卻因為應用層的恐慌性重試，產生了 300% 甚至 1000% 的額外流量。這些無效的請求塞滿了負載平衡器（Load Balancer）的佇列，耗盡了資料庫的連接池（Connection Pool）。

3. 排隊理論與 Little 定律的崩潰 (Little's Law violation)

根據 Little 定律 $L = \lambda W$，系統中的並發請求數（$L$）等於到達率（$\lambda$）乘以平均處理時間（$W$）。

當海纜斷線導致 $W$ 劇增，若要維持相同的吞吐量，系統必須容納更高的並發數 $L$。然而，記憶體和 CPU 是有限的。當 $L$ 超過伺服器的飽和點，CPU 開始頻繁進行 Context Switch，導致 $W$ 進一步上升。重試機制則在此时增加了 $\lambda$。

$\lambda \uparrow \times W \uparrow = L \uparrow\uparrow$

這是一個死結。系統不是因為「處理不了請求」而死，而是因為「忙著處理無效的重試請求」而耗盡資源。這就是典型的「亞穩態故障」——一旦系統進入過載狀態，即使原始故障（海纜修復）排除，系統也無法自動恢復，因為積壓的重試請求會持續讓系統保持癱瘓。

架構批判 (Architecture Critique)

盲目追求「可用性」的代價

許多工程師誤解了 CAP 定理。在發生網路分區（Partition, P）時，我們必須在可用性（Availability, A）與一致性（Consistency, C）之間做選擇。但這裡有一個隱藏的維度：生存性（Survivability）。

在海纜斷線這種極端情境下，堅持「對終端用戶隱藏錯誤」（即無限重試以達成高可用假象）是錯誤的決策。這違背了「Fail Fast」（快速失敗）的原則。

歷史教訓與解決方案

這並非新問題。早期的乙太網路（Ethernet）使用 CSMA/CD 協議時，就引入了二進制指數退避（Binary Exponential Backoff）來解決碰撞問題。現代微服務卻常遺忘這個古老的智慧。

為了避免自我毀滅，架構設計必須包含：

指數退避與抖動（Exponential Backoff with Jitter）：重試間隔必須隨次數指數增長，並加入隨機因子以避免所有客戶端在同一毫秒發起重試（Thundering Herd）。
斷路器模式（Circuit Breaker）：當錯誤率超過閾值，直接阻斷下游呼叫，立即回傳錯誤。這能讓系統「喘息」，消化積壓的佇列。
權杖桶限流（Token Bucket Rate Limiting）：在出口處限制重試流量的比例。例如，只允許 10% 的流量是用於重試的，其餘必須是新請求。