论文范文:基于 RFID 的分布式物流仓储管理系统的 设计与实现

来源: 未知 作者:paper 发布时间: 2022-06-30 11:34
论文地区:中国 论文语言:中文 论文类型:工程硕士
随着社会的发展,人们对于物流行业的需求越来也高。而仓储管理作为物 流供应链中关键的一环,对物流企业的高效运作有着不可替代的作用。但目前 来看,国内大部分的物流企业信
随着社会的发展,人们对于物流行业的需求越来也高。而仓储管理作为物
流供应链中关键的一环,对物流企业的高效运作有着不可替代的作用。但目前
来看,国内大部分的物流企业信息化程度不高,作业方式还停留在手工阶段,
企业普遍存在仓储管理效率低、人工成本过高、数据难以实时更新以及数据错
误风险高等问题。此外,现有的仓库管理系统有着系统容量不足、扩展性不佳
等问题,并且没有提供完整的数据采集以及任务决策的全套方案,难以应对全
球日益扩大的仓库管理规模。
本论文从上述国内企业所存在的问题入手,基于 RFID(Radio Frequency
Identification)技术、采用分布式的架构设计并实现一种仓储管理系统,该系统
包含了三个子系统:仓库管理子系统、RFID 中间件子系统、决策平台子系统。
本论文进行了各个子系统的需求分析和架构设计,并在此基础上进行系统的开
发。仓库管理子系统作为主系统,主要负责仓库管理相关业务,论文基于 RFID
技术优化了包括出库、入库、盘点等业务流程,设计并实现了包括系统管理模
块、基本信息管理模块、库存管理模块、入库管理模块以及出库管理模块等功
能模块。RFID 中间件子系统主要用于标签数据的采集、处理和上传,论文基
于 ALE(Application Level Event)标准设计了数据处理服务模块以及数据访问
服务模块,简化了实现逻辑,同时进行了中间件的接口设计。决策平台子系统
主要用于仓库任务的高效决策,论文基于主从架构模式设计了 Master 与 Slave
节点,梳理了平台的各项业务流程,并定义了消息传递格式。
整个系统在 JaveEE 平台上进行开发,采用 B/S 和 C/S 的开发架构,并结合
了 WebService、Jquery、HTML、JS、Mysql 等技术。系统利用 Docker、Kubernetes
等技术可以实现系统服务的容器化以及分布式部署管理,并借助云的思想实现
系统的 SaaS 化。该系统创造性地利用分布式架构将仓库管理、数据采集与处理、
任务决策三个部分有机地统一了起来,并结合 RFID 和云服务,提高了系统的
整体性和扩展性、增强了系统的处理性能、降低了企业的运营维护成本,显著
地提高了仓库管理效率,这对物流企业的信息化和智能化具有非常重要的意义。
关键词:仓库管理;中间件;决策平台;RFID;分布式
Abstract
With the development of society, people's demand for logistics industry is
higher and higher. As a key part of logistics supply chain, warehouse management
plays an irreplaceable role in the efficient operation of logistics enterprises. But at
present, the informationization degree of most domestic logistics enterprises is not
high, and the operation mode is still in the manual stage. There are many problems
in the enterprises, such as low efficiency of warehouse management, high cost of
manpower, difficulty in real-time updating of data, high risk of data error and so on.
In addition, the existing warehouse management system has some problems, such as
insufficient system capacity, poor scalability, and does not provide a complete
solution of data collection and task decision-making scheme, so it is difficult to cope
with the increasing scale of warehouse management in the world.
This paper starts with the problems existing in the above domestic enterprises,
designs and implements a warehouse management system based on RFID (Radio
Frequency Identification) technology and distributed architecture, which includes
three subsystems: warehouse management subsystem, RFID middleware subsystem
and decision platform subsystem. This paper carries on the requirement analysis and
architecture design of each subsystem, and develops the system on this basis. As the
main system, the warehouse management subsystem is mainly responsible for the
related business of warehouse management. Based on RFID technology, this paper
optimizes the business process including outbound, inbound and inventory, designs
and implements the functional modules including system management module, basic
information management module, inventory management module, inbound
management module and outbound management module. RFID middleware
subsystem is mainly used for the collection, processing and upload of tag data.
Based on ALE (Application Level Event) standard, this paper designs data
processing service module and data access service module, which simplifies the
implementation logic, and designs the interface of middleware. The decision
platform subsystem is mainly used for efficient decision-making of warehouse tasks.
Based on the master-slave architecture pattern, this paper designs Master and Slave
nodes, sorts out the business processes of the platform, and defines the message
transfer format.
The whole system is developed on JavaEE platform, using B/S and C/S
development architecture, combined with WebService, Jquery, HTML, JS, MySQL
and other technologies. Using Docker, Kubernetes and other technologies, the
system can realize the containerization of system services and distributed
- II -
哈尔滨工业大学工程硕士学位论文
deployment management, and realize the SaaS of the system with the idea of cloud.
The system creatively uses the distributed architecture to organically unify the three
parts of warehouse management, data collection and task decision-making, and
combines RFID and cloud services to improve the integrity and expansibility of the
system, enhance the processing performance of the system, reduce the operation and
maintenance costs of the enterprise, and significantly improve the efficiency of
warehouse management, which is of great significance to the informatization and
intelligence of logistics enterprises.
Keywords: Warehouse Management, Middleware, Decision Platform, RFID,
Distributed Systems
- III -
哈尔滨工业大学工程硕士学位论文
目 录
摘 要 ..........................................................................................................................I
ABSTRACT................................................................................................................ II
第 1 章 绪 论 ...........................................................................................................1
1.1 课题背景及研究意义 ................................................................................ 1
1.2 国内外研究现状........................................................................................ 3
1.2.1 仓库管理系统研究现状............................................................................4
1.2.2 RFID 中间件研究现状 ..............................................................................5
1.2.3 决策平台研究现状....................................................................................6
1.3 本文主要工作 ........................................................................................... 7
1.4 本文章节安排 ........................................................................................... 8
第 2 章 相关技术及理论概述 ...................................................................................9
2.1 仓储管理概述 ........................................................................................... 9
2.2 RFID 技术概述.......................................................................................... 9
2.2.1 RFID 系统基本组成 ..................................................................................9
2.2.2 RFID 系统工作原理 ................................................................................10
2.3 分布式技术概述.......................................................................................11
2.3.1 Docker 容器技术...................................................................................... 11
2.3.2 Kubernetes 容器编排技术 .......................................................................12
2.4 本章小结................................................................................................. 14
第 3 章 物流仓储管理系统的需求分析及架构设计 .............................................15
3.1 系统总体需求分析及架构设计 ............................................................... 15
3.1.1 系统总体需求分析..................................................................................15
3.1.2 系统总体架构设计..................................................................................15
3.2 仓库管理系统需求分析 .......................................................................... 17
3.3 RFID 中间件需求分析............................................................................. 18
3.4 决策平台需求分析 .................................................................................. 18
3.5 本章小结................................................................................................. 19
第 4 章 仓库管理系统的设计 .................................................................................20
4.1 仓库管理系统架构设计 .......................................................................... 20
4.2 仓库管理系统业务流程设计 ................................................................... 22
- IV -
哈尔滨工业大学工程硕士学位论文
4.2.1 入库流程..................................................................................................22
4.2.2 出库流程..................................................................................................23
4.2.3 盘点流程..................................................................................................24
4.3 仓库管理系统模块设计 .......................................................................... 26
4.3.1 系统管理模块..........................................................................................26
4.3.2 基本信息管理模块..................................................................................26
4.3.3 库存管理模块..........................................................................................27
4.3.4 入库管理模块..........................................................................................27
4.3.5 出库管理模块..........................................................................................27
4.4 数据库模型设计...................................................................................... 28
4.5 本章小结................................................................................................. 32
第 5 章 RFID 中间件的设计 ...................................................................................33
5.1 RFID 中间件架构设计............................................................................. 33
5.2 RFID 中间件模块设计............................................................................. 34
5.2.1 数据处理服务模块..................................................................................35
5.2.2 数据访问服务模块..................................................................................36
5.3 RFID 中间件接口设计............................................................................. 36
5.4 数据库模型设计...................................................................................... 38
5.5 本章小结................................................................................................. 38
第 6 章 决策平台的设计 .........................................................................................40
6.1 决策平台架构设计 .................................................................................. 40
6.2 决策平台业务流程设计 .......................................................................... 42
6.2.1 file 业务流程 ............................................................................................42
6.2.2 start/stop 业务流程...................................................................................43
6.2.3 query 业务流程 ........................................................................................45
6.3 决策平台功能设计 .................................................................................. 46
6.3.1 Master 节点 ..............................................................................................46
6.3.2 Slave 节点.................................................................................................47
6.4 消息格式设计 ......................................................................................... 48
6.5 本章小结................................................................................................. 51
第 7 章 系统的实现 .................................................................................................52
7.1 系统实现环境 ......................................................................................... 52
7.2 仓库管理系统的实现 .............................................................................. 52
7.2.1 主要模块的实现......................................................................................52
- V -
哈尔滨工业大学工程硕士学位论文
7.2.2 系统测试..................................................................................................60
7.3 RFID 中间件的实现 ................................................................................ 63
7.3.1 中间件功能实现......................................................................................64
7.3.2 可视化界面..............................................................................................64
7.3.3 中间件测试..............................................................................................66
7.4 决策平台的实现...................................................................................... 68
7.4.1 节点功能实现..........................................................................................68
7.4.2 可视化界面..............................................................................................72
7.4.3 平台测试..................................................................................................73
7.5 本章小结................................................................................................. 75
结 论 .......................................................................................................................76
参考文献 ...................................................................................................................78
哈尔滨工业大学与南方科技大学联合培养研究生学位论文原创性声明和使用权限..... 82
致 谢 .......................................................................................................................83
- VI -
哈尔滨工业大学工程硕士学位论文
第 1 章 绪 论
1.1 课题背景及研究意义
21 世纪以来,随着社会经济的持续发展以及人们物流需求的不断增长,一
批又一批的中小型物流企业如春笋般涌出。根据前瞻产业研究院发布的《中国
仓储行业市场前瞻与投资战略规划分析报告》[1]统计,从 2010 年到 2018 年,
中国社会物流总额从 125.4 万亿元增长到了 283.1 万亿元,仓储类企业数量也
从 1.67 万家增加到了 6 万家,年复合增长率达到了 17.4%。然而物流市场规模
的增加也加剧了企业之间的竞争,这不仅仅体现在资源、人才和技术等因素上,
企业自身的管理水平也成为了重要的竞争指标。在这个充满竞争的全球化背景
下,如何提高企业管理水平和效率、增强企业管理质量、减少企业运营成本都
是企业需要思考的重要议题。而仓储管理作为物流供应链系统的基础和物流管
理的核心,在提高企业核心竞争力上有着不可忽视的作用。
仓储管理是物流供应链中非常关键的一环,它通过一定的方式对仓库或者
仓库中的物资进行管理,包括出库、入库、盘点等等,以达到对仓库物资的合
理管控。传统的仓储管理,主要通过人工管理方式,手动记录与物资相关的数
据并进行管理,这种管理方式非常繁琐且容易出错,仅仅适合仓库规模不大的
情况。当仓库规模扩大时,普遍存在一些包括作业效率低下、人力成本变高、
数据难以及时更新、信息化水平低、物资位置难以确定等等的问题[2]。于是,
为了提高仓储管理水平和企业竞争力,很多企业和学者都开始对仓储管理技术
进行研究[3,4]。在这个背景下,仓储管理系统得以诞生。它通过互联网技术,以
信息化的方式对仓库进行管理,进而极大地提高仓储管理的水平,而采用 RFID
作为信息化采集数据的识别技术,相对于之前的条形码技术来说,有着识别速
度更快、数据记忆容量大、具有穿透性和无障碍阅读等等诸多优点,可以极大
提高企业的管理效率[5]。
仓库管理系统的不断更新迭代也带动了 RFID 技术的发展,面向 RFID 技
术的终端设备种类也开始越来越多,不同厂商所采用的 RFID 接口和标准也不
尽相同,这些设备的差异会给上层系统带来诸多麻烦。比如,更换不同接口或
者标准的终端设备后,上层系统需要进行大量的逻辑修改,这样就给开发人员
带来大量重复性工作,进而降低了系统开发和维护的效率。由于 RFID 系统工
- 1 -
哈尔滨工业大学工程硕士学位论文
作特性以及环境复杂性,不同规格的阅读器以及电子标签之间存在相互的电磁
干扰,这会导致 RFID 读写器采集到的数据信息发生冗余和错误。此外,阅读
器与上层系统之间的直接交互也难以保证数据的正确性和安全性。而 RFID 中
间件刚好可以解决这些问题,越来越多的研究机构开始了对 RFID 中间件的研
究[6,7]。在逻辑上,RFID 中间件位于上层应用和终端设备之间,主要用于对上
传的数据进行处理。RFID 中间件向下提供了统一的标准和接口,屏蔽了底层
设备的差异,保证不同的 RFID 终端设备可以通过这个接口连接到中间件;RFID
中间件自身包含数据的过滤、验证等逻辑,可以将底层采集的数据进行清洗处
理后再上传给上层应用;RFID 中间件向上提供了统一的接口,便于上层应用
获取数据。通过采用 RFID 中间件,上层应用可以屏蔽掉底层的细节,当更换
底层终端设备时,只需要完善中间件的接口逻辑而无需更改上层应用系统逻辑,
降低了系统的复杂性,提高了数据传输和存储的安全性。
而仓库管理规模的扩大也带来了系统业务的多样化和功能的复杂化,这对
系统的计算决策能力提出了一个新的挑战。要知道,传统仓库管理系统在处理
入库、出库以及盘点等业务的过程中,对于入库位置、盘点顺序、路径规划、
订单拣选、销售预测等物流问题的决策,往往需要进行手动统计和计算。即使
部分先进企业能够自行设计开发出一套决策系统以用于内需,但该系统并不具
有普适性和复用性,仅仅之能针对某一特定的环境,这样极大的增加了企业的
开发和维护成本。而决策平台就是为了解决企业的这一难题而生,它能够提供
一个通用的决策模型框架,以应对不同环境下的不同决策任务,从而避免了大
量的重复性工作。决策平台主要负责分配底层的计算资源实现任务的并行计算,
而不关心底层算法的具体实现,当然这些对于用户来说都是透明的,用户能够
看到的只是任务的决策结果而已。
随着人们对物流需求的急剧增多,物流数据短时间内呈现爆发式的增长,
使得将所有业务单元集中部署到一个或几个大型物理机上的集中式体系结构已
经越来越不能满足物流系统的需求了,而分布式的处理方式由于其高可用性、
易扩展性、低耦合性等特点,越来越受到业界的欢迎。分布式系统将硬件或者
软件资源分布在不同主机之上,系统各部分组件通过网络消息进行相互通信和
协调,实现整个系统的正常运行。简单来说,就是一群独立的计算机集群共同
向外提供服务,用户可以通过某一接口对系统服务进行访问,这个服务具体运
行在哪个计算机上是不确定的,但对于用户来说,服务的来源无法感知,就好
- 2 -
哈尔滨工业大学工程硕士学位论文
似仅有一台计算机在专门提供服务一样。采用分布式的架构,在逻辑上,整个
系统被分割为各种独立的微服务,有利于降低系统的耦合度,提高系统扩展性
和稳定性;在资源上,计算机集群越多,能够使用的硬件资源(比如 CPU、GPU、
内存等)就越多,有利于提高系统的并发处理能力。因此基于分布式架构的仓
库管理系统能够极大提高系统的运行和维护效率,从而提高整个仓库管理的效
率。
此外,新世纪云理念的迅速兴起和推广,使得更多企业开始偏向于使用成
熟的云产品而不是自己再去开发产品,因此基于云的思想实现仓库管理系统已
经成为一种趋势。基于云来说,不论是 IaaS、PaaS 还是 SaaS,都是云服务商
将服务器资源作为服务并提供其他用户使用的产品,例如 SaaS 即软件即服务,
服务提供商将软件打包成服务并部署在服务器上,而用户可以花费一定的支出
而获得该服务的访问使用权,这种服务方式避免了用户本地部署所带来的麻烦。
采用云计算服务有诸多好处,企业购买后就能使用云服务提供商提供的最新的
服务,而无需关注服务的具体实现和更新维护,这样一来既能获取优质的计算
资源又能减少企业的开发以及维护成本。事实上,对于一些中小企业来说,企
业内部的业务场景不会很复杂,选用市场的成熟云计算产品,能够明显的降低
企业开发成本,同时提高灵活度;对于大企业来说,复杂的业务逻辑以及业务
规模使得企业对技术需求比较高,而使用第三方可靠稳定的云计算产品,可以
巧妙地将企业技术问题以及资源问题转移给服务提供商,这样能够提高企业产
品聚焦度,避免因其他问题而影响企业的发展。
本论文结合 RFID 技术和计算机技术,设计并开发出了一套物流仓储管理
系统。针对传统仓储管理系统的仓管功能单一、集中式架构不易扩展、本地安
装和托管等局限和不足,本系统采用分布式的架构进行设计,开创性地汇集了
仓库管理、数据采集与处理、任务决策三大功能于一身,同时利用云技术提供
对外 SaaS 化服务,减少用户使用成本。本系统的实现使得仓库管理变得自动化,
提高了仓库管理的安全性和实时性,同时解决了现有仓储管理系统的一些不足
之处,增强了系统的计算处理能力,降低企业的运营维护成本。这对企业乃至
世界的信息化和智能化具有非常重要的现实意义。
1.2 国内外研究现状
随着计算机技术以及物联网技术的急速发展,社会的信息化程度越来越高,
- 3 -
哈尔滨工业大学工程硕士学位论文
企业和个人无时不刻都要与海量的信息打交道,这对于信息交互的速度又有了
一个更高的要求。而射频识别技术(RFID)作为一种快速、无接触的信息交互
技术开始逐步受到各类企业单位的广泛应用,从工业自动化、物流管理到身份
识别、电子收费等各个领域都有着 RFID 的影子[8,9],RFID 技术也得此机遇开
始急速发展。西方发达国家率先研究并制定了 RFID 相关标准(EPCglobal、
ISO/IEC 标准),同时应用到各个企业,沃尔玛集团和麦德龙集团最早获益,借
由 RFID 技术大幅提高了供应链效率,节省了昂贵的管理费用。日韩等亚洲发
达国家也紧随其后开始自主研究 RFID 技术,并制定了自己的 RFID 标准(UID
标准)[10]。
国内的 RFID 技术起步比较晚,但是发展迅猛,已经应用在很多包括身份
识别、电子收费等诸多领域。京东物流在 2012 年运用 RFID 技术实现自动化、
信息化的仓库管理,提高了货物处理能力,大大提高了自身的仓库管理效率[11]。
国内有一些软件开发公司也在设计基于 RFID 的仓库管理系统,以应对各领域
未来的需求。此外,很多国内学者也开始研究各个领域包括医疗设备管理、车
辆管理等系统中 RFID 技术的应用[12]。但由于 RFID 技术成本高昂,国内大部
分中小企业还停留在最原始的人工管理阶段,自动化水平较低,难以实现方便
高效的仓库管理。因此作为物联网的核心技术,RFID 技术迫切需要得到推广
和应用,而它的发展必将推动企业全面自动化时代的到来。
1.2.1 仓库管理系统研究现状
在当今竞争激烈的全球商业环境下,各个企业和组织都在强调资产回报率。
有研究表明,仓储成本占企业销售成本的 2%到 5%左右[13],可见仓储管理的重
要性,如何将仓储成本降至最低已成为各个企业所必须考虑的重要商业问题。
为了提高仓库的生产效率,降低运作成本,有必要对仓库资源进行有效的配置
[14]。而决定仓库效率的一个重要方面就是如何准确和高效地确定仓库中数千种
产品的适当储存位置。在广泛的研究了影响仓储分配的各种因素(如拣货方式、
物资搬运系统、产品特性、需求分析、空间需求等等)之后,有人建议,针对
上述因素选择适当的存储分配策略和路由方法是提高效率的可能解决方案[15]。
此外,其他一些学者还研究了解决各种决策支持模型的求解算法,以解决仓库
运营的规划问题[16]。
结合了 RFID 技术的仓库管理系统将极大方便仓库货物数据的采集和共
- 4 -
哈尔滨工业大学工程硕士学位论文
享,提高管理的效率和准确性。使用自动化的仓库管理系统将减少仓储管理的
人工数量甚至仅仅保留维护系统的人工,极大降低了人工成本,并通过缩短周
期时间为客户提供更大的服务能力。仓库管理系统将提高产品快速流动性、减
少实时库存并可以服务于更大存储容量的仓库。仓储管理过程中数据采集的准
确性和效率的提高可能导致其安全水平的降低。但是从总体看,这种安全性的
降低所带来的影响有限,几乎可以忽略。使用仓库管理系统不会影响到控制库
存水平的因素(包括批量大小、提前日期和需求变换),有助于提高效率和组织
性,进而一定程度提高了库存容量[17]。
企业对仓库管理需求的快速增长也带动了各类人员在仓库管理系统上的研
究。熊平[18]设计实现了一套基于 RFID 的仓库管理系统,引入 WebService 技术
来实现多平台间数据交互问题,同时结合 C/S 和 B/S 架构进行系统设计,整个
系统能够兼容多种读写设备和应用。杨峚[19]设计实现了一套使用 B/S 架构的仓
库管理系统,开发环境使用了 NetBeans 提高开发效率,架构上利用了 JSP 技术,
采用 J2EE 体系中的 java WEB 三层架构减少系统的耦合度并提高可扩展性和易
维护性,数据库方面采用 SQL Server,提高系统数据并发能力和计算能力。郭
剑英[20]设计了一套基于 RFID 的仓库管理系统,采用 B/S 的模式简化部署过程,
同时利用 ASP.NET 的可视化平台,对系统进行高效的开发。翁祖蓉[21]在其仓
库管理系统设计中,采用了 MVC 设计模型,将系统中业务逻辑和前台视图分
离,使系统逻辑变得清晰且容易维护。Luo Cheng[22]在其仓库管理系统设计中
利用 AOP 技术,它使得系统的代码高度模块化和结构化,只关注本地内容而忽
略各模块之间的信息传输,重构了业务系统,简化了系统结构。Liu Pin[23]等针
对现代企业的产品信息管理,采用 J2EE 体系、基于 B/S 模式实现了一种仓库
管理系统,系统集成开源的 SSH 框架进行设计实现,显著提高了系统的安全性
和可靠性。裘森林[24]采用 B/S 架构、云计算结合的方式设计了一个具有三层架
构的分布式仓库管理系统,其利用虚拟化技术将企业的各种软硬件虚拟化,并
将系统部署在云平台,以提高用户接入的并发性和吞吐量,显著提高系统的安
全控制能力。
1.2.2 RFID 中间件研究现状
RFID 技术的发展也带来了很多国外知名厂商的 RFID 中间件产品,包括
BEA 公司的 WebLogicRFID 产品、IBM 公司的 WebSphere RFID Primises
- 5 -
哈尔滨工业大学工程硕士学位论文
Server、Oracle 公司的 Sensor Edge Server、微软公司的 BizTalk RFID 等等[25]。
但在国内,专门研发中间件产品的企业非常少,RFID 中间件的发展还属于实
验室阶段,相比于国外还有明显差距。国内的 RFID 中间件在公共服务方面也
开展了一些工作,包含有中科院自动化所研发的基于公共服务体系架构的可追
溯管理中间件、华中科技大学研发的多通信 RFID 中间件产品 Smarti、上海交
通大学研发的面向商业物流数据管理集成的中间件平台,此外,还包括东方励
格的 LYNKO-AlE 中间件、清华同方的 ezRFID 中间件等等[26]。
各类中间件产品的出现同样也带动了各界人员对于 RFID 中间件的研究。
沈玮玮[27]针对 RFID 中间件在处理数据漏读和冗余读的数据过滤清洗算法进行
了研究,提出一种新的冗余消除算法和滑动窗口清洗算法,显著降低了数据采
集的错误率。张翔[28]着手于 RFID 中间件的安全问题,提出了漏洞检测和入侵
检测两种安全技术模型,并设计出一种归并算法,可以增加检测效率和预测未
知攻击的能力。周悦[29]设计并实现了一个基于 LLRP 协议、符合 ALE 标准的
RFID 中间件系统,并提供了数据收集和过滤的功能,同时具有一定的扩展性。
林凤群[30]研究了一种轻量型的 RFID 中间件,它实现了 ALE 规范规定的基本功
能,并具有系统结构简单、技术要求不高、易于实现和使用、可扩展性强等优
点。贾红梅[31]着重对 RFID 中间件的数据过滤部分进行了深入研究,创新性地
设计了数据初步过滤、标签重复过滤、属性过滤、阅读器重复过滤和行为过滤
数据等过滤方法,提高了数据处理的效率。应俊[32]等基于 ALE 规范设计了一
个通用的分布式 RFID 中间件架构,可以运用于物流管理、汽车管理、资金管
理等多个应用场合,验证了中间件的可靠性和高效性。Tian Wenhong[33]等基于
云计算的虚拟化特征,提出了一种先进的云计算 RFID 中间件系统,通过采用
分布式的结构体系、负载均衡的策略保证了系统的稳定性和高性能。Liu Fagui[34]
等设计并实现了一种基于 ALE 的轻量级嵌入式 RFID 中间件,提供了统一的接
口、事件处理等机制,提高了中间件的可重构性、可扩展性和可移植性。
1.2.3 决策平台研究现状
随着大数据、云计算、虚拟化、物联网等新兴技术的发展,越来越多的物
流企业致力于构建一种服务型以及物流任务型的物流模式,其不仅可以保障物
流任务的高效执行,而且还能满足企业的各种专业化、个性化的需求。而云物
流就这样诞生了,云物流是云计算在物流业的应用,其利用云计算的强大通信、
- 6 -
哈尔滨工业大学工程硕士学位论文
运算、匹配能力,集成众多物流用户的需求形成服务平台。云物流的模式下,
企业可以实现物流资源的高效整合和物流成本的显著降低,这将大大提高物流
业的社会效益。而决策平台可以说是定制版的 SaaS 服务模式的云服务平台,专
门向用户提供仓库管理任务的计算调度服务。
目前国内外有关于云物流的研究虽然处于起步阶段,但云物流模式下的各
种决策系统的研究也不少,其大多数都是对具体的物流问题进行模型构建和求
解。王羽欣[35]基于云物流模式,构建了“初分配-再分配”两阶段任务分配模型
以及合作配送模型,并通过演化算法验证了其合理性。毕娅[36]等对云物流模式
下的基于最大覆盖配送中心选址分配问题进行了研究,提出了多目标非线性的
决策模型,并设计了基于遗传和粒子群的组合式启发式算法,验证了决策模型
的有效性和稳定性。姜春艳[37]等探究了 SaaS 模式下云平台的技术架构,并对
物流各环节的功能进行整合,提供了一定的参考价值。万千惠[38]探究了云服务
模式的物流资源调度流程,构建了基于云服务平台的物流任务调度模型和物流
合作配送模型,并结合遗传算法进行求解,验证了模型的可行性和有效性。陈
昌豪[39]提出了一种基于计算机网络技术的智能物流决策系统,将数据通过其设
计的匹配模块和优化模块,计算出最佳匹配和路径,实现物流高效智能决策。
1.3 本文主要工作
本文以仓储管理系统为研究对象,通过对 RFID 技术原理以及分布式技术
概念的介绍和相关知识的学习,将整个系统给划分为主要的三个子系统,包括
仓库管理子系统、RFID 中间件子系统、决策平台子系统,分析了各个子系统
的侧重点和功能需求,进行了系统的模块化架构设计,对仓库管理子系统以及
决策平台子系统的业务流程进行了优化设计,定义了相关的接口和规范,针对
各个子系统的功能进行了实现和测试,并利用分布式架构替代传统集中式的部
署方式,显著提高了系统的整体性能,同时提出了利用 Docker 容器化技术与
Kubernets 编排技术实现系统的容器化部署及容器的自动化管理,使得系统的稳
定性和扩展性有了进一步的提升。
本项目提出的基于 RFID 的分布式物流仓储管理系统,弥补了现有仓储管
理系统难以支持分布式智能计算的不足,形成了一套集仓储数据收集、管理、
分析与决策于一体的底层支撑平台,有效地拓展了现有仓储管理系统的功能边
界。
- 7 -
哈尔滨工业大学工程硕士学位论文
1.4 本文章节安排
本文结构安排如下:
第一章,主要阐述论文背景,对国内外的仓库管理系统、RFID 中间件以
及决策平台进行综述,并安排了论文的内容和结构。
第二章,相关技术概述。介绍仓库管理、RFID 技术、分布式技术等理论
知识,为整个系统设计与实现提供理论依据。
第三章,系统总体架构设计及需求分析。针对整个系统进行分布式架构设
计以及功能需求分析,对包括仓库管理系统、RFID 中间件、决策平台的三个
子系统进行角色定位。
第四章,仓库管理系统的设计。针对该子系统进行架构设计、流程设计以
及模块设计,同时明确数据库的设计。
第五章,RFID 中间件的设计。基于 RFID 技术标准,对该子系统进行架构
设计、模块设计以及接口设计,并给出数据库模型的设计方案。
第六章,决策平台的设计。针对该子系统的架构模式、业务流程、节点功
能以及消息格式,给出明确的设计方案。
第七章,系统的实现。参照上述设计,完成三个子系统关键功能的实现,
并进行部分实现展示和主要功能测试。
- 8 -
哈尔滨工业大学工程硕士学位论文
第 2 章 相关技术及理论概述
2.1 仓储管理概述
所谓仓储就是货物物资在转移过程中由于某些原因而产生停滞所发生的存
储状态,而仓储管理,主要是指对仓库以及仓库中因为停滞而存储的货物进行
管理,包括入库出库管理、货物信息管理等诸多方面。随着社会的发展,现代
仓储不仅仅起到物资保管的作用,更是起到物流运转中心的作用,而基于现代
化的信息技术、自动化技术的仓库管理系统的出现更是提高了仓储运作效率。
高效的仓储管理能够有效降低储存成本,提高作业执行速度,是企业高效管理、
保持竞争力的关键所在。
目前仓库管理的模式很多种,包括自建仓库管理模式、租赁仓库管理模式、
第三方仓库管理模式。自建仓库管理模式即企业自行建设仓库,仓库归企业自
有,如此企业可以按照自己的想法对仓库进行更大程度的管理,使得仓库管理
更灵活更合理,一定程度降低仓储成本;租赁仓库管理模式即企业租赁营业性
的仓库进行仓储,这种模式能够减低企业资金投入,减少自我管理的难度,降
低仓储成本;第三方仓库管理模式指的是企业将仓储管理活动丢给外包公司,
由成熟的第三方企业提供综合的存储和物流服务,极大减少了企业的仓储投入,
方便企业将自己的重心方向转移到具有竞争力的部分。
2.2 RFID 技术概述
2.2.1 RFID 系统基本组成
射频识别技术(Radio Frequency Identification,RFID)是一种无接触式的
自动识别技术,它能够借助无线电波,在不需要人工干预的情况下将信息从一
个载体传输到另外一个载体上,具有识别速度快、传输效率高的优点。而 RFID
系统经过这么多时间的发展和完善,逐渐形成了一套稳定的结构,基本的 RFID
系统如图 2-1 所示,按照工作原理主要包括阅读器、天线和电子标签。
电子标签是由微型天线、耦合元件以及内部芯片组合而成,在 RFID 系统
中是作为信息载体的存在,每个标签都具有唯一的编码,以此作为识别的依据。
此外,根据信号发送方式的不同,电子标签分为主动和被动两种形式:主动标
签内部包含微型电池,能够在阅读器靠近时,主动发送电子编码信号;而被动
- 9 -
哈尔滨工业大学工程硕士学位论文
标签通过线圈感应阅读器的射频信号,获得感应电流,从而被动向阅读器发送
编码信号。
应用系统
阅读器 天线 电子标签
图 2-1 RFID 系统原理图
阅读器作为 RFID 的终端设备,主要功能就是和电子标签进行数据交互,
起到信息控制和处理的作用,并且能够从电子标签里读取信息及写入更新过的
信息到电子标签中。从形式上来说,阅读器分为手持式阅读器和固定式阅读器
两种,手持式阅读器主要用于货物的更新和统计,固定式阅读器主要用于跟踪
物资的移动。
天线的主要是用于接收和传递阅读器与电子标签之间的射频信号,是阅读
器和标签之间进行数据传输的发射、接收装置。
就宏观而言,应用主机系统也是整个 RFID 系统很重要的一环,其包括中
间件系统、数据库系统等,主要负责对阅读器传来的数据进行存储和处理,同
时可以控制阅读器对标签进行的读取和写入操作,并在此基础上提供一些数据
计算服务。
2.2.2 RFID 系统工作原理
RFID 系统的基本工作原理:RFID 阅读器通过发射天线持续发送特定的射
频信号,对于被动标签来说,当其进入该射频范围时将产生感应电流,被动标
签利用该能量将自身编码等信息发回给阅读器;对于主动标签来说,只要进入
阅读器的射频范围,接收到特定的射频信号,就会主动的将本地存储的数据信
息发送给阅读器。阅读器的天线接收到电子标签的载波信号后,经过天线调制
器传输给阅读器,阅读器再进行解调和解码生成有效信息,并可以传给后台系
统的逻辑控制单元进行相应的数据处理。主系统接收到有效信息后,对该电子
标签进行逻辑运算验证其身份合法性,并做出不同的处理控制指令信号,以完
成阅读器的读写操作。
整个工作流程依靠阅读器和电子标签之间射频信号的空间耦合作用以实现
数据和能量的交互式通信,主要包括电感耦合和电磁反向散射耦合。
- 10 -
哈尔滨工业大学工程硕士学位论文
2.3 分布式技术概述
2.3.1 Docker 容器技术
自二十一世纪以来,云计算、云服务这类概念开始火爆,虚拟化技术开始
得到飞速发展。所谓虚拟化技术,简单地说就是将一台物理主机虚拟为多台逻
辑主机,每个逻辑主机有自己的一套操作系统,各个逻辑主机之间应用程序相
互独立的运行,就仿佛真的存在多台物理机一般。但与真正的多台物理机不同
的是,虚拟化技术起到了硬件资源的动态分配、实时调度、跨域共享的作用,
通过充分利用硬件资源,使其发挥最大功效,从而显著提高计算机系统整体的
运行效率。
容器技术是一种高效的轻量级虚拟化技术,其采用一种以应用程序为中心
的虚拟化手段,将应用程序所需的环境打包成独立环境,并运行在主机的操作
系统之上,各个独立环境之间的运行互不干扰,独立环境和宿主机 OS 之间相
互隔离、互不影响。容器技术采用共享主机的操作系统的做法,以进程为单位
的虚拟化,其启动和运行性能远超其他虚拟化实现。在这方面最具代表性的就
是 2013 年由 dotCloud 公司开源的 Docker 容器引擎了,其允许用户将应用程序
和依赖包打包并发布到各种操作系统上,而屏蔽掉不同主机环境的影响,具有
非常好的隔离性。Docker 容器及虚拟机的分层架构图[40]如图 2-2 所示,相比于
传统的基于 Hypervisor 的虚拟机技术,Docker 容器技术采用沙箱机制,并以应
用服务为核心,不用在宿主机上再虚拟一套用于虚拟机的操作系统,从而极大
的减少了运行开销,这对于系统的快速部署和规模调整起到非常大的作用[41]。
a) Docker 容器分层架构 b) 虚拟机分层架构
图 2-2 Docker 容器及虚拟机的架构图[40]
- 11 -
哈尔滨工业大学工程硕士学位论文
Docker 采用 C/S 架构进行构建,其核心模块架构图如图 2-3 所示,Docker
client 和 Docker daemon 通过 RESTful 或者 socket 进行通信,daemon 起到后端
管理容器的作用,包括构建、运行、发布等功能,client 作为面向用户的接口,
接收用户传来的命令,并传递给 daemon 执行。此外,Docker 还包括容器、镜
像、注册中心的概念:容器(Containers)即 Docker 运行实例,是应用程序运
行的独立环境,可以被建立、启动、销毁,各个容器之间相互隔离,又有特定
的共享机制,可以把它当作是一个小型的操作系统;镜像(Images)可以认为
是 Docker 容器的模板,里面已经打包好程序运行所需的环境,使用时只需按照
镜像构建容器就能进行使用,不用再做重复性的工作;而注册中心(Registry)
可以理解为镜像仓库,包括公有仓库和私有仓库,用户可以上传和下载自己需
要的镜像,很方便地构建程序运行环境。
图 2-3 Docker 核心模块架构图
2.3.2 Kubernetes 容器编排技术
容器化的方式能够极大提高系统可移植性、降低部署难度,用户可以通过
CLI 对单个主机上的容器进行手动管理。但随着系统复杂度的提升,容器规模
开始增加,容器很可能部署在多个物理主机之上,各个容器的状态管理也不可
能完全交由用户手动管理。为了解决这个问题,实现大规模跨域的容器管理,
基于容器编排技术的管理工具得以出现。容器编排工具以容器为单位实现资源
管理、容器调度以及服务管理,确保资源分配的正确合理性,同时提供了集群
管理以及数据维护等功能,能够快速地进行容器集群的构建和销毁,极大的减
少了运维人员的工作量。
- 12 -
哈尔滨工业大学工程硕士学位论文
Kubernetes 是由 Google 公司在 2014 年开源的一款优秀的容器编排工具,
由 Borg 演变而来,采用 go 语言实现。在 Kubernetes 的视角里,它将底层多个
物理主机的资源抽象出来,组织成一个资源平台实现资源的统一调配管理,而
用户无需关注底层硬件资源如何分配。Kubernetes 可以实现容器的自动化部署、
弹性扩容、服务发现等功能,并向外提供 RESTful API 接口,供第三方应用进
行访问。此外,Kubernetes 提供集群管理的功能,通过内置的负载均衡策略,
自动实现容器的管理和负载访问;同时具有自我扩展和修复的功能,Kubernetes
持续监控各个服务实例的状态,一旦服务副本状态异常或者服务数量不够,系
统能够自动重启或在其他节点进行重建该服务,整个过程无需人工干预,极大
提高了系统运行效率。
Kubernetes 采用主从架构,其架构图[42]如图 2-4 所示,主要分为主节点
Master 和从节点 Node。Master 节点负责节点管理、资源调度和状态监控等管理
任务,同时对外提供集群资源管理和访问的接口;Node 节点负责各个应用服务
的执行。Master 节点同一时间只能有一个处于有效状态,其他处于备用状态;
Node 节点一般有多个作为集群使用。
图 2-4 Kubernetes 架构图[42]
Master 作为主节点,有四大核心组件,分别是 API Server、Scheduler、
Controllers 以及 etcd:API Server 作为 Kubernetes 集群唯一对外暴露的接口,
负责接收及过滤所有的请求,并将其存入数据库 etcd 中;Scheduler 作为资源调
度中心,会监听 API Server 的请求命令,当得到命令需求后,会利用特定的调
度策略选用最佳的 Node 来执行该命令,并将该结果保持到 etcd 中;Controllers
作为控制管理器,负责维护以及管理各个节点容器的状态及数量,一旦某个节
- 13 -
哈尔滨工业大学工程硕士学位论文
点里容器的状态和数量与 etcd 里预期的不相符,Controllers 会不断进行容器的
重建,直到运行结果与预期相符;etcd 是一个基于键值对格式的数据库,负责
保存其余三个组件产生的配置及状态等重要信息并进行持久化。
Node 作为工作节点,包含 Kubelet、Kube-proxy、Contain runtime 三大组件:
Kubelet 作为代理管理者,主要负责当前节点资源与容器的监控和管理,确保工
作节点的正常运行,并将结果返回给 API Server,同 时 Kubelet 也会去监听 API
Server,以获取执行任务;Kube-proxy 主要用来维护服务网络,创建网络代理
服务,并提供集群内部的服务转发以及高可用的负载均衡方案;Contain runtime
其主要负责下载镜像以及运行容器,这里可以选用 Kubernetes 支持 Docker、
containerd、rkt 等容器引擎,或者实现了 CRI 接口的任何容器。Pod 是 Kubernetes
集群中的最小部署单元,每个 Pod 都有着独立的 IP 地址,而同一个 Pod 中可
以拥有多个容器,各个容器既共享网络又共享存储卷。
2.4 本章小结
本章主要对本系统在研究过程中所涉及到的相关技术做了一个简要的概
述。首先对仓库管理的定义做了一个解释,作为后续仓库管理系统需求分析的
基础;然后介绍了 RFID 技术,包括 RFID 系统组成以及工作原理,并以此作
为基础对后续的仓库管理系统的业务流程以及 RFID 中间件数据采集功能进行
设计;最后介绍了以 Docker 为例的容器技术以及以 Kubernetes 为例的容器编
排技术,并详细的分析了 Kubernetes 架构以及各个组件的功能,后续的仓库管
理系统、RFID 中间件以及决策平台都需要基于这些技术进行架构设计和功能
拆分,以实现系统的分布式部署以及容器的自动化管理。
- 14 -
哈尔滨工业大学工程硕士学位论文
第 3 章 物流仓储管理系统的需求分析及架构设计
本章主要是对本文提出的物流仓储管理系统进行总体的需求分析和架构设
计,从用户角度剖析系统所能提供的主要功能,并理清物流仓储管理系统与各
子系统之间的逻辑以及架构关系,明确各个子系统的功能定位,同时还需要针
对每个子系统单独进行需求分析,以获取后续子系统的设计依据。
3.1 系统总体需求分析及架构设计
3.1.1 系统总体需求分析
传统的仓储管理系统具有识别速度慢、决策能力弱、系统冗余难扩展等诸
多问题,为了克服这些问题,我们提出一种全新的基于 RFID 技术实现的分布
式物流仓储管理系统。
本系统应在仓管流程、数据采集、决策计算等诸多方面进行优化,并向外
提供 SaaS 化的云服务。企业和用户在使用系统时,无需亲自进行系统的部署和
管理,仅仅只用下载客户端或者登录网页即可方便的进行入库、出库、盘点等
仓库管理操作。用户使用配置页面对阅读器进行相关配置后,就可以通过相应
的界面进行高效的数据采集、过滤、上传等数据管理操作。此外,该系统通过
集成决策平台,提高系统的决策能力,使物流决策可以更快更准确的进行,用
户同样可以访问决策系统提供的可视化界面,对决策计算过程进行管理和控制。
3.1.2 系统总体架构设计
系统总体分为三大子系统,包括仓库管理系统(Warehouse Management
System,WMS)、RFID 中间件系统(RFID Middleware,RM)、决策平台系统
(Decision Platform,DP)。仓库管理系统作为该系统的最核心的部分,主要负
责仓库货物数据的管理;RFID 中间件系统主要负责对终端传入的标签数据进
行采集和清洗;决策平台系统主要负责处理系统中的计算问题,包括货物最优
调度、最佳路径规划等实际问题。
基于 RFID 的分布式物流仓储管理系统总体架构图如图 3-1 所示,管理人
员可以操作手持阅读器,手动地读取电子标签的信息,或者使用固定式的阅读
器自动地读取标签数据信息,并将信息上传给 RFID 中间件;RFID 中间件将依
- 15 -
哈尔滨工业大学工程硕士学位论文
据用户预先设置的配置信息,对数据进行合法验证以及过滤清洗等操作处理,
随后将清洗后的数据上传至仓库管理系统的数据库中;当用户调用接口访问仓
库管理系统并请求调度任务时,仓库管理系统会将任务发送至决策平台系统;
决策平台系统接收到任务后,通过分布式的并行计算,迅速得到最佳调度方案,
并将调度结果返回给仓库管理系统,处理后进一步返回给客户端,实现快速高
效的仓库调度。
基于RFID的分布式物流仓储管理系统
仓库管理子系统 决策平台子系统
(WMS) (DP)
RFID中间件子系统
(RM)
数据过滤 数据采集 数据上传
图 3-1 系统总体架构图
整个系统的分层架构图如图 3-2 所示,主要包括基础设施层、应用服务层、
接口访问层以及终端展示层。
(1)基础设施层,主要提供保证系统正常运作的硬件资源,包括数据库资
源、计算资源、网络资源等,该层的实现可以自己构建也可以采用成熟的云服
务。
(2)应用服务层,使用 Docker 技术以及 Kubernetes 技术实现服务的容器
化和服务管理。该层利用容器化的思想屏蔽底层细节,使得各个服务的设计实
现更聚焦于服务本身的业务逻辑,同时该层提供服务通信、服务治理等功能,
方便系统的部署及管理。
(3)接口访问层,包含各个服务的入口逻辑,各个服务之间可以通过包括
HTTP、Socket、WebService 等方式进行服务访问。此外,用户可以通过 API
网关快速定位和访问相应的服务。
- 16 -
哈尔滨工业大学工程硕士学位论文
(4)终端展示层,主要为不同终端设备提供不同的展示界面,以供用户对
系统进行操作管理。现有终端包括浏览器、客户端等。
终端展示层
浏览器 客户端 其他终端
API网关 接口访问层
SOCKET HTTP WebService
Docker容器化+Kubernetes集群管理
服务 WMS RM DP
通信 管 标
应用服务层 服务
治理
... 理 准
基础设施层 数据库资源 CPU资源 网络资源
图 3-2 系统分层架构图
3.2 仓库管理系统需求分析
本仓库管理系统基于 RFID 技术实现,需要提供仓库的入库管理、出库管
理、库存盘点三个基本仓库调度功能,以及系统权限、基本信息、出入库信息
等管理功能。
用户使用该系统能够实现对库存信息、出入库记录、用户信息等的实时且
智能的管理,而且不同种类用户应分配不同的角色、不同的角色应具有不同的
的管理权限,如仓库管理员拥有除了系统权限之外的所有权限、而采购员只有
入库管理的权限等,以便明确仓库管理系统用户之间的分工。当进行入库或者
出库操作时,用户录入或者系统自动生成入库或出库记录,并在出入库动作完
成时,及时参照记录实现仓库数据库的更新;当进行库存盘点操作时,系统应
及时比较盘点结果与库存差异,并由用户决定是否更新数据库。此外,系统应
当提供系统权限以及基本信息等相关信息的删除、修改、查询操作,便于实现
- 17 -
哈尔滨工业大学工程硕士学位论文
用户对仓库信息的实时监控和管理;最后,需要系统提供一个可供后台管理人
员使用的可视化界面,界面绑定上述提到的所有功能。
3.3 RFID 中间件需求分析
本中间件系统基于 RFID 技术实现,应按照 EPCglobal ALE 规范[43]进行设
计。该系统用于与终端阅读器进行交互,并将其传来地标签数据进行清洗,可
以提供数据收集和上传、数据过滤、数据统计查询、阅读器管理等基本功能。
用户通过可视化的配置界面,设置中间件系统的数据处理参数(比如实体
阅读器连接地址以及接口类型、过滤时间窗口大小、结果报告样式等),以实现
对数据收集、处理、上传整个流程的控制,同时用户也可通过独立的可视化界
面进行数据和阅读器的维护和管理。此外,对于固定式以及手持式两种不同类
型的阅读器,标签数据应采用不同的上传方式:固定式阅读器可以通过低级阅
读器协议持续自动地将标签数据上传至中间件系统;而手持式阅读器包含操作
系统,用户可以手动控制数据的上传,同时终端可以提供一部分数据处理的能
力。
3.4 决策平台需求分析
本决策平台采用分布式并行计算的思想进行设计,目的在于处理大规模数
据,并提高决策系统的计算性能。本系统主要用于对仓库管理系统分配的各种
计算任务进行调度以及高速运算,以快速获取最优结果。
决策平台应实现一个计算展示界面,并提供任务控制、决策监控等功能。
用户通过该可视化的界面,可以手动的进行决策参数的初始化、计算任务的启
动和终止、决策结果查询等操作。同时决策任务计算的中间结果也会展示在界
面上,包括计算时间、进度、当前结果等等信息,方便用户实时地对计算状态
进行管理和控制。实际中,用户应通过仓库管理系统将不同的决策任务分配给
该决策平台,由决策平台负责对任务进行资源调度以及并行计算,在计算结束
后将各个并行的计算结果进行汇总,以获得最优结果并返回给用户。本决策平
台不用关注决策问题本身,而仅仅作为一个任务调度以及资源分配的中心,从
宏观上把握整体计算进程。
- 18 -
哈尔滨工业大学工程硕士学位论文
3.5 本章小结
本章主要对本文提出的物流仓储管理系统进行了整体的需求分析和架构设
计,明确了系统结构和层级关系,将系统按功能划分为三大子系统,并理清了
各个子系统之间的逻辑关系,同时分别对各个子系统进行了基本的需求分析。
对于仓库管理系统来说,我们需要实现登录验证,而且针对不同的登录用户,
我们需要给予不同的访问权限,对于此我们可以通过设计一个权限表,并与用
户表进行绑定,实现权限的分配绑定。不同的用户在系统中可能有消息的交互,
比如采购员通知仓库管理员进行入库的审核,这一问题可以通过共享信息并赋
予状态标记进行解决。对于 RFID 中间件来说,针对不同的阅读器我们应该采
用不同的接口,通过适配器模式能够很好的解决这一问题。在中间件设计上,
我们也可以参照已有的成熟的标准规范,简化功能设计。对于决策平台来说,
我们可以采用并行计算框架以提升平台的计算性能,同时为了确保能够获得实
时更新的计算结果,可以采用 ajax 局部刷新技术进行解决,通过统一消息格式,
实现平台数据的内部传输。此外,我们采用持续轮询的方式,保证在有任务未
分配的前提下,只要有节点空闲,就会立即进行任务的分配。
- 19 -
哈尔滨工业大学工程硕士学位论文
第 4 章 仓库管理系统的设计
本章主要基于上述需求分析的结果而对仓库管理系统进行相关的设计工
作,主要包括架构设计、业务流程设计、模块设计以及数据库设计。架构设计
上采用分层架构,简化逻辑,提高系统稳定性;业务流程设计上基于 RFID 技
术应用来对仓库管理系统进行流程设计和优化;模块设计上描述了不同模块的
分工以及所包含的主要功能;数据库设计则定义了数据内容。
4.1 仓库管理系统架构设计
仓库管理系统采用 B/S 架构模式进行设计,用户可以通过 WEB 端直接对
仓库管理系统进行访问,无需考虑平台差异所带来的影响,简化系统开发。仓
库管理系统架构主要分为三层,其三层架构图如图 4-1 所示,包括应用服务层、
数据访问层以及数据存储层。其中应用服务层主要实现仓库管理过程中需要的
管理服务,同时提供用户访问接口,以供管理者进行调用;数据访问层提供各
种数据的访问接口,任何数据的增删改查操作均需要借助这一层进行实现;数
据存储层即数据库,主要实现数据的持久化存储功能。
图 4-1 仓库管理系统三层架构图
仓库管理系统开发平台采用 J2EE 平台,利用分布式微服务架构思想进行
设计,将系统各个功能模块分解到离散的各个服务当中,不同的服务与服务之
间通过 RPC 或 RESTful API 进行数据交互,从而降低系统的耦合性,并提供更
加灵活的服务支持。通过对单体应用的有效拆分,微服务架构能够实现敏捷开
发和部署,同时提高系统的易扩展性、高可用性、高容错性,支持快速演化和
迭代。对比传统的单体应用,微服务架构更注重各个服务独立的功能实现,极
大降低了程序之间的耦合度,同时简化了系统的维护和升级。
仓库管理系统微服务架构如图 4-2 所示。用户视图层根据用户指令,通过
- 20 -
哈尔滨工业大学工程硕士学位论文
API 网关调用相关的后台服务,与后台交换数据,然后渲染页面并向用户展示;
应用服务层主要提供仓库管理系统的一些关键服务,包括出入库服务、库存盘
点服务等,通过调用数据访问层的数据处理逻辑服务,结合一些切面功能,完
成当前服务的基本功能;数据访问层主要用来完善对数据库的一些增删改查相
关的一些基本逻辑服务。每种服务只关注当前服务的基本功能,扩展功能交给
下一个服务完成,并提供相关的 API 接口供其他服务进行调用。此外,数据库
也按照业务功能划分为不同的子功能数据库,每个子功能数据库只需要关注当
前子功能的数据管理,降低数据之间的耦合度,同时提高了并发度。为了提高
数据库命中率,可以按照需求添加缓存数据库,以提高数据访问性能。
服务注册中心 服务监控中心
应用服务层 数据访问层 数据存储层
库存信息接口
CACHE
库存盘点服务 客户端
出入库信息接口
CACHE
出库服务
API网关
入库服务
供应商信息接口
CACHE
CACHE
基本信息服务
客户信息接口
CACHE
系统管理服务
用户信息接口
图 4-2 仓库管理系统微服务架构图
通过使用 Springboot 整合 Mybatis、Shrio 等框架实现系统各个服务的功能
业务,同时结合 SpringCloud 分布式服务框架,结合 Kubernetes 自带的服务注
册发现功能,实现服务的注册发现、以及服务监控和治理等功能。分布式服务
治理框架如下,由暴露服务的服务提供者向特定的服务注册与发现中心进行服
务的注册,而需要调用服务的服务消费者向该注册中心订阅相关服务,并由注
册中心通知消费者已注册服务所在的 IP 和端口。当消费者被告知服务已被注册
时,就可以通过相应的 IP 和端口,通过 RPC 或 RESTful 的方式,对目标服务
进行调用,整个过程对用户透明,用户基本感受不到远程调用的存在。此外,
可以使用微服务监控中心,对服务提供者和消费者的数量和状态进行监控,包
括配置信息、熔断监控、日志信息、HTTP 跟踪等信息均可以实现设置和监控。
- 21 -
哈尔滨工业大学工程硕士学位论文
4.2 仓库管理系统业务流程设计
4.2.1 入库流程
基于 RFID 技术的仓储管理系统的入库管理流程图如图 4-3 所示,流程步
骤如下:
入库开始
 采购员向
