專利名稱：一種網(wǎng)絡(luò)業(yè)務(wù)請求的處理系統(tǒng)及其方法
技術(shù)領(lǐng)域：
本發(fā)明涉及互聯(lián)網(wǎng)和電信業(yè)務(wù)系統(tǒng)，特別是涉及增值業(yè)務(wù)領(lǐng)域和HTTP(Hyper Text Transfer Protocol,超文本傳輸協(xié)議)及類似協(xié)議請求和響應(yīng)的 處理系統(tǒng)及其方法。
背景技術(shù)：
隨著無線帶寬的提高，增值業(yè)務(wù)在移動通訊中占有越來越重要的地位。目 前很多增值業(yè)務(wù)系統(tǒng)都使用HTTP或其他網(wǎng)絡(luò)協(xié)議(如SMTP、 SIP、 SOAP、 WAP等，與使用HTTP協(xié)議等同)與客戶端交互， 一般的處理流程為HTTP服務(wù)器接受來自客戶端的業(yè)務(wù)請求，然后將該業(yè)務(wù)請求轉(zhuǎn)交給其他網(wǎng)元進(jìn)行處 理；其他網(wǎng)元完成業(yè)務(wù)處理之后由HTTP服務(wù)器將處理結(jié)果返回給客戶端。其 中，SMTP(Simple Mail Transfer Protocol)為簡單郵件傳輸協(xié)議，SIP(Session Initiation Protocol)為會話發(fā)起協(xié)議，SOAP(Simple Object Access Protocol)為簡 單對象訪問協(xié)議，WAP(Wireless Application Protocol)為無線應(yīng)用協(xié)議。對于并發(fā)的HTTP請求，傳統(tǒng)的HTTP服務(wù)器采取的策略是為每 一個(gè)業(yè)務(wù) 請求分配一個(gè)單獨(dú)的線程來處理，該線程一直到響應(yīng)結(jié)束后才能被回收。這樣 的處理方法對于響應(yīng)時(shí)間較短的系統(tǒng)來說是合適的，因?yàn)橐粋€(gè)業(yè)務(wù)請求不會長 時(shí)間占用一個(gè)線程，該線程相關(guān)的資源能很快被回收。但是在移動通訊領(lǐng)域的很多增值業(yè)務(wù)系統(tǒng)，HTTP的響應(yīng)時(shí)間比普通網(wǎng)站 的響應(yīng)時(shí)間長得多。在這些增值業(yè)務(wù)系統(tǒng)中，對一個(gè)業(yè)務(wù)請求的處理需多個(gè)網(wǎng) 元的多次交互才能完成，有些網(wǎng)元還是跨地域的，交互時(shí)間較長；有些網(wǎng)元由 于同時(shí)訪問的移動用戶數(shù)量多，本身負(fù)載就較重，響應(yīng)較慢；有些網(wǎng)元與外界 交互采取異步方式，只能保證準(zhǔn)實(shí)時(shí)響應(yīng)。例如，某增值業(yè)務(wù)，涉及的跨地域 的網(wǎng)元超過10個(gè)，平均響應(yīng)時(shí)間在30秒鐘以上，忙時(shí)響應(yīng)時(shí)間甚至可能達(dá)到 2-5分鐘。在這種情況下，如果HTTP服務(wù)器還是按傳統(tǒng)的處理方法，為每一個(gè)業(yè)務(wù)
請求分配一個(gè)單獨(dú)的線程，那么HTTP服務(wù)器的并發(fā)處理能力將急劇卜-降。這 是由于在請求處理過程中，該請求占用了 -個(gè)線程，當(dāng)其他網(wǎng)元進(jìn)行業(yè)務(wù)處理 時(shí)，這個(gè)線程只能等待并占用系統(tǒng)資源；其他網(wǎng)元處理業(yè)務(wù)需要的時(shí)間越長， 該線程等待的時(shí)間就越長，從而在單位時(shí)間內(nèi)處理的請求數(shù)就越少。因此，系 統(tǒng)要提高并發(fā)處理能力，HTTP服務(wù)器就必須創(chuàng)建大量的線程，并且每個(gè)線程 的利用率都非常低，而線程是一種數(shù)量非常有限的資源；并且隨著線程數(shù)量的 增加，線程間切換的代價(jià)也變大，從而降低了 CPU(Center Processing Unit，中 央處理器)的利用率。發(fā)明內(nèi)容本發(fā)明所要解決的技術(shù)問題在于提供一種網(wǎng)絡(luò)業(yè)務(wù)請求的處理系統(tǒng)及其 方法，用于解決電信增值業(yè)務(wù)處理時(shí)間較長導(dǎo)致接入服務(wù)器并發(fā)處理能力較 低，占用資源過多的問題。為了實(shí)現(xiàn)上述目的，本發(fā)明提供了一種網(wǎng)絡(luò)業(yè)務(wù)請求的處理系統(tǒng)，包括順 次連接的客戶端、服務(wù)器，其特征在于，所述服務(wù)器又包括一通訊處理模塊，用于與所述客戶端進(jìn)行通訊；一協(xié)議處理模塊，用于根據(jù)協(xié)議將所述通訊處理模塊轉(zhuǎn)發(fā)的請求數(shù)據(jù)包解 析成所述協(xié)議對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，將接收的響應(yīng)數(shù)據(jù)結(jié)構(gòu)構(gòu)造成所述協(xié)議對應(yīng)的 響應(yīng)數(shù)據(jù)包，再轉(zhuǎn)發(fā)至所述通訊處理模塊，并負(fù)責(zé)請求、響應(yīng)的調(diào)度；及一業(yè)務(wù)處理模塊，用于接收并根據(jù)所述協(xié)議處理模塊發(fā)送的數(shù)據(jù)進(jìn)行業(yè)務(wù) 處理，并將處理結(jié)果再轉(zhuǎn)發(fā)至所述協(xié)議處理模塊；所述通訊處理模塊與所述協(xié)議處理模塊之間、所述協(xié)議處理模塊與所述業(yè) 務(wù)處理模塊之間均通過異步消息進(jìn)行通信。所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理系統(tǒng)，其中，所述協(xié)議處理模塊、所述業(yè)務(wù)處 理模塊皆為多個(gè)。所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理系統(tǒng)，其中，所述每一業(yè)務(wù)處理模塊設(shè)置有一 個(gè)或多個(gè)業(yè)務(wù)處理器。所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理系統(tǒng)，其中，所述客戶端與所述通訊處理模塊 之間的接口協(xié)議包括HTTP協(xié)議、SMTP、 SOAP協(xié)議、SIP協(xié)議及WAP協(xié)議。 所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理系統(tǒng)，其中，所述通訊處理模塊通過異步套接 字方式與所述協(xié)議處理模塊通信。為了實(shí)現(xiàn)上述目的，本發(fā)明還一種利用所述系統(tǒng)實(shí)現(xiàn)網(wǎng)絡(luò)業(yè)務(wù)請求的處理 方法，其特征在于，包括一通訊處理步驟，用于與所述客戶端進(jìn)行通訊；一協(xié)議處理步驟，用于根據(jù)協(xié)議將所述通訊處理模塊轉(zhuǎn)發(fā)的請求數(shù)據(jù)包解 析成所述協(xié)議對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，將接收的響應(yīng)數(shù)據(jù)結(jié)構(gòu)構(gòu)造成所述協(xié)議對應(yīng)的 響應(yīng)數(shù)據(jù)包，再轉(zhuǎn)發(fā)至所述通訊處理模塊，并負(fù)責(zé)請求、響應(yīng)的調(diào)度；及一業(yè)務(wù)處理步驟，用于接收并根據(jù)所述協(xié)議處理模塊發(fā)送的數(shù)據(jù)進(jìn)行業(yè)務(wù) 處理，并將處理結(jié)果再轉(zhuǎn)發(fā)至所述協(xié)議處理模塊；所述通訊處理模塊與所述協(xié)議處理模塊之間、所述協(xié)議處理模塊與所述業(yè) 務(wù)處理模塊之間均通過異步消息進(jìn)行通信。所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理方法，其中，還包括一請求接收處理步驟，具 體為步驟71，由所述通訊處理模塊接收所述客戶端發(fā)送的請求數(shù)據(jù)包并轉(zhuǎn)發(fā) 至所述協(xié)議處理模塊；步驟72，通過所述協(xié)議處理模塊根據(jù)一特定協(xié)議解析所述請求數(shù)據(jù)包， 構(gòu)造成一內(nèi)部數(shù)據(jù)結(jié)構(gòu)，并通過異步消息轉(zhuǎn)發(fā)至所述業(yè)務(wù)處理模塊；及步驟73，由所述業(yè)務(wù)處理模塊接收并根據(jù)所述內(nèi)部數(shù)據(jù)結(jié)構(gòu)進(jìn)行業(yè)務(wù)處理。所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理方法，其中，所述步驟71中，還包括當(dāng)所述 通訊處理模塊接收到所述客戶端建立連接的請求時(shí)根據(jù)安全策略確定是否接 受該請求的步驟，若該請求在拒絕范圍內(nèi)，則直接斷開該連接，若是，所述通 訊處理模塊接收請求數(shù)據(jù)包并通過異步消息轉(zhuǎn)發(fā)至所述協(xié)議處理模塊。所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理方法，其中，還包括一響應(yīng)處理返回步驟，具 體為步驟91，所述業(yè)務(wù)處理模塊進(jìn)行業(yè)務(wù)處理，構(gòu)造一表示響應(yīng)的內(nèi)部數(shù)據(jù)結(jié)構(gòu)，并將該內(nèi)部數(shù)據(jù)結(jié)構(gòu)發(fā)送給協(xié)議處理模塊；步驟92，由所述協(xié)議處理模塊根據(jù)該內(nèi)部數(shù)據(jù)結(jié)構(gòu)構(gòu)造一特定協(xié)議的響 應(yīng)數(shù)據(jù)包，并通過異步消息將該響應(yīng)數(shù)據(jù)包發(fā)送給通訊處理模塊；及
步驟93，通過所述通訊處理模塊轉(zhuǎn)發(fā)該響應(yīng)數(shù)據(jù)包至所述客戶端。 所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理方法，其中，所述步驟93之后，還包括一通 過協(xié)議處理模塊判斷是否需要關(guān)閉所述通訊處理模塊與所述客戶端之間指定 連接的步驟，若是，則所述協(xié)議處理模塊發(fā)送一異步消息通知所述通訊處理模 塊關(guān)閉所述指定連接，所述通訊處理模塊在收到所述通知后關(guān)閉所述指定連 接。本發(fā)明的技術(shù)效果在于本發(fā)明通過提供一種結(jié)構(gòu)清晰的框架和實(shí)現(xiàn)方法，使得在接入服務(wù)器內(nèi)部 和后續(xù)的業(yè)務(wù)處理以異步方式運(yùn)行，避免線程過多并被長期占用引起的問題， 另外，對于模塊功能的合理劃分避免了單個(gè)節(jié)點(diǎn)成為性能瓶頸的可能性。進(jìn)一步，本發(fā)明通過合理劃分模塊，各個(gè)模塊之間采用異步消息通訊，通 訊處理模塊采用異步套接字實(shí)現(xiàn)，避免由于多個(gè)線程長時(shí)間等待導(dǎo)致并發(fā)處理 能力較低，占用資源過多。通過業(yè)務(wù)處理模塊提供開發(fā)接口，屏蔽接入服務(wù)器 內(nèi)部框架和協(xié)議解析等實(shí)現(xiàn)細(xì)節(jié)，使得增值業(yè)務(wù)開發(fā)人員只需要關(guān)心業(yè)務(wù)邏輯 即可。進(jìn)一步，協(xié)議處理模塊和業(yè)務(wù)處理模塊都可以有多個(gè)，部署在多臺物理機(jī) 器上，通過一定的分發(fā)策略實(shí)現(xiàn)負(fù)荷分擔(dān)，從而提高處理能力，避免性能瓶頸。本發(fā)明解決了因電信增值業(yè)務(wù)處理時(shí)間較長導(dǎo)致接入服務(wù)器(接收客戶端 請求的第一個(gè)網(wǎng)元)并發(fā)處理能力較低、占用資源過多、資源利用率低，從而 導(dǎo)致系統(tǒng)整體性能下降的問題。以下結(jié)合附圖和具體實(shí)施例對本發(fā)明進(jìn)行詳細(xì)描述，但不作為對本發(fā)明的 限定。


