[發(fā)明專利]一種Web應(yīng)用服務(wù)方法和系統(tǒng)

有效

• 申請(qǐng)?zhí)枺?/td>: 201310213891.4
• 申請(qǐng)日: 2013-05-31
• 公開(kāi)（公告）號(hào): CN103259870A
• 公開(kāi)（公告）日: 2013-08-21
• 發(fā)明（設(shè)計(jì)）人: 胡奇
• 申請(qǐng)（專利權(quán)）人: 北京京東尚科信息技術(shù)有限公司
• 主分類號(hào): H04L29/08
• 分類號(hào): H04L29/08
• 代理公司: 北京邦信陽(yáng)專利商標(biāo)代理有限公司 11012
• 代理人: 王昭林;胡冰

技術(shù)領(lǐng)域

本發(fā)明屬于Web應(yīng)用領(lǐng)域，涉及一種Web應(yīng)用服務(wù)方法和系統(tǒng)。

背景技術(shù)

隨著網(wǎng)絡(luò)信息技術(shù)在人類生活中的地位越來(lái)越重要，互聯(lián)網(wǎng)站承載的信息量也越來(lái)越巨大，特別是作為信息主入口的網(wǎng)站門(mén)戶頁(yè)面更承受著海量的訪問(wèn)，需要快速的展現(xiàn)訪問(wèn)結(jié)果，更加無(wú)法承受不能服務(wù)的損失，一旦門(mén)戶頁(yè)面不能訪問(wèn)，即使其它頁(yè)面都沒(méi)有問(wèn)題，用戶也會(huì)因?yàn)闆](méi)有入口而喪失對(duì)整個(gè)網(wǎng)站的體驗(yàn)。跟進(jìn)一步，對(duì)于需要實(shí)時(shí)展現(xiàn)來(lái)自不同業(yè)務(wù)模塊、不同數(shù)據(jù)源的動(dòng)態(tài)門(mén)戶頁(yè)面，因?yàn)橛脩羝鋵?duì)后臺(tái)數(shù)據(jù)即時(shí)性的需求，無(wú)法忍受頁(yè)面靜態(tài)化的延遲，因此門(mén)戶網(wǎng)站壓力更為巨大，一旦后臺(tái)任何一個(gè)數(shù)據(jù)來(lái)源出現(xiàn)問(wèn)題，不僅單個(gè)頁(yè)面無(wú)法展示，甚至有可能拖垮整個(gè)Web應(yīng)用服務(wù)器。

現(xiàn)有技術(shù)展現(xiàn)網(wǎng)頁(yè)一般是基于同步的請(qǐng)求-應(yīng)答模式，即客戶端（可以是計(jì)算機(jī)或移動(dòng)終端的瀏覽器）向服務(wù)器發(fā)出一個(gè)請(qǐng)求（request），服務(wù)器收到請(qǐng)求后進(jìn)行后臺(tái)處理，這些處理包括但不限于內(nèi)存運(yùn)算、Socket讀寫(xiě)、文件或數(shù)據(jù)庫(kù)讀寫(xiě)等，處理完成后服務(wù)器向客戶端應(yīng)答（response）,應(yīng)答內(nèi)容包括但不限于狀態(tài)碼（status?code）、應(yīng)答頭（response?header）、消息體（response?body）等，一次請(qǐng)求-應(yīng)答處理一般只有1個(gè)HTTP主線程，并且是同步進(jìn)行的。

對(duì)于后臺(tái)處理需要訪問(wèn)多個(gè)數(shù)據(jù)源且無(wú)法保證數(shù)據(jù)源可靠性的應(yīng)用，如果使用同步請(qǐng)求-應(yīng)答模式執(zhí)行，一旦任何一段業(yè)務(wù)邏輯或數(shù)據(jù)源出現(xiàn)問(wèn)題，例如處理性能下降或網(wǎng)絡(luò)中斷，那么都將影響到主線程的應(yīng)答，輕則相關(guān)頁(yè)面無(wú)法顯示，重則Web應(yīng)用服務(wù)器前端被大量請(qǐng)求阻塞（因?yàn)楹笈_(tái)數(shù)據(jù)源阻塞），導(dǎo)致無(wú)法響應(yīng)任何應(yīng)答，整個(gè)應(yīng)用程序都不可用。

現(xiàn)有的web應(yīng)用技術(shù)有異步加載的，例如Portal技術(shù)，其一般是在主頁(yè)面框架內(nèi)嵌入多個(gè)子模塊（Portlet）,子模塊可以隨主頁(yè)面框架同步加載，也可以異步加載，但后者一般需要新開(kāi)啟一個(gè)HTTP主線程，例如使用HTTP/1.1規(guī)范的IFrame技術(shù)實(shí)現(xiàn)。

