本發(fā)明屬于移動互聯(lián)網(wǎng)技術(shù)領(lǐng)域,尤其涉及一種基于事件總線的web推送方法。

背景技術(shù)：

由于企業(yè)商業(yè)環(huán)境不斷變化，在新的企業(yè)應(yīng)用中，各類應(yīng)用系統(tǒng)要能夠快速適應(yīng)變化，必須是輕量級與碎片化的應(yīng)用，應(yīng)用架構(gòu)必須支持并適應(yīng)這種變化，也需要向互聯(lián)網(wǎng)方向轉(zhuǎn)變。隨著互聯(lián)網(wǎng)化發(fā)展，特別是移動互聯(lián)網(wǎng)的發(fā)展，人們的辦公方式發(fā)生了變化。系統(tǒng)的操作不再是傳統(tǒng)的記日志方式就能夠滿足，而是需要對每一步操作需要通知相關(guān)人員，讓他們第一時間能夠知道，并快速處理相關(guān)任務(wù)；輕量級與碎片化應(yīng)用之間也需要通過事件機制的異步調(diào)用，因此，應(yīng)用之間的消息推送功能在企業(yè)互聯(lián)網(wǎng)應(yīng)用中就顯得尤為重要。

在企業(yè)互聯(lián)網(wǎng)平臺的開發(fā)中，首先需要考慮租戶的多應(yīng)用服務(wù),不同的租戶有對應(yīng)的工作臺，后臺應(yīng)用都是以輕量級的應(yīng)用服務(wù)提供,租戶操作應(yīng)用服務(wù)時，都需要通知到相關(guān)的操作人員和管理人員，而且他們基本是基于瀏覽器進(jìn)行操作。隨著注冊的租戶數(shù)增多，消息訂閱數(shù)增加，應(yīng)用服務(wù)需要處理的消息成幾倍增長;隨著客戶端請求數(shù)量激增，消息提醒也越來越重要，傳統(tǒng)的消息服務(wù)已不堪重負(fù)，致使人們在不斷尋找新的解決方案，基于事件和異步的解決方案備受追捧。

早期的通過Ajax 輪訓(xùn)的方式、基于Comet 長連接推送技術(shù)和Flash 的 WebSocket等技術(shù)都無法滿足用戶需求。由于企業(yè)互聯(lián)網(wǎng)下用戶消息推送的需求不斷變化，而且對實時性要求不斷提高，消息之間也需要相互隔離。因此，在設(shè)計和開發(fā)過程中，需要一種新的事件總線的web推送裝置與方法技術(shù)來避免上述缺陷的產(chǎn)生。

技術(shù)實現(xiàn)要素：

針對現(xiàn)有技術(shù)的不足，本發(fā)明提供一種基于事件總線的web推送方法，通過此技術(shù)可以很好了解決用戶需求，并可以很好地實現(xiàn)橫向擴(kuò)展。

一種基于事件總線的web推送方法，所述方法包括以下步驟：

S1,服務(wù)容器入棧地址綁定；

S2，消息的異步處理；

S3，應(yīng)用服務(wù)消息發(fā)布；

S4，web端消息訂閱；

S5，事件總線推送。

優(yōu)選地，所述步驟S1具體為：

S11，先把綁定地址通過服務(wù)接口寫入數(shù)據(jù)庫中；

S12，從服務(wù)器中讀取所有需要綁定的地址；

S13，把綁定地址寫入一個集合選項中；

S14，注冊綁定地址到事件總線上。

優(yōu)選地，所述步驟S2具體為：

S21，服務(wù)地址的綁定，并注冊一個異步處理器;

S22, 當(dāng)應(yīng)用上述注冊好的異步處理器的請求地址時，就會執(zhí)行綁定的異步服務(wù)；

S23，每個服務(wù)地址可以能夠被多個異步處理程序注冊；

S24，每一個異步處理服務(wù)可以被多個服務(wù)地址注冊。

優(yōu)選地，所述步驟S3具體為：

S31，應(yīng)用程序獲取需要發(fā)布的消息；

S32，準(zhǔn)備服務(wù)調(diào)用的密鑰參數(shù)，并調(diào)用發(fā)布服務(wù)；

S33，服務(wù)容器接收消息，并解密處理；

S34，服務(wù)容器向調(diào)用者返回請求的結(jié)果。

優(yōu)選地，所述步驟S4具體為：

