加權負載均衡演算法

『壹』 軟體架構中，負載均衡有哪些調度演算法

謝邀！
負載均衡調度演算法也叫負載均衡方法有很多種，下面以使用比較廣的nginx為例說說軟體負載均衡的調度演算法：
nginx默認的調度演算法，按照時間順序逐一分配後台伺服器
在server後加weigth，weight值越高，後台伺服器分配概率越大，下圖是說ip為102的後台服務分配概率是ip為101後台服務的兩倍
按照訪問ip的hash分配，增加ip_hash關鍵字，同一ip訪問相同的後台服務
按照訪問url的hash分配，增加url_hash關鍵字，同一url訪問相同的後台服務
按照最少連接數方式分配，增加least_conn關鍵字，哪個後台服務連接數少就分配哪個
按照最短響應時間分配，增加fair關鍵字，響應時間短的後台服務優先分配

『貳』 負載均衡進階：SLB常見問題解決方法

摘要： 在由雲棲社區和阿里雲網路團隊聯合主辦的2017阿里雲網路技術在線高峰論壇上，阿里雲技術專家添毅分享了網路產品部根據客戶和阿里雲運維的反饋提煉出的幾大最主要和最常見的在使用SLB產品中發生的問題，並為大家介紹了針對這些常見問題的相應處理方法。

摘要： 在由雲棲社區和阿里雲網路團隊聯合主辦的2017阿里雲網路技術在線高峰論壇上，阿里雲技術專家添毅分享了網路產品部根據客戶和阿里雲運維的反饋提煉出的幾大最主要和最常見的在使用SLB產品中發生的問題，並為大家介紹了針對這些常見問題的相應處理方法。想知道如何藉助SLB構建高可用系統以及健康檢查是如何實現的，本文不容錯過！

本文內容根據演講嘉賓分享視頻以及PPT整理而成。

本次的分享將會主要圍繞以下5個部分

基本概念回顧

如何構建高可用系統

選擇性能共享型還是性能保障型實例

為什麼健康檢查異常

為什麼負載不均衡

一、基本概念回顧

SLB是什麼

SLB是阿里雲推出的一款雲負載均衡服務，其主要針對於多台雲伺服器進行流量分發，能夠將業務流量分發到由多台雲伺服器所組成的後端伺服器池上去，以此來提升系統的處理能力。負載均衡所解決的問題主要包括兩點：第一點，SLB能夠消除系統的單點故障，這是因為SLB的後面是由多台雲伺服器組成的伺服器池，那麼當其中某一台伺服器出現故障的時候並不會影響整個系統的可服務性。第二點，由於後端的雲伺服器能夠橫向地進行擴展，所以也具有為海量業務提供服務的能力。那麼，為什麼要使用雲上的負載均衡呢？這是因為雲上負載均衡主要有這樣的幾個特點：高可靠、高性能、低成本、安全性、易用性。

SLB基本組件

阿里雲的SLB主要包括了三個基本組件，這里也進行簡單地介紹。第一個基本組件就是實例，每個實例都唯一地標識了雲負載均衡器，並且每個實例都對應一個VIP，VIP唯一地標識了負載均衡實例，也是負載均衡對外提供服務的地址。第二個組件是監聽，監聽是由VIP+埠號來唯一標識的，一個監聽中包含用戶定製的負載均衡策略和轉發規則。最後一個基本組件就是後端掛載的伺服器，也就是雲伺服器ECS，負責處理真正的業務請求。

二、如何構建高可用系統

多層次的高可用

如下圖所示，阿里雲的負載均衡是從四個層面上去構建高可用的。從底層往上層看，分別是應用級別的高可用、集群級別的高可用、可用區級別(AZ)的高可用以及地域級別(Region)的高可用。

應用級別的高可用主要是通過針對SLB後端的ECS實例的健康檢查來實現的。當SLB發現後端不健康的或者不能正常工作的ECS的時候，會將這些不健康的ECS從SLB的轉發路徑中剔除掉，保證業務流量能夠轉發到正常的工作伺服器當中。集群級別的高可用主要是通過集群中LVS機器間的session同步來保障任何一個用戶的業務會話都能夠在所有的LVS機器上是相互同步的，當其中某一台LVS出現故障時，可以由其他的LVS來接替出現故障的機器的工作。同時，由於會話保持的存在，用戶的業務是不會發生中斷的。對於可用區級別的高可用和地域級別的高可用，在本文的後面會進行更加詳細的介紹。

細說可用區級別容災

