負載平衡（Load Balancing）是什麼？

更新日期： 2025 年 3 月 23 日

想像你正在排隊買超人氣飲料，只有一個店員在接單，人潮爆滿，等一杯飲料要半小時。

這時店家派出三位新店員加入接單流程，大家分工合作，排隊時間瞬間縮短，客人也不再暴動——這，就是「負載平衡」的概念！

在電腦網路或伺服器的世界裡，當有大量的請求湧入（例如成千上萬的使用者同時上你家的網站），如果只靠單一伺服器來處理，肯定會超載，導致網站變慢甚至崩潰。

而「負載平衡」正是用來解決這種問題的技術，讓流量更平均、更高效地分配到多台伺服器上。

什麼是負載平衡（Load Balancing）？

負載平衡（Load Balancing）是一種網路架構中的關鍵技術。

目的是將進入系統的流量（如網頁請求、資料處理、API 呼叫等）智慧地分配到多個後端伺服器（也稱為「節點」或「服務節點」）。

以確保每一台伺服器都能平均分擔工作負載，達到最佳效能、可用性與系統穩定性。

舉例來說，當你打開一個熱門的購物網站時，背後可能有好幾十台伺服器同時在服務來自全球的用戶。

這時負載平衡器就像是前線的指揮官，根據不同的條件（如伺服器目前的忙碌程度、健康狀況、地理位置等）來分配請求，避免有某台伺服器超載，或某些伺服器閒著沒事做。

簡單來說，負載平衡的三個主要目標是：

• 提高整體系統效能（Performance）
• 保持高可用性與穩定性（Availability & Reliability）
• 支援系統擴充（Scalability）

負載平衡就像一位非常聰明的交通警察，站在多線道高速公路的十字路口，隨時觀察哪一條車道車流最順、哪條快塞爆。

然後靈活引導每一台車（用戶請求）走上最適合的道路（伺服器節點），避免任何一路堵車或空轉，讓整體交通順暢無阻。

技術架構中的位置

在現代網路架構中，負載平衡器通常位於使用者端（Client）與後端伺服器群（Backend Servers）之間，扮演「請求中介」的角色。

graph LR
    Users((使用者群)) --> LB{負載平衡器}
    
    LB -->|請求 1| S1[伺服器 1]
    LB -->|請求 2| S2[伺服器 2]
    LB -->|請求 3| S3[伺服器 3]
    
    S1 --> DB[(資料庫)]
    S2 --> DB
    S3 --> DB
    
    classDef server fill:#bdf,stroke:#333,stroke-width:1px
    classDef loadbalancer fill:#f96,stroke:#333,stroke-width:2px,color:white
    classDef users fill:#ddd,stroke:#333,stroke-width:1px
    classDef database fill:#fdb,stroke:#333,stroke-width:1px
    
    class S1,S2,S3 server
    class LB loadbalancer
    class Users users
    class DB database

使用者其實不會知道自己的請求，最終是由哪一台伺服器處理的，整個過程對使用者來說是無縫、透明的。

但正是這樣的分流機制，確保了網站或應用服務能穩定運作，即使有一部分伺服器故障也不會影響整體服務。

為什麼負載平衡很重要？

在現代網站、App、遊戲甚至雲端服務的背後，幾乎都少不了負載平衡這個看不見的關鍵角色。

從使用者體驗到系統穩定性，負載平衡扮演著不可或缺的角色。以下是它重要性的三大面向：

提高網站效能與速度

為什麼這很重要？

現代使用者對網站的容忍度極低，只要超過 3 秒沒打開頁面，就可能直接關掉換下一個網站。更不用說購物車、線上影音、遊戲登入等高流量場景，一卡就是錢包飛走、使用者流失。

負載平衡怎麼幫上忙？

負載平衡會將使用者的請求平均分散到多台伺服器，避免單一機器負荷過重。

