專利名稱：一種文件發(fā)布的方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及Web (網(wǎng)頁)服務(wù)器系統(tǒng)，尤其涉及一種向Web服務(wù)器發(fā)布文件的文件 發(fā)布的方法及系統(tǒng)。
背景技術(shù)：
隨著因特網(wǎng)的高速發(fā)展，在傳統(tǒng)的大型門戶網(wǎng)站和新興的IPTV(Interactive Personality Television，個(gè)性化互動(dòng)電視)等業(yè)務(wù)環(huán)境中，直接為用戶提供服務(wù)的Web系 統(tǒng)越來越多地使用了多Web服務(wù)器系統(tǒng)。多個(gè)Web服務(wù)器能夠提高整個(gè)系統(tǒng)的并行處理能 力，在單位時(shí)間內(nèi)能夠響應(yīng)更多的用戶請(qǐng)求。但是，隨之而來的問題是在新的文件上線時(shí)， 很難保證新的文件盡快發(fā)布到所有的Web服務(wù)器上。由于Web服務(wù)器直接連接在公共網(wǎng)絡(luò)上，運(yùn)營(yíng)商從安全角度考慮，在公共網(wǎng)絡(luò)上 通常只開放Web服務(wù)器上的HTTP協(xié)議(Hypertext Transfer Protocol,超文本傳輸協(xié) 議)的端 口禾口 HTTPS 協(xié)議(Hypertext Transfer Protocol over Secure Socket Layer, 安全超文本傳輸協(xié)議)的端口。為了進(jìn)行管理和文件發(fā)布，只會(huì)在內(nèi)部網(wǎng)絡(luò)上允許Web服 務(wù)器以特定端口訪問特定的服務(wù)器以獲取管理指令和更新文件。因此，在Web服務(wù)器之間 只能通過公網(wǎng)的HTTP或HTTPS協(xié)議互相訪問，向Web服務(wù)器發(fā)布文件時(shí)，無法利用現(xiàn)有的 CDN(Content Distribute Network，內(nèi)容分發(fā)網(wǎng)絡(luò))和 P2P (Point to Point，點(diǎn)對(duì)點(diǎn))等文 件發(fā)布技術(shù)，需要采用FTP (File Transfer Protocol，文件傳輸協(xié)議)端口技術(shù)或不受端口 限制的傳輸技術(shù)。如圖1所示，現(xiàn)有的Web服務(wù)器文件發(fā)布技術(shù)是在Web服務(wù)器系統(tǒng)外配置一臺(tái)管 理服務(wù)器和一臺(tái)保存上傳文件以及提供下載文件功能的服務(wù)器(稱為發(fā)布服務(wù)器)，向Web 服務(wù)器發(fā)布文件的過程為第一步將要發(fā)布到Web服務(wù)器的文件，傳輸給發(fā)布服務(wù)器；可以采用以下方式向發(fā)布服務(wù)器傳輸要發(fā)布的文件1、管理服務(wù)器將文件直接下發(fā)給發(fā)布服務(wù)器(圖1中①)。2、由其它系統(tǒng)將文件發(fā)送給發(fā)布服務(wù)器(圖1中②)，再通知管理服務(wù)器文件已下 發(fā)到發(fā)布服務(wù)器(圖1中③)。第二步管理服務(wù)器制定文件發(fā)布計(jì)劃，根據(jù)計(jì)劃向每臺(tái)Web服務(wù)器的后臺(tái)服務(wù) 程序發(fā)送文件更新指令(圖1中④)，要求Web服務(wù)器從發(fā)布服務(wù)器獲取更新的文件；第三步Web服務(wù)器在收到管理服務(wù)器的文件更新指令后，從發(fā)布服務(wù)器獲取更 新的文件(圖1中⑤)，并向管理服務(wù)器上報(bào)結(jié)果。在Web服務(wù)器數(shù)量較少的情況下，上述方式尚且能夠正常工作，但是，當(dāng)Web服務(wù) 器的數(shù)量增加到一定程度后，在發(fā)布文件時(shí)，短時(shí)間內(nèi)大量并發(fā)請(qǐng)求會(huì)使發(fā)布服務(wù)器超負(fù) 荷運(yùn)行甚至阻塞，導(dǎo)致Web服務(wù)器獲取文件失敗，甚至導(dǎo)致發(fā)布服務(wù)器宕機(jī)。為了避免瞬時(shí) 海量并發(fā)操作引起的問題，在現(xiàn)有技術(shù)中也提出了一些優(yōu)化方案。一種優(yōu)化方案是將文件發(fā)布由并行改為串行，不是所有Web服務(wù)器同時(shí)進(jìn)行更新，而是讓W(xué)eb服務(wù)器排隊(duì)，逐個(gè)或逐批更新，第一個(gè)或第一批更新完成后，下一個(gè)或下一 批Web服務(wù)器再進(jìn)行更新。這種方式在發(fā)布任務(wù)比較少并且Web服務(wù)器也比較少的情況下 比較可行，但由于是串行執(zhí)行，存在以下弊端1、由于排隊(duì)和超時(shí)等待等因素，串行執(zhí)行的總時(shí)間比并行長(zhǎng)了很多，如果發(fā)布任 務(wù)很頻繁或者Web服務(wù)器很多，容易導(dǎo)致一個(gè)發(fā)布任務(wù)還沒執(zhí)行完，后續(xù)發(fā)布任務(wù)又到來， 發(fā)布服務(wù)器將始終處于忙碌狀態(tài)，并且任務(wù)無法準(zhǔn)時(shí)完成，隨著任務(wù)的積累問題將更加越嚴(yán)重。2、雖然發(fā)布服務(wù)器一直處于忙碌狀態(tài)，但是，大部分Web服務(wù)器卻因?yàn)樵谂抨?duì)等 待而閑置，白白浪費(fèi)了系統(tǒng)資源。另一種優(yōu)化方案是增加發(fā)布服務(wù)器數(shù)量，讓W(xué)eb服務(wù)器隨機(jī)選擇發(fā)布服務(wù)器，或 者采用其它方式選擇發(fā)布服務(wù)器。但是，這種方式也存在較多問題，如1、由于文件來源很多，很難保證上傳到發(fā)布服務(wù)器上的文件的一致性，進(jìn)而難以 保證Web服務(wù)器上文件的一致性。這個(gè)問題很難發(fā)覺并且很難修復(fù)。2、需要保證任何發(fā)布服務(wù)器均不能宕機(jī)或者出現(xiàn)網(wǎng)絡(luò)故障，否則不但會(huì)出現(xiàn)第一 個(gè)問題，而且依靠故障發(fā)布服務(wù)器提供服務(wù)的Web服務(wù)器改為向其它發(fā)布服務(wù)器請(qǐng)求服務(wù) 后，可能導(dǎo)致其它發(fā)布服務(wù)器相繼超負(fù)荷引起整個(gè)系統(tǒng)宕機(jī)。在發(fā)布服務(wù)器很多的情況下， 保證所有的機(jī)器在任何時(shí)候都正常運(yùn)行是非常困難的。3、最重要的是，并沒有從根本上解決并發(fā)服務(wù)能力低的問題，有限的發(fā)布服務(wù)器 很難跟上Web服務(wù)器的快速增長(zhǎng)。如果隨著Web服務(wù)器的增長(zhǎng)不斷添置造價(jià)昂貴的發(fā)布服 務(wù)器(發(fā)布服務(wù)器往往需要性能很高的服務(wù)器以及網(wǎng)絡(luò)帶寬，甚至磁盤陣列)，會(huì)產(chǎn)生高昂 的成本，降低產(chǎn)品的市場(chǎng)競(jìng)爭(zhēng)力。

