負載均衡，就是將請求分發到不一樣服務器上去響應，讓每一個服務器的負載達到均衡的狀態。如今負載均衡是每一個在線應用不可缺乏的環節，因此咱們須要瞭解一下負載均衡的模型和類型，固然在實際解決問題時模型會變的很複雜。本文只討論軟件方案，並不涉及硬件。文末會有一點點小乾貨，是我在新浪課堂上聽的一點知識，關於新浪負載均衡的演進和使用。nginx
1、負載均衡
負載均衡的目的就是讓請求到達不一樣的服務器上。一次請求到服務器之間，有那麼多環節，所以能夠實現的方法有不少種，實際應用中不外乎如下幾種方式。web
1.HTTP重定向負載均衡
HTTP重定向負載均衡有一臺重定向服務器，它也是一臺普通的服務器，其惟一的功能就是根據用戶的HTTP請求計算一臺應用集羣中服務器的地址，並將此地址寫入HTTP重定向響應中返回給用戶。算法
這種方案實現起來很是簡單，可是須要瀏覽器請求兩次服務器才能完成。而且重定向服務器很容易編程瓶頸，由於一次重定向返回的過程，也是一次標準HTTP請求，若是集羣內有10臺機器，那HTTP重定向服務器的流量將是應用服務器的10倍，若是有100臺估計就要宕機了，因此伸縮性能受到了很大的限制。還有使用302響應碼重定向，不利於網站的SEO。編程
2.DNS域名解析負載均衡
這是利用DNS處理域名解析請求的同時進行負載均衡處理的一種方案。在DNS中配置多個A記錄，每次域名解析請求都會根據負載均衡算法計算一個不一樣的IP地址返回。瀏覽器
DNS域名解析負載均衡的優勢是將負載均衡的工做轉交給DNS，省掉了網站管理維護負載均衡服務器的麻煩，同時還可使用智能DNS能夠基於地理位置或者ISP來作域名解析，用戶將會獲得距離最近或者速度最快的一個服務器地址，這樣能夠加快用戶的訪問速度，改善性能。緩存
可是這種方法也有很大的缺點，DNS是多級解析，每一級都會緩存DNS記錄，若是某個服務器變更了，DNS記錄更新的時間將會很長，這個速度取決於域名服務商。服務器
通常大型網站都會使用DNS域名解析，利用域名解析做爲一級負載均衡手段。你可使用 dig <域名> 的方法查看某個域名的A記錄，你會發現不少網站會有多條A記錄。網絡
3.反向代理負載均衡
這種方法就是使用反向代理服務器，它通常在web服務器前面，這個位置也正好是負載均衡服務器的位置，因此大多數反向代理服務器同時也提供負載均衡的功能。併發
因爲web服務器不直接對外提供訪問，所以web服務器不須要使用外部IP，而反向代理服務器則須要配置雙網卡和內部外部兩套IP地址。負載均衡
反向代理服務器轉發請求是在HTTP協議層面，所以也叫應用層負載均衡，因爲應用層在七層網絡模型中的第七層，因此通常也稱爲七層負載均衡。優勢就是和反向代理功服務器功能集成在一塊兒，部署簡單。缺點是反向代理服務器是全部請求和響應的中轉站，其性能可能會成爲瓶頸。
4.網絡層負載均衡
這種方法是在網絡層經過修改請求目標地址進行負載均衡，網絡層在七層網絡層模型的第四層，因此也叫作四層負載均衡，也叫作IP層負載均衡。
請求達到負載均衡服務器後，由負載均衡服務器在操做系統內核進程獲取網絡數據包，根據負載均衡算法獲得一臺真實web服務器的地址，而後修改請求的目的地址到這臺真實的web服務器地址，等到web服務器處理完成後，響應數據包回到負載均衡服務器，再將數據包源地址修改成自身的IP（負載均衡服務器的IP）地址發送給用戶瀏覽器
這裏關鍵在於真實無力web服務器響應數據包如何返回給負載均衡服務器。一種是源地址轉換（SNAT），第二種是負載均衡服務器做爲網關服務器。
網絡層的負載均衡在內核進程完成數據轉發，有更好的性能。可是因爲響應請求的流量要通過負載均衡服務器，容易成爲瓶頸。
5.數據鏈路層負載均衡
數據鏈路層主要處理 mac 地址，因此使用修改mac地址進行轉發請求。負載均衡數據分發過程當中不修改IP地址，只修改mac地址，經過配置真實物理服務器集羣全部機器虛擬IP和負載均衡服務器IP地址一致，從而達到不修改數據包的源地址和目的地址就能夠進行數據分發的目的。
因爲web服務器的服務器地址IP和數據請求目的IP地址一致，不須要經過負載均衡服務器進行地址轉換，可將相應數據包直接返回用戶。若是有足夠的公有IP，其實web服務器也能夠直接使用本身的IP響應請求，不過這樣web服務器必須綁定負載均衡的虛擬IP地址（VIP），才能保證web服務器收到來自負載均衡發送的數據包。
這種方式稱做三角傳輸模式，單臂模式，也叫作直接路由方式（DR）。使用DR方式的鏈路層負載均衡是目前大型網站使用最廣的一種負載均衡手段。
2、關於負載均衡演進
一個應用的流量從多到少，負載均衡的演進基本都是一個套路，新浪也不例外（如下內容有修改），大體打演進過程以下：
- nginx作反向代理的同時也作七層負載均衡。
- 使用四層的代理負載均衡，並使用主備，通常使用HAproxy或者LVS
- 使用單臂模式加七層代理集羣，通常是LVS（DR模式）主備+HAproxy集羣（七層負載均衡）
Nginx 作負載均衡是很是方便的，若是一個機器知足不了需求了，能夠直接作一個反向代理加上負載均衡。四層的代理負載均衡比七層負載均衡性能好不少，集羣規模能夠迅速擴大，而且能夠細分服務。當公司的規模很大的時候，有多個機房、多個大型服務時，LVS（單臂）+HAproxy（七層）就更適合了，以下圖所示（網上盜了一張圖）：
最近我聽了一節新浪有關負載均衡的講座，實際上是一個簡短的課程。新浪的演進過程和上面三個步驟很像，沒有太多的差別。目前大多數服務正在使用2和3的模式，未來須要全量SSL加密，因此新浪準備在LVS層上加一個SSL加解密集羣。請求進LVS的443端口，以後被轉發到SSL集羣中進行解密，再回到LVS下接HAproxy的80端口，作七層負載均衡。這樣能夠收緊證書，也能夠將服務的入口統一，雖然在性能上可能會有很大的挑戰。負載均衡將來的發展可能將會是四層代理+ospf集羣模式，每一層都是代理。
3、總結
如今使用的負載均衡無外乎這幾種方式，或者幾種方式的組合。我相信不少大廠能用這種模式解決高併發高性能的問題，不少其餘服務也是沒有問題的。這篇文章只是負載均衡的基礎知識，並無涉及到太多的應用，LVS、HAproxy、Nginx等在使用中還有不少細節的區別，但都是以上模型。關於這三個軟件的負載均衡，若是之後使用到了會再討論。