大型網(wǎng)站--負(fù)載均衡架構(gòu)選型關(guān)注點(共9頁)

1、 HYPERLINK /and/p/3366400.html 大型(dxng)網(wǎng)站-負(fù)載(fzi)均衡架構(gòu)負(fù)載(fzi)均衡（Load Balancing） 負(fù)載均衡建立在現(xiàn)有網(wǎng)絡(luò)結(jié)構(gòu)之上，它提供了一種廉價有效透明的方法擴展網(wǎng)絡(luò)設(shè)備和服務(wù)器的帶寬、增加吞吐量、加強網(wǎng)絡(luò)數(shù)據(jù)處理能力、提高網(wǎng)絡(luò)的靈活性和可用性。大型網(wǎng)站負(fù)載均衡的利器全局負(fù)載均衡系統(tǒng)（GSLB）內(nèi)容緩存系統(tǒng)（CDN）服務(wù)器負(fù)載均衡系統(tǒng)（SLB）DNS域名解析的基本過程最初的負(fù)載均衡解決方案（DNS輪詢）優(yōu)點(yudin)基本上無成本，因為(yn wi)往往域名注冊(zhc)商的這種解析都是免費的；部署方便，除了網(wǎng)絡(luò)拓?fù)涞暮唵螖U增，新

2、增的Web服務(wù)器只要增加一個公網(wǎng)IP即可缺點健康檢查，如果某臺服務(wù)器宕機，DNS服務(wù)器是無法知曉的，仍舊會將訪問分配到此服務(wù)器。修改DNS記錄全部生效起碼要3-4小時，甚至更久；分配不均，如果幾臺Web服務(wù)器之間的配置不同，能夠承受的壓力也就不同，但是DNS解析分配的訪問卻是均勻分配的。用戶群的分配不均衡導(dǎo)致DNS解析的不均衡。會話保持，如果是需要身份驗證的網(wǎng)站，在不修改軟件構(gòu)架的情況下，這點是比較致命的，因為DNS解析無法將驗證用戶的訪問持久分配到同一服務(wù)器。雖然有一定的本地DNS緩存，但是很難保證在用戶訪問期間，本地DNS不過期，而重新查詢服務(wù)器并指向新的服務(wù)器，那么原服務(wù)器保存的用戶信息

3、是無法被帶到新服務(wù)器的，而且可能要求被重新認(rèn)證身份，來回切換時間長了各臺服務(wù)器都保存有用戶不同的信息，對服務(wù)器資源也是一種浪費。全局負(fù)載均衡(jnhng)系統(tǒng)（GSLB）優(yōu)勢(yush)數(shù)據(jù)中心冗余(rn y)備份多站點流量優(yōu)化確保用戶體驗全局負(fù)載均衡系統(tǒng)（GSLB）的原理DNS檢查工具網(wǎng)上有很多，感興趣的可以搜索一下。內(nèi)容緩存系統(tǒng)（CDN）內(nèi)容緩存系統(tǒng)（CDN）之靜態(tài)加速內(nèi)容(nirng)緩存系統(tǒng)（CDN）之動態(tài)(dngti)加速動態(tài)加速(ji s)的特點智能路由傳輸控制協(xié)議（TCP）優(yōu)化HTTP預(yù)載服務(wù)器負(fù)載均衡系統(tǒng)應(yīng)用背景訪問流量快速增長業(yè)務(wù)量不斷提高用戶需求希望獲得724的不間斷可用性

4、及較快的系統(tǒng)反應(yīng)時間負(fù)載均衡必須滿足性能、擴展、可靠性服務(wù)器負(fù)載均衡系統(tǒng)三種接入方式部署方式特點優(yōu)點缺點串聯(lián)路由模式比較常見的部署方式負(fù)載均衡設(shè)備將服務(wù)器有效隔離，安全考慮上最好服務(wù)器網(wǎng)關(guān)指向負(fù)載均衡設(shè)備, 功能實現(xiàn)更簡單，有利于最大化負(fù)載均衡性能服務(wù)器可以直接接收到真實訪問源客戶IP地址對現(xiàn)有拓?fù)浣Y(jié)構(gòu)變動較大需要考慮內(nèi)網(wǎng)服務(wù)器是否有對外訪問需求，必要時需要設(shè)置靜態(tài)NAT轉(zhuǎn)換單臂模式最常見的部署方式部署方便，對現(xiàn)有拓?fù)浣Y(jié)構(gòu)變動小和應(yīng)用無關(guān)的流量不會通過負(fù)載均衡設(shè)備內(nèi)部應(yīng)用無影響，外部應(yīng)用通常需要前端防火墻做NAT映射到應(yīng)用VIP服務(wù)器不能直接接收訪問客戶源地址，需要對應(yīng)用做修改后才可以通過其他