這樣每台伺服器的反應時間都能維持在最佳狀態，大大提升整體網站或服務的回應速度與穩定性。

舉個例子：

就像是一家早餐店突然湧入 100 個顧客，如果只有一個店員做三明治，肯定忙不過來。但如果有 5 個店員分工合作，現場的等待時間就能大幅縮短。負載平衡的作用就類似這樣的「工作分配」。

增加系統穩定性與可靠性

為什麼這很關鍵？

一個穩定的系統能避免服務中斷、使用者流失，更能維持企業品牌形象。

沒有人想在刷卡結帳時網站當掉，或者影片看到一半突然斷線。

負載平衡怎麼做到？

當其中一台伺服器突然宕機（掛掉），負載平衡器會立刻偵測到，並自動將流量導向其他「健康」的伺服器。

這叫做容錯機制（Fault Tolerance），讓整個服務不中斷、持續可用。

舉個例子：

想像一下你搭捷運上班，平常固定走 2 號出口，但那天剛好在施工。系統告訴你：「出口關閉，請改走 4 號。」

你照著走，一樣能順利抵達公司，完全不影響你的通勤。負載平衡就是在做這樣的即時引導，讓服務不中斷。

提升系統擴充性（Scalability）

為什麼擴充性重要？

當網站或應用服務越來越多人使用，系統也需要跟著「長大」，這就是所謂的擴充性。

如果不能快速、順暢地應對流量成長，就會錯失商機，甚至導致整個系統崩潰。

負載平衡怎麼幫助擴充？

負載平衡的設計可以讓你在原有架構上水平擴充（Horizontal Scaling），也就是只要新增伺服器節點，就能立刻納入系統使用。

你不需要關閉網站、也不必重新設定整個服務，只要加進去，流量自然會分流過去。

舉個例子：

就像一家餐廳原本只有 5 張桌子，現在生意變好，你再加開 10 張桌子，服務生（負載平衡器）會自動把新來的客人安排到新桌，完全不用重新整修或打掉重建。擴充簡單、彈性十足。

常見的負載平衡方式

負載平衡看起來像是一個統一的概念，但實際上，它有許多不同的實作方式，根據你的需求、系統規模、預算和架構不同，會選擇不同的方法來實現。

以下是最常見的三種負載平衡方式，每一種各有優缺點。

DNS 負載平衡（DNS Load Balancing）

是什麼？

這是一種最基礎的負載平衡方式，透過 DNS（網域名稱系統）伺服器回傳不同的 IP 位址來達到「分流」效果。

當使用者在瀏覽器輸入網址（例如 example.com）時，DNS 伺服器會輪流提供不同的伺服器 IP，例如：

• 第一次：192.168.0.1
• 第二次：192.168.0.2
• 第三次：192.168.0.3

如此一來，不同使用者就會被導向不同伺服器，達到基本的流量分散。

優點：

• 架構簡單，不需要額外設備。
• 幾乎所有網域服務商都支援。

缺點：

• 不夠即時：DNS 快取會造成 IP 回應不會馬上改變。
• 缺乏健康檢查機制：如果其中一台伺服器宕機，使用者還是可能會被導向那台故障的伺服器。

舉例來說：

就像你用 Google Maps 找餐廳，它隨機給你三家分店的地址，但其中一家今天剛好沒開，Google 也沒更新，那你可能白跑一趟。

硬體式負載平衡器（Hardware Load Balancer）

是什麼？

這是一種專用設備（通常是一台高性能網路裝置），專門處理負載分配工作。大型企業或金融系統常使用這種設備，來支援高併發、高可靠性的服務需求。

常見品牌如 F5、Cisco、Citrix 等。

優點：

• 效能強大，可處理極大量的請求。
• 擁有完整的安全性設定與高階流量控制功能。
• 支援各種協定（如 HTTP、TCP、SSL 解除加密等）。

缺點：

