日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

均衡網(wǎng)絡(luò)流量的常用技術(shù)，它們的優(yōu)勢和利弊權(quán)衡。

大型的多站點互聯(lián)網(wǎng)系統(tǒng)，包括內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）和云服務(wù)提供商，用一些方法來均衡來訪的流量。這篇文章我們講一下常見的流量均衡設(shè)計，包括它們的技術(shù)手段和利弊權(quán)衡。

早期的云計算服務(wù)提供商，可以提供單一一臺客戶 Web 服務(wù)器，分配一個 IP 地址，然后用一個便于人讀的域名配置一個 DNS 記錄指向這個 IP 地址，再將 IP 地址通過邊界網(wǎng)關(guān)協(xié)議（BGP）宣告出去，BGP 是在不同網(wǎng)絡(luò)之間交換路由信息的標(biāo)準(zhǔn)方式。

這本身并不是負載均衡，但是能在冗余的多條網(wǎng)絡(luò)路徑中進行流量分發(fā)，而且可以利用網(wǎng)絡(luò)技術(shù)讓流量繞過不可用的網(wǎng)絡(luò)，從而提高了可用性（也引起了非對稱路由的現(xiàn)象）。

簡單的 DNS 負載均衡

隨著來自客戶的流量變大，老板希望服務(wù)是高可用的。你上線第二臺 web 服務(wù)器，它有自己獨立的公網(wǎng) IP 地址，然后你更新了 DNS 記錄，把用戶流量引到兩臺服務(wù)器上（內(nèi)心希望它們均衡地提供服務(wù)）。在其中一臺服務(wù)器出故障之前，這樣做一直是沒有問題的。假設(shè)你能很快地監(jiān)測到故障，可以更新一下 DNS 配置（手動更新或者通過軟件）刪除解析到故障機器的記錄。

不幸的是，因為 DNS 記錄會被緩存，在客戶端緩存和它們依賴的 DNS 服務(wù)器上的緩存失效之前，大約一半的請求會失敗。DNS 記錄都有一個幾分鐘或更長的生命周期（TTL），所以這種方式會對系統(tǒng)可用性造成嚴(yán)重的影響。

更糟糕的是，部分客戶端會完全忽略 TTL，所以有一些請求會持續(xù)被引導(dǎo)到你的故障機器上。設(shè)置很短的 TTL 也不是個好辦法，因為這意味著更高的 DNS 服務(wù)負載，還有更長的訪問時延，因為客戶端要做更多的 DNS 查詢。如果 DNS 服務(wù)由于某種原因不可用了，那設(shè)置更短的 TTL 會讓服務(wù)的訪問量更快地下降，因為沒那么多客戶端有你網(wǎng)站 IP 地址的緩存了。

增加網(wǎng)絡(luò)負載均衡

要解決上述問題，可以增加一對相互冗余的四層（L4）網(wǎng)絡(luò)負載均衡器，配置一樣的虛擬 IP 地址（VIP）。均衡器可以是硬件的，也可以是像 HAProxy 這樣的軟件。域名的 DNS 記錄指向 VIP，不再承擔(dān)負載均衡的功能。

四層負載均衡器能夠均衡用戶和兩臺 web 服務(wù)器的連接

四層均衡器將網(wǎng)絡(luò)流量均衡地引導(dǎo)至后端服務(wù)器。通常這是基于對 IP 數(shù)據(jù)包的五元組做散列（數(shù)學(xué)函數(shù)）來完成的，五元組包括：源地址、源端口、目的地址、目的端口、協(xié)議（比如 TCP 或 UDP）。這種方法是快速和高效的（還維持了 TCP 的基本屬性），而且不需要均衡器維持每個連接的狀態(tài)。（更多信息請閱讀谷歌發(fā)表的 Maglev 論文，這篇論文詳細討論了四層軟件負載均衡器的實現(xiàn)細節(jié)。）

四層均衡器可以對后端服務(wù)做健康檢查，只把流量分發(fā)到健康的機器上。和使用 DNS 做負載均衡不同的是，在某個后端 web 服務(wù)故障的時候，它可以很快地把流量重新分發(fā)到其他機器上，雖然故障機器的已有連接會被重置。

當(dāng)后端服務(wù)器的能力不同時，四層均衡器可以根據(jù)權(quán)重做流量分發(fā)。它為運維人員提供了強大的能力和靈活性，而且硬件成本相對較小。

擴展到多站點

系統(tǒng)規(guī)模在持續(xù)增長。你的客戶希望能一直使用服務(wù)，即使是數(shù)據(jù)中心發(fā)生故障的時候。所以你建設(shè)了一個新的數(shù)據(jù)中心，另外獨立部署了一套服務(wù)和四層負載均衡器集群，仍然使用同樣的 VIP。DNS 的設(shè)置不變。

