第一篇：軟件開發(fā)報告

負載均衡器軟件

開發(fā)報告

院系： 班級： 成員：

目錄

1.可行性分析報告..........................................................................................................................1 1.1 項目背景..............................................................................................................................1 1.2產(chǎn)品分析...............................................................................................................................1 1.3 結(jié)論意見..............................................................................................................................2 2.項目開發(fā)計劃..............................................................................................................................2 2.1 總體功能要求......................................................................................................................2 2.2 軟件開發(fā)平臺要求..............................................................................................................2 2.3 軟件項目的開發(fā)實施過程管理要求...................................................................................2 3.軟件開發(fā)......................................................................................................................................2 3.1 軟件的需求分析..............................................................................................................3 3.3軟件的詳細設(shè)計...................................................................................................................4 3.4 軟件的編碼..........................................................................................................................5 3.5軟件的測試.........................................................................................................................31 3.5.1測試計劃.....................................................................................................................31 3.5.2 軟件測試....................................................................................................................31 4.項目開發(fā)總結(jié)報告....................................................................................................................32

I

1.可行性分析報告

1.1 項目背景

面對龐大的數(shù)據(jù)流量，面對集中性的訪問，是不是覺得網(wǎng)絡(luò)服務(wù)器岌岌可危呢?不用怕，負載均衡器就能幫你緩解這個問題。負載均衡器通過虛擬IP地址方法，解決了輪流排程所面臨的許多問題。使用了負載均衡器集群系統(tǒng)，在外部看來，像是具有一個IP地址的單一服務(wù)器一樣，當然，這個IP地址是虛擬的，它映射了集群中的每一臺機器的地址。所以，在某種程度上，負載均衡器是將整個集群的IP地址報漏給外部網(wǎng)絡(luò)。

當請求到達負載均衡器時，它會重寫該請求的頭文件，并將之指定到集群中的機器上。如果某臺機器被從集群中移除了，請求不會別發(fā)往已經(jīng)不存在的服務(wù)器上，因為所有的機器表面上都具有同一個IP地址，即使集群中的某個節(jié)點被移除了，該地址也不會發(fā)生變化。而且，internet上緩存的DNS條目也不再是問題了。當返回一個應(yīng)答時，客戶端看到的只是從負載均衡器上所返回的結(jié)果。也就是說，客戶端操作的對象是負載均衡器，對于其更后端的操作，對客戶端來講，是完全透明的。

1.2產(chǎn)品分析

服務(wù)器一致性負載均衡器讀取客戶端發(fā)出的每一個請求中所包含的cookies或url解釋?；谒x出的這些信息，負載均衡器就可以重寫報頭并將請求發(fā)往集群中合適的節(jié)點上，該節(jié)點維護著相應(yīng)客戶端請求的會話信息。在HTTP通信中，負載均衡器可以提供服務(wù)器一致性，但并不是通過一個安全的途徑（例如：HTTPS）來提供這種服務(wù)。當消息被加密后（SSL），負載均衡器就不能讀出隱藏在其中的會話信息。

通過故障恢復(fù)機制獲得高可靠性故障恢復(fù)發(fā)生在當集群中某個節(jié)點不能處理請求，需將請求重新導(dǎo)向到其他節(jié)點時。主要有兩種故障恢復(fù)：

請求級故障恢復(fù)。當集群中的一個節(jié)點不能處理請求時（通常是由于down機），請求被發(fā)送到其他節(jié)點。當然，在導(dǎo)向到其他節(jié)點的同時，保存在原節(jié)點上的會話信息將會丟失。

透明會話故障恢復(fù)。當一個引用失敗后，負載均衡器會將之發(fā)送到集群中其他的節(jié)點上，以完成操作，這一點對用戶來說是透明的。由于透明會話故障恢復(fù)需要節(jié)點具備相應(yīng)的操作信息，因此為了實現(xiàn)該功能，集群中的所有節(jié)點必須具有公共存儲區(qū)域或通用數(shù)據(jù)庫，存儲會話信息數(shù)據(jù)，以提供每個節(jié)點在進行單獨進程會話故障恢復(fù)時所需要的操作信息。