這里詳細地介紹一下可用區級別的容災。可用區級別容災的設計初衷是在當一個可用區出現重大災情的時候，比如整個可用區的機房發生了掉電、光纜出現了中斷、整個可用區機房中所有的物理機都無法正常工作的時候，也就是整個可用區都宕掉了的情況下，能夠由備可用區來繼續提供服務，這就是可用區級別容災的設計初衷。可用區級別的容災並不是說某一個可用區中的某一個實例或者是某幾個實例出現了故障就會發生可用區的切換，實例自動從可用區A切換到可用區B，這是一個比較常見的誤區。而針對於這樣的誤區，阿里雲也建議用戶在構建可用區級別的高可用的時候採取以下兩個步驟：

首先，建議用戶在SLB實例的後端盡可能地去掛載多個可用區的ECS實例。SLB能夠支持跨可用區地掛載ECS雲伺服器，這樣可以避免某個可用區的ECS都出現故障的情況下，還有其他可用區的ECS能夠接替工作，雖然跨可用區掛在ECS會存在大約2毫秒左右的延遲，但是卻能夠大大地提升服務的可用性。

第二步就是針對於一些特別重要的業務，建議在不同的可用區分別地去購買SLB的實例。比如在可用區A和可用區B各自購買一個SLB實例，在此基礎之上再使用全球負載均衡GSLB來進行實例間的調度。

跨地域容災的實現

