阿里雲代理商開戶 如何透過 SLB 解決單點故障問題

第一章：把「單點」從架構裡挖掉

單點故障（Single Point of Failure）最可怕的地方，不在於它是否會發生，而在於它一旦發生，影響往往是「瞬間且全域」的。你可能把監控做得很漂亮，但只要請求都被打到同一個節點上，那節點一出問題，系統的可用性就會立刻跌落。

很多團隊在初期規劃時，只想著「能跑就好」。例如：後端只有一台服務、或是只掛了一條連到單一資料庫的依賴鏈路。等到業務上線、流量增加、維運壓力變高，才發現這個節點等同於整個系統的命門。於是我們開始找補救方式，而 SLB（負載均衡）通常是最先被採納的解法之一。

透過 SLB 的核心思想很簡單：把「請求落點」從單一實例改成多實例，讓任何一台故障不至於導致整體不可用。這不是把風險平均化這麼表面而已，而是用工程手段把失效的半徑縮小，讓系統具備容錯能力。

第二章：先釐清什麼算單點

在談 SLB 方案之前，我建議先把單點故障拆得更具體。因為「單點」不一定只是一台機器，它可能是某種依賴關係或某個鏈路環節。

小節一：只有一台後端服務

最典型的單點是後端只有一台，前端或入口只會把流量送到它。SLB 在這裡很有價值：你可以先把後端擴到多台，再由 SLB 進行流量分發。當其中一台掛了，其他台仍能承接請求。

小節二：入口或邊界網關只有單設備

有些架構把 SLB 設在入口層，但同時又只有一台網關、或同一個安全設備（例如 WAF、API Gateway）作為唯一通道。你即使做了後端多實例，如果入口層仍是單點，故障仍可能造成不可用。要把問題完整看齊，才能決定哪些層需要冗餘。

小節三：健康檢查與故障切換做得不夠

即使你有多台，也可能因為「SLB 不知道誰壞了」而失效。比如健康檢查設定過鬆、或只檢查端口連通卻沒有檢查應用邏輯，導致壞節點仍被分到流量；又或者超時與重試策略不合理，使得切換不但無法恢復，反而加大抖動。

小節四：會話綁定造成的隱性單點

如果你的服務需要會話狀態（例如登入態、購物車、分散式鎖），而你用錯了會話保持（Session Persistence）策略，可能產生「看似多台、實則綁死」的問題。當特定節點失效，這部分使用者會話丟失，可能演變成不可用或高錯誤率。

因此，SLB 的價值不僅是分流，而是要搭配對的健康檢查、對的切換與對的狀態策略，才能真正修掉單點。

第三章：SLB 的角色與工作方式

簡化理解，SLB 是流量的「交通管制」。它接收外部請求後，根據負載算法（如輪詢、最少連線、權重）把請求轉送到一個後端實例。更關鍵的是，它還會持續進行健康檢查：判斷後端是否可用，並在實例故障時把它從可用池移除。

阿里雲代理商開戶 當你把這套機制做完整，系統就從「一台壞則全壞」變成「單台壞只影響一部分，且可以快速恢復」。這對可用性（availability）是根本性的提升。

小節一：健康檢查決定「是否真的健康」

健康檢查不只是端口連通。很多服務可能狀態其實已經不可用：例如卡在依賴（資料庫、快取、第三方 API）、或只剩慢回應。若健康檢查只測 TCP 握手，SLB 仍可能把流量導向已經無法服務的實例。

因此你需要用「能代表服務可用性」的指標設計健康檢查。例如提供一個健康端點（/health 或 /ready），其中包含依賴檢查或最小功能驗證。當依賴不可用時返回失敗，讓 SLB 主動摘除故障節點。

小節二：故障摘除與恢復的時間要可控

SLB 的摘除不是「立即」，而是依賴檢查週期、超時、重試次數、閾值等參數。這些參數決定了系統對故障的反應速度，也決定了在不穩定時是否會頻繁切換（flapping）。

工程上要追求平衡：太快可能誤判暫時抖動為故障；太慢會讓錯誤請求堆積。通常做法是先用觀測數據（延遲分佈、錯誤率、GC/超時行為）估計恢復窗口，再反推檢查策略。

小節三：負載演算法影響整體穩定性

不同負載策略在不同服務形態下效果不同。輪詢簡單但不考慮實際處理能力差異；最少連線較適合處理時間差異較大的場景；加權則可用於不同規格機器或不同服務版本共存。