供应商发出
 采购通知
返回供应商
要求重发货 供应商供货
 并生成
供货清单
仓管员接收
 供货清单
并对入库货
物进行校验
拒绝收货 N 货物是否与
供货单匹配?
Y
仓管员制作
 电子标签
 并审核
生成入库单
 操作员按
入库单进行
 入库任务
入库结束
更新仓库
数据库信息
入库结束
图 4-3 入库流程图
- 22 -
哈尔滨工业大学工程硕士学位论文
(1)首先采购员确定采购任务,填写采购物资的信息,并向供应商发出采
购通知。
(2)供应商确认采购任务后,生成供货清单,并向仓库供货。
(3)仓库管理员接收到货物之后,按照供货清单的信息对入库的货物进行
清点校验和审核。
(4)如果货物与供货单显示的信息匹配,则开始入库;否则,拒绝收货,
同时要求供应商重新发货。
(5)确认入库信息完备且通过库存容量审核,仓库管理员则开始使用手持
阅读器制作临时 RFID 电子标签,并将电子标签附于该货物包装之外。同时系
统结合当前库存状况,计算出最佳入库策略,包括入库位置、入库路径等信息,
并按照供货清单生成详细的入库单。
(6)操作员按照入库单的信息,将对应货物送达指定库存位置,同时修改
对应库位的固定 RFID 电子标签,最后确认入库完毕。
(7)仓库管理员收到操作员入库完毕指令,即开始按照入库单更新数据库
信息。
4.2.2 出库流程
基于 RFID 技术的仓储管理系统的出库管理流程如图 4-4 所示,步骤如下:
(1)首先销售员确认客户订单,填写销售货物的相关信息,并生成销售订
单。
(2)仓库管理员根据销售订单信息,通过库存容量审核后,结合当前库存
状况生成拣货单,拣货单包括拣货库位、拣货路径、货物数量等信息。
(3)操作员按照拣货单,使用手持阅读器进行货物分拣。
(4)如果对应货物以及数量与拣货单相匹配,则分拣完毕或者继续分拣下
一货物,同时修改库位固定的 RFID 电子标签;否则,重新分拣。
(5)仓库管理员按照拣货单对出库货物使用手持阅读器进行再次清点,如
果电子标签信息符合拣货单,则可以出库;否则,拒绝出库,并重新生成拣货
单。
(6)仓库管理员清除并回收出库货物临时 RFID 电子标签,并根据拣货单
生成对应的出库单。
(7)出库完毕,仓库管理员开始按照出库单更新数据库信息。
- 23 -
哈尔滨工业大学工程硕士学位论文
出库开始
客户生成
销售订单
重新生成
 拣货单 仓管员审核