跨地域容災這一部分與上面介紹的可用區級別容災的第二步非常相似，也是藉助於GSLB產品實現的，GSLB即 智能DNS實現了針對於後端的健康檢查、路由調度的優化功能，能夠實現在地域之間的負載均衡實例的調度。關於這部分的更詳細的內容請參考：全球負載均衡跨地域容災解決方案(https://promotion.aliyun.com/ntms/act/globalslb.html)。

三、選擇性能共享型還是性能保障型實例

共享型vs保障型-WHY保障型

在如今這個共享經濟的時代，像滴滴打車這樣的模式是非常火的。但是即便是有了滴滴打車，但是還有人會去買車，這是因為會出現如下兩個大家可能曾經都碰到過的場景：

早晚高峰叫不到車？雨雪天氣路邊凍成狗？還大幅提價？

假期想遠離塵囂，找個僻靜曠野放空自我，叫個滴滴？也許有去，但保證無回！

所以說共享和保障都是客戶的需求。出於對於類似需求的考慮，阿里雲的負載均衡也推出了性能保障型實例。以前所推出的SLB共享型實例是因為性能指標沒有辦法實現隔離，因為所有的共享型實例都處於同一個大共享資源池中，所以在高峰期的時候就會出現資源的爭搶，這樣就無法滿足對於性能具有剛性需求的大客戶的訴求。除此之外，還有一些體量特別大的超級用戶，他們對於性能的要求會是非常高的，但是由於共享型實例無法做到性能隔離，也支持不了大顆粒度的性能指標，所以也無法完成這樣的工作。因此，阿里雲推出了性能保障型的負載均衡實例。

超強性能

保障型實例的性能規格如上圖所示，其並發連接數最大可以達到500萬，每秒的新建鏈接數(CPS)可以達到50萬，針對於七層負載均衡系統的QPS可以達到10萬。除此之外，性能保障型實例還具有以下的特點：

超強HTTPS性能。 性能保障型實例針對於七層系統，特別是HTTPS的業務進行了優化，實現了高性能硬加解卡，並且能夠實現使HTTPS的業務單實例可達10萬QPS。

超大並發連接數。 性能保障型實例的單實例的並發連接數可達500萬，所以其可承載物聯網場景的下海量連接，可以支撐共享自行車、智能手錶等存在特別大量長連接的場景。

共享型實例平滑升級。 原有的共享型實例可以平滑升級至性能保障型實例，而無需更換VIP。

完善的業務監控系統。 在推出性能保障型實例之後，因為每個實例都有相應的性能規格和性能指標，所以阿里雲也為用戶提供了完整的業務指標監控系統，並支持電話、簡訊、釘釘企業群等方式的告警。

性能規格

上圖所展現的是阿里雲SLB性能保障型實例的規格參數。圖中的最後兩行規格7、8默認在控制台上是無法購買的，目前只針對企業級用戶，而且需通過客戶經理申請後，通過白名單開放。

如何選擇規格

對於保障型實例而言，主要有如下幾個性能指標：

最大連接數：一個實例可承載的最大連接數。

新建連接數：CPS表示一個實例每秒可以新建的鏈接數。

每秒查詢數：QPS表示一個實例7層的像HTTP或者HTTPS系統的吞吐量。

通常一個4層SLB的性能好壞由最大連接數和新建連接數來衡量，它們表示了一個SLB系統的並發能力和處理突發連接的能力。通常一個7層SLB的性能好壞主要由QPS決定，QPS表示了一個7層系統的吞吐量。這里需要注意的是QPS是7層獨有概念。雖然每個規格都定義了三個性能指標，但是這並不代表這三個性能指標在任何一個性能場景下或者任何一個時刻都能夠同時達到最大值，這里存在一個性能指標的短木板原則。比如在某一個應用系統中，QPS已經達到指標上限，但最大連接數還遠遠沒有達到上限，這時不論怎樣加大客戶端數量，最大連接數都會因為QPS達到上限，而無法達到最大值。

對於規格的選擇而言，需要通過之前提到的業務監控系統來獲取相關指標。如果用戶十分了解自己業務的相關指標，也就是對於高峰期的並發連接數會達到多少以及QPS會達到多少都有非常清晰的了解，也可以直接在控制台上選購。但是如果用戶並不清楚自己的相關業務指標，可以在初期選購按量付費的較高規格的實例，並且在一個業務周期內監控流量的峰值，在峰值確定好之後再通過變配的方式改變到比較合適的實例規格。目前性能保障型實例還處於公測階段，所以現在還沒有對於實例收取規格費用，也就是說在這個階段無論用戶選擇最小規格還是最大規格，實際上都只需要花費IP配置費和帶寬費就可以了，這樣也比較便於用戶去熟悉和使用阿里雲的性能保障型實例。

監控和告警

前面也有所提及，在負載均衡的控制台上面能夠直接地顯示出相應的一些性能指標，但是在這里只能夠實現對於性能指標的監控，卻無法進行告警。如果用戶需要進行監控告警，可以在阿里雲所提供的雲監控控制台進行操作。雲監控平台可以監控阿里雲中的所有產品並且實現業務告警的定製，並且可以選擇包括簡訊郵件、電話、企業釘釘群等方式進行業務的實時告警。

四、為什麼健康檢查異常

健康檢查機制

接下來分享在負載均衡的日常使用中出現的問題，特別是很多用戶都存在疑問的健康檢查部分的問題。

阿里雲的負載均衡一共可以支持四種協議，四層的負載均衡系統主要包括了TCP、HTTP以及UDP協議，而七層的系統則包括了HTTP和HTTPS，而由於目前HTTP和HTTPS都是使用的普通的HTTP方式，所以其實也可以歸結為三類協議。對於TCP而言，健康檢查的過程是通過發送ACK這種TCP的探測報文去探測埠是否仍然存活；對於HTTP而言，則主要使用的是HEAD的請求方式來檢查目標的頁面是否正常；UDP部分則主要借鑒了SMP協議的原理。

健康檢查部分主要會涉及到幾個指標，這些指標需要用戶在控制台上進行設置，上圖中給出了一些默認的建議值，比如響應的超時時間，也就是在每一次進行健康檢查的時候，如果超過一定時間健康檢查還沒有回應就認為這次的健康檢查是失敗的；還有健康檢查間隔，也就是兩次健康檢查之間通常需要間隔2秒鍾；而所謂的不健康閥值和健康閥值就是在網路環境中往往會由於網路的抖動以及其他的因素導致偶爾的一次健康檢查失敗了，但是這時候並不能認為服務是真的失敗了，所以需要設置一個閥值，比如3次就指的是當3次健康檢查都失敗的時候才會認為後端的服務是存在問題的，然後將其從轉發路徑中摘除掉。同樣的，當服務從不健康變為健康的時候，也需要進行連續的幾次探測，當確定處於穩定的健康狀態之後再將其加入到SLB的後端中去。

為啥會失敗(TCP)

TCP的健康檢查也經常會出現一些失敗的情況，這里也為大家提供了簡單的故障排查順序供參考。當出現健康檢查失敗的時候，首先可以檢查一下後端的伺服器是否已經啟動。如果後端伺服器的負載是比較高的，也可能會因為沒有CPU時間去處理健檢查的回應，這樣就有可能導致健康檢查失敗。除此之外，因為對於阿里雲的負載均衡而言，健康檢查使用的都是私網地址實現的，所以如果根本沒有監聽到私網地址或者私網地址本身存在故障也會導致健康檢查的失敗。還有伺服器上可能存在防火牆，將監聽埠屏蔽掉了，導致健康檢查並未通過。此外還可能存在一些配置方面的問題，比如提供服務的埠和做健康檢查的埠不一致也可能存在健康檢查失敗。

針對於TCP的健康檢查而言，很多用戶會經常看到自己的後端伺服器上日誌上面有很多10或者16這些網段的訪問，並且訪問流量還比較大，這是因為之前所提到的健康檢查具有一定的間隔時間，比如2秒或者3秒一次。這時候一些用戶可能就會認為健康檢查會影響伺服器的性能，佔了很多的伺服器的連接數。其實可以從上圖中左側的報文交互情況看到，當SLB對於雲伺服器發起健康檢查的時候首先會發一個SYN的請求，如果伺服器埠是存活的，那麼它會回應一個ACK，這個時候SLB端就會緊接著發送RST報文。也就是說實際上連接是並沒有建立的，所以也不會佔用後端伺服器的連接數的資源，並且對於性能的影響也是極為有限的。

為啥會失敗(HTTP)

HTTP常見的健康檢查失敗原因大概會有這樣的三點：最常見的情況就是有些用戶把伺服器的HEAD請求方式禁掉了，因為默認在使用瀏覽器或者手機等請求一個頁面的時候使用的都是GET方式，有時候可能需要上傳數據則會使用POST方式，雖然很多伺服器都支持HEAD請求方式，但是有些伺服器可能會處於安全或者其他復雜因素的考慮將HEAD請求禁掉。所以在這里建議客戶將伺服器的HEAD請求方式打開，因為阿里雲負載均衡七層健康檢查方案就是使用的HEAD方案。另外一種常見情況就是頁面訪問本身上就存在問題，這樣的情況下健康檢查也是無法通過的。最後一種常見情況就是期望結果配置錯誤，針對於七層的健康檢查是通過使用HEAD請求方式去請求頁面，頁面返回碼可能會是200、300或者400以及500等，用戶可以在健康檢查的配置中設定預期的正常情況下的返回碼值，當健康檢查返回碼值與預期值不一致就會判定健康檢查是失敗的。

為啥會失敗(UDP)

這里介紹一下UDP健康檢查的原理。首先，健康檢查通過SLB向後端發送UDP報文探測來獲取狀態信息。SLB會周期性地給後端ECS發送UDP報文，如果UDP埠的業務處於正常情況，則沒有任何回應。而當服務出現問題，比如指定的UDP服務埠處於不可達的情況或者無服務的狀態的時候，會回復ICMP的不可達報文。這里也會存在一個問題就是如果後端伺服器已經變成了網路中的孤島，比如出現了整個伺服器的掉電、關機情況這樣完全不能工作的狀態，這時候的ICMP不可達報文是永遠不可能收到的，因為後端的伺服器無法收到SLB發來的UDP探測報文，那麼在這種情況下，可能會出現誤認為後端健康的情況，但是實際上這個服務可能已經宕掉了。為了應對這種情況，健康檢查還提供用戶自定義UDP應答報文來實現精確的UDP健康檢查，也就是由用戶自定義指定一個字元串，當後端的雲伺服器收到UDP健康檢查的探測的時候，也回應指定的字元串，之後SLB對於這個字元串進行對比和校驗，如果匹配成功則認為服務一定是健康的，這樣就可以實現非常精確的健康檢查。

而UDP的健康檢查失敗也有很多原因，比如在協議棧裡面有可能會有ICMP限速保護。當頻率達到一定速率的時候，ICMP會被協議棧限制，後端無法回應ICMP不可達報文，進而導致SLB收不到ICMP的報文，出現健康檢查的失敗情況。所以這部分是需要注意的，如果可能盡量將速率限制放大一些。

其他問題

健康檢查時好時壞的可能原因如下：

HTTP類型健康檢查目標URI響應慢。比如本身是動態頁面，會涉及到大量的計算才能夠渲染完成並返回到前端，這樣肯定就會導致健康檢查響應比較慢。如果伺服器負載過高同樣也會出現這樣的問題。

未全部放開對SLB健康檢查源地址的限制導致分布式健康檢查失敗。因為阿里雲的伺服器都是分布式的部署，健康檢查也會是分布式的探測，LVS等機器在後端有不同的源去針對某一個雲伺服器進行探測的，所以如果沒有將這些源地址都放開，實際上也會影響健康檢查的效率，因為對於這么多機器而言，只要有一台機器檢測到是正常的那麼就是正常的。

還可能出現直接訪問正常，但是健康檢查失敗的情況。造成這樣情況的可能原因如下：

防火牆限制。

目的埠不一致。

檢查方法不同，可能使用瀏覽器看頁面是沒問題的，但是健康檢查卻不行，這就是因為剛才所提到的HEAD方法沒有開啟。或者七層的健康檢查配置了URL按照域名轉發，但是在瀏覽器上直接訪問則是使用域名去做的，而健康檢查是使用IP地址做的，這樣也可能出現轉發和預期結果的不同。

檢查頻率不同，ICMP限速。

五、為什麼負載不均衡

調度演算法與會話保持

首先介紹一下負載均衡的調度演算法。阿里雲的負載均衡支持三種演算法，第一種演算法是單純的輪詢(RR)，也就是將業務的請求依次地分發到後端的伺服器。第二種演算法是加權輪詢(WRR)，也就是在處理調度的時候會根據針對於每一台後端伺服器設置權重來進行轉發。這里之所以設置權重是因為後端伺服器的處理能力可能是不同的，如果使用相同的權重進行輪詢可能就會把後端處理能力比較弱的伺服器擠爆，所以需要針對於伺服器的處理能力設置一些權重。第三種演算法是針對於加權最小連接數的輪詢(WLC)，也就是除了根據每台後端伺服器設定的權重值來進行輪詢，同時還考慮後端伺服器的實際負載，也就是連接數。當權重值相同時，當前連接數越小的後端伺服器被輪詢到的次數也越高，這樣就能夠保證負載盡量地均衡。如果不考慮這一點就會造成某些伺服器連接數已經很高了但是流量依然還往上面分發，而另外一些伺服器卻一直處於空閑狀態。

會話保持指的是來自同一用戶請求始終保持分發到同一台後端的雲伺服器上。對於同一用戶而言，使用的是四層的負載均衡和使用七層的負載均衡在理解上是不一樣的。如果是四層負載均衡，則會使用源IP地址標識同一用戶，所以如果在可能會有很多辦公電腦的大型企業中，這些電腦在企業內部是通過區域網的IP進行通信的，在訪問公網的時候都是通過NAT網關處理的，所以在走到Internet的時候，源地址通常會是一個或者很有限的幾個。在這種情況下，如果是四層的負載均衡就會把裡面所有的請求都視為來自同一個用戶的，這種情況下如果開啟了會話保持，就會發生問題。而七層的負載均衡是根據用戶瀏覽器中的Cookie來進行唯一識別的，對於剛才的案例在大型企業裡面因為內網訪問公網的源地址都是一樣的，導致沒有辦法識別到底是不是同一個用戶，此時建議使用七層的負載均衡方案解決，因為Cookie是每個瀏覽器都唯一的。會話的保持時間是可以在控制台上配置的，四層的負載均衡方案最大可達1小時，而七層的方案最大可達24小時。

為何不均衡

最後分享一下不均衡的常見情況。有時候會需要新加一個伺服器進來，這時候往往到新加進來的伺服器上的連接會很少，這是因為可能會存在以下原因：

存在會話保持的情況下，會話保持會讓請求停留在原有的伺服器上，這樣到新加進來的伺服器上的連接自然會少一些。

權重設置不一致，如果在權重的設置上存在區別，而新加進來的伺服器的權重如果很低，連接也過不去。

應用屬於長連接類型，因為需要在TCP上復用，如果客戶端不主動斷開連接，後續所有的請求都會繼續復用當前伺服器上的連接，只有新建連接才有可能到新的伺服器上。

而有時候在業務量或者新建連接較少時，也會出現負載不均衡的問題。這是因為每個Core都是獨立的調度單元，因此可能存在將某個Client的多條業務經過不同core的調度後全部轉發到一台ECS上的情況，同時由於業務量較少，因此出現了不均衡。建議使用輪詢演算法解決，在RR輪詢演算法中加入了擾亂因子，可以更加有效的打散SLB到後端的轉發路徑。

原文鏈接

『叄』 計算機的負載均衡演算法

計算機的負載均衡演算法主要有以下幾種：

1、靜態負載均衡演算法包括：輪詢，比率，優先權。

2、動態負載均衡演算法包括：最少連接數，最快響應速度，觀察方法，預測法，動態性能分配，動態伺服器補充，服務質量，服務類型，規則模式。

負載均衡演算法的種類有很多種，常見的負載均衡演算法包括輪詢法、隨機法、源地址哈希法、加權輪詢法、加權隨機法、最小連接法等，應根據具體的使用場景選取對應的演算法。

(3)加權負載均衡演算法擴展閱讀：

在計算機的世界，這就是大家耳熟能詳的負載均衡（load balancing），所謂負載均衡，就是說如果一組計算機節點（或者一組進程）提供相同的（同質的）服務，那麼對服務的請求就應該均勻的分攤到這些節點上。

負載均衡的意義在於，讓所有節點以最小的代價、最好的狀態對外提供服務，這樣系統吞吐量最大，性能更高，對於用戶而言請求的時間也更小。而且，負載均衡增強了系統的可靠性，最大化降低了單個節點過載、甚至crash的概率。不難想像，如果一個系統絕大部分請求都落在同一個節點上，那麼這些請求響應時間都很慢，而且萬一節點降級或者崩潰，那麼所有請求又會轉移到下一個節點，造成雪崩。

『肆』 負載均衡權重輪詢演算法中的權重有什麼作用

不理解你說的權重是什麼，優先順序還是比率？
如果你有兩台伺服器，伺服器A和伺服器B
優先順序：伺服器A優先順序100，伺服器B優先順序50
流量全部分發到伺服器A上面，只有伺服器A掛掉才會分到B上面，類似於主備。
比率：伺服器A為3，服務B為1
如果一共有12個連接，伺服器A會分發到3+3+3 伺服器B會分發到1+1+1
也就是每4個連接中會有3個分發到伺服器A，剩下的1個分發到伺服器B。

『伍』 負載均衡基本介紹

【負載均衡架構部分轉自】 58沈劍 [架構師之路]( https://mp.weixin.qq.com/s

負載均衡： 是分布式系統架構設計中必須考慮的因素之一，它通常是指，將請求/數據【均勻】分攤到多個操作單元上執行，負載均衡的關鍵在於【均勻】
常見的負載均衡方案：

【客戶端層】到【反向代理層】的負載均衡，是通過「DNS輪詢」實現的：DNS-server對於一個域名配置了多個解析ip，每次DNS解析請求來訪問DNS-server，會輪詢返回這些ip，保證每個ip的解析概率是相同的。這些ip就是nginx的外網ip，以做到每台nginx的請求分配也是均衡的。

【反向代理層】到【站點層】的負載均衡，是通過「nginx」實現的。通過修改nginx.conf，可以實現多種負載均衡策略：

【站點層】到【服務層】的負載均衡，是通過「服務連接池」實現的。
上游連接池會建立與下游服務多個連接，每次請求會「隨機」選取連接來訪問下游服務。（也即是rpc框架實現的）

在數據量很大的情況下，由於數據層（db，cache）涉及數據的水平切分，所以數據層的負載均衡更為復雜一些，它分為「數據的均衡」，與「請求的均衡」。
數據的均衡是指 ：水平切分後的每個服務（db，cache），數據量是差不多的。
請求的均衡是指 ：水平切分後的每個服務（db，cache），請求量是差不多的。
（1）按照range水平切分

（2）按照id哈希水平切分

[圖片上傳中...(-6b2508-1561902875888-0)]

常見的負載均衡系統包括 3 種：DNS 負載均衡、硬體負載均衡和軟體負載均衡。

硬體負載均衡是通過單獨的硬體設備來實現負載均衡功能，這類設備和路由器、交換機類似，可以理解為一個用於負載均衡的基礎網路設備。比如業界非常出名的F5

缺點：
（1）價格實在非常昂貴
（2）擴展性不強

軟體負載均衡通過負載均衡軟體來實現負載均衡功能，常見的有 Nginx 和 LVS。

nginx和F5： https://blog.csdn.net/chabale/article/details/8956717
nginx和lvs比較： https://blog.51cto.com/hzcto/2086691
lvs： https://www.cnblogs.com/liwei0526vip/p/6370103.html
ELB： https://aws.amazon.com/cn/elasticloadbalancing/
SLB： https://help.aliyun.com/proct/27537.html

題目：日活躍用戶 1000 萬的論壇的負載均衡集群，該如何設計呢？
（1）評估流量
1000萬DAU，換算成秒級（一天12小時），平均約等於232。
考慮每個用戶操作次數，假定10，換算成平均QPS=2320。
考慮峰值是均值倍數，假定5，換算成峰值QPS=11600。
考慮靜態資源、圖片資源、服務拆分等，流量放大效應，假定10，QPS 10=116000。
（2）容量規劃
考慮高可用、異地多活，QPS 2=232000。
考慮未來半年增長，QPS*1.5=348000。
（3）方案設計
可以用三級導流：
第一級，DNS，確定機房，以目前量級，可以不考慮。
第二級，確定集群，擴展優先，則選Haproxy/LVS，穩定優先則選F5。
第三級，Nginx+KeepAlived，確定實例。
（4）架構圖

接入層技術：

缺點：

優點：

缺點：

優點：

缺點：

缺點：

nginx畢竟是軟體，性能比tomcat好，但總有個上限，超出了上限，還是扛不住。lvs就不一樣了，它實施在操作系統層面；f5的性能又更好了，它實施在硬體層面；它們性能比nginx好很多，例如每秒可以抗10w，這樣可以利用他們來擴容。

99.9999%的公司到這一步基本就能解決接入層高可用、擴展性、負載均衡的問題。 假設還扛不住的話，就要考慮使用硬體設備f5等。如果還是扛不住，那麼只有DNS來擴容了。

水平擴展，才是解決性能問題的根本方案，能夠通過加機器擴充性能的方案才具備最好的擴展性。 facebook，google，的PV是不是超過80億呢，它們的域名只對應一個ip么，終點又是起點，還是得通過DNS輪詢來進行擴容：

比如購買了阿里雲或者aws。那麼基本會使用雲廠商提供的負載均衡中間件，比如aws（elb）、阿里雲（slb）。這個負載均衡軟體可以認為是 lvs+keepalived的高可用負載均衡服務

後端的service有可能部署在硬體條件不同的伺服器上：
1）如果對標最低配的伺服器「均勻」分攤負載，高配的伺服器的利用率不足；
2）如果對標最高配的伺服器「均勻」分攤負載，低配的伺服器可能會扛不住；

（1）通過「靜態權重」標識service的處理能力

優點： 簡單，能夠快速的實現異構伺服器的負載均衡。
缺點： 權重是固定的，無法自適應動態調整，而很多時候，伺服器的處理能力是很難用一個固定的數值量化。

（2）通過「動態權重」標識service的處理能力
提問：通過什麼來標識一個service的處理能力呢？
回答：其實一個service能不能處理得過來，能不能響應得過來，應該由調用方說了算。調用服務，快速處理了，處理能力跟得上；調用服務，處理超時了，處理能力很有可能跟不上了。

動態權重設計：

例如：

（1）設置一個閾值，超過閾值直接丟棄

（2）藉助「動態權重」來實施過載保護
案例策略：

1）service的負載均衡、故障轉移、超時處理通常是RPC-client連接池層面來實施的
2）異構伺服器負載均衡，最簡單的方式是靜態權重法，缺點是無法自適應動態調整
3）動態權重法，可以動態的根據service的處理能力來分配負載，需要有連接池層面的微小改動
4）過載保護，是在負載過高時，service為了保護自己，保證一定處理能力的一種自救方法
5）動態權重法，還可以用做service的過載保護

『陸』 負載均衡詳解 - 玩轉Kong網關

KONG為請求多個後端服務提供了多種負載均衡方案：一種是簡單的基於DNS，另一種是更加動態的環形均衡器，他在不需要DNS伺服器的情況下也允許服務注冊。

當使用基於DNS的負載平衡時，後端服務的注冊是在Kong之外完成，而Kong只接收來自DNS伺服器的更新。如果請求的API被解析為多個IP地址，則已使用包含主機名（而不是IP地址）的upstream_url定義的每個API將自動使用基於DNS的負載平衡，前提是主機名未被解析為upstream名稱或你的localhosts文件中的名稱。DNS記錄ttl設置（生存時間）確定刷新信息的頻率。當設置ttl為0時，每個請求將使用自己的dns查詢進行解析。顯然這會帶來性能損失，但更新/更改的延遲將非常低。

A記錄包含一個或多個IP地址。因此，當主機名解析為A記錄時，每個後端服務都必須有自己的IP地址。因為沒有 weight 信息，所有條目在負載平衡器中將被視為同樣的權重，平衡器將進行直線循環。來自DNS記錄的IP地址的初始選擇是隨機的。這是為了確保即使當ttl為0時，負載也正確分配。

SRV記錄包含所有IP地址的權重和埠信息。可以通過唯一的IP埠號的組合來標識後端服務。因此，單個IP地址可以託管不同埠上相同服務的多個實例。因為權重信息可用，每個條目將在負載平衡器中獲得自己的權重，並且它將執行加權循環。

類似地，任何給定的埠信息將被來自DNS伺服器的埠信息覆蓋。如果一個API的 upstream_url= http://myhost.com:1234/path 並且 myhost.com 被解析為 SRV 記錄中的 127.0.0.1:5678，此時的API將會被代理到 http://127.0.0.1:5678/path ，之前的 1234 埠會被重寫為 5678 埠。IP地址+埠組合在初始時是隨機選擇的，這是為了確保服務能被正確分配，即使ttl設置為0。

tip：每當刷新DNS記錄時，都會生成列表以正確處理加權。建議將權重保持為彼此的倍數以保證系統的性能。

DNS解析器按順序開始解析以下記錄類型：

1. 最後一個成功的類型優先解析；

2. SRV記錄

3. A記錄

4. CNAME記錄

所以，如果你使用的主機名稱中同時含有SRV記錄和A記錄時，將僅解析SRV實例。如果你想使用A記錄，那麼你必須得把SRV記錄從DNS中刪除。如果你只有A記錄，則SRV記錄查詢失敗，然後自動指向到A記錄，並查詢A記錄是否存在，依次類推。

使用環形平衡器時，後台服務的添加和刪除將由Kong處理，不需要進行DNS更新。KONG將扮演服務注冊的角色。可以通過單個HTTP請求添加/刪除節點，並可立即啟動/停止接收請求流量。

可以通過配置 upstream 和 target 屬性來配置環形均衡器。

默認情況下，一個環平衡器將使用一個加權循環的方案。另一種方法是使用基於散列的演算法。散列的輸入可以是 none , consumer , ip , 或者 header 。當設置為none時，將使用加權循環方案，並且將禁用哈希。

有兩種選擇，一種主要的和一種備用方案，以防主伺服器出現故障（例如，如果主伺服器被設置為 consumer ，但是沒有經過身份驗證）

不同的散列選項:

哈希演算法是基於「一致性哈希」，它確保當平衡器通過改變目標（添加、移除、失敗或改變權重）來修改時，只有最小的散列損失發生。這將最大優化上游緩存的命中。

一堆原理實在不好理解，下面來幾個案例研究下：

這是一個安全部署應用的方法，它通過提供兩個版本的應用同時運行。為了部署一個新版本的應用，你需要將當前版本切換到新版本，然後關閉老版本。Blue-green deployment不會使應用停止服務，在必要的情況下允許你快速回滾應用到blue版本。

設置「藍色」環境，運行版本1的地址服務：

將主機頭設置為 address.mydomain.com ，就可以讓那Kong代理這個請求轉發到定義的兩個目標；三分之二的請求將發送到 http://192.168.34.15:80/address （權重=100），1/3將轉到 http://192.168.34.16:80/address （權重=50）。

設置「綠色」環境，運行版本2的地址服務：

將主機頭設置為 address.mydomain.com ，現在已經給Kong設置了一個新的目標；一半的請求將被發送到 http://192.168.34.17:80/address （權重=100），另外1/2將轉到 http://192.168.34.18:80/address （權重=100）。

通常，通過Kong管理API的更改是動態的，並將立即生效。不需要重新載入或重啟，在進度請求中不需要刪除。

使用環型平衡器，目標權重可以精確地調整，允許一個平滑的、可控的金絲雀環境。

使用一個非常簡單的2個目標示例：

通過重復請求，但是每次改變權重，流量將慢慢地路由到另一個目標。例如，將其設置為10%：

同樣，通過Kong管理API的更改是動態的，並將立即生效。不需要重新載入或重啟，在進度請求中不需要刪除。

『柒』 slb負載均衡 是 nginx 嗎

不是。

SLB，伺服器負載均衡（Server Load Balancing），可以看作HSRP（熱備份路由器協議）的擴展，實現多個伺服器之間的負載均衡。

Nginx(engine x) 為一個高性能的HTTP和反向代理web伺服器，同時也提供了IMAP/POP3/SMTP服務。Nginx由伊戈爾·賽索耶夫為俄羅斯訪問量第二的Rambler.ru站點（俄文：Рамблер）開發的，第一個公開版本0.1.0發布於2004年10月4日。

(7)加權負載均衡演算法擴展閱讀

負載均衡演算法有兩種：

Weighted round robin(WRR)和Weighted least connections(WLC)，WRR使用加權輪詢演算法分配連接，WLC通過一定的權值，將下一個連接分配給活動連接數少的伺服器。

配置分為兩部分，第一部分使用slb serverfarm serverfarm_name命令定義SLB選項，包括指定真實伺服器地址；第二部分使用ip slb vserver virtual_server-name來指定虛擬伺服器地址。

Nginx可以在大多數UnixLinux OS上編譯運行，並有Windows移植版。Nginx的1.4.0穩定版於2013年4月24日發布，一般情況下，對於新建站點，使用最新穩定版作為生產版本，已有站點的升級急迫性不高。

Nginx的源代碼使用 2-clause BSD-like license。Nginx為一個很強大的高性能Web和反向代理服務，它具有很多非常優越的特性：

在連接高並發的情況下，Nginx為Apache的替代品：Nginx在美國為做虛擬主機生意的老闆們經常選擇的軟體平台之一。能夠支持高達50000個並發連接數的響應。

『捌』 伺服器集群的負載均衡演算法有哪些

輪轉(Round-Robin)演算法
加權輪轉(Weighted Round Robin)演算法
最小連接數（Least Connections）演算法
加權最小連接數（Weighted Least Connections）演算法
目的地址哈希散列（Destination Hashing Scheling）演算法
源地址哈希散列（Source Hashing Scheling）演算法
隨機（Random）演算法