S41，根據(jù)服務(wù)容器發(fā)布的身份信息與服務(wù)器進(jìn)行握手；

S42，通過事件總線橋與服務(wù)容器進(jìn)行連接；

S43，通過事件總線橋向事件總線橋注冊接收消息出棧地址；

S44，接收服務(wù)器推送的消息，并進(jìn)行消息處理。

優(yōu)選地，所述事件總線包括：

協(xié)調(diào)事件循環(huán)線程和長任務(wù)工作線程之間的任務(wù)；

拓展到客戶端邊的Javascript，通過客戶端的事件總線橋可以在客戶端和服務(wù)器端分發(fā)事件；

多個實例之間可以通過事件總線進(jìn)行通訊；

在多個成員之間進(jìn)行資源共享。

本發(fā)明的技術(shù)方案具有以下有益效果：

本發(fā)明提供的一種基于事件總線的web推送方法，通過事件總線橋的實現(xiàn)，拓展了web客戶端與服務(wù)容器之間的事件分發(fā)，保證了消息、出入棧地址等資源在事件總線上進(jìn)行共享，并根據(jù)需要對出入棧地址分別注冊，更好地實現(xiàn)了消息在發(fā)布端與接收端推送的實時性，減少了通過代理轉(zhuǎn)發(fā)的環(huán)節(jié)，提高了效率。本發(fā)明技術(shù)不僅解決了實際應(yīng)用中的需求問題，而且解決了API調(diào)用的安全性和服務(wù)的可擴(kuò)展性，降低了升級擴(kuò)容的難度，減少了升級的工作量，使得消息發(fā)送與接收更加及時；隨著注冊用戶數(shù)的增加，服務(wù)能夠快速部署；通過異步處理，提高了系統(tǒng)的并發(fā)數(shù)；系統(tǒng)的TPS（每秒處理的事務(wù)數(shù)）明顯提高；服務(wù)調(diào)用更加安全。

附圖說明

下面通過附圖和實施例，對本發(fā)明的技術(shù)方案做進(jìn)一步的詳細(xì)描述。

圖1為本發(fā)明一種基于事件總線的web推送方法的異步消息推送方案圖。

具體實施方式

為了清楚了解本發(fā)明的技術(shù)方案，將在下面的描述中提出其詳細(xì)的結(jié)構(gòu)。顯然，本發(fā)明實施例的具體施行并不足限于本領(lǐng)域的技術(shù)人員所熟習(xí)的特殊細(xì)節(jié)。本發(fā)明的優(yōu)選實施例詳細(xì)描述如下，除詳細(xì)描述的這些實施例外，還可以具有其他實施方式。

下面結(jié)合附圖和實施例對本發(fā)明做進(jìn)一步詳細(xì)說明。

結(jié)合圖1，本實施例提出了一種基于事件總線的web推送裝置與方法，主要包括：事件總線橋、可共享的事件總線、Vertx服務(wù)容器、異步事件機制應(yīng)用；這種發(fā)明技術(shù)可以解決我們在互聯(lián)網(wǎng)下的消息推送需求，基于事件總線的異步消息推送方案如圖1所示。

本發(fā)明后端通過java實現(xiàn)，前端sdk通過javascript實現(xiàn)。首先web端通過事件總線橋注冊一個接收地址到事件總線上，應(yīng)用端處理完一個業(yè)務(wù)后，需要把相關(guān)信息通過發(fā)布端發(fā)送出去，當(dāng)vertx容器接收到一個消息后，立即通過一個處理器對消息進(jìn)行處理，消息處理完成后，再由事件總線推送到各個訂閱者，這樣就完成了一次消息處理。

具體實現(xiàn)步驟如下：

一、服務(wù)容器入棧地址綁定

服務(wù)容器的入棧地址綁定，主要是當(dāng)服務(wù)器運行時，需要暴露給客戶端允許訪問的地址，通過此地址，客戶端與服務(wù)端能夠進(jìn)行握手并通訊，入棧地址只需要在運行時加載一次，具體綁定過程如下：

1、先把綁定地址通過服務(wù)接口寫入數(shù)據(jù)庫中；

2、從服務(wù)器中讀取所有需要綁定的地址；

3、把綁定地址寫入一個集合選項中；

4、注冊綁定地址到事件總線上。

二、消息的異步處理

