<b>摘要：</b>在由雲栖社群和阿裡雲網絡團隊聯合主辦的2017阿裡雲網絡技術線上高峰論壇上，阿裡雲技術專家添毅分享了網絡産品部根據客戶和阿裡雲運維的回報提煉出的幾大最主要和最常見的在使用SLB産品中發生的問題，并為大家介紹了針對這些常見問題的相應處理方法。想知道如何借助SLB建構高可用系統以及健康檢查是如何實作的，本文不容錯過！
<b>本文内容根據演講嘉賓分享視訊以及PPT整理而成。</b>
本次的分享将會主要圍繞以下5個部分
基本概念回顧
如何建構高可用系統
選擇性能共享型還是性能保障型執行個體
為什麼健康檢查異常
為什麼負載不均衡
<b>一、基本概念回顧</b>
<b></b>
SLB是什麼
SLB是阿裡雲推出的一款雲負載均衡服務，其主要針對于多台雲伺服器進行流量分發，能夠将業務流量分發到由多台雲伺服器所組成的後端伺服器池上去，以此來提升系統的處理能力。負載均衡所解決的問題主要包括兩點：第一點，SLB能夠消除系統的單點故障，這是因為SLB的後面是由多台雲伺服器組成的伺服器池，那麼當其中某一台伺服器出現故障的時候并不會影響整個系統的可服務性。第二點，由于後端的雲伺服器能夠橫向地進行擴充，是以也具有為海量業務提供服務的能力。那麼，為什麼要使用雲上的負載均衡呢？這是因為雲上負載均衡主要有這樣的幾個特點：高可靠、高性能、低成本、安全性、易用性。
<b>SLB基本元件</b>
阿裡雲的SLB主要包括了三個基本元件，這裡也進行簡單地介紹。第一個基本元件就是執行個體，每個執行個體都唯一地辨別了雲負載均衡器，并且每個執行個體都對應一個VIP，VIP唯一地辨別了負載均衡執行個體，也是負載均衡對外提供服務的位址。第二個元件是監聽，監聽是由VIP+端口号來唯一辨別的，一個監聽中包含使用者定制的負載均衡政策和轉發規則。最後一個基本元件就是後端挂載的伺服器，也就是雲伺服器ECS，負責處理真正的業務請求。
<b>二、如何建構高可用系統</b>
<b>多層次的高可用</b>
如下圖所示，阿裡雲的負載均衡是從四個層面上去建構高可用的。從底層往上層看，分别是應用級别的高可用、叢集級别的高可用、可用區級别(AZ)的高可用以及地域級别(Region)的高可用。
應用級别的高可用主要是通過針對SLB後端的ECS執行個體的健康檢查來實作的。當SLB發現後端不健康的或者不能正常工作的ECS的時候，會将這些不健康的ECS從SLB的轉發路徑中剔除掉，保證業務流量能夠轉發到正常的工作伺服器當中。叢集級别的高可用主要是通過叢集中LVS機器間的session同步來保障任何一個使用者的業務會話都能夠在所有的LVS機器上是互相同步的，當其中某一台LVS出現故障時，可以由其他的LVS來接替出現故障的機器的工作。同時，由于會話保持的存在，使用者的業務是不會發生中斷的。對于可用區級别的高可用和地域級别的高可用，在本文的後面會進行更加詳細的介紹。
<b>細說可用區級别容災</b>
這裡詳細地介紹一下可用區級别的容災。可用區級别容災的設計初衷是在當一個可用區出現重大災情的時候，比如整個可用區的機房發生了掉電、光纜出現了中斷、整個可用區機房中所有的實體機都無法正常工作的時候，也就是整個可用區都宕掉了的情況下，能夠由備可用區來繼續提供服務，這就是可用區級别容災的設計初衷。可用區級别的容災并不是說某一個可用區中的某一個執行個體或者是某幾個執行個體出現了故障就會發生可用區的切換，執行個體自動從可用區A切換到可用區B，這是一個比較常見的誤區。而針對于這樣的誤區，阿裡雲也建議使用者在建構可用區級别的高可用的時候采取以下兩個步驟：
首先，建議使用者在SLB執行個體的後端盡可能地去挂載多個可用區的ECS執行個體。SLB能夠支援跨可用區地挂載ECS雲伺服器，這樣可以避免某個可用區的ECS都出現故障的情況下，還有其他可用區的ECS能夠接替工作，雖然跨可用區挂在ECS會存在大約2毫秒左右的延遲，但是卻能夠大大地提升服務的可用性。
第二步就是針對于一些特别重要的業務，建議在不同的可用區分别地去購買SLB的執行個體。比如在可用區A和可用區B各自購買一個SLB執行個體，在此基礎之上再使用全球負載均衡GSLB來進行執行個體間的排程。
<b>跨地域容災的實作</b>
跨地域容災這一部分與上面介紹的可用區級别容災的第二步非常相似，也是借助于GSLB産品實作的，GSLB即 智能DNS實作了針對于後端的健康檢查、路由排程的優化功能，能夠實作在地域之間的負載均衡執行個體的排程。關于這部分的更詳細的内容請參考：全球負載均衡跨地域容災解決方案(https://promotion.aliyun.com/ntms/act/globalslb.html)。
<b>三、選擇性能共享型還是性能保障型執行個體</b>
<b>共享型vs保障型-WHY保障型</b>
在如今這個共享經濟的時代，像滴滴打車這樣的模式是非常火的。但是即便是有了滴滴打車，但是還有人會去買車，這是因為會出現如下兩個大家可能曾經都碰到過的場景：
早晚高峰叫不到車？雨雪天氣路邊凍成狗？還大幅提價？
假期想遠離塵嚣，找個僻靜曠野放空自我，叫個滴滴？也許有去，但保證無回！
是以說共享和保障都是客戶的需求。出于對于類似需求的考慮，阿裡雲的負載均衡也推出了性能保障型執行個體。以前所推出的SLB共享型執行個體是因為性能名額沒有辦法實作隔離，因為所有的共享型執行個體都處于同一個大共享資源池中，是以在高峰期的時候就會出現資源的争搶，這樣就無法滿足對于性能具有剛性需求的大客戶的訴求。除此之外，還有一些體量特别大的超級使用者，他們對于性能的要求會是非常高的，但是由于共享型執行個體無法做到性能隔離，也支援不了大顆粒度的性能名額，是以也無法完成這樣的工作。是以，阿裡雲推出了性能保障型的負載均衡執行個體。
<b>超強性能</b>
保障型執行個體的性能規格如上圖所示，其并發連接配接數最大可以達到500萬，每秒的建立連結數(CPS)可以達到50萬，針對于七層負載均衡系統的QPS可以達到10萬。除此之外，性能保障型執行個體還具有以下的特點：
<b>超強HTTPS性能。</b>性能保障型執行個體針對于七層系統，特别是HTTPS的業務進行了優化，實作了高性能硬加解卡，并且能夠實作使HTTPS的業務單執行個體可達10萬QPS。
<b>超大并發連接配接數。</b>性能保障型執行個體的單執行個體的并發連接配接數可達500萬，是以其可承載物聯網場景的下海量連接配接，可以支撐共享自行車、智能手表等存在特别大量長連接配接的場景。
<b>共享型執行個體平滑更新。</b>原有的共享型執行個體可以平滑更新至性能保障型執行個體，而無需更換VIP。
<b>完善的業務監控系統。</b>在推出性能保障型執行個體之後，因為每個執行個體都有相應的性能規格和性能名額，是以阿裡雲也為使用者提供了完整的業務名額監控系統，并支援電話、短信、釘釘企業群等方式的告警。
<b>性能規格</b>
上圖所展現的是阿裡雲SLB性能保障型執行個體的規格參數。圖中的最後兩行規格7、8預設在控制台上是無法購買的，目前隻針對企業級使用者，而且需通過客戶經理申請後，通過白名單開放。
<b>如何選擇規格</b>
對于保障型執行個體而言，主要有如下幾個性能名額：
最大連接配接數：一個執行個體可承載的最大連接配接數。
建立連接配接數：CPS表示一個執行個體每秒可以建立的連結數。
每秒查詢數：QPS表示一個執行個體7層的像HTTP或者HTTPS系統的吞吐量。
通常一個4層SLB的性能好壞由最大連接配接數和建立連接配接數來衡量，它們表示了一個SLB系統的并發能力和處理突發連接配接的能力。通常一個7層SLB的性能好壞主要由QPS決定，QPS表示了一個7層系統的吞吐量。這裡需要注意的是QPS是7層獨有概念。雖然每個規格都定義了三個性能名額，但是這并不代表這三個性能名額在任何一個性能場景下或者任何一個時刻都能夠同時達到最大值，這裡存在一個性能名額的短木闆原則。比如在某一個應用系統中，QPS已經達到名額上限，但最大連接配接數還遠遠沒有達到上限，這時不論怎樣加大用戶端數量，最大連接配接數都會因為QPS達到上限，而無法達到最大值。
對于規格的選擇而言，需要通過之前提到的業務監控系統來擷取相關名額。如果使用者十分了解自己業務的相關名額，也就是對于高峰期的并發連接配接數會達到多少以及QPS會達到多少都有非常清晰的了解，也可以直接在控制台上選購。但是如果使用者并不清楚自己的相關業務名額，可以在初期選購按量付費的較高規格的執行個體，并且在一個業務周期内監控流量的峰值，在峰值确定好之後再通過變配的方式改變到比較合适的執行個體規格。目前性能保障型執行個體還處于公測階段，是以現在還沒有對于執行個體收取規格費用，也就是說在這個階段無論使用者選擇最小規格還是最大規格，實際上都隻需要花費IP配置費和帶寬費就可以了，這樣也比較便于使用者去熟悉和使用阿裡雲的性能保障型執行個體。
<b>監控和告警</b>
前面也有所提及，在負載均衡的控制台上面能夠直接地顯示出相應的一些性能名額，但是在這裡隻能夠實作對于性能名額的監控，卻無法進行告警。如果使用者需要進行監控告警，可以在阿裡雲所提供的雲監控控制台進行操作。雲監控平台可以監控阿裡雲中的所有産品并且實作業務告警的定制，并且可以選擇包括短信郵件、電話、企業釘釘群等方式進行業務的實時告警。
<b>四、為什麼健康檢查異常</b>
<b>健康檢查機制</b>
接下來分享在負載均衡的日常使用中出現的問題，特别是很多使用者都存在疑問的健康檢查部分的問題。
阿裡雲的負載均衡一共可以支援四種協定，四層的負載均衡系統主要包括了TCP、HTTP以及UDP協定，而七層的系統則包括了HTTP和HTTPS，而由于目前HTTP和HTTPS都是使用的普通的HTTP方式，是以其實也可以歸結為三類協定。對于TCP而言，健康檢查的過程是通過發送ACK這種TCP的探測封包去探測端口是否仍然存活；對于HTTP而言，則主要使用的是HEAD的請求方式來檢查目标的頁面是否正常；UDP部分則主要借鑒了SMP協定的原理。
健康檢查部分主要會涉及到幾個名額，這些名額需要使用者在控制台上進行設定，上圖中給出了一些預設的建議值，比如響應的逾時時間，也就是在每一次進行健康檢查的時候，如果超過一定時間健康檢查還沒有回應就認為這次的健康檢查是失敗的；還有健康檢查間隔，也就是兩次健康檢查之間通常需要間隔2秒鐘；而所謂的不健康閥值和健康閥值就是在網絡環境中往往會由于網絡的抖動以及其他的因素導緻偶爾的一次健康檢查失敗了，但是這時候并不能認為服務是真的失敗了，是以需要設定一個閥值，比如3次就指的是當3次健康檢查都失敗的時候才會認為後端的服務是存在問題的，然後将其從轉發路徑中摘除掉。同樣的，當服務從不健康變為健康的時候，也需要進行連續的幾次探測，當确定處于穩定的健康狀态之後再将其加入到SLB的後端中去。
<b>為啥會失敗(TCP)</b>
TCP的健康檢查也經常會出現一些失敗的情況，這裡也為大家提供了簡單的故障排查順序供參考。當出現健康檢查失敗的時候，首先可以檢查一下後端的伺服器是否已經啟動。如果後端伺服器的負載是比較高的，也可能會因為沒有CPU時間去處理健檢查的回應，這樣就有可能導緻健康檢查失敗。除此之外，因為對于阿裡雲的負載均衡而言，健康檢查使用的都是私網位址實作的，是以如果根本沒有監聽到私網位址或者私網位址本身存在故障也會導緻健康檢查的失敗。還有伺服器上可能存在防火牆，将監聽端口屏蔽掉了，導緻健康檢查并未通過。此外還可能存在一些配置方面的問題，比如提供服務的端口和做健康檢查的端口不一緻也可能存在健康檢查失敗。
針對于TCP的健康檢查而言，很多使用者會經常看到自己的後端伺服器上日志上面有很多10或者16這些網段的通路，并且通路流量還比較大，這是因為之前所提到的健康檢查具有一定的間隔時間，比如2秒或者3秒一次。這時候一些使用者可能就會認為健康檢查會影響伺服器的性能，占了很多的伺服器的連接配接數。其實可以從上圖中左側的封包互動情況看到，當SLB對于雲伺服器發起健康檢查的時候首先會發一個SYN的請求，如果伺服器端口是存活的，那麼它會回應一個ACK，這個時候SLB端就會緊接着發送RST封包。也就是說實際上連接配接是并沒有建立的，是以也不會占用後端伺服器的連接配接數的資源，并且對于性能的影響也是極為有限的。
<b>為啥會失敗(HTTP)</b>
HTTP常見的健康檢查失敗原因大概會有這樣的三點：最常見的情況就是有些使用者把伺服器的HEAD請求方式禁掉了，因為預設在使用浏覽器或者手機等請求一個頁面的時候使用的都是GET方式，有時候可能需要上傳資料則會使用POST方式，雖然很多伺服器都支援HEAD請求方式，但是有些伺服器可能會處于安全或者其他複雜因素的考慮将HEAD請求禁掉。是以在這裡建議客戶将伺服器的HEAD請求方式打開，因為阿裡雲負載均衡七層健康檢查方案就是使用的HEAD方案。另外一種常見情況就是頁面通路本身上就存在問題，這樣的情況下健康檢查也是無法通過的。最後一種常見情況就是期望結果配置錯誤，針對于七層的健康檢查是通過使用HEAD請求方式去請求頁面，頁面傳回碼可能會是200、300或者400以及500等，使用者可以在健康檢查的配置中設定預期的正常情況下的傳回碼值，當健康檢查傳回碼值與預期值不一緻就會判定健康檢查是失敗的。
<b>為啥會失敗(UDP)</b>
這裡介紹一下UDP健康檢查的原理。首先，健康檢查通過SLB向後端發送UDP封包探測來擷取狀态資訊。SLB會周期性地給後端ECS發送UDP封包，如果UDP端口的業務處于正常情況，則沒有任何回應。而當服務出現問題，比如指定的UDP服務端口處于不可達的情況或者無服務的狀态的時候，會回複ICMP的不可達封包。這裡也會存在一個問題就是如果後端伺服器已經變成了網絡中的孤島，比如出現了整個伺服器的掉電、關機情況這樣完全不能工作的狀态，這時候的ICMP不可達封包是永遠不可能收到的，因為後端的伺服器無法收到SLB發來的UDP探測封包，那麼在這種情況下，可能會出現誤認為後端健康的情況，但是實際上這個服務可能已經宕掉了。為了應對這種情況，健康檢查還提供使用者自定義UDP應答封包來實作精确的UDP健康檢查，也就是由使用者自定義指定一個字元串，當後端的雲伺服器收到UDP健康檢查的探測的時候，也回應指定的字元串，之後SLB對于這個字元串進行對比和校驗，如果比對成功則認為服務一定是健康的，這樣就可以實作非常精确的健康檢查。
而UDP的健康檢查失敗也有很多原因，比如在協定棧裡面有可能會有ICMP限速保護。當頻率達到一定速率的時候，ICMP會被協定棧限制，後端無法回應ICMP不可達封包，進而導緻SLB收不到ICMP的封包，出現健康檢查的失敗情況。是以這部分是需要注意的，如果可能盡量将速率限制放大一些。
<b>其他問題</b>
健康檢查時好時壞的可能原因如下：
HTTP類型健康檢查目标URI響應慢。比如本身是動态頁面，會涉及到大量的計算才能夠渲染完成并傳回到前端，這樣肯定就會導緻健康檢查響應比較慢。如果伺服器負載過高同樣也會出現這樣的問題。
未全部放開對SLB健康檢查源位址的限制導緻分布式健康檢查失敗。因為阿裡雲的伺服器都是分布式的部署，健康檢查也會是分布式的探測，LVS等機器在後端有不同的源去針對某一個雲伺服器進行探測的，是以如果沒有将這些源位址都放開，實際上也會影響健康檢查的效率，因為對于這麼多機器而言，隻要有一台機器檢測到是正常的那麼就是正常的。
還可能出現直接通路正常，但是健康檢查失敗的情況。造成這樣情況的可能原因如下：
防火牆限制。
目的端口不一緻。
檢查方法不同，可能使用浏覽器看頁面是沒問題的，但是健康檢查卻不行，這就是因為剛才所提到的HEAD方法沒有開啟。或者七層的健康檢查配置了URL按照域名轉發，但是在浏覽器上直接通路則是使用域名去做的，而健康檢查是使用IP位址做的，這樣也可能出現轉發和預期結果的不同。
檢查頻率不同，ICMP限速。
<b>五、為什麼負載不均衡</b>
<b>排程算法與會話保持</b>
首先介紹一下負載均衡的排程算法。阿裡雲的負載均衡支援三種算法，第一種算法是單純的輪詢(RR)，也就是将業務的請求依次地分發到後端的伺服器。第二種算法是權重輪詢(WRR)，也就是在處理排程的時候會根據針對于每一台後端伺服器設定權重來進行轉發。這裡之是以設定權重是因為後端伺服器的處理能力可能是不同的，如果使用相同的權重進行輪詢可能就會把後端處理能力比較弱的伺服器擠爆，是以需要針對于伺服器的處理能力設定一些權重。第三種算法是針對于權重最小連接配接數的輪詢(WLC)，也就是除了根據每台後端伺服器設定的權重值來進行輪詢，同時還考慮後端伺服器的實際負載，也就是連接配接數。當權重值相同時，目前連接配接數越小的後端伺服器被輪詢到的次數也越高，這樣就能夠保證負載盡量地均衡。如果不考慮這一點就會造成某些伺服器連接配接數已經很高了但是流量依然還往上面分發，而另外一些伺服器卻一直處于空閑狀态。
會話保持指的是來自同一使用者請求始終保持分發到同一台後端的雲伺服器上。對于同一使用者而言，使用的是四層的負載均衡和使用七層的負載均衡在了解上是不一樣的。如果是四層負載均衡，則會使用源IP位址辨別同一使用者，是以如果在可能會有很多辦公電腦的大型企業中，這些電腦在企業内部是通過區域網路的IP進行通信的，在通路公網的時候都是通過NAT網關處理的，是以在走到Internet的時候，源位址通常會是一個或者很有限的幾個。在這種情況下，如果是四層的負載均衡就會把裡面所有的請求都視為來自同一個使用者的，這種情況下如果開啟了會話保持，就會發生問題。而七層的負載均衡是根據使用者浏覽器中的Cookie來進行唯一識别的，對于剛才的案例在大型企業裡面因為内網通路公網的源位址都是一樣的，導緻沒有辦法識别到底是不是同一個使用者，此時建議使用七層的負載均衡方案解決，因為Cookie是每個浏覽器都唯一的。會話的保持時間是可以在控制台上配置的，四層的負載均衡方案最大可達1小時，而七層的方案最大可達24小時。
<b>為何不均衡</b>
最後分享一下不均衡的常見情況。有時候會需要新加一個伺服器進來，這時候往往到新加進來的伺服器上的連接配接會很少，這是因為可能會存在以下原因：
存在會話保持的情況下，會話保持會讓請求停留在原有的伺服器上，這樣到新加進來的伺服器上的連接配接自然會少一些。
權重設定不一緻，如果在權重的設定上存在差別，而新加進來的伺服器的權重如果很低，連接配接也過不去。
應用屬于長連接配接類型，因為需要在TCP上複用，如果用戶端不主動斷開連接配接，後續所有的請求都會繼續複用目前伺服器上的連接配接，隻有建立連接配接才有可能到新的伺服器上。
而有時候在業務量或者建立連接配接較少時，也會出現負載不均衡的問題。這是因為每個Core都是獨立的排程單元，是以可能存在将某個Client的多條業務經過不同core的排程後全部轉發到一台ECS上的情況，同時由于業務量較少，是以出現了不均衡。建議使用輪詢算法解決，在RR輪詢算法中加入了擾亂因子，可以更加有效的打散SLB到後端的轉發路徑。
<b>更多詳細的技術問題分享可以參考以下文章：</b>