目錄
負載平衡器（Load Balancer）是什麼？
通常一個大型的資料中心裡面，每秒可能會有上百萬甚至是上千萬來自其他伺服器或是用戶端的請求。為了有效地處理這些流量，我們勢必需要針對這些流量進行管理以及平衡，而負載平衡器就是這樣的模組，專門用來處理這種大流量的問題！
負載平衡器主要是將所有用戶端的請求，根據當前伺服器負載的情況，進行分配到對應的伺服器。這樣的好處是避免伺服器過載或是崩潰。不過這邊也可以思考一下，如果當前系統的流量不高，大約只有每秒幾千個請求，則可能不太需要負載平衡器，畢竟一個系統越複雜，則需要考慮的事情越多。
負載平衡器特性
如果負載平衡器是專門處理大流量的元件，那負載平衡器應該需要有哪些特性呢？
可擴展性（Scalability）
根據 現代系統設計介紹 – 系統設計 01 有提到，一個良好的系統必須要考慮到可擴展性，因為系統用龐大需要的伺服器或是元件則越多。負載平衡器則有這樣的特性，本身是一個可以擴大或是縮小的元件，因此可以根據當前系統的系統去做擴展。
可用性（Availability）
所謂的可用性指的是，如果系統某些伺服器當機時，整個系統不會因此停止運作。負載平衡器則可以有效地處理這類型的問題，因為負載平衡器可以判斷哪些伺服器過載或是當機，而將流量導流至正常運作的伺服器，進而避免系統故障甚至停止營運。
效能（Performance）
對於負載平衡器來說，有一項非常重要的任務就是確保每一台伺服器是平均分配的，基本上來說不會有特定伺服器流量過高的問題。這樣的特性，可以確保用戶端可以獲得更快的回應時間。
負載平衡器如何運作？
先來看看如果沒有負載平衡器的話，伺服器是如何運作
如同前面所提到的，如果沒有負載平衡器，會導致流量流向特定伺服器，用戶端會因此延遲。
相反的，如果中間放置負載平衡器，則可以有效的平衡流量至對應的伺服器
AWS 負載平衡器解說
這邊提供先 AWS 的原理圖來做講解，並且附上出處與來源！
以下是 AWS 原文翻譯後的文字：
公司通常將其應用程式運行在多個伺服器上。這種伺服器佈置稱為伺服器集區。用戶對應用程式的請求首先轉到負載平衡器。然後，負載平衡器將每個請求路由到伺服器叢集中最適合處理該請求的單一伺服器。
負載平衡就像餐廳經理所做的工作。考慮一家有五名服務員的餐廳 如果允許顧客選擇服務員，那麼一兩個服務員可能會超負荷工作，而其他服務員卻閒著。 為了避免這種情況，餐廳經理將顧客分配給最適合為他們服務的特定服務員。
負載平衡器運作原理
負載平衡是由負載平衡器來去做處理的，因此可以分成兩個部分，第一個是負載平衡器這個工具，第二個則是負載平衡這件事情。
負載平衡器（Load balancer）
首先是負載平衡器可以是硬體也可以是軟體。如果是硬體的負載平衡器需要安裝專用的負載平衡設備，而如果是軟體的負載平衡器，則可以在伺服器、虛擬機器、雲端上運作。曾經在 系統設計元件介紹 Building Block – 系統設計 05 有提到的內容傳遞網路（CDN） 也通常會有負載平衡的功能，未來也會花一篇文章的篇幅，好好的講解CDN。
負載平衡演算法（Load balancing algorithms）
當用戶發送請求時，負載平衡器會將請求透過不同的演算法，來決定哪個伺服器來處理請求。這些演算法可以分成兩大類：靜態負載平衡演算法以及動態負載平衡演算法
靜態負載平衡演算法（Static load balancing algorithms）
靜態負載平衡演算法，是根據平均演算法來去做負載平衡，不會考慮當前系統的狀態。白話來說，靜態負載平衡不會知道伺服器的狀態，也無法根據伺服器過載、閒置來決定是否導入流量。而是透過最一開始根據的計畫來去分配負載。這樣的好處是非常好設定以及理解負載平衡，當然壞處是會導致效率低下。
其中常見的靜態負載平衡為輪流法（Round Robin, RR），這個演算法其實在作業系統、CPU 排程中相當常見，顧名思義就是根據時間量的長短，輪流的執行對應的任務。為了更深入講解 Round Robin 演算法，這邊也提供維基百科的範例。
在時間片長度為100毫秒的系統中，考慮下表所列舉的進程：
動態負載平衡演算法（Dynamic load balancing algorithms）
動態負載平衡演算法會考慮每一台伺服器當前狀態，包含：可用性、工作負載情況、伺服器運作情況。
並且會將流量從負擔過重或效能不佳的伺服器，轉移到尚未滿載的伺服器之中，這樣的優點是平均分配流量更加高效。不過缺點則是動態負載平衡是很難達到的，許多不同的因素都會影響到伺服器的可用性，例如：伺服器運作的情況、伺服器的記憶體容量、用戶端請求的規模。
這邊也提供幾個常見的動態平衡演算法給各位讀者，包含最少連線（Least Connection）、加權最少連線（Weighted Least Connection）、資源負載平衡（Resource-Based Load Balancing）、地理位置負載平衡（Geolocation-based Load Balancing）
全域端和本地負載平衡
前面有提到負載平衡器是什麼以及負載平衡器的運作原理，接下來講講負載平衡器的種類，基本上可以分成全域負載平衡器（Global Server Load Balancing） 以及本地負載平衡器（Local Load Balancing）。如果單純從字面上的意思，也不難看出，全域負責的範圍是跨多了地理位置的流量平衡，本地負載平衡則是負責一個大型資料中心的流量平衡。
全域伺服器負載平衡（Global Server Load Balancing）
全域伺服器負載平衡最主要的工作就是將全球的流量，平衡分散至不同的大型資料中心。例如：美國用戶的流量，透過 GSLB 來將流量分散至北美的資料中心。全域伺服器負載平衡可以根據使用者當前的地理位置、不同資料中心的狀態來去決定將流量導流至哪一個地理位置的資料中心。
這邊提供另一個例子：如果使用者在東京，並且他們正在使用伺服器位於紐約的 Web 服務，則請求和回應都必須傳輸很長的距離，這會導致載入時間明顯延遲。
使用 GSLB，全球伺服器集區可確保每個使用者都可以連接到地理位置靠近他們的伺服器，從而最大限度地減少躍點和傳輸時間。這邊的例子中，如果總部位於紐約的公司正在使用 GSLB，東京使用者可以連接到距離其位置較近伺服器，從而獲得更快速的使用者體驗。
GSLB 之於 DNS
前一篇文章 DNS 是什麼？網域名稱系統介紹 – 系統設計 06 深入講解了 DNS，不過實際上裡面的運作方式與負載平衡的概念是相關連的。DNS 重新排序 IP 位址清單以回應每個 DNS 查詢，不同的使用者也會得到 IP 位置清單。使用者也會發送請求至不同的伺服器來處理他們的請求，因此 DNS 也是透過全域伺服器負載平衡來去將請求流量，分配至不同的資料中心。
本地負載平衡（Local Load Balancing）
本地負載平衡則是一個限制在資料中心內部的負載平衡，範圍僅限於一個資料中心內部。不過本質上與負載平衡器一樣，都是將流量透過不同的演算法來去分配至對應的伺服器。
負載平衡器的實現
最一開始的介紹提到負載平衡器可以簡單分成硬體、軟體、雲端負載平衡器，以下則是三者的實現方式介紹：
硬體負載平衡器
負載平衡器在 30 年前就已經存在了，最一開始也是由硬體來去實作出負載平衡器。當然在早期年代，要用硬體時做出負載平衡器是非常昂貴的，不過好處是可以處理當時流量的使用者需求。不過到了現代，硬體負載平衡器不一定是企業的首選，主要缺點是硬體負載平衡器非常依賴於硬體，需要較高的維護、運營成本，並且還需要處理硬體相容性問題。
軟體負載平衡器
軟體負載平衡器則相較於硬體，多了幾個特性：高靈活性、可程式性、成本便宜。軟體負載平衡器也因為有高度擴展性，可以隨著系統規模越大而快速地進行設置，越來越受企業歡迎。
雲端負載平衡器
當然除了軟體以外，隨著三大雲服務商的出現，現在負載平衡器也可以使用雲端服務。其中負載平衡器及服務（LBaaS）也是在這時候出現的。當然如果對於其他的專有名詞，IaaS、PaaS、SaaS 有興趣的讀者，可以觀看這一篇 從 Zeabur 來講解 IaaS & PaaS & SaaS 是什麼？雲端服務模型介紹！。
雲端負載平衡器最大的好處是，使用者可以根據當前使用量與雲端提供商付費。並且相較於硬體、軟體的技術門檻，雲端負載平衡器是相對門檻低的。因此當前雲端負載平衡器是滿多企業的主要選擇之一。
結語
負載平衡器是系統設計中，重要的概念之一，並且也是大型系統必不可少的工具。除了可以提高系統效能以外，更可以確保系統不至於因為短時間的高流量，導致系統崩潰。
如果對於其他系統設計有興趣的讀者，也不妨觀看其他系統設計的文章，也非常歡迎留言交流！
相關文章
系統設計元件介紹 Building Block – 系統設計 05
Back-of-the-envelope 封底計算 – 系統設計 04
引用
CLOUD FLARE – What is load balancing? | How load balancers work
繁體中文 
English 
简体中文 
한국어 
日本語 
Español