Linux中級之負載均衡（lvs,nginx,haproxy）、中間件

1、負載均衡的概念

1、系統的擴展方式：

       scale up：向上擴展

       scale out：向外擴展

2、集羣類型：  LB（Load Balancing）、HA（high availability）

3、LB集羣的實現

              硬件：F5、Redware

              軟件：lvs、haproxy、nginx

4、基於工做的協議層劃分：

       傳輸層：

       Lvs：工做在內核模塊中

       HAProxy：

1.mode tcp，若是工做在應用層只能調度http協議，若是基於tcp協議它可以調度https，mysql等經常使用的tcp協議

2.haproxy只是模擬tcp協議，由於tcp協議工做在內核當中，而haproxy屬於應用程序工做在第七層，是工做在某個套接字上的應用程序

應用層：haproxy，nginx

從負載均衡設備的角度來看，分爲硬件負載均衡和軟件負載均衡：

硬件負載均衡：好比最多見的F5，還有Array等，這些負載均衡是商業的負載均衡器，性能比較好，畢竟他們的就是爲了負載均衡而生的，背後也有很是成熟的團隊，能夠提供各類解決方案，可是價格比較昂貴，因此沒有充足的理由，充足的軟妹幣是不會考慮的。

軟件負載均衡：包括咱們耳熟能詳的Nginx，LVS，Tengine（阿里對Nginx進行的改造）等。優勢就是成本比較低，可是也須要有比較專業的團隊去維護，要本身去踩坑，去DIY。

從負載均衡的技術來看，分爲服務端負載均衡和客戶端負載均衡：

服務端負載均衡：當咱們訪問一個服務，請求會先到另一臺服務器，而後這臺服務器會把請求分發到提供這個服務的服務器，固然若是隻有一臺服務器，那好說，直接把請求給那一臺服務器就能夠了，可是若是有多臺服務器呢？這時候，就會根據必定的算法選擇一臺服務器。

客戶端負載均衡：客戶端服務均衡的概念貌似是有了服務治理才產生的，簡單的來講，就是在一臺服務器上維護着全部服務的ip，名稱等信息，當咱們在代碼中訪問一個服務，是經過一個組件訪問的，這個組件會從那臺服務器上取到全部提供這個服務的服務器的信息，而後經過必定的算法，選擇一臺服務器進行請求。

2、三大主流軟件負載均衡器對比(LVS、Nginx、HAproxy)

1、LVS：

1. 抗負載能力強，性能高，能達到F5的60%，對內存和CPU資源消耗比較低

2. 工做在網絡4層，經過VRRP協議(僅做代理分發之用)，具體的流量是由linux內核來處理，所以沒有流量的產生。

3. 穩定，可靠性高，自身有完美的熱備方案(Keepalived+lvs)

4. 不支持正則處理，不能作動靜分離；但應用範圍比較廣，能夠對全部應用作負載均衡

5. 支持多種負載均衡算法：rr(輪詢)，wrr(帶權輪詢)、lc(最小鏈接)、wlc(帶權最小鏈接)

6. 配置相對複雜，對網絡依賴比較大，穩定性很高。

7. LVS工做模式有4種：

(1) nat 地址轉換

(2) dr 直接路由

(3) tun 隧道

(4) full-nat

2、Nginx：

1. 工做在網絡7層，能夠針對http應用作一些分流的策略，好比針對域名，目錄結構

2. Nginx對網絡的依賴較小，理論上能ping通就能進行負載功能

3. Nginx安裝配置比較簡單，測試起來很方便

4. 也能夠承擔較高的負載壓力且穩定，nginx是爲解決c10k問題而誕生的，通常能支撐超過1萬次的併發

5. 對後端服務器的健康檢查，只支持經過端口來檢測，不支持經過url來檢測

6. Nginx對請求的異步處理能夠幫助節點服務器減輕負載壓力

7. Nginx僅能支持http、https和Email協議，這樣就在適用範圍較小。

8. 不支持Session的直接保持，但能經過ip_hash來解決。對Big request header的支持不是很好。

9. Nginx還能作Web服務器即Cache功能。

10. 支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、Ip-hash（IP哈希）

第6點補充：

squid同步處理：瀏覽器發起請求，然後請求會馬上被轉到後端，因而在瀏覽器和後臺之間就創建了一個通道。從請求發起直到請求完成，這條通道都是一直存在的。

