以上結構是一般的分布式架構的組成,所有標記紅點的位置就是我們可以運用負載均衡的地方,顯然在使用者的請求和應用之間我們需要乙個反向**來實現負載均衡,這裡一般是七層負載均衡.還有一些地方只是需要簡單的修改ip來達到負載均衡,想象這樣乙個場景,就是所有的使用者對於乙個公司只是知道乙個ip,但是向這個ip發起請求顯然不會只落在乙個伺服器上,這裡就會出現修改ip,這裡我們不需要知道包的內容,這樣的過程一般稱為四層負載均衡.
這裡說的幾層是什麼意思呢?其實就是七層網路模型的數字,七層就是基於應用層的,四層基於傳輸層.
上面提到了四層和七層,這兩種負載均衡策略也是最為常見的兩種,一般的,也存在兩層負載均衡和三層負載均衡:二層負載均衡會通過乙個虛擬mac位址接收請求,然後再分配到真實的mac位址.三層負載均衡會通過乙個虛擬ip位址接收請求,然後再分配到真實的ip位址.
這裡值得一提的是一般來說四層負載均衡我們只需要建立一次tcp連線,而七層負載均衡需要建立兩次tcp連線.
四層負載均衡其實就是基於ip+埠的負載均衡,因為負載均衡器的ip是所謂的vip,即虛擬ip,也就是說在負載均衡器上我們需要修改ip和埠已達到負載均衡,這樣的話我們就不必建立連線,直接**syn報文即可,所以我們只需要做一次tcp連線,也就是負載均衡器只是起到了乙個**的作用,所有又被稱作四層交換機.
七層負載均衡需要我們對包的內容進行分析,所以要求使用者先於負載均衡器做連線,以保證負載均衡器能夠分析包的內容,根據其中的內容和內建的選擇策略為客戶端分配不同的伺服器,然後進行連線.這樣看來其實這在功能上類似於乙個反向**伺服器.顯然這相比於四層交換機對機器的要求更高.
這時我們平時所熟知的負載均衡演算法才派上了用場,諸如輪詢,加權輪詢,隨機等方法,顯然這些方法都運用在前面我們所說的負載均衡伺服器上,這樣看來就有了一種豁然開朗的感覺.那麼這些多種多樣的方法如何運用呢?這裡因為貧窮不談諸如f5的硬體負載均衡,就暫且說一說軟體.最經典的大概就是基於nginx的l7負載均衡:
這其實就是做乙個反向**伺服器.在nginx中我們就可以非常靈活,可以根據我們的需求去設定,在nginx中負載均衡策略的預設值是輪詢.
下面是一種更優的架構方式,確實在不考慮儲存(資料一致性)的情況下可以做到無限擴充套件,就是使用l4負載均衡器對平衡對nginx的請求,nginx負責正常的**:
負載均衡顯然是乙個大坑,說淺,每個人都知道輪詢,加權輪詢;說深,這涉及到太多安全和效能上的考慮,可以說有訪問的地方就有負載均衡存在.對於我們而言要學習到什麼境界呢?我的建議是先淺嘗輒止,知道技術原理,待用時再深入了解.學無止境,保持一顆上進與敬畏的心才可.
參考:
再識Nginx負載均衡與健康檢查
在業界，一直流傳這樣一句話 nginx抗併發能力強！為什麼nginx抗併發能力強？原因是使用了非阻塞 非同步傳輸 阻塞 如apache tomcat時，apache開啟10個程序，同時處理著10個請求，在tomcat沒有返回給apache結果時，apache是不會處理使用者發出的第11個請求 非阻塞...
再識今目標
認真的檢視了我的今目標使用情況，看到了我們一路走來的點點滴滴。發現我們已經使用今目標2年多了 2012.06.24開始 很驚訝！為什麼會這樣？乙個使用了2年多的工具 學習小助手應該更貼切些 到現在我還沒有將它融合到我們的生活中。或者說，沒有真正認識到它在我的學習歷程中地位。2年的成長，誰在為我們見證...
再識軟體測試
因為軟體的 不斷發展 維護數量不斷增長的軟體產品 軟體危機出現 軟體測試便出現了 軟體測試的更早執行 降低了開發成本 貫穿整個週期的軟體測試更能保證專案的完整性 軟體測試應由不同於開發者的另外第三方執行 在測試開始時 應有預期結果 如何根據問題去分析 測試應該注意排除隨意性 盡可能的保證測試的全面性...