負載均衡，就是將請求分發到不同服務器上去響應，讓每個服務器的負載達到均衡的狀態。現在負載均衡是每個在線應用不可缺少的環節，所以我們需要了解一下負載均衡的模型和類型，當然在實際解決問題時模型會變的很復雜。本文只討論軟件方案，並不涉及硬件。文末會有一點點小干貨，是我在新浪課堂上聽的一點知識，關於新浪負載均衡的演進和使用。
一、負載均衡
負載均衡的目的就是讓請求到達不同的服務器上。一次請求到服務器之間，有那么多環節，因此可以實現的方法有很多種，實際應用中不外乎以下幾種方式。
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方式的鏈路層負載均衡是目前大型網站使用最廣的一種負載均衡手段。
二、關於負載均衡演進
一個應用的流量從多到少，負載均衡的演進基本都是一個套路，新浪也不例外（以下內容有修改），大致打演進過程如下：
- nginx做反向代理的同時也做七層負載均衡。
- 使用四層的代理負載均衡，並使用主備，一般使用HAproxy或者LVS
- 使用單臂模式加七層代理集群，一般是LVS（DR模式）主備+HAproxy集群（七層負載均衡）
Nginx 做負載均衡是非常方便的，如果一個機器滿足不了需求了，可以直接做一個反向代理加上負載均衡。四層的代理負載均衡比七層負載均衡性能好很多，集群規模可以迅速擴大，並且可以細分服務。當公司的規模很大的時候，有多個機房、多個大型服務時，LVS（單臂）+HAproxy（七層）就更適合了，如下圖所示（網上盜了一張圖）：
最近我聽了一節新浪有關負載均衡的講座，其實是一個簡短的課程。新浪的演進過程和上面三個步驟很像，沒有太多的差異。目前大多數服務正在使用2和3的模式，將來需要全量SSL加密，所以新浪准備在LVS層上加一個SSL加解密集群。請求進LVS的443端口，之后被轉發到SSL集群中進行解密，再回到LVS下接HAproxy的80端口，做七層負載均衡。這樣可以收緊證書，也可以將服務的入口統一，雖然在性能上可能會有很大的挑戰。負載均衡未來的發展可能將會是四層代理+ospf集群模式，每一層都是代理。
三、總結
現在使用的負載均衡無外乎這幾種方式，或者幾種方式的組合。我相信很多大廠能用這種模式解決高並發高性能的問題，很多其他服務也是沒有問題的。這篇文章只是負載均衡的基礎知識，並沒有涉及到太多的應用，LVS、HAproxy、Nginx等在使用中還有很多細節的區別，但都是以上模型。關於這三個軟件的負載均衡，如果以后使用到了會再討論。
轉載自：https://caoyi.me/load-balancing/