本發明涉及一種消息隊列業務數據調度及消息隊列的實現方法,屬于物聯網技術領域。
背景技術:
伴隨著物聯網應用的廣泛普及,各個網絡運營商開始大力發展物聯網業務運營平臺,如何設計一種能融合運營商各種業務應用平臺已成為當前的熱點問題。特別是在物聯網異構設備及技術日新月異的今天,面對各種復雜的物聯網業務數據以及差異化巨大的用戶需求,人們需要提供一種統一的物聯網業務運營支撐平臺,從而用于滿足大量異構數據的融合與處理,為不同的用戶提供方便、快捷的業務應用。
在傳統運營商物聯網系統中,有各種異構的業務系統,如信息檢索業務系統、策略控制系統、用戶信息系統、計費處理數據系統、權限認證系統、CRM客戶關系管理系統,如何根據客戶的需求,將來自不同系統的不同類型的數據進行匯集與處理,通過統一的平臺展示給客戶,讓客戶進行信息查詢、權限管理等操作,這可以打造面向物聯網產業群的業務運營服務新供給,形成一種面向物聯網領域產業群的綜合智能運營管理服務平臺。
目前各個網絡運營商的物聯網業務數據、應用差異化和用戶對物聯網多元化需求在不斷攀升,特別是物聯網異構設備和技術革新所帶動的市場價值遠遠超出了最初的預期。
技術實現要素:
本發明目的在于針對上述現有技術的不足,提出了一種消息隊列業務數據調度及消息隊列的實現方法,著眼于集約運營物聯網公共服務行業,如車聯網、智能家居、智慧健康等行業,該系統面向物聯網客戶輸出業務應用信息。通過實時采集各種業務運營數據用于解決物聯網異構設備數據融合和實時處理問題。本發明的系統核心在于業務運營支撐,將運營商物聯網業務信息進行匯聚,并對物聯網業務進行抽取、組合和發布,構建穩定的泛在業務運行支撐環境,為業務使用者提供可擴展的業務應用。
本發明解決其技術問題所采取的技術方案是:一種消息隊列業務數據調度及消息隊列的實現方法,該方法包括如下步驟:
步驟1:物聯網自管理平臺用戶請求經過HTTP協議編碼,通過Socket套接字傳送到服務器端;
步驟2:到達服務器端的業務消息經過HTTP解碼后封裝為Message消息對象,并根據操作類型的優先級存入相應的接收消息隊列中,接收隊列包括三個優先級;
步驟3:通過對隊列的調度控制,獲取消息隊列模塊中的Message消息對象,進入物聯網業務解析模塊并進行解析。根據物聯網業務類型選擇相應的下部操作。如果業務請求類型為登錄執行步驟4;如果業務請求類型為注冊執行步驟5;如果業務請求類型為業務查詢執行步驟6;如果業務請求類型為修改執行步驟7;如果業務請求類型為業務定制受理,執行步驟8;
步驟4:用戶請求類型為登錄操作時時,消息隊列管理模塊獲得用戶名密碼,并查詢數據庫中用戶信息表,若果沒有用戶名或者密碼不對,服務器拒絕用戶登錄,返回到登陸界面。如果用戶名密碼匹配,查詢用戶物聯網訂購業務和用戶權限,根據相應權限將結果返回到Result消息對象,執行步驟9;
步驟5:用戶請求類型為注冊操作時時,消息隊列管理模塊獲得用戶名和密碼,若否存在用戶已存在則拒絕注冊,若用戶不存在,在將相應的用戶信息插入用戶信息表中返回success成功接收消息,并將消息封裝為Result消息對象,執行步驟9;
步驟6:用戶請求為物聯網業務查詢操作時,消息隊列管理模塊獲得查詢條件,如果是套餐使用量查詢,則根據相應的條件查詢物聯網數據中心庫中的相應記錄,并將結果封裝為Result消息對象,執行步驟9;
步驟7:用戶請求為業務修改操作時,消息隊列管理模塊獲得修改的業務屬性值,如活卡激活操作業務變更,在物聯網數據中心庫中進行修改。返回結果success成功接收消息,封裝為Result消息對象。執行步驟9;
步驟8:用戶請求為業務定制時,消息隊列管理模塊獲得修改的業務定制類型,如果物聯網數據中心存在相關的業務類型,則服務器返回success成功接收消息,反之,則返回錯誤。執行步驟9;
步驟9:用戶請求為消息確認時,消息隊列管理模塊獲得相應應答請求,在物聯網數據中心中進行修改。并返回結果最終竣工消息。執行步驟9。
進一步地,本發明的消息隊列的實現機制包括線程池機制、數據持久化機制和消息隊列管理調度機制。
有益效果
1、本發明能夠很好地加快運營商物聯網業務數據交互,實現了系統集成。
2、本發明的消息隊列管理模塊能夠方便運營商業務數據高效接入平臺。
3、本發明構建運營商物聯網業務運營支撐層的架構和所需要的功能模塊,方便搭建統一的運營支撐平臺。
4、本發明的通信層模塊描述了業務運行流程設計,包括數據封裝格式,用偽代碼描述了通信過程。
5、本發明整合了各個網絡運營商的智能管道能力,形成一種面向物聯網領域產業群的業務運營支撐體系。
附圖說明
圖1為本發明的系統架構圖。
圖2為本發明的物聯網自管理平臺邏輯架構圖。
圖3為本發明的數據中心交互圖。
圖4為本發明的業務運營支撐層架構圖。
圖5為本發明的消息隊列數據交互結構圖。
圖6為本發明的通信層接口模塊結構圖。
圖7為本發明的通信層接口模塊業務運行流程圖。
圖8為本發明的通信層接口模塊與消息隊列管理模塊數據交互圖。
具體實施方式
下面結合說明書附圖對本發明創造作進一步的詳細說明。
如圖1所示,本發明提供了一種應用于物聯網自管理平臺的業務運營支撐系統,該系統包括六大功能,即:信息查詢功能、業務受理功能、策略控制功能、增值服務功能、權限管理功能、API開放功能。(1)信息查詢功能包括賬單查詢、清單查詢、套餐使用量查詢、充值查詢、調賬查詢、余額查詢、歷史費用查詢、下載任務查詢,各種查詢信息通過消息隊列進行交換;(2)業務受理功能包括充值繳費功能、活卡激活功能、自助停復機管理,各種受理類操作通過消息隊列進行處理;(3)策略控制功能包括用戶狀態查詢、預警監控查詢、號碼清單查詢、卡信息查詢、業務統計查詢,各種策略控制信息通過消息隊列進行控制;(4)增值服務功能包括成員管理、充值管理、使用量查詢管理,增值服務信息通過消息隊列進行傳遞;(5)權限管理功能包括二級用戶管理和二級用戶權限配置管理;(6)API開放功能指將各個功能模塊的數據進行標準數據格式處理并提供給用戶使用。
圖2所示的是本發明物聯網自管理平臺邏輯架構,業務運營支撐層屬于自管理平臺核心位置,以一種開放性的架構,整合了電信運營商的智能管道能力、成熟的運營管理經驗和能力,采用分層結構,整個業務運營支撐層包括以下幾個模塊:有五個最主要的核心模塊,從底至上依次為通信層接入模塊、消息隊列管理模塊、系統服務模塊、業務解析模塊、用戶應用模塊。各個模塊的物聯網業務數據來源于物聯網數據中心,圖3所示是整個平臺的物聯網數據中心結構圖,包括物聯網自管理平臺數據處理中心、信息檢索數據倉庫、策略控制數據倉庫、用戶信息倉庫、計費處理數據倉庫、權限認證數據倉庫、CRM客戶關系管理倉庫。其中,物聯網自管理平臺數據處理中心負責集約采集各模塊數據倉庫的信息數據,并對整個平臺的數據進行邏輯控制。
通信層接入模塊的功能:從物聯網自管理平臺數據中心獲取物聯網業務數據,從而為整個平臺提供可靠的數據源。
消息隊列管理模塊的功能:作為一個開放式的物聯網業務運營支撐平臺,如何管理大量用戶同一時刻的業務請求是至關重要的,因此需要引入消息隊列管理機制。
業務解析模塊:主要有兩個方面的功能,一是對用戶的請求進行解析得出用戶請求的類型及參數,二是根據用戶的業務請求去選擇具體的業務,如用戶選擇了充值繳費這個業務,則平臺會給用戶分配充值繳費這個業務的入口權限。
系統服務模塊:主要包括了用戶信息管理服務,增值業務管理服務,業務受理服務、策略控制服務、數據庫交互功能等。
用戶應用模塊:主要針對平臺物聯網用戶,提供服務運營開發接口。
本發明設計的物聯網業務運營支撐層主要包括通信層接入模塊、消息隊列管理模塊、系統服務模塊、業務解析模塊、用戶應用模塊,其中消息隊列管理模塊與各個模塊進行物聯網業務數據的傳遞與交換,是業務運營支撐層的核心功能模塊。
針對運營商各種業務系統之間存在異構數據的問題,本發明將介紹一種物聯網運營支撐層的設計技術,描述了消息隊列管理管理模塊與業務解析模塊、系統服務模塊的數據交互流程與實現方法,同時闡述了通信層模塊業務運行流程。
一、物聯網自管理平臺邏輯架構設計
如圖2所示為物聯網自管理平臺邏輯架構,自管理平臺是按照面向服務的設計思想來進行架構設計的,目前物聯網行業數據來源復雜、非結構性特點突出,故而需要采用業務使能的形式進行開發與運行。此外,為了達到跨平臺、高并發、高性能的要求,我們采用Java軟件進行程序開發。
本發明的各層主要功能包括如下:
(1)平臺的接入用戶,主要分為兩類,即業務開發人員與業務接入用戶。業務開發人員工作于平臺的服務器端,負責開發各類物聯網業務,是平臺業務的提供者;業務接入用戶指平臺的客戶端用戶,是平臺業務的直接使用者。
(2)業務運營支撐層主要有五個最主要的核心模塊,分別是通信層接入模塊、消息隊列管理模塊、系統服務模塊、業務解析模塊、用戶應用模塊。圖4所示的框圖中描述了業務運營支撐層的主要功能模塊。
(3)物聯網客戶自管理平臺通過物聯網平臺數據處理中心獲取數據,并經由數據交互模塊存入數據庫,由此完成數據的交互對接工作。圖3所示為自管理平臺數據交互圖,其中,物聯網自管理平臺數據處理中心負責集約采集各模塊數據倉庫的信息數據,并對整個平臺的數據進行邏輯控制。
(4)平臺用戶可通過各類終端設備,包括PC端、移動端、Web端等方式接入物聯網客戶自管理平臺服務器。
二、業務運營支撐層架構設計主要包括如下:
業務運營支撐層是整個平臺的核心功能構件,負責運營商物聯網業務數據的傳輸及面向用戶提供服務能力,是平臺數據處理的中間橋梁與紐帶。
如圖4所示為業務運營支撐層的架構,本發明首先采用描述了模塊層次結構,提出一種通用的業務支撐框架,具體包括通信層接入模塊、消息隊列管理模塊、系統服務模塊、業務解析模塊、用戶應用模塊,在此基礎上,設計了消息隊列的業務數據交互過程,并描述了通信層業務數據請求模型。
本發明的業務運營支撐層主要包括如下:
(1)通信層接入模塊。該模塊從物聯網自管理平臺數據中心獲取物聯網業務數據,從而為整個平臺提供可靠的數據源。
(2)消息隊列管理模塊。作為一個開放式的物聯網業務運營支撐平臺,如何管理大量用戶同一時刻的業務請求是至關重要的,因此消息隊列管理模塊是業務支撐層的核心模塊。
(3)業務解析模塊。主要有兩個方面的功能,一是對用戶的請求進行解析得出用戶請求的類型及參數,二是根據用戶的業務請求去選擇具體的業務,如用戶選擇了充值繳費這個業務,則平臺會給用戶分配充值繳費這個業務的入口權限。
(4)系統服務模塊。該模塊主要包括以下服務,用戶信息管理服務,增值業務管理服務,業務受理服務、策略控制服務,這些都是運營商物聯網業務的基礎服務。
(5)用戶應用模塊。該模塊主要針對平臺物聯網用戶提供了服務運營開發接口。
本發明的消息隊列管理模塊設計主要包括如下:
如圖4所示,本發明的消息隊列管理模塊是整個業務運營支撐層的核心部分,它位于通信層接口模塊與系統服務模塊之間,在行業現有的傳統單條隊列的基礎上,提出了多級多用戶的消息隊列管理機制,作為一個開放式物聯網業務運營支撐平臺,如何管理大量用戶同一時刻的業務請求是至關重要的。
圖5所示為消息隊列數據交互結構圖,消息隊列模塊主要包括了兩大類:接受消息隊列和發送消息隊列,其中接收消息隊列包括三個子隊列,發送消息隊列包括三個。每一個隊列有不同的優先級,本發明設計了一種通過隊列調度的算法,從而實現了物聯網用戶請求的優先級的管理。
本發明的消息隊列業務數據調度流程包括主要如下:
步驟1:物聯網自管理平臺用戶請求經過HTTP協議編碼,通過Socket套接字傳送到服務器端;
步驟2:到達服務器端的業務消息經過HTTP解碼后封裝為Message消息對象,并根據操作類型的優先級存入相應的接收消息隊列中,接收隊列包括三個優先級;
步驟3:通過對隊列的調度控制,獲取消息隊列模塊中的Message消息對象,進入物聯網業務解析模塊并進行解析。根據物聯網業務類型選擇相應的下部操作。如果業務請求類型為登錄執行步驟4;如果業務請求類型為注冊執行步驟5;如果業務請求類型為業務查詢執行步驟6;如果業務請求類型為修改執行步驟7;如果業務請求類型為業務定制受理,執行步驟8;
步驟4:用戶請求類型為登錄操作時時,消息隊列管理模塊獲得用戶名密碼,并查詢數據庫中用戶信息表,若果沒有用戶名或者密碼不對,服務器拒絕用戶登錄,返回到登陸界面。如果用戶名密碼匹配,查詢用戶物聯網訂購業務和用戶權限,根據相應權限將結果返回到Result消息對象,執行步驟9;
步驟5:用戶請求類型為注冊操作時時,消息隊列管理模塊獲得用戶名和密碼,若否存在用戶已存在則拒絕注冊,若用戶不存在,在將相應的用戶信息插入用戶信息表中返回success成功接收消息,并將消息封裝為Result消息對象,執行步驟9;
步驟6:用戶請求為物聯網業務查詢操作時,消息隊列管理模塊獲得查詢條件,如果是套餐使用量查詢,則根據相應的條件查詢物聯網數據中心庫中的相應記錄,并將結果封裝為Result消息對象,執行步驟9;
步驟7:用戶請求為業務修改操作時,消息隊列管理模塊獲得修改的業務屬性值,如活卡激活操作業務變更,在物聯網數據中心庫中進行修改。返回結果success成功接收消息,封裝為Result消息對象。執行步驟9;
步驟8:用戶請求為業務定制時,消息隊列管理模塊獲得修改的業務定制類型,如果物聯網數據中心存在相關的業務類型,則服務器返回success成功接收消息,反之,則返回錯誤。執行步驟9;
步驟9:用戶請求為消息確認時,消息隊列管理模塊獲得相應應答請求,在物聯網數據中心中進行修改。并返回結果最終竣工消息。執行步驟9。
本發明同時設計了消息隊列的實現機制,包括線程池機制、數據持久化機制和消息隊列管理調度機制。主要解決的問題包括:多線程資源共享問題,消息隊列的調度問題以及數據庫訪問機制的優化。如圖1所示,業務支撐層業務數據交互主要包括了信息查詢交互、業務受理交互、策略控制交互、增值服務交互、權限管理交互、API開放交互,數據交互信息均是通過消息隊列進行管理。
(1)線程池機制設計
線程池主要用來管理各種消息請求,本文設計了一種基于中斷任務控制的線程池管理機制,具體業務偽代碼設計如下:
(2)數據持久化機制設計
訪問數據庫的方式有很多,JDBC(Java Data Base Connectivity,java數據庫連接)是一種用于執行SQL語句的Java API,可以為多種關系數據庫提供統一訪問,它由一組用Java語言編寫的類和接口組成。JDBC為工具/數據庫開發人員提供了一個標準的API,據此可以構建更高級的工具和接口,使數據庫開發人員能夠用純Java API編寫數據庫應用程序。但是JDBC存在的缺陷是每次訪問數據庫都需要建立和數據庫的的鏈接,這個鏈接的過程浪費了大量的時間。
本設計在考慮數據庫交互的優化時,首先想到了數據庫的連接池機制,數據庫的連接池仍然采用JDBC機制,但是他不需要每次對去連接數據庫,節省了大量的時間。其后經過大量的調查,發現了Hibernate機制,它包含了數據庫的連接池機制,而且還能實現了數據的持久化,簡化了數據的操作過程,并提高了系統的可靠性,具體過程如下:
步驟1:在工程中加入Hibernate功能,配置相應的配置文件,數據庫連接池根據數據庫服務器配好URL,JDBC驅動等。
步驟2:數據庫中使用到的表包括用戶信息表,業務庫,權限管理表等進行映射處理。生成對應的關聯文件以及POJO實體類。
步驟3:將數據庫的各種操作封裝在HibernateDao類中。
(3)消息隊列管理調度機制設計
消息隊列管理調度算法主要是實現消息隊列的調度,它是一種特殊的隊列機制,阻塞仍然采用FIFO(即:先進先出)原則進行存取數據,可以實現對線程共享資源的管理,提高運營商物聯網業務數據高效安全的傳輸。
消息隊列中我們事先封裝好相應的消息對象,我們將用戶的物聯網業務請求封裝成Message消息對象,并將處理結果封裝為了Result消息對象,具體業務偽代碼設計如下:
本發明的通信層接入模塊設計主要包括如下:
如圖6所示為通信層模塊結構圖,該模塊從物聯網自管理平臺數據中心獲取物聯網業務數據,從而為整個平臺提供可靠的數據源,并將數據傳輸至消息隊列管理模塊。
本發明的通信層接入模塊業務內部通信過程主要包括如下:
步驟1:物聯網自管理平臺數據中心將業務數據進行ASN.1編碼;
步驟2:將ASN.1編碼后的消息體通過Socket套接字傳送到消息隊列管理模塊;
步驟3:消息隊列管理模塊將收到的物聯網業務消息進行解碼,然后放在一個消息發送隊列中,交給業務運營支撐層去處理;
步驟4:業務運營支撐層從消息隊列中取出處理后的消息;
步驟5:通過Socket套接字將接收的消息回傳給用戶;
本發明的通信層接入模塊業務運行流程設計如圖7所示,為了滿足雙工通信的要求,即服務器和客戶端可以同時收發數據,需建立發送,接收兩個線程,如圖8所示,通信層接口模塊與消息隊列管理模塊有兩個接口:receiveQueue(即:接收消息隊列)和sendQueue(即:發送消息隊列),接口數據類型為Message消息對象和ResaultMessage結果對象類,具體流程主要包括如下:
步驟1:在建立連接后該線程取出Socket連接;
步驟2:接收消息并通過接收消息隊列傳送至消息隊列管理模塊,同時建立發送線程;
步驟3:監聽發送消息隊列sendQuene,取出結果并發送,與此同時,接收線程處于阻塞狀態;
步驟4:如果物聯網平臺用戶請求斷開連接,則關閉Socket連接;
步驟5:為防止連接數過多,將超過池中線程數的連接放入緩沖池,等到出現空閑線程再取出;
步驟6:關閉Socket套接字連接,并記錄接收消息隊列receiveQueue中的消息對象。
本發明的通信層接入模塊與消息隊列管理模塊交互過程設計如下:
通信層接入模塊和消息隊列管理模塊以消息隊列作為數據傳遞接口,消息隊列采用的是BlockingQueue機制,它是一種特殊的隊列機制,BlockingQueue仍然采用FIFO原則進行存取數據,但是他加入了特殊的機制實現了對線程共享資源的管理,可以高效安全傳輸數據。消息隊列中元素是封裝好的業務對象。我們將用戶的業務請求封裝為了Message對象,并將服務器處理結果封裝為了ResultMessage。消息隊列、Message以及ResultMessage的定義如下:
為了體現業務的優先級我們分別定義了三個接受隊列和三個發送隊列,接受隊列分別為:receiveQueue1,receiveQueue2,receiveQueue3,其中三個隊列的優先級依次遞增。發送隊列分別為:sendQueue1,sendQueue2,sendQueue3優先級依次遞增,隊列偽代碼如下:
Message是對用戶請求的封裝主要包括:業務類型、地點、時間、請求對象、用戶名密碼、socket標記、登錄時間、操作狀態等,詳細可見如下代碼。
if(this.operation.equals("log")||this.operation.equals("register")){//用戶業務請求判斷,此處為注冊或登錄操作
ResultMessgae是對服務器對用戶請求響應的封裝,主要包括:主要包括了結果和socket標記兩個屬性。結果是用戶請求的處理結果,包括兩大類,一種是status表示的是狀態值,一種是result是結果集。socket標記是保證服務器的響應能夠正確的交付給相應用戶。代碼如下
。