• 價格昂貴：購買與維護成本都高。
• 彈性較差：擴充性有限，維修需實體操作。

舉例來說：

想像這像是一台「超高階總機」，能一次接聽成千上萬個電話，而且還能判斷誰是 VIP、誰要轉給哪個部門。不過這台總機價格不便宜，也不適合小型公司使用。

軟體式負載平衡器（Software Load Balancer）

是什麼？

這是目前最受歡迎、最彈性的做法之一，透過安裝在伺服器上的軟體工具來實現負載分配功能。常見工具包括：

• Nginx：簡單、輕量，除了負載平衡，還能當網頁伺服器與反向代理（reverse proxy）。
• HAProxy：高效能、穩定性佳，專為負載平衡設計。
• Traefik：雲原生時代的新星，與 Docker、Kubernetes 整合方便。

優點：

• 成本低（甚至免費）。
• 配置彈性高，容易調整與擴充。
• 社群資源豐富，學習門檻適中。

缺點：

• 需要一點技術知識來設定與維護。
• 效能可能略低於硬體解決方案，特別是在高併發情境下。

舉例來說：

這就像是你自己架了一個分流系統，可以自訂規則、條件、甚至加入自動化判斷。

如果你熟悉這些工具，它的靈活程度遠比硬體高，而且維護方便、擴充快速。

小補充：雲端平台內建的負載平衡服務

現在很多開發者都直接使用雲端平台的負載平衡工具，不用自己設定硬體或軟體。

像是：

• AWS Elastic Load Balancer（ELB）
• Google Cloud Load Balancing
• Azure Load Balancer

這些服務已經內建健康檢查、地區分流、自動擴展等功能，特別適合使用雲端部署的應用程式。

不用自己管理伺服器，也可以享有強大的負載平衡效果。

總結：依據需求選擇適合你的方式

負載平衡器的運作原理

負載平衡器不像魔術師，它的行為其實有一套明確的邏輯。

它如何知道「要把這個請求送去哪一台伺服器」？

答案其實就在兩大核心功能中：健康檢查（Health Check）與分配演算法（Routing Algorithm）。

你可以把負載平衡器想像成一位高效率的客服櫃檯人員：

1. 他隨時掌握每位同事（伺服器）的狀態，有人生病請假（宕機）就不派工作過去。
2. 他根據工作量、排班順序或客戶特性，靈活地分配每一筆工作。

flowchart LR
    Users((使用者)) --> LB{負載平衡器}
    
    subgraph LB
        HA[健康檢查]
        RA[路由演算法]
    end
    
    LB -->|檢查狀態| S1[伺服器 1<br>正常]
    LB -->|檢查狀態| S2[伺服器 2<br>正常]
    LB -->|檢查狀態| S3[伺服器 3<br>故障]
    
    LB -->|分配請求| S1
    LB -->|分配請求| S2
    LB -.-x|停止分配| S3
    
    S1 --> DB[(資料庫)]
    S2 --> DB
    
    classDef normal fill:#bdf,stroke:#333,stroke-width:1px
    classDef failed fill:#faa,stroke:#333,stroke-width:1px
    classDef loadbalancer fill:#f96,stroke:#333,stroke-width:2px,color:white
    classDef database fill:#fdb,stroke:#333,stroke-width:1px
    
    class S1,S2 normal
    class S3 failed
    class LB,HA,RA loadbalancer
    class DB database

健康檢查（Health Check）

是什麼？

健康檢查是一種定期自動化機制，用來確認每一台後端伺服器是否「還活著」並能正常處理請求。

它怎麼做？

負載平衡器會不斷地向每台伺服器發送測試請求，例如：

• ping 指令
• 嘗試連接某個 API 路由（例如 /healthz 或 /status）
• 連線到特定埠（port）測試回應時間

如果連續幾次都沒收到回應，就會判定該伺服器「不健康」，暫時從流量分配名單中移除。等它恢復正常時，才會重新加入。