發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問題是提供一種文件發(fā)布的方法及系統(tǒng)，解決在采用較多 Web服務(wù)器時(shí)，向Web服務(wù)器發(fā)布文件效率低、擴(kuò)展性差的問題，實(shí)現(xiàn)提高文件發(fā)布的效率。為解決上述技術(shù)問題，本發(fā)明的一種文件發(fā)布的方法，包括管理服務(wù)器通知所選擇的網(wǎng)頁Web服務(wù)器從發(fā)布服務(wù)器獲取更新文件，所選擇的 Web服務(wù)器從發(fā)布服務(wù)器獲取更新文件，完成更新；管理服務(wù)器選擇待更新的Web服務(wù)器，通知所選擇的待更新的Web服務(wù)器從已更 新的Web服務(wù)器獲取更新文件，待更新的Web服務(wù)器從已更新的Web服務(wù)器獲取更新文件， 完成更新。進(jìn)一步地，更新文件為普通文件或特殊文件；當(dāng)更新文件為特殊文件時(shí)，管理服務(wù)器通知待更新的Web服務(wù)器從已更新的Web 服務(wù)器獲取更新文件前，還通知已更新的Web服務(wù)器對(duì)更新文件進(jìn)行點(diǎn)對(duì)點(diǎn)加密；已更新的Web服務(wù)器選擇點(diǎn)對(duì)點(diǎn)加密的方式，并將所選擇的點(diǎn)對(duì)點(diǎn)加密的方式及 加密參數(shù)通過管理服務(wù)器通知待更新的Web服務(wù)器；管理服務(wù)器通知待更新的Web服務(wù)器從已更新的Web服務(wù)器獲取更新文件；待更 新的Web服務(wù)器根據(jù)點(diǎn)對(duì)點(diǎn)加密的方式及加密參數(shù)從已更新的Web服務(wù)器獲取更新文件。進(jìn)一步地，點(diǎn)對(duì)點(diǎn)加密的方式包括采用HTPPS協(xié)議傳輸更新文件；
采用HTTPS協(xié)議傳輸更新文件時(shí)，待更新的Web服務(wù)器根據(jù)點(diǎn)對(duì)點(diǎn)加密的方式及 加密參數(shù)從已更新的Web服務(wù)器獲取更新文件的過程包括待更新的Web服務(wù)器使用加密參數(shù)解密HTPPS傳輸信道，從已更新的Web服務(wù)器 獲取更新文件。進(jìn)一步地，點(diǎn)對(duì)點(diǎn)加密的方式包括對(duì)更新文件進(jìn)行加密，使用超文本傳輸協(xié)議 HTTP傳輸加密后的更新文件；采用對(duì)更新文件進(jìn)行加密，使用HTTP傳輸加密后的更新文件時(shí)，待更新的Web服 務(wù)器根據(jù)點(diǎn)對(duì)點(diǎn)加密的方式及加密參數(shù)從已更新的Web服務(wù)器獲取更新文件的過程包括待更新的Web服務(wù)器從已更新的Web服務(wù)器獲取加密后的更新文件，使用加密參 數(shù)對(duì)加密后的更新文件進(jìn)行解密。進(jìn)一步地，更新文件為普通文件或特殊文件；當(dāng)更新文件為特殊文件時(shí)，管理服務(wù)器在選擇Web服務(wù)器從發(fā)布服務(wù)器獲取更新 文件前，選擇加密算法并生成加密密鑰和解密密鑰，將加密算法、加密密鑰以及更新文件的 文件名通知發(fā)布服務(wù)器；發(fā)布服務(wù)器根據(jù)更新文件的文件名，按照加密算法使用加密密鑰分別對(duì)更新文件 的文件體和文件名加密，并使用加密后的文件名命名加密后的文件體，將加密后的文件名 發(fā)送給管理服務(wù)器；管理服務(wù)器根據(jù)加密后的文件名，執(zhí)行通知所選擇的Web服務(wù)器從發(fā)布服務(wù)器獲 取更新文件的操作，完成對(duì)Web服務(wù)器的更新后，將加密算法、解密密鑰和加密后的文件名 通知完成更新的Web服務(wù)器；完成更新的Web服務(wù)器根據(jù)加密算法，采用解密密鑰分別對(duì)加密后的文件名和文 件體進(jìn)行解密。進(jìn)一步地，管理服務(wù)器根據(jù)Web服務(wù)器選擇策略選擇待更新的Web服務(wù)器，Web服 務(wù)器選擇策略包括但不限于根據(jù)硬件性能對(duì)Web服務(wù)器進(jìn)行排序，按照硬件性能由好到差的順序選擇Web服 務(wù)器；根據(jù)負(fù)荷對(duì)Web服務(wù)器進(jìn)行排序，按照負(fù)荷由低到高的順序選擇Web服務(wù)器；每輪發(fā)布時(shí)，根據(jù)機(jī)器性能和當(dāng)前負(fù)荷參數(shù)計(jì)算出當(dāng)前服務(wù)能力，按當(dāng)前服務(wù)能 力由高到低的順序選擇Web服務(wù)器；預(yù)先配置更新隊(duì)列，按照由前到后的順序選擇Web服務(wù)器。進(jìn)一步地，一種文件發(fā)布系統(tǒng)，包括管理服務(wù)器、發(fā)布服務(wù)器和Web服務(wù)器，其 中管理服務(wù)器，用于通知所選擇的Web服務(wù)器從發(fā)布服務(wù)器獲取更新文件，所選擇 的Web服務(wù)器從發(fā)布服務(wù)器獲取更新文件，完成更新后，管理服務(wù)器還選擇待更新的Web服 務(wù)器，通知所選擇的待更新的Web服務(wù)器從已更新的Web服務(wù)器獲取更新文件；待更新的Web服務(wù)器，用于從已更新的Web服務(wù)器獲取更新文件，完成更新。進(jìn)一步地，更新文件為普通文件或特殊文件；管理服務(wù)器，還用于當(dāng)更新文件為特殊文件時(shí)，在通知待更新的Web服務(wù)器從已 更新的Web服務(wù)器獲取更新文件前，通知已更新的Web服務(wù)器對(duì)更新文件進(jìn)行點(diǎn)對(duì)點(diǎn)加密；已更新的Web服務(wù)器，用于選擇點(diǎn)對(duì)點(diǎn)加密的方式，并將所選擇的點(diǎn)對(duì)點(diǎn)加密的 方式及加密參數(shù)通過管理服務(wù)器通知待更新的Web服務(wù)器；待更新的Web服務(wù)器根據(jù)點(diǎn)對(duì)點(diǎn)加密的方式及加密參數(shù)從已更新的Web服務(wù)器獲 取更新文件。進(jìn)一步地，更新文件為普通文件或特殊文件；管理服務(wù)器，還用于當(dāng)更新文件為特殊文件時(shí)，在選擇Web服務(wù)器從發(fā)布服務(wù)器 獲取更新文件前，選擇加密算法并生成加密密鑰和解密密鑰，將加密算法、加密密鑰以及更 新文件的文件名通知發(fā)布服務(wù)器；并且，根據(jù)接收到的加密后的文件名，執(zhí)行通知所選擇的 Web服務(wù)器從發(fā)布服務(wù)器獲取更新文件的操作，完成對(duì)Web服務(wù)器的更新后，將加密算法、 解密密鑰和加密后的文件名通知完成更新的Web服務(wù)器；發(fā)布服務(wù)器，用于根據(jù)更新文件的文件名，按照加密算法使用加密密鑰分別對(duì)更 新文件的文件體和文件名加密，并使用加密后的文件名命名加密后的文件體，將加密后的 文件名發(fā)送給管理服務(wù)器；完成更新的Web服務(wù)器，用于根據(jù)加密算法，采用解密密鑰分別對(duì)加密后的文件 名和文件體進(jìn)行解密。進(jìn)一步地，管理服務(wù)器根據(jù)Web服務(wù)器選擇策略選擇待更新的Web服務(wù)器，Web服 務(wù)器選擇策略包括但不限于根據(jù)硬件性能對(duì)Web服務(wù)器進(jìn)行排序，按照硬件性能由好到差的順序選擇Web服 務(wù)器；根據(jù)負(fù)荷對(duì)Web服務(wù)器進(jìn)行排序，按照負(fù)荷由低到高的順序選擇Web服務(wù)器；每輪發(fā)布時(shí)，根據(jù)機(jī)器性能和當(dāng)前負(fù)荷參數(shù)計(jì)算出當(dāng)前服務(wù)能力，按當(dāng)前服務(wù)能 力由高到低的順序選擇Web服務(wù)器；預(yù)先配置更新隊(duì)列，按照由前到后的順序選擇Web服務(wù)器。綜上所述，本發(fā)明在不增加硬件、不改動(dòng)現(xiàn)有硬件環(huán)境的前提下，提高了文件發(fā)布 的效率和硬件的利用率。