并按照订单
生成拣货单
 操作员
接收拣货单
 准备分拣
拣选货物 N
是否与拣货
单匹配? 重新分拣
Y
仓管员按订单
对出库货物进
 行二次校验
N
货物是否
拒绝出库 与销售订单
 匹配?
Y
仓管员清理
 电子标签
生成出库单
出库结束
更新仓库
数据库信息
出库结束
图 4-4 出库流程图
4.2.3 盘点流程
基于 RFID 技术的仓储管理系统的货物库存盘点管理流程图如图 4-5 所示,
流程步骤如下:
- 24 -
哈尔滨工业大学工程硕士学位论文
(1)首先仓库管理员根据需求,生成盘点任务清单。
(2)操作员根据盘点任务清单,手持阅读器进行货物盘点,盘点记录包括
货物名称、库存位置、库存编号、货物数量等信息,并生成盘点清单。
(3)仓库管理员在后台查询库存状况,并结合对应的盘点清单,进行盘点
审查。
(4)根据实际需要,判断是否重新盘点。若需要重新盘点,则 操作员重新
进行盘点流程;否则,盘点完毕。
(5)系统根据盘点清单,生成盘点日志,同时更新仓库数据库 信息。盘点
流程结束。
盘点开始
仓管员生成
 盘点任务