既然所有的Web應(yīng)用請求都必須經(jīng)過負載均衡系統(tǒng)，那么系統(tǒng)就可以確定活動會話的數(shù)量，在任何實例訪問中的活動會話的數(shù)目，應(yīng)答的次數(shù)，高峰負載

次數(shù)，以及在高峰期和低谷期的會話的數(shù)目，還有其他更多的。所有的這些統(tǒng)計信息都可以被很好的用來調(diào)整整個系統(tǒng)的性能。

1.3 結(jié)論意見

雖然此項目存在一定的技術(shù)難度和風險，但我們對項目要達到的目標十分清楚，對所要開發(fā)系統(tǒng)將要實現(xiàn)的功能也非常了解。而且有一些成品作為參考，并且在項目的實施過程中我們能夠獲得幫助，我認為只要我們能夠認真思考、仔細規(guī)劃、明確分工，我們可以承擔此項目的開發(fā)。

2.項目開發(fā)計劃

2.1 總體功能要求

1.擴展網(wǎng)絡(luò)設(shè)備和服務(wù)器的帶寬 2.增加吞吐量

3.加強網(wǎng)絡(luò)數(shù)據(jù)處理能力 4.提高網(wǎng)絡(luò)的靈活性和可用性

2.2 軟件開發(fā)平臺要求

Visual c++ 6.0 SQL Server 2008 C++ Builder 網(wǎng)絡(luò)架構(gòu)：

完全支持TCP/IP協(xié)議

2.3 軟件項目的開發(fā)實施過程管理要求

3.軟件開發(fā)

3.1 軟件的需求分析

1．DNS負載均衡最早的負載均衡技術(shù)是通過DNS來實現(xiàn)的，在DNS中為多個地址配置同一個名字，因而查詢這個名字的客戶機將得到其中一個地址，從而使得不同的客戶訪問不同的服務(wù)器，達到負載均衡的目的。DNS負載均衡是一種簡單而有效的方法，但是它不能區(qū)分服務(wù)器的差異，也不能反映服務(wù)器的當前運行狀態(tài)。

2．代理服務(wù)器負載均衡 使用代理服務(wù)器，可以將請求轉(zhuǎn)發(fā)給內(nèi)部的服務(wù)器，使用這種加速模式顯然可以提升靜態(tài)網(wǎng)頁的訪問速度。然而，也可以考慮這樣一種技術(shù)，使用代理服務(wù)器將請求均勻轉(zhuǎn)發(fā)給多臺服務(wù)器，從而達到負載均衡的目的。

3．地址轉(zhuǎn)換網(wǎng)關(guān)負載均衡 支持負載均衡的地址轉(zhuǎn)換網(wǎng)關(guān)，可以將一個外部IP地址映射為多個內(nèi)部IP地址，對每次TCP連接請求動態(tài)使用其中一個內(nèi)部地址，達到負載均衡的目的。

4．協(xié)議內(nèi)部支持負載均衡除了這三種負載均衡方式之外，有的協(xié)議內(nèi)部支持與負載均衡相關(guān)的功能，例如HTTP協(xié)議中的重定向能力等，HTTP運行于TCP連接的最高層。

5．NAT負載均衡NAT簡單地說就是將一個IP地址轉(zhuǎn)換為另一個IP地址，一般用于未經(jīng)注冊的內(nèi)部地址與合法的、已獲注冊的Internet IP地址間進行轉(zhuǎn)換。適用于解決Internet IP地址緊張、不想讓網(wǎng)絡(luò)外部知道內(nèi)部網(wǎng)絡(luò)結(jié)構(gòu)等的場合下。

6．反向代理負載均衡普通代理方式是代理內(nèi)部網(wǎng)絡(luò)用戶訪問internet上服務(wù)器的連接請求，客戶端必須指定代理服務(wù)器，并將本來要直接發(fā)送到internet上服務(wù)器的連接請求發(fā)送給代理服務(wù)器處理。反向代理（Reverse Proxy）方式是指以代理服務(wù)器來接受internet上的連接請求，然后將請求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給internet上請求連接的客戶端，此時代理服務(wù)器對外就表現(xiàn)為一個服務(wù)器。反向代理負載均衡技術(shù)是把將來自internet上的連接請求以反向代理的方式動態(tài)地轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的多臺服務(wù)器進行處理，從而達到負載均衡的目的。