5、方式獲得真實訪問地址DSR服務(wù)器回程報文不通過負(fù)載均衡設(shè)備，直接返回給客戶端；延遲短，適合流媒體等對延時要求較高應(yīng)用性能高，可處理吞吐量高服務(wù)器可以直接接收到真實訪問源客戶IP地址只能做4層的負(fù)載均衡，基于7層的服務(wù)無法實現(xiàn)優(yōu)化(例如壓縮等)無法使用需要在服務(wù)器上配置loopback地址服務(wù)器負(fù)載均衡系統(tǒng)的常見調(diào)度算法輪詢（Round Robin）加權(quán)輪詢（Weighted Round Robin）最少連接(linji)（Least Connections）加權(quán)最少連接(linji)（Weighted Least Connections）健康(jinkng)性檢查健康性檢查算法的目的：通過某種

6、探針機制，檢查服務(wù)器群中真實服務(wù)器的健康情況，避免把客戶端的請求分發(fā)給出現(xiàn)故障的服務(wù)器，以提高業(yè)務(wù)的HA能力。目前常用的健康性檢查算法：Ping（ICMP）TCPHTTPFTP系統(tǒng)加速優(yōu)化功能-SSL加速優(yōu)化功能-HTTP壓縮HTTP壓縮(y su)是在Web服務(wù)器和瀏覽器間傳輸壓縮文本內(nèi)容(nirng)的方法。F5 HTTP HYPERLINK /search?word=%E5%8E%8B%E7%BC%A9%E6%8A%80%E6%9C%AF&fr=qb_search_exp&ie=utf8 t _blank 壓縮(y su)技術(shù)通過具有智能壓縮能力的 BIG-IP 系統(tǒng)可縮短 HYPERL

7、INK /search?word=%E5%BA%94%E7%94%A8%E4%BA%A4%E4%BB%98&fr=qb_search_exp&ie=utf8 t _blank 應(yīng)用交付時間并優(yōu)化帶寬。HTTP壓縮采用通用的壓縮算法壓縮HTML、JavaScript或CSS文件。壓縮的最大好處就是降低了網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量，從而提高客戶端瀏覽器的訪問速度。優(yōu)化功能-連接復(fù)用優(yōu)化功能-TCP緩存會話(huhu)保持會話(huhu)保持-客戶端源IP會話(huhu)保持源IP地址會話保持就是將同一個源IP地址的連接或者請求認(rèn)為是同一個用戶，根據(jù)會話保持策略，在會話保持有效期內(nèi)，將這些發(fā)自同一個源IP地址

8、的連接/請求都轉(zhuǎn)發(fā)到同一臺服務(wù)器。會話保持-Cookie會話保持當(dāng)采用基于源地址的會話保持無法做到負(fù)載均分時，例如客戶端發(fā)起連接請求的源IP地址相對固定，發(fā)生此類問題通?？刹捎没趹?yīng)用層的會話保持方式，Cookie通常是存在于HTTP頭中，現(xiàn)如今基于HTTP的應(yīng)用被廣泛使用，因此基于Cookie的會話保持越來越多的出現(xiàn)在服務(wù)器負(fù)載均衡解決方案中。局限性：對于非HTTP協(xié)議，或者客戶端禁用Cookie，無效。會話保持-URL哈希（Hash）會話保持哈希會話保持的一個基本概念就是按照某個Hash因子，根據(jù)此因子以及后臺存在多少臺服務(wù)器計算得到的結(jié)果來選擇將請求分配到那臺服務(wù)器。哈希會話保持的特點是

