物聯網業務系統中的流量查詢子系統分析、設計與實現*

王禹皓 趙爾平

（西藏民族大學信息工程學院，陜西 咸陽 712082）

0 引言

在新技術不斷涌現的今天，人們的生活也越來越便利，高鐵的出現方便了人們的出行，移動網絡的升級讓我們擁有了更好的上網體驗，移動支付讓我們擺脫了現金的累贅。在經歷了計算機和物聯網的快速發展后，物聯網成為了當前信息產業的最新發展方向。物聯網概念上是指將網絡虛擬數據進行實體化，與實際物品和生活場景相結合，將物品與物品之間進行關聯化管理，通過物品相互之間的信息交換，實現真正的物物相息[1]。

在物聯網的系統中，數據信息的交互產生的流量數據和手機流量相似。運營商會對流量數據傳輸提供相應的流量套餐服務。流量查詢子系統作用是對物聯網中各種產品流量進行查詢處理。該子系統在實現基本查詢業務的基礎之上又具有較高的處理速度。查詢所覆蓋的產品范圍比較廣其中包括系列類產品、非系列類產品、月流量等。該系統為純后臺系統，以Java 作為開發語言進行開發，框架選取的是SpringBoot與持久層框架MyBatis，因其配置簡單，方便搭建快速開發，能實現功能的靈活性［2］。文章將圍繞物聯網流量查詢子系統展開研究。

1 研究現狀

流量查詢，是運營商所必要提供的服務之一，也是用戶得知可使用剩余流量的方式。系統需要對用戶所使用的流量數據進行計算處理，給用戶反饋剩余流量情況。目前有多種的流量查詢，各自應用于不同的場景，不同業務所涵蓋的范圍也不相同。比如孫曉燕；高婷；曾悠；陳晴研發的，采用asp.net 平臺，SQL Server數據庫配置方案，基于B/S架構的省市寬帶流量Web 查詢系統，實現某一天或某一時段的數據流量連續性查詢,滿足科研開發人員、網絡設計人員的查詢要求［3］。如涵蓋了流量查詢的手機流量管理專家流量銀行。當今生活中，有許多智能化產品能提供良好的服務，這都依賴于數據流量的傳輸。物聯網的各項產品也不例外，為了支持物聯網用戶的流量查詢，物聯網業務系統的流量查詢子系統應運而生。

2 流量查詢子系統需求分析

2.1 需求分析

流量查詢子系統，主要提供用戶套餐流量查詢的后臺業務支撐。

用戶每日發起流量查詢請求數量較大，所以該子系統需要有處理大量請求的能力，同時也需要有較快的處理速度，要能夠快速解決請求的積壓問題。

流量查詢子系統，需要按照數據流轉流程和業務流程正確及時的對請求做出響應，保證反饋信息的準確性。對于轉發過程中出錯的訂單，需要進行統一的記錄。為了提高用戶的體驗，這些因轉發導致出錯的訂單需要被重新執行。

可能存在數據非法或者是數據的不規范的請求，所以該子系統需要具有對不合法數據以及不規范數據正確判斷和處理的能力，以減少不合法請求對資源造成的浪費。

其數據來源為:用戶發起流量查詢請求，經過第三方系統的轉發，至Nginx 主機，Nginx 進行負載均衡，將請求發送至物聯網業務支撐系統。

根據用戶需求描述，大致處理流程如下：業務支撐系統需要對請求報文進行入庫處理，將請求信息存入訂單表。訂單表需要有對應的狀態信息，以便于客戶端對報文進行取出，發往服務端進行處理。服務端需要對客戶端發來的請求進行查重，以避免重復訂單操作浪費資源。若為重單，則應該進行返回查重表的內容信息。如果不是重單，應該進行相應的業務判斷操作，校驗用戶等一系列信息的合法性。校驗不通過的訂單請求應該被定義為失敗單加入查重表。校驗通過則進行后續步驟，操作完成后也應在查重表進行相應的記錄。

2.2 數據類型

訂單數據會以XML 報文格式被發送到物聯網業務系統，進行解析并映射到對象中，用于程序處理。處理完畢后的返回數據經過拼裝組裝成XML 報文形式進行對外反饋。

3 流量查詢子系統設計

3.1 流程處理設計

流量查詢子系統是用以處理系列類產品流量查詢、非系列類產品流量查詢、月流量查詢三種查詢請求的系統。

客戶的請求以XML 報文的形式被外部系統發送物聯網業務系統（以下簡稱“系統”）的流量查詢子系統。系統接收到報文并進行解析入庫處理。訂單表中狀態為未處理的記錄，將由客戶端取出，交由服務端進行處理。服務端將進行查重處理,其依據是訂單的唯一標識流水號。查重成功后會對報文進行解析，以獲取報文中的相應信息，如用戶的手機號等，用于后續一系列校驗，通過則繼續處理。反之記錄入查重記錄表。客戶端接收來自服務端的處理結果，對外反饋。如圖1所示。

