負載平衡是將流量、服務請求、運算任務或通訊負載分散到多個資源上的處理程序，以避免任何單一伺服器、應用程式、閘道或網路路徑因過度集中而超載。
認識負載平衡
在現今的數位系統中，使用者期望網站、應用程式、通訊平台、資料庫和雲端服務即使面對高峰流量，也能快速回應並維持可用。若所有請求都送往同一臺伺服器或同一個系統元件，該資源就可能變慢、不穩定，甚至完全無法使用。負載平衡正是透過將工作分配給多個可用資源來解決這個問題。負載平衡器就像一位流量指揮官，負責接收進來的請求、評估可用的後端資源，再依據預先設定的規則或演算法，將每個請求轉送到最合適的目的地。後端資源可以是網頁伺服器、應用伺服器、資料庫節點、媒體伺服器、SIP 伺服器、雲端執行個體、容器、閘道或網路連結。
負載平衡不只是為了速度，更重要的是讓服務保持可用、容易預測，並在需求變化時更容易擴充。
負載平衡如何運作
流量經由共用入口進入
使用者或裝置通常會連到單一的服務位址、網域名稱、虛擬 IP、閘道位址或應用程式端點。在這個入口後方，有多個後端系統準備好處理請求，而使用者無須知道實際由哪臺伺服器負責處理。
這種設計不僅簡化了存取方式，也為管理人員帶來彈性。後端伺服器可以隨時新增、移除、更新或隔離，無需更動客戶、員工、應用程式或連線裝置所使用的位址。
負載平衡器先評估後端狀態
一套完善的負載平衡系統不會盲目地轉送流量，它會先檢查後端資源是否健康、能夠回應、是否可觸及，以及是否適合接收新流量。健康檢查可能包含簡單的 ping 測試、連接埠檢查、HTTP 狀態碼確認、應用層探查，或是自訂的監控腳本。
當某臺後端伺服器無法通過健康檢查時，負載平衡器可以暫時停止將流量送給它，避免使用者被導向故障或已超載的資源。
依據策略來分配請求
完成後端狀態檢查後，負載平衡器便會決定每個請求該送往何處。這項決定可能根據輪詢順序、伺服器權重、目前連線數、回應時間、地理位置、連線駐留（Session Persistence）、應用內容或自訂規則。
對單純的系統來說，基本的分配規則或許就足夠了；但若是高流量或業務關鍵系統，分配策略可能就必須一併考量應用程式健康程度、使用者工作階段、服務優先順序、安全檢查及故障切換行為。
典型的負載平衡流程
一個基本的負載平衡流程，可以理解成由四個階段組成的作業程序，既能維持流量可控，又能保護後端資源。
常見的分配方式
輪詢（Round Robin）
輪詢方式會按照循環順序，將請求逐一分配給後端資源。這種做法簡單易懂，適合用在後端伺服器規格相近，且請求複雜度相對平均的環境。
不過，當某些伺服器的處理能力明顯優於其他伺服器，或是部分請求需要更長的處理時間時，輪詢就不見得是理想選擇。此時可能需要改用更能適應差異的方法。
最少連線數（Least Connections）
最少連線數方式會將新請求送給目前連線數最少的後端資源。這在連線保持時間長短不一的情境下特別有用，例如資料庫連線、長時間的 HTTP 工作階段、媒體串流或即時通訊服務。
這種方法有助於避免單一伺服器累積大量長時間連線，而其他伺服器卻未充分發揮的情況。
加權式平衡
加權負載平衡會為不同的後端資源設定不一樣的流量配額。效能較高的伺服器會獲得較多請求，而規格較低或較舊的伺服器則分得較少。當硬體、雲端執行個體或虛擬機器的處理能力有高低之分時，這種方式就很實用。
此外，在進行系統遷移時也可以善用權重。管理人員可先將少量流量導向新版本，待確認穩定後再逐步調高分配比例。
依據內容與應用程式屬性來路由
功能更進階的負載平衡器能夠檢查請求內的資訊，並根據 URL 路徑、標頭、Cookie、通訊協定、租戶身分、應用程式類型或服務類別來分配流量。這在網頁平臺、微服務、API 和雲端原生系統中十分常見。
例如，靜態內容可以交給其中一組伺服器，API 請求分配給另一組，即時通訊流量則導向專門的媒體服務。如此一來，系統架構不僅更有彈性，也更加高效。
核心功能
健康檢查與故障切換
透過健康檢查，負載平衡器可以偵測後端資源是否仍能處理請求。一旦某臺伺服器發生故障，流量就會自動轉移到其他資源，進而提升可用性，因為單一伺服器的故障不會癱瘓整項服務。
故障切換的機制務必經過審慎測試。管理人員必須清楚系統偵測到故障的速度有多快、現有工作階段會受到什麼影響，以及當故障資源恢復後，流量會如何重新回到該節點。
連線駐留（Session Persistence）
某些應用程式需要讓使用者在同一個工作階段內始終連到同一臺後端伺服器，這就稱為連線駐留、固定式工作階段或會話親和性。這類機制可能透過 Cookie、來源 IP 位址、權杖或應用程式識別碼來實現。連線駐留對於會在本機端暫存工作階段狀態的應用程式很有幫助，但必須謹慎使用。因為如果太多使用者都被綁在同一臺後端資源，可能會拖累流量分配的整體效率。
SSL 卸載
許多負載平衡器能在前端處理 SSL 或 TLS 加密。也就是說，來自用戶端的加密流量會先在負載平衡器上解密，再轉送給後端伺服器。SSL 卸載不僅能簡化憑證管理，也能減輕後端系統的加解密負擔。
在敏感性較高的環境中，負載平衡器與後端伺服器之間的流量也可能維持加密。合適的設計取決於安全需求、網路信任邊界、法規遵循要求以及效能需求。
能將流量從故障或狀態不佳的資源上移開，讓服務在發生部分故障時仍然可以存取。
可將請求分散到多個資源，減輕個別伺服器的壓力，並提升回應的穩定度。
隨著需求成長，可以在負載平衡器後方隨時加入新的伺服器、節點或服務執行個體。
主要效益
提升服務可靠度
負載平衡能防止單一資源成為服務的唯一供應點，進而提高可靠度。即便有一臺後端伺服器無法提供服務，健康的伺服器仍可持續接收流量。
這並不能取代完整的高可用性設計，但確實是其中關鍵的一環。一套可靠的服務通常還需要備援的負載平衡器、多重網路路徑、資料庫複本、備援電力、監控機制以及災難復原計畫。
更佳的使用者體驗
當流量分配得當，使用者就比較不會遇到網頁開啟緩慢、請求失敗、工作階段中斷或服務超載的狀況。這對網站、線上平臺、客戶入口網站、雲端應用、通訊服務和企業內部系統來說都很重要。
在流量高峰期間，使用者體驗會格外敏感。平日運作正常的系統，很可能在行銷活動、產品發表、季節性需求、公眾事件或意外事故的衝擊下發生異常。
維護作業更有彈性
負載平衡能讓維護工作變得更輕鬆，因為後端資源可以在不關閉整個平臺的情況下依序下線、更新、測試再重新上線。管理人員可以將流量從某臺伺服器排乾，同時讓其他伺服器繼續服務使用者。
這對於軟體升級、安全性修補、硬體更換、組態變更以及新版本的分階段部署都很有幫助。
典型應用場景
網站與網頁應用程式
網頁平臺普遍使用負載平衡，將 HTTP 和 HTTPS 流量分散到多臺網頁伺服器或應用伺服器上。這能幫助網站應付更多訪客、保持快速回應，並避免因單一伺服器故障而導致停機。
對現代網頁應用程式而言，負載平衡還可依據應用規則，將 API 呼叫、靜態資源、使用者工作階段和微服務請求分別導向不同的後端集區。
雲端與容器環境
雲端平臺與容器系統極度依賴負載平衡，因為服務執行個體可能會動態地建立、替換、擴充或遷移。即使後端資源頻繁變動，負載平衡器仍能提供穩定的存取端點。
在容器調度環境中，負載平衡可能同時運作在多個層級，包括 Ingress 控制器、服務網格路由、節點層平衡以及外部雲端負載平衡器。
通訊與媒體服務
通訊平臺可以將負載平衡用於 SIP 信令、媒體服務、會議系統、訊息閘道、錄音服務和 API 存取。設計時必須將通訊協定行為、連線駐留、NAT 穿透、延遲以及即時媒體品質納入考量。
對語音或視訊服務來說，光靠一般網頁式的負載平衡可能還不夠。管理人員應確認負載平衡器是否理解相關通訊協定，以及媒體路徑是否需要特殊處理。
資料庫與內部平臺
資料庫負載平衡可以分散讀取流量、將應用程式導向可用的資料庫複本，或支援節點之間的故障切換。企業內部平臺也可能將負載平衡用於身分驗證系統、檔案服務、監控平臺及業務應用程式。
資料庫的負載平衡需要周密規劃，因為資料一致性、寫入路由、複寫延遲和交易行為都可能影響應用程式的正確性。
規劃考量
選擇合適的網路層級
負載平衡可以運作在不同的網路層。第四層（L4）負載平衡主要處理 IP 位址與連接埠；第七層（L7）負載平衡則能理解 HTTP 標頭、URL、Cookie 和請求內容等應用層資訊。
L4 通常能快速且有效率地處理一般流量；L7 則能為網頁應用、API 和依應用程式內容判別的政策提供更聰明的路由。最終的選擇取決於通訊協定類型、效能要求、安全檢查需求以及路由的複雜程度。
避免隱藏的單點故障
只在多臺伺服器前方放置一臺負載平衡器，固然能改善後端分配，但如果該負載平衡器本身沒有備援，它就可能成為新的單點故障。關鍵系統通常會採用主動-被動或主動-主動的負載平衡器配對。
此外，網路路徑、DNS、憑證、防火牆規則、監控系統和管理存取權限也應一併檢視。如果存取路徑本身很脆弱，光是後端集區具備高可用性並不夠。
監控實際效能
負載平衡環境需要持續監控。重要的指標包括請求數量、回應時間、錯誤率、目前連線數、後端健康狀態、頻寬用量、CPU 負載、記憶體使用量、佇列長度以及健康檢查失敗次數。
各類報表能協助管理人員調校演算法、調整後端容量、找出瓶頸，並決定何時該進行水平擴充。如果缺乏監控，負載平衡可能會將問題隱藏起來，直到使用者開始反映抱怨。
務實的設計提醒
千萬不要把負載平衡器當成魔術般的效能萬靈丹。只有在後端系統本身健康、監控機制確實啟動、容量規劃貼近現實，且故障切換機制已於真正停機前完成測試的情況下，負載平衡才能發揮最大功效。
維護要點
檢視健康檢查設定
健康檢查應如實反映服務的實際可用狀態。一臺伺服器可能對簡單的 ping 有回應，但上面的應用程式其實已經故障。應用層級的檢查通常更有幫助，因為它們能確認服務是否真的有能力執行有意義的工作。
健康檢查的間隔和故障臨界值也需要仔細調整。過於激進的檢查，可能只因短暫延遲就誤將健康的伺服器下線；而過於緩慢的檢查，則可能持續將流量送往早已故障的資源。
測試故障切換與復原
故障切換行為應在計畫性維護期間就測試完畢，而不是等到線上發生事故時才被迫驗證。團隊必須確認：當後端伺服器故障、當負載平衡器本身故障、當某條網路路徑中斷，以及當已復原的伺服器重新加入集區時，系統分別會發生什麼事。
測試時不僅要看技術指標，也要評估對使用者的衝擊。就算從記錄檔看起來故障切換已經成功，如果狀態處理的設計不正確，仍然可能導致工作階段中斷或應用程式錯誤。
保持憑證與政策的更新
如果由負載平衡器負責 SSL 卸載，就必須謹慎管理憑證的有效期限。過期的憑證會讓健康的服務在使用者眼中變成無法存取的狀態。此外，安全性政策、加密套件設定、存取規則與記錄組態也應定期檢視。
在受監管的環境中，管理人員應該將憑證變更、存取政策更新以及流量處理規則等資訊都記錄下來，以便日後稽核與問題排查。
常見問題
負載平衡能提升安全性嗎？
若搭配 SSL 卸載、存取控制、流量過濾、整合網頁應用防火牆、速率限制與日誌記錄等機制，負載平衡確實能為安全性加分。但請勿把它本身當成一套完整的資安解決方案。
負載平衡與故障切換有什麼不同？
負載平衡是將正常流量分散到多個資源上，而故障切換則是將流量從故障的資源移往另一個可用的資源。許多系統兩者都會採用，但它們解決的是服務可靠度中不同面向的問題。
每個小型網站都需要負載平衡器嗎？
不一定。流量不高的小型網站，或許只用單臺伺服器就能運作得很好。當您開始在意正常運行時間、流量成長、維護彈性或效能穩定度時，負載平衡的價值就會浮現。
如果設定錯誤，負載平衡會引發問題嗎？
會的。錯誤的連線駐留設定、不夠嚴謹的健康檢查、不合適的路由規則、憑證出錯或後端權重配置不平均，都可能導致登入失敗、交易中斷、服務迴圈或流量全部湧向錯誤的伺服器。
負載平衡規則應該多久檢視一次？
每逢應用程式大幅改動、流量顯著成長、伺服器更換、雲端搬遷、憑證更新，或是持續收到效能相關的客訴時，就該檢視規則。對關鍵服務而言，定期檢視更應納入日常維運的一環。