消息的異步處理，主要是在一個地址上注冊一個異步處理程序，收到消息后將觸發(fā)這個異步處理程序；同一個消息異步處理程序可以注冊到不同的地址上，同樣同一個地址也能注冊多個異步處理程序，具體實現(xiàn)過程如下；

1、服務(wù)地址的綁定，并注冊一個異步處理器，如下所示：router.post("/vi/message.send").handler(this::sendMessageInfo);

2、當(dāng)應(yīng)用請求地址“/vi/message.send”時，就會執(zhí)行綁定的異步服務(wù)；

3、每個服務(wù)地址可以能夠被多個異步處理程序注冊；

4、每一個異步處理服務(wù)可以被多個服務(wù)地址注冊；

三、應(yīng)用服務(wù)消息發(fā)布

應(yīng)用服務(wù)消息發(fā)布，主要是根據(jù)服務(wù)地址，向服務(wù)容器的事件總線發(fā)送消息，發(fā)送過程中需要獲取服務(wù)容器發(fā)布的密鑰信息，具體實現(xiàn)過程是：

1、應(yīng)用程序獲取需要發(fā)布的消息；

2、準(zhǔn)備服務(wù)調(diào)用的密鑰參數(shù)，并調(diào)用發(fā)布服務(wù)；

3、服務(wù)容器接收消息，并解密處理；

4、服務(wù)容器向調(diào)用者返回請求的結(jié)果；

四、web端消息訂閱

Web端消息訂閱，主要是向服務(wù)容器注冊一個接收消息的地址，建立http長連接，然后等待服務(wù)容器推送的消息，并進(jìn)行處理；

1、根據(jù)服務(wù)容器發(fā)布的身份信息與服務(wù)器進(jìn)行握手；

2、通過事件總線橋與服務(wù)容器進(jìn)行連接；

3、通過事件總線橋向事件總線橋注冊接收消息出棧地址；

4、接收服務(wù)器推送的消息，并進(jìn)行消息處理；

五、事件總線

事件總線，可以在分布式系統(tǒng)中的多個服務(wù)器節(jié)點之間或多個瀏覽器之間進(jìn)行點對點通信，支持發(fā)布/訂閱模式，點對點模式和請求/響應(yīng)模式。包括注冊消息處理事件，取消處理事件，發(fā)送和發(fā)布消息等；

1、事件總線可以協(xié)調(diào)事件循環(huán)線程和長任務(wù)工作線程之間的任務(wù)；

事件總線可以拓展到客戶端邊的Javascript，通過客戶端的事件總線橋可以在客戶端和服務(wù)器端分發(fā)事件；

多個實例之間可以通過事件總線進(jìn)行通訊；

事件總線可以在多個成員之間進(jìn)行資源共享；

本發(fā)明技術(shù)方案在設(shè)計和實現(xiàn)上進(jìn)行了創(chuàng)新，通過事件總線橋的實現(xiàn)，拓展了web客戶端與服務(wù)容器之間的事件分發(fā)，保證了消息、出入棧地址等資源在事件總線上進(jìn)行共享，并根據(jù)需要對出入棧地址分別注冊，更好地實現(xiàn)了消息在發(fā)布端與接收端推送的實時性，減少了通過代理轉(zhuǎn)發(fā)的環(huán)節(jié)，提高了效率。本發(fā)明技術(shù)不僅解決了實際應(yīng)用中的需求問題，而且解決了API調(diào)用的安全性和服務(wù)的可擴(kuò)展性。降低了升級擴(kuò)容的難度，減少了升級的工作量，帶來技術(shù)效果上的改進(jìn)主要表現(xiàn)如下：

1、消息發(fā)送與接收更加及時；

2、隨著注冊用戶數(shù)的增加，服務(wù)能夠快速部署；

3、通過異步處理，提高了系統(tǒng)的并發(fā)數(shù)；

4、系統(tǒng)的TPS（每秒處理的事務(wù)數(shù)）明顯提高；

5、服務(wù)調(diào)用更加安全；

最后應(yīng)當(dāng)說明的是：以上實施例僅用以說明本發(fā)明的技術(shù)方案而非對其限制，盡管參照上述實施例對本發(fā)明進(jìn)行了詳細(xì)的說明，所屬領(lǐng)域的普通技術(shù)人員依然可以對本發(fā)明的具體實施方式進(jìn)行修改或者等同替換，這些未脫離本發(fā)明精神和范圍的任何修改或者等同替換，均在申請待批的權(quán)利要求保護(hù)范圍之內(nèi)。