為什麼重要？

這就像一間公司安排排班時，先確認哪些員工今天有上班、有沒有生病。如果明明請假了還把任務派給他，那工作根本完成不了。

分配演算法（Routing Algorithm）

當確認伺服器「健康」，接下來的任務就是「怎麼分配請求？」這就進入演算法的範疇。

負載平衡器會根據不同策略來做決策，以下是幾種常見的演算法：

A. Round Robin（輪詢法）

概念：按照順序一台一台輪流分配請求。第一個給 A、第二個給 B、第三個給 C，第四個再從 A 開始，依此類推。

適合場景：後端伺服器能力差不多，流量也平均的情況。

舉例比喻：就像老師點名叫同學報告，每個人輪一次，不重不漏。

B. Least Connections（最少連線數）

概念：分配給目前處理請求最少的那台伺服器，讓忙的先喘口氣，空的先接客。

適合場景：後端伺服器處理複雜任務（如影音編碼、資料庫查詢），每筆請求處理時間長短不一。

舉例比喻：就像醫院掛號，會把你分派到診間裡目前病人最少的醫師，這樣你可以比較快輪到。

C. IP Hash（根據 IP 位址分配）

概念：根據使用者的 IP 位址計算出一個哈希值，對應到特定伺服器。這樣每位用戶通常會被固定導向同一台伺服器。

適合場景：當伺服器需要記住使用者狀態（Session），或希望使用者一直連到同一台機器時（例如登入狀態、購物車等資料）。

舉例比喻：就像你每次打電話給客服，系統會固定幫你轉接到熟悉你的專員，這樣處理會更快。

D. Weighted Round Robin / Weighted Least Connections（加權版本）

概念：類似輪詢法與最少連線法，但會根據伺服器性能設定權重。例如 A 是高配伺服器，可以處理兩倍請求，就會多分給它一些。

適合場景：當伺服器等級不同，有的強、有的弱時。

舉例比喻：像分配搬運任務時，壯漢搬 3 箱，瘦子搬 1 箱，平均又有效率。

流量類型的判斷與分流

高階的負載平衡器還能根據「流量的內容」來做分流，例如：

• 根據網址路徑：/api/ 的流量送到 API 伺服器，/images/ 的流量送到靜態資源伺服器。
• 根據裝置類型：手機的流量導向行動版網站，桌機則導向完整版。
• 根據地理位置：東南亞流量導向新加坡機房，美洲流量導向美國伺服器。

這樣的功能需要更進階的設定與邏輯判斷，但卻能大幅提升效能與用戶體驗。

從「誰還活著」到「怎麼分工最合理」，負載平衡器不是隨便亂丟請求，而是根據系統健康與流量情境做出智慧選擇。這不只是網路架構的基礎，更是確保服務穩定與擴展彈性的核心關鍵。

實際生活中的應用場景

雖然「負載平衡」這個詞聽起來像是專屬工程師的技術用語，但事實上，它每天都默默出現在你我的生活中。

我們打開手機看影片、玩遊戲、買東西時，負載平衡正悄悄在後台努力，確保整個體驗順暢不當機。以下是三個常見且具代表性的應用場景：

電子商務網站：秒殺搶購背後的「流量分流大作戰」

情境說明：

以蝦皮、momo、PChome 等大型購物平台為例，每逢雙11、黑五、年終慶等促銷活動，網站同一時間會湧入幾十萬甚至上百萬名使用者，大家拼手速搶購秒殺商品、瘋狂下單。

挑戰：

這些行為會在短時間內產生巨量的 HTTP 請求，從瀏覽商品頁面、加入購物車、送出訂單、付款驗證到物流查詢，每一步都需要與伺服器互動。

如果這些請求同時打到單一伺服器，那麼不只網站會變慢，甚至會整體崩潰導致服務中斷。

負載平衡的角色：

