本發(fā)明涉及數(shù)據(jù)處理領域，更為具體而言，涉及一種即時通信方法和系統(tǒng)。

背景技術：

當前，隨著移動互聯(lián)網(wǎng)技術的快速發(fā)展，智能移動設備的日益普及，隨之伴隨而來的是手機app的廣泛流行。在移動互聯(lián)時代，手機app因為其便利性、不受時間空間限制的特點，不僅深受廣大用戶歡迎，也成為企業(yè)拓展業(yè)務、宣傳企業(yè)形象、拉近企業(yè)與用戶的距離的重要手段，企業(yè)app的建設已經(jīng)成為廣大企業(yè)的共同需求。即時通訊功能是企業(yè)app的重要功能之一，對于一般的企業(yè)而言開發(fā)一個app并不是一件很難的事情，但是要開發(fā)好移動即時通訊卻絕非易事。企業(yè)即時通訊涉及到通訊協(xié)議的選擇、和現(xiàn)有企業(yè)業(yè)務集成、保證消息不丟失和跨平臺支持等諸多問題。

目前大多數(shù)的即時通訊都是采用基于tcp、udp協(xié)議的c/s模式或者p2p模式。用戶與服務器之間通過c/s模式進行通訊連接進行身份認證，認證通過之后用戶之間則可采用p2p的模式進行點對點信息交換。當然有些即時通訊軟件點對點之間的通訊也是經(jīng)過即時通訊服務器進行消息轉(zhuǎn)發(fā)。

即時通訊另外一個重要的技術點就是通訊協(xié)議，目前大多數(shù)的即時通訊軟件使用的通訊協(xié)議和接口都是廠商自定義的，多個即時通訊軟件之間無法互聯(lián)互通。為了解決即時通訊的標準問題，互聯(lián)網(wǎng)工程工作小組(ietf)研究和開發(fā)了im相關的協(xié)議，xmpp協(xié)議是目前采納最為廣泛的一種。

xmpp(extensiblemessagingandpresenceprotocol，前稱jabber[1])是一種以xml為基礎的開放式實時通信協(xié)議，是經(jīng)由互聯(lián)網(wǎng)工程工作小組(ietf)通過的互聯(lián)網(wǎng)標準。xmpp是一種基于xml的協(xié)議，它繼承了在xml環(huán)境中靈活的發(fā)展性。因此，基于xmpp的應用具有超強的可擴展性。經(jīng)過擴展以后的xmpp可以通過發(fā)送擴展的信息來處理用戶的需求，以及在xmpp的頂端建立如內(nèi)容發(fā)布系統(tǒng)和基于地址的服務等應用程序。而且，xmpp包含了針對服務器端的軟件協(xié)議，使之能與另一個進行通話，這使得開發(fā)者更容易建立客戶應用程序或給一個配好系統(tǒng)添加功能。

xmpp中定義了三個角色，客戶端，服務器，網(wǎng)關。通信能夠在這三者的任意兩個之間雙向發(fā)生。服務器同時承擔了客戶端信息記錄，連接管理和信息的路由功能。網(wǎng)關承擔著與異構即時通信系統(tǒng)的互聯(lián)互通，異構系統(tǒng)可以包括sms(短信)，msn，icq等。xmpp協(xié)議是自由、開放、公開的，并且易于了解。而且在客戶端、服務器、組件、源碼庫等方面，都已經(jīng)各自有多種實現(xiàn)。

基于c/s模式的即時通訊技術是目前采用最為廣泛的方案，對于一般的企業(yè)而言采用此方案存在以下幾個方面的不足：首先是系統(tǒng)架構較復雜，開發(fā)成本較高。基于c/s模式的即時通訊技術涉及到tcp、udp、socket、p2p和編碼解碼等多種技術和協(xié)議，而且都是偏系統(tǒng)層的技術。要將這些技術組合在一起構建一個穩(wěn)定的即時通訊系統(tǒng)，需要大量的技術投入和積累。其次，無法跨平臺使用，由于不同的手機操作系統(tǒng)平臺不一樣，支持的開發(fā)技術平臺也不一致，而基于c/s模式即時通訊技術都需要基于特定的語言進行開發(fā)，所以基于此技術開發(fā)的app也無法跨平臺使用。

因此，目前需要解決傳統(tǒng)c/s模式即時通訊系統(tǒng)架構復雜、開發(fā)成本高，且無法跨平臺使用的缺點。提出一種基于web標準規(guī)范、跨手機平臺、易于實現(xiàn)的企業(yè)級app即時通訊系統(tǒng)構建方法，滿足廣大企業(yè)即時通訊的需求。

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