操作员按照
盘点任务进
行货物盘点
盘点完毕生
成盘点清单
仓管员对比
盘点单差异
 进行审核
Y
重新盘点?
N
生成日志
更新仓库
数据库信息
盘点结束
图 4-5 盘点流程图
- 25 -
哈尔滨工业大学工程硕士学位论文
4.3 仓库管理系统模块设计
该仓库管理系统主要包括五大管理模块,包括系统管理模块、基本信息管
理模块、库存管理模块、入库管理模块和出库管理模块。本系统功能模块设计
图如图 4-6 所示。
仓 库 管 理 系 统
系统管理 基本信息管理 库存管理 入库管理 出库管理
图 4-6 系统功能模块图
4.3.1 系统管理模块
超级管理员是该模块的主要使用者,该模块一般只负责维护后台管理系统
的正常运作,不涉及仓库管理相关业务,主要是对用户信息的管理和用户权限
的管理。
用户管理主要针对系统登录用户的信息管理,包括操作本系统的用户姓名、
编号等信息的新增、删除、更新以及查询功能;角色管理即用户的工作职位,
本案例主要指的是采购员、操作员、超级管理员等;权限管理主要针对登录用
户的权限修改,为不同类的角色分配不同的权限,或者添加新的权限,比如仓
管员拥有除系统权限及用户管理之外的所有权限,而操作员仅有库存查询权限
和基本信息管理权限。此外,超级管理员拥有最高权限。
4.3.2 基本信息管理模块
仓库管理员和操作员为该模块主要使用者,该模块主要针对仓库、客户、
供应商等信息进行管理,主要提供了添加、删除、查询和修改相关基本信息。
其中仓库提供了仓库编号、地址、管理人员等信息,货物可以包括了货物
编号、货物类型、货物单位等信息,客户管理及供应商管理则提供了个体人的
编号、姓名、地址等信息。通过该模块,可以很高效的实现仓库管理的综合查
- 26 -
哈尔滨工业大学工程硕士学位论文
询,方便管理人员的操作和分析。同时在后台中该模块也提供相关操作接口供
其他上层模块的调用。
4.3.3 库存管理模块
库存管理模块作为仓库管理的基础,有着非常重要的地位。仓库管理员作
为该模块的主要使用者。该模块提供了包括库存盘点、库存查询、库存预警等
相关功能,任何对库存信息的查询更新,均需要调用这个模块的服务才能进行。
其中,库存盘点负责对库存进行盘点,修正实际库存与系统库存的差异,
统计损益数量,对库存统一有着非常重要的作用;库存查询针对各个仓库中各
个货物数量的展示,实现实时的统计功能,同时库存更新功能同样也在这个模
块中实现;库存预警则实时监控库存容量,当发现库存容量过多或过少,超过
某一阈值时,立即发起预警,提示仓库管理员进行相关补救措施。
4.3.4 入库管理模块
仓库管理员作为入库模块主要使用者,该模块主要针对仓库管理中的入库
管理部分,以实现货物的高效准确的入库操作,入库操作需要操作员的配合才
能完成。
入库管理模块中,入库单管理部分主要提供了入库单记录的查询和更新操
作,需要供应商信息和仓库信息的支持;入库作业部分则作为入库流程的主要
模块,由仓库管理员发起入库作业,生成入库单,以及操作员操作入库的完整
流程;异常入库即入库失败,归属于入库流程的审核部分,由仓库管理员来负
责,主要审核供货清单明细是否和实际货物相符,以及库存容量是否支持货物
入库等。
4.3.5 出库管理模块
与入库相反,出入模块作为仓库管理中出库管理部分,实现货物高效准确
的出库流程,同样需要操作员的配合。
出库管理模块中,出库单管理主要提供出库单的增删改查操作;出库作业
同样由仓库管理员发起,并由操作员实操,生成出库单,最后更新库存信息的
整套流程;而异常出库验证出库流程准确性,属于出库审核部分,主要针对出
货订单明细和实际出货是否相同,以及库存是否支持货物出库等。
- 27 -
哈尔滨工业大学工程硕士学位论文
4.4 数据库模型设计
结合功能模块的设计分析,本系统使用者主要包括仓库管理员、超级管理
员、采购员和销售员。其中仓库管理员拥有大部分仓库管理权限,包括入库管
理、出库管理、盘点管理、信息查询和修改等权限;而超级管理员主要负责系
统的管理,拥有对用户权限和系统信息进行管理的高级权限,但是不负责仓库
管理的细节;采购员和销售员主要是根据业务需求,生成相应的采购清单以及
销售清单给仓库管理员,同样不负责仓库管理的细节。
整个仓库管理系统的主要实体属性包括用户、角色、权限、仓库、货物、
供应商、客户、入库单、出库单、库存信息,其中入库单主要与货物、仓库、
供应商相关联,对应入库管理;出库单主要与货物、仓库、客户相关联,对应
出库管理;同时库存实体储存库存的相关信息,主要与仓库、货物相关联,对
应库存管理;货物、供应商、客户实体则对应基础信息管理;此外,用户、角
色、权限实体包含系统信息。本系统数据库不同实体间的关系 E-R 图如图 4-7
所示。
 客户姓名
货物类型
货物编号
 客户电话
 客户编号
货物名称
货物 出库单 客户
客户地址 货物数量
用户电话
库存
仓库容量
用户编号
入库单 仓库
 用户
仓库地址
 用户账号
供应商编号
仓库编号
权限级别
 用户密码
供应商 权限
供应商姓名
角色
供应商电话 供应商地址 权限编号
权限名称
图 4-7 仓库管理系统的数据库 E-R 图
根据展示的 E-R 图进行数据表属性的详细设计,该数据库主要包括八个数
据表,分别是客户表、供应商表、货物表、仓库表、库存表、入库单表、出库
单表、用户表、角色表、权限表,以下是全部表字段名属性的详细展示,表结
- 28 -
哈尔滨工业大学工程硕士学位论文
构的设计如下:
(1)客户信息表见表 4-1。
表 4-1 客户信息表
字段 标题 类型
customer_id 客户公司 ID Int(8) PK
customer_name 公司名称 Varchar(32)
customer_person 公司主体人 Varchar(32)
customer_tel 公司电话 Varchar(32)
customer_email 公司邮箱 Varchar(32)
customer_address 公司地址 Varchar(32)
(2)供应商信息表见表 4-2。
表 4-2 供应商信息表
字段 标题 类型
supplier_id 供应商公司 ID Int(8) PK
supplier_name 公司名称 Varchar(32)
supplier_person 公司主体人 Varchar(32)
supplier_tel 公司电话 Varchar(32)
supplier_email 公司邮箱 Varchar(32)
supplier_address 公司地址 Varchar(32)
(3)货物信息表见表 4-3。
表 4-3 货物信息表
字段 标题 类型
cargo_id 货物 ID Int(8) PK
cargo_name 货物名称 Varchar(32)
cargo_description 货物描述 Varchar(32)
cargo_type 货物类型 Varchar(32)
cargo_unit 计量单位 Varchar(32)
cargo_num_per_shelf 货架存放上限 Double
- 29 -
哈尔滨工业大学工程硕士学位论文
(4)仓库信息表见表 4-4。
表 4-4 仓库信息表
字段 标题 类型
repository_id 仓库 ID Int(8) PK
repository_name 仓库名称 Varchar(32)
repository_person 仓库负责人 Varchar(32)
repository_shelf_num 每区域货架数 Int(8)
repository_area_num 仓库区域数 Int(8)
repository_address 仓库地址 Varchar(32)
(5)库存信息表见表 4-5。
表 4-5 库存信息表
字段 标题 类型
storage_id 库存 ID Int(8) PK
storage_cargo_id 货物 ID Int(8)
storage_repository_id 仓库 ID Int(8)
storage_area 区域位置 Int(8)
storage_shelf 货架位置 Int(8)
storage_num 库存数量 Int(8)
(6)入库单信息表见表 4-6。
表 4-6 入库单信息表
字段 标题 类型
stock_in_id 入库单 ID Int(8) PK
stock_in_supplier_id 供应商 ID Int(8)
stock_in_repository_id 仓库 ID Int(8)
stock_in_cargo_id 货物 ID Int(8)
stock_in_num 入库数量 Double
stock_in_date 入库日期 Date
stock_in_user_id 负责人 ID Int(8)
stock_in_price_in 单位进价 Double
- 30 -
哈尔滨工业大学工程硕士学位论文
(7)出库单信息表见表 4-7。
表 4-7 出库单信息表
字段 标题 类型
stock_out_id 出库单 ID Int(8) PK
stock_out_customer_id 客户 ID Int(8)
stock_out_repository_id 仓库 ID Int(8)
stock_out_cargo_id 货物 ID Int(8)
stock_out_num 出库数量 Double
stock_out_date 出库日期 Date
stock_out_user_id 负责人 ID Int(8)
stock_out_price_out 单位售价 Double
(8)用户信息表见表 4-8。
表 4-8 用户信息表
字段 标题 类型
user_id 用户 ID Int(8) PK
user_name 用户姓名 Varchar(32)
user_username 用户账号 Varchar(32)
user_password 用户密码 Varchar(32)
user_tel 用户电话 Varchar(32)
user_email 用户邮箱 Varchar(32)
user_role_id 角色 ID Int(8)
(9)角色信息表见表 4-9。
表 4-9 角色信息表
字段 标题 类型
role_id 角色 ID Int(8) PK
role_name 角色名称 Varchar(32)
role_permission_id 权限 ID Int(8)
role_description 角色描述 Varchar(32)
- 31 -
哈尔滨工业大学工程硕士学位论文
(10)权限信息表见表 4-10。
表 4-10 权限信息表
字段 标题 类型
permission_id 权限 ID Int(8) PK
permisstion_level 权限级别 Varchar(32)
permisstion_name 权限名称 Varchar(32)
permisstion_description 权限描述 Varchar(32)
4.5 本章小结
本章主要对仓库管理系统部分进行了详细的设计。首先通过架构设计初步
确定系统的分层架构模型,明确系统入口以及各层的主要功能。为了满足用户
对仓库管理进行入库管理、出库管理、库存盘点的功能需求,我们通过对入库
流程、出库流程、盘点流程进行详细的分析和优化设计,明确了基于 RFID 的
仓库管理流程步骤的先后顺序。为了确保不同种类的用户具有不同的数据操作
权限,我们基于业务流程设计的结果,对系统进行模块的分割和功能的设计,
确立了各个模块的权限等级,通过数据库的结构设计,可以实现用户对仓库各
类信息的增删改查操作。本章的设计基本可以满足系统的功能需求,通过画出
业务流程图,我们能够直观的展示系统业务流程的先后顺序,并基于此快速地
分析模块的功能以及明确用户的权限。
- 32 -
哈尔滨工业大学工程硕士学位论文
第 5 章 RFID 中间件的设计
本章主要以第三章节的需求分析作为设计依据,描述 RFID 中间件子系统
的相关设计工作,并给出基本的设计方案,主要包含架构设计、模块设计、接
口设计以及数据库的设计。在架构上,把中间件分为数据处理与数据访问两大
服务模块,以明确模块的功能侧重以及模块之间的逻辑关系;在模块功能上,
基于 ALE 标准对中间件模块的主要功能进行描述和分析,完善基本功能逻辑;
在接口设计上,列举出相关接口的功能和作用,并给出部分实现方式;数据库
设计则简单的定义了中间件的数据存储格式。
5.1 RFID 中间件架构设计
RFID 中间件基于 EPCglobal ALE 规范标准,并采用面向服务的架构进行设
计。系统借助轻量级的远程调用技术向外发布服务,同时暴露服务地址和列表,
客户端生成用于本地代理代码,以实现本地调用,提高了系统的跨平台通信能
力,同时也降低了程序的耦合性以及程序集成部署的难度。中间件整体架构图
如图 5-1 所示,主要包括数据处理服务模块与数据访问服务模块两个核心模块。
RFID中间件系统
数据处理服务模块 数据访问服务模块
配置管理
配置管理
数据过滤
数据转换
 
 
 
数据上传
阅读器管理
配置接口 数据存储
统计查询
可视化 访
可视化配置页面 数据库
图 5-1 RFID 中间件架构图
(1)数据处理服务模块。主要负责对从阅读器传来的标签数据进行收集、
处理以及上传操作。该服务提供阅读器接口以及配置接口:其中阅读器接口采
- 33 -
哈尔滨工业大学工程硕士学位论文
用适配器模式设计,用于适配不用种类的阅读器的连接以及数据传输;配置接
口使用 RPC、WebService 等技术发布接口服务,暴露中间件系统的配置入口,
便于用户进行远程控制操作。
(2)数据访问服务模块。主要负责将数据处理服务上传的数据进行存储以
及对数据库的访问,包括增删改查操作。该服务同样利用相关技术向外发布数
据库访问服务,提供 CRUD 调用接口,以供用户或者第三方企业应用系统进行
调用。此外,该层服务还包含一个可视化界面,便于用户进行数据的管理操作。
5.2 RFID 中间件模块设计
RFID 中间件基于应用层事件规范(Application Level Event,ALE)进行设
计。ALE 是由 EPCglobal 发布的一种专门用于 RFID 中间件的规范标准,其定
义了中间件的基本接口框架,标准化有效的业务逻辑,减少原始数据的冗余。
ALE 规范主要包含三个基本概念,读周期(Reader)、事件周期(Event Cycle)
以及事件报告(Report)。读周期用来表示中间件系统与阅读器交互的单位时间,
阅读器在单位时间内进行数据的上传;事件周期则包含了一到多个的读周期,
用于将这多个读周期上传的数据进行相应的业务逻辑处理;事件报告是每个事
件周期逻辑业务处理之后返回给用户的结果报告。
ALE 模式的中间件交互图如图 5-2 所示,其中 Reader 负责与实体阅读器建
立连接以及接收数据,而 Event Cycle 负责接收和控制 Reader 组件传来的数据
并实现数据过滤等相关处理,同时生成 Report 报告,将数据处理结果上传至其
他模块或应用。用户需要按照 ALE 规范将相应的配置信息写入 XML 文件(ALE
规范中的 XML 文件包括 ECSpec 和 LRSpec)中来对中间件的 Event Cycle 和
Reader 组件进行配置(包括读取时间周期、事件触发条件、阅读器连接等等配
置),同时应将 Report 的返回地址也予以配置,以便其他模块或者第三方系统
能够接收并解析该消息。此外,Event Cycle 生成 Report 并发布给接收端时,用
户有两 种接收 消息 的模式 ,包括 订 阅 模 式( Subscription ) 以及轮 询模 式
(Poll/Immediate)。其中订阅模式由订阅者对该事件周期进行消息订阅,一旦
有新 Report 生成时,中间件自动将其发送给订阅了该事件的订阅者;而在轮询
模式中,每当有新的 Report 生成时,中间件不会自动返回消息报告,需要等有
客户端进行消息请求时,才将保存好的 Report 返回给请求的客户端,以达到单
次即时获取报告结果的目的。
- 34 -
哈尔滨工业大学工程硕士学位论文
ALE模式中间件
阅读器
EventCycle Reader
其他模块/
第三方系统 Report EventCycle Reader 阅读器
EventCycle Reader
阅读器
ECSpec配置
 LRSpec配置