負載平衡器會像一個交通指揮官，根據即時的伺服器狀態，把大量湧入的請求分散到數十台甚至數百台後端伺服器中。

同時它也會針對失效伺服器排除流量，確保即便有節點故障，整個系統依然能穩定服務使用者。

成果：

• 用戶依然能順利下單搶購，網站不卡不當機。
• 電商平台維持高效能與穩定度，保障銷售與商譽。

串流影音平台：畫面不卡頓的祕密武器

情境說明：

你晚上躺在沙發上，打開 Netflix 追劇；隔壁小孩在用 YouTube 看卡通；爸媽則在電視上播 Disney+。

像這樣的情況，每天都在全球數百萬個家庭同步上演。

挑戰：

影片串流非常吃資源，尤其是高畫質（HD、4K）的影片會產生大量的資料流，對伺服器與頻寬造成極大負擔。

如果無法即時回應、緩衝過慢，使用者就會出現畫面卡頓、影片讀不出來的情況。

負載平衡的角色：

串流平台會部署大量的內容傳遞伺服器（Content Delivery Servers），並透過負載平衡技術：

• 將觀看者導向最近或最少負載的伺服器
• 根據影片類型、地理位置、用戶設備來做智慧分流
• 結合 CDN（內容傳遞網路）進行分區處理

成果：

• 即使有數百萬人同時觀看，也能保證影片即時播放、無卡頓
• 使用者的觀影體驗自然流暢，平台滿意度與續訂率提升

線上遊戲伺服器：千軍萬馬中保持遊戲不斷線

情境說明：

在一款大型線上遊戲（如《英雄聯盟》、《原神》、《Final Fantasy XIV》）中，高峰時段常常有數萬名玩家同時上線登入遊戲伺服器、進行配對、參與活動或戰鬥。

挑戰：

即時遊戲對於「延遲（lag）」非常敏感，只要伺服器稍微塞車或處理不及時，畫面就會卡頓、技能施放延遲，甚至造成角色瞬移、掉線，嚴重影響玩家體驗。更別提大型多人副本或跨區戰爭場面，負載劇增更容易出現系統瓶頸。

負載平衡的角色：

遊戲服務提供商會使用負載平衡技術：

• 在登入階段，將玩家導向最空閒或最靠近他地理位置的伺服器
• 在遊戲中，動態監控伺服器狀態，及時調整分配邏輯
• 將後端不同功能（如聊天系統、配對系統、遊戲引擎）獨立分層，再個別實施負載平衡，讓每個模組都有最適化的流量處理

成果：

• 遊戲畫面順暢、指令反應即時，即便在大型戰場也能穩定執行
• 減少玩家斷線或排隊等待時間，提升遊戲黏著度與品牌信任度

從電商的搶購狂潮，到你晚上的追劇時光，再到熱血的遊戲戰場，負載平衡就像是數位世界中的「交管中心」，默默調度每一筆請求、確保所有人都能順暢上線、即時互動。

它可能不被用戶看見，但只要有負載平衡存在，網站就不會崩、影片不會卡、遊戲不會斷。這就是它為何如此重要，也是所有網路架構中最值得認識的基礎技術之一。

初學者如何入門？

負載平衡聽起來雖然偏向進階技術，但其實只要抓住核心概念，再透過一些實作練習，就能輕鬆上手。

這裡提供一份實用的入門指南，從觀念到實作，幫助你一步步建立對負載平衡的理解與操作能力。

建立基礎網路概念

在學習負載平衡之前，先理解一些核心的網路基礎觀念，會讓後續的學習事半功倍。

你可以從以下幾個方向入手：

• 什麼是 HTTP 請求？（GET、POST、連線與回應的流程）
• IP 位址與 DNS 是什麼？
• 伺服器與客戶端的互動方式
• 什麼是「伺服器超載」、「單點故障（Single Point of Failure）」？

▶ 建議資源：

