負載均衡支持對多臺ECS進行流量分發，以提升應用系統的服務能力，長期以來都是關鍵業務系統的入口。淘寶，天貓，阿裡雲等無不依賴負載均衡產品，雙11的流量洪峰也依賴負載均衡的調度和處理能力。
負載均衡SLB簡單介紹
下圖是負載均衡的簡單示意圖，用戶的訪問請求經過SLB實例的一個監聽（端口），再被轉發到後端的ECS上。SLB實例對應一個IP地址，監聽就是實例上IP地址的一個端口，流量調度是基於監聽（端口）進行的，ECS是真正處理服務請求的。
負載均衡SLB架構
下圖是從流量轉發路徑來看的負載均衡SLB的架構圖，可以稱為一個負載均衡SLB的集群，這個集群部署在華東1的兩個可用區，每個可用區都部署瞭LVS集群和Tengine集群，其中LVS集群負責接收所有流量的請求，包括TCP/UDP/HTTP/HTTPS，對於TCP和UDP請求，LVS集群會直接將流量轉發到後端ECS，對於HTTP/HTTPS 請求會將流量轉發給Tengine集群，再轉發到後端ECS上。
負載均衡SLB高可用的四個層次
為瞭便於理解和說明，可以將負載均衡SLB高可用劃分為四個層次，如圖上圖所示，第1層是應用處理層，即真正處理請求的ECS層。第2層是集群轉發層，即在集群轉發層面要保證高可用，第3層是跨可用區容災層，在出現可用區級別的故障時可以切換，第4層是跨地域容災層，上圖未標示。下面分別從這4個層次進行分析和說明。
特別要說明的是，產品設計上SLB會盡可能做到高可用，但如果用戶系統沒有高可用設計，最終也不可能實現真正的高可用，而且除瞭負載均衡，還有數據庫等的高可用問題，因此產品設計的高可用和用戶系統設計高可用必須結合起來。下面4個層次的說明也會分別從產品設計和用戶使用兩個角度進行分析和解讀。
第一層 應用處理層
應用處理層是真正處理用戶請求的，一般將應用部署在ECS上。
從產品設計角度看：
應用處理層的高可用主要有下面兩點，一是要保證ECS出現故障時能及時屏蔽，避免將流量轉發到故障節點從而影響用戶訪問，SLB產品是通過健康檢查功能實現的。二是SLB實例能夠添加多臺ECS，特別是可以添加不同可用區的ECS，從而避免一個可用區的ECS均不可用時影響用戶訪問。這兩點目前SLB產品都可以做到。
從用戶使用角度看：
首先，用戶一定要開啟並正確配置健康檢查。SLB支持TCP/UDP/HTTP/HTTPS 四種協議，其中對TCP協議提供瞭TCP和HTTP兩種健康檢查方式，用戶可以根據需要選擇。對UDP協議，用戶可以定義UDP健康檢查端口，還可以根據自己定義健康檢查請求和返回值來判斷健康檢查結果。對於HTTP和HTTPS協議，默認使用HTTP健康檢查，用戶可以定義一個健康檢查URL，負載均衡的健康檢查模塊會通過HTTP HEAD來探測獲取狀態。關於健康檢查詳細信息可以參考健康檢查原理說明。
其次，用戶要考慮到單可用區ECS都不可用的情況，選擇多個可用區的ECS添加到負載均衡SLB的實例中。用戶可能有疑問，如果一個可用區的ECS不可用瞭，那這個可用區的負載均衡是不是也會不可用？這個問題在稍後的第三層來說明。
第二層 集群轉發層
集群轉發層指的是負載轉發用戶請求的SLB集群，包括LVS 集群和Tengine集群，不管是機器故障還是集群升級，都要保障用戶請求盡可能不中斷，
從產品設計角度看：
首先，必須避免單點故障，如果采用傳統的主備切換模式一方面在切換的時候可能影響用戶請求，另一方面主備切換還是依賴單機的處理能力，無法很好的橫向擴充，因此，轉發層不管是LVS還是Tengine集群都集群部署，並通過上層交換機的ECMP等價路由還實現用戶請求到集群多臺機器的流量轉發。看上面的架構圖可能用戶有疑問，TENGINE集群是接在LVS集群後面的，上層交換機的ECMP如何起作用呢？其實LVS集群對Tengine集群也是有健康檢查機制的，即如果Tengine集群的機器出現異常，LVS健康檢查發現後會將這臺異常的Tengine機器從集群中摘除。
其次，在集群中機器出現down機等異常時盡可能不影響用戶請求。有瞭集群部署後，集群中的機器出現軟硬件故障還是難以避免的，有可能機器徹底不可用瞭或者有異常瞭需要通過運維手段將這臺機器從集群中移出並維修，這個時候這臺機器上的用戶請求要盡可能做到不中斷。
SLB集群是通過Session同步來實現集群中有機器故障時盡可能不影響用戶請求的。如下圖所示，當用戶的訪問請求經過集群中的一臺LVS時，集群會根據預設的規則將Session同步到其它LVS機器，從而實現LVS集群所有機器都有該Session，當如下圖中的LVS1機器出現故障或需要維護時，用戶請求就會通過其它LVS機器進行流量轉發並且用戶基本不感知。但是有Session同步不代表就解決瞭所有問題，Session同步能解決大部分長連接的問題，但是對於短鏈接，連接未建立（三次握手未完成）或者已建立連接但是還沒有觸發Session同步規則時，機器故障還是可能會影響用戶請求。因此，需要用戶的系統和程序進行配合。
從用戶使用角度看，一定要在代碼中加上相應的重試機制！ 這樣在上述情況出現時，會進一步降低對用戶訪問影響。
第三層 跨可用區容災層
上面說的是在一個可用區內負載均衡轉發集群的高可用，跨可用容災層則要解決的是當一個可用區都不可用時，還能繼續使用另外一個可用區的負載均衡繼續提供服務。
從產品設計角度看：
還是如看SLB架構圖，首先，負載均衡集群要實現跨可用區部署。另外，還需要一種機制能及時發現其中某個可用區，如可用區A都出現瞭故障然後切換到另外一個可用區B繼續服務。從技術上講，使用瞭路由探測和路由優先級機制來實現，即可用區A的一段地址（對應一批SLB實例1-N）除瞭在本可用區的集群上配置外，其實底層還在可用區B的集群上也有這段地址（對應一批SLB實例1-N），隻不過在正常情況下，由於可用區A的這段地址路由優先級更高，所以流量都從可用區A的集群進行轉發，如果路由探測到整個可用區A不可用（路由不可達）或者可用區A的某段地址不可用（路由不可達），則路由到可用區B的集群進行流量轉發。
從用戶對產品形態的感知上來說，就是主可用區和備可用區，但實例上的這個主備可用區用戶選擇後就無法更改瞭，用戶也無法自行切換主備關系。也就是說主備可用區是底層的機制，用戶一旦選擇無法幹預瞭。暴露主備可用區概念的原因一方面希望用戶在使用SLB和其它有可用區屬性的產品進行組合的時候，能做到按需組合，如ECS可用區，RDS的主備可用區等。另一方面也是希望用戶更多認知到產品在高可用方面的價值。不過在實際使用時，用戶往往存在誤區，這些誤區使我們考慮是不是要關閉備可用區概念，隻對用戶暴露主可用區，後面再來解釋這些誤區。
回過頭來說跨可用區高可用，其實，最理想的情況是一個可用區的一個SLB實例出現異常（路由不可達）時，系統就能夠自動切換或者用戶能手動切換到另外一個可用區的SLB實例繼續服務。但不能這樣做的主要原因是需要發佈明細路由，即32位路由，而這在雲環境中是無法接受的。
從用戶使用角度看：
首先，跨可用區容災需要保證一個SLB實例的後端服務器ECS分佈在多個可用區，即避免一個可用區不可用時，SLB後端的ECS都無法使用從而影響用戶訪問，這點在第一層 應用處理層中已經說明瞭。當然，如果還使用DB等產品，還需要考慮DB的跨可用區容災問題，用戶可以參考DB相關產品的說明。這裡主要談負載均衡本身以及和負載均衡緊密相關的後端服務器ECS的高可用問題。
其次，對於重要的業務，一定要使用至少兩個且主可用區不一樣的實例來容災，這點非常重要。如重要的用戶註冊系統，如下圖所示，在華東1的可用區A和可用區B分佈部署一個SLB實例，都掛載瞭兩個可用區的相同ECS。
用戶可能會有兩個疑問，一是負載均衡SLB產品本身有跨可用區切換能力，為什麼註冊系統還需要自己在兩個可用區建立兩個實例進行跨可用區容災呢？負載均衡SLB產品本身的跨可用區切換是在非常極端的情況下（整個可用區不可用/所有LVS集群上的IP無法路由/某個地址段都無法路由）才切換，而對於比如僅一個可用區的Tengine有部分異常、LVS集群有異常但是IP還可以Ping通等相對不那麼極端又會影響用戶業務的情況下是不起作用的，因此，重要的業務系統非常有必要用戶自己在兩個可用區建立實例容災。
二是註冊系統使用的兩個SLB實例如何調度，用戶可以使用雲解析將註冊系統的域名解析到上面的兩個SLB實例，其它的相關域名解析系統也都支持這樣的功能。如果是私網SLB實例，阿裡雲正在研發私網DNS系統，當前用戶可以自己構建一個私網DNS系統或者通過程序來實現調度。
再次強調一下重要業務系統用戶自行在兩個可用區建立實例容災的必要性。哪怕正常情況下有一個實例就配置好不使用，雖然需要支付每小時2分錢的公網IP費用，但當出現其中一個實例所在集群異常並且恢復時間較長時，用戶也可以自行通過修改DNS解析或者程序調用地址來快速恢復業務。
最後，再來說下用戶對於主備可用區可能存在的誤區
1）認為主備可用區就是隻要一個實例有異常瞭負載均衡就能自動切換到備可用區
2）認為主備可用區切換的異常包括個別實例無法Ping、實例上的服務異常等等很多條件
其實，負載均衡主備可用區切換設計是在極端情況下（整個可用區不可用/所有LVS集群上的IP無法路由/某個地址段都無法路由）才會自動進行的，它既不是某個IP地址無法路由就切換，也不是某個或者某些IP地址可以Ping但這些IP的服務異常就切換。因此，用戶系統通過自身在多個可用區建立實例實現跨可用區災是非常必要的。
第四層 跨地域容災層
最後來說下跨地域容災層。隨著業務的發展，用戶對業務系統的高可用要求越來越高，已經不滿足於隻能做到跨可用區的容災，用戶希望即使某個地域的系統都不可用瞭，還可用通過其它地域的系統繼續提供服務，這就是跨地域容災。
跨地域容災是個非常大的課題，不僅僅涉及到網絡層面，更涉及到應用系統的改造和適配，數據的同步和一致性等很棘手的問題。這裡僅說明下網絡層面的跨地域容災。從產品角度看，跨可用區容災一般是通過DNS來實現的，如下圖所示
傳統的如F5的全局負載均衡（以前叫GTM，現在叫BIG-IP DNS）就有比較完善的解決方案，或者一些提供DNS服務的系統也有類似的功能。負載均衡SLB產品本身沒有提供這樣的能力，跨地域容災的能力是通過雲解析DNS產品來實現的，雲解析DNS產品提供瞭全局負載均衡的能力，還有如健康檢查，路由調度優化等功能，可以參考 全球負載均衡跨地域容災解決方案
另外，對於跨可用區容災可能需要使用在不同地域間同步數據或者跨地域私網調用，可以使用高速通道產品構建不同地域的通信鏈路
從用戶角度看，跨可用區容災網絡層面主要通過雲解析DNS產品，對於不同地域間通信可以使用高速通道產品，這兩個產品不是本文的重點，可以查看阿裡雲官網的相關產品文檔說明。
作者
李泉，阿裡雲網絡產品高級專傢
原文鏈接：負載均衡SLB高可用的四個層次-博客-雲棲社區-阿裡雲