圖1為現(xiàn)有技術(shù)中向Web服務(wù)器發(fā)布文件的架構(gòu)圖；圖2為本發(fā)明的向Web服務(wù)器發(fā)布文件的1輪的架構(gòu)圖；圖3為本發(fā)明的向Web服務(wù)器發(fā)布文件的2輪的架構(gòu)圖；圖4為本發(fā)明的向Web服務(wù)器發(fā)布文件的3輪的架構(gòu)圖；圖5為本發(fā)明采用點(diǎn)對(duì)點(diǎn)加密的方式發(fā)布特殊文件的架構(gòu)圖；圖6為本發(fā)明采用全局加密方式發(fā)布特殊文件的架構(gòu)圖。
具體實(shí)施例方式本發(fā)明中向Web服務(wù)器發(fā)布文件時(shí)，管理服務(wù)器根據(jù)策略通知一部分待更新的 Web服務(wù)器從發(fā)布服務(wù)器進(jìn)行更新。完成更新后，已完成更新的Web服務(wù)器可以作為其它 未更新的Web服務(wù)器的發(fā)布服務(wù)器，管理服務(wù)器可選擇通知待更新的Web服務(wù)器，從已更新的Web服務(wù)器獲取更新文件，或從發(fā)布服務(wù)器獲取更新文件，進(jìn)而完成全部Web服務(wù)器的更新。管理服務(wù)器在選擇待更新的Web服務(wù)器時(shí)，可以有多種選擇策略，例如1、根據(jù)硬件性能對(duì)Web服務(wù)器進(jìn)行排序，將硬件性能好的優(yōu)先更新。2、根據(jù)負(fù)荷對(duì)Web服務(wù)器進(jìn)行排序，對(duì)負(fù)荷低的優(yōu)先更新。3、每輪發(fā)布時(shí)，根據(jù)機(jī)器性能和當(dāng)前負(fù)荷等參數(shù)，計(jì)算出當(dāng)前服務(wù)能力，按當(dāng)前服 務(wù)能力由高到低的順序選擇Web服務(wù)器。 4、預(yù)先配置更新隊(duì)列，按照先后順序進(jìn)行更新。下面結(jié)合附圖對(duì)本發(fā)明的具體實(shí)施方式
進(jìn)行說明。在Web服務(wù)器上存在兩類文件，一類允許外部直接訪問，如圖片和靜態(tài)HTML頁面 等，以下稱為普通文件；另一類不允許外部直接訪問，如動(dòng)態(tài)網(wǎng)頁的源代碼和庫文件等，以 下稱為特殊文件。特殊文件的傳輸面臨兩個(gè)問題一是Web服務(wù)器之間無法相互讀取這些 文件，例如，JSP和PHP等動(dòng)態(tài)網(wǎng)頁的源文件；二是特殊文件屬于不能向外部泄露的文件， 如，包含口令信息的配置文件。普通文件和特殊文件的的發(fā)布流程在整體上是相同的，但 是，對(duì)特殊文件需要一些特殊處理，下面予以描述。如圖2所示，下面以在系統(tǒng)中存在7臺(tái)Web服務(wù)器為例，為方便描述，以下將管理 服務(wù)器記為M,發(fā)布服務(wù)器記為S，Web服務(wù)器分別標(biāo)記為AB⑶ER；。S采用FTP方式提供文 件發(fā)布功能。為簡(jiǎn)化描述，采用預(yù)先配置更新隊(duì)列的策略選擇待更新的Web服務(wù)器，更新順 序?yàn)?ABCDEFG。普通文件的發(fā)布流程包括步驟1. 1 :M根據(jù)Web服務(wù)器選擇策略選擇A作為第一輪文件發(fā)布的待更新Web服 務(wù)器；步驟1. 2 :M向A發(fā)送文件更新指令(圖2中①)；步驟1. 3 =A接收到M的文件更新指令后，從S獲取更新文件(圖2中②)；步驟1. 4 :A向M報(bào)告文件獲取成功(圖2中③)；此時(shí)，A已經(jīng)完成更新，第一輪發(fā)布完成。下面進(jìn)入第二輪發(fā)布，如圖3所示，在已經(jīng)完成發(fā)布的Web服務(wù)器A上加圈以示區(qū) 別)。步驟2. 1 =M根據(jù)Web服務(wù)器選擇策略選取Web服務(wù)器B和C作為第二輪文件發(fā)布 的待更新Web服務(wù)器；由于A已經(jīng)完成更新，在第二輪文件發(fā)布中將A作為“發(fā)布服務(wù)器”，這樣就存在S 與A兩個(gè)可以發(fā)布文件的服務(wù)器。步驟2. 2 =M分別向B和C發(fā)送文件更新指令，通知B以HTTP方式從A獲取更新文 件，通知C以FTP方式從S獲取更新文件(圖3中①)；步驟2. 3 :B以HTTP方式從A獲取更新文件(圖3中②)，C以FTP方式從S獲取 更新文件(圖3中③)；步驟2.4 :B和C分別向M報(bào)告文件獲取成功(圖3中④和圖3中⑤)；此時(shí)，ABC三臺(tái)Web服務(wù)器均已完成文件更新，下面進(jìn)入第三輪文件發(fā)布，如圖4所 示，在已經(jīng)完成發(fā)布的Web服務(wù)器ABC上加圈以示區(qū)別。
9
步驟3. 1 :M根據(jù)Web服務(wù)器選擇策略選取DER；作為第三輪文件發(fā)布的待更新Web 服務(wù)器；由于ABC都已完成更新，加上S共有四臺(tái)可提供文件發(fā)布的服務(wù)器，因此，可以為 DEFG四個(gè)待更新Web服務(wù)器分別匹配一個(gè)“發(fā)布服務(wù)器”，根據(jù)“發(fā)布服務(wù)器”是Web服務(wù) 器還是真實(shí)的發(fā)布服務(wù)器分別指定是采用HTTP方式還是采用FTP方式獲取文件。步驟3. 2 =M分別向DER；發(fā)送文件更新指令(圖4中①)，通知D以HTTP方式從 C獲取更新文件，通知E以HTTP方式從B獲取更新文件，通知F以HTTP方式從A獲取更新 文件，通知G以FTP方式從S獲取更新文件；步驟3. 3 =DEFG分別從各自指定的服務(wù)器獲取更新文件(圖4中②)；步驟3. 4 =DEFG分別向M報(bào)告文件獲取成功。(限于圖形復(fù)雜，圖4圖不再繪制報(bào) 告的連線)。此時(shí)，文件發(fā)布任務(wù)完成。下面對(duì)特殊文件的發(fā)布流程進(jìn)行說明。由于發(fā)布服務(wù)器在內(nèi)網(wǎng)采用FTP向Web服務(wù)器發(fā)布文件，可以直接傳輸任何文件 而不用擔(dān)心外泄。而將Web服務(wù)器作為“發(fā)布服務(wù)器”時(shí)，則存在Web服務(wù)器之間無法讀取 特殊文件，以及Web服務(wù)器之間在公網(wǎng)上明文傳輸文件帶來的泄密問題。這樣就需要采取 一些額外措施來發(fā)布特殊文件。解決特殊文件的發(fā)布可以采用點(diǎn)對(duì)點(diǎn)加密的方式，即在兩臺(tái)Web服務(wù)器之間進(jìn) 行文件發(fā)布時(shí)，兩臺(tái)服務(wù)器采用可以保護(hù)文件內(nèi)容的加密的方式進(jìn)行文件發(fā)布，而不是直 接傳輸文件。加密的方式包括但是不限于=HTTPS傳輸協(xié)議、文件加密等。為簡(jiǎn)化敘述，下 面僅以HTTPS傳輸協(xié)議、文件加密兩種方式進(jìn)行說明。下面仍以上述在系統(tǒng)中存在7臺(tái)Web服務(wù)器為例，其中，第一輪文件發(fā)布與上述步 驟1. 1 1. 4相同，在第二輪發(fā)布中，當(dāng)M需要指定待更新的Web服務(wù)器從已更新的Web服 務(wù)器獲取更新文件時(shí)，需要按照以下流程處理，包括步驟1 :M將B需要從A獲取更新文件的信息通知A (圖5中①)，并通知A對(duì)更新 文件進(jìn)行點(diǎn)對(duì)點(diǎn)加密；步驟2 =A根據(jù)M的通知，選定一種點(diǎn)對(duì)點(diǎn)加密方式；例如，A可選擇采用HTTPS協(xié)議傳輸數(shù)據(jù)，或者是對(duì)更新文件加密后，采用HTTP傳 輸文件。如果是采用對(duì)更新文件加密，則A需要將更新文件加密。此步驟在一個(gè)發(fā)布任務(wù) 中可以僅做一次，A以后為其它Web服務(wù)器提供文件加密方式的發(fā)布服務(wù)時(shí)，可以重用這個(gè) 已加密的文件。步驟3 :A將點(diǎn)對(duì)點(diǎn)加密方式及加密參數(shù)(加密算法和解密密鑰等)上報(bào)給M(圖 5中②)；步驟4 :M將點(diǎn)對(duì)點(diǎn)加密方式及加密參數(shù)通知B，通知B從A上獲取更新文件(圖5 中③)；步驟5 =B根據(jù)點(diǎn)對(duì)點(diǎn)加密的方式及加密參數(shù)獲取更新文件(圖5中④)；采用HTTPS協(xié)議傳輸更新文件時(shí)，待更新的Web服務(wù)器使用加密參數(shù)解密HTPPS 傳輸信道，從已更新的Web服務(wù)器獲取更新文件。采用對(duì)更新文件進(jìn)行加密，使用HTTP傳 輸加密后的更新文件時(shí)，待更新的Web服務(wù)器從已更新的Web服務(wù)器獲取加密后的更新文件，使用加密參數(shù)對(duì)加密后的更新文件進(jìn)行解密。步驟6 :B向M報(bào)告文件獲取成功(圖5中⑤)。此時(shí)Web服務(wù)器之間的特殊文件的發(fā)布完成一輪，以后每一輪的發(fā)布都采用相同 的方式處理，在此不再贅述。當(dāng)所有Web服務(wù)器都更新完成后，M通知所有發(fā)布過特殊文件 的Web服務(wù)器將本地加密后的特殊文件刪除。此方案的優(yōu)點(diǎn)在于各Web服務(wù)器可以根據(jù)自身情況決定自己在發(fā)布文件時(shí)采用 何種方式，不需要所有的Web服務(wù)器都具有統(tǒng)一的軟、硬件環(huán)境。同時(shí)，加密方式還可以組 合起來使用，例如同時(shí)應(yīng)用HTTPS和文件加密，以進(jìn)一步提高安全性。對(duì)特殊文件的發(fā)布也可以采用對(duì)全局文件加密，此方案需要發(fā)布服務(wù)器至少具有 文件加密功能，所有的Web服務(wù)器至少具有文件解密功能，具體過程包括步驟a 在發(fā)布文件前，M選擇加密算法并生成密鑰；密鑰包含加密密鑰和解密密鑰，密鑰的具體形式取決于所用的加密算法，如果是 對(duì)稱加密算法則兩者相同，密鑰強(qiáng)度要求在可接受的時(shí)間內(nèi)加密后的文件不能被破解即可。步驟b :M將加密算法、加密密鑰和更新文件的文件名發(fā)送給S (圖6中①)；步驟c =S按照加密算法，使用加密密鑰對(duì)更新文件的文件體和文件名分別加密， 并使用加密后的文件名對(duì)加密后的文件體命名，將加密后的文件名發(fā)送給M(圖6中②)；步驟d :M按照上述步驟1. 1 3. 4的過程發(fā)布加密后的更新文件(圖6中未繪制 該流程)；步驟e 完成向Web服務(wù)器發(fā)布加密后的更新文件后，M將加密算法、解密密鑰和加 密后的文件名等解密所需的信息發(fā)送給完成更新的Web服務(wù)器(圖6中③)；步驟f:完成更新的Web服務(wù)器根據(jù)加密算法，采用解密密鑰分別對(duì)加密后的文件 名和文件體進(jìn)行解密。此方案不需要Web服務(wù)器提供HTTPS服務(wù)，系統(tǒng)只需進(jìn)行一次文件加密，節(jié)省了軟 件資源。同時(shí)，此方案與點(diǎn)對(duì)點(diǎn)加密的方案并不沖突，可以聯(lián)合使用，進(jìn)一步提高Web服務(wù) 器之間進(jìn)行文件發(fā)布時(shí)的安全性。本發(fā)明還提供了一種文件發(fā)布的系統(tǒng)，包括管理服務(wù)器、發(fā)布服務(wù)器和Web服務(wù) 器，其中，管理服務(wù)器，用于根據(jù)Web服務(wù)器選擇策略選擇待更新Web服務(wù)器，向待更新Web 服務(wù)器發(fā)送文件更新指令，將待更新的Web服務(wù)器需要從已更新的Web服務(wù)器獲取更新文 件的信息通知已更新的Web服務(wù)器，并通知已更新的Web服務(wù)器對(duì)更新文件進(jìn)行點(diǎn)對(duì)點(diǎn)加 密；將接收到的點(diǎn)對(duì)點(diǎn)加密方式及加密參數(shù)通知待更新的Web服務(wù)器，通知待更新的Web服 務(wù)器從已更新的Web服務(wù)器上獲取更新文件；在發(fā)布文件前，選擇加密算法并生成密鑰，將 加密算法、加密密鑰和更新文件的文件名發(fā)送給發(fā)布服務(wù)器，將加密算法、解密密鑰和加密 后的文件名等解密所需的信息發(fā)送給完成更新的Web服務(wù)器，完成更新的Web服務(wù)器根據(jù) 加密算法，采用解密密鑰分別對(duì)加密后的文件名和文件體進(jìn)行解密。待更新的Web服務(wù)器，用于根據(jù)管理服務(wù)器的指令，從發(fā)布服務(wù)器或已更新的Web 服務(wù)器獲取更新文件，并向管理服務(wù)器上報(bào)獲取結(jié)果，當(dāng)更新文件為特殊文件時(shí)，根據(jù)接收 到的點(diǎn)對(duì)點(diǎn)加密的方式及加密參數(shù)獲取更新文件。
已更新的Web服務(wù)器服務(wù)器，用于根據(jù)管理服務(wù)器的通知，選定一種點(diǎn)對(duì)點(diǎn)加密 方式，將點(diǎn)對(duì)點(diǎn)加密方式及加密參數(shù)(加密算法和解密密鑰等)上報(bào)給管理服務(wù)器。發(fā)布服務(wù)器，用于儲(chǔ)存需要發(fā)布的文件并響應(yīng)Web服務(wù)器的請(qǐng)求，為其提供文件 (原始文件或加密后的文件)；按照加密算法，使用加密密鑰對(duì)更新文件的文件體和文件名 分別加密，并使用加密后的文件名對(duì)加密后的文件體命名，將加密后的文件名發(fā)送給管理 服務(wù)器。應(yīng)當(dāng)理解的是，對(duì)本發(fā)明技術(shù)所在領(lǐng)域的普通技術(shù)人員來說，可以根據(jù)本發(fā)明的 技術(shù)方案及其構(gòu)思進(jìn)行相應(yīng)的等同改變或替換，而所有這些改變或替換，都應(yīng)屬于本發(fā)明 所附權(quán)利要求的保護(hù)范圍。
權(quán)利要求
1. 一種文件發(fā)布的方法，包括管理服務(wù)器通知所選擇的網(wǎng)頁Web服務(wù)器從發(fā)布服務(wù)器獲取更新文件，所選擇的Web 服務(wù)器從所述發(fā)布服務(wù)器獲取更新文件，完成更新；所述管理服務(wù)器選擇待更新的Web服務(wù)器，通知所選擇的待更新的Web服務(wù)器從已更 新的Web服務(wù)器獲取更新文件，所述待更新的Web服務(wù)器從所述已更新的Web服務(wù)器獲取 更新文件，完成更新。
2.如權(quán)利要求1所述的方法，其特征在于，所述更新文件為普通文件或特殊文件；當(dāng)所述更新文件為特殊文件時(shí)，所述管理服務(wù)器通知所述待更新的Web服務(wù)器從已更 新的Web服務(wù)器獲取更新文件前，還通知所述已更新的Web服務(wù)器對(duì)更新文件進(jìn)行點(diǎn)對(duì)點(diǎn) 加密；所述已更新的Web服務(wù)器選擇點(diǎn)對(duì)點(diǎn)加密的方式，并將所選擇的點(diǎn)對(duì)點(diǎn)加密的方式及 加密參數(shù)通過管理服務(wù)器通知所述待更新的Web服務(wù)器；所述管理服務(wù)器通知待更新的Web服務(wù)器從已更新的Web服務(wù)器獲取更新文件；所述 待更新的Web服務(wù)器根據(jù)點(diǎn)對(duì)點(diǎn)加密的方式及加密參數(shù)從所述已更新的Web服務(wù)器獲取更 新文件。
3.如權(quán)利要求2所述的方法，其特征在于，所述點(diǎn)對(duì)點(diǎn)加密的方式包括采用HTPPS協(xié)議傳輸更新文件；采用HTTPS協(xié)議傳輸更新文件時(shí)，待更新的Web服務(wù)器根據(jù)點(diǎn)對(duì)點(diǎn)加密的方式及加密 參數(shù)從所述已更新的Web服務(wù)器獲取更新文件的過程包括所述待更新的Web服務(wù)器使用加密參數(shù)解密HTPPS傳輸信道，從已更新的Web服務(wù)器 獲取更新文件。
4.如權(quán)利要求2所述的方法，其特征在于，所述點(diǎn)對(duì)點(diǎn)加密的方式包括對(duì)更新文件進(jìn)行加密，使用超文本傳輸協(xié)議HTTP傳輸加 密后的更新文件；采用對(duì)更新文件進(jìn)行加密，使用HTTP傳輸加密后的更新文件時(shí)，所述待更新的Web服 務(wù)器根據(jù)點(diǎn)對(duì)點(diǎn)加密的方式及加密參數(shù)從所述已更新的Web服務(wù)器獲取更新文件的過程 包括所述待更新的Web服務(wù)器從所述已更新的Web服務(wù)器獲取加密后的更新文件，使用加 密參數(shù)對(duì)加密后的更新文件進(jìn)行解密。
5.如權(quán)利要求1所述的方法，其特征在于，所述更新文件為普通文件或特殊文件；當(dāng)所述更新文件為特殊文件時(shí)，所述管理服務(wù)器在選擇Web服務(wù)器從發(fā)布服務(wù)器獲取 更新文件前，選擇加密算法并生成加密密鑰和解密密鑰，將所述加密算法、加密密鑰以及更 新文件的文件名通知發(fā)布服務(wù)器；所述發(fā)布服務(wù)器根據(jù)更新文件的文件名，按照加密算法使用加密密鑰分別對(duì)更新文件 的文件體和文件名加密，并使用加密后的文件名命名加密后的文件體，將加密后的文件名 發(fā)送給管理服務(wù)器；所述管理服務(wù)器根據(jù)加密后的文件名，執(zhí)行所述通知所選擇的Web服務(wù)器從發(fā)布服務(wù)器獲取更新文件的操作，完成對(duì)Web服務(wù)器的更新后，將加密算法、解密密鑰和加密后的文 件名通知完成更新的Web服務(wù)器；所述完成更新的Web服務(wù)器根據(jù)加密算法，采用解密密鑰分別對(duì)加密后的文件名和文 件體進(jìn)行解密。
6.如權(quán)利要求1所述的方法，其特征在于，所述管理服務(wù)器根據(jù)Web服務(wù)器選擇策略選 擇待更新的Web服務(wù)器，所述Web服務(wù)器選擇策略包括但不限于根據(jù)硬件性能對(duì)Web服務(wù)器進(jìn)行排序，按照硬件性能由好到差的順序選擇Web服務(wù)器；根據(jù)負(fù)荷對(duì)Web服務(wù)器進(jìn)行排序，按照負(fù)荷由低到高的順序選擇Web服務(wù)器； 每輪發(fā)布時(shí)，根據(jù)機(jī)器性能和當(dāng)前負(fù)荷參數(shù)計(jì)算出當(dāng)前服務(wù)能力，按當(dāng)前服務(wù)能力由 高到低的順序選擇Web服務(wù)器；預(yù)先配置更新隊(duì)列，按照由前到后的順序選擇Web服務(wù)器。
7.一種文件發(fā)布系統(tǒng)，包括管理服務(wù)器、發(fā)布服務(wù)器和Web服務(wù)器，其中所述管理服務(wù)器，用于通知所選擇的Web服務(wù)器從發(fā)布服務(wù)器獲取更新文件，所選擇 的Web服務(wù)器從所述發(fā)布服務(wù)器獲取更新文件，完成更新后，所述管理服務(wù)器還選擇待更 新的Web服務(wù)器，通知所選擇的待更新的Web服務(wù)器從已更新的Web服務(wù)器獲取更新文件； 所述待更新的Web服務(wù)器，用于從所述已更新的Web服務(wù)器獲取更新文件，完成更新。
8.如權(quán)利要求7所述的系統(tǒng)，其特征在于， 所述更新文件為普通文件或特殊文件；所述管理服務(wù)器，還用于當(dāng)所述更新文件為特殊文件時(shí)，在通知所述待更新的Web服 務(wù)器從已更新的Web服務(wù)器獲取更新文件前，通知所述已更新的Web服務(wù)器對(duì)更新文件進(jìn) 行點(diǎn)對(duì)點(diǎn)加密；所述已更新的Web服務(wù)器，用于選擇點(diǎn)對(duì)點(diǎn)加密的方式，并將所選擇的點(diǎn)對(duì)點(diǎn)加密的 方式及加密參數(shù)通過管理服務(wù)器通知所述待更新的Web服務(wù)器；所述待更新的Web服務(wù)器根據(jù)點(diǎn)對(duì)點(diǎn)加密的方式及加密參數(shù)從所述已更新的Web服務(wù) 器獲取更新文件。
9.如權(quán)利要求7所述的系統(tǒng)，其特征在于， 所述更新文件為普通文件或特殊文件；所述管理服務(wù)器，還用于當(dāng)所述更新文件為特殊文件時(shí)，在選擇Web服務(wù)器從發(fā)布服 務(wù)器獲取更新文件前，選擇加密算法并生成加密密鑰和解密密鑰，將所述加密算法、加密密 鑰以及更新文件的文件名通知發(fā)布服務(wù)器；并且，根據(jù)接收到的加密后的文件名，執(zhí)行所述 通知所選擇的Web服務(wù)器從發(fā)布服務(wù)器獲取更新文件的操作，完成對(duì)Web服務(wù)器的更新后， 將加密算法、解密密鑰和加密后的文件名通知完成更新的Web服務(wù)器；所述發(fā)布服務(wù)器，用于根據(jù)更新文件的文件名，按照加密算法使用加密密鑰分別對(duì)更 新文件的文件體和文件名加密，并使用加密后的文件名命名加密后的文件體，將加密后的 文件名發(fā)送給管理服務(wù)器；所述完成更新的Web服務(wù)器，用于根據(jù)加密算法，采用解密密鑰分別對(duì)加密后的文件 名和文件體進(jìn)行解密。
10.如權(quán)利要求7所述的系統(tǒng)，其特征在于，所述管理服務(wù)器根據(jù)Web服務(wù)器選擇策略選擇待更新的Web服務(wù)器，所述Web服務(wù)器 選擇策略包括但不限于根據(jù)硬件性能對(duì)Web服務(wù)器進(jìn)行排序，按照硬件性能由好到差的順序選擇Web服務(wù)器；根據(jù)負(fù)荷對(duì)Web服務(wù)器進(jìn)行排序，按照負(fù)荷由低到高的順序選擇Web服務(wù)器； 每輪發(fā)布時(shí)，根據(jù)機(jī)器性能和當(dāng)前負(fù)荷參數(shù)計(jì)算出當(dāng)前服務(wù)能力，按當(dāng)前服務(wù)能力由 高到低的順序選擇Web服務(wù)器；預(yù)先配置更新隊(duì)列，按照由前到后的順序選擇Web服務(wù)器。
全文摘要
本發(fā)明公開了一種文件發(fā)布的方法，包括管理服務(wù)器通知所選擇的網(wǎng)頁Web服務(wù)器從發(fā)布服務(wù)器獲取更新文件，所選擇的Web服務(wù)器從發(fā)布服務(wù)器獲取更新文件，完成更新；管理服務(wù)器選擇待更新的Web服務(wù)器，通知所選擇的待更新的Web服務(wù)器從已更新的Web服務(wù)器獲取更新文件，待更新的Web服務(wù)器從已更新的Web服務(wù)器獲取更新文件，完成更新。本發(fā)明在不增加硬件、不改動(dòng)現(xiàn)有硬件環(huán)境的前提下，提高了文件發(fā)布的效率和硬件的利用率。
文檔編號(hào)H04L29/06GK101997896SQ20091016489
公開日2011年3月30日 申請(qǐng)日期2009年8月19日 優(yōu)先權(quán)日2009年8月19日
發(fā)明者于華 申請(qǐng)人:中興通訊股份有限公司