• MDN Web Docs（非常適合初學者）
• YouTube 搜尋「網路基礎概念入門」

從 Nginx 開始學習最簡單的負載平衡

為什麼選 Nginx？

Nginx 是一個免費、輕量級、高效能的網頁伺服器，同時也是非常受歡迎的軟體式負載平衡器。

它不只簡單好上手，網路上的教學資源也非常豐富，是初學者的絕佳起點。

實作練習（示意）：

1. 安裝 Nginx
2. 建立三個假設的後端伺服器（可以是三個不同的 localhost 埠口）
3. 編輯 nginx.conf 加入以下設定：

http {
    upstream backend_servers {
        server 127.0.0.1:8081;
        server 127.0.0.1:8082;
        server 127.0.0.1:8083;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend_servers;
        }
    }
}

4. 啟動 Nginx，觀察請求會被平均分配到不同的後端伺服器。

學習目標：

• 看懂 Nginx 如何設定 upstream（後端伺服器群）
• 實際觀察負載平衡器分流請求的效果
• 嘗試使用不同演算法（如 least_conn）做變化實驗

了解不同演算法的應用邏輯

學習負載平衡不能只靠抄範例，更重要的是理解「演算法為什麼這樣設計」、「在什麼情況下適合用哪一種演算法」。

你可以用這幾個問題幫助自己思考：

• 什麼情況適合用輪詢（Round Robin）？
• 什麼時候該選最少連線（Least Connections）？
• Session 需要維持時要怎麼做？（可能就要用 IP Hash 或 Sticky Session）

▶ 建議延伸閱讀：

• HAProxy 官方文件
• Nginx Docs: Load Balancing

實戰練習與模擬高流量測試

當你已經熟悉基本設定後，可以進一步模擬「高流量」的場景來驗證負載平衡的效果。可以使用工具像：

• Apache Bench (ab)：簡單測試 HTTP 請求的工具
• wrk：效能更強、適合壓力測試
• JMeter：支援圖形化介面，功能強大

試著對你的 Nginx 負載平衡架構進行壓測，觀察請求如何被分流、效能表現如何。

進階探索雲端負載平衡

當你對本機的軟體式負載平衡有基本了解後，可以進一步探索雲端平台提供的負載平衡服務。

這些服務自帶健康檢查、自動擴充與高可用性，是真實企業架構中常見的做法。

常見平台與工具有：

• AWS Elastic Load Balancer (ELB)
• Google Cloud Load Balancing
• Azure Load Balancer
• Kubernetes Ingress Controller + LoadBalancer Service

雲端教學平台如 Coursera、Udemy、AWS Academy 都有免費或平價課程，非常適合初學者延伸學習。

實作專案、打造作品集

將學到的技術應用在小型專案中，才是真正理解與內化的關鍵。例如你可以嘗試：

• 架設一個簡單的購物網站，讓請求透過 Nginx 分流到不同服務
• 做一個聊天室系統，觀察使用者如何分配到不同的服務節點
• 用 Docker 建立多個後端服務，透過 Nginx 做負載平衡

將這些實作過程寫成技術筆記或部落格，不但幫助自己複習，也能成為作品集的一部分，對求職或轉職非常有幫助。

負載平衡聽起來可能偏向資深工程師的範疇，但對初學者來說，只要掌握基礎概念、挑一個好工具實作，再循序漸進地探索應用場景與進階技巧，其實一點都不難。

記住：學習負載平衡，不只是為了技術，更是為了打造更穩、更快、更可靠的服務。

結語：不只是技術，更是穩定網路世界的幕後英雄

負載平衡不是只有工程師才需要懂的黑科技，它其實與我們每一次順暢的上網、穩定的線上交易、流暢的影劇播放都有關。

對初學者來說，了解這背後的機制，是邁入網路世界專業領域的第一步。

從認識開始，再到實作體驗，你會發現，這項技術遠比你想像的還要重要。