如果采用類似IFrame等技術(shù)實(shí)現(xiàn)的異步加載機(jī)制，雖然可以在某種程度上避免整個(gè)應(yīng)用程序不可用，但是仍然不能避免后臺(tái)出現(xiàn)問(wèn)題影響前端展現(xiàn)美觀和響應(yīng)速度。同時(shí)每個(gè)異步加載的模塊都需要新開(kāi)啟一個(gè)HTTP主線程，會(huì)占用Web應(yīng)用服務(wù)器有限的連接數(shù)，并且系統(tǒng)開(kāi)銷也會(huì)成倍增加，難以應(yīng)對(duì)互聯(lián)網(wǎng)海量訪問(wèn)的情況。

綜上所述，現(xiàn)有技術(shù)存在面對(duì)海量訪問(wèn)時(shí)，無(wú)法保證動(dòng)態(tài)實(shí)時(shí)應(yīng)答，進(jìn)而喪失服務(wù)體驗(yàn)的問(wèn)題。

發(fā)明內(nèi)容

針對(duì)現(xiàn)有技術(shù)中的問(wèn)題，本發(fā)明提供一種Web應(yīng)用服務(wù)方法，包括：A）收到客戶端的請(qǐng)求后，建立一個(gè)主線程；B）在主線程中，生成所述請(qǐng)求的副本；C）在主線程中，將所述副本分發(fā)到所涉及的業(yè)務(wù)模塊，并設(shè)置超時(shí)響應(yīng)時(shí)間；D）所涉及的業(yè)務(wù)模塊執(zhí)行請(qǐng)求的業(yè)務(wù)；E）在主線程中，在所述超時(shí)響應(yīng)時(shí)間內(nèi)等待所涉及的業(yè)務(wù)模塊的執(zhí)行結(jié)果；F)在主線程中，根據(jù)所述執(zhí)行結(jié)果和超時(shí)情況，向客戶端發(fā)送應(yīng)答；G）終止該主線程。

本發(fā)明提供一種Web應(yīng)用服務(wù)系統(tǒng)，包括服務(wù)端控制器和至少一個(gè)業(yè)務(wù)模塊，

所述服務(wù)端控制器被配置為用于接收來(lái)自客戶端的請(qǐng)求，并建立一個(gè)主線程，在主線程中：生成所述請(qǐng)求的副本；將所述副本分發(fā)到所涉及的業(yè)務(wù)模塊，并設(shè)置超時(shí)響應(yīng)時(shí)間；在所述超時(shí)響應(yīng)時(shí)間內(nèi)等待所涉及的業(yè)務(wù)模塊的執(zhí)行結(jié)果；根據(jù)所述執(zhí)行結(jié)果和超時(shí)情況，向客戶端發(fā)送應(yīng)答；

所述業(yè)務(wù)模塊被配置為響應(yīng)于接收到請(qǐng)求的副本而執(zhí)行業(yè)務(wù)；

其中，所述服務(wù)端控制器被配置為在向客戶端發(fā)送應(yīng)答后終止該主線程。

在本發(fā)明中，即使后臺(tái)某個(gè)業(yè)務(wù)模塊出現(xiàn)嚴(yán)重問(wèn)題，只要主線程服務(wù)是獨(dú)立、健康的，則服務(wù)響應(yīng)的及時(shí)性、有效性和可用性都能得到保證和控制，并且本方法對(duì)系統(tǒng)資源的額外開(kāi)銷很小，能夠適應(yīng)互聯(lián)網(wǎng)應(yīng)用海量并發(fā)的情況。

而且，一旦某個(gè)后臺(tái)應(yīng)用模塊出了問(wèn)題無(wú)法響應(yīng)，只要HTTP請(qǐng)求的主線程健康，其它應(yīng)用模塊的響應(yīng)和整體的服務(wù)都不受到影響，保證快速準(zhǔn)確的返回，并且前端頁(yè)面展示的美觀也不受到影響。

本發(fā)明可以有效的避免因數(shù)據(jù)源不可靠、程序死鎖、外部業(yè)務(wù)服務(wù)調(diào)用阻塞等難以控制的因素長(zhǎng)時(shí)間阻塞Web服務(wù)器的HTTP主線程，從而引發(fā)頁(yè)面展示慢、頁(yè)面無(wú)法展示甚至Web服務(wù)器資源耗盡等導(dǎo)致宕機(jī)、重啟的嚴(yán)重問(wèn)題。能大幅度增強(qiáng)依賴多個(gè)數(shù)據(jù)源、多個(gè)外部服務(wù)、需要?jiǎng)討B(tài)展現(xiàn)的Web應(yīng)用服務(wù)的健壯性。

附圖說(shuō)明

圖1顯示了本發(fā)明的方法的一個(gè)實(shí)施例的流程圖；

圖2為本發(fā)明的系統(tǒng)的結(jié)構(gòu)圖的一個(gè)實(shí)施例；

圖3為圖2中的系統(tǒng)的時(shí)序圖。