兩個站點的邊緣路由器都把自己的地址空間宣告出去，包括 VIP 地址。發(fā)往該 VIP 的請求可能到達任何一個站點，取決于用戶和系統(tǒng)之間的網(wǎng)絡(luò)是如何連接的，以及各個網(wǎng)絡(luò)的路由策略是如何配置的。這就是泛播。大部分時候這種機制可以很好的工作。如果一個站點出問題了，你可以停止通過 BGP 宣告 VIP 地址，客戶的請求就會迅速地轉(zhuǎn)移到另外一個站點去。

多個站點使用泛播提供服務(wù)

這種設(shè)置有一些問題。最大的問題是，不能控制請求流向哪個站點，或者限制某個站點的流量。也沒有一個明確的方式把用戶的請求轉(zhuǎn)到距離他最近的站點（為了降低網(wǎng)絡(luò)延遲），不過，網(wǎng)絡(luò)協(xié)議和路由選路配置在大部分情況下應(yīng)該能把用戶請求路由到最近的站點。

控制多站點系統(tǒng)中的入站請求

為了維持穩(wěn)定性，需要能夠控制每個站點的流量大小。要實現(xiàn)這種控制，可以給每個站點分配不同的 VIP 地址，然后用簡單的或者有權(quán)重的 DNS 輪詢來做負載均衡。

多站點提供服務(wù)，每個站點使用一個主 VIP，另外一個站點作為備份?；谀芨兄乩砦恢玫?DNS。

現(xiàn)在有兩個問題。

第一、使用 DNS 均衡意味著會有被緩存的記錄，如果你要快速重定向流量的話就麻煩了。

第二、用戶每次做新的 DNS 查詢，都可能連上任意一個站點，可能不是距離最近的。如果你的服務(wù)運行在分布廣泛的很多站點上，用戶會感受到響應(yīng)時間有明顯的變化，取決于用戶和提供服務(wù)的站點之間有多大的網(wǎng)絡(luò)延遲。

讓每個站點都配置上其他所有站點的 VIP 地址，并宣告出去（因此也會包含故障的站點），這樣可以解決第一個問題。有一些網(wǎng)絡(luò)上的小技巧，比如備份站點宣告路由時，不像主站點使用那么具體的目的地址，這樣可以保證每個 VIP 的主站點只要可用就會優(yōu)先提供服務(wù)。這是通過 BGP 來實現(xiàn)的，所以我們應(yīng)該可以看到，流量在 BGP 更新后的一兩分鐘內(nèi)就開始轉(zhuǎn)移了。

即使離用戶最近的站點是健康而且有服務(wù)能力的，但是用戶真正訪問到的卻不一定是這個站點，這個問題還沒有很好的解決方案。很多大型的互聯(lián)網(wǎng)服務(wù)利用 DNS 給不同地域的用戶返回不同的解析結(jié)果，也能有一定的效果。不過，因為網(wǎng)絡(luò)地址的結(jié)構(gòu)和地理位置無關(guān)，一個地址段也可能會改變所在位置（例如，當(dāng)一個公司重新規(guī)劃網(wǎng)絡(luò)時），而且很多用戶可能使用了同一個 DNS 緩存服務(wù)器。所以這種方案有一定的復(fù)雜度，而且容易出錯。

增加七層負載均衡

又過了一段時間，你的客戶開始要更多的高級功能。

雖然四層負載均衡可以高效地在多個 web 服務(wù)器之間分發(fā)流量，但是它們只針對源地址、目標(biāo)地址、協(xié)議和端口來操作，請求的內(nèi)容是什么就不得而知了，所以很多高級功能在四層負載均衡上實現(xiàn)不了。而七層（L7）負載均衡知道請求的內(nèi)容和結(jié)構(gòu)，所以能做更多的事情。

七層負載均衡可以實現(xiàn)緩存、限速、錯誤注入，做負載均衡時可以感知到請求的代價（有些請求需要服務(wù)器花更多的時間去處理）。

七層負載均衡還可以基于請求的屬性（比如 HTTP cookies）來分發(fā)流量，可以終結(jié) SSL 連接，還可以幫助防御應(yīng)用層的拒絕服務(wù)（DoS）攻擊。規(guī)模大的 L7 負載均衡的缺點是成本 —— 處理請求需要更多的計算，而且每個活躍的請求都占用一些系統(tǒng)資源。在一個或者多個 L7 均衡器前面運行 L4 均衡器集群，對擴展規(guī)模有幫助。

結(jié)論

負載均衡是一個復(fù)雜的難題。除了上面說過的策略，還有不同的負載均衡算法，用來實現(xiàn)負載均衡器的高可用技術(shù)、客戶端負載均衡技術(shù)，以及最近興起的服務(wù)網(wǎng)絡(luò)等等。

核心的負載均衡模式隨著云計算的發(fā)展而不斷發(fā)展，而且，隨著大型 web 服務(wù)商致力于讓負載均衡技術(shù)更可控和更靈活，這項技術(shù)會持續(xù)發(fā)展下去。