nginx異步處理：瀏覽器發起請求，請求不會馬上轉到後端，而是請求數據(header)先收到nignx上，而後nginx再把這個請求發到後端，後端處理完成後把數據返回到nginx上，nginx將數據流發到瀏覽器。

使用異步處理的好處：

1. 假設用戶執行一個上傳文件操做，由於用戶網速又比較慢，所以須要花半個小時才能把文件傳到服務器。squid的同步代理在用戶開始上傳後就和後臺創建了鏈接，半小時後文件上傳結束，因而可知，後臺服務器鏈接保持了半個小時；而nginx異步代理就是先將此文件收到nginx上，所以僅僅是nginx和用戶保持了半小時鏈接，後臺服務器在這半小時內沒有爲這個請求開啓鏈接，半小時後用戶上傳結束，nginx纔將上傳內容發到後臺，nginx和後臺之間的帶寬是很充裕的，因此只花了一秒鐘就將請求發送到了後臺，因而可知，後臺服務器鏈接保持了一秒。同步傳輸花了後臺服務器半個小時，異步傳輸只花一秒，可見優化程度很大。

2. 在上面這個例子中，假如後臺服務器由於種種緣由重啓了，上傳文件就天然中斷了，這對用戶來講是很是惱火的一件事情，想必各位也有上傳文件傳到一半被中斷的經歷。用nginx代理以後，後臺服務器的重啓對用戶上傳的影響減小到了極點，而nginx是很是穩定的並不須要常去重啓它，即便須要重啓，利用kill -HUP就能夠作到不間斷重啓nginx。

3. 異步傳輸能夠令負載均衡器更有保障，爲何這麼說呢？在其它的均衡器（lvs/haproxy/apache等）裏，每一個請求都是隻有一次機會的，假如用戶發起一個請求，結果該請求分到的後臺服務器恰好掛掉了，那麼這個請求就失敗了；而nginx由於是異步的，因此這個請求能夠從新發往下一個後臺，下一個 後臺返回了正常的數據，因而這個請求就能成功了。仍是用用戶上傳文件這個例子，假如不但用了nginx代理，並且用了負載均衡，nginx把上傳文件發往 其中一臺後臺，但這臺服務器忽然重啓了，nginx收到錯誤後，會將這個上傳文件發到另外一臺後臺，因而用戶就不用再花半小時上傳一遍。

4. 假如用戶上傳一個10GB大小的文件，然後臺服務器沒有考慮到這個狀況，那麼後臺服務器豈不要崩潰了。用nginx就能夠把這些東西都攔在nginx上，經過nginx的上傳文件大小限制功能來限制，另外nginx性能很是有保障，就放心的讓互聯網上那些另類的用戶和nginx對抗去吧。

用異步傳輸會形成問題：

後臺服務器有提供上傳進度的功能的話，用了nginx代理就沒法取得進度，這個須要使用nginx的一個第三方模塊來實現。

第8點補充：

Nginx upstream支持的分配策略及原理：

1. 輪詢(默認)：每一個請求按照順序逐一分配到不一樣的後端服務器。如後端服務器down掉，就切換到另外一臺並剔除down的後端主機

2. weight：指定輪詢概率，weight和訪問比率成正比，用於後端服務器性能不均的狀況。

3. ip_hash：每一個請求按照訪問ip的hash結果分配，不一樣ip的請求被分配到後端不一樣的服務器上，能夠解決session的問題。

3、HAProxy:

1. 支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機；

2. 可以補充Nginx的一些缺點好比Session的保持，Cookie的引導等工做

3. 支持url檢測後端的服務器出問題的檢測會有很好的幫助。

4. 更多的負載均衡策略好比：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現

5. 單純從效率上來說HAProxy更會比Nginx有更出色的負載均衡速度。

6. HAProxy能夠對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。

7. 支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie）

8. 不能作Web服務器即Cache。

三大主流軟件負載均衡器適用業務場景：

1. 網站建設初期，能夠選用Nginx、HAProxy做爲反向代理負載均衡(流量不大時，能夠不選用負載均衡)，由於其配置簡單，性能也能知足通常業務場景。若是考慮到負載均衡器是有單點問題，能夠採用Nginx+Keepalived/HAproxy+Keepalived避免負載均衡器自身的單點問題。

