專利名稱：網(wǎng)絡(luò)業(yè)務(wù)管理和負載平衡的系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明涉及分布計算環(huán)境中的網(wǎng)絡(luò)業(yè)務(wù)管理和負載平衡的系統(tǒng)和方法。
背景技術(shù)：
為服務(wù)諸如超文本標(biāo)記語言(HTML)頁面、文本文件、圖像、音頻和視頻等的靜態(tài)文檔而初始創(chuàng)建了萬維網(wǎng)。其連接全球數(shù)百萬計用戶的容量已經(jīng)引起世界變革。開發(fā)者很快意識到使用網(wǎng)絡(luò)服務(wù)動態(tài)內(nèi)容的價值。通過向站點增加應(yīng)用邏輯以及數(shù)據(jù)庫連通性，不管有多少用戶站點能夠支持與每個個體用戶的個人化交互。我們將這種站點稱為“動態(tài)站點，，或“web應(yīng)用”，而把僅具有靜態(tài)文檔的站點稱為“靜態(tài)站點”。今天要看見一個完全靜態(tài)的站點是非常罕見的。現(xiàn)在的大多數(shù)站點都是動態(tài)的并且包含靜態(tài)內(nèi)容以及動態(tài)代碼。 例如，amazon. com、eBay, com以及Myspace. com者β是眾所周知的云力態(tài)web站點(web應(yīng)用) 的例子。參見圖1，靜態(tài)站點145包含web服務(wù)器150和靜態(tài)文檔160。當(dāng)web瀏覽器110 通過因特網(wǎng)140發(fā)送請求120時，web服務(wù)器150提供相應(yīng)的文檔作為對客戶端的響應(yīng)130。與之相反，圖2示出了 web應(yīng)用(“動態(tài)網(wǎng)站”)的體系結(jié)構(gòu)。動態(tài)網(wǎng)站基礎(chǔ)設(shè)施 245不僅包括web服務(wù)器250 (以及相關(guān)的靜態(tài)文檔25 ，而且還包括諸如應(yīng)用服務(wù)器260 以及數(shù)據(jù)庫服務(wù)器275的中間件。應(yīng)用邏輯265在應(yīng)用服務(wù)器260上運行，并且數(shù)據(jù)庫服務(wù)器275在應(yīng)用服務(wù)器260上管理對數(shù)據(jù)觀0的訪問。為了使web應(yīng)用成功，其主機基礎(chǔ)設(shè)施必須滿足性能、縮放性以及可獲得性的要求。“性能”是指應(yīng)用對用戶交互的響應(yīng)性?！翱s放性”是指應(yīng)用在負載需求增加情況下的執(zhí)行能力?！翱色@得性”是指應(yīng)用交付連續(xù)不間斷服務(wù)的能力。隨著因特網(wǎng)用戶數(shù)量的指數(shù)增長，接入需求會更容易地排在單個服務(wù)器計算機的性能之前。一種解決性能、縮放性以及可獲得性的有效途徑是將web應(yīng)用裝在多個服務(wù)器 (服務(wù)器簇)上，或者有時將包括文檔、數(shù)據(jù)、代碼以及全部其他軟件的整個應(yīng)用復(fù)制到兩個不同的數(shù)據(jù)中心(站點鏡像)，并且在這些服務(wù)器(或者站點)間對客戶端請求進行負載平衡。負載平衡遍布以上負載的多個服務(wù)器。如果一個服務(wù)器失敗，則負載平衡機制將業(yè)務(wù)從失敗的服務(wù)器移走，以便使得該站點仍處于運行中。對于服務(wù)器簇和站點鏡像二者，已經(jīng)開發(fā)了多種負載均衡機制。它們在其特定上
5下文中工作良好。但是服務(wù)器簇和站點鏡像二者具有顯著的限制。兩種方式都提供“固定量”的基礎(chǔ)設(shè)施容量，但是web應(yīng)用上的負載不是固定的。在實際中，沒有“合適”量的基礎(chǔ)設(shè)施提供給web應(yīng)用，因為當(dāng)存在業(yè)務(wù)尖峰時，應(yīng)用上的負載在短時間段內(nèi)可能在從零到數(shù)百萬的點擊之間擺動。當(dāng)提供不足時，應(yīng)用可能執(zhí)行得較差，或者甚至變得不可用。當(dāng)提供過多時，浪費了提供過多的容量。為了節(jié)約，許多web操作員停止購買顯著比需求多的容量。今天，許多數(shù)據(jù)中心服務(wù)器的利用率低于20%是常見的，導(dǎo)致了容量的顯著浪費。近幾年來，作為有效和更靈活的計算方式，已經(jīng)出現(xiàn)了云計算。根據(jù)維基百科，云計算是指“對于可變服務(wù)使用基于因特網(wǎng)(即，云)的計算機技術(shù)。它是一種動態(tài)可縮放的計算方式，并常常在其中提供虛擬資源作為因特網(wǎng)上的服務(wù)。用戶不需要知曉、專長于、或控制支持它們的‘云’中的技術(shù)基礎(chǔ)設(shè)施。”術(shù)語“云”是基于在計算機網(wǎng)絡(luò)圖中如何對它的描述的比喻，并且是它掩蓋的復(fù)雜的基礎(chǔ)設(shè)施的抽象表示。在本文中，我們使用術(shù)語“云計算”來指代基于網(wǎng)絡(luò)的計算基礎(chǔ)設(shè)施的利用，基于網(wǎng)絡(luò)的計算基礎(chǔ)設(shè)施包括許多互聯(lián)的計算節(jié)點以提供某種類型的服務(wù)，其中每個節(jié)點可以使用像虛擬化和web服務(wù)的技術(shù)。云自身的內(nèi)部工作對用戶而言被隱蔽。使云計算能夠進行的技術(shù)之一是虛擬化。維基百科對“虛擬化”的解釋為“虛擬化是廣義的術(shù)語，指計算機資源的抽象”。它包括“平臺虛擬化”和“資源虛擬化”?！捌脚_虛擬化”將操作系統(tǒng)與底層平臺資源分開，而“資源虛擬化”將具體的系統(tǒng)資源虛擬化，例如存儲體、命名空間和網(wǎng)絡(luò)資源等。VMWare公司提供基于底層硬件資源“虛擬化”計算機操作系統(tǒng)的虛擬化軟件。通過虛擬化，人們可以使用軟件啟動、停止和管理計算環(huán)境中的“虛擬機器”(VM)節(jié)點。每個“虛擬機器”表現(xiàn)得就像從外部角度來看的常規(guī)計算機一樣。盡管“虛擬機器”自身僅是在“真正”計算機上運行的軟件程序，人們可以向其安裝軟件，從其刪除文件和在其上運行程序。使云計算能夠進行的另一技術(shù)是產(chǎn)品硬件的可獲得性以及產(chǎn)品硬件的低成本和強計算能力?，F(xiàn)在人們可以用幾百美元獲得一臺比二十多年前花費十倍成本獲得的機器功能更加強大的計算機。盡管個體產(chǎn)品機器自身可能不可靠，但是將許多個體產(chǎn)品機器放到一起可以產(chǎn)生極其可靠和強大的系統(tǒng)。Amazom. com的彈性計算云(EC^)是通過虛擬化軟件使用數(shù)千產(chǎn)品機器形成極其強大的計算基礎(chǔ)設(shè)施的云計算環(huán)境的例子。通過利用產(chǎn)品硬件和虛擬化，云計算能夠增加數(shù)據(jù)中心效率、增強操作靈活性和降低成本。但是，因為頻繁的節(jié)點停止和啟動，在像Amazom EC2的云計算環(huán)境中運行web 應(yīng)用對業(yè)務(wù)管理和負載平衡產(chǎn)生了新的要求。在服務(wù)器簇和站點鏡像的情況中，停止服務(wù)器或服務(wù)器故障是例外。對應(yīng)的負載平衡機制還被設(shè)計為將這種情況處理為例外。在云計算環(huán)境中，服務(wù)器重新引導(dǎo)和服務(wù)器關(guān)閉被假設(shè)為除例外的常見情形。由于云系統(tǒng)利用產(chǎn)品硬件，所以個體節(jié)點不可靠的假設(shè)是針對云系統(tǒng)設(shè)計的核心。還存在啟動或停止節(jié)點的商業(yè)原因以增加資源利用并降低成本。自然地，云計算環(huán)境所需的業(yè)務(wù)管理和負載平衡系統(tǒng)必須響應(yīng)于這些節(jié)點狀態(tài)的改變。對于簇和站點鏡像，已經(jīng)開發(fā)了各種負載平衡技術(shù)。在現(xiàn)有技術(shù)中，為改進應(yīng)用性能和縮放性，服務(wù)器簇是眾所周知的途徑。該構(gòu)思是將單個服務(wù)器節(jié)點替換為應(yīng)用體系結(jié)構(gòu)中的多個服務(wù)器。因為多個服務(wù)器分擔(dān)應(yīng)用負載，所以性能和縮放性二者都得到改進。如果服務(wù)器之一出現(xiàn)故障，則其他服務(wù)器承擔(dān)起工作，從而防止可用性的丟失。圖3示出一個例子，其中多個web服務(wù)器形成web服務(wù)器群350，多個應(yīng)用服務(wù)器形成應(yīng)用服務(wù)器群360， 并且多個數(shù)據(jù)庫服務(wù)器形成數(shù)據(jù)庫服務(wù)器群380。負載平衡器340添加到體系結(jié)構(gòu)中以使負載分布到不同服務(wù)器。負載平衡器340還檢測節(jié)點故障，并且如果服務(wù)器出現(xiàn)故障，則將請求重新路由到其余服務(wù)器。存在來自諸如 Cisco、Foundry、Networks、F5 Networks、Citrix System 等公司的可用的硬件負載平衡器。流行的軟件負載平衡器包括Apache HTTP服務(wù)器的mocLproxy和 HAProxy0在專利7，480，705和7，346，695等中描述了實現(xiàn)服務(wù)器簇的負載平衡的例子。但是，這樣的負載平衡技術(shù)針對相同數(shù)據(jù)中心中的負載平衡，對頻率節(jié)點狀態(tài)改變的響應(yīng)不好，并要求購買、安裝和維護特殊的軟件或硬件。在專利7，325，109,7, 203，796和7，111，061等描述了比服務(wù)器簇更高級的增強應(yīng)
用可用性的方法稱為“站點鏡像”。其將包括文檔、代碼、數(shù)據(jù)、web服務(wù)器軟件、應(yīng)用服務(wù)器軟件、數(shù)據(jù)庫服務(wù)器軟件等等的整個應(yīng)用復(fù)制到另一地理位置，創(chuàng)建兩個地理分離的彼此鏡像的站點。與服務(wù)器簇相比，站點鏡像具有下列優(yōu)點即使在一個站點完全失敗時，也能夠提供服務(wù)器的可用性。但是它比服務(wù)器簇復(fù)雜，因為它要求兩個站點之間的數(shù)據(jù)同步。被稱為“全局負載平衡設(shè)備”的硬件設(shè)備典型地用于多個站點間的負載平衡。但是，該設(shè)備獲得非常昂貴，并且該系統(tǒng)安裝非常昂貴。而且，對于大多數(shù)應(yīng)用來說，先期投資很高，管理安裝需要專門技術(shù)知識，并且進行變化費時。持續(xù)的維護也昂貴。最后，全局負載平衡設(shè)備的集合形成單點故障。已經(jīng)結(jié)合內(nèi)容交付網(wǎng)絡(luò)(⑶N)開發(fā)了第三種負載平衡方法。像Akamai和 Limelight Networks之類的公司操縱包括戰(zhàn)略上布局在全球的成千上萬的服務(wù)器的全球內(nèi)容交付體系結(jié)構(gòu)。這些服務(wù)器緩存由其客戶(內(nèi)容提供商)產(chǎn)生的web站點內(nèi)容(靜態(tài)文檔)。當(dāng)用戶請求這樣的web站點內(nèi)容時，路由機制發(fā)現(xiàn)合適的服務(wù)該請求的緩存服務(wù)器。通過使用內(nèi)容交付服務(wù)，用戶接收更好的內(nèi)容性能，因為內(nèi)容是從較接近用戶的邊緣服務(wù)器交付的。在內(nèi)容交付的背景下，已經(jīng)開發(fā)了多種用于負載平衡和業(yè)務(wù)管理的技術(shù)。例如，專禾Ij 6，108，703,7, 111，061、和7，251，688說明了產(chǎn)生網(wǎng)絡(luò)地圖和將網(wǎng)絡(luò)地圖提供給域名系統(tǒng)(DNS)并接著選擇合適的內(nèi)容服務(wù)器來服務(wù)用戶請求的方法。專利6，754，699、 7，032，010、和7，346，676公開了將認證DNS服務(wù)器與客戶端DNS服務(wù)器列表關(guān)聯(lián)并接著基于諸如延遲的度量返回合適的內(nèi)容服務(wù)器的方法。盡管這些技術(shù)已經(jīng)成功，但是仍設(shè)計它們來管理用于緩存內(nèi)容交付網(wǎng)絡(luò)的服務(wù)器的業(yè)務(wù)。而且，這些技術(shù)不能實時響應(yīng)負載平衡和失效備援狀態(tài)改變，因為DNS結(jié)果通常被緩存至少一“生存期(TTL) ”時間段，并且因此改變不可見，直到TTL超期為止。剛出現(xiàn)的云計算環(huán)境向負載平衡和失效備援提出了新挑戰(zhàn)。在云計算環(huán)境中，上述一些服務(wù)器節(jié)點可以是“虛擬機器(VM) ”。這些“虛擬機器”表現(xiàn)得就像常規(guī)的物理服務(wù)器。事實上，客戶端甚至不知道服務(wù)器應(yīng)用是在代替物理服務(wù)器的“虛擬機器”上運行的。 這些“虛擬機器”可以成簇，或者在不同的數(shù)據(jù)中心被鏡像，就像傳統(tǒng)的方法一樣以增強應(yīng)用的縮放性。但是，與傳統(tǒng)的成簇或站點鏡像不同，這些虛擬機器可以使用純計算機軟件來啟動、停止和管理，所以更容易管理它們且更容易地進行改變。但是，從業(yè)務(wù)管理的視點看云計算中服務(wù)器節(jié)點的頻繁啟動和停止增加了新要求。因此，期望提供一種負載平衡和業(yè)務(wù)管理系統(tǒng)，其有效地將業(yè)務(wù)定向到多個服務(wù)器節(jié)點，實時響應(yīng)服務(wù)器節(jié)點啟動和停止，同時增強應(yīng)用性能、縮放性和可用性。還期望提供一種在云計算環(huán)境中容易實施、容易維護以及工作良好的負載平衡系統(tǒng)。

發(fā)明內(nèi)容
總的來說，在一個方面，本發(fā)明提供一種在運行網(wǎng)絡(luò)可接入計算機服務(wù)的計算節(jié)點組提供負載平衡和失效備援的方法。該方法包括提供計算機服務(wù)，其中所述計算機服務(wù)存在于在所述計算節(jié)點組包含的一個或多個服務(wù)器上，并且經(jīng)由第一網(wǎng)絡(luò)可被客戶端接入；提供包括多個業(yè)務(wù)處理節(jié)點和負載平衡裝置的第二網(wǎng)絡(luò)，并且其中所述負載平衡裝置被配置為在運行所述計算機服務(wù)的所述計算節(jié)點組提供負載平衡；提供重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置，該網(wǎng)絡(luò)業(yè)務(wù)包括客戶端請求從所述第一網(wǎng)絡(luò)向所述第二網(wǎng)絡(luò)接入所述計算機服務(wù)； 提供選擇所述第二網(wǎng)絡(luò)的業(yè)務(wù)處理節(jié)點的裝置，所述第二網(wǎng)絡(luò)接收所述重定向的網(wǎng)絡(luò)業(yè)務(wù)，并且經(jīng)由所述重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置重定向所述網(wǎng)絡(luò)業(yè)務(wù)到所述業(yè)務(wù)處理節(jié)點，所述網(wǎng)絡(luò)業(yè)務(wù)包括所述客戶端請求接入所述計算機服務(wù)；對于接入所述計算機服務(wù)的每個客戶端請求，經(jīng)由所述負載平衡裝置確定在由所述業(yè)務(wù)處理節(jié)點運行所述計算機服務(wù)的所述計算節(jié)點組的最優(yōu)計算節(jié)點；以及經(jīng)由所述第二網(wǎng)絡(luò)由所述業(yè)務(wù)處理節(jié)點將所述客戶端請求路由到所述最優(yōu)計算節(jié)點。實現(xiàn)本發(fā)明的該方面可以包括下述的一個或多個所述負載平衡裝置是負載平衡和失效備援算法。所述第二網(wǎng)絡(luò)是強加在所述第一網(wǎng)絡(luò)之上的疊加網(wǎng)。所述業(yè)務(wù)處理節(jié)點檢查所述重定向網(wǎng)絡(luò)業(yè)務(wù)并將所有源自相同的客戶端會話的客戶端請求路由到相同的最優(yōu)計算節(jié)點。所述方法還可以包括將針對源自該相同客戶端會話的客戶端請求的來自計算機服務(wù)的響應(yīng)定向到第二網(wǎng)絡(luò)的業(yè)務(wù)處理節(jié)點，并接著將業(yè)務(wù)處理節(jié)點的響應(yīng)定向到該相同的客戶端。經(jīng)由第一網(wǎng)絡(luò)內(nèi)的域名接入所述網(wǎng)絡(luò)可接入的計算機服務(wù)，并且其中所述重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置分析所述網(wǎng)絡(luò)可接入計算機服務(wù)的所述域名為所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的IP地址。所述網(wǎng)絡(luò)可接入計算機服務(wù)是經(jīng)由第一網(wǎng)絡(luò)內(nèi)的域名接入的，并且其中所述重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置將CNAME添加到所述網(wǎng)絡(luò)可接入計算機服務(wù)的所述域名的域名服務(wù)(DNS)記錄中，并分析CNAME為所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的IP 地址。所述網(wǎng)絡(luò)可接入計算機服務(wù)是經(jīng)由第一網(wǎng)絡(luò)內(nèi)的域名接入的，并且其中所述第二網(wǎng)絡(luò)還包括域名服務(wù)器(DNQ節(jié)點，并且其中所述DNS節(jié)點接收所述域名的客戶端DNS查詢， 并且分析所述網(wǎng)絡(luò)可接入計算機服務(wù)的所述域名為所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的 IP地址?；诘皆撜埱蟀l(fā)起的客戶端的所述業(yè)務(wù)處理節(jié)點的地理周邊選擇所述業(yè)務(wù)處理節(jié)點?；谂c所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的負載條件相關(guān)的度量來選擇所述業(yè)務(wù)處理節(jié)點?；谂c所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的性能統(tǒng)計相關(guān)的度量來選擇所述業(yè)務(wù)處理節(jié)點?；诘剿鰳I(yè)務(wù)處理節(jié)點的映射客戶端的粘性會話表來選擇所述業(yè)務(wù)處理節(jié)點。 基于所述負載平衡算法確定所述最優(yōu)計算節(jié)點，并且其中所述負載平衡算法利用最優(yōu)計算節(jié)點性能、最低計算成本、輪叫或加權(quán)業(yè)務(wù)分配作為計算規(guī)則。所述方法還包括提供監(jiān)視裝置，用于監(jiān)視所述業(yè)務(wù)處理節(jié)點和所述計算節(jié)點的狀態(tài)。在檢測到失敗的業(yè)務(wù)處理節(jié)點或失敗的計算節(jié)點時，分別將實時網(wǎng)絡(luò)業(yè)務(wù)重定向到非失敗的業(yè)務(wù)處理節(jié)點或?qū)⒖蛻舳苏埱舐酚傻椒鞘〉挠嬎愎?jié)點?；趤碜运霰O(jiān)控裝置的反饋實時確定所述最優(yōu)計算節(jié)點。所述第二網(wǎng)絡(luò)包括虛擬機器節(jié)點。所述第二網(wǎng)絡(luò)通過動態(tài)調(diào)整業(yè)務(wù)處理節(jié)點的數(shù)量來縮放其
8處理容量和網(wǎng)絡(luò)容量。所述計算機服務(wù)是web應(yīng)用、web服務(wù)或電子郵件服務(wù)。總的來說，在另一個方面，本發(fā)明提供一種在運行網(wǎng)絡(luò)可接入計算機服務(wù)的計算節(jié)點組提供負載平衡和失效備援的系統(tǒng)。該系統(tǒng)包括在計算節(jié)點組和多個客戶端之間提供網(wǎng)絡(luò)連接的第一網(wǎng)絡(luò)；計算機服務(wù)，其中所述計算機服務(wù)處于所述計算節(jié)點組包括的一個或多個服務(wù)器上，并經(jīng)由所述第一網(wǎng)絡(luò)可被客戶端接入；并且包括多個業(yè)務(wù)處理節(jié)點和負載平衡裝置的第二網(wǎng)絡(luò)。所述負載平衡裝置被配置為在運行所述計算機服務(wù)的所述計算節(jié)點組提供負載平衡。該系統(tǒng)還包括重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置，該網(wǎng)絡(luò)業(yè)務(wù)包括客戶端請求從所述第一網(wǎng)絡(luò)向所述第二網(wǎng)絡(luò)接入所述計算機服務(wù)；選擇所述第二網(wǎng)絡(luò)的業(yè)務(wù)處理節(jié)點的裝置，所述第二網(wǎng)絡(luò)接收所述重定向的網(wǎng)絡(luò)業(yè)務(wù)；對于接入所述計算機服務(wù)的每個客戶端請求，經(jīng)由所述負載平衡裝置確定在由所述業(yè)務(wù)處理節(jié)點運行所述計算機服務(wù)的所述計算節(jié)點集中的最優(yōu)計算節(jié)點的裝置；以及經(jīng)由所述第二網(wǎng)絡(luò)由所述業(yè)務(wù)處理節(jié)點將所述客戶端請求路由到所述最優(yōu)計算節(jié)點的裝置。該系統(tǒng)還包括實時監(jiān)視裝置，在業(yè)務(wù)路由中提供用于選擇最優(yōu)業(yè)務(wù)處理節(jié)點和最優(yōu)計算節(jié)點的實時狀態(tài)數(shù)據(jù)，由此最小化由個體節(jié)點的失敗引起的服務(wù)破壞。本發(fā)明的優(yōu)點可以是以下的一個或多個。本發(fā)明采用商品硬件(而不是特定硬件設(shè)備)上的軟件，并提供執(zhí)行全局業(yè)務(wù)管理的服務(wù)。因為其提供web交付服務(wù)，更容易采用和更容易維護。不需要購買特殊的硬件或軟件，并且不必安裝和維護。與現(xiàn)有技術(shù)的負載平衡方法相比，本發(fā)明的系統(tǒng)成本利用效率高且總的來說是靈活的。與內(nèi)容交付網(wǎng)絡(luò)的負載平衡技術(shù)不同，本發(fā)明被設(shè)計為提供動態(tài)web應(yīng)用的業(yè)務(wù)管理，其內(nèi)容不可被緩存。服務(wù)器節(jié)點可以在一個數(shù)據(jù)中心、多個數(shù)據(jù)中心中或者可以在不同的地理位置上分布。而且，這些服務(wù)器節(jié)點的一些可以是運行在云計算環(huán)境中的“虛擬機器”。本發(fā)明是可縮放的、容錯的業(yè)務(wù)管理系統(tǒng)，其執(zhí)行負載平衡和失效備援。業(yè)務(wù)管理系統(tǒng)內(nèi)的個體節(jié)點的失敗不會引起系統(tǒng)的失敗。本發(fā)明被設(shè)計為在商品硬件上運行，并且作為經(jīng)由因特網(wǎng)交付的服務(wù)而被提供。系統(tǒng)是水平可縮放的。通過僅向系統(tǒng)增加更多的業(yè)務(wù)處理節(jié)點可以增加計算能力。該系統(tǒng)特別適于節(jié)點停止和啟動是經(jīng)常出現(xiàn)的諸如云計算環(huán)境的計算環(huán)境的業(yè)務(wù)管理和負載平衡。而且，本發(fā)明還考慮會話粘性，從而當(dāng)要求會話粘性時，來自相同的客戶端會話的請求可以持續(xù)地被路由到相同的計算節(jié)點。會話粘性，也稱為“IP地址持久化”或“服務(wù)器親和力”，意味著源自相同的客戶端不同會話請求將總是被路由到多服務(wù)器環(huán)境中的相同的服務(wù)器。對多種多樣的web應(yīng)用要求“會話粘性”以運行正確的功能。本發(fā)明應(yīng)用的例子包括以下的一些如圖5所示的，定向在相同數(shù)據(jù)中心內(nèi)的不同服務(wù)器上運行的多個復(fù)制的web應(yīng)用例程中的請求；如圖6所示的，對運行在多個站點 (數(shù)據(jù)中心)上的復(fù)制的web應(yīng)用例程之間進行負載平衡；如圖7所示的，在云計算環(huán)境中向節(jié)點定向業(yè)務(wù)。在圖7中，這些節(jié)點示出為“虛擬機器(VM) ”節(jié)點。管理運行在云計算環(huán)境中的到3層(3-tierecOweb應(yīng)用的業(yè)務(wù)。每一層(web服務(wù)器、應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器)包含多個VM例程，如圖8所示。管理多服務(wù)器環(huán)境中到郵件服務(wù)器的業(yè)務(wù)。例如，圖 9示出了這些郵件服務(wù)器也作為VM節(jié)點運行在計算云中。如圖20所示，本發(fā)明還可以用于提供經(jīng)由因特網(wǎng)交付的點播服務(wù)到站點操作員以幫助他們改進他們的web應(yīng)用性能、可縮放性和可獲得性。服務(wù)提供商HOO管理和操作全局基礎(chǔ)設(shè)施H40，提供web性能相關(guān)的服務(wù)，包括監(jiān)視、負載平衡、業(yè)務(wù)管理、縮放和失效備援等等。如圖20所示，為了用戶購買、配置和管理來自服務(wù)提供商的服務(wù)，全局基礎(chǔ)設(shè)施具有管理和配置用戶界面(UI)H30?？蛻舭〒碛泻凸芾韜eb應(yīng)用H50的web操作員H10。 Web應(yīng)用H50可以部署在一個數(shù)據(jù)中心，或在幾個數(shù)據(jù)中心，在一個位置或在多個位置，或作為虛擬機器運行在分布的云計算環(huán)境中。H40提供包括監(jiān)視、業(yè)務(wù)管理、負載平衡和失效備援的服務(wù)給web應(yīng)用H50，這產(chǎn)生了向web用戶H20交付更好的性能、更好的縮放性和更好的可用性。反過來，對于使用該服務(wù)，web操作員HlO向服務(wù)提供商HOO支付費用。結(jié)合下面的附圖和說明，給出本發(fā)明的一個或多個實施例的細節(jié)。本發(fā)明的其他特點、目的和優(yōu)點將從優(yōu)選實施例、附圖的下面描述以及從權(quán)利要求書中是顯而易見的。


圖1是靜態(tài)站點的框圖；圖2是典型web應(yīng)用(“動態(tài)web站點”)的框圖；圖3示出經(jīng)由負載平衡設(shè)備在簇環(huán)境中的負載平衡的框圖(現(xiàn)有技術(shù))。圖4示出經(jīng)由全局負載平衡設(shè)備在兩個鏡像站點之間的負載平衡的示意圖(現(xiàn)有技術(shù))；圖5A是本發(fā)明第一實施例的示意圖；圖5B是圖5A的云路由系統(tǒng)的框圖；圖5C是圖5A的系統(tǒng)中的業(yè)務(wù)處理管線的框圖；圖5是本發(fā)明用于運行在位于相同數(shù)據(jù)中心的不同服務(wù)器上的多個復(fù)制web應(yīng)用例程的業(yè)務(wù)負載平衡的例子的示意圖；圖6是本發(fā)明用于運行在位于不同數(shù)據(jù)中心的不同服務(wù)器上的多個復(fù)制web應(yīng)用例程的業(yè)務(wù)負載平衡的例子的示意圖；圖7是本發(fā)明用于運行在云計算環(huán)境中的“虛擬機器(VM)節(jié)點”上的多個復(fù)制web 應(yīng)用例程的業(yè)務(wù)負載平衡的例子的示意圖；圖8是使用本發(fā)明管理運行在云計算環(huán)境中的3-層web應(yīng)用的業(yè)務(wù)的例子的示意圖；圖9是使用本發(fā)明管理運行在云計算環(huán)境中的郵件服務(wù)器的業(yè)務(wù)的例子的示意圖；圖10是被稱為“Yottaa”的本發(fā)明的實施例的示意圖；圖11示出圖10的^ttaa如何處理客戶端請求的流程圖；圖12示出圖10的^ttaa業(yè)務(wù)管理節(jié)點的體系結(jié)構(gòu)的框圖；圖13示出如何使用本發(fā)明從3-層web應(yīng)用服務(wù)HTTP請求；圖14示出了使用本發(fā)明的業(yè)務(wù)管理系統(tǒng)的應(yīng)用交付網(wǎng)絡(luò)的各種功能塊；圖15示出了 ^ttaa業(yè)務(wù)管理節(jié)點的生命周期；圖16示出了 ^ttaa管理器節(jié)點的體系結(jié)構(gòu)；圖17示出了 ^ttaa管理器節(jié)點的生命周期；圖18示出了 ^ttaa監(jiān)視器節(jié)點的體系結(jié)構(gòu)；圖19示出了使用本發(fā)明提供全局地理負載平衡的例子；以及
圖20示出了使用本發(fā)明提供經(jīng)由因特網(wǎng)向web站點操作員提供改進的web性能服務(wù)的例子。
具體實施例方式本發(fā)明利用重疊虛擬網(wǎng)絡(luò)提供具有運行在相同數(shù)據(jù)中心或不同數(shù)據(jù)中心中的不同服務(wù)器上的多個復(fù)制例程的聯(lián)網(wǎng)計算機服務(wù)的業(yè)務(wù)管理和負載平衡。業(yè)務(wù)處理節(jié)點部署在物理網(wǎng)絡(luò)上，通過該物理網(wǎng)絡(luò)客戶端將業(yè)務(wù)運送到正運行網(wǎng)絡(luò)應(yīng)用的數(shù)據(jù)中心。這些業(yè)務(wù)處理節(jié)點被稱為“業(yè)務(wù)處理單元”(TPU)。TPU部署在不同的位置，每一個位置形成一個計算云。所有TPU —起形成被稱為“云路由網(wǎng)絡(luò)”的“虛擬網(wǎng)絡(luò)”。 業(yè)務(wù)管理機制截獲定向到網(wǎng)絡(luò)應(yīng)用的所有客戶端業(yè)務(wù)并將其重定向到TPU。TPU執(zhí)行負載平衡并將業(yè)務(wù)定向到運行網(wǎng)絡(luò)應(yīng)用的合適的服務(wù)器。每一個TPU具有特定量的帶寬和處理容量。這些TPU彼此經(jīng)由底層網(wǎng)絡(luò)而連接，形成第二虛擬網(wǎng)絡(luò)。通過合并所有TPU的帶寬和處理容量，該虛擬網(wǎng)絡(luò)處理特定量的帶寬和處理容量。當(dāng)業(yè)務(wù)增長到特定級別時，作為增加其處理能力以及帶寬容量的方法，虛擬網(wǎng)絡(luò)啟動更多的TPU。當(dāng)業(yè)務(wù)級別減少到特定閾值時，虛擬網(wǎng)絡(luò)關(guān)閉一些TPU以降低其處理和帶寬容量。參照圖5A，虛擬網(wǎng)絡(luò)包括部署在云；340、云350和云360的位置的節(jié)點。每一個云包括運行用于業(yè)務(wù)管理、業(yè)務(wù)清理和相關(guān)數(shù)據(jù)處理的專業(yè)軟件的節(jié)點。從功能的角度，虛擬網(wǎng)絡(luò)包括截獲和重定向網(wǎng)絡(luò)業(yè)務(wù)的業(yè)務(wù)管理系統(tǒng)330、執(zhí)行接入控制、故障檢測、故障預(yù)防和減輕阻斷攻擊(DOS)的業(yè)務(wù)處理系統(tǒng)334、以及聚集來自不同源的數(shù)據(jù)并提供全局決定支持的全局數(shù)據(jù)處理系統(tǒng)332。聯(lián)網(wǎng)的計算機服務(wù)運行在位于多個站點(即分別是站點A 580以及站點B 590)的多個服務(wù)器(即服務(wù)器550和服務(wù)器591)?？蛻舳?00經(jīng)由網(wǎng)絡(luò) 370接入該網(wǎng)絡(luò)服務(wù)?？蛻舳?00向站點A 580的web服務(wù)器550中的網(wǎng)絡(luò)服務(wù)發(fā)出HTTP請求535。 HTTP請求535被業(yè)務(wù)管理系統(tǒng)(TMQ 330截獲。代替將該請求直接路由到其上正運行該應(yīng)用的目標(biāo)服務(wù)器陽0( “目標(biāo)服務(wù)器”)，業(yè)務(wù)管理系統(tǒng)330將該請求重定向到“最優(yōu)”業(yè)務(wù)處理單元(TPU)342進行處理。更具體地，如圖5A所示，業(yè)務(wù)管理系統(tǒng)330咨詢?nèi)謹?shù)據(jù)處理系統(tǒng)332并選擇“最優(yōu)”業(yè)務(wù)處理單元342以便向其路由該請求。通過特定應(yīng)用來定義 “最優(yōu)”，諸如地理位置是最近的、就網(wǎng)絡(luò)距離/延遲而言是最近的、是性能最佳的節(jié)點、就成本而言是最廉價的節(jié)點、或者根據(jù)特定算法計算的幾個因素的組合。接著業(yè)務(wù)處理單元342 截獲HTTP請求，執(zhí)行負載平衡功能并確定用于處理HTTP請求的“最優(yōu)”服務(wù)器。通過運行負載平衡和失效備援來執(zhí)行負載平衡。在一些情況中，TPU將該請求直接路由到目標(biāo)服務(wù)器。在其他情況中，TPU將該請求路由到另外的業(yè)務(wù)處理單元，該另外的業(yè)務(wù)處理單元最終能將該請求路由到目標(biāo)服務(wù)器，諸如路由到TPU 342至TPU 352然后到服務(wù)器550。云路由網(wǎng)絡(luò)本發(fā)明調(diào)節(jié)(leverage)云路由網(wǎng)絡(luò)。通過背景技術(shù)，我們使用術(shù)語“云路由網(wǎng)絡(luò)” 來指代包括在底層物理網(wǎng)絡(luò)的各種位置上布置的業(yè)務(wù)處理節(jié)點的虛擬網(wǎng)絡(luò)。這些業(yè)務(wù)處理節(jié)點運行專業(yè)業(yè)務(wù)處理軟件來執(zhí)行諸如業(yè)務(wù)重定向、業(yè)務(wù)分離、負載平衡、業(yè)務(wù)檢查、業(yè)務(wù)清理、業(yè)務(wù)優(yōu)化、路由選擇、路由優(yōu)化等等的功能。這些節(jié)點的典型配置包括在各種云計算數(shù)據(jù)中心的虛擬機器。這些云計算數(shù)據(jù)中心提供物理基礎(chǔ)設(shè)施以動態(tài)添加或移除節(jié)點，其還使得虛擬網(wǎng)絡(luò)能縮放其處理容量和網(wǎng)絡(luò)帶寬容量。云路由網(wǎng)絡(luò)包括將網(wǎng)絡(luò)業(yè)務(wù)重定向到其業(yè)務(wù)處理單元(TPU)的業(yè)務(wù)管理系統(tǒng)330、檢查和處理網(wǎng)絡(luò)業(yè)務(wù)的業(yè)務(wù)處理機制334以及聚集來自不同源的數(shù)據(jù)并提供全局決定支持和配置及管理系統(tǒng)的裝置的全局數(shù)據(jù)數(shù)據(jù)存儲庫(store) 332。大多數(shù)節(jié)點是運行專業(yè)業(yè)務(wù)處理軟件的虛擬機器。每個云自身是位于相同數(shù)據(jù)中心(或相同地理位置)的節(jié)點集合。一些節(jié)點執(zhí)行業(yè)務(wù)管理。一些節(jié)點執(zhí)行業(yè)務(wù)處理。一些節(jié)點執(zhí)行監(jiān)視和數(shù)據(jù)處理。一些節(jié)點執(zhí)行調(diào)整虛擬網(wǎng)絡(luò)容量的管理功能。一些節(jié)點執(zhí)行接入管理和安全控制。這些節(jié)點彼此經(jīng)由底層網(wǎng)絡(luò)370連接。兩個節(jié)點之間的連接可以包含底層網(wǎng)絡(luò)中的許多物理鏈路和中繼，但是這些鏈路和中繼一起形成概念上的“虛擬鏈路”，概念上直接連接這兩個節(jié)點。所有這些虛擬鏈路一起形成虛擬網(wǎng)絡(luò)。每一個節(jié)點僅具有固定量的帶寬和處理容量。該虛擬網(wǎng)絡(luò)的容量是所有節(jié)點容量的和，并且因此云路由網(wǎng)絡(luò)在任何給定時刻僅具有固定量的處理和網(wǎng)絡(luò)容量。該固定量的容量對于業(yè)務(wù)需求來說可能不足或過度。通過調(diào)節(jié)單個節(jié)點的容量或通過添加或移動節(jié)點，虛擬網(wǎng)絡(luò)能夠調(diào)整其處理能力以及其帶寬容量。參照圖5B，云路由系統(tǒng)400的功能組件包括業(yè)務(wù)管理接口單元410、業(yè)務(wù)重定向單元420、業(yè)務(wù)路由單元430、節(jié)點管理單元440、監(jiān)視單元450以及數(shù)據(jù)資料庫460。業(yè)務(wù)管理接口單元410包括管理用戶界面(UI)412以及管理API 414。業(yè)務(wù)處理本發(fā)明使用網(wǎng)絡(luò)服務(wù)處理業(yè)務(wù)，并因此僅交付“條件”業(yè)務(wù)給目標(biāo)服務(wù)器。圖5A 示出典型的業(yè)務(wù)處理服務(wù)。當(dāng)客戶端500向運行在服務(wù)器550、591上的網(wǎng)絡(luò)服務(wù)發(fā)出請求時，云路由網(wǎng)絡(luò)在下列步驟中處理請求1、業(yè)務(wù)管理服務(wù)330截獲該請求并將該請求路由到TPU節(jié)點340、350和360 ；2、TPU節(jié)點檢查應(yīng)用特定策略并執(zhí)行如圖5C所示的管線處理；3、如果必須，使用全局數(shù)據(jù)資料庫進行數(shù)據(jù)收集和關(guān)于決定支持的數(shù)據(jù)分析；4、如果必須，將客戶端請求路由到下一 TPU節(jié)點，即從TPU 342到352 ；以及接著5、將請求發(fā)送到“最優(yōu)”服務(wù)器381進行處理。更具體地，當(dāng)客戶端發(fā)送請求到服務(wù)器(例如，客戶向web瀏覽器輸入web URL以接入web站點)時，缺省因特網(wǎng)路由機制將該請求通過網(wǎng)絡(luò)中繼沿特定網(wǎng)絡(luò)路徑從客戶端路由到目標(biāo)服務(wù)器(“缺省路徑”)。使用云路由網(wǎng)絡(luò)，如果存在多個服務(wù)器節(jié)點，則云路由網(wǎng)絡(luò)首先從多個服務(wù)器節(jié)點選擇“最優(yōu)”服務(wù)器節(jié)點作為目標(biāo)服務(wù)器節(jié)點以服務(wù)該請求。該服務(wù)器節(jié)點選擇處理考慮包括以下的因素負載平衡、性能、成本以及地理接近性等等。其次，代替通過缺省路徑，業(yè)務(wù)管理服務(wù)將該請求重定向到該重疊網(wǎng)絡(luò)內(nèi)的“最優(yōu)”業(yè)務(wù)處理單元(TPU)。通過系統(tǒng)路由策略來定義“最優(yōu)”，諸如地理位置是最近的、最具成本效率的、 或者幾個因素的組合。如果需要，該“最優(yōu)”TPU還將該請求路由到云路由網(wǎng)絡(luò)內(nèi)的第二“最優(yōu)” TPU。針對性能和可靠性原因，這兩個TPU節(jié)點使用最佳可獲得或最優(yōu)傳輸機制來彼此通信。接著第二“最優(yōu)”節(jié)點可以將該請求路由到第三“最優(yōu)”節(jié)點等等。該處理可以在云路由網(wǎng)絡(luò)中重復(fù)，直到該請求最終到達目標(biāo)服務(wù)器為止。該組“最優(yōu)” TPU節(jié)點一起形成業(yè)務(wù)延其行進的“虛擬”路徑。該虛擬路徑是這樣選擇的優(yōu)化諸如性能、成本、碳足跡、或幾個因素的組合的特定路由測量，這樣是最優(yōu)的。當(dāng)服務(wù)器響應(yīng)時，該響應(yīng)通過云路由網(wǎng)絡(luò)內(nèi)的相似的管線處理直到其到達客戶端。處理縮放和網(wǎng)絡(luò)縮放本發(fā)明還使用虛擬網(wǎng)絡(luò)執(zhí)行處理縮放和帶寬縮放以響應(yīng)業(yè)務(wù)需求改變。云路由網(wǎng)絡(luò)經(jīng)由其監(jiān)視服務(wù)監(jiān)視業(yè)務(wù)需求、負載條件、網(wǎng)絡(luò)性能和各種其他因素。 當(dāng)滿足特定條件時，其動態(tài)地啟動合適位置的新節(jié)點并將負載擴展到這些新節(jié)點以響應(yīng)增加的需求，或者關(guān)閉一些現(xiàn)存的節(jié)點響應(yīng)于減少的業(yè)務(wù)需求。該最后結(jié)果是云路由網(wǎng)絡(luò)動態(tài)調(diào)整其處理和網(wǎng)絡(luò)容量以將交付最優(yōu)結(jié)果同時去除不必要的容量浪費和碳足跡。而且，云路由網(wǎng)絡(luò)能夠快速地從“故障”中恢復(fù)。當(dāng)諸如節(jié)點失敗和鏈路失敗之類的故障出現(xiàn)時，該系統(tǒng)檢查問題并通過新節(jié)點或選擇替代的路由來從其恢復(fù)。結(jié)果，盡管個體組件可能不可靠，但是整個系統(tǒng)是高可靠的。業(yè)務(wù)重定向本發(fā)明包括被稱為“業(yè)務(wù)重定向”的機制，其截獲客戶端請求并將其重定向到業(yè)務(wù)處理節(jié)點。以下列表包括業(yè)務(wù)截獲和重定向機制的幾個例子。但是，該列表并不意欲排他。 本發(fā)明意欲包括各種業(yè)務(wù)重定向手段。1、代理服務(wù)器設(shè)置大多數(shù)客戶端支持被稱為“代理服務(wù)器設(shè)置”的特征，其允許客戶端指定中繼業(yè)務(wù)到目標(biāo)服務(wù)器的代理服務(wù)器。當(dāng)配置代理服務(wù)器時，所有客戶端請求被發(fā)送到代理服務(wù)器，代理服務(wù)器接著將該業(yè)務(wù)在目標(biāo)服務(wù)器和客戶端之間中繼。2、DNS重定向當(dāng)客戶端試圖經(jīng)由其主機名接入網(wǎng)絡(luò)服務(wù)時，主機名需要被解析成IP地址。該主機名到IP地址的解析通過使用域名服務(wù)器(DNS)系統(tǒng)來實現(xiàn)。通過實現(xiàn)將客戶端主機名解析請求解析成合適的業(yè)務(wù)處理節(jié)點的IP地址而不是目標(biāo)服務(wù)器節(jié)點的 IP地址的定制的DNS系統(tǒng)，DNS重定向能夠提供從業(yè)務(wù)截獲到重定向的透明方式。3、HTTP重定向存在內(nèi)置到HTTP協(xié)議的“重定向”指令，其允許服務(wù)器告訴客戶端向不同的服務(wù)器發(fā)送請求。4、網(wǎng)絡(luò)地址映射可以配置特定設(shè)備以將在特定目的地的業(yè)務(wù)“重定向”到不同目的地。該特征由不同的應(yīng)用(諸如網(wǎng)關(guān)設(shè)備)和軟件產(chǎn)品支持。人們可以配置這樣的設(shè)備來執(zhí)行業(yè)務(wù)重定向功能。監(jiān)視云路由網(wǎng)絡(luò)包含向云路由網(wǎng)絡(luò)提供必須的數(shù)據(jù)作為操作基礎(chǔ)的監(jiān)視服務(wù)720，如圖5C所示。各種實施例實現(xiàn)用于監(jiān)視的各種技術(shù)。下面列出幾種監(jiān)視技術(shù)的例子。1、因特網(wǎng)控制消息協(xié)議(ICMP)Ping 經(jīng)由網(wǎng)絡(luò)配發(fā)送以檢測路由和節(jié)點狀態(tài)的小IP分組；2、跟蹤程序(traceroute)通常用于檢查網(wǎng)絡(luò)路由條件的技術(shù)；3、主機代理運行在收集有關(guān)主機的數(shù)據(jù)的主計算機上的嵌入代理；4、web性能監(jiān)視監(jiān)視器節(jié)點，用作正常用戶代理，周期性地向web服務(wù)器發(fā)送 HTTP請求并處理來自web服務(wù)器的HTTP請求。監(jiān)視器節(jié)點沿著諸如DNS解析時間、請求時間、響應(yīng)時間、頁加載時間、請求數(shù)量、Java腳本文件數(shù)量或頁足跡等等的途徑來記錄度量。5、安全監(jiān)視監(jiān)視器節(jié)點周期性地掃描目標(biāo)系統(tǒng)的安全弱點，諸如周期性地進行網(wǎng)絡(luò)端口掃描和網(wǎng)絡(luò)服務(wù)掃描，以確定哪些端口是公開可接入的以及哪些網(wǎng)絡(luò)服務(wù)正在運行，并且還確定是否存在弱點。
13
6、內(nèi)容安全監(jiān)視監(jiān)視器節(jié)點周期性地緩慢行進于站點，并掃描其內(nèi)容以檢測感染內(nèi)容，諸如惡意軟件、間諜軟件、不期望的成人內(nèi)容或病毒等等。上述例子用于說明的目的。本發(fā)明是不可知的(agnostic)并且包括廣泛不同的監(jiān)視方式。本發(fā)明的實施例可以使用上述用于監(jiān)視不同目標(biāo)系統(tǒng)的技術(shù)之一或組合，即使用ICMP、跟蹤程序以及主機代理來監(jiān)視云路由網(wǎng)絡(luò)自身、使用web性能監(jiān)視、網(wǎng)絡(luò)安全監(jiān)視以及內(nèi)容安全監(jiān)視來監(jiān)視諸如web應(yīng)用的目標(biāo)網(wǎng)絡(luò)服務(wù)的可獲得性、性能和安全。數(shù)據(jù)處理系統(tǒng)(DPS)聚集來自諸如監(jiān)視服務(wù)的數(shù)據(jù)并將所有其他服務(wù)全局可見性提供給這樣的數(shù)據(jù)。負載平衡和業(yè)務(wù)管理的示例在下面說明中，術(shù)語“^ttaa服務(wù)”是指實現(xiàn)業(yè)務(wù)管理和負載平衡的本發(fā)明的系統(tǒng)。圖5說明了負載平衡從客戶端到在相同數(shù)據(jù)中心的不同服務(wù)器上運行的多個復(fù)制web應(yīng)用例程的業(yè)務(wù)的例子。參照圖5，業(yè)務(wù)重定向機制利用DNS重定向機制。為了接入web服務(wù)器550，客戶端機器500需要首先解析web服務(wù)器550的IP地址?？蛻舳?00 發(fā)送出DNS請求510，并且^ttaa服務(wù)520以DNS響應(yīng)515進行應(yīng)答。DNS響應(yīng)515向在 ^ttaa服務(wù)520內(nèi)運行的業(yè)務(wù)處理節(jié)點解析HTTP請求530的域名。結(jié)果，到web服務(wù)器 550的HTTP請求530被重定向到^ttaa服務(wù)520內(nèi)運行的業(yè)務(wù)處理節(jié)點。該節(jié)點還將該請求轉(zhuǎn)發(fā)到web服務(wù)器群550內(nèi)的web服務(wù)器之一，并最終處理該請求。類似地，數(shù)據(jù)中心中的web服務(wù)器節(jié)點550和應(yīng)用服務(wù)器560也可以使用^ttaa服務(wù)520以接入它們的通信目標(biāo)。圖6示出了 ^ttaa服務(wù)620重定向和負載平衡從客戶端500、600向在不同數(shù)據(jù)中心550、650的不同服務(wù)器上運行的多個復(fù)制web應(yīng)用例程的業(yè)務(wù)的例子。圖7說明^ttaa服務(wù)720重定向和負載平衡運行在云計算環(huán)境750中的“虛擬機器”(VM)節(jié)點755上的多個復(fù)制web應(yīng)用例程的業(yè)務(wù)的例子。當(dāng)客戶端機器700請求云 750提供的服務(wù)時，Yottaa服務(wù)720選擇該云內(nèi)的最合適的虛擬機器節(jié)點以服務(wù)該請求。圖8說明^ttaa服務(wù)820重定向和負載平衡從客戶端800到運行在云計算環(huán)境中的3-層web應(yīng)用的業(yè)務(wù)的例子。每一層(web服務(wù)器850、應(yīng)用服務(wù)器860、數(shù)據(jù)庫服務(wù)器870)包含多個VM例程。圖9說明^ttaa服務(wù)920重定向和負載平衡從客戶端900到多服務(wù)器環(huán)境中的郵件服務(wù)器955的業(yè)務(wù)的例子。該郵件服務(wù)器可以作為計算云950中的VM節(jié)點運行。本發(fā)明使用域名系統(tǒng)(DNS)以通過在DNS主機名查詢中提供期望的處理節(jié)點的因特網(wǎng)協(xié)議(IP)地址來獲得業(yè)務(wù)重定向。結(jié)果，客戶端請求被重定向到期望的處理節(jié)點，接著該處理節(jié)點將該請求路由到目標(biāo)計算節(jié)點進行處理。在客戶端要求接入復(fù)制網(wǎng)絡(luò)資源的任何情形下可以使用這種技術(shù)。其將客戶端請求定向到合適的復(fù)制資源，從而從性能角度看到該復(fù)制資源的路由是好的。而且，本發(fā)明還考慮會話粘性。當(dāng)要求會話粘性時，來自相同客戶端會話的請求被持續(xù)地路由到相同的服務(wù)器計算節(jié)點。會話粘性，本領(lǐng)域也稱為“IP 地址持續(xù)性”或“服務(wù)器親和性”，意味著來自相同客戶端會話的不同請求將總是被路由到多服務(wù)器環(huán)境中的相同服務(wù)器。針對不同的web應(yīng)用要求“會話粘性”以使功能正確。通過檢查在圖10所示的被命名為“Yottaa”的本發(fā)明的實施例來更好地理解本發(fā)明的技術(shù)細節(jié)。^ttaa包含功能部件包括業(yè)務(wù)處理單元(TPU)節(jié)點A45、A65 Jottaa業(yè)務(wù)管理(YTM)節(jié)點A30、A50、A70、Yottaa管理器節(jié)點A38、A58、A78以及^ttaa監(jiān)視器節(jié)點 A32、A52、A72。在該例子中，計算服務(wù)運行在諸如網(wǎng)絡(luò)計算環(huán)境A20中的服務(wù)器A47和A67 的多個服務(wù)器計算節(jié)點上。該系統(tǒng)包含一起負責(zé)重定向從客戶端機器到網(wǎng)絡(luò)A20中的服務(wù)器計算節(jié)點的列表的業(yè)務(wù)的多個YTM節(jié)點。每個YTM節(jié)點包含DNS模塊。上級YTM節(jié)點和下級YTM節(jié)點一起形成分級DNS樹，分級DNS樹通過考慮諸如節(jié)點負載條件、地理接近性和網(wǎng)絡(luò)性能的因素將主機名解析成合適的所選擇的“最優(yōu)”TPU節(jié)點的IP地址。而且，每一個TPU節(jié)點選擇向其轉(zhuǎn)發(fā)客戶端請求的“最優(yōu)”的服務(wù)器計算節(jié)點?；诳紤]諸如節(jié)點可獲性、性能和會話粘性(如果需要)的因素來選擇“最優(yōu)”的服務(wù)器計算節(jié)點。結(jié)果，在服務(wù)器計算節(jié)點列表中對客戶端請求進行負載平衡，在一些服務(wù)器計算節(jié)點失敗時應(yīng)該提供實時失效備援保護。參照圖10，使用本發(fā)明將客戶端請求重定向到特定服務(wù)器節(jié)點的工作流包括下面的步驟。1、客戶端AOO向本地DNS服務(wù)器發(fā)送請求以解析運行計算機服務(wù)的服務(wù)器的主機名(1)。如果本地DNS服務(wù)器不能解析主機名，則將其轉(zhuǎn)發(fā)到上級YTM節(jié)點A3(K2)。上級 YTM節(jié)點A30接收來自客戶端DNS服務(wù)器AlO的請求以解析該主機名。2、上級YTM節(jié)點A30選擇下級YTM節(jié)點列表并將它們的地址返回到客戶端DNS服務(wù)器A10(3)。該列表的大小通常是3-5并且如果可能上級YTM試圖確認所返回的列表跨越兩個不同的數(shù)據(jù)中心。下級YTM的選擇是根據(jù)可重復(fù)的路由策略決定的。當(dāng)上級YTM應(yīng)答 DNS查詢請求時，其根據(jù)路由策略設(shè)置長的生存時間值(例如，一天，幾天或甚至更長)。3、客戶端DNS服務(wù)器AlO依次向所返回的下級YTM節(jié)點A50查詢主機名的名稱解析(4)。下級YTM節(jié)點A50利用監(jiān)視器節(jié)點A52收集的數(shù)據(jù)選擇“最優(yōu)”的TPU節(jié)點并返回該TPU節(jié)點的IP地址到客戶端DNS服務(wù)器AlO (5)。4、客戶端AOO接著向TPU A45發(fā)送請求(7)。當(dāng)所選擇的TPU節(jié)點A45接收到客戶端請求時，它首先檢查來看看是否要求會話粘性支持。如果要求會話粘性，它通過咨詢粘性會話表A48進行檢查來看看根據(jù)先前的請求的先前選擇的服務(wù)器計算節(jié)點是否存在。該搜索僅需在本地區(qū)域進行。如果先前選擇的服務(wù)器計算節(jié)點存在，則立即返回該服務(wù)器計算節(jié)點。如果先前選擇的服務(wù)器計算節(jié)點不存在，則TPU節(jié)點根據(jù)特定的負載平衡和失效備援策略選擇“最優(yōu)”的服務(wù)器計算節(jié)點A47 (8)。而且，如果應(yīng)用要求會話粘性，則選擇的服務(wù)器計算節(jié)點和客戶端被添加到粘性會話表A48以備將來參考。服務(wù)器A47接著處理該請求并將響應(yīng)發(fā)送回TPU A45 (9)，并且TPU A45將其發(fā)送到客戶端AOO (10)。在業(yè)務(wù)重定向和負載平衡處理中使用的組合了設(shè)置的不同TTL值和負載平衡策略的YTM DNS節(jié)點的分級結(jié)構(gòu)導(dǎo)致了獲得業(yè)務(wù)管理的任務(wù)，即性能加速、負載平衡和失效備援。本實施例的基于DNS的方式僅是如何能實現(xiàn)業(yè)務(wù)管理的例子，并且在任何方面上其不將本發(fā)明限制在該具體實現(xiàn)上。本發(fā)明的一個方面在于其是容錯的且高速響應(yīng)節(jié)點狀態(tài)改變。當(dāng)下級YTM節(jié)點啟動時，它從其配置數(shù)據(jù)中發(fā)現(xiàn)上級YTM列表并將其可用性自動通知它們。結(jié)果，上級YTM 節(jié)點將該新節(jié)點添加到接收DNS請求的節(jié)點的列表中。當(dāng)從管理器節(jié)點接收到下級YTM節(jié)點關(guān)閉通知事件時，上級YTM節(jié)點將關(guān)閉節(jié)點從其列表中移除。因為針對DNS查詢請求返回多個YTM節(jié)點，所以一個YTM節(jié)點變?yōu)殛P(guān)閉將不會導(dǎo)致DNS查詢失敗。而且，因為從下級 YTM節(jié)點返回的短的TTL值，所以服務(wù)器節(jié)點失敗將對任何用戶是透明的。如果要求粘性會話支持，則這些目前連接到該失敗的服務(wù)器節(jié)點的用戶可以獲得一錯誤。但是甚至對于這些用戶，在TTL逾期后其將不能短期恢復(fù)。當(dāng)管理器節(jié)點檢測到服務(wù)器節(jié)點失敗時，它通知本地區(qū)域中的下級YTM節(jié)點并且這些YTM節(jié)點立即將該服務(wù)器節(jié)點從路由列表中移除。 而且，如果一些上級節(jié)點關(guān)閉，因為上級YTM節(jié)點返回的長的TTL值，所以大多數(shù)DNS查詢將不注意該失敗。只要在請求的主機名的DNS記錄中的至少一個上級YTM節(jié)點仍在運行， 則在TTL逾期后對失敗的上級節(jié)點的查詢將仍會是成功的。當(dāng)服務(wù)器計算節(jié)點停止或啟動時，監(jiān)視器節(jié)點立即檢測其狀態(tài)改變。這樣的信息使得TPU節(jié)點能響應(yīng)節(jié)點狀態(tài)改變進行實時路由調(diào)整。本發(fā)明的另一方面在于它是高效且可縮放的。因為上級YTM返回長的TTL值，并且因特網(wǎng)上的DNS服務(wù)器執(zhí)行DNS緩存，所以大多數(shù)DNS查詢將直接轉(zhuǎn)向下級YTM節(jié)點，并且因此在上級YTM節(jié)點上的實際負載是很低的。而且上級YTM節(jié)點不需要彼此通信，并且因此通過向系統(tǒng)添加新節(jié)點，系統(tǒng)的容量線性增加。只要在本地區(qū)域中粘性會話列表是可接入的，則下級YTM節(jié)點也不需要彼此通信。當(dāng)添加新的YTM節(jié)點時，其僅需要與少量上級 YTM節(jié)點以及少量管理器節(jié)點通信，并且容量也線性增加。具體地，圖10示出了 ^ttaa服務(wù)的體系結(jié)構(gòu)以及解析從位于北美的客戶端機器 AOO到其最近的服務(wù)器例程A47的請求的步驟。同樣地，來自位于亞洲的客戶端機器A80的請求被定向到接近A80的服務(wù)器A67。如果應(yīng)用請求粘性會話支持，則系統(tǒng)使用粘性會話列表來路由從相同客戶端會話到持續(xù)服務(wù)器計算節(jié)點的請求。系統(tǒng)“Yottaa”部署在網(wǎng)絡(luò)A20上。網(wǎng)絡(luò)可以是局域網(wǎng)、無線網(wǎng)、諸如因特網(wǎng)的廣域網(wǎng)等等。應(yīng)用運行在被圖中標(biāo)注為“服務(wù)器”的節(jié)點上，諸如服務(wù)器A47和服務(wù)器A67。 ^ttaa將全部這些服務(wù)器例程常常是根據(jù)地理接近性或網(wǎng)絡(luò)接近性分成不同區(qū)域。每一個 YTM節(jié)點管理服務(wù)器節(jié)點列表。例如，YTM節(jié)點A50管理區(qū)域A40中的服務(wù)器，諸如服務(wù)器 A47。在網(wǎng)絡(luò)上，Yottaa部署幾種類型的邏輯節(jié)點，包括TPU節(jié)點A45、A65、Yottaa業(yè)務(wù)管理(YTM)節(jié)點諸如A30、A50和A70、Yottaa管理器節(jié)點諸如A38、A58和A78、Yottaa監(jiān)視器節(jié)點諸如A32、A52和A72。注意，在實際實現(xiàn)中，不要求將這些類型的邏輯節(jié)點分離成三種實體，在實際部署中它們中的兩個或它們的全部可以組合到同一物理節(jié)點中。存在兩種類型的YTM節(jié)點上級YTM節(jié)點(諸如A30)和下級YTM節(jié)點(諸如A50 和A70)。它們結(jié)構(gòu)相同但功能不同。通過節(jié)點自身的配置來定義YTM節(jié)點是上級節(jié)點還是下級節(jié)點。每一個YTM節(jié)點都包含DNS模塊。例如，YTM A50包含DNS A55。而且，如果主機名要求粘性會話支持(如web操作員定義的)，則針對每一個應(yīng)用的主機名創(chuàng)建粘性會話列表(諸如A48和A68)。該粘性會話列表由管理該應(yīng)用的服務(wù)器節(jié)點的相同列表的YTM 節(jié)點共享。在某種意義上，上級YTM節(jié)點通過向下級YTM節(jié)點定向DNS請求來向它們提供服務(wù)。在級聯(lián)形式中，每個下級YTM節(jié)點向其自己的“下級"YTM節(jié)點組提供類似的服務(wù)，類似于典型的DNS拓撲中的DNS樹。使用這樣的級聯(lián)樹結(jié)構(gòu)，系統(tǒng)防止了節(jié)點由于太多的請求而崩潰，保證了每一個節(jié)點的性能并僅通過增加更多的節(jié)點能擴展到覆蓋整個因特網(wǎng)。圖10結(jié)構(gòu)性地示出了在一個地理區(qū)域中客戶端如何被定向到“最近”的服務(wù)器節(jié)點。通過特定應(yīng)用的系統(tǒng)路由策略確定“最近”的含義。當(dāng)客戶端A00想連接到服務(wù)器時，
16在解析客戶端DNS請求中發(fā)生如下步驟1、客戶端AOO向其本地DNS服務(wù)器AlO發(fā)送DNS查詢請求；2、本地DNS服務(wù)器AlO (如果其不能直接解析該請求)向上級YTM A30(實際上， 運行在A30內(nèi)部的DNS模塊A35)發(fā)送該請求。YTM A30的選擇基于系統(tǒng)配置，即針對請求的主機名，YTM A30配置在DNS記錄中；3、在從AlO接收到請求時，上級YTM A30將下級YTM節(jié)點列表返回到A10。根據(jù)當(dāng)前路由策略選擇該列表，諸如選擇地理上最接近客戶端本地DNS AlO的YTM節(jié)點；4、AlO接收該響應(yīng)，并向所返回的下級YTM節(jié)點之一 A50發(fā)送主機名解析請求；5、下級YTM節(jié)點A50接收該請求，根據(jù)其路由策略返回“最優(yōu)”TPU節(jié)點的IP地址列表。在這種情況中，選擇并返回TPU節(jié)點A45，因為它地理上最接近客戶端DNS AlO ；6、AlO將所接收的IP地址列表返回到客戶端AOO ；7、AOO向TPU節(jié)點A45發(fā)送其請求；8,TPU節(jié)點A45從客戶端AOO接收請求并選擇諸如服務(wù)器A47的“最優(yōu)”服務(wù)器節(jié)點以向其轉(zhuǎn)發(fā)該請求；9、服務(wù)器A47接收該轉(zhuǎn)發(fā)的請求，處理該轉(zhuǎn)發(fā)的請求并返回響應(yīng)；10、TPU節(jié)點A45向客戶端AOO發(fā)送該響應(yīng)。類似地，位于亞洲的客戶端A80被路由到替代的服務(wù)器A65。^ttaa服務(wù)向web操作員提供基于web的用戶界面(UI)進行系統(tǒng)配置以針對他們的web應(yīng)用使用^ttaa服務(wù)。web操作員也能夠使用諸如基于網(wǎng)絡(luò)的應(yīng)用編程接口 (API)調(diào)用或由服務(wù)提供商直接修改配置文件之類的其他方法。使用^ttaa web UI作為例子，web操作員執(zhí)行下列步驟1、輸入目標(biāo)web應(yīng)用的主機名，例如www, yottaa. com 2、輸入目標(biāo)web應(yīng)用運行于其上的服務(wù)器計算節(jié)點的IP地址(如果存在web應(yīng)用已經(jīng)直接由web操作員部署的服務(wù)器)；3、響應(yīng)于業(yè)務(wù)需求增加和相關(guān)的配置參數(shù)，配置^ttaa是否應(yīng)該開始新的服務(wù)器例程。而且，如果容量超過特定閾值的需求，配置^ttaa是否應(yīng)該關(guān)閉服務(wù)器節(jié)點；4、向目標(biāo)web應(yīng)用的主機名的DNS記錄添加所提供的上級^ttaa節(jié)點名稱；5、配置諸如應(yīng)用是否要求粘性會話支持，會話逾期值、路由策略等等的其他參數(shù)。一旦^ttaa系統(tǒng)接收到上述信息，則它執(zhí)行建立其服務(wù)的必須動作以最優(yōu)化目標(biāo)web應(yīng)用的業(yè)務(wù)負載平衡。例如，一旦接收到主機名和目標(biāo)服務(wù)器節(jié)點的靜態(tài)IP地址， 系統(tǒng)就將這樣的信息傳播給所選擇的下級YTM節(jié)點(使用當(dāng)前的路由策略)，從而當(dāng)接收到 DNS查詢請求時，至少一些下級YTM節(jié)點能夠?qū)⒅鳈C名解析成IP地址。圖11示出了使用^ttaa服務(wù)如何路由請求的處理流程。當(dāng)客戶端想連接到諸如 www, example, com的主機時，它需要首先解析主機名的IP地址。為此，它查詢它的本地DNS 服務(wù)器。本地DNS服務(wù)器首先檢查這樣的主機名是否被緩存并且根據(jù)在前的解析是否仍有效。如果是，則返回緩存的結(jié)果。如果否，則客戶端DNS服務(wù)器針對mm. example, com向預(yù)配置的作為上級YTM節(jié)點的DNS服務(wù)器發(fā)布請求。上級YTM節(jié)點根據(jù)針對該應(yīng)用配置的可重復(fù)的路由策略返回下級YTM節(jié)點的列表。在接收到所返回的YTM DNS節(jié)點的返回列表時， 客戶端DNS服務(wù)器需要查詢這些節(jié)點直到返回所解析的IP地址為止。因此，它向列表中之一的下級YTM節(jié)點發(fā)送請求。下級YTM接收該請求，并接著它基于當(dāng)前的路由策略和節(jié)點監(jiān)視狀態(tài)信息選擇“最優(yōu)”TPU節(jié)點列表。返回所選擇的“最優(yōu)”TPU節(jié)點的IP地址。結(jié)果， 客戶端向“最優(yōu)” TPU節(jié)點之一發(fā)送請求。所選擇的“最優(yōu)” TPU節(jié)點接收該請求。首先，它確定該應(yīng)用是否要求粘性會話支持。在定制的^ttaa服務(wù)的初始建立期間通常由web操作員配置應(yīng)用是否要求粘性會話支持。這樣的初始改變隨后可以改變。如果不要求粘性會話支持，則TPU節(jié)點選擇正運行應(yīng)用www, example, com的、根據(jù)當(dāng)前的路由策略和服務(wù)器計算節(jié)點監(jiān)視數(shù)據(jù)選擇的“最優(yōu)”服務(wù)器計算節(jié)點。如果要求粘性會話支持，則TPU節(jié)點首先使用主機名或URL(此情況中，www, example, com)以及客戶端的IP地址作為關(guān)鍵信息(key) 查找粘性會話列表中的條目。如果發(fā)現(xiàn)這樣的條目，在粘性會話列表中的該條目的逾期時間被更新為當(dāng)前時間加上預(yù)配置的會話逾期值。當(dāng)web操作員執(zhí)行^ttaa服務(wù)的初始配置時，他向系統(tǒng)輸入會話逾期超時值，諸如一小時。如果沒有發(fā)現(xiàn)條目，則TPU節(jié)點根據(jù)當(dāng)前路由策略選擇“最優(yōu)”服務(wù)器計算節(jié)點，創(chuàng)建具有合適的關(guān)鍵信息以及逾期信息的條目， 并將該條目輸入到粘性會話列表中。最后，TPU節(jié)點向所選擇的“最優(yōu)”服務(wù)器計算節(jié)點轉(zhuǎn)發(fā)客戶端請求進行處理。如果在查詢下級YTM節(jié)點的過程中接收到錯誤，則客戶端DNS服務(wù)器將查詢列表中的下一個TPU節(jié)點。所以個體下級YTM節(jié)點的失敗對于客戶端而言是不可見的。類似地，如果在連接至所返回的“最優(yōu)”TPU節(jié)點之一的IP地址中存在錯誤，則客戶端將試圖連接到列表中的下一個IP地址，直到成功地進行連接為止。上級YTM節(jié)點通常對于它返回的結(jié)果設(shè)置長的生存時間(TTL)值。這樣做最小化了上級節(jié)點的負載并減少了來自客戶端DNS服務(wù)器的查詢數(shù)量。另一方面，下級YTM節(jié)點通常設(shè)置短的TTL值，使得系統(tǒng)很快響應(yīng)TPU節(jié)點狀態(tài)改變。通過清除過期條目來周期性地清理粘性會話列表。在自從上一查詢后的整個會話逾期期間不存在從相同的客戶端的針對相同應(yīng)用的客戶端請求時，條目過期。在粘性會話情形中，如果持續(xù)性IP地址的服務(wù)器節(jié)點關(guān)閉，則^ttaa監(jiān)視器節(jié)點檢測服務(wù)器失敗并通知其相關(guān)的管理器節(jié)點。相關(guān)的管理器節(jié)點通知相應(yīng)的YTM節(jié)點。接著這些YTM節(jié)點從粘性會話列表中移除該條目。TPU節(jié)點將自動地向走在前面的不同的服務(wù)器節(jié)點轉(zhuǎn)發(fā)業(yè)務(wù)。 而且，對于粘性會話情形，^ttaa聰明地管理關(guān)閉的服務(wù)器節(jié)點以消除針對連接到計劃關(guān)閉的服務(wù)器節(jié)點的這些用戶的服務(wù)中斷。它等待直到在該服務(wù)器節(jié)點上的所有用戶會話在最終關(guān)閉節(jié)點例程之前都已經(jīng)逾期為止。^ttaa調(diào)節(jié)設(shè)計到因特網(wǎng)的DNS系統(tǒng)中的遺留的縮放性。它在每一步驟中還提供多個冗余級別(除了 DNS查詢需要持續(xù)性IP地址的粘性會話情形外)。而且，系統(tǒng)使用多層DNS層次體系，從而它自然地將負載散布到不同的YTM節(jié)點，以有效地分布負載且高度可縮放，同時能夠調(diào)節(jié)針對不同節(jié)點的TTL值并響應(yīng)于節(jié)點狀態(tài)變化。圖12示出了 ^ttaa業(yè)務(wù)管理節(jié)點的功能塊，如圖示為C00。節(jié)點包括DNS模塊C10，執(zhí)行標(biāo)準DNS功能；狀態(tài)探頭模塊C60，監(jiān)視該YTM節(jié)點自身的狀態(tài)并響應(yīng)于狀態(tài)詢問；管理UI模塊C50，使系統(tǒng)管理者在需要時直接管理該節(jié)點；虛擬機器管理器C40(可選)，能夠管理網(wǎng)絡(luò)上的虛擬機器節(jié)點；以及路由策略模塊C30，管理路由策略。路由策略模塊可以按照需要加載不同的路由策略。模塊C30的部分是用于路由策略的接口，并且該模塊的另一部分提供DNS查詢過程期間的粘性會話支持。而且，YTM節(jié)點COO包括配置模塊 C75、節(jié)點例程DB C80以及數(shù)據(jù)存儲庫模塊C85。
圖15示出了 YTM節(jié)點如何工作。當(dāng)YTM節(jié)點引導(dǎo)時，它從其環(huán)境、配置文件、例程 DB等等中讀取初始化參數(shù)。在該過程中，它按照需要采用合適的動作，諸如針對不同應(yīng)用加載特定路由策略。而且，如果存在初始化參數(shù)中指定的管理器節(jié)點，則YTM節(jié)點向這樣的管理器節(jié)點發(fā)送啟動可用性事件。因此，這些管理器節(jié)點向該YTM節(jié)點傳遞服務(wù)器節(jié)點列表，并分配監(jiān)視器節(jié)點以監(jiān)視該YTM節(jié)點的狀態(tài)。下面，YTM節(jié)點進行檢查確定根據(jù)其配置參數(shù)它是否是上級YTM。如果它是上級YTM，則節(jié)點進入請求處理的主循環(huán)，直到最終接收到關(guān)閉請求或出現(xiàn)節(jié)點失敗為止。當(dāng)接收關(guān)閉命令時，該節(jié)點向其相關(guān)的管理器節(jié)點通知關(guān)閉事件、記錄該事件并接著執(zhí)行關(guān)閉。如果它不是上級YTM節(jié)點，則它通過向如在節(jié)點配置數(shù)據(jù)中指定的上級YTM節(jié)點的指定列表發(fā)送啟動可用性事件而繼續(xù)其初始化。當(dāng)上級YTM節(jié)點從下級YTM節(jié)點接收到啟動可用性事件時，它執(zhí)行下列動作1、向路由列表添加下級YTM節(jié)點，從而將來的DNS請求可被路由到該下級YTM節(jié)點2、如果下級YTM節(jié)點沒有已經(jīng)建立的相關(guān)管理器節(jié)點(如由啟動可用性事件消息指示的)，則根據(jù)上級YTM節(jié)點自身的路由策略選擇管理器節(jié)點列表，并將該管理器節(jié)點列表返回到下級YTM節(jié)點。當(dāng)下級YTM節(jié)點從上級YTM節(jié)點接收到該管理器節(jié)點列表時，它通過向列表中的每一個管理器節(jié)點發(fā)送啟動可用性事件進行狀態(tài)更新而繼續(xù)其初始化。當(dāng)管理器節(jié)點從下級YTM節(jié)點接收到啟動可用性事件時，它分配監(jiān)視器節(jié)點以監(jiān)視該YTM節(jié)點的狀態(tài)。而且， 管理器節(jié)點向YTM節(jié)點返回在該管理器(實際的監(jiān)視通過該管理器的相關(guān)監(jiān)視器節(jié)點執(zhí)行)管理之下的服務(wù)器節(jié)點的列表。當(dāng)下級YTM節(jié)點從管理器節(jié)點接收到服務(wù)器節(jié)點列表時，該信息被添加到由該YTM節(jié)點管理的被管理的服務(wù)器節(jié)點列表中，從而將來的DNS請求可被路由到該列表中的服務(wù)器。在YTM節(jié)點完成建立其管理的服務(wù)器節(jié)點列表之后，它進入請求處理的主循環(huán)。 例如.如果接收到DNS請求，則根據(jù)針對目標(biāo)主機名和客戶端DNS服務(wù)器的路由策略， YTM節(jié)點從其管理的節(jié)點返回一個或多個節(jié)點。.如果該請求是來自管理器節(jié)點的節(jié)點關(guān)閉事件，則從被管理節(jié)點列表中除去該節(jié)點。.如果接收到節(jié)點啟動事件，則將該新節(jié)點添加到被管理節(jié)點列表中。最后，如果接收到關(guān)閉請求，則YTM節(jié)點向其相關(guān)的管理器節(jié)點以及上級YTM節(jié)點通知其關(guān)閉，向其本地存儲器存儲必要的狀態(tài)，記錄事件并關(guān)閉。圖16示出了 ^ttaa管理器節(jié)點的功能塊。它包括請求處理器模塊F20，處理從網(wǎng)絡(luò)上的其他^ttaa節(jié)點的接收的請求；虛擬機器(VM)管理器模塊F30，能夠用于管理虛擬機器例程；管理用戶界面(UI)模塊F40，能夠用于本地的配置節(jié)點；以及狀態(tài)探頭模塊 F50，監(jiān)視該節(jié)點自身的狀態(tài)并響應(yīng)狀態(tài)詢問?？蛇x地，如果監(jiān)視器節(jié)點被組合到該節(jié)點，則管理器節(jié)點還包括節(jié)點監(jiān)視器模塊F10，保持被監(jiān)視節(jié)點的列表并根據(jù)當(dāng)前監(jiān)視策略周期性地輪詢列表中的節(jié)點。圖17示出了 ^ttaa管理器節(jié)點如何工作。當(dāng)它啟動時，它從其環(huán)境、配置文件、 例程DB等等中讀取配置數(shù)據(jù)和初始化參數(shù)。在該過程中采取合適的動作。接著它向如在其節(jié)點配置數(shù)據(jù)或初始化參數(shù)中指定的父管理器節(jié)點的列表發(fā)送啟動可用性事件。當(dāng)父管理器節(jié)點接收到啟動可用性事件時，它將該新節(jié)點添加到它“管理”下的節(jié)點列表中，并“分配” 一些相關(guān)的監(jiān)視器節(jié)點以通過向這些監(jiān)視器節(jié)點發(fā)送相應(yīng)請求監(jiān)視該新節(jié)點的狀態(tài)。接著該父管理器節(jié)點通過以一些服務(wù)器節(jié)點的列表進行響應(yīng)來將這些服務(wù)器節(jié)點的管理責(zé)任交付給新管理節(jié)點。當(dāng)子管理器節(jié)點接收到期望其繼續(xù)管理責(zé)任的服務(wù)器節(jié)點列表時，它將它的一些相關(guān)的監(jiān)視器節(jié)點分配來進行服務(wù)器節(jié)點列表的性能監(jiān)視和狀態(tài)輪詢。如果沒有指定父管理器節(jié)點，則期望^ttaa管理器根據(jù)其配置數(shù)據(jù)創(chuàng)建其服務(wù)器節(jié)點列表。接著，管理器節(jié)點完成其初始化并進入其請求處理的主處理循環(huán)。如果請求是來自YTM節(jié)點的啟動可用性事件，則它將YTM節(jié)點添加到監(jiān)視列表中， 并以針對其分配YTM節(jié)點進行業(yè)務(wù)管理的服務(wù)器列表進行應(yīng)答。注意，通常，可以向多個 YTM節(jié)點分配相同的服務(wù)器節(jié)點進行路由。如果請求是關(guān)閉請求，則它向其父管理器節(jié)點通知關(guān)閉，記錄事件并接著執(zhí)行關(guān)閉。如果從監(jiān)視器節(jié)點報告節(jié)點錯誤請求，則管理器節(jié)點將該錯誤節(jié)點從其列表中移除(或?qū)⑵湟苿拥讲煌牧斜?，記錄事件并可選擇地報告事件。 如果錯誤節(jié)點是服務(wù)器節(jié)點，則管理器節(jié)點通知丟失的該服務(wù)器節(jié)點的相關(guān)的YTM節(jié)點， 并且如果配置如此進行并滿足特定條件的話，它試圖重新啟動該節(jié)點或開始新的服務(wù)器節(jié)點ο本發(fā)明的一個應(yīng)用是向web站點操作員提供因特網(wǎng)上交付的點播內(nèi)容以幫助他們改善他們的web應(yīng)用性能、縮放性和可用性，如圖20所示。服務(wù)提供商HOO管理和操縱提供web性能相關(guān)的服務(wù)的全局基礎(chǔ)設(shè)施H40，包括監(jiān)視、負載平衡、業(yè)務(wù)管理、縮放和失效備援等等。全局基礎(chǔ)設(shè)施還具有管理和配置用戶界面(UI)H30，如圖19所示，用于客戶訂購、配置和管理服務(wù)提供商的服務(wù)?？蛻舭〒碛泻凸芾韜eb應(yīng)用H50的web操作員H10。 Web應(yīng)用H50可以部署在一個數(shù)據(jù)中心、幾個數(shù)據(jù)中心、一個位置、多個位置，或者作為分布式云計算環(huán)境中虛擬機器運行。H40提供包括監(jiān)視、業(yè)務(wù)管理、負載平衡、失效備援等的服務(wù)給web應(yīng)用H50，向web用戶H20提供具有交付更好性能、更好縮放性和更好可用性的效果。反過來，對于使用該服務(wù)，web管理員HlO向服務(wù)提供商HOO支付費用。內(nèi)容交付網(wǎng)絡(luò)在全局上通常使用成千上萬的服務(wù)器，并且需要盡可能多的接入點 (point of presence POP)。于此不同，本發(fā)明需要被部署到僅僅幾個或幾十個位置。而且， 本發(fā)明意欲管理服務(wù)器業(yè)務(wù)的服務(wù)器通常部署在僅僅幾個數(shù)據(jù)中心，或者有時部署在僅僅一個數(shù)據(jù)中心。已經(jīng)描述了本發(fā)明的幾個實施例。但是，應(yīng)該理解的是，在不背離本發(fā)明的精神和范圍的前提下，可以進行各種修改。因此其他實施例在下述權(quán)利要求書的范圍之內(nèi)。
20
權(quán)利要求
1.一種在運行網(wǎng)絡(luò)可接入計算機服務(wù)的計算節(jié)點組提供負載平衡和失效備援的方法， 包括提供計算機服務(wù)，其中所述計算機服務(wù)存在于在所述計算節(jié)點組包含的一個或多個服務(wù)器上，并且經(jīng)由第一網(wǎng)絡(luò)可被客戶端接入；提供包括多個業(yè)務(wù)處理節(jié)點和負載平衡裝置的第二網(wǎng)絡(luò)，并且其中所述負載平衡裝置被配置為在運行所述計算機服務(wù)的所述計算節(jié)點組提供負載平衡；提供重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置，該網(wǎng)絡(luò)業(yè)務(wù)包括客戶端請求從所述第一網(wǎng)絡(luò)向所述第二網(wǎng)絡(luò)接入所述計算機服務(wù)；提供選擇所述第二網(wǎng)絡(luò)的業(yè)務(wù)處理節(jié)點的裝置，所述第二網(wǎng)絡(luò)接收所述重定向的網(wǎng)絡(luò)業(yè)務(wù)，并且經(jīng)由所述重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置重定向所述網(wǎng)絡(luò)業(yè)務(wù)到所述業(yè)務(wù)處理節(jié)點，所述網(wǎng)絡(luò)業(yè)務(wù)包括所述客戶端請求接入所述計算機服務(wù)；對于接入所述計算機服務(wù)的每個客戶端請求，經(jīng)由所述負載平衡裝置確定在由所述業(yè)務(wù)處理節(jié)點運行所述計算機服務(wù)的所述計算節(jié)點組的最優(yōu)計算節(jié)點；以及經(jīng)由所述第二網(wǎng)絡(luò)由所述業(yè)務(wù)處理節(jié)點將所述客戶端請求路由到所述最優(yōu)計算節(jié)點。
2.如權(quán)利要求1所述的方法，其中所述負載平衡裝置包括負載平衡和失效備援算法。
3.如權(quán)利要求1所述的方法，其中所述第二網(wǎng)絡(luò)包括強加在所述第一網(wǎng)絡(luò)之上的疊加網(wǎng)。
4.如權(quán)利要求1所述的方法，其中所述業(yè)務(wù)處理節(jié)點檢查所述重定向網(wǎng)絡(luò)業(yè)務(wù)并將所有源自相同的客戶端會話的客戶端請求路由到相同的最優(yōu)計算節(jié)點。
5.如權(quán)利要求1所述的方法，其中經(jīng)由第一網(wǎng)絡(luò)內(nèi)的域名接入所述網(wǎng)絡(luò)可接入的計算機服務(wù)，并且其中所述重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置分析所述網(wǎng)絡(luò)可接入計算機服務(wù)的所述域名為所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的IP地址。
6.如權(quán)利要求1所述的方法，其中所述網(wǎng)絡(luò)可接入計算機服務(wù)是經(jīng)由第一網(wǎng)絡(luò)內(nèi)的域名接入的，并且其中所述重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置將CNAME添加到所述網(wǎng)絡(luò)可接入計算機服務(wù)的所述域名的域名服務(wù)(DNQ記錄中，并解析CNAME為所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的IP地址。
7.如權(quán)利要求1所述的方法，其中所述網(wǎng)絡(luò)可接入計算機服務(wù)是經(jīng)由第一網(wǎng)絡(luò)內(nèi)的域名接入的，并且其中所述第二網(wǎng)絡(luò)還包括域名服務(wù)器(DNQ節(jié)點，并且其中所述DNS節(jié)點接收所述域名的客戶端DNS查詢并且解析所述網(wǎng)絡(luò)可接入計算機服務(wù)的所述域名為所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的IP地址。
8.如權(quán)利要求1所述的方法，其中基于到該請求發(fā)起的客戶端的所述業(yè)務(wù)處理節(jié)點的地理周邊選擇所述業(yè)務(wù)處理節(jié)點。
9.如權(quán)利要求1所述的方法，其中基于與所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的負載條件相關(guān)的度量來選擇所述業(yè)務(wù)處理節(jié)點。
10.如權(quán)利要求1所述的方法，其中基于與所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的性能統(tǒng)計相關(guān)的度量來選擇所述業(yè)務(wù)處理節(jié)點。
11.如權(quán)利要求1所述的方法，其中基于到所述業(yè)務(wù)處理節(jié)點的映射客戶端的粘性會話表來選擇所述業(yè)務(wù)處理節(jié)點。
12.如權(quán)利要求2所述的方法，其中基于所述負載平衡算法確定所述最優(yōu)計算節(jié)點，并且其中所述負載平衡算法利用最優(yōu)計算節(jié)點性能、最低計算成本、輪叫或加權(quán)業(yè)務(wù)分配計算規(guī)則之一。
13.如權(quán)利要求1所述的方法，其中所述業(yè)務(wù)處理節(jié)點包括虛擬機器節(jié)點。
14.如權(quán)利要求1所述的方法，其中所述第二網(wǎng)絡(luò)包括在不同的地理位置分配的業(yè)務(wù)處理節(jié)點。
15.如權(quán)利要求1所述的方法，還包括提供監(jiān)視裝置，用于監(jiān)視所述業(yè)務(wù)處理節(jié)點和所述計算節(jié)點的狀態(tài)。
16.如權(quán)利要求15所述的方法，其中在檢測到失敗的業(yè)務(wù)處理節(jié)點或失敗的計算節(jié)點時，分別將實時網(wǎng)絡(luò)業(yè)務(wù)重定向到非失敗的業(yè)務(wù)處理節(jié)點或?qū)⒖蛻舳苏埱舐酚傻椒鞘〉挠嬎愎?jié)點。
17.如權(quán)利要求15所述的方法，其中基于來自所述監(jiān)控裝置的反饋實時確定所述最優(yōu)計算節(jié)點。
18.如權(quán)利要求1所述的方法，其中所述第二網(wǎng)絡(luò)通過動態(tài)調(diào)整業(yè)務(wù)處理節(jié)點的數(shù)量來實時縮放其處理容量和網(wǎng)絡(luò)容量。
19.如權(quán)利要求1所述的方法，其中所述計算機服務(wù)包括web應(yīng)用、web服務(wù)或電子郵件服務(wù)之一。
20.一種在運行網(wǎng)絡(luò)可接入計算機服務(wù)的計算節(jié)點組提供負載平衡和失效備援的系統(tǒng)，包括在計算節(jié)點組和多個客戶端之間提供網(wǎng)絡(luò)連接的第一網(wǎng)絡(luò)；計算機服務(wù)，其中所述計算機服務(wù)處于所述計算節(jié)點組包括的一個或多個服務(wù)器上， 并經(jīng)由所述第一網(wǎng)絡(luò)可被客戶端接入；包括多個業(yè)務(wù)處理節(jié)點和負載平衡裝置的第二網(wǎng)絡(luò)，并且其中所述負載平衡裝置被配置為在運行所述計算機服務(wù)的所述計算節(jié)點組提供負載平衡；重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置，該網(wǎng)絡(luò)業(yè)務(wù)包括客戶端請求從所述第一網(wǎng)絡(luò)向所述第二網(wǎng)絡(luò)接入所述計算機服務(wù)；選擇所述第二網(wǎng)絡(luò)的業(yè)務(wù)處理節(jié)點的裝置，所述第二網(wǎng)絡(luò)接收所述重定向的網(wǎng)絡(luò)業(yè)務(wù)，對于接入所述計算機服務(wù)的每個客戶端請求，經(jīng)由所述負載平衡裝置確定在由所述業(yè)務(wù)處理節(jié)點運行所述計算機服務(wù)的所述計算節(jié)點組的最優(yōu)計算節(jié)點的裝置；以及經(jīng)由所述第二網(wǎng)絡(luò)由所述業(yè)務(wù)處理節(jié)點將所述客戶端請求路由到所述最優(yōu)計算節(jié)點的裝置。
21.如權(quán)利要求20所述的系統(tǒng)，其中所述負載平衡裝置包括負載平衡和失效備援算法。
22.如權(quán)利要求20所述的系統(tǒng)，其中所述第二網(wǎng)絡(luò)包括強加在所述第一網(wǎng)絡(luò)之上的疊加網(wǎng)。
23.如權(quán)利要求20所述的系統(tǒng)，還包括所述業(yè)務(wù)處理節(jié)點檢查所述重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置以及將所有源自相同的客戶端會話的客戶端請求路由到相同的最優(yōu)計算節(jié)點的裝置。
24.如權(quán)利要求20所述的系統(tǒng)，其中經(jīng)由第一網(wǎng)絡(luò)內(nèi)的域名接入所述網(wǎng)絡(luò)可接入的計算機服務(wù)，并且其中所述重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置分析所述網(wǎng)絡(luò)可接入計算機服務(wù)的所述域名為所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的IP地址。
25.如權(quán)利要求20所述的系統(tǒng)，其中所述網(wǎng)絡(luò)可接入計算機服務(wù)是經(jīng)由第一網(wǎng)絡(luò)內(nèi)的域名接入的，并且其中所述重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置將CNAME添加到所述網(wǎng)絡(luò)可接入計算機服務(wù)的所述域名的域名服務(wù)(DNQ記錄中，并解析CNAME為所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的IP地址。
26.如權(quán)利要求20所述的系統(tǒng)，其中所述網(wǎng)絡(luò)可接入計算機服務(wù)是經(jīng)由第一網(wǎng)絡(luò)內(nèi)的域名接入的，并且其中所述第二網(wǎng)絡(luò)還包括域名服務(wù)器(DNQ節(jié)點，并且其中所述DNS節(jié)點接收所述域名的客戶端DNS查詢并且解析所述網(wǎng)絡(luò)可接入計算機服務(wù)的所述域名為所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的IP地址。
27.如權(quán)利要求20所述的系統(tǒng)，其中基于到該請求發(fā)起的客戶端的所述業(yè)務(wù)處理節(jié)點的地理周邊選擇所述業(yè)務(wù)處理節(jié)點。
28.如權(quán)利要求20所述的系統(tǒng)，其中基于與所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的負載條件相關(guān)的度量來選擇所述業(yè)務(wù)處理節(jié)點。
29.如權(quán)利要求20所述的系統(tǒng)，其中基于與所述第二網(wǎng)絡(luò)的所述業(yè)務(wù)處理節(jié)點的性能統(tǒng)計相關(guān)的度量來選擇所述業(yè)務(wù)處理節(jié)點。
30.如權(quán)利要求20所述的系統(tǒng)，其中基于到所述業(yè)務(wù)處理節(jié)點的映射客戶端的粘性會話表來選擇所述業(yè)務(wù)處理節(jié)點。
31.如權(quán)利要求21所述的系統(tǒng)，其中基于所述負載平衡算法確定所述最優(yōu)計算節(jié)點， 并且其中所述負載平衡算法利用最優(yōu)計算節(jié)點性能、最低計算成本、輪叫或加權(quán)業(yè)務(wù)分配計算規(guī)則之一。
32.如權(quán)利要求20所述的系統(tǒng)，其中所述業(yè)務(wù)處理節(jié)點包括虛擬機器節(jié)點。
33.如權(quán)利要求20所述的系統(tǒng)，其中所述第二網(wǎng)絡(luò)包括在不同的地理位置分配的業(yè)務(wù)處理節(jié)點。
34.如權(quán)利要求20所述的系統(tǒng)，還包括監(jiān)視裝置，并且其中所述監(jiān)視裝置監(jiān)視所述業(yè)務(wù)處理節(jié)點和所述計算節(jié)點的狀態(tài)。
35.如權(quán)利要求34所述的系統(tǒng)，其中在所述監(jiān)視裝置檢測到失敗的業(yè)務(wù)處理節(jié)點或失敗的計算節(jié)點時，所述系統(tǒng)分別將實時網(wǎng)絡(luò)業(yè)務(wù)重定向到非失敗的業(yè)務(wù)處理節(jié)點或?qū)⒖蛻舳苏埱舐酚傻椒鞘〉挠嬎愎?jié)點。
36.如權(quán)利要求34所述的系統(tǒng)，其中基于來自所述監(jiān)控裝置的反饋實時確定所述最優(yōu)計算節(jié)點。
37.如權(quán)利要求20所述的系統(tǒng)，其中所述第二網(wǎng)絡(luò)通過動態(tài)調(diào)整業(yè)務(wù)處理節(jié)點的數(shù)量來實時縮放其處理容量和網(wǎng)絡(luò)容量。
38.如權(quán)利要求20所述的系統(tǒng)，其中所述計算機服務(wù)包括web應(yīng)用、web服務(wù)或電子郵件服務(wù)之一。
全文摘要
一種在運行網(wǎng)絡(luò)可接入計算機服務(wù)的計算節(jié)點組提供負載平衡和失效備援的方法，包括提供計算機服務(wù)，其中所述計算機服務(wù)存在于在所述計算節(jié)點組包含的一個或多個服務(wù)器上，并且經(jīng)由第一網(wǎng)絡(luò)可被客戶端接入；提供包括多個業(yè)務(wù)處理節(jié)點和負載平衡裝置的第二網(wǎng)絡(luò)，并且其中所述負載平衡裝置被配置為在運行所述計算機服務(wù)的所述計算節(jié)點組提供負載平衡；提供重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置，該網(wǎng)絡(luò)業(yè)務(wù)包括客戶端請求從所述第一網(wǎng)絡(luò)向所述第二網(wǎng)絡(luò)接入所述計算機服務(wù)；提供選擇所述第二網(wǎng)絡(luò)的業(yè)務(wù)處理節(jié)點的裝置，所述第二網(wǎng)絡(luò)接收所述重定向的網(wǎng)絡(luò)業(yè)務(wù)，并且經(jīng)由所述重定向網(wǎng)絡(luò)業(yè)務(wù)的裝置重定向所述網(wǎng)絡(luò)業(yè)務(wù)到所述業(yè)務(wù)處理節(jié)點，所述網(wǎng)絡(luò)業(yè)務(wù)包括所述客戶端請求接入所述計算機服務(wù)；對于接入所述計算機服務(wù)的每個客戶端請求，經(jīng)由所述負載平衡裝置確定在由所述業(yè)務(wù)處理節(jié)點運行所述計算機服務(wù)的所述計算節(jié)點集中的最優(yōu)計算節(jié)點；以及經(jīng)由所述第二網(wǎng)絡(luò)由所述業(yè)務(wù)處理節(jié)點將所述客戶端請求路由到所述最優(yōu)計算節(jié)點。
文檔編號H04L12/56GK102439913SQ201080017922
公開日2012年5月2日 申請日期2010年2月26日 優(yōu)先權(quán)日2009年2月27日
發(fā)明者羅伯特·布弗恩, 考持·維, 雷蒙德·斯塔塔 申請人:雅塔公司