物联网业务系统中的流量查询子系统分析、设计与实现*

王禹皓 赵尔平

（西藏民族大学信息工程学院，陕西 咸阳 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 部分实现

对报文头的解析：

业务报文提取：