有個朋友的web服務，因為線上使用者數目平常波動很大，按照最大線上數部署伺服器顯然太浪費，是以選擇了騰訊雲的彈性伸縮(AutoScaling)服務，在每天使用者集中上線的時間點上快速擴容伺服器加入到叢集中分散壓力。是以在叢集遭遇到突發的通路壓力的時候，快速的自動擴容能力就顯得非常重要了。前陣子還專門為此請教了騰訊雲專家，解析了快速生成主機的不傳之秘 。
但是快速生成了主機并加入叢集，并不能確定主機快速的分擔壓力，因為騰訊雲的負載均衡目前隻支援IP hash 和按權重輪詢兩種方式，這兩種配置設定算法在新伺服器加入後都需要經過一段短時間的預熱才能逐漸配置設定到流量。是以擴容後的曲線常常會是這樣子的（剛剛進行的擴容實測，為了降低對業務影響測試了5分鐘就停掉了）：
注意紅色曲線和橫軸重合的部分：
（第一分鐘0Mbps）
（第二分鐘0Mbps）
（第三分鐘0Mbps）
也就是說，雖然生成一台伺服器我們可以優化到數十秒，但是新伺服器加入叢集後的前面幾分鐘幾乎沒有請求分發到新伺服器上，随後才步入正軌。這樣顯然延長了壓力緩解過程，讓更多使用者忍受了幾分鐘的惡劣體驗。
那有沒有辦法縮短這個過程呢？騰訊雲近期将推出的新的負載均衡輪詢算法就可以解決這個問題。新算法被稱為“最小連接配接數”算法，也就是LB會随時判斷哪台主機上的HTTP連接配接數最少，然後盡量把新的請求分發給它。經過一番軟磨硬泡，終于從負載均衡團隊磨到了新LB算法的内測體驗資格，立刻做了一個擴容實驗。我們來看看效果：
可以看到，最開始和橫軸重合的一段消失了，新伺服器在接入的第一時間立刻分攤到了通路量并輸出流量，叢集中過載的伺服器壓力也就立刻得到了緩解。
不隻是擴容過程會從新算法中收益，實際上在以往的算法中，叢集中的伺服器都難以即時分擔彼此的壓力，當某一台或者幾台伺服器壓力過大的時候，LB隻會繼續按照權重随機的配置設定新的請求給它，而不是降低它的權重，讓它緩一緩。而在新算法中，如果一台伺服器負擔壓力過重導緻請求無法及時響應完成，LB就會觀察到它的連接配接數增加，并把更多的請求配置設定給連接配接數更少的伺服器，進而達到更優的負載均衡效果。
當然，要充分獲得這些優勢都要取決于接入伺服器已經實作了『無狀态化』這個前提，否則負載均衡也無法随意的把一台伺服器的壓力轉移到另一台上面。
相關推薦
【騰訊TMQ】和開發一起寫代碼，讓測試左移起來
手遊相容性測試MGCT
【App專項測試】—沖突測試