2. 網站併發到達必定程度後，爲了提升穩定性和轉發效率，可使用lvs，畢竟lvs比Nginx/HAProxy要更穩定，轉發效率也更高。

注：nginx與HAProxy比較：nginx只支持七層，用戶量最大，穩定性比較可靠。Haproxy支持四層和七層，支持更多的負載均衡算法，支持session等。

衡量負載均衡器好壞的幾個重要的因素：

1. 會話率 ：單位時間內的處理的請求數

2. 會話併發能力：併發處理能力

3. 數據率：處理數據能力

3、中間件

中間件是在操做系統功能範圍外爲應用提供服務的多用途軟件。任何位於內核和用戶應用之間的軟件均可以是中間件。中間件不提供傳統應用的功能，而是將軟件與其餘軟件銜接。因爲中間件可以讓數據從一個應用流動到另外一箇中，所以把它比做輸水管最爲貼切。

中間件就是程序中可織入的，可重用的，與業務邏輯無關的各類組件。

中間件(middleware)是基礎軟件的一大類，屬於可複用軟件的範疇。

顧名思義，中間件處於操做系統軟件與用戶的應用軟件的中間。

中間件在操做系統、網絡和數據庫之上， 應用軟件的下層，總的做用是爲處於本身上層的應用軟件提供運行與開發的環境，幫助用戶靈活、高效地開發和集成複雜的應用軟件。

在衆多關於中間件的定義中，比較廣泛被接受的是 IDC 表述的：中間件是一種獨立的系統軟件或服務程序，分佈式應用軟件藉助這種軟件在不一樣的技術之間共享資源，中間件位於客戶機服務器的操做系統之上，管理計算資源和網絡通訊。

分類：數據訪問中間件，遠程調用中間件，消息中間件，交易中間件，對象中間件。

舉例：

1. RMI (Remote Method Invocations, 遠程調用)

2. Load Balancing(負載均衡，將訪問負荷分散到各個服務器中)

3. Transparent Fail-over(透明的故障切換)

4. Clustering(集羣 , 用多個小的服務器代替大型機)

5. Back-end-Integration(後端集成，用現有的、新開發的系統如何去集成遺留的系統)

6. T ransaction 事務(全局 / 局部)全局事務(分佈式事務)局部事務(在同一數據庫聯 接內的事務)

7. Dynamic Redeployment (動態從新部署 , 在不中止原系統的狀況下，部署新的系統)

8. System Management(系統管理)

9. Threading(多線程處理)

10. Message-oriented Middleware 面向消息的中間件(異步的調用編程)

11. Component Life Cycle(組件的生命週期管理)

12. Resource pooling (資源池)

13. Security (安全)

14. Caching (緩存)

4、cookie和session

        一、Cookie是服務器存儲在本地計算機上的小塊文本，並隨每一個請求發送到同一服務器。 IETF RFC 2965 HTTP狀態管理機制是一種通用的cookie規範。 Web服務器使用HTTP標頭將cookie發送到客戶端。在客戶端終端，瀏覽器解析cookie並將其保存爲本地文件，該文件自動未來自同一服務器的任何請求綁定到這些cookie。

        具體來講，cookie機制使用一種在客戶端維護狀態的方案。它是客戶端會話狀態的存儲機制，他須要用戶打開客戶端的cookie支持。 Cookie的做用是解決HTTP協議中缺乏無狀態缺陷的問題。

        二、session會話機制是一種服務器端機制，它使用相似於哈希表（可能還有哈希表）的結構來保存信息。

        當程序須要爲客戶端的請求建立會話時，服務器首先檢查客戶端的請求是否包含會話標識符（稱爲會話ID）。若是包含它，它先前已爲此客戶端建立了一個會話。服務器根據會話ID檢索會話（沒法檢索，將建立新會話），若是客戶端請求不包含會話ID，則爲客戶端建立會話並生成與會話關聯的會話ID。 session id應該是一個既不重複也不容易被複制的字符串。會話ID將返回給客戶端以保存此響應。

        三、Session是保存在服務器上的數據結構，用於跟蹤用戶的狀態。此數據能夠保存在羣集、數據庫、文件中。

        Cookie是客戶端存儲用戶信息的機制。它用於記錄有關用戶的一些信息，是實現會話的一種方式。