slb
簡單來講就是slb系統也是乙個由多台計算機構成的集群。使用者在這個系統中申請和配置了乙個slb的例項對外提供服務，針對該slb例項的訪問請求會通過我們的系統按照使用者設定的規則向後端的多台ecs進行**。那麼當我們系統內的某一台計算機出現問題的時候，其他的計算機可以承擔本應由其處理的任務而保證整個集群和服務的可用性。如果你為自己的slb例項正確的開啟了健康檢查功能，那麼當你slb例項後端的某一台ecs出現問題的時候，其他的ecs也會承擔其工作來保證你對外服務的可用性。
負載均衡（阿里雲幫助與文件）：
基礎架構：
技術原理：
健康檢查原理：
網路流量說明：
高可用概要說明：
關鍵點：
基礎架構及入網流量圖，資料報走向
**策略
支援 tcp/udp（4 層） 和 http/https（7 層） 這 4 種協議
基礎架構
負載均衡採用集群部署，可實現會話同步，以消除伺服器單點，提公升冗餘，保證服務穩定。阿里雲當前提供4層（tcp協議和udp協議）和7層（http和https協議）的負載均衡服務。
如下圖所示，各個地域的四層負載均衡實際上是由多台 lvs 機器部署成乙個 lvs 集群來執行的，採用集群部署模式極大的保證了異常情況下負載均衡服務的可用性、穩定性與可擴充套件性。
對於入網流量，負載均衡會根據使用者在控制台或api上配置的**策略，對來自前端的訪問請求進行**和處理。資料流轉如下圖所示。
雲伺服器（elastic compute service，簡稱 ecs）是一種簡單高效、處理能力可彈性伸縮的計算服務
客戶端訪問負載均衡例項ip位址時，相關請求由負載均衡例項對應的lvs集群處理。
lvs集群內的每一台節點伺服器均分來自前端的請求。
如果相應的負載均衡例項服務埠使用的是四層協議（tcp或udp），那麼lvs集群內每個節點都會根據負載均衡例項負載均衡策略，將其承載的服務請求按策略直接分發到後端ecs伺服器，並同時維護會話保持等特性。
如果相應的負載均衡例項服務埠使用的是七層http協議，那麼lvs集群內每個節點會先將其承載的服務請求均分到tengine集群；而後，tengine集群內的每個節點再根據負載均衡策略，將服務請求按策略最終分發到後端ecs伺服器，並同時維護會話保持等特性。
如果相應的負載均衡例項服務埠使用的是七層https協議，與上述http處理過程類似，差別是在按策略將服務請求最終分發到後端ecs伺服器前，會先呼叫key server進行證書驗證及資料報解密等前置操作。
負載均衡例項服務埠：多個埠，不同埠使用不同協議？按資料報協議型別分發？負載均衡和後端ecs之間是通過內網進行通訊的，所以，正常情況下，負載均衡後端ecs無需配置外網頻寬。如果使用者業務有同時通過後端ecs對外提供服務，或後端ecs有訪問外網的需求， 那麼，在後端ecs購買了公網頻寬後，後端ecs的出網流量路徑有所不同。
技術原理
整個負載均衡系統由三部分構成：四層負載均衡、七層負載均衡和控制系統。
四層負載均衡 vs 七層負載均衡：
選擇**策略
權重代表相應伺服器所承載的業務的相對佔比，而非絕對值。當前 slb 支援 3 種**策略，其使用場景及要點如下：
**策略
演算法說明
使用要點
加權輪詢（wrr）
按比重輪流分配新增連線。
●根據後端 ecs 規格的不同，配置相應的權重。
●如果是長連線業務，可能會導致老伺服器的連線數持續增加， 而新加入伺服器的連線數相對非常低，造成負載不均的假象。
加權最小連線數（wlc）
●在 slb 服務端，實時統計與後端 ecs 已建立的 established 狀態連線數，來評估相應伺服器的負載情況。
●按權重比例，將新增連線分配給活動連線數少的伺服器，最終盡可能使伺服器的已建立連線數與其權重成正例。
當前暫未實現新增伺服器的過載保護或緩衝機制。所以，如果業務併發非常高，可能會導致新增伺服器連線數陡增，對業務造成影響。建議新增伺服器時，逐步調高權重。
輪詢（rr）
按順序逐一分發新增連線。
必須手工確保後端 ecs 的業務承載能力一致。
示例：假設有 100 個新增連線，則在不同的排程演算法下，不同伺服器的分配連線數示意如下：
伺服器權重
佔比加權輪詢
加權最小連線數輪詢a
5050/
(100+50+50)
=25%
將 100*25%=25 個連線分發給伺服器 a
實時統計連線數，逐一將新增連線分配給活動連線數最少的伺服器。最終使其新增連線數佔比大致為 25%
不考慮權重，按順序分發新增連線到伺服器 a/b/c
b100
100/
(100+50+50)
=50%
將 100*50%=50 個連線分發給伺服器 b
↑ 同上，最終使其新增連線數佔比大致為 50%
↑ 同上c50
50/(100+50+50)=
25%將 100*25%=25 個連線分發給伺服器 c
↑ 同上，最終使其新增連線數佔比大致為 25%
↑ 同上d0
0/(100+50+50)
=0%伺服器下線，不分配任何連線
← 同左
← 同左
使用者通過 ping slb 的 vip 位址來判斷 slb 服務的有效性。
其實，這種測試非常不可靠。因為 ping 響應是由 slb 服務端直接完成的，與後端 ecs 無關。所以，正常情況下：
建議：對於 4 層服務，；對於 7 層服務，通過實際的業務訪問進行可用性測試。
技術限制：
slb 在技術層面還在逐步增強和完善，截止本文發稿，還存在如下技術限制：
不支援**超時時間的調整：
金融雲 slb 基於安全性考慮，僅允許開放特定的埠：80，443，2800-3300，6000-10000，13000-14000
健康檢查：
負載均衡通過健康檢查來判斷後端ecs的業務可用性。開啟健康檢查功能後，當後端某台ecs健康檢查出現異常時，負載均衡會自動將新的請求分發到其它健康檢查正常的ecs上；而當該ecs恢復正常執行時，負載均衡會將其自動恢復到對外或對內的服務中。
負載均衡健康檢查機制提高了前端業務整體可用性，避免了後端ecs異常對總體服務的影響。
如果您對業務對負載有高敏感性，高頻率的健康檢查探測可能會對正常業務訪問造成影響。您可以結合業務情況，通過降低健康檢查頻率、增大健康檢查間隔、七層檢查修改為四層檢查等方式，來降低對業務的影響。但為了保障業務的持續可用，不建議關閉健康檢查。
阿里雲負載均衡SLB配置教程 實戰案例
雖然實際訪問量沒有達到預估的百萬，日均有4 5萬，併發有100多，所以此次配置還是相當有效的。由於專案是純前端h5，把專案整體打包到cdn，這樣就算分享介面掛掉，也不會影響h5的正常訪問。那壓力就集中在分享介面的承載上。具體的slb操作方法這裡不再陳述，阿里雲slb的入門文件 寫的很清楚了。這裡只是...
負載均衡SLB
負載均衡 server load balancer，簡稱slb 是一種網路負載均衡服務，針對阿里雲彈性計算平台而設計，在系統架構 系統安全及效能，擴充套件，相容性設計上都充分考慮了彈性計算平台雲伺服器使用特點和特定的業務場景。slb服務主要由3個基本概念組成。loadbalancer代表乙個slb例...
阿里雲負載均衡服務SLB實戰案例 說明指南
雖然實際訪問量沒有達到預估的百萬，日均有4 5萬，併發有100多，所以此次配置還是相當有效的。由於專案是純前端h5，把專案整體打包到cdn，這樣就算分享介面掛掉，也不會影響h5的正常訪問。那壓力就集中在分享介面的承載上。具體的slb操作方法這裡不再陳述，阿里雲slb的入門文件 寫的很清楚了。這裡只是...