图 5-2 ALE 模式中间件交互图
5.2.1 数据处理服务模块
基于 ALE 规范,数据处理服务模块作为中间件系统的核心模块,其设计包
含两大组件:Event Cycle 和 Reader,Event Cycle 主要负责数据过滤以及数据
上传,Reader 主要负责数据收集以及阅读器管理。此外,在标签中以二进制存
储的数据在经过中间件时,需要有一个数据转换并验证的处理。
Reader 作为模块中直接与阅读器交互的逻辑组件,起到与实体阅读器通信
连接以及控制管理的作用。对于不同规格的阅读器,Reader 采用不同的接口逻
辑设计,以达到兼容、便于扩展的目的。首先,用户可以通过可视化的配置界
面,调用系统发布的服务接口,实现将配置好的 XML 文件传入模块中进行
Reader 定义以及初始化。随后,Reader 通过 TCP、HTTP 或者 LLRP 等传输协
议,与阅读器建立连接。用户可以选择性地开启或者关闭多个已经定义的 Reader
读周期,以实现对多个阅读器的管理,并同时有序地、可控地收集相关阅读器
的数据。
此外,由于标签里存储的是按照 EPC global 标准设置的二进制编码数据,
其包含 SGTIN、SGLN、GID 等多种编码格式,系统需要将不同编码风格的数
据转换成固定不变的 URI 码统一处理,同时验证原有编码的正确性,过滤掉错
误的编码信息。
Event Cycle 是中间件系统中的核心组件,主要实现数据的过滤以及上传等
功能。不论是固定阅读器还是手持阅读器,其在读取标签数据的时候,是按一
- 35 -
哈尔滨工业大学工程硕士学位论文
定间隔,持续不断地扫描读取,所以在一段时间之内,重复的读取势必产生标
签数据的冗余。为了解决这一问题,Event Cycle 组件通过设置时间周期或者触
发数据处理的条件,将一段时间内监听到的多个 Reader 数据集按照某种配置进
行合并过滤处理,比如设定 10s 的时间周期,每个周期合并过滤前 8 秒的数据
集合,这些设定均可以由用户通过接口进行指定配置。当 Event Cycle 组件处理
完数据的时候,系统将生成对应的事件报告 Report,并按照用户配置的参数进
行规范化,同时发送到指定的服务器端口,第三方应用系统或者其他模块通过
监听该端口即可获取到处理后的数据。
5.2.2 数据访问服务模块
数据访问服务模块主要处理与数据库交互部分的访问逻辑,将上传的数据
进行及时存储以及查询。该模块的设计主要包含三个方面:数据库访问接口的
设计、监听端口功能的设计、可视化操作界面的设计。
数据库访问接口即为实现 CRUD 操作的调用接口,并实现出可满足用户的
多功能统计查询接口,同时为满足第三方应用系统的接入调用要求,这些访问
接口需要以服务的形式向外发布,以实现数据库的远程调用以及权限的管理。
数据监听端口主要用于接收数据处理服务模块处理完毕的数据,并通过数据访
问接口实现数据的存储。可视化操作界面主要方便于用户的对数据库方便实时
的监控和管理,这里采用 B/S 的交互模式进行设计,可以实现可视化界面的平
台无关性。
5.3 RFID 中间件接口设计
中间件的接口的设计内容包括,数据处理服务模块的阅读器接口设计、配
置接口设计,数据访问服务模块的访问接口设计。
阅读器接口设计如图 5-3 所示,是一种代码模式的设计,采用适配器的设
计思想,将 Reader 的通用功能抽离出来作为接口,具体的实现逻辑通过子类进
行实现,以应对不同实体阅读器的交互操作。当有特定某一阅读器接入系统时,
指定配置已实现的特定阅读器设配器,或者设计一套新的阅读器适配器去实现
相关接口,便可完成阅读器的连接和管理,提高中间件系统的兼容性和扩展性。
阅读器的通用接口主要包含启动和停止读周期、启动和断开阅读器连接、读取
标签、更新 Reader 配置等逻辑功能。
- 36 -
哈尔滨工业大学工程硕士学位论文
图 5-3 阅读器接口设计图
配置接口设计如图 5-4 所示,LRManager 和 ALE 类分别作为 Reader 和
EventCycle 的配置启动类。其中 LRManager 提供了定义 Reader 信息、管理 Reader
以及获取相关配置信息的接口,ALE 则提供了定义 EventCycle 信息、启动订阅
模式以及获取配置信息的接口,并通过 ReportGenerator 实现 Report 信息的生成
以及发送。为了供第三方应用或者其他模块调用这些配置接口,系统采用 RPC、
WebService 等远程调用技术暴露相关接口,而用户可以通过这些接口,对中间
件系统进行远程的操作管理。
图 5-4 配置接口设计图
- 37 -
哈尔滨工业大学工程硕士学位论文
访问接口通常作为第三方应用管理系统(这里通常指仓库管理系统)或者
其他模块的访问入口,提供对中间件数据库的各种操作功能。中间件系统采集
并处理后的标签数据通常存储在中间件数据库中,而仓库管理系统可以通过暴
露的访问接口实现与中间件数据库的通信,以达到数据再上传的功能。访问接
口的设计通常使用 RESTful API 完成。
5.4 数据库模型设计
中间件数据库的数据信息表主要包括阅读器信息表、事件信息表、标签信
息表、用户信息表。阅读器表用来存储 Reader 组件的相关信息,包括所连接实
体阅读器的 ip、端口地址以及用户的配置信息;事件表用来存储 EventCycle 组
件的相关信息,包括绑定的 Reader 组件编号(即阅读器编号)以及用户的事件
配置信息;标签表主要存储标签相关的信息,标签数据以及收集该标签信息的
阅读器编号;用户表作为登录权限的使用,主要记录用户的登录信息以及其他
基本信息。
中间件数据库的实体 E-R 图如图 5-5 所示。其中阅读器实体属性包括阅读
器编号、名称、类型、实体阅读器地址、阅读器配置信息;事件实体属性包括
事件编号、事件名称、事件配置信息;标签实体属性包括标签编号、标签类型、
标签信息;用户实体属性包括用户编号、用户名、密码、电话。
 阅读器编号 阅读器名称
事件名称
配置信息
连接地址 管理
事件 阅读器
事件编号
配置信息
读取 权限类型
用户编号
用户 标签
用户账号
 标签编号
 用户电话 标签信息
用户密码
图 5-5 中间件数据库的实体 E-R 图
5.5 本章小结
本章主要对中间件系统的功能进行了详细的分析和设计。首先从整体架构
- 38 -
哈尔滨工业大学工程硕士学位论文
上对中间件进行设计,将功能模块分为数据处理以及数据访问两个大的模块,
并明确模块功能定位。同时为了满足中间件的数据收集、处理、上传等功能的
实现,并通过设置参数进行控制,我们基于 ALE 规范进行组件设计,统一标准
简化了系统的设计与实现。针对接口部分,我们设计了 ALE 规范下的配置接口,
给出了主要的调用接口设计图,同时为了适配多种阅读器,我们采用了阅读器
适配器模式。最后对 RFID 中间件系统的数据库做了一个简单设计。本章的设
计基本可以满足中间件的功能需求,通过 ALE 规范,明确了软件设计思路,后
续的开发可以快速进行,但由于某些原因,本章在设计方面没能针对不同的阅
读器差异进行具体的接口适配器设计,只进行了通用的接口方法设计,设计上
还不够全面。
- 39 -
哈尔滨工业大学工程硕士学位论文
第 6 章 决策平台的设计
本章主要依据决策平台的需求分析介绍本平台相关的设计工作,主要内容
包括架构设计、业务流程设计、功能节点设计以及消息的格式设计。平台的架
构方面采用主从模式,明确各个节点的功能定位;在业务方面进行了 file、start、
stop 以及 query 业务的详细流程设计;功能设计上,以节点为单位,对节点内
部的主要功能进行了深入剖析和设计;最后设计并规范了节点之间进行消息交
互的消息格式。
6.1 决策平台架构设计
主从架构模式(Master-Slave),其架构模式图如图 6-1 所示,这是一种基
于分治思想的分布式架构模式,它可以利用中心节点将单个复杂任务拆分为多
个简单且语义相同的子任务,并将其分配到各个子节点中进行处理,最后将各
子节点的处理计算结果进行整合并输出。这种架构模式充分利用子节点各项资
源,通过采用并行的运算方式,提高系统的计算性能,同时由于多子节点的利
用,增强了系统的容错处理,大大提高了系统的可靠性。Master 作为中心节点,
主要负责任务的调度与分配,并且只能有一个;Slave 作为子节点,主要负责各
个子任务的计算,可以同时运行多个节点以构建集群提高计算的并行性。
Job
Master
Init1 Init3
 Init2
···
Slave1 Slave2 Slave3
Result2
Result1 Result3
Master
图 6-1 主从架构模式图
本决策平台采用上述主从架构实现任务的分发和结果的汇总功能,并借助
云计算思想,利用本地资源或者 IaaS 服务来搭建 SaaS 化的决策平台,用户无
需关心系统的底层部署以及硬件分配,而只用熟悉平台如何操作即可,用户完
- 40 -
哈尔滨工业大学工程硕士学位论文
全可以通过浏览器实现对决策平台计算服务的访问。决策平台架构图如图 6-2
所示,该系统在逻辑上分为 Master 和 Slave 两种节点,其中 Master 节点又包含
任务处理组件以及路由调度组件,而 Slave 节点可以被看作不同的物理机,具
有独立的 cpu、gpu 和内存,主要作为 Slave 节点进行异步的并行计算。Master
与 Slave 集群之间的交互是基于网络的消息传递式交互,这里的消息既可以是
计算数据或者配置信息,也可以是单纯的控制命令,这需要业务自身去控制消
息交互的规范。
决策平台
Master
Slave1
任务处理组件 任务处理组件
Slave2
任务管理 任务管理
Slave3 数据更新 数据更新
Slave4
可视化 可视化
...
图 6-2 决策平台架构图
Master 节点是该决策平台设计的重点,是作为用户访问服务的入口,其有
两个核心组件来进行任务管理和子节点管理:任务处理组件主要负责任务状态
的控制和管理,其包括上传数据、配置任务、启动任务、停止任务、结果汇总
等业务子功能,同时对外提供服务访问接口,用户可以通过可视化界面对决策
平台进行访问并进行服务的调用;路由调度组件的核心功能即调度功能,不仅
需要将任务正确地调度分发到合适的子 Slave 节点中,还要时刻监控子节点的
状态信息是否正常以避免错误的产生,此外子节点的注册、注销功能以及信息
交互等功能均由该模块进行直接控制。
Slave 节点主要负责具体任务的计算,是决策平台可扩展的部分。通过容器
技术,平台屏蔽了算法的底层实现,用户可以自由选定合适的算法或者语言平
台,前提是保证与 Master 达成统一的接口以及消息规范。为了不影响主从节点
之间的交互,子节点的计算过程应当采用异步的方式进行,每隔一段时间应向
主节点汇报当前状态、计算进度以及中间结果。此外,为了实现平台 SaaS 化,
要求决策平台实现包括互联网特性、多重租赁特性、服务特性以及可扩展特性
- 41 -
哈尔滨工业大学工程硕士学位论文
这四大特性。
6.2 决策平台业务流程设计
本决策平台在业务功能上,主要包含四个业务:file(上传计算模型以及数
据 )、start(启动计算任务)、stop(停止计算任务)、query(查询当前计算结果)。
则四个业务是该决策平台 SaaS 服务的入口,通过对外提供访问接口,用户可以
通过这些接口实现对计算服务的访问以及计算进程的把控。此外,为了实时更
新计算的过程结果,在启动计算任务时,需要启动自动查询功能,通过不间断
地接收计算中间结果以实现伪实时监听 Slave 节点的功能。
6.2.1 file 业务流程
file 业务的主要目的是为了将用户本地的计算模型或者初始数据上传到
Slave 节点,定制化计算的初始数据和模型,以提供计算依据。同时,为了达到
一次上传多次下载的目的,本业务需要借助第三方云存储服务实现。file 业务
的消息传递图如图 6-3 所示、业务流程图如图 6-4 所示,其主要流程步骤如下:
download
云存储
Slave1
upload
file
业务 Master Slave2
file消息
Slave3 filed消息
图 6-3 file 业务消息传递图
(1)用户将数据或者模型文件上传至云存储服务中,并结合存储地址生成
file 请求,发送至 Master 开始启动 file 业务;
(2)Master 接收到 file 请求后,生成 file 消息,并通过调度后,发送给符
合条件的 Slave 节点,通知其准备进行数据下载;
(3)Slave 节点接收到 file 消息后,按照给定参数向指定的云存储上下载
相关数据和模型;
(4)Slave 节点下载完数据和模型后,检查文件大小并验证校验码,如果
验证正常,表示下载没有问题,返回 filed 成功消息;否则,表示下载文件出现
- 42 -
哈尔滨工业大学工程硕士学位论文
问题需要重新下载,并继续进行验证,如果验证成功,返回 filed 成功消息,如
果再次失败则返回 filed 失败消息。
file业务 流程开始
用户将数据
及模型上传
至Master
Master上传
至云存储
Master发送
 file消息至
 计算节点
计算节点下
载云存储数
 据并验证
N Y
首次验证?
Y N 验证正确 验证正确
否? 否?
 Y
N
回复filed
失败消息给
 Master 回复filed
成功消息给
 Master
file业务 流程结束
图 6-4 file 业务流程图
6.2.2 start/stop 业务流程
start 业务主要负责向子节点传达初始化参数并启动计算进程;而 stop 业务
则负责停止所有还在运行状态的 Slave 节点。为了监控 Slave 节点的运行状态,
在启动计算的同时,自动查询功能被起用,实现实时数据的获取和状态更新,
- 43 -
哈尔滨工业大学工程硕士学位论文
停止计算同时也将停止自动查询。Start 业务流程图如图 6-5 所示、消息传递图
如图 6-6 所示,其主要流程步骤如下:
start业务 stop业务 流程开始 流程开始
 用户向 用户向
Master发送 Master发送
 start请求 stop请求
Master发送 Master发送
 start消息至 stop消息至
 计算节点 计算节点
计算节点启动 计算节点停止
 计算并返回 计算并返回
started消息 stopped消息
Master接收到 Master接收到
 started消息后 stopped消息后
 开始自动查询 停止自动查询
start业务 stop业务 流程结束 流程结束
图 6-5 start/stop 业务流程图
Slave1
start/stop
业务
Master Slave2
start/stop
消息
started/stopped
消息 Slave3
图 6-6 start/stop 业务消息传递图
(1)用户通过浏览器,向 Master 发送 start/stop 请求,开始启动 start/stop
业务;
(2)Master 将接收到的 start/stop 消息通过调度模块轮询发送至符合要求
的 Slave 节点:start 消息发往停止状态的 Slave 节点,而 stop 消息发往至运行
- 44 -
哈尔滨工业大学工程硕士学位论文
状态的 Slave 节点;
(3)Slave 节点收到消息后,做出相应的反应,并返回 started/stopped 消
息,告知 Master 已经启动或者停止计算;
(4)Master 收到回复消息后,开启或者停止自动查询更新的功能,实现
客户端页面对计算中间结果信息的实时获取。
6.2.3 query 业务流程
query 业务主要用于查询 Slave 节点当前的计算状态以及中间结果,实现数
据的伪实时的同步更新,更好的让用户跟踪各个节点的计算动态,对计算时出
现的异常问题进行把控。query 业务流程图如图 6-7 所示、消息传递图如图 6-8
所示,其主要流程步骤如下:
query业务
流程开始
用户向 Master发送
 query请求
Master发送
 query消息
 至计算节点
计算节点
检查自身
计算状态
N Y
是否 计算完毕?
返回result消 返回final消
 息给Master 息给Master