7．混合型負載均衡在有些大型網(wǎng)絡(luò)，由于多個服務(wù)器群內(nèi)硬件設(shè)備、各自的規(guī)模、提供的服務(wù)等的差異，可以考慮給每個服務(wù)器群采用最合適的負載均衡方式，然后又在這多個服務(wù)器群間再一次負載均衡或群集起來以一個整體向外界提供服務(wù)（即把這多個服務(wù)器群當做一個新的服務(wù)器群），從而達到最佳的性能。將這種方式稱之為混合型負載均衡。此種方式有時也用于單臺均衡設(shè)備的性能不能滿足大量連接請求的情況下。

3.2軟件的概要設(shè)計

軟件負載均衡解決方案是指在一臺或多臺服務(wù)器相應(yīng)的操作系統(tǒng)上安裝一

個或多個附加軟件來實現(xiàn)負載均衡，DNSLoadBalanceCheckPointFirewall-1 ConnectControl等，它的優(yōu)點是基于特定環(huán)境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。硬件負載均衡解決方案是直接在服務(wù)器和外部網(wǎng)絡(luò)間安裝負載均衡設(shè)備，這種設(shè)備通常稱之為負載均衡器，由于專門的設(shè)備完成專門的任務(wù)，獨立于操作系統(tǒng)，整體性能得到大量提高，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。

一般而言，硬件負載均衡在功能、性能上優(yōu)于軟件方式，不過成本昂貴。本地負載均衡能有效地解決數(shù)據(jù)流量過大、網(wǎng)絡(luò)負荷過重的問題，并且不需花費昂貴開支購置性能卓越的服務(wù)器，充分利用現(xiàn)有設(shè)備，避免服務(wù)器單點故障造成數(shù)據(jù)流量的損失。其有靈活多樣的均衡策略把數(shù)據(jù)流量合理地分配給服務(wù)器群內(nèi)的服務(wù)器共同負擔。即使是再給現(xiàn)有服務(wù)器擴充升級，也只是簡單地增加一個新的服務(wù)器到服務(wù)群中，而不需改變現(xiàn)有網(wǎng)絡(luò)結(jié)構(gòu)、停止現(xiàn)有的服務(wù)。

全局負載均衡主要用于在一個多區(qū)域擁有自己服務(wù)器的站點，為了使全球用戶只以一個IP地址或域名就能訪問到離自己最近的服務(wù)器，從而獲得最快的訪問速度，也可用于子公司分散站點分布廣的大公司通過企業(yè)內(nèi)部互聯(lián)網(wǎng)來達到資源統(tǒng)一合理分配的目的。

3.3軟件的詳細設(shè)計

1.輪轉(zhuǎn)法：輪轉(zhuǎn)算法是所有調(diào)度算法中最簡單也最容易實現(xiàn)的一種方法。在一個任務(wù)隊列里，隊列的每個成員（節(jié)點）都具有相同的地位，輪轉(zhuǎn)法簡單的在這組成員中順序輪轉(zhuǎn)選擇。在負載平衡環(huán)境中，均衡器將新的請求輪流發(fā)給節(jié)點隊列中的下一節(jié)點，如此連續(xù)、周而復(fù)始，每個集群的節(jié)點都在相等的地位下被輪流選擇。這個算法在DNS域名輪詢中被廣泛使用。

輪轉(zhuǎn)法的活動是可預(yù)知的，每個節(jié)點被選擇的機會是1/N，因此很容易計算出節(jié)點的負載分布。輪轉(zhuǎn)法典型的適用于集群中所有節(jié)點的處理能力和性能均相同的情況，在實際應(yīng)用中，一般將它與其他簡單方法聯(lián)合使用時比較有效。

2.散列法：散列法也叫哈希法（HASH），通過單射不可逆的HASH函數(shù)，按照某種規(guī)則將網(wǎng)絡(luò)請求發(fā)往集群節(jié)點。哈希法在其他幾類平衡算法不是很有效時會顯示出特別的威力。例如，在前面提到的UDP會話的情況下，由于輪轉(zhuǎn)法和其他幾類基于連接信息的算法，無法識別出會話的起止標記，會引起應(yīng)用混亂。