當你做故障切換後，某些節點可能在短時間內承接更高的負載。如果負載策略與容量預估沒有跟上，可能導致錯誤率上升。這也是為什麼「SLB + 擴容」往往要一起規劃，而不是只把入口換掉。

第四章：用 SLB 解決單點故障的可落地流程

下面給一個從需求到驗證的流程。你不一定照抄所有細節，但可以用它作為檢查清單，確保你修掉的是真正的單點。

小節一：先建立多實例（至少兩台）

SLB 的前提是你要有可分流的後端實例。實務上，至少要兩台，並且最好分散到不同可用區（AZ）或不同機房/故障域。原因很現實：若兩台都在同一故障域，一旦那個域掛了，SLB 仍無法救回。

在部署上，建議使用一致的映像與版本策略，避免在故障時切換到異構環境導致更大的錯誤。

小節二：設計健康檢查：能否「回答對」而不是「能否連上」

健康檢查應涵蓋必要依賴。你可以把健康拆成兩層：

• liveness：只要程式還在跑就算活（例如進程未死）。
• readiness：能處理請求才算就緒（例如資料庫可連、必要配置已載入、關鍵快取可用）。

實務上，SLB 更適合接 readiness，避免把還沒準備好的節點拿去分流。當依賴不可用時立即回傳失敗，讓 SLB 快速摘除。

小節三：調整會話與狀態管理

很多單點故障的「副作用」會在會話層放大。若你的服務是無狀態（stateless），SLB 天然友好：任一台都能處理請求，只要健康檢查正確即可。

若你必須有狀態，請優先把狀態外移到共享儲存（例如分散式快取、資料庫或專門的會話存儲）。當你使用外部狀態，SLB 切換後用戶不必依賴原節點，系統容錯性會大幅提升。

如果你確實使用 Session Persistence（會話保持），也要評估其成本：節點失效時，固定綁定的會話要如何恢復？是允許重新建立會話，還是需要提前設置更保守的故障策略？這些選擇會影響用戶體驗。

阿里雲代理商開戶 小節四：設定超時、重試與連線策略，避免「故障放大器」

在單點被移除後，很多系統仍會因為通信策略不當而出現新問題：例如上游在後端故障時不斷重試，讓流量集中到尚可用的節點上，造成雪崩。

建議把「重試」與「降級」放進同一個設計裡：

• 對非冪等操作（如扣款、下單）通常避免自動重試，或採用冪等鍵（idempotency key）。
• 阿里雲代理商開戶 對冪等查詢可有限次重試，但要加入退避（backoff）與上限。
• 超時要與健康檢查策略協調，否則你會看到一段時間內「SLB 尚未摘除，但應用已超時」，造成錯誤率飆升。

這些不是 SLB 功能本身，而是你要在整體鏈路上避免故障被放大。

小節五：做灰度與漸進式切換，降低切換本身的風險

當你把 SLB 導入，最好從低風險方式開始：例如先把少部分流量導向多實例池，觀察健康檢查命中、延遲與錯誤率是否符合預期，再逐步擴大。這能避免一次性切換導致的未知問題。

同時，你也可以用權重策略做版本共存：新版本逐步接流量，降低回滾成本。雖然這看起來和「單點故障」無直接關係，但在真實環境中，運維引發的回滾也常被當作事故來源。把風險管理加入架構，是對可用性的加分。

第五章：配置要點與常見誤區

SLB 能解決單點，但前提是配置正確。許多事故不是發生在「沒用 SLB」，而是發生在「用了卻沒把它用對」。以下是常見誤區。

小節一：只檢查連通性，忽略依賴與業務健康

這是最常見的錯誤。連通性只能證明網路通，不能證明服務可用。結果就是壞節點仍被導流，錯誤率反而加大。

解法是設計 readiness 檢查，把關鍵依賴納入（至少做最小必要驗證）。若依賴有降級策略，可以在健康端點反映「可降級」而不是直接宣告失敗；但要明確定義什麼情況算可用。

阿里雲代理商開戶 小節二：健康檢查時間太短或太長

時間太短：節點剛恢復、或遇到偶發抖動就被摘除，導致流量頻繁抖動。時間太長：故障已經造成大量錯誤，SLB 才慢慢摘除，影響擴散。

阿里雲代理商開戶 建議使用觀測數據設定：例如根據歷史延遲、錯誤分佈調整超時與閾值，並在測試環境用「故障注入」驗證切換節奏。

小節三：容量規劃不符合預期切換峰值

你要假設：當一台故障時，剩下的節點會短時間承接更多流量。若你的容量剛好等於平均值，在切換期間很可能超載，導致剩餘節點也變慢甚至掛掉。