圖1 基本處理流程圖

3.2 數據庫設計

流量查詢子系統采用Oracle 作為數據庫。Oracle數據庫有海量數據處理的優勢。

錯單入庫工具采用HBase 作為數據庫，HBase 是NoSql數據庫[4]。Row Key生成規則為：文件名后六位+文件首行前四位（文件生成時間）+數據行號。

部分數據對象表：

表1 訂單請求對象表

表2 組織信息對象模型

表3 用戶狀態對象模型

4 系統功能的開發和實現

4.1 錯單入庫工具開發

在訂單轉發過程中，業務支撐系統需要對請求報文進行入庫之前，會有一些轉發出錯的訂單請求。這些訂單請求將會被第三方系統收采集，存儲到指定位置，為了保證訂單都能順利被執行。同時也是為了更好的輔助流量查詢子系統完成流量查詢任務設計了錯單入庫工具。如圖2所示：

圖2 錯單入HBase庫工具結構圖

首先錯單入庫工具功能：轉發過程中的失敗單，被錯單入庫工具進行解析文件并入HBase 庫。后被物聯網業務系統掃描。保證了所有請求報文得到處理。

錯單入庫工具三個目錄功能：這樣設計避免了宕機對錯單入庫的影響，避免出現未入庫完全的文件。

錯單入庫工具的根據文件信息建立表部分代碼實現：

4.2 流量查詢子系統實現

子系統處理三種類型的流量查詢請求，對每一種請求都有專門的處理方式，用于支持物聯網的產品流量查詢業務。能夠接收報文，并解析報文對報文的正確性進行檢驗，如果為非法報文需要進行相應記錄并給出相應反饋。進行流量查詢會記錄開始與結束時間，用于后期收集處理時長，對系統運行情況判斷和對余量查詢子系統效率進行檢驗。報文中解析出來的OprCode（操作代碼）用于確認是那種產品。

程序中優化業務中的系列類產品查詢操作，將OprCode 為3 的（系列類產品）流量查詢下的所有產品，進行抽象，通過一條SQL 將原來需多次查詢的內容一次查詢出來。從而降低了對數據庫的訪問次數。經過效率測試，每條訂單的處理時間相較之前提升了百分之三十，能更好的實現快速處理大批量訂單的要求。對所有產品的相似處理方法，進行提取和封裝，做到了代碼簡潔，提高了代碼的內聚性。降低了子系統間的耦合程度，便于后期更新和完善。

4.3 程序邏輯

流量查詢子系統服務端處理流程圖如圖3所示流量查詢整體流程如下：

圖3 流量查詢流程圖

4.3.1 運行程序，加載配置文件。配置文件中包含部分容易變更的配置參數。包括及客戶端需要掃描的訂單表信息、查重表信息、連接Oracle 數據庫失敗重試次數和失敗重試間隔時間等配置項。

4.3.2 客戶端會不斷去掃描指定訂單表，會根據相應的要求對訂單狀態進行判斷，判斷是否有STATE(訂單狀態)為0的訂單,如果有則進行后續步驟。

4.3.3 掃描到的符合要求的訂單狀態將會被變更為1，并有客戶端發送給服務端，如果發送失敗（超時/報文存在問題）將會變更狀態為11。

4.3.4 服務端流量查詢子系統會對該訂單進行查重檢測。若檢查到為重單，則返回查重表的相應內容信息，反之，則對報文進行解析。

4.3.5 解析完報文獲取到相應信息，根據請求類型進行不同的校驗，校驗成功則進行后續操作，不成功則加入查重表，反饋錯誤信息。

4.3.6 解析完的報文信息中獲取到OprSeq（操作流水）、UserID（用戶標識）、和OprCode(操作類型)等信息。

4.3.7 流量查詢子系統將調用第三方系統提供的接口獲取當前帳期的套餐余量信息。針對訂購非系列產品的用戶的號碼，返回信息包括：號碼、套內流量總量(MB)、流量余量(KB)等現有返回信息；在訂購系列產品的情況下，返回信息包括：號碼、所在組織訂購系列產品ID、系列產品流量總量(MB)等。

4.3.8 流量查詢子系統針對返回的產品流量進行計算。

4.3.9 處理完成后將產品訂購實例、用戶狀態等信息、寫入日志組裝報文，修改訂單狀態為3，并記入查重表。后將報文反饋給客戶端。

4.3.10 客戶端將報文組裝、處理，完成后修改訂單狀態為6，并將報文發送給網狀網。

4.4 接口定義

流量查詢子系統接口定義，如表4 流量查詢子系統接口表4所示：

表4 流量查詢子系統接口定義表

接口描述：

（1）TrafficQueryService 流量查詢數據接口

（2）QueryRepetitionService 查詢重復訂單數據接口

（3）UserInfoService 用戶信息數據接口

（4）TPBInfoService 第三方系統信息接口

4.5 部分實現

對報文頭的解析：

業務報文提取：