鑒于現(xiàn)有技術的上述缺陷，本發(fā)明實施方式提供了一種即時通信方法和系統(tǒng)，能夠有效解決傳統(tǒng)c/s模式即時通訊系統(tǒng)架構復雜、開發(fā)成本高，且無法跨平臺使用的缺點。

具體地，本發(fā)明實施方式提供了一種即時通信方法，所述方法包括：

在發(fā)送端與接收端之間，通過web協(xié)議和簡單文本定向消息協(xié)議，將消息從所述發(fā)送端通過消息隊列中間件實時發(fā)送至所述接收端。

相應地，本發(fā)明實施方式還提供了一種即時通信系統(tǒng)，所述系統(tǒng)包括：

發(fā)送端，用于通過web協(xié)議和簡單文本定向消息協(xié)議，向?qū)崟r消息中間件發(fā)送消息；

消息中間件，用于接收所述發(fā)送端發(fā)送的消息，并將所述消息實時轉(zhuǎn)發(fā)給接收端；

接收端，用于接收所述消息中間件轉(zhuǎn)發(fā)的消息。

通過采用本發(fā)明實施方式具有下述有益效果：基于web標準規(guī)范、跨手機平臺、易于實現(xiàn)的企業(yè)級app即時通訊系統(tǒng)構建方法，滿足廣大企業(yè)即時通訊的需求。

附圖說明

圖1是根據(jù)本發(fā)明實施方式的一種即時通信方法的流程示意圖；

圖2是根據(jù)本發(fā)明實施方式中另一種實施方式的流程示意圖；

圖3是根據(jù)本發(fā)明實施方式中又一種實施方式的流程示意圖；

圖4是根據(jù)本發(fā)明實施方式的一種即時通信系統(tǒng)的架構圖。

具體實施方式

為了便于理解本發(fā)明技術方案的各個方面、特征以及優(yōu)點，下面結(jié)合附圖對本發(fā)明進行具體描述。應當理解，下述的各種實施方式只用于舉例說明，而非用于限制本發(fā)明的保護范圍。

首先對根據(jù)本發(fā)明可能涉及到的名稱或術語進行解釋。

即時通訊(im)：一種實時通信系統(tǒng)，允許兩人或多人使用網(wǎng)絡實時的傳遞文字消息、文件、語音和視頻交流。

消息中間件(mq)：消息中間件利用高效可靠的消息傳遞機制進行平臺無關的數(shù)據(jù)交流，并基于數(shù)據(jù)通信來進行分布式系統(tǒng)的集成。

websocket：是html5一種新的協(xié)議，它實現(xiàn)了瀏覽器與服務器全雙工通信。

stomp(simple(orstreaming)textorientatedmessagingprotocol):簡單(流)文本定向消息協(xié)議，它提供了一個可互操作的連接格式，允許stomp客戶端與任意stomp消息代理(broker)進行交互。

手機app：安裝在手機上軟件，用于完善原始系統(tǒng)的不足與個性化。提供面向特定領域的應用功能。

實施例1：

圖1是根據(jù)本發(fā)明實施方式的一種數(shù)據(jù)特征庫建立方法的流程示意圖。參照圖1，具體實施例如下：

在發(fā)送端與接收端之間，通過web協(xié)議和簡單文本定向消息協(xié)議，將消息從所述發(fā)送端通過消息隊列中間件實時發(fā)送至所述接收端。

本發(fā)明的實現(xiàn)方法是通過“websocket+stomp+mq”這種組合技術手段來完成。websocket作為html5中新增的一種通信協(xié)議，由通信協(xié)議和編程api組成，它能夠在瀏覽器和服務器之間建立雙向連接，以基于事件的方式，賦予瀏覽器原生的實時通信能力，來擴展我們的web應用，增加用戶體驗，提升應用的性能。本方案中手機app通過websocket通信協(xié)議與消息網(wǎng)關通訊獲取或者發(fā)送消息。同時采用stomp協(xié)議來組織數(shù)據(jù)，stomp是一個簡單的流文本定向消息協(xié)議，支持與任意stomp消息代理交互，進行消息發(fā)送與訂閱。本方案通過消息中間件(mq)的隊列和訂閱機制實現(xiàn)點對點和群組即時通訊。