解法是至少預留緩衝：例如以故障域為單位做容量預估，並設定自動擴縮（autoscaling）或手動擴容策略。SLB 不是魔法，它只是把風險轉移到「可承受的範圍」。

小節四：忽略跨區域與 DNS/路由的單點

有的團隊把 SLB 放在單一區域，當該區域網路異常時仍無法救回；還有的團隊把外部入口依賴 DNS 固定解析，切換時間太慢。

因此你要盤點外部到內部的整條路徑：入口是否有備援？路由與解析是否具備快速收斂？SLB 只是其中一環，但單點可能藏在別的地方。

小節五：會話處理不一致導致「切換後看似可用但不可用」

切換後端服務正常回應，但用户操作流程仍失敗，例如登入態丟失、購物車回到空、或分散式鎖被重新拿，造成資料錯亂。這種錯誤會讓你誤以為「SLB 失效」或「健康檢查錯誤」，但根源可能是狀態策略。

建議把狀態與一致性模型納入架構設計：要嘛完全無狀態，要嘛狀態外部化並保證一致性；若不可避免需要 session persistence，就把失效時的用戶體驗納入策略。

第六章：如何驗證 SLB 真正消除了單點

驗證是工程裡最常被低估的環節。你不能只看「部署成功」就認定單點已移除。真正的驗證要能回答幾個問題：故障發生時，流量如何被重新導到健康節點？恢復速度如何？錯誤率是否在可控範圍？

小節一：故障注入（Failure Injection）

在測試環境或預發環境做故障注入：例如停止一台後端、讓依賴返回錯誤、或故意提高回應時間讓節點超時。觀察 SLB 摘除是否正確，切換是否快速。

這一步可以驗證健康檢查的可靠性，也可以驗證重試、超時是否造成放大效應。

小節二：觀測指標要包含「系統行為」而非只看服務存活

建議觀測：

• 請求成功率（2xx/4xx/5xx）
• 延遲分佈（p50/p90/p99）
• 錯誤類型（超時、連線拒絕、依賴錯誤）
• SLB 摘除事件（健康檢查失敗次數與摘除時間）
• 阿里雲代理商開戶 後端節點的 CPU/記憶體/GC、連線池耗盡等

你要確認：在單台故障時，系統是否仍維持可用性門檻，而不是只看「節點是否存活」。

小節三：測試「最糟情境」而不是平均情境

單點故障通常伴隨最糟情境：例如網路抖動、依賴延遲、短暫失效。你應該測試的不只是「節點完全掛掉」，也包括「節點變慢但還在回應」這種更隱蔽的情況。

如果健康檢查沒有覆蓋到慢響應，SLB 仍可能把流量分到慢節點。你的錯誤率或延遲將在尖峰時惡化，表面上看起來服務仍在線，但用戶體驗會顯著下降。

第七章：把 SLB 當作平台能力，而不是一次性修補

把 SLB 引入後，你可能完成了當下的單點修復，但系統仍會演進：流量增長、服務拆分、依賴變多、版本更新頻繁。要避免單點故障在新環境再次出現，團隊需要把 SLB 納入日常的運維與開發流程。

小節一：健康端點與就緒策略要標準化

每個服務都要有清晰的健康與就緒定義。定義越模糊，SLB 越難做到正確摘除。你可以建立內部規範，例如必須回傳特定結構、需要檢查哪些依賴、超時與容忍策略如何。

當標準化完成，你就能減少「某個服務忘記就緒檢查」而造成的事故。

小節二：把容量預留寫入規劃假設

單點移除後，你仍要考慮切換帶來的容量峰值。將容錯假設納入容量規劃，並用壓測與指標持續校正。避免在事故後才補救。

小節三：把故障演練變成常態

真正的韌性不是靠一次部署，而是靠反覆演練。你可以定期做「後端節點失效」或「依賴不可用」演練，觀察監控告警、應急流程與回復時間，確保團隊在事故時能快速定位。

結語：SLB 解決的是「風險半徑」，不是把一切變成永遠穩定

SLB 解決單點故障的本質，是讓系統具備在局部失效時仍維持服務的能力。它把「全域不可用」的風險，轉成「局部承壓與可控降級」的風險。健康檢查要能判斷真實可用性，會話與狀態要能跨節點生存，超時與重試要避免故障放大，容量要承接切換峰值。

當你把這些因素一起落地，SLB 才不只是流量分發器，而是一個讓系統真正可靠起來的平台能力。最後，記住一句話：不是你沒有壞節點，而是你在壞節點出現時仍能讓用戶拿到可用的服務。