圖l為本發(fā)明模塊劃分和接口圖； 圖2為本發(fā)明一種典型的多模塊組網(wǎng)示意圖； 圖3為本發(fā)明一典型請求處理流程示意圖； 圖4為本發(fā)明一典型響應(yīng)處理流程示意圖。
具體實(shí)施方式
下面結(jié)合附圖，以HTTP請求為例，對本發(fā)明(其他協(xié)議類似，包括SMTP、 SIP、 SOAP、 WAP等)進(jìn)行詳細(xì)描述。如圖1所示，為本發(fā)明模塊劃分和接口圖。本發(fā)明的系統(tǒng)結(jié)構(gòu)包括HTTP 客戶端IO、異步處理HTTP服務(wù)器20、其他系統(tǒng)/輔助設(shè)備30;其中異步處理 HTTP處理器20由三個(gè)模塊組成通訊處理模塊201、協(xié)議處理模塊202及業(yè) 務(wù)處理模塊203。通訊處理模塊201，負(fù)責(zé)處理與HTTP客戶端10之間的通訊，包括接受 來自HTTP客戶端10的通訊連接請求、進(jìn)行安全處理、接收請求數(shù)據(jù)和發(fā)送 響應(yīng)數(shù)據(jù)。協(xié)議處理模塊202，負(fù)責(zé)處理HTTP協(xié)議，根據(jù)HTTP協(xié)議把HTTP請求 消息解析成系統(tǒng)內(nèi)部的數(shù)據(jù)結(jié)構(gòu)，以及把系統(tǒng)內(nèi)部的響應(yīng)數(shù)據(jù)結(jié)構(gòu)構(gòu)造成 HTTP協(xié)議對應(yīng)的響應(yīng)數(shù)據(jù)包；同時(shí)還負(fù)責(zé)管理請求和響應(yīng)之間的對應(yīng)關(guān)系和 發(fā)送響應(yīng)的先后順序。業(yè)務(wù)處理模塊203，負(fù)責(zé)處理具體業(yè)務(wù)；為了適應(yīng)多變的業(yè)務(wù)邏輯，業(yè)務(wù) 處理模塊203被設(shè)計(jì)成一個(gè)容器，該容器中可以裝配一個(gè)或多個(gè)不同的業(yè)務(wù)處 理器2031。由開發(fā)人員按照規(guī)定接口開發(fā)業(yè)務(wù)處理器2031，即可裝配到業(yè)務(wù) 處理模塊203中，實(shí)現(xiàn)需要的業(yè)務(wù)邏輯。通訊處理模塊201與HTTP客戶端10之間的接口為HTTP協(xié)議，也可以 定義成其他協(xié)議，如SMTP、 SIP、 SOAP、 WAP等協(xié)議。通訊處理模塊201與協(xié)議處理模塊202之間、協(xié)議處理模塊202與業(yè)務(wù)處 理模塊203之間均為系統(tǒng)內(nèi)部的異步消息通信；業(yè)務(wù)處理器2031如果與其他 網(wǎng)元之間進(jìn)行交互， 一般也通過異步消息通訊。異步消息，是指發(fā)出一個(gè)消息 之后，線程繼續(xù)向下執(zhí)行，而不必等待響應(yīng)數(shù)據(jù)包的返回。如圖2所示，為本發(fā)明一種典型的多模塊組網(wǎng)示意圖。結(jié)合圖1，該圖中， 描述了通訊處理模塊201、協(xié)議處理模塊202、業(yè)務(wù)處理模塊203之間的組網(wǎng) 關(guān)系；協(xié)議處理模塊202包括協(xié)議處理模塊l…協(xié)議處理模塊n，業(yè)務(wù)處理模 塊203包括業(yè)務(wù)處理模塊1…業(yè)務(wù)處理模塊m，其中，n、 m均為大于等于2 的自然數(shù)。 通訊處理模塊201與具體協(xié)議無關(guān)，只根據(jù)安全策略決定是否接受HTTP 客戶端10連接；如果接受了連接，則根據(jù)配置的分發(fā)策略和各個(gè)協(xié)議處理模 塊l n的狀態(tài)，把數(shù)據(jù)包轉(zhuǎn)發(fā)給協(xié)議處理模塊1到協(xié)議處理模塊n中的--個(gè)， 并記錄轉(zhuǎn)發(fā)的協(xié)議處理模塊的序號k(k=l n)。協(xié)議處理模塊k根據(jù)協(xié)議解析 數(shù)據(jù)包，完成原始數(shù)據(jù)包到協(xié)議數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換，如果解析過程中出錯(cuò)，解析失 敗，則直接返回響應(yīng)給通訊處理模塊201，并通知通訊處理模塊201斷開連接， 如果解析成功，則根據(jù)分發(fā)策略和業(yè)務(wù)處理模塊1 m的狀態(tài)將轉(zhuǎn)換后的對象 轉(zhuǎn)發(fā)業(yè)務(wù)處理模塊1到業(yè)務(wù)處理模塊m中的一個(gè)，并記錄對應(yīng)業(yè)務(wù)處理模塊 的序號j(j— m)。業(yè)務(wù)處理模塊j收到請求后，調(diào)用對應(yīng)的業(yè)務(wù)處理器j，業(yè) 務(wù)處理器j與其他網(wǎng)元進(jìn)行交互；業(yè)務(wù)處理器j返回結(jié)果后，業(yè)務(wù)處理模塊203 和協(xié)議處理模塊202、通訊處理模塊201沿著與請求相反方向返回響應(yīng)并修改 自身狀態(tài)。如圖3所示，為本發(fā)明一典型請求處理流程示意圖。結(jié)合圖1、 2，以HTTP 協(xié)議和Java實(shí)現(xiàn)為例進(jìn)行如下描述系統(tǒng)啟動時(shí)，根據(jù)配置依次啟動通訊處理模塊201，協(xié)議處理模塊l n， 業(yè)務(wù)處理模塊1 m;各個(gè)模塊啟動完畢后，通過定時(shí)消息向前一級模塊報(bào)告 自身狀態(tài)，具體為業(yè)務(wù)處理模塊j向協(xié)議處理模塊1 n報(bào)告，協(xié)議處理模 塊k向通訊處理模塊201報(bào)告。如果協(xié)議處理模塊k連續(xù)幾次沒有收到業(yè)務(wù)處 理模塊j的狀態(tài)報(bào)告，則認(rèn)為業(yè)務(wù)處理模塊j己經(jīng)不可用；同樣，連接處理模 塊j連續(xù)幾次沒有收到協(xié)議處理模塊k的狀態(tài)報(bào)告，也認(rèn)為協(xié)議處理模塊k不 可用。啟動完畢后，通訊處理模塊201處于監(jiān)聽狀態(tài)。該請求處理流程具體包括如下步驟步驟301， HTTP客戶端10發(fā)起一個(gè)HTTP連接請求，指向通訊處理模塊 201所在的IP和對應(yīng)的監(jiān)聽端口，默認(rèn)為80;步驟302，通訊處理模塊201接收HTTP客戶端10建立連接的請求后， 根據(jù)安全策略決定是否允許建立連接，如果連接請求在拒絕范圍內(nèi)，則不允許， 直接斷開該連接；如果允許，則采用Java異步1/0(Input/0utput，輸入/輸出) 建立連接并等待請求數(shù)據(jù)包；步驟303，通訊處理模塊201在指定時(shí)間內(nèi)接收用戶請求數(shù)據(jù)包，通訊處 理模塊201可采用異步套接字，單個(gè)線程即可接收多個(gè)并發(fā)連接發(fā)送的數(shù)據(jù)； 如果超時(shí)則返回錯(cuò)誤；步驟304，通訊處理模塊201生成序列號SeqNO(隨機(jī)數(shù)， 一定時(shí)間內(nèi)保 持唯一)，并在請求數(shù)據(jù)包中添加該序列號SeqNO后，根據(jù)已知的分發(fā)策略和 協(xié)議處理模塊1 n的狀態(tài)列表，選擇一個(gè)協(xié)議處理模塊k轉(zhuǎn)發(fā)請求數(shù)據(jù)包， 并記錄序列號SeqNO和客戶端連接之間的對應(yīng)關(guān)系。該轉(zhuǎn)發(fā)過程能夠?qū)崿F(xiàn)負(fù) 荷分擔(dān)和高可用性，并具有良好的可擴(kuò)展性；步驟305，協(xié)議處理模塊k首先解析出序列號SeqNO，然后根據(jù)協(xié)議(可 配置或自我適配)把請求數(shù)據(jù)包解析成 一個(gè)表示該特定協(xié)議的請求的數(shù)據(jù)結(jié)構(gòu) 并填寫同一個(gè)序列號S叫NO;如果解析過程中出錯(cuò)，直接返回錯(cuò)誤響應(yīng)給通 訊處理模塊201。協(xié)議可配置或自我適配是指在實(shí)現(xiàn)了多種協(xié)議的情況下，程 序可以指定采用其中一種協(xié)議進(jìn)行解析，也可以根據(jù)協(xié)議本身的特點(diǎn)分析部分 數(shù)據(jù)包(如前面幾個(gè)字節(jié))判斷應(yīng)該采用何種協(xié)議解析。步驟306，協(xié)議處理模塊k根據(jù)已知的分發(fā)策略和業(yè)務(wù)處理模塊1 m的 狀態(tài)列表，選擇一個(gè)業(yè)務(wù)處理模塊j轉(zhuǎn)發(fā)該數(shù)據(jù)結(jié)構(gòu)，并記錄序列號SeqNO 和對應(yīng)數(shù)據(jù)結(jié)構(gòu)之間的關(guān)系。該轉(zhuǎn)發(fā)過程能夠?qū)崿F(xiàn)負(fù)荷分擔(dān)和高可用性，并具 有良好的可擴(kuò)展性；及步驟307，業(yè)務(wù)處理模塊j根據(jù)請求的URL(Uniform Resource Locator,統(tǒng) 一資源定位器)調(diào)用對應(yīng)業(yè)務(wù)處理器j，調(diào)用參數(shù)中包含一個(gè)數(shù)據(jù)結(jié)構(gòu)和一個(gè)對 應(yīng)的響應(yīng)數(shù)據(jù)結(jié)構(gòu)(內(nèi)部也有一個(gè)序列號SeqNO，并與數(shù)據(jù)結(jié)構(gòu)的序列號 SeqNO —致)，并等待響應(yīng)。業(yè)務(wù)處理器j與其他網(wǎng)元交互的過程一般是異步 的，當(dāng)然也可以是同步的，可以根據(jù)消息和業(yè)務(wù)類型自由選擇。如圖4所示，為本發(fā)明一典型響應(yīng)處理流程示意圖。結(jié)合圖1、 2，該響 應(yīng)處理流程具體包括如下步驟步驟401，業(yè)務(wù)處理結(jié)束并返回，或者超時(shí)(超時(shí)時(shí)間可配置或程序設(shè)置)， 或者響應(yīng)數(shù)據(jù)結(jié)構(gòu)的緩沖區(qū)滿，或者響應(yīng)數(shù)據(jù)結(jié)構(gòu)被觸發(fā)某些特定操作(如 Flush、 Finish等)，則返回響應(yīng)數(shù)據(jù)結(jié)構(gòu)；如果是超時(shí)或者被觸發(fā)如Finish等特定操作時(shí)，響應(yīng)數(shù)據(jù)結(jié)構(gòu)中是否最后 一個(gè)響應(yīng)的標(biāo)志設(shè)置為True;步驟402，業(yè)務(wù)處理模塊j返回表示內(nèi)部的響應(yīng)數(shù)據(jù)結(jié)構(gòu)到協(xié)議處理模塊k;
步驟403，業(yè)務(wù)處理模塊j根據(jù)響應(yīng)數(shù)據(jù)結(jié)構(gòu)中的序列號S叫NO修改自身 狀態(tài)；步驟404，協(xié)議處理模塊k根據(jù)特定協(xié)議對響應(yīng)數(shù)據(jù)結(jié)構(gòu)進(jìn)行編碼，生成 表示特定協(xié)議的響應(yīng)數(shù)據(jù)包，并轉(zhuǎn)發(fā)給通訊處理模塊201;步驟405，協(xié)議處理模塊k根據(jù)序列號SeqNO修改自身狀態(tài)，如果是最 后一個(gè)響應(yīng)，則刪除序列號SeqNO和對應(yīng)數(shù)據(jù)結(jié)構(gòu)之間的對應(yīng)關(guān)系和其他一 些相關(guān)記錄，并發(fā)送斷開連接的消息給通訊處理模塊201;步驟406，通訊處理模塊201根據(jù)請求過程中保存的序列號SeqNO和連 接之間的對應(yīng)關(guān)系，轉(zhuǎn)發(fā)響應(yīng)數(shù)據(jù)包至HTTP客戶端10;步驟407，判斷是否需要斷開連接，如果不需要，則通訊處理模塊201繼 續(xù)等待協(xié)議處理模塊k的下一個(gè)響應(yīng)數(shù)據(jù)包；若需要，執(zhí)行步驟408;步驟408，收到協(xié)議處理模塊k的斷開連接消息或者超時(shí)，通訊處理模塊 201斷開連接，刪除對應(yīng)的序列號SeqNO和連接的對應(yīng)關(guān)閉，釋放連接和相 關(guān)的資源。在上述實(shí)施例中，通訊處理模塊能夠并發(fā)處理多個(gè)請求，但并沒有對每一 個(gè)請求建立一個(gè)線程，而從通訊處理模塊往后的處理流程中都是異步方式實(shí)現(xiàn) 的。這些協(xié)議處理模塊和業(yè)務(wù)處理模塊，完全可以根據(jù)業(yè)務(wù)量大小和實(shí)際情況 在多臺物理機(jī)器上部署，而通訊處理模塊由于僅僅是處理連接和發(fā)送響應(yīng)并且 避免了多個(gè)長時(shí)間等待的線程帶來的問題，所以一般很難成為性能瓶頸。異步 處理是從系統(tǒng)整體或者通訊處理模塊、協(xié)議處理模塊、業(yè)務(wù)處理模塊各模塊之 間的交互來說的，也即是，如果采用協(xié)議A的應(yīng)用解析協(xié)議本身比較耗資源， 就采用多臺物理機(jī)器配置多個(gè)協(xié)議處理模塊，如果采用協(xié)議B的應(yīng)用業(yè)務(wù)本 身比較耗資源，就多配置幾個(gè)物理機(jī)器來部署業(yè)務(wù)處理模塊。綜上所述，采用本發(fā)明克服了由于增值業(yè)務(wù)系統(tǒng)本身響應(yīng)時(shí)間過長，線程 占用時(shí)間過長，從而導(dǎo)致WWW服務(wù)器處理能力下降的問題。對用戶保持同 步響應(yīng)的效果的同時(shí)，在系統(tǒng)內(nèi)部又具有異歩處理的好處，同時(shí)使得系統(tǒng)具有 部署的靈活性和良好的擴(kuò)展性。本發(fā)明實(shí)現(xiàn)過程中，通訊處理模塊采用2個(gè)線 程-一個(gè)接收線程、 一個(gè)發(fā)送線程；協(xié)議處理模塊和業(yè)務(wù)處理模塊采用10-20 個(gè)線程并發(fā)處理，在平均響應(yīng)時(shí)間30秒鐘以上時(shí)，與傳統(tǒng)的WWW處理方式 (并發(fā)線程300個(gè))相比處理能力至少提高3-10倍。 進(jìn)一歩，采用多線程處理人量并發(fā)請求的其他協(xié)議(如SMTP、 SOAP、 SIP、 WAP)的服務(wù)器，在遇到由于服務(wù)器端業(yè)務(wù)邏輯復(fù)雜、交互網(wǎng)元多等因素造成 處理時(shí)間長從而導(dǎo)致系統(tǒng)整體性能下降的時(shí)候，完全可以采用類似的方法解 決，只需要針對不同協(xié)議作-些簡單的適應(yīng)性修改即可。本發(fā)明通過提供一種結(jié)構(gòu)清晰的框架和實(shí)現(xiàn)方法，使得在接入服務(wù)器內(nèi)部 和后續(xù)的業(yè)務(wù)處理以異步的方式來運(yùn)行，避免線程過多并被長期占用引起的問 題，對于模塊功能的合理劃分避免了單個(gè)節(jié)點(diǎn)成為性能瓶頸的可能性。本發(fā)明解決了因電信增值業(yè)務(wù)處理時(shí)間較長導(dǎo)致接入服務(wù)器(接收客戶端 請求的第一個(gè)網(wǎng)元)并發(fā)處理能力較低、占用資源過多、資源利用率低，從而 導(dǎo)致系統(tǒng)整體性能下降的問題。當(dāng)然，本發(fā)明還可有其他多種實(shí)施例，在不背離本發(fā)明精神及其實(shí)質(zhì)的情 況下，熟悉本領(lǐng)域的技術(shù)人員當(dāng)可根據(jù)本發(fā)明作出各種相應(yīng)的改變和變形，但 這些相應(yīng)的改變和變形都應(yīng)屬于本發(fā)明所附的權(quán)利要求的保護(hù)范圍。
權(quán)利要求
1、一種網(wǎng)絡(luò)業(yè)務(wù)請求的處理系統(tǒng)，包括順次連接的客戶端、服務(wù)器，其特征在于，所述服務(wù)器又包括一通訊處理模塊，用于與所述客戶端進(jìn)行通訊；一協(xié)議處理模塊，用于根據(jù)協(xié)議將所述通訊處理模塊轉(zhuǎn)發(fā)的請求數(shù)據(jù)包解析成所述協(xié)議對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，將接收的響應(yīng)數(shù)據(jù)結(jié)構(gòu)構(gòu)造成所述協(xié)議對應(yīng)的響應(yīng)數(shù)據(jù)包，再轉(zhuǎn)發(fā)至所述通訊處理模塊，并負(fù)責(zé)請求、響應(yīng)的調(diào)度；及一業(yè)務(wù)處理模塊，用于接收并根據(jù)所述協(xié)議處理模塊發(fā)送的數(shù)據(jù)進(jìn)行業(yè)務(wù)處理，并將處理結(jié)果再轉(zhuǎn)發(fā)至所述協(xié)議處理模塊；所述通訊處理模塊與所述協(xié)議處理模塊之間、所述協(xié)議處理模塊與所述業(yè)務(wù)處理模塊之間均通過異步消息進(jìn)行通信。
2、 根據(jù)權(quán)利要求1所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理系統(tǒng)，其特征在于，所述 協(xié)議處理模塊、所述業(yè)務(wù)處理模塊皆為多個(gè)。
3、 根據(jù)權(quán)利要求2所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理系統(tǒng)，其特征在于，所述 每--業(yè)務(wù)處理模塊設(shè)置有一個(gè)或多個(gè)業(yè)務(wù)處理器。
4、 根據(jù)權(quán)利要求1、 2或3所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理系統(tǒng)，其特征在于， 所述客戶端與所述通訊處理模塊之間的接口協(xié)議包括HTTP協(xié)議、SMTP、 SOAP協(xié)議、SIP協(xié)議及WAP協(xié)議。
5、 根據(jù)權(quán)利要求1、 2或3所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理系統(tǒng)，其特征在于， 所述通訊處理模塊通過異步套接字方式與所述協(xié)議處理模塊通信。
6、 -一種利用權(quán)利要求1所述系統(tǒng)實(shí)現(xiàn)網(wǎng)絡(luò)業(yè)務(wù)請求的處理方法，其特征 在于，包括一通訊處理步驟，用于與所述客戶端進(jìn)行通訊；一協(xié)議處理步驟，用于根據(jù)協(xié)議將所述通訊處理模塊轉(zhuǎn)發(fā)的請求數(shù)據(jù)包解 析成所述協(xié)議對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，將接收的響應(yīng)數(shù)據(jù)結(jié)構(gòu)構(gòu)造成所述協(xié)議對應(yīng)的 響應(yīng)數(shù)據(jù)包，再轉(zhuǎn)發(fā)至所述通訊處理模塊，并負(fù)責(zé)請求、響應(yīng)的調(diào)度；及一業(yè)務(wù)處理步驟，用于接收并根據(jù)所述協(xié)議處理模塊發(fā)送的數(shù)據(jù)進(jìn)行業(yè)務(wù)處理，并將處理結(jié)果再轉(zhuǎn)發(fā)至所述協(xié)議處理模塊；所述通訊處理模塊與所述協(xié)議處理模塊之間、所述協(xié)議處理模塊與所述業(yè) 務(wù)處理模塊之間均通過異步消息進(jìn)行通信。
7、 根據(jù)權(quán)利要求6所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理方法，其特征在于，還包括-請求接收處理步驟，具體為步驟71，由所述通訊處理模塊接收所述客戶端發(fā)送的請求數(shù)據(jù)包并轉(zhuǎn)發(fā)至所述協(xié)議處理模塊；步驟72，通過所述協(xié)議處理模塊根據(jù)一特定協(xié)議解析所述請求數(shù)據(jù)包， 構(gòu)造成一內(nèi)部數(shù)據(jù)結(jié)構(gòu)，并通過異步消息轉(zhuǎn)發(fā)至所述業(yè)務(wù)處理模塊；及步驟73，由所述業(yè)務(wù)處理模塊接收并根據(jù)所述內(nèi)部數(shù)據(jù)結(jié)構(gòu)進(jìn)行業(yè)務(wù)處理。
8、 根據(jù)權(quán)利要求7所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理方法，其特征在于，所述 步驟71中，還包括當(dāng)所述通訊處理模塊接收到所述客戶端建立連接的請求時(shí) 根據(jù)安全策略確定是否接受該請求的步驟，若該請求在拒絕范圍內(nèi)，則直接斷 開該連接，若是，所述通訊處理模塊接收請求數(shù)據(jù)包并通過異步消息轉(zhuǎn)發(fā)至所 述協(xié)議處理模塊。
9、 根據(jù)權(quán)利要求6、 7或8所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理方法，其特征在于， 還包括-響應(yīng)處理返回步驟，具體為步驟91，所述業(yè)務(wù)處理模塊進(jìn)行業(yè)務(wù)處理，構(gòu)造一表示響應(yīng)的內(nèi)部數(shù)據(jù) 結(jié)構(gòu)，并將該內(nèi)部數(shù)據(jù)結(jié)構(gòu)發(fā)送給協(xié)議處理模塊；步驟92，由所述協(xié)議處理模塊根據(jù)該內(nèi)部數(shù)據(jù)結(jié)構(gòu)構(gòu)造一特定協(xié)議的響 應(yīng)數(shù)據(jù)包，并通過異步消息將該響應(yīng)數(shù)據(jù)包發(fā)送給通訊處理模塊；及步驟93，通過所述通訊處理模塊轉(zhuǎn)發(fā)該響應(yīng)數(shù)據(jù)包至所述客戶端。
10、 根據(jù)權(quán)利要求9所述的網(wǎng)絡(luò)業(yè)務(wù)請求的處理方法，其特征在于，所述 步驟93之后，還包括一通過協(xié)議處理模塊判斷是否需要關(guān)閉所述通訊處理模 塊與所述客戶端之間指定連接的步驟，若是，則所述協(xié)議處理模塊發(fā)送一異步 消息通知所述通訊處理模塊關(guān)閉所述指定連接，所述通訊處理模塊在收到所述 通知后關(guān)閉所述指定連接。
全文摘要
本發(fā)明公開了一種網(wǎng)絡(luò)業(yè)務(wù)請求的處理系統(tǒng)及其方法，該系統(tǒng)包括順次連接的客戶端、服務(wù)器，服務(wù)器又包括通訊處理模塊，用于與客戶端進(jìn)行通訊；協(xié)議處理模塊，用于根據(jù)協(xié)議將通訊處理模塊轉(zhuǎn)發(fā)的請求數(shù)據(jù)包解析成協(xié)議對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，將接收的響應(yīng)數(shù)據(jù)結(jié)構(gòu)構(gòu)造成協(xié)議對應(yīng)的響應(yīng)數(shù)據(jù)包，再轉(zhuǎn)發(fā)至通訊處理模塊，并負(fù)責(zé)請求、響應(yīng)的調(diào)度；及業(yè)務(wù)處理模塊，用于接收并根據(jù)協(xié)議處理模塊發(fā)送的數(shù)據(jù)進(jìn)行業(yè)務(wù)處理，并將處理結(jié)果再轉(zhuǎn)發(fā)至協(xié)議處理模塊；通訊處理模塊與協(xié)議處理模塊之間、協(xié)議處理模塊與業(yè)務(wù)處理模塊之間均通過異步消息進(jìn)行通信。本發(fā)明解決了電信增值業(yè)務(wù)處理時(shí)間較長導(dǎo)致接入服務(wù)器并發(fā)處理能力較低，占用資源過多的問題。
文檔編號H04L29/06GK101115050SQ20061008889
公開日2008年1月30日 申請日期2006年7月24日 優(yōu)先權(quán)日2006年7月24日
發(fā)明者呂偉初, 泳 熊 申請人:中興通訊股份有限公司