目前主流的手機操作系統(tǒng)有android、ios和windows，每種操作系統(tǒng)的編程語言、運行機制都不相同。對于手機app開發(fā)而言，開發(fā)者需要針對不同的操作系統(tǒng)開發(fā)不同app版本，對于一般的企業(yè)而言，這意味著一筆很大的人力和財力支出。因此采用標準的web協(xié)議實現(xiàn)手機app跨平臺的支持具有很強的現(xiàn)實意義。傳統(tǒng)的web信息交互過程通常是客戶端通過瀏覽器發(fā)出一個請求，服務器端接收后進行處理并返回結(jié)果給客戶端，然后客戶端瀏覽器將信息呈現(xiàn)出來，這種機制對于普通的信息和展示和操作來說是沒有問題的，但是對于即時通訊這種信息交互頻繁、實時性要求高的應用來說，傳統(tǒng)的web交互方式雖然在一定程度上可以模擬雙向通信，但效率較低,并需要服務器有較好的支持。因此我們需要一種高效節(jié)能的雙向通信機制來保證數(shù)據(jù)的實時傳輸。有webtcp之稱的websocket正好可以解決傳統(tǒng)web交互模式的缺點。

websocketprotocol是html5一種新的協(xié)議。它實現(xiàn)了瀏覽器與服務器全雙工通信。使用websocketapi，瀏覽器和服務器只需要做一個握手的動作，然后，瀏覽器和服務器之間就形成了一條快速通道。兩者之間就直接可以數(shù)據(jù)互相傳送，既能節(jié)省流量也能實現(xiàn)實時性的要求。目前主流的瀏覽器都支持websocket協(xié)議，因此雖然不同的手機平臺操作系統(tǒng)不一致，但是只要操作系統(tǒng)支持websocket就可以實現(xiàn)app即時通訊跨平臺支持。

實施例2：

在本發(fā)明的另一種實施方式中，所述方法除了上述處理方式外，其中，所述將消息從所述發(fā)送端通過消息隊列中間件發(fā)送給所述接收端包括：所述消息中間件通過消息網(wǎng)關，接收所述發(fā)送端發(fā)送的消息和向所述接收端轉(zhuǎn)發(fā)所述消息，其中，所述接收端可以是一個用戶或多個用戶。

websocket只是一個底層協(xié)議，缺少框架支持，使用較復雜，因此在本方案中引入mq消息中間作為即時通訊消息的轉(zhuǎn)發(fā)，確保手機在不聯(lián)網(wǎng)的情況下消息不會丟失，同時通過mq集群特性提供水平擴展能力，提高更高的性能和高可用性。websocket客戶端和mq之間通過stomp協(xié)議進行數(shù)據(jù)傳遞。stomp即simple(orstreaming)textorientatedmessagingprotocol，簡單(流)文本定向消息協(xié)議，它提供了一個可互操作的連接格式，允許stomp客戶端與任意stomp消息代理(broker)進行交互。stomp協(xié)議由于設計簡單，易于開發(fā)客戶端，因此在多種語言和多種平臺上得到廣泛地應用。stomp協(xié)議的前身是ttmp協(xié)議(一個簡單的基于文本的協(xié)議)，專為消息中間件設計。通過使用消息架構可以實現(xiàn)松散耦合的分布式數(shù)據(jù)通訊。消息從手機app發(fā)送給消息中間件，消息中間件再負責將消息推送給目標手機app。本專利方案研究采用activemq消息中間件，activemq是目前使用最廣泛的開源消息中間件，它完全支持jms規(guī)范。(支持jms規(guī)范的商業(yè)中間件產(chǎn)品如weblogic、websphere也可以用于此方案)。jms(javamessageservice)即java消息服務應用程序接口，是一個java平臺中面向消息中間件的api，用于在兩個應用程序之間，或分布式系統(tǒng)中發(fā)送消息，它是一種與廠商無關的api。jms規(guī)范目前支持兩種消息模型：點對點(pointtopoint，queue)和發(fā)布/訂閱(publish/subscribe，topic)。

其中，點對點通訊方式：消息生產(chǎn)者發(fā)送消息發(fā)送到queue中，然后消息消費者從queue中取出并且消費消息。具體流程包括：1)手機app通過websocket協(xié)議發(fā)送消息到消息網(wǎng)關，消息中包含目標用戶信息，消息網(wǎng)關對消息進行處理后負責將消息發(fā)送到接收方的用戶b的私有隊列；2)手機app啟動運行時即監(jiān)控自己的私有隊列，這樣發(fā)送到用戶b的私有隊列中的消息都能第一時間被用戶b接收到；3)手機app將接收到的消息緩存到手機上，然后進行展示。本發(fā)明的該實施方式中采用“點對點”消息模型實現(xiàn)“點對點”即時通訊，消息生產(chǎn)者即相當于發(fā)送消息的人，消息消費者即相當于接收消息的人。