query业务
流程结束
图 6-7 query 业务流程图
- 45 -
哈尔滨工业大学工程硕士学位论文
Slave1
query
业务 Master Slave2
query
消息
result/final
消息 Slave3
图 6-8 query 业务消息传递图
(1)用户通过客户端向 Master 发送 query 请求,或者由 start 业务触发自
动查询更新功能,持续发送 query 请求,启动 query 业务;
(2)Master 根据 query 请求生成 query 消息,并筛选出运行态的 Slave 节
点,通过调度逻辑分发 query 消息。
(3)Slave 节点收到 query 消息后,检查当前计算状态:若还在计算过程
中,回复 result 消息,表明为计算还在运行,返回中间结果;否则回复 final 消
息,表明计算完毕,返回最后结果。其中,result 消息和 final 消息都包含当前
运行结果以及运行状态。
(4)Master 收到 Slave 节点返回的结果消息后,更新本地存储的计算数据,
实现数据的伪同步。
6.3 决策平台功能设计
6.3.1 Master 节点
Master 节点是管理分配任务的核心节点,除了上传文件、启动停止任务、
查询状态等业务功能外,还包括节点注册、任务调度、数据更新、消息处理等
内部功能。
6.3.1.1 节点注册
系统运行时,Master 节点持续监听 Slave 节点的注册请求。当收到某一节
点的注册信息时,可以将其纳入整个决策系统,并适时分配计算任务;当收到
某一节点注销信息时,则将其从系统中删除。后续的任务分配和调度都需要参
考已经注册的节点资源。
6.3.1.2 任务调度
在分配任务的过程中,Master 利用自身调度逻辑,从符合要求的 Slave 节
- 46 -
哈尔滨工业大学工程硕士学位论文
点中选取一个优先级最高的节点进行节点资源分配。具体实现时可以利用优先
队列实现 Slave 节点排序,或者单纯地利用轮询模式进行任务分配。
6.3.1.3 数据更新
Slave 节点在计算的过程中,会持续的将中间结果发送回 Master,用于计
算结果的数据更新,以便客户端任何时刻都能获取到最新的计算结果。为了达
到时间的一致性,每个 Slave 节点在计算过程中不会主动发送中间的计算数据
和状态,只有在 Master 发送 query 消息后,Slave 节点才会返回计算和状态信
息。此外,Master 提供了用户访问入口以及数据展示界面,用户通过客户端即
可实现对计算过程的监控。
6.3.1.4 消息处理
整个系统采用传统的 Socket 或者 HTTP 协议进行消息的传输,消息接收与
发送逻辑相互独立,即发送逻辑只负责消息的生成和发送,而接收逻辑只负责
消息的接收和处理,以达到消息打包与处理互不干扰的效果。此外,系统约定
好 Master 与 Slave 节点之间进行消息传递的消息格式的规范标准,消息的处理
过程须参考该规范标准。
6.3.2 Slave 节点
Slave 节点则是利用多个物理资源进行高效计算的 Slave 节点,除了负责计
算决策外,还具有与 Master 异步通信的功能。Master 通过消息传递的方式,来
对 Slave 节点集群进行管理,以实现系统的分布式的并行计算。
Slave 节点的算法没有具体固定的实现,可以供设计者自由实现以及扩展。
但要注意的是,Slave 节点的设计须符合系统统一的消息格式规范,并严格按照
该规范与 Master 进行消息交互与处理,消息交互的形式可采用 Socket 或者
HTTP 等方式。Slave 节点的行为完全由 Master 通过不同的消息传递进行控制,
针对不同的业务命令,Slave 进行不同的任务处理,主要包括下载数据、启动计
算、停止计算和返回计算结果。同时 Slave 节点在启动时就向 Master 发送注册
信息,终止时就发送注销信息,实现启动即加入、终止即退出的效果。此外为
了保证各个节点运算过程的独立性和代码的可移植性,系统用到了到容器化技
术。通过容器的虚拟化和封装,在保证系统消息传递的消息格式标准统一的前
提下,设计者可以自行选用最优的实现算法(如演化算法、分类算法等)和平
台语言(Matlab、C++等)进行问题决策,从而屏蔽底层逻辑或者平台环境的
差异,提高系统兼容性和扩展性。
- 47 -
哈尔滨工业大学工程硕士学位论文
6.4 消息格式设计
Master 节点与 Slave 节点的交互方式采用消息传递的方式,而统一的消息
格式能够清晰系统业务逻辑、简化处理难度,因此规范化消息的格式非常有必
要。该系统的消息格式采用 json 消息格式,json 消息相对于 xml 来说格式简单、
体积更小、网络传输速度更快,同时具有平台、语言无关性,便于服务器的解
析。此外,为了具体化消息格式的设计,这里引入一个最大集合覆盖问题的案
例,并使用演化算法进行求解,以此为基础进行 json 消息格式的设计。
每种消息主要包含 type、content、id 这三个属性:其中 type 表示消息类型,
用以区分消息种类;content 表示消息主体内容,不同类别的消息内容会有区别,
处理的逻辑也会不一样;id 表示各个节点的唯一标识码,主要包含了与 Master
进行消息传递的 Slave 节点的 ip 和 port,用于 Master 逻辑来区分不同的 Slave
节点传来的消息。以下消息种类按业务,包括 file、filed、start、started、stop、
stopped、query、result、final、register 以及 registered,其中 register 和 registered
主要用于系统初始化阶段的节点注册。
(1)file 消息由 Master 节点发送至 Slave 节点,其格式如下所示。其中
content 内容主要包含 url、md5 以及 size 三项属性,url 表示云存储的文件路径,
md5 作为文件校验码,size 指代文件的大小。
{//file 消息
"type":"file"
"content":{
"url":"pan.baidu.com/file.txt"
"md5":"0ca175b9c0f726a831d895e269332461"
"size":2131412
}
"id":"106.128.2.1:5084"
}
(2)filed 消息由 Slave 节点发送至 Master 节点,其格式如下所示。其中
content 属性中的 status 表示文件是否下载及验证成功,msg 则用来补充原因等
备注信息。
{//file 消息
"type":"filed"
"content":{
- 48 -
哈尔滨工业大学工程硕士学位论文
"status":"succeed"/"failed"
"msg":"success/fail to download file"
}
"id":"106.128.2.1:5084"
}
(3)start 消息由 Master 节点发送至 Slave 节点,其格式如下所示。其中
content 中的 population、iteration、k 是演化算法运行的初始参数,作为一个特
殊案例设计的表现形式。当然对于具体的不同算法,应当有不同的 content 内容。
{//start 消息
"type":"start"
"content":{
"population":[[5,6,8],[4,8,6,9],[0,24,6],[2],[8,5]], "iteration":100, "k":5
}
"id":"106.128.2.1:5084"
}
(4)started 消息由 Slave 节点发送至 Master 节点,其格式如下所示。其中
content 包含的 status 和 msg 表示的含义与 filed 消息类似,这里不再赘述。
{//started 消息
"type":"started"
"content":{
"status":"succeed"/"failed"
"msg":"success/fail to start"
}
"id":"106.128.2.1:5084"
}
(5)stop 消息由 Master 节点发送至 Slave 节点,其格式如下所示。这里的
content 没有属性,表示直接停止当前计算。当然,content 的属性可以再进行扩
展定制,比如 delay 用来指定经过多少秒后再停止 Slave 节点的计算等等。
{//stop 消息
"type":"stop"
"content":{}
"id":"106.128.2.1:5084"
}
- 49 -
哈尔滨工业大学工程硕士学位论文
(6)stopped 消息由 Slave 节点发送至 Master 节点,其格式如下所示。同
样,content 属性内容与 started 消息相似,不再赘述。
{//stopped 消息
"type":"stopped"
"content":{
"status":"succeed"/"failed"
"msg":"success/fail to stop"
}
"id":"106.128.2.1:5084"
}
(7)query 消息由 Master 节点发送至 Slave 节点,其格式如下所示。其
content 内容没有属性,表示获取当前计算结果并返回。设计者同样可以自行进
行消息定制,例如筛选并按照关键字属性进行计算结果的查询。
{//query 消息
"type":"query"
"content":{}
"id":"106.128.2.1:5084"
}
(8)final/result 消息由 Slave 节点发送至 Master 节点,其格式如下所示。
final 与 result 消息相似,仅用来区分当前 Slave 节点是否已经自行计算所有的
运算任务。在这个案例中,content 包含 solution、fitness、iteration、timecost
等结果数据,是算法运行所产生的中间结果。
{//final/result 消息
"type":"final"/"result"
"content":{
"solution":[5,9,6,3,4], "fitness":96, "iteration":50, "timecost":12.364
}
"id":"106.128.2.1:5084"
}
(9)register 消息由 Slave 节点发送至 Master 节点,其格式如下所示。
content 中主要包含当前 Slave 节点的 ip 和 port 信息,提供节点注册依据,而后
续消息的 id 属性也是基于此内容生成。
- 50 -
哈尔滨工业大学工程硕士学位论文
{//register 消息
"type":"register"
"content":{
"ip":"106.128.2.1", "port":5084
}
"id":""
}
(10)registered 消息由 Master 节点发送至 Slave 节点,其格式如下所示。
该消息的 content 内容与 filed、started 以及 stopped 消息内容相似,不再赘述。
{//registered 消息
"type":"registered"
"content":{
"status":"succeed"/"failed"
"msg":"success/fail to register"
}
"id":"106.128.2.1:5084"
}
6.5 本章小结
本章主要对决策平台系统的设计做了一个详细的分析。首先我们确立了平
台采用的主从架构,基本理清了平台并行计算的工作模式,以提高决策系统的
计算性能。为了满足用户对决策平台的任务进行可视化管理控制,我们设计了
file、start、stop、query 业务流程,明确了设计要点,并配以相关的功能按钮,
理清了平台的操作流程。同时为了保证平台的正确运行,我们对 Master 节点以
及 Slave 节点进行了详细的功能设计,明确了节点之间消息交互机制、数据更
新方式、任务调度模式等等主要功能。最后设计出了一套标准化的消息格式,
统一了节点之间的交互方式,简化的消息的处理过程。本章的设计基本可以满
足系统的功能需求,通过架构设计以及流程设计,我们清晰了平台的工作模式,
为后续的节点功能提供了设计依据。我们对消息格式进行了统一,简化了系统
设计,但针对不同的任务理应有不同的消息细节,设计的这一部分没有确切的
定义,留有一定的设计空间。
- 51 -
哈尔滨工业大学工程硕士学位论文
第 7 章 系统的实现
本章主要作为各个子系统完成需求分析和系统设计后进行的系统实现的展
示章节,主要通过代码对各子系统主要功能进行实现。本章节着重介绍了系统
的实现环境、主要功能界面展示以及部分算法核心代码,同时针对不同子系统
的主要功能进行了软件测试,以便验证系统设计和实现的正确性及合理性。
7.1 系统实现环境
整个基于 RFID 技术的分布式物流仓储管理系统主要基于 JavaEE 平台并结
合 Maven 管理工具进行开发,选用成熟的 Springboot 规范构建单个独立的服务,
然后利用 Docker 容器技术将服务打包并以微服务的形式部署到 Kubernetes 集
群中,实现分布式的服务管理。技术选型上,采用 Mybatis 作为 ORM 框架、
Apache Shiro 作为安全框架、Apache cxf 作为 WebService 框架、Vue 或者 Jquery
作为前端框架,数据库选用 Mysql 技术。
整个系统将会部署在 Linux 系统之上,用户可以通过 PC 端或移动端的浏
览器对系统有关服务进行访问,实现系统的控制管理。
7.2 仓库管理系统的实现
7.2.1 主要模块的实现
仓库管理系统的后端采用 Java 实现,并使用 Springboot、Shiro、MybatisPlus
等后端技术简化后端开发;前端采用 JS+HTML 技术进行实现,并使用 Jquery、
Themyleaf、LayUI 等前端框架简化逻辑以及优化界面。仓库管理系统在 Windows
平台上进行开发,并使用 IDEA、Navicat 等作为开发工具、Maven 作为项目管
理工具。仓库管理系统的数据库技术选用 Mysql,并使用 Druid 作为数据库连
接池。
下面对仓库管理 系 统 基本功能模块进行介绍,用户通过浏览器访问
http://localhost:8888/sys/toLogin,开始进入仓库管理系统的登录界面,如图 7-1
所示。
用户输入正确的用户名、密码以及验证码登录后,通过验证后,即可进入
仓库管理系统后台主界面,如图 7-2 所示。后台系统的主界面主体包括三个部
- 52 -
哈尔滨工业大学工程硕士学位论文
分,包括顶部导航栏、左侧菜单栏、右侧内容页面。用户通过点击左侧菜单栏
菜单项,右侧可以跳转到对应的管理页面,其中后台内容首页作为预留页可以
展示当前时间或公告信息。
图 7-1 系统登录界面
图 7-2 系统后台主界面
用户进入任何管理界面,都可以发现,本仓库管理系统对于所有模块的表
单信息都提供了属性筛选、数据导出以及表单打印的功能,其功能按钮位于各
- 53 -
哈尔滨工业大学工程硕士学位论文
个表单的右上角。利用这些小功能,用户可以快速查找信息、保存数据,表单
信息界面如图 7-3 所示。系统在信息增删改查的代码实现上利用 MybatisPlus
快速生成数据访问代码,并实现了分页查询。
图 7-3 表单信息界面
7.2.1.1 系统管理模块
系统管理模块包括权限管理、角色管理、用户管理三部分,主要用于对系
统权限的编辑和分配以及对用户信息的查询和更新,是系统的安全部分,只有
拥有最高权限的超级管理员可以使用。
本设计下,系统如何进行权限的分配是一个难点,为了保证不同权限的用
户登录系统时,系统只会展示符合权限要求的管理模块的要求,我们构建了一
个额外的数据表,用来存储各个模块的信息以及权限等级。当用户登录系统时,
系统会读取该数据表,自动更新管理菜单,而系统的权限分配也是基于此实现。
在这种实现方式下,仓库管理系统的管理权限已经细化为各个管理模块增
删改查的各个操作。在权限管理界面下,管理员可以对各个权限进行新建、删
除或者更改操作,并构建权限从属关系树,实现权限的绑定。管理员可以通过
点击权限管理界面下的编辑按钮,在弹出的对话框中对相关信息进行修改,其
权限管理界面如图 7-4 所示。
角色管理主要负责实现系统角色的增删改查以及权限的分配。在利用仓库
管理系统的进行管理过程中,每个角色所拥有的管理权限各不相同,而相同角
色之间的管理权限须保持一致,在角色管理界面下,超级管理员可以自行选择
和控制。在本设计下,预设的角色分别有超级管理员、仓库管理员、采购员、
销售员,外加一个测试角色。角色管理界面如图 7-5 所示。
- 54 -
哈尔滨工业大学工程硕士学位论文
图 7-4 权限管理界面
图 7-5 角色管理界面
用户管理实现了对使用本仓库管理系统的人员的管理。在仓库管理系统中,
不同用户拥有各自的用户属性,比如用户账号、用户地址、所属部门等信息。
在用户管理界面下,超级管理员可以实现对用户信息的增删改查,同时还能为
不同用户分配不同角色,以实现动态的用户权限分配。用户管理界面如图 7-6
所示。
- 55 -
哈尔滨工业大学工程硕士学位论文
图 7-6 用户管理界面
7.2.1.2 基本信息管理模块
基本信息管理模块包括供应商管理以及客户管理,主要负责供应商、客户
信息的增删查改处理,同时该模块支持特定属性(包括名称、联系方式)的模
糊查询,用户可以通过输入相应关键字进行模糊查询。该模块主要由仓库管理
员以及超级管理员使用,系统的供应商管理界面如图 7-7 所示,客户管理界面
如图 7-8 所示。
图 7-7 供应商管理界面
- 56 -
哈尔滨工业大学工程硕士学位论文
图 7-8 客户管理界面
7.2.1.3 库存管理模块
库存管理模块是提供库存信息的重要模块,主要由仓库管理员进行操作。
在货物管理界面下,用户可以通过多种关键字对库存的货物信息实施查询筛选。
此外货物的库存量和预警值属性,可以作为库存预警的依据,一旦库存量大于
预警值,系统公告将对相关用户提出预警信息,使得管理人员能够及时发现。
货物管理界面下的货物添加操作如图 7-9 所示。
图 7-9 货物管理界面
- 57 -
哈尔滨工业大学工程硕士学位论文
7.2.1.4 入库管理模块
入库管理模块主要由采购员以及仓库管理员使用。该模块负责货物的入库
作业,实现对入库货物信息的登记记录。在入库业务流程上,应该是由采购员
负责发起入库请求,并提交采购单准备进行入库业务,随后供应商发货,货物
开始入库,仓库管理员进行核实后生成入库单,最后实现数据库的更新,完成
入库作业。
如何实现将采购员生成的入库单通知到仓库管理员是一个难点,这里的给
出的实现方式是给入库单标记一个属性用于判断当前入库单信息是否已经更新
到系统中,当标记可用时,表明还没有进行审核,即入库单属于待审核状态,
需要仓库管理员手动确认,随后系统才进行入库信息的更新,同时会将其标记
为不可用。生成入库单时,需要相应用户填写包括供应商名称、货物名称、入
库数量、入库备注等基本入库信息。入库管理下,添加入库作业请求操作界面
如图 7-10 所示。
图 7-10 入库作业界面
当货物入库请求审核被仓库管理员否决时,货物入库流程失败,系统随即
生成入库异常记录,即失效的入库单,用户可以对该信息进行搜索核查。入库
管理下的异常入库记录界面如图 7-11 所示。
- 58 -
哈尔滨工业大学工程硕士学位论文
图 7-11 入库异常界面
7.2.1.5 出库管理模块
出库管理模块主要是由销售员与仓库管理员使用。其界面操作与业务实现
与入库管理模块类似,此处不再赘述。出库管理模块的出库作业界面如图 7-12
所示、出库异常界面如图 7-13 所示。在出库异常界面下,用户可以对异常信息
进行时间范围内的查询,对于已经处理的异常信息可以进行删除。
图 7-12 出库作业界面
- 59 -
哈尔滨工业大学工程硕士学位论文
图 7-13 出库异常界面
7.2.2 系统测试
为了保证仓库管理系统的设计合理性和功能正确性,系统需要进行相关功
能以及访问性能测试,及时发现系统存在的问题并加以修正,减少系统错误的
可能。系统的测试方式采用黑盒测试,通过设计不同的测试用例,输入系统中,
并检查程序是否能够与预期的结果相吻合,以此判断系统的功能以及性能是否
能够满足设计需求。仓库管理系统的测试环境为 Linux 系统,由于篇幅所限,
这里仅仅对部分关键功能以及查询性能的测试情况加以叙述。
7.2.2.1 系统登录测试
这里主要测试用户登录功能,测试用户在输入用户名和密码进行系统登录
时,所有可能出现的情况,包括输入账号与密码错误、验证码错误、密码为空
等情况。具体测试用例如表 7-1 所示,能够成功登录系统的用户名为 admin,
密码为 123456。
表 7-1 系统登录测试用例
输入用例 预计输出 实际输出 测试结果
用户名:admin
密码:123456 成功登录系统 成功登录系统 通过
正确的用户名和密码
- 60 -
哈尔滨工业大学工程硕士学位论文
表 7-1 (续表)
输入用例 预计输出 实际输出 测试结果
用户名:admin0
密码:123456
错误的用户名 提示“用户名或密
码错误” 提示“用户名或
密码错误”
通过
用户名:admin
密码:00000
错误的密码 提示“用户名或密
码错误” 提示“用户名或
密码错误”
通过
用户名:admin
密码:
用户名或密码为空 提示“必填项不能
为空” 提示“必填项不
能为空”
通过
错误的验证码
或者验证码为空 提示“验证码错
误” 提示“验证码错
误” 通过
7.2.2.2 系统管理测试
这里主要测试系统能否成功实现用户信息录入、查询、角色分配、权限分
配等功能。具体测试用例如表 7-2 所示。
表 7-2 库存管理测试用例
输入用例 预计输出 实际输出 测试结果
用户编号:ID100001
用户姓名:张三
用户名:zhangsan
联系方式:135000
备注:无 系统成功录入
用户信息 系统成功录入
用户信息 通过
录入用户信息
查询姓名为“张三”
的用户信息 系统成功展示“张
三”的用户信息 系统成功展示“张
三”的用户信息 通过
为“张三”赋予“超级管
理员”的角色权限 系统成功为“张三”
分配角色 系统成功为“张三”
分配角色 通过
为“超级管理员”角色分
配所有的管理权限 系统成功分配所有
权限 系统成功分配所有
权限” 通过
- 61 -
哈尔滨工业大学工程硕士学位论文
7.2.2.3 库存管理测试
这里同样用来测试库存的货物信息能否成功添加、编辑、查询。当库存货
物的数量大于预警值时,系统将进行提示,以便用户采取相应措施。具体测试
用例如表 7-3 所示。
表 7-3 库存管理测试用例
输入用例 预计输出 实际输出 测试结果
货物编号:SP123456
货物名称:旺仔饼干
货物类型:食品
货物数量:30 系统成功添加
库存信息 系统成功添加
库存信息 通过
货物规格:500g
添加库存信息
修改货物数量为 100
编辑库存信息 系统成功修改
货物数量信息 系统成功修改
货物数量信息 通过
搜索货物编号为 系统成功展示 系统成功展示
“SP123456”的 “SP123456”相关 “SP123456”相关 通过
库存货物信息 的库存信息 的库存信息
添加或者编辑货物数量
使其大于当前货物的
预警值 提示“货物数量即
将到达库存上限” 提示“货物数量即
将到达库存上限”
通过
7.2.2.4 入库管理测试
这里主要用来测试入库清单信息能否成功添加、编辑、查找以及删除。当
某一信息填写格式出错时,系统可以自行验证并给予警告。具体测试用例如表
7-4 所示,出库管理测试过程类似,测试结果均通过,这里不再赘述。
表 7-4 入库管理测试用例
输入用例 预计输出 实际输出 测试结果
供应商:旺旺食品
货物:旺仔饼干
入库数量:50
入库价格:30 系统成功添加
入库信息 系统成功添加
入库信息
通过
添加入库信息
- 62 -
哈尔滨工业大学工程硕士学位论文
表 7-4 (续表)
输入用例 预计输出 实际输出 测试结果
修改入库数量为 10
编辑入库信息 系统成功修改
入库数量信息 系统成功修改
入库数量信息 通过
搜索供应商名称为
“旺旺食品”的信息 系统成功展示
“旺旺食品”相关
的入库记录 系统成功展示
“旺旺食品”相关
的入库记录
通过
删除该入库记录 系统成功删除信息 系统成功删除信息 通过
将货物数量改为“abc”
输入错误格式的数据 提示“格式错误,
只能填写数字” 提示“格式错误,
只能填写数字” 通过
7.2.2.5 查询响应时间测试
仓库管理系统其实现的本质就是数据库的增删改查,因此在对系统进行性
能测试的时候,用户通过浏览器对仓库管理系统当前所有货物的查询操作可以
说是系统最耗时的操作。为了测试查询响应时间,我们在数据库中批量加入货
物信息,通过设置不同量级的分页记录条数,进行分页查询的测试结果如下表
7-5 所示。
表 7-5 查询响应时间表
分页记录条数 10 100 200 500
实测响应时间 (ms) 54 289 454 1075
通过以上的响应时间测试,我们可以看到,当页面分页记录条数设置为 10
的时候,页面查询响应时间在 50ms 左右,完全可以满足用户在进行相关操作
的性能要求。
7.3 RFID 中间件的实现
本 RFID 中间件的实现是在开源软件 Fosstrak[44]的基础上重构实现。
Fosstrak 是一款早期开源的 RFID 中间件系统,系统基于 ALE 标准规范进行实
现,其主要模块包括进行数据访问的 EPCIS、用于数据转换的 TDT、用于数据
清洗的 ALE 以及对于固定式阅读器管理的 LLRP Commander。但该中间件系统
业务功能对于本仓库管理系统来说相对冗余,达不到针对性、轻量型的效果。
- 63 -
哈尔滨工业大学工程硕士学位论文
ALE 模块只实现了基于 LLRP 协议的固定式阅读器接口,而关于手持式阅读器
的适配器没有具体实现。EPCIS 模块功能繁琐、业务冗余,于是在本系统对该
模块进行重构,使用数据访问服务模块进行替代。该中间件由于针对手持式阅
读器,其 LLRP Commander 模块留为扩展或予以摒弃,而 TDT 数据转换模块
实现的很完善,本 RFID 中间件的实现中将继续采用该模块。
7.3.1 中间件功能实现
7.3.1.1 数据采集
数据采集的实现主要针对手持式阅读器,通过设计一个专门与手持式阅读
器进行交互的阅读器适配器,以达到数据采集的效果,这一功能主要由 Reader
组件实现。该适配器采用建立 TCP 服务器的方式持续接收阅读器传来的数据信
息,用户通过手持终端可以将读取完毕的数据一次性上传给 RFID 中间件。
7.3.1.2 数据过滤
数据过滤的实现针对阅读器上传的冗余数据,主要由数据处理服务模块中
的 EventCycle 组件实现。EventCycle 根据配置信息,将一个事件周期内的数据
进行过滤整合,底层代码使用 HashSet 结构实现数据过滤的功能。此外,每过
一个事件周期执行一次数据过滤后,就会生成一次事件报告 Report,并附上经
过过滤处理后的数据信息,交由数据访问服务模块进行存储操作,并在 Mysql
数据库的水平上再进行一次过滤。
7.3.1.3 数据访问
数据访问是数据访问服务的主要功能,负责对中间件数据库里的数据进行
增删改查的实现。这里采用 Springboot 整合 Mybatis-Plus 插件,自动生成通用
的 CRUD 操作相关的 DAO、Service、Controller 层,实现对 Mysql 数据库的快
速访问,简化服务开发。该模块利用 RESTful API 向外暴露数据的访问接口,
达到向外发布服务的目的。
7.3.2 可视化界面
本 RFID 中间件的可视化界面主要包括数据处理服务的配置界面以及数据
访问服务的信息界面。
7.3.2.1 配置界面
配置界面用来对数据处理服务中的 EventCycle 和 Reader 组件进行配置和
控制。在该 RFID 中间件系统中,EventCycle 和 Reader 组件的控制逻辑被抽象
- 64 -
哈尔滨工业大学工程硕士学位论文
为服务接口,同时利用 Apache cxf 框架实现服务的发布,而配置客户端通过调
用该 WebService 服务的方式实现远程配置和控制。配置界面本身通过 javaEE
平台实现,采用 C/S 架构,配置界面如图 7-14 以及图 7-15 所示。
图 7-14 Reader 组件配置界面
图 7-15 EventCycle 组件配置界面
- 65 -
哈尔滨工业大学工程硕士学位论文
其中 Reader 组件配置界面主要包含选择指令选项框和结果展示框:选择指
令选项框作为用户进行逻辑阅读器配置的可视化接口,用户可以通过选定特定
的接口函数,调用中间件的服务,例如定义阅读器规范、修改阅读器配置、获
取当前配置参数等等功能;而结果展示框主要作为调用接口后的回调展示,目
的在于告知用户调用是否成功以及调用后的结果。而 EventCycle 组件配置界面
于 Reader 类似,不同的是,其选择指令选项框除了用于定义事件周期的规范、
获取相关配置的接口服务之外,还具有启动事件周期、选择订阅模式等等功功
能,结果展示框作用与 Reader 类似,这里不再赘述。
7.3.2.2 信息界面
信息界面主要是数据访问服务中,用来实现对用户友好的数据库增删改查
操作以及向用户进行数据的展示功能。信息界面采用 B/S 架构,前端框架采用
Jquery、HTML、JS 实现页面逻辑与展示,并通过 RESTful API 实现与后端的
数据交互。
7.3.3 中间件测试
为了确保中间件能够完整的实现与阅读器的对接以及数据处理,中间件需
要对主要的数据采集和处理功能进行测试。由于相关硬件条件的不足,测试阶
段我们采用阅读器模拟器 Rifidi Emulator 来模拟 RFID 阅读器读取标签数据的
过程,模拟器如图 7-16 所示,其具有实体阅读器的基本功能。
图 7-16 Rifidi Emulator 阅读器模拟器
- 66 -
哈尔滨工业大学工程硕士学位论文
为了测试清晰中间件功能的先后逻辑,我们按照中间件启动流程来进行中
间件功能测试。中间件测试环境为 Windows,具体测试案例如表 7-6 所示。
表 7-6 中间件功能测试用例
输入用例 预期输出 实际输出 测试结果
使用 define 接口上传 成功连接阅读器,
LRSpec 配置文件对阅读 并提示“成功定义 提示“成功定义阅读器” 通过
器进行相关配置 阅读器”
使用 define 接口上传
ECSpec 配置文件对事件
周期进行相关配置 提示“成功定义事
件周期”
提示“成功定义事件周期” 通过
使用 subscribe 接口开启事 成功激活事件周
件订阅并配置 URL 端,进 期,并提示“成功 提示“成功订阅 URL” 通过
行数据报告的持续上传 订阅 URL”
URL 端持续接收 epc:
将 5 个模拟标签置于
Rifidi Emulator 阅读器
天线内 订阅的 URL 端接
收到清洗过滤后的
数据报告 3099D5CC8A5442A09A8DCB2D
30484CE4ED9C5E564D555DE3
30A05AA6B9C80185766A5553
30191791066745E03318A399
通过
309BA9620091C655459B5911
减少模拟标签
至 2 个标签 订阅的 URL 端接
收到清洗过滤后的
数据报告 URL 端持续接收 epc:
3099D5CC8A5442A09A8DCB2D
30484CE4ED9C5E564D555DE3
通过
使用 poll/immediate 接口
立即获取当前
数据处理报告 客户端展示当前数
据处理报告 客户端展示 epc:
3099D5CC8A5442A09A8DCB2D
30484CE4ED9C5E564D555DE3
通过
使用 unsubscribe 接口
取消订阅 成功取消事件订
阅,并提示“成功
取消订阅 URL” 提示“成功取消
订阅 URL”
通过
通过上述的功能测试,我们可以看到,该中间件基于 ALE 规范实现了基本
- 67 -
哈尔滨工业大学工程硕士学位论文
的数据采集、处理和上传等功能,能够在平台上稳定的工作,达到了我们设计
轻量级中间件的预期要求。
7.4 决策平台的实现
决策平台采用了上述提出的主从架构进行设计,而为了进一步验证该架构
和业务的合理性,需要基于此架构和业务实现一个简单的决策平台并进行响应
测试。这里我们引入了一个具体的实际问题作为设计案例,即最大集合覆盖问
题[45,46],来简化系统的逻辑实现。该问题描述为:给定多个集合,须在给定的
集合中挑选出固定数量的集合,使得挑选出来的集合进行并集操作后,结果集
包含的元素个数最多。该问题是一类 NP 问题,不能在多项式时间内求得最优
解,鉴于此本案例使用演化算法,利用其遗传变异的特性进行迭代计算,在多
次迭代后,获得一个近似较优解。最后,系统在多个节点所计算出的近似较优
解中汇总出近似最优解。
此外,为了体现决策平台的计算节点独立性和平台无关性,Master 节点基
于 JavaEE 平台实现,并使用 Springboot 作为 web 开发框架,而 Slave 节点使用
python 环境搭建。在消息交互上,整个平台系统均采用原生的 socket 编程实现,
并使用阿里云作为 OSS 服务。平台系统使用 Docker 容器打包并部署至 Linux
服务器,进行系统响应测试。
7.4.1 节点功能实现
决策平台系统的节点功能实现上包括 Master 节点和 Slave 节点,其中 Master
节点功能实现主要有节点注册、消息处理、数据更新以及节点调度,Slave 节点
功能实现主要包括演化算法的实现以及数据接收处理逻辑的实现。
具体的代码设计流程图如图 7-17 所示。其中当 start 业务启动时,Master
接收到某个 Slave 节点回复的 started 消息时,会开启该节点的 query 自动查询
线程,持续不断地获取该节点的计算结果并对 Master 保存的数据进行更新;而
接收到 stopped 消息时,将暂停自动查询线程,保留当前数据。此外,自动查
询线程还有一个作用,就是监控当前 Slave 节点的状态,当 Slave 节点接收到
query 消息时,会根据当前计算状态回复 result/final 消息,其分别表示正在计算
和计算结束,当 Master 获取到已经结束计算的 Slave 节点,同时系统还有未分
配的计算任务时,会重新对该子节点发送 start 消息,达到资源饱和式利用的效
果。系统在实现的时候,当用户预备的启动数大于已注册的 Slave 数时,需要
- 68 -
哈尔滨工业大学工程硕士学位论文
按顺序利用所有的计算资源依次对所有子任务进行计算,因此 Slave 在重新计
算时,需要通知 Master 保留上一次计算的结果,以达到显示所有子任务的计算
数据而不仅仅只展示当前 Slave 计算的数据。
前端 Master Slave
file.json
file sendfile dofile
 filed.json Cloud
 OSS