而采取基于數(shù)據(jù)包源地址的哈希映射可以在一定程度上解決這個問題：將具有相同源地址的數(shù)據(jù)包發(fā)給同一服務(wù)器節(jié)點，這使得基于高層會話的事務(wù)可以以適當?shù)姆绞竭\行。相對稱的是，基于目的地址的哈希調(diào)度算法可以用在Web Cache集群中，指向同一個目標站點的訪問請求都被負載平衡器發(fā)送到同一個Cache服務(wù)節(jié)點上，以避免頁面缺失而帶來的更新Cache問題。

3.最少連接法：在最少連接法中，平衡器紀錄目前所有活躍連接，把下一個新的請求發(fā)給當前含有最少連接數(shù)的節(jié)點。這種算法針對TCP連接進行，但由于

不同應(yīng)用對系統(tǒng)資源的消耗可能差異很大，而連接數(shù)無法反映出真實的應(yīng)用負載，因此在使用重型Web服務(wù)器作為集群節(jié)點服務(wù)時（例如Apache服務(wù)器），該算法在平衡負載的效果上要打個折扣。為了減少這個不利的影響，可以對每個節(jié)點設(shè)置最大的連接數(shù)上限（通過閾值設(shè)定體現(xiàn)）。

4.最低缺失法：在最低缺失法中，平衡器長期紀錄到各節(jié)點的請求情況，把下個請求發(fā)給歷史上處理請求最少的節(jié)點。與最少連接法不同的是，最低缺失記錄過去的連接數(shù)而不是當前的連接數(shù)。

5.最快響應(yīng)法：平衡器記錄自身到每一個集群節(jié)點的網(wǎng)絡(luò)響應(yīng)時間，并將下一個到達的連接請求分配給響應(yīng)時間最短的節(jié)點，這種方法要求使用ICMP包或基于UDP包的專用技術(shù)來主動探測各節(jié)點。

在大多數(shù)基于LAN的集群中，最快響應(yīng)算法工作的并不是很好，因為LAN中的ICMP包基本上都在10ms內(nèi)完成回應(yīng)，體現(xiàn)不出節(jié)點之間的差異；如果在 WAN上進行平衡的話，響應(yīng)時間對于用戶就近選擇服務(wù)器而言還是具有現(xiàn)實意義的；而且集群的拓撲越分散這種方法越能體現(xiàn)出效果來。這種方法是高級平衡基于拓撲結(jié)構(gòu)重定向用到的主要方法。

6.加權(quán)法：加權(quán)方法只能與其他方法合用，是它們的一個很好的補充。加權(quán)算法根據(jù)節(jié)點的優(yōu)先級或當前的負載狀況（即權(quán)值）來構(gòu)成負載平衡的多優(yōu)先級隊列，隊列中的每個等待處理的連接都具有相同處理等級，這樣在同一個隊列里可以按照前面的輪轉(zhuǎn)法或者最少連接法進行均衡，而隊列之間按照優(yōu)先級的先后順序進行均衡處理。在這里權(quán)值是基于各節(jié)點能力的一個估計值。

3.4 軟件的編碼

#include #include #include #include “conn.h” #include “l(fā)og.h” #include “fdwrapper.h”

conn::conn(){ m_srvfd =-1;m_clt_buf = new char[ BUF_SIZE ];if(!m_clt_buf){ throw std::exception();}

m_srv_buf = new char[ BUF_SIZE ];if(!m_srv_buf){ throw std::exception();} reset();}

conn::~conn(){ delete [] m_clt_buf;delete [] m_srv_buf;}

void conn::init_clt(int sockfd, const sockaddr_in& client_addr){ m_cltfd = sockfd;m_clt_address = client_addr;}

void conn::init_srv(int sockfd, const sockaddr_in& server_addr){ m_srvfd = sockfd;m_srv_address = server_addr;}

void conn::reset(){ m_clt_read_idx = 0;m_clt_write_idx = 0;m_srv_read_idx = 0;m_srv_write_idx = 0;m_srv_closed = false;m_cltfd =-1;memset(m_clt_buf, '