其中，發(fā)布/訂閱通訊方式：消息生產(chǎn)者將消息發(fā)布到topic中，同時有多個消息消費者(訂閱)消費該消息。和點對點方式不同，發(fā)布到topic的消息會被所有訂閱者消費。具體流程包括：1)手機app通過websocket協(xié)議發(fā)送消息到消息網(wǎng)關，消息中包含目標群組信息，消息網(wǎng)關對消息進行處理后負責將消息發(fā)送到消息中間件對應的群組主題(可以建立多個群組主題，每個群組主題相當于一個聊天群)；2)手機app啟動運行時即訂閱自己加入的群組主題，這樣發(fā)送到相應群組主題的消息都能被訂閱該群組隊列的所有用戶接收到(如本例中的用戶b和用戶c)；3)手機app將接收到消息緩存到手機上，然后進行展示。本發(fā)明的該實施方式采用“發(fā)布/訂閱”消息模型實現(xiàn)“群組”模式的即時通訊，消息生產(chǎn)者即相當于發(fā)送消息的人，加入群組的所有人相當于消息訂閱者。

實施例3：

在本發(fā)明的另一種實施方式中，所述方法除了上述處理方式外，其中，所述消息網(wǎng)關利用web接口或httprest接口與外部系統(tǒng)集成。

具體而言，企業(yè)內(nèi)部的即時通訊除了實現(xiàn)即時通訊功能外，往往還需要和其它的業(yè)務系統(tǒng)進行集成。在本方案中引入消息網(wǎng)關的目的有兩個，一是實現(xiàn)消息的永久存儲，雖然消息中間件(mq)都提供消息的緩存功能，但是這是mq本身的特性，其主要目的防止消息中間件出現(xiàn)異常后，如宕機，消息不會丟失，且其消息存儲方式和存儲內(nèi)容的靈活性上往往不能滿足企業(yè)應用的需求，因此本方案采用消息網(wǎng)關在應用層面進行消息格式化存儲，可以將消息存儲到各種關系數(shù)據(jù)庫中，便于企業(yè)用于審計或者其它業(yè)務上的用途。引入消息網(wǎng)關的另外一個用途是進行應用集成，本方案中消息網(wǎng)關采用java平臺開發(fā)，可以非常方便的使用webservice或者httprest接口和外部系統(tǒng)進行集成，實現(xiàn)企業(yè)應用中即時通訊與其它應用場景整合。

實施例4：

在本發(fā)明的另一種實施方式中，所述方法除了上述處理方式外，其中，所述消息中間件包括多個并行處理集群。

其中，activemq具備master/slave主從容錯后備模式，兩個或多個隊列服務broker的群集，包括一個broker為當前活動有效的主broker，和一個或多個做為熱備的從broker。當主broker失效或關閉時，由其中一個從broker代替主broker提供隊列服務功能。同時activemq具有將多個broker通過網(wǎng)絡連接成brokernetwork集群的能力，主要目的是提供高擴展性。集群中多個broker是并行工作的，因此也可達到高可用性。本方案中將master/slave主從對當作單一節(jié)點，用來構成brokernetwork集群，以達到隊列服務的高可用性、容錯性。為了擴展容錯的brokernetwork集群，一種有效的基本構建單元是雙機組成方式，如圖2所示。

雙機組成的基本構建單元中包括兩個master/slave主從對，分布部署在兩臺服務器上。正常情況下，每臺服務器上運行一個主broker；當中其中某臺服務器出現(xiàn)故障時，另一臺服務器上的從broker會獲得控制權，繼續(xù)對外提供隊列服務。

實施例5：

在本發(fā)明的另一種實施方式中，所述方法除了上述處理方式外，其中，所述方法還包括：通過本地存儲、聯(lián)機對比和自動重連的多重方式對所述消息進行存儲，以確保即時通訊消息的可用性和完整性。

手機app本地存儲用于緩存收到的即時消息，避免反復從后臺獲取消息的流量開銷，同時保證在手機離線情況下也可以高效查閱本地消息；本方案中采用在手機app端集成輕量級數(shù)據(jù)庫sqllite作為消息存儲數(shù)據(jù)庫，在具體實現(xiàn)上也可以使用文件存儲方式作為本方案的消息存儲介質(zhì)。