本地文件
 读取
start.json
start sendstart dostart
 started.json
开启计算 接收到started消息
线程 开启查询线程
stop.json
stop sendstop dostop
 stopped.json 终止 保存
接收到stopped消息
关闭查询线程
query.json
query sendquery doquery
 result/final.json
接收到final消息
且还有任务未分配
尝试start 结果变量
图 7-17 设计流程图
7.4.1.1 Master 节点
节点注册功能的实现借助 java socket 编程,系统在启动时立即开启一个注
册线程,专门用于处理 Slave 节点的注册请求。Master 节点中会持续维护一个
Slave 状态注册表,当有新的注册消息发送过来时,Master 验证其没有在该注
册表中时,会将其列入注册表中,进而实现 Slave 节点的管理。
消息处理功能负责消息的发送和接收以及对各种 json 消息的打包生成、数
据提取、逻辑处理,参考业务流程实现不同业务的不同逻辑。在消息的交互上,
同样采用 socket 编程实现,并对于每个 Slave 节点绑定唯一的查询线程,以减
少系统的线程切换花销。在 json 消息处理上,借助第三方的 fastjson 包以实现
json 字符串与 json 对象的快速转换和处理。
数据更新功能作为查询业务的核心需求,主要用于计算结果数据的实时展
示。Master 节点会在每个 Slave 节点的注册信息基础上维护一个用于线程共享
- 69 -
哈尔滨工业大学工程硕士学位论文
的数据变量,该变量持续更新并保存各个节点的中间结果数据。
平台的节点调度功能实现的较为简单,采用轮询的方式,遍历所有的 Slave
节点注册信息,找到符合要求的节点,然后分配任务即可。
7.4.1.2 Slave 节点
本案例的演化算法的具体实现思路如下:在计算开始前,系统随机生成初
始的种群(其中种群包含多个个体解,每个个体解就是一个集合,其包含所选
择的多个问题集合),并以此作为种群演化的依据;在开始计算时,算法会在当
前获得的种群基础上,进行种群的变异演化,简单来说,就是从种群中按某种
要求挑出某个个体,并对该个体的值按一定规则进行变换操作,得到变异个体,
通过个体评价,排除适应值较低的个体而保留适应值较高的个体,进行种群的
优化,进而获取最优解。
在本案例中,个体选择采用随机选择的方式,变异过程通过期望值为一的
概率对该个体进行增加或者删除元素,以获取更优秀的个体解,进而舍弃一些
不好的个体解。而个体解的好坏判断主要依据该个体解的问题规模(所选集合
数量)以及该个体解的并集结果集元素的个数(集合覆盖数)。当种群中某个变
异后的个体解里的集合覆盖数较大且所选集合数量相对较少时,说明该个体解
需要被保留,以作为后续演化的依据;否则,该个体解须被淘汰。通过这种方
式的不断迭代演化,种群将不断地自我优化。这个变异的过程通过迭代指定次
数,就能得到一个近似的较优解。
演化算法实现部分伪代码如表 7-7 所示,输入参数包括初始数据集、初始
种群、迭代次数、问题规模,输出结果即符合要求的当前最优解集合。算法的
伪代码中,mutation 方法执行的是种群的变异流程,可以获得变异后的个体解;
fitness 方法可以计算出当前个体解的适应值,这里即表示该个体解的集合覆盖
数,是作为评判个体好坏的标准之一;choose_best 方法可以从种群中获取到指
定问题规模的当前最佳解,即在特定问题规模 k 下的集合覆盖数最大的个体解。
由于篇幅限制,这里不再列出上述方法的代码实现。
值得注意的是,对于不同的优化算法,我们需要设计不同的程序接口,以
便更好的进行参数控制。对于这一点,目前还没有很好的实现接口统一,只是
在消息格式的设计方面留有了兼容和扩展空间,在采用对应的优化算法的时候,
Slave 节点可能需要进行接口的二次设计,并在实现中加入这一优化算法实现的
执行路径,以实现算法的局部模块化。本案例仅仅作为一个特殊案例,用于简
化该决策平台架构的实现,并测试平台的执行性能,以验证平台的合理性和稳
定性。
- 70 -
哈尔滨工业大学工程硕士学位论文
表 7-7 演化算法伪代码
算法:演化算法求解最大集合覆盖问题
输入:初始数据集 dataSet,初始种群 population,迭代次数 iteration,问题规模 k
输出:当前最优解集合
1: function ALGORITHM (dataSet, population, iteration, k)
2: m←len(dataSet)
3: t←0
4: while t<iteration do
5: s←random.choice(population) 6: offSpring_s←mutation(s[0],m)
7: tmp_f←fitness(offSpring_s,dataSet)
8: hasBetter←false
9: lo←len(offSpring_s)
10: fo←tmp_f
11: for s in population do
12: ls←len(s[0])
13: fs←s[1]
14: if (fs>fo and ls<=lo) or (fs>=fo and ls<lo) then
15: hasBetter←true
16: break 17: end if
18: end for
19: if hasBetter==false then
20: Q←[]
21: for s in population do
22: ls←len(s[0])
23: fs←s[1]
24: if fo>=fs and lo<=ls then
25: continue
26: else
27: Q.append(s)
28: end if
29: end for
30: population←Q
31: population.append((offspring_s, tmp_f))
32: t←t+1
33: end while
34: result←choose_best(population, k)
35: return result
36: end function
- 71 -
哈尔滨工业大学工程硕士学位论文
消息接收处理部分的逻辑实现参考上述提到的四个业务流程,包括 file、
start、stop 以及 query 业务。具体业务流程不再叙述,该部分实现主要依据 Master
节点传递的消息关键字,通过识别不同的关键字,Slave 节点将执行不同的业务
处理逻辑。具体流程设计参考图 7-17。
7.4.2 可视化界面
本决策平台实现了一个简约的 Web 可视化界面,并通过浏览器向用户提供
SaaS 化的服务,可以方便用户进行任务的管理和控制操作。
该可视化的分代计算展示界面如图 7-18 所示,其中包括上传文件、开始运
行、结束运行、清空状态四个按钮,分别用于 file 业务、start 业务和 query 业
务、stop 业务以及数据的初始化,其中上传文件和开始运行都带有输入框,用
于计算初始化和参数的传递。
图 7-18 分代计算展示界面
通过前端页面的逻辑,我们将按钮执行顺序进行了锁定,例如只有执行完
了开始运行后,结束执行的按钮才会变得可用,同样在没有上传文件之前,页
- 72 -
哈尔滨工业大学工程硕士学位论文
面将不提供其他按钮的功能,以明确系统的执行过程,避免用户的操作失误。
而四个业务按钮栏下面是计算结果的展示部分,展示包括各个节点计算的实时
中间结果,以及总体的实时汇总结果,其中的属性包括总耗时、个体数、平均
每代耗时、最佳结果、最佳个体等。该可视化界面采用 Bootstrap、JS、Themeleaf
等技术实现数据绑定、消息交互以及页面优化,并使用 Jquery 的 ajax 技术实现
网页局部的数据实时更新。
7.4.3 平台测试
为了确保平台功能的正确性,我们进行了平台功能测试。主要通过用户界
面点击各个按钮的方式触发程序执行,观察界面是否输出预期的展示结果,用
以判断功能是否正确。测试流程即按照上传文件、开始运行、结束运行、清空
状态的顺序进行。
当前测试环境为 Linux 系统,测试系统启动一个 Master 节点容器和 2 个
Slave 节点容器作为测试条件。具体测试用例如表 7-8 所示。
表 7-8 平台测试用例
输入用例 预计输出 实际输出 测试结果
提示“文件上传
成功” 提示“文件上传
成功”系统上传
文件成功
上传数据文件 通过
计算代数:1000
问题规模:5
并行任务数:2
开始运行 提示“启动成功,
正在计算”,
页面实时展示 2个
任务的计算数据 提示“启动成功,
正在计算”,
页面实时展示个
体 1、个体 2以及
总体的计算数据
汇总结果
计算正确
通过
提示“启动成功,
将并行任务数改为 4,
重新开始运行 提示“启动成功,
正在计算”,
页面展示 4个任务
的计算数据 正在计算”,
页面展示 2个个体
实时计算数据,并
最后展示 4个任务 汇总结果
计算正确
通过
计算数据
- 73 -
哈尔滨工业大学工程硕士学位论文
表 7-8 (续表)
输入用例 预计输出 实际输出 测试结果
提示“计算已经停 提示“计算已经
结束运行 止”,页面显示最 停止”,页面显示 通过
终计算的数据 最终计算的数据
提示“数据清空完 提示“数据清空
清空状态 毕”,页面计算数 完毕”,页面计算 通过
据成功清空 数据成功清空
同时,为了验证本文提出的决策平台架构的合理性以及算法有效性,我们
进行了平台性能测试。我们主要通过测量系统的各项业务的页面服务响应时间
来可视化决策平台系统的性能指标,其中服务响应时间包括请求时间、后台处
理时间以及接收时间,而后台处理时间是作为业务耗时与否的关键。
这里的测试环境同样为 Linux 系统,测试系统启动一个 Master 节点容器以
及注册 30 个 Slave 节点容器,测试条件为同时执行 30 个演化计算子任务,即
每个节点分配一个子任务进行演化计算,各个条件下的四种业务均执行 30 次,
取平均算得一般响应时间,作为衡量业务性能的指标。各项子业务的服务响应
时间如表 7-9 所示,我们可以看到服务响应时间均在 200ms 以内,基本满足用
户对页面响应时间的最低要求。
表 7-9 业务服务响应时间表
业务服务名称 file start stop query
一般响应时间(ms) 62.2 148 177.9 154.1
Master 节点后台处理时间包括业务逻辑处理时间以及与 Slave 节点的 TCP
消息交互时间。在同一测试环境下,同样 30 个 Slave 节点、30 个子任务的条件
下,测得 30 次取平均值,得到各业务后台处理时间如表 7-10 所示,时间单位
均为 ms。其中 Logic 表示各个业务的平均逻辑处理时间,而 Net 表示各个业务
的中的平均 TCP 消息交互时间。
- 74 -
哈尔滨工业大学工程硕士学位论文
表 7-10 后台业务处理时间表
业务服务 file start stop query
Logic (ms) 10.24 23.71 9.44 0.12
Net (ms) 1.23 3.93 21.86 3.87
对于 Slave 节点来说,总体计算时间是作为衡量 Slave 节点计算性能的重要
指标。我们经过多次的实验测试发现, 每个 Slave 节点 1000 代的演化算法计
算总时间大概在 30 多秒。但是通过一些工具的优化,比如 numba、pypy3 等,
可以将计算总时间压缩到 10s 以内,提升了三倍的速度,显著提高了计算效率。
当然对于不同的算法或者语言平台上,优化方式也很多种,这里只作为一种典
型案例进行举例。
通过上述数据我们可以看到,基于前文的主从构架所构建的决策平台案例,
在使用过程中,具有良好的系统响应性能和优秀的并行计算性能,同时又满足
底层的算法选型以及语言平台的自定义要求,可以大幅度简化用户的控制操作、
提升系统执行效率,有着一定的实用价值。
7.5 本章小结
本章主要对三个子系统进行了实现和测试。首先是仓库管理系统的实现,
我们对包括系统管理、基本信息管理、库存管理、入库管理、出库管理这五个
模块的实现页面进行展示和描述,同时对系统主要功能和查询性能进行了黑盒
测试,测试结果显示该实现基本可以满足软件设计的预期需求;对于 RFID 中
间件的实现,我们从功能实现和可视化界面两个方面进行展示和描述,并按照
启动流程来对中间件的关键功能进行了测试,包括数据采集、处理、上传,测
试结果基本展示了该中间件功能的正确性和稳定性;在决策平台的实现上,我
们展示了 Master 节点、Slave 节点的部分功能实现以及平台的可视化界面,并
且对平台的主要功能和响应性能进行了测试,测试结果验证了平台架构的合理
性和功能的正确性。
- 75 -
哈尔滨工业大学工程硕士学位论文
结 论
本论文主要的研究内容是基于 RFID 的分布式物流仓储管理系统,该系统
包含仓库管理系统、RFID 中间件、决策平台这三个子系统。本文详细描述了
这三个子系统的设计与实现,并测试了各子系统部分模块功能和响应性能。主
要的研究成果如下:
(1)设计并实现了一种基于微服务架构的仓库管理系统,基于 RFID 技术
优化了实际的仓库管理业务,并且通过了软件测试,达到了预期的使用要求。
仓库管理系统包括入库、出库、盘点三大业务流程以及系统管理、基本信息管
理、库存管理、入库管理、出库管理五大功能模块。
(2)设计并开发了一种轻量型的 RFID 中间件,减少了冗余的功能模块,
完善了接口设计,并通过测试验证了功能的正确性。该中间件包括数据处理服
务模块以及数据访问服务模块这两大核心模块。
(3)分析并提出了一种用于物流决策平台的架构模型,完善了消息格式规
范,并进行了部分实现和测试,验证了架构的合理性和算法有效性。平台在逻
辑上包括 Master 和 Slave 两类节点,在业务上包含 file、start、stop、query 四
大业务流程。
(4)提出了使用 Docker 容器化技术进行系统分布式部署以及使用
Kubernetes 编排技术实现系统的维护和管理的方案,提升了系统的稳定性以及
可扩展性,同时也降低了系统的耦合程度。整个系统可以对外提供 SaaS 化的云
服务,显著降低了企业开发及维护成本。
本文所实现物流仓储管理系统有诸多优点:系统通过采用分布式架构将这
三个子系统整合到一起,不仅全面地完善了管理系统从数据采集和处理到任务
决策和管理的所有基本功能,而且还提升了系统的整体性能;系统采用 Docker
容器化技术进行搭建,有效屏蔽了系统底层实现的差异,并通过 Kubernetes 技
术进一步提升了系统的稳定性和扩展性;系统使用 SaaS 化的服务模式,极大降
低了企业和用户的使用和维护成本;此外,系统采用分层模式进行开发,结合
C/S 和 B/S 架构,简化了用户操作难度,有效地降低了企业的学习成本。
同时,鉴于自身能力和条件的不足,本系统也有许多的缺点,需要进一步
进行研究和改进:对于整体而言,我们仅仅进行了各个子系统的单独实现,而
- 76 -
哈尔滨工业大学工程硕士学位论文
在子系统之间的交互以及分布式整合部署方面还没有做很完善,因此未来在这
方面还需要进行补充和实践;在中间件的实现过程中,没有具体分析不同型号
阅读器所带来的交互差异的影响,因此在不同种类的设备上的交互实现还需要
完善,同时系统仅仅实现了主要的功能,全面性还不够,需进一步的研究和补
充;此外由于时间等原因,现有的系统部分功能的实现可能比较粗糙,还有很
多可以优化的地方,包括前端页面优化、后端逻辑优化、算法优化等等,这也
是系统后续改进的主要方向所在。
- 77 -
哈尔滨工业大学工程硕士学位论文
参考文献
[1] 蒋平. 2018 年中国仓储行业发展现状与投资前景分析[OL].[2019-08-28].
https://www.qianzhan.com/analyst/detail/220/180329-6b87f6fb.html
[2] 张明伟, 王欣兰. 中小企业仓储管理中存在的问题及对策研究[J]. 中外企
业家,2015(08):157-160.
[3] Nils B, Koster R, Felix W. Warehousing in the E-commerce Era: A Survey[J].
European Journal of Operational Research, 2019:396-411.
[4] Lim M K, Bahr W, Leung S C H. RFID in the Warehouse: A Literature
Analysis (1995–2010) of its Applications, Benefits, Challenges and Future
Trends[J]. International Journal of Production Economics, 145(1):409-430.
[5] 蒋峻, 唐日英. RFID 射频标签——取代条形码的一种方案[J]. 科技资
讯,2007(004):17-18.
[6] Al-Jaroodi J, Aziz J, Mohamed N. Middleware for RFID Systems : An
Overview[C]// IEEE International Computer Software & Applications
Conference. IEEE, 2009:154-159.
[7] Ding Z H, Li J T, Feng B, et al. Survey on RFID Middleware[J]. Computer
Engineering, 2006, 32(21):9-11.
[8] 张华, 魏臻. 无线射频识别技术 RFID 及其应用[J]. 安防科技, 2007,
000(010):48-50.
[9] 马庆容, 俞军, 张纲. 国内 RFID 应用及产业研究[J]. 中国集成电路,
2006(11):15-19.
[10] 罗春彬, 彭龑, 易彬. RFID 技术发展与应用综述[J]. 通信技术, 2009,
042(012):112-114.
[11] 翟虎林, 谭蓉. RFID 技术在京东物流中的应用研究[J]. 农村经济与科技,
2017, 028(016):80.
[12] 罗锦, 李然, 曾隽芳, 等. 基于 RFID 技术的血液管理系统研究与开发[J].
 计算机工程与应用, 2006(23):172-176.
