摘要：在由云棲社區(qū)和阿里云網(wǎng)絡團隊聯(lián)合主辦的2017阿里云網(wǎng)絡技術(shù)在線高峰論壇上，阿里云技術(shù)專家添毅分享了網(wǎng)絡產(chǎn)品部根據(jù)客戶和阿里云運維的反饋提煉出的幾大最主要和最常見的在使用SLB產(chǎn)品中發(fā)生的問題濒持，并為大家介紹了針對這些常見問題的相應處理方法昙篙。
摘要：在由云棲社區(qū)和阿里云網(wǎng)絡團隊聯(lián)合主辦的2017阿里云網(wǎng)絡技術(shù)在線高峰論壇上腔召，阿里云技術(shù)專家添毅分享了網(wǎng)絡產(chǎn)品部根據(jù)客戶和阿里云運維的反饋提煉出的幾大最主要和最常見的在使用SLB產(chǎn)品中發(fā)生的問題锌半，并為大家介紹了針對這些常見問題的相應處理方法俗慈。想知道如何借助SLB構(gòu)建高可用系統(tǒng)以及健康檢查是如何實現(xiàn)的姑宽，本文不容錯過！
本文內(nèi)容根據(jù)演講嘉賓分享視頻以及PPT整理而成闺阱。
本次的分享將會主要圍繞以下5個部分
基本概念回顧
如何構(gòu)建高可用系統(tǒng)
選擇性能共享型還是性能保障型實例
為什么健康檢查異常
為什么負載不均衡
一炮车、基本概念回顧
SLB是什么
SLB是阿里云推出的一款云負載均衡服務，其主要針對于多臺云服務器進行流量分發(fā)酣溃，能夠?qū)I(yè)務流量分發(fā)到由多臺云服務器所組成的后端服務器池上去瘦穆，以此來提升系統(tǒng)的處理能力。負載均衡所解決的問題主要包括兩點：第一點赊豌，SLB能夠消除系統(tǒng)的單點故障扛或，這是因為SLB的后面是由多臺云服務器組成的服務器池，那么當其中某一臺服務器出現(xiàn)故障的時候并不會影響整個系統(tǒng)的可服務性碘饼。第二點熙兔，由于后端的云服務器能夠橫向地進行擴展，所以也具有為海量業(yè)務提供服務的能力艾恼。那么住涉，為什么要使用云上的負載均衡呢？這是因為云上負載均衡主要有這樣的幾個特點：高可靠蒂萎、高性能秆吵、低成本、安全性五慈、易用性纳寂。
SLB基本組件
阿里云的SLB主要包括了三個基本組件，這里也進行簡單地介紹泻拦。第一個基本組件就是實例毙芜，每個實例都唯一地標識了云負載均衡器，并且每個實例都對應一個VIP，VIP唯一地標識了負載均衡實例压状，也是負載均衡對外提供服務的地址。第二個組件是監(jiān)聽榔至，監(jiān)聽是由VIP+端口號來唯一標識的隘冲，一個監(jiān)聽中包含用戶定制的負載均衡策略和轉(zhuǎn)發(fā)規(guī)則闹瞧。最后一個基本組件就是后端掛載的服務器，也就是云服務器ECS展辞，負責處理真正的業(yè)務請求奥邮。
二、如何構(gòu)建高可用系統(tǒng)
多層次的高可用
如下圖所示罗珍，阿里云的負載均衡是從四個層面上去構(gòu)建高可用的洽腺。從底層往上層看，分別是應用級別的高可用覆旱、集群級別的高可用蘸朋、可用區(qū)級別(AZ)的高可用以及地域級別(Region)的高可用。
應用級別的高可用主要是通過針對SLB后端的ECS實例的健康檢查來實現(xiàn)的扣唱。當SLB發(fā)現(xiàn)后端不健康的或者不能正常工作的ECS的時候藕坯，會將這些不健康的ECS從SLB的轉(zhuǎn)發(fā)路徑中剔除掉，保證業(yè)務流量能夠轉(zhuǎn)發(fā)到正常的工作服務器當中噪沙。集群級別的高可用主要是通過集群中LVS機器間的session同步來保障任何一個用戶的業(yè)務會話都能夠在所有的LVS機器上是相互同步的堕担，當其中某一臺LVS出現(xiàn)故障時，可以由其他的LVS來接替出現(xiàn)故障的機器的工作曲聂。同時霹购，由于會話保持的存在，用戶的業(yè)務是不會發(fā)生中斷的朋腋。對于可用區(qū)級別的高可用和地域級別的高可用齐疙，在本文的后面會進行更加詳細的介紹。
細說可用區(qū)級別容災
這里詳細地介紹一下可用區(qū)級別的容災旭咽≌攴埽可用區(qū)級別容災的設計初衷是在當一個可用區(qū)出現(xiàn)重大災情的時候，比如整個可用區(qū)的機房發(fā)生了掉電穷绵、光纜出現(xiàn)了中斷轿塔、整個可用區(qū)機房中所有的物理機都無法正常工作的時候，也就是整個可用區(qū)都宕掉了的情況下仲墨，能夠由備可用區(qū)來繼續(xù)提供服務勾缭，這就是可用區(qū)級別容災的設計初衷∧垦可用區(qū)級別的容災并不是說某一個可用區(qū)中的某一個實例或者是某幾個實例出現(xiàn)了故障就會發(fā)生可用區(qū)的切換俩由，實例自動從可用區(qū)A切換到可用區(qū)B，這是一個比較常見的誤區(qū)癌蚁。而針對于這樣的誤區(qū)幻梯，阿里云也建議用戶在構(gòu)建可用區(qū)級別的高可用的時候采取以下兩個步驟：
首先兜畸，建議用戶在SLB實例的后端盡可能地去掛載多個可用區(qū)的ECS實例。SLB能夠支持跨可用區(qū)地掛載ECS云服務器碘梢，這樣可以避免某個可用區(qū)的ECS都出現(xiàn)故障的情況下咬摇，還有其他可用區(qū)的ECS能夠接替工作，雖然跨可用區(qū)掛在ECS會存在大約2毫秒左右的延遲煞躬，但是卻能夠大大地提升服務的可用性菲嘴。
第二步就是針對于一些特別重要的業(yè)務，建議在不同的可用區(qū)分別地去購買SLB的實例汰翠。比如在可用區(qū)A和可用區(qū)B各自購買一個SLB實例，在此基礎之上再使用全球負載均衡GSLB來進行實例間的調(diào)度昭雌。
跨地域容災的實現(xiàn)
跨地域容災這一部分與上面介紹的可用區(qū)級別容災的第二步非常相似复唤，也是借助于GSLB產(chǎn)品實現(xiàn)的，GSLB即 智能DNS實現(xiàn)了針對于后端的健康檢查烛卧、路由調(diào)度的優(yōu)化功能佛纫，能夠?qū)崿F(xiàn)在地域之間的負載均衡實例的調(diào)度。關(guān)于這部分的更詳細的內(nèi)容請參考：全球負載均衡跨地域容災解決方案(https://promotion.aliyun.com/ntms/act/globalslb.html)总放。
三呈宇、選擇性能共享型還是性能保障型實例
共享型vs保障型-WHY保障型
在如今這個共享經(jīng)濟的時代，像滴滴打車這樣的模式是非尘中郏火的甥啄。但是即便是有了滴滴打車，但是還有人會去買車炬搭，這是因為會出現(xiàn)如下兩個大家可能曾經(jīng)都碰到過的場景：
早晚高峰叫不到車蜈漓？雨雪天氣路邊凍成狗？還大幅提價宫盔？
假期想遠離塵囂融虽，找個僻靜曠野放空自我，叫個滴滴灼芭？也許有去有额，但保證無回！
所以說共享和保障都是客戶的需求彼绷。出于對于類似需求的考慮巍佑，阿里云的負載均衡也推出了性能保障型實例。以前所推出的SLB共享型實例是因為性能指標沒有辦法實現(xiàn)隔離寄悯，因為所有的共享型實例都處于同一個大共享資源池中句狼，所以在高峰期的時候就會出現(xiàn)資源的爭搶，這樣就無法滿足對于性能具有剛性需求的大客戶的訴求热某。除此之外腻菇，還有一些體量特別大的超級用戶胳螟，他們對于性能的要求會是非常高的，但是由于共享型實例無法做到性能隔離筹吐，也支持不了大顆粒度的性能指標糖耸，所以也無法完成這樣的工作。因此丘薛，阿里云推出了性能保障型的負載均衡實例嘉竟。
超強性能
保障型實例的性能規(guī)格如上圖所示，其并發(fā)連接數(shù)最大可以達到500萬洋侨，每秒的新建鏈接數(shù)(CPS)可以達到50萬舍扰，針對于七層負載均衡系統(tǒng)的QPS可以達到10萬。除此之外希坚，性能保障型實例還具有以下的特點：
超強HTTPS性能边苹。性能保障型實例針對于七層系統(tǒng)，特別是HTTPS的業(yè)務進行了優(yōu)化裁僧，實現(xiàn)了高性能硬加解卡个束，并且能夠?qū)崿F(xiàn)使HTTPS的業(yè)務單實例可達10萬QPS。
超大并發(fā)連接數(shù)聊疲。性能保障型實例的單實例的并發(fā)連接數(shù)可達500萬茬底，所以其可承載物聯(lián)網(wǎng)場景的下海量連接，可以支撐共享自行車获洲、智能手表等存在特別大量長連接的場景阱表。
共享型實例平滑升級。原有的共享型實例可以平滑升級至性能保障型實例贡珊，而無需更換VIP捶枢。
完善的業(yè)務監(jiān)控系統(tǒng)。在推出性能保障型實例之后飞崖，因為每個實例都有相應的性能規(guī)格和性能指標烂叔，所以阿里云也為用戶提供了完整的業(yè)務指標監(jiān)控系統(tǒng)，并支持電話固歪、短信蒜鸡、釘釘企業(yè)群等方式的告警。
性能規(guī)格
上圖所展現(xiàn)的是阿里云SLB性能保障型實例的規(guī)格參數(shù)牢裳。圖中的最后兩行規(guī)格7逢防、8默認在控制臺上是無法購買的，目前只針對企業(yè)級用戶蒲讯，而且需通過客戶經(jīng)理申請后忘朝，通過白名單開放。
如何選擇規(guī)格
對于保障型實例而言判帮，主要有如下幾個性能指標：
最大連接數(shù)：一個實例可承載的最大連接數(shù)局嘁。
新建連接數(shù)：CPS表示一個實例每秒可以新建的鏈接數(shù)溉箕。
每秒查詢數(shù)：QPS表示一個實例7層的像HTTP或者HTTPS系統(tǒng)的吞吐量。
通常一個4層SLB的性能好壞由最大連接數(shù)和新建連接數(shù)來衡量悦昵，它們表示了一個SLB系統(tǒng)的并發(fā)能力和處理突發(fā)連接的能力肴茄。通常一個7層SLB的性能好壞主要由QPS決定，QPS表示了一個7層系統(tǒng)的吞吐量但指。這里需要注意的是QPS是7層獨有概念寡痰。雖然每個規(guī)格都定義了三個性能指標，但是這并不代表這三個性能指標在任何一個性能場景下或者任何一個時刻都能夠同時達到最大值棋凳，這里存在一個性能指標的短木板原則拦坠。比如在某一個應用系統(tǒng)中，QPS已經(jīng)達到指標上限剩岳，但最大連接數(shù)還遠遠沒有達到上限贞滨，這時不論怎樣加大客戶端數(shù)量，最大連接數(shù)都會因為QPS達到上限卢肃，而無法達到最大值。
對于規(guī)格的選擇而言才顿，需要通過之前提到的業(yè)務監(jiān)控系統(tǒng)來獲取相關(guān)指標莫湘。如果用戶十分了解自己業(yè)務的相關(guān)指標，也就是對于高峰期的并發(fā)連接數(shù)會達到多少以及QPS會達到多少都有非常清晰的了解郑气，也可以直接在控制臺上選購幅垮。但是如果用戶并不清楚自己的相關(guān)業(yè)務指標，可以在初期選購按量付費的較高規(guī)格的實例尾组，并且在一個業(yè)務周期內(nèi)監(jiān)控流量的峰值忙芒，在峰值確定好之后再通過變配的方式改變到比較合適的實例規(guī)格。目前性能保障型實例還處于公測階段讳侨，所以現(xiàn)在還沒有對于實例收取規(guī)格費用呵萨，也就是說在這個階段無論用戶選擇最小規(guī)格還是最大規(guī)格，實際上都只需要花費IP配置費和帶寬費就可以了跨跨，這樣也比較便于用戶去熟悉和使用阿里云的性能保障型實例潮峦。
監(jiān)控和告警
前面也有所提及，在負載均衡的控制臺上面能夠直接地顯示出相應的一些性能指標勇婴，但是在這里只能夠?qū)崿F(xiàn)對于性能指標的監(jiān)控忱嘹，卻無法進行告警。如果用戶需要進行監(jiān)控告警耕渴，可以在阿里云所提供的云監(jiān)控控制臺進行操作拘悦。云監(jiān)控平臺可以監(jiān)控阿里云中的所有產(chǎn)品并且實現(xiàn)業(yè)務告警的定制，并且可以選擇包括短信郵件橱脸、電話础米、企業(yè)釘釘群等方式進行業(yè)務的實時告警分苇。
四、為什么健康檢查異常
健康檢查機制
接下來分享在負載均衡的日常使用中出現(xiàn)的問題椭盏，特別是很多用戶都存在疑問的健康檢查部分的問題组砚。
阿里云的負載均衡一共可以支持四種協(xié)議，四層的負載均衡系統(tǒng)主要包括了TCP掏颊、HTTP以及UDP協(xié)議糟红，而七層的系統(tǒng)則包括了HTTP和HTTPS，而由于目前HTTP和HTTPS都是使用的普通的HTTP方式乌叶，所以其實也可以歸結(jié)為三類協(xié)議盆偿。對于TCP而言，健康檢查的過程是通過發(fā)送ACK這種TCP的探測報文去探測端口是否仍然存活准浴；對于HTTP而言事扭，則主要使用的是HEAD的請求方式來檢查目標的頁面是否正常；UDP部分則主要借鑒了SMP協(xié)議的原理乐横。
健康檢查部分主要會涉及到幾個指標求橄，這些指標需要用戶在控制臺上進行設置，上圖中給出了一些默認的建議值葡公，比如響應的超時時間罐农，也就是在每一次進行健康檢查的時候，如果超過一定時間健康檢查還沒有回應就認為這次的健康檢查是失敗的催什；還有健康檢查間隔涵亏，也就是兩次健康檢查之間通常需要間隔2秒鐘；而所謂的不健康閥值和健康閥值就是在網(wǎng)絡環(huán)境中往往會由于網(wǎng)絡的抖動以及其他的因素導致偶爾的一次健康檢查失敗了蒲凶，但是這時候并不能認為服務是真的失敗了气筋，所以需要設置一個閥值，比如3次就指的是當3次健康檢查都失敗的時候才會認為后端的服務是存在問題的旋圆，然后將其從轉(zhuǎn)發(fā)路徑中摘除掉宠默。同樣的，當服務從不健康變?yōu)榻】档臅r候灵巧，也需要進行連續(xù)的幾次探測光稼，當確定處于穩(wěn)定的健康狀態(tài)之后再將其加入到SLB的后端中去。
為啥會失敗(TCP)
TCP的健康檢查也經(jīng)常會出現(xiàn)一些失敗的情況孩等，這里也為大家提供了簡單的故障排查順序供參考艾君。當出現(xiàn)健康檢查失敗的時候，首先可以檢查一下后端的服務器是否已經(jīng)啟動肄方。如果后端服務器的負載是比較高的冰垄，也可能會因為沒有CPU時間去處理健檢查的回應，這樣就有可能導致健康檢查失敗。除此之外虹茶，因為對于阿里云的負載均衡而言逝薪，健康檢查使用的都是私網(wǎng)地址實現(xiàn)的，所以如果根本沒有監(jiān)聽到私網(wǎng)地址或者私網(wǎng)地址本身存在故障也會導致健康檢查的失敗蝴罪。還有服務器上可能存在防火墻董济，將監(jiān)聽端口屏蔽掉了，導致健康檢查并未通過要门。此外還可能存在一些配置方面的問題虏肾，比如提供服務的端口和做健康檢查的端口不一致也可能存在健康檢查失敗。
針對于TCP的健康檢查而言欢搜，很多用戶會經(jīng)撤夂溃看到自己的后端服務器上日志上面有很多10或者16這些網(wǎng)段的訪問，并且訪問流量還比較大炒瘟，這是因為之前所提到的健康檢查具有一定的間隔時間吹埠，比如2秒或者3秒一次。這時候一些用戶可能就會認為健康檢查會影響服務器的性能疮装，占了很多的服務器的連接數(shù)缘琅。其實可以從上圖中左側(cè)的報文交互情況看到，當SLB對于云服務器發(fā)起健康檢查的時候首先會發(fā)一個SYN的請求廓推，如果服務器端口是存活的刷袍，那么它會回應一個ACK，這個時候SLB端就會緊接著發(fā)送RST報文受啥。也就是說實際上連接是并沒有建立的做个，所以也不會占用后端服務器的連接數(shù)的資源鸽心，并且對于性能的影響也是極為有限的滚局。
為啥會失敗(HTTP)
HTTP常見的健康檢查失敗原因大概會有這樣的三點：最常見的情況就是有些用戶把服務器的HEAD請求方式禁掉了，因為默認在使用瀏覽器或者手機等請求一個頁面的時候使用的都是GET方式顽频，有時候可能需要上傳數(shù)據(jù)則會使用POST方式藤肢，雖然很多服務器都支持HEAD請求方式，但是有些服務器可能會處于安全或者其他復雜因素的考慮將HEAD請求禁掉糯景。所以在這里建議客戶將服務器的HEAD請求方式打開嘁圈，因為阿里云負載均衡七層健康檢查方案就是使用的HEAD方案。另外一種常見情況就是頁面訪問本身上就存在問題蟀淮，這樣的情況下健康檢查也是無法通過的最住。最后一種常見情況就是期望結(jié)果配置錯誤，針對于七層的健康檢查是通過使用HEAD請求方式去請求頁面怠惶，頁面返回碼可能會是200涨缚、300或者400以及500等，用戶可以在健康檢查的配置中設定預期的正常情況下的返回碼值策治，當健康檢查返回碼值與預期值不一致就會判定健康檢查是失敗的脓魏。
為啥會失敗(UDP)
這里介紹一下UDP健康檢查的原理兰吟。首先，健康檢查通過SLB向后端發(fā)送UDP報文探測來獲取狀態(tài)信息茂翔。SLB會周期性地給后端ECS發(fā)送UDP報文混蔼，如果UDP端口的業(yè)務處于正常情況，則沒有任何回應珊燎。而當服務出現(xiàn)問題惭嚣，比如指定的UDP服務端口處于不可達的情況或者無服務的狀態(tài)的時候，會回復ICMP的不可達報文俐末。這里也會存在一個問題就是如果后端服務器已經(jīng)變成了網(wǎng)絡中的孤島料按，比如出現(xiàn)了整個服務器的掉電、關(guān)機情況這樣完全不能工作的狀態(tài)卓箫，這時候的ICMP不可達報文是永遠不可能收到的载矿，因為后端的服務器無法收到SLB發(fā)來的UDP探測報文，那么在這種情況下烹卒，可能會出現(xiàn)誤認為后端健康的情況闷盔，但是實際上這個服務可能已經(jīng)宕掉了。為了應對這種情況旅急，健康檢查還提供用戶自定義UDP應答報文來實現(xiàn)精確的UDP健康檢查逢勾，也就是由用戶自定義指定一個字符串，當后端的云服務器收到UDP健康檢查的探測的時候藐吮，也回應指定的字符串溺拱，之后SLB對于這個字符串進行對比和校驗，如果匹配成功則認為服務一定是健康的谣辞，這樣就可以實現(xiàn)非常精確的健康檢查迫摔。
而UDP的健康檢查失敗也有很多原因，比如在協(xié)議棧里面有可能會有ICMP限速保護泥从。當頻率達到一定速率的時候句占，ICMP會被協(xié)議棧限制，后端無法回應ICMP不可達報文躯嫉，進而導致SLB收不到ICMP的報文纱烘，出現(xiàn)健康檢查的失敗情況。所以這部分是需要注意的祈餐，如果可能盡量將速率限制放大一些擂啥。
其他問題
健康檢查時好時壞的可能原因如下：
HTTP類型健康檢查目標URI響應慢。比如本身是動態(tài)頁面帆阳，會涉及到大量的計算才能夠渲染完成并返回到前端哺壶，這樣肯定就會導致健康檢查響應比較慢。如果服務器負載過高同樣也會出現(xiàn)這樣的問題。
未全部放開對SLB健康檢查源地址的限制導致分布式健康檢查失敗变骡。因為阿里云的服務器都是分布式的部署离赫，健康檢查也會是分布式的探測，LVS等機器在后端有不同的源去針對某一個云服務器進行探測的塌碌，所以如果沒有將這些源地址都放開渊胸，實際上也會影響健康檢查的效率，因為對于這么多機器而言台妆，只要有一臺機器檢測到是正常的那么就是正常的翎猛。
還可能出現(xiàn)直接訪問正常，但是健康檢查失敗的情況接剩。造成這樣情況的可能原因如下：
防火墻限制切厘。
目的端口不一致。
檢查方法不同懊缺，可能使用瀏覽器看頁面是沒問題的疫稿，但是健康檢查卻不行，這就是因為剛才所提到的HEAD方法沒有開啟鹃两∫抛或者七層的健康檢查配置了URL按照域名轉(zhuǎn)發(fā)，但是在瀏覽器上直接訪問則是使用域名去做的俊扳，而健康檢查是使用IP地址做的途蒋，這樣也可能出現(xiàn)轉(zhuǎn)發(fā)和預期結(jié)果的不同。
檢查頻率不同馋记，ICMP限速号坡。
五、為什么負載不均衡
調(diào)度算法與會話保持
首先介紹一下負載均衡的調(diào)度算法梯醒。阿里云的負載均衡支持三種算法宽堆，第一種算法是單純的輪詢(RR)，也就是將業(yè)務的請求依次地分發(fā)到后端的服務器冤馏。第二種算法是加權(quán)輪詢(WRR)日麸，也就是在處理調(diào)度的時候會根據(jù)針對于每一臺后端服務器設置權(quán)重來進行轉(zhuǎn)發(fā)寄啼。這里之所以設置權(quán)重是因為后端服務器的處理能力可能是不同的逮光，如果使用相同的權(quán)重進行輪詢可能就會把后端處理能力比較弱的服務器擠爆，所以需要針對于服務器的處理能力設置一些權(quán)重墩划。第三種算法是針對于加權(quán)最小連接數(shù)的輪詢(WLC)涕刚，也就是除了根據(jù)每臺后端服務器設定的權(quán)重值來進行輪詢，同時還考慮后端服務器的實際負載乙帮，也就是連接數(shù)杜漠。當權(quán)重值相同時，當前連接數(shù)越小的后端服務器被輪詢到的次數(shù)也越高，這樣就能夠保證負載盡量地均衡驾茴。如果不考慮這一點就會造成某些服務器連接數(shù)已經(jīng)很高了但是流量依然還往上面分發(fā)盼樟，而另外一些服務器卻一直處于空閑狀態(tài)。
會話保持指的是來自同一用戶請求始終保持分發(fā)到同一臺后端的云服務器上锈至。對于同一用戶而言晨缴，使用的是四層的負載均衡和使用七層的負載均衡在理解上是不一樣的。如果是四層負載均衡峡捡，則會使用源IP地址標識同一用戶击碗，所以如果在可能會有很多辦公電腦的大型企業(yè)中，這些電腦在企業(yè)內(nèi)部是通過局域網(wǎng)的IP進行通信的们拙，在訪問公網(wǎng)的時候都是通過NAT網(wǎng)關(guān)處理的稍途，所以在走到Internet的時候，源地址通常會是一個或者很有限的幾個砚婆。在這種情況下械拍，如果是四層的負載均衡就會把里面所有的請求都視為來自同一個用戶的，這種情況下如果開啟了會話保持装盯，就會發(fā)生問題殊者。而七層的負載均衡是根據(jù)用戶瀏覽器中的Cookie來進行唯一識別的，對于剛才的案例在大型企業(yè)里面因為內(nèi)網(wǎng)訪問公網(wǎng)的源地址都是一樣的验夯，導致沒有辦法識別到底是不是同一個用戶猖吴，此時建議使用七層的負載均衡方案解決，因為Cookie是每個瀏覽器都唯一的挥转。會話的保持時間是可以在控制臺上配置的海蔽，四層的負載均衡方案最大可達1小時，而七層的方案最大可達24小時绑谣。
為何不均衡
最后分享一下不均衡的常見情況党窜。有時候會需要新加一個服務器進來，這時候往往到新加進來的服務器上的連接會很少借宵，這是因為可能會存在以下原因：
存在會話保持的情況下幌衣，會話保持會讓請求停留在原有的服務器上，這樣到新加進來的服務器上的連接自然會少一些壤玫。
權(quán)重設置不一致豁护，如果在權(quán)重的設置上存在區(qū)別，而新加進來的服務器的權(quán)重如果很低欲间，連接也過不去楚里。
應用屬于長連接類型，因為需要在TCP上復用猎贴，如果客戶端不主動斷開連接班缎，后續(xù)所有的請求都會繼續(xù)復用當前服務器上的連接蝴光，只有新建連接才有可能到新的服務器上。
而有時候在業(yè)務量或者新建連接較少時达址，也會出現(xiàn)負載不均衡的問題蔑祟。這是因為每個Core都是獨立的調(diào)度單元，因此可能存在將某個Client的多條業(yè)務經(jīng)過不同core的調(diào)度后全部轉(zhuǎn)發(fā)到一臺ECS上的情況沉唠，同時由于業(yè)務量較少做瞪，因此出現(xiàn)了不均衡。建議使用輪詢算法解決右冻，在RR輪詢算法中加入了擾亂因子装蓬，可以更加有效的打散SLB到后端的轉(zhuǎn)發(fā)路徑。