作為一個手機app即時通訊應用，消息完整性是首要考慮的方面。影響消息完整性最主要的原因就是網(wǎng)絡異常。具體到本方案，網(wǎng)絡異常對點對點和群組即時通訊的影響是不一樣的，需要采取相對應的解決方案。

點對點即時通訊：本方案中點對點即時通訊采用的是mq隊列(queue)來實現(xiàn)的，隊列的特性使其能夠確保消費者(接收方)能夠接收到消息，在斷網(wǎng)情況下，發(fā)送方發(fā)送的消息會被隊列緩存。接收在網(wǎng)絡恢復后，app會自動重新連接消息隊列獲取離線消息，保證消息的完整性。

群組即時通訊：本方案中群組即時通訊采用的是mq主題(topic)來實現(xiàn)的，和點對點方式不同，發(fā)送到主題的消息，訂閱該主題的多個消費者(消息接收方)都能夠接收到。但是如果在某一時點某個消息接收方不在線(斷網(wǎng)情況下)，那么該接收方就不會接收到該時點的消息。解決此問題有兩種方式：

方式1：利用jms規(guī)范的持久訂閱機制。采用持久訂閱方式下，訂閱者(消息接收方)使用唯一的名稱和id在在消息中間件(mq)進行注冊，在消息接收方離線情況下，消息中間件會將該訂閱者的消息存儲下來，等訂閱者在線的時候，在將保持的消息推送給訂閱者。

方式2：在用戶進入app或者斷網(wǎng)重連時，手機app向消息網(wǎng)關發(fā)送聯(lián)機請求，通過消息id、時間等信息比對，查詢手機app端未獲取的離線消息，所有獲取的離線消息都存儲到手機app的本地緩存，如圖3所示。

以上為本申請?zhí)峁┑囊环N即時通信方法的各種實施方式的說明，下面對本申請?zhí)峁┑囊环N即時通信系統(tǒng)的實施方式進行說明。

圖4是根據(jù)本發(fā)明實施方式的一種即時通信系統(tǒng)的架構圖，如圖所示，所述系統(tǒng)包括：

發(fā)送端100，用于通過web協(xié)議和簡單文本定向消息協(xié)議，向?qū)崟r消息中間件發(fā)送消息；

消息中間件200，用于接收所述發(fā)送端發(fā)送的消息，并將所述消息實時轉(zhuǎn)發(fā)給接收端；

接收端300，用于接收所述消息中間件轉(zhuǎn)發(fā)的消息。

通過采用本發(fā)明實施方式具有下述有益效果：基于web標準規(guī)范、跨手機平臺、易于實現(xiàn)的企業(yè)級app即時通訊系統(tǒng)構建方法，滿足廣大企業(yè)即時通訊的需求。

在本發(fā)明的另一實施方式中，所述將消息從所述發(fā)送端通過消息隊列中間件發(fā)送給所述接收端包括：所述消息中間件通過消息網(wǎng)關，接收所述發(fā)送端發(fā)送的消息和向所述接收端轉(zhuǎn)發(fā)所述消息，其中，所述接收端可以是一個用戶或多個用戶。

在本發(fā)明的又一實施方式中，所述消息網(wǎng)關利用web接口或httprest接口與外部系統(tǒng)集成。

在本發(fā)明的再一實施方式中，所述消息中間件包括多個并行處理集群。

在本發(fā)明的最后一個實施方式中，所述系統(tǒng)還包括：存儲處理模塊，用于通過本地存儲、聯(lián)機對比和自動重連的多重方式對所述消息進行存儲。

需要說明的是，上述即時通信系統(tǒng)的各個實施方式與所述即時通信方法的對應技術內(nèi)容完全一致，為了避免重復，在此不再冗述。

通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到本發(fā)明可借助軟件結(jié)合硬件平臺的方式來實現(xiàn)。基于這樣的理解，本發(fā)明的技術方案對背景技術做出貢獻的全部或者部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品可以存儲在存儲介質(zhì)中，如rom/ram、磁碟、光盤等，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網(wǎng)絡設備等)執(zhí)行本發(fā)明各個實施例或者實施例的某些部分所述的方法。

本領域技術人員應當理解，以上所公開的僅為本發(fā)明的實施方式而已，當然不能以此來限定本發(fā)明之權利范圍，依本發(fā)明實施方式所作的等同變化，仍屬本發(fā)明權利要求所涵蓋的范圍。