[13] Hwang H S, Cho G S. A Performance Evaluation Model for Order Picking
 Warehouse Design[J]. Computers & Industrial Engineering, 2005, 51(2):
 335-342.
- 78 -
哈尔滨工业大学工程硕士学位论文
[14] Poon T C, Choy K L, Chow H K H, et al. A RFID Case-based Logistics
Resource Management System for Managing Order-picking Operations in
Warehouses[J]. Expert Systems with Applications, 2009, 36(4):8277-8301.
[15] Chan F T S, Chan H K. Improving the Productivity of Order Picking of a
Manual-pick and Multi-level Rack Distribution Warehouse through the
Implementation of Class-based Storage[J]. Expert Systems with Applications,
2010, 38(3):2686-2700.
[16] Gu J, Goetschalckx M, McGinnis L F. Research on Warehouse Operation: A
Comprehensive Review[J]. European Journal of Operational Research, 2006,
177(1):1-21.
[17] 肖建辉. 浅谈仓储管理[J]. 物流工程与管理, 2010, 32(6):130-132.
[18] 熊平. 基于 RFID 技术的仓库管理系统设计与实现[D]. 哈尔滨:哈尔滨工业
大学学位论文,2016:1-6.
[19] 杨峚. 基于 B/S 架构的仓库管理优化系统设计与实现[D]. 武汉:湖北工业大
学学位论文,2017:6-9.
[20] 郭剑英. 基于 RFID 的仓储管理系统的设计与实现[D]. 长春:吉林大学学位
论文,2015:2-5.
[21] 翁祖蓉. 基于 RFID 技术的企业仓库管理系统设计与实现[D]. 成都:电子科
技大学学位论文,2014:3-4.
[22] Luo C, Xu D D, Lai M Y, et al. Design and Implement of Warehouse
Management System Based on AOP[C]// IEEE International Engineering
Management Conference. IEEE, 2007:243-246.
[23] Liu P , Yao G Q , Cai H Y , et al. Design and Implementation of Warehouse
Management System Based on B/S Mode[C]// International Conference on
Computer Science & Applications. IEEE, 2015:146-150.
[24] 裘森林. 生产企业分布式仓库管理系统应用与研究[J]. 企业改革与管理,
2016, 000(015):216-218.
[25] 郭洪役, 郦苏丹. 由 IBM 和 BEA 的代表产品看 RFID 中间件[J]. 计算机与
信息技术, 2008(10):76-78.
[26] 孙剑, 陈琪明. RFID 中间件在世界及中国的发展现状[J]. 物流技术与应用,
2007, 12(2):98-101.
[27] 沈玮玮. 基于 RFID 中间件的数据清洗算法研究及系统实现[D]. 南京:南京
邮电大学学位论文,2017:3-5.
- 79 -
哈尔滨工业大学工程硕士学位论文
[28] 张翔. RFID 安全中间件关键技术研究与实现[D]. 成都:电子科技大学学位
论文,2014:1-6.
[29] 周悦. 基于 LLRP 协议的可扩展 RFID 中间件的研究与实现[D]. 北京:北京
交通大学学位论文,2014:2-3.
[30] 林凤群. 一种轻量型 RFID 中间件的研究[D]. 北京:清华大学学位论
文,2010:2-5.
[31] 贾红梅. 面向仓储管理的 RFID 中间件研究与应用[D]. 武汉:武汉科技大学
学位论文,2013:4-7.
[32] 应俊,王社周,吉福生.基于 ALE 规范的分布式 RFID 中间件研究与实现[J].
计算机应用与软件,2016,33(07):14-18.
[33] Tian W H, Xue R N, Dong X, et al. An Approach to Design and Implement
RFID Middleware System over Cloud Computing[J]. International Journal of
Distributed Sensor Networks,2013:2-10.
[34] Liu F G, Lin Y D, Ruan Y X, et al. Lightweight-ALE-Based Embedded RFID
Middleware[C]// International Conference on Wireless Communications,
Networking and Mobile Computing. IEEE, 2009:1-4.
[35] 王羽欣. 基于云物流服务平台的任务分配与物流配送研究[D]. 北京:北京
交通大学学位论文,2017:3-4.
[36] 毕娅, 梁晓磊, 赵韦, 等. 云物流模式下基于最大覆盖配送中心的选址—
分配问题研究[J]. 计算机应用研究, 2012, 29(10): 3640-3644.
[37] 姜春艳, 吴克寿. SaaS 模式下云物流服务平台架构设计[J]. 福建电脑,
2013,29(01):26-28.
[38] 万千惠. 基于云服务平台的物流资源调度模型研究[D]. 重庆:重庆邮电大
学学位论文, 2018:6-10.
[39] 陈昌豪. 基于计算机网络技术的智能物流决策系统[J]. 物流技术, 2015,
34(07):274-276.
[40] What is a Container? [OL]. [2019-08-28]. https://www.docker.com/resources/
what-container.
[41] 伍阳. 基于 Docker 的虚拟化技术研究[J]. 信息技术, 2016(01):121-123.
[42] Kubernetes Components [OL].[2019-08-28]. https://kubernetes.io/docs/
concepts/overview/components/.
- 80 -
哈尔滨工业大学工程硕士学位论文
[43] Bach R, Paley D, Tracey B, et al. The Application Level Events (ALE)
Specification [S/OL] . EPCgloabl, 2009 : 77-119. https : // www.gs1.org/sites/
default/files/docs/epc/ale_1_1_1-standard-core-20090313.pdf.
[44] Free and Open Source Softwore for Track and Trace (Fosstrak) [OL].
[2019-06-12]. https://fosstrak.github.io/index.html.
[45] Qian C , Shi J C , Yu Y , et al. Parallel Pareto Optimization for Subset
Selection[C]// Proceedings of the 24th International Joint Conference on
Artificial Intelligence (IJCAI 2016). 2016:1939-1945.
[46] Qian C, Li G Y, Feng C, et al. Distributed Pareto Optimization for Subset
Selection[C]// Proceedings of the 27th International Joint Conference on
Artificial Intelligence (IJCAI 2018).2018:1492-1498.
学术论文网提供数万篇的免费毕业论文、硕士论文、博士论文、sci论文发表的范文供您参考,并提供经济、管理、医学、法律、文学、教育、理工论文、mba作业、英语作业的论文辅导写作、发表等服务,团队实力雄厚,多达人,帮您解决一切论文烦恼。