9、在后臺服務(wù)器的健康狀態(tài)不發(fā)生改變的時候，每個特定的Hash因子被分配到的服務(wù)器是固定的。其最大的優(yōu)勢是哈希會話保持可以沒有會話保持表，而僅僅是根據(jù)計算的結(jié)果來確定被分配到那臺服務(wù)器，尤其在一些會話保持表查詢的開銷已經(jīng)遠(yuǎn)遠(yuǎn)大于Hash計算開銷的情況下，采用Hash會話保持可以提高系統(tǒng)的處理能力和響應(yīng)速度。URL哈希會話保持通常針對后臺采用Cache服務(wù)器的應(yīng)用場景，針對URL進行Hash計算，將同一個URL的請求分配到同一臺Cache服務(wù)器，這樣，對后臺的Cache服務(wù)器群來說，每臺Cache服務(wù)器上存放的內(nèi)容都是不一樣的，提高Cache服務(wù)器的利用率。故障(gzhng)案例分析Q&A案例(n

10、l)分析（1）-循環(huán)(xnhun)跳轉(zhuǎn)故障現(xiàn)象：Web服務(wù)端對用戶訪問的URL進行判斷，對于非https的請求，重定向到http站點，結(jié)果導(dǎo)致用戶一直302跳轉(zhuǎn)。原因分析：采用了負(fù)載均衡SSL加速功能，在服務(wù)端看到所有的用戶請求都來自于http。解決方案：全站啟用SSL加速。Q&A案例分析（2）-用戶Session丟失故障現(xiàn)象：用戶在http站點上提交數(shù)據(jù)到同域名的https站點，web程序拋出session丟失的異常，用戶提交數(shù)據(jù)失敗。原因分析：http和https在負(fù)載均衡設(shè)備上被認(rèn)為是2個獨立的服務(wù)，產(chǎn)生2個獨立的TCP鏈接，會命中不同的真實服務(wù)器，導(dǎo)致session丟失。解決方案：在負(fù)

11、載均衡設(shè)備上啟用基于真實服務(wù)器的會話保持。Q&A案例(n l)分析（3）-客戶端源IP取不到(b do)故障(gzhng)現(xiàn)象：服務(wù)端獲取不到用戶外網(wǎng)的IP地址，看到的都是大量來自于內(nèi)網(wǎng)特定網(wǎng)段的IP地址。原因分析：負(fù)載均衡設(shè)備啟用了用戶源地址轉(zhuǎn)換（SNAT）模式，修改了TCP報文中的用戶源IP。解決方案： 負(fù)載均衡設(shè)備會用用戶的外網(wǎng)IP改寫x-forwarded-for值，服務(wù)端通過獲取http協(xié)議中request header頭的x-forwarded-for值作為用戶源IP。IIS日志通過安裝插件形式顯示用戶源IP。服務(wù)器負(fù)載均衡設(shè)備選型1.價格因素 硬件設(shè)備：F5、 Citrix 、R

12、edware 、A10 軟件：LVS、Nginx、Haproxy、zen loadbalance2.性能 4/7層吞吐量(單位bps) 4/7層新建連接數(shù)（單位CPS） 并發(fā)連接數(shù) 功能模塊性能指標(biāo)（ssl加速、 HTTP壓縮、內(nèi)存Cache）3.滿足真實和未來需求 1）如果確認(rèn)負(fù)載均衡設(shè)備對所有應(yīng)用的處理都是最簡單的4層處理，那么理論上選擇的負(fù)載均衡設(shè)備的4層性能稍高于實際性能需求即可。 2）如果確認(rèn)負(fù)載均衡設(shè)備對所有應(yīng)用的處理都是簡單的7層處理，那么理論上選擇的負(fù)載均衡設(shè)備的7層性能稍高于實際性能需求即可。 3）如果負(fù)載均衡設(shè)備處理的應(yīng)用既有4層的也有7層的，建議按照7層應(yīng)用的性能來考慮負(fù)載均衡設(shè)備。 4）如果確認(rèn)自己的應(yīng)用經(jīng)過負(fù)載均衡處理時，需要復(fù)雜的4層或者7層處理，例如需要根據(jù)客戶端的地址做策略性分發(fā)，需要根據(jù)tcp的內(nèi)容做處理，需要根據(jù)HTTP頭或者HTTP報文做處理，那么建議選擇的負(fù)載均衡設(shè)備4/7層性能為真實性能需求的兩倍。 5）如果負(fù)載均衡設(shè)備有混合的復(fù)雜流量處理并且還開啟了一些功能模塊，那么建議選擇的負(fù)載均衡設(shè)備4/7層性能為真實性能需求的3倍。 6）考慮到設(shè)備需要輕載運行才能更加穩(wěn)定，所以有可能的話在以上基礎(chǔ)上再增加30%的性能。 7）如果還要滿足未來幾年的發(fā)展需求，在以上基礎(chǔ)上還要留出未來發(fā)展所需要增加的性能。 8）不同負(fù)載均衡設(shè)備廠家由于不