智能仓库系统的研究与实现

狄宏林 （东莞开放大学，广东 东莞 523000）

0 引 言

近年来人工智能、大数据、云计算、物联网等技术的落地，对物流仓库数字化建设进程有着极大的推动作用，现代化仓储系统需要满足此背景下电子商务企业高效灵活的运营需求[1]，在国内仓库系统的数字化建设浪潮中，在国家政府的大力推进和各类政策的鼓励中，数字化、信息化、智能化的仓储管理系统的研究和探索也正逐步进入深水区，成为很多电子商务企业的信息化建设的重要组成部分[2]。目前中小企业中拥有的信息管理系统仅限于针对财务管理、人力资源管理、客户关系管理和企业官方信息网站，缺乏部分物流仓库管理所涉及的专业知识，现存的仓库信息管理系统也仅仅限于对整个仓库的业务流程管理，并没有和现有的ERP 系统等进行有效结合，相关的分配单和作业都需要人为的手动确认和分配，效率较低，并且自动化和智能化水平未达到企业要求，尤其是系统整站上云对团队和现存系统都是巨大的挑战。本文研究实现全流程管理的数字化智能仓库系统，对外提供Restful 风格的API，方便多个现存系统的集成，可以协同处理上下游的业务节点，充分利用微服务架构和定时任务进行自动派单以提升仓库的流转效率，减少仓库作业的人工错误，选择标准的云原生底座组件实现系统，为系统迁移到云厂商的环境提供一定的便利。

1 智能仓库系统分析

1.1 通用仓库业务流程

通用仓库业务流程分为入库、质检、上架、移库、盘点和出库。入库作业主要的业务流程为仓库接收到预到货通知单ASN，供应商将货物运抵仓库，仓库员工指引到空闲的月台进行卸货，并分类码货，货物分为散货与托盘货物，员工线下按ASN 清点货物后，打印货物标签后贴标然后使用RF 枪扫码入库，货物在收货区的状态为待上架。质检上架作业的主要业务流程为管理人员将货物分为免质检和待质检货物，将待质检货物单给员工，员工根据货物进行抽样质检并登记合格与否，合格的待质检货物才能上架，不合格的货物进行退订处理。上架由管理人员根据上架策略开具上架库位分配单，员工负责上架，上架完成后，货物放置在仓库对应库区的货架，状态为已上架。移库作业的主要业务流程分为有计划与无计划，有计划的移库通常用于大规模的批量库内移位，比如季节性的库位调整、大批量翻仓理货，首先管理人员生成移位单，员工按移位单进行移位，无计划的移位通常是有安全库存的限制必须补货，无需生成移位单，员工直接使用RF 枪扫货物和货架即可。此流程不会改变货物状态，仅仅改变了货物所属货架的属性。盘点作业的主要业务流程分为全盘、循环盘、明盘和盲盘，管理人员根据具体业务创建盘点单，员工进行盘点并登记，盘点登记允许重复多次，以最后一次为准，登记结束后，管理人员计算差异，有差异则需要报损或报盈处理。出库作业的主要业务流程为仓库接收到拣货单，通过拣货规则分配拣货单给员工，员工拣货完成后，按需进行打包作业，复核打包后，运送到备货库位，货物在备货区，状态为待发运。客户确认收货后，货物在物流车上，状态为已出库。货品从入库到出库的整个业务流程就结束了，其中涉及到财务核对的可以直接交予财务管理系统进行处理。

1.2 系统功能模块

智能仓库管理系统的主要用户有三类，一是仓库管理人员，二是仓库管理助理，三是库内作业人员。仓库管理人员在系统中负责员工、供应商、客户信息的维护，库存的规划、分配与盘点，入库和出库的单据审核与监管以及及时性的跟踪。仓库管理助理在系统中主要负责入库和出库信息的增加、查看、修改、删除、导出质检单和拣货单，移库计划管理查询、编辑、制定、修改、导出，库内的作业人员主要是负责根据管理人员或者管理助理通过系统下发的质检单和拣货单等进行库内货品的物理搬运和信息的修改。其中系统支持各个模块使用自动模式，如设置好质检货品的质检单可以自动下发，无需管理人员的审批、上架策略根据设定好的库存规划自动寻找空闲的库区下发上架库位分配单给作业人员、计划性的移库也支持自动生成移位单、货物盘点单支持自动生成且对接财务系统后可以自动对账、拣货单也支持根据设置的拣货规则自动下发给库内的作业人员。

系统内置的超级管理员拥有整个系统所有模块的操作权限，其他用户可以通过LDAP 的方式从其他的信息系统同步获得权限，或者具有管理员角色的用户进行创建和管理。仓库库位作为物理上存放实际货品的区域，在智能化的仓库管理系统中的作用非常重要，它的状态是整个业务流程都需要考虑的要素。在收货入库后，每个ASN 对应的收货明细会更新到系统中，后续的作业流程中造成的变更可以直接更新收货明细，如质检不合格到货破损数会实时更新，线下清点来货短少、多到货的数量。质检业务可以通过设置质检货品的质检单自动下发给库内的作业人员，无需管理人员的审批，也可以由管理人员或助理手动录入待质检的货品单。

质检管理管理的信息主要有：质检货品模板、待质检货品单号、货品编码、货品数量、所属库位、质检结果。质检货品模板中存放的是管理员设置的待质检的货品类型、货品品牌、货品产地、货品成本、货品价格等内容，例如：质检货品模板的货品类型为服装、货品品牌为贵人鸟、货品产地为浙江、货品成本大于500、货品价格大于1 000，那么当货品类型为服装且货品品牌为贵人鸟且货品产地为浙江且货品成本大于500 且货品价格大于1 000 时，货品就需要质检。质检货品的模板信息可以根据需要进行修改，当管理人员设置为自动下发时，仓库系统就会自动匹配质检货品的模板信息，下发给库内的作业人员，同时可以进行质检单的手动录入和下发。

上架业务可以同时使用自动和手动模式并下发给库内的作业人员，上架完成后，货物在仓库对应库区的货架，货品管理的货品状态显示为已上架，所属库位也随之更新，库位管理的库位剩余尺寸、库位剩余承重也需要更新。自动模式会根据空库位标识和库位剩余的尺寸、库位剩余承重来合理地分配上架的库位。

移库作业改变了货物管理中货物所属库位的属性，移库管理主要是移库计划管理的查询、删除、新增、修改、导出，移库计划本质上是一个定时任务，季节性的移库翻仓理货可以进行设定，线下移库作业完成后，库位管理的库位剩余尺寸、库位剩余承重的信息会同步更新。管理人员维护盘点的主要信息有盘点单号、盘点时间、盘点次数、盘点结果，盘点后会将当前的货品管理信息与财务系统通过API 进行数据核对，省去人工核对的过程。

当客户下订单后，系统会自动或手动生成对应的拣货单，货物可能是散货或托盘货物，仓库接收到拣货单，通过拣货规则下发拣货单，拣货规则有按订单先进先出、按波次拣货、按品类拣货等。库内作业员工拣货后，按需进行打包作业，运送到备货区，相关货品的状态显示为待发运。客户物流司机收货确认后，相关货品的状态显示为已出库。按订单先进先出的拣货规则适用于紧急需求可快速拣选、大批量的少品种拣选单的场景，按波次拣货适用于在一个时间段内订单爆发，货品类型较多且库位分散需要合并拣货单为一个波次的场景，按品类拣货适用于订单集中分布于某几个类型货品的场景。

2 智能仓库系统设计

2.1 微服务架构系统

现有的仓库系统是传统的单体MVC 的架构，在系统需要重构时无法将业务分层很好地扩展和迁移到云厂商的平台上，因此使用微服务架构来重新设计系统。微服务架构[3-8]的核心是服务治理，其关键是服务划分，（DDD，Domain-Driven Design）领域驱动的设计，其是一种拆解业务、划分业务、确定业务边界的通用方法论，它尽量从业务的视角去划分领域边界，领域指业务的某一个部分，例如仓库系统的入库、出库，DDD 将问题范围限定在了特定的边界内，在这个边界内建立领域模型，进而编码实现该领域模型，解决相应的业务问题。将领域进行进一步划分的问题域就是子域，所有领域中最关键的部分就是核心域。通用域指的是除了核心领域之外，还需要自己做的一些领域，例如鉴权、日志等，特点是可能被多个领域公用的域，支撑域则是在业务分析中仅仅为了支撑业务的正常运转而存在的[9]。微服务架构本质上是分布式系统架构，各个服务需要配合协同来完成系统的需求，下游服务直接单向依赖并使用上游服务，通过上游服务提供的Restful API[10]对上游服务的序列化数据进行读写操作，接口的实现需要考虑幂等性，如果不幂等，就不能影响下游的服务。微服务的架构可以很好地维持业务和代码的逻辑一致性。由于整个应用被DDD 划分为了多个微小的服务，服务与服务之间的技术选型灵活，可用性高，每个微小的应用服务可以独立开发、测试、构建和部署。如智能仓库系统的微服务的架构图，见图1。

如上图所示，客户端的类型主要是电脑和仓库作业时的手持设备，它们与系统的API 统一网关进行交互，由统一网关zuul进行统一调度。zuul 在云环境中提供了动态的路由、监控和安全等边缘服务。它的核心是一系列处理用户请求的过滤器，两两之间没有直接的通信，过滤器按用途分为PRE、ROUNTING、POST 和ERROR 四类，并通过Request Context 进行数据传递。PRE 用于身份验证、在云环境中选择请求的微服务和记录调试信息等；ROUNTING 用于将请求路由到具体的微服务，将使用Apache Http 或者Netflix Ribbon 请求微服务；POST 用于添加标准的HTTP 头部信息、统计指标将微服务的响应发送给对应的客户端等；ERROR 过滤器在其他步骤发生错误时执行。云计算中的中间层服务器的负载平衡和故障转移，云环境中的每个节点都至少有一个zuul Server 可以处理节点所在区域的故障，防止该区域的服务不可用。zuul 的另一个作用则是限流，保护微服务，防止缓存的雪崩。所有的用户请求在处理之前都需要一个可用的令牌，令牌以一定的速率加入队列中，队列满时，新的令牌就会直接被丢弃，利用这样的队列可以限制流量的突变。

请求被调度到具体的微服务后，由对应的微服务对请求进行处理，有效性比较敏感的数据调用都内聚封装到微服务的内部，即业务领域内，不要暴露给其他微服务的调用方，数据的缓存预处理和失效的策略也在业务领域内做处理，尽量减少微服务之间的rpc 的调用[11]。智能仓库系统涉及大量需要查询的场景，因此微服务与数据库层面的缓存是最容易且性价比相对较高的。缓存的实时性和一致性得不到完全的保证，如果使用实时将写入数据库的数据放入缓存，数据库的压力会达到最高，异步间隔地写入缓存就会存在不一致的问题。缓存雪崩的问题在统一网关zuul 中使用令牌生成的方式，可以限制流量实现一定程度的缓解，但该问题还是存在，缓存可以看作是数据库的一道“防火墙”，防止请求的数据大量的命中数据库，造成数据库宕机，影响整个系统的运行。针对缓存穿透[12]和缓存雪崩的情况，智能仓库系统使用布隆过滤器对缓存Key 校验，将缓存存储进行高可用的处理，热点数据定时更新避免自动失效。

每个微服务得益于现代容器和自动化运维技术的普及和应用，可以被视为SOA[13](Service-Oriented Architecture,面向服务的架构思想)的一个落地方案。其中的用户管理服务、入库服务、出库服务等方面都可以被不同的容器所管理、调度和编排，数据也可以根据网站的应用流量情况动态地分散在不同的数据库。日志、认证和鉴权的模块是基础服务模块，涉及整个应用的运维和安全，在业务上一般不会被独立拆分出来的，集中和外部化日志存储是个简单直接的方式，通过将运行在不同容器上的每个微服务的日志，跨节点、定期、集中发送给一个外部的存储位置，整个智能仓储系统可以直接从这个外部的存储位置去获取日志。由于每个微服务的运行日志都可能不同，因此需要将日志数据进行结构化处理，利用日志编码器生成JSON 结构的日志关联每个微服务的ID，以及所有微服务的的调用关系的关联ID，这样就可以跟踪每个微服务的日志。

2.2 Restful 风格接口

Restful 是Representational State Transfer 的缩写，直接可以翻译为表现层状态转化，使用GET、POST、PUT、DELETE4 个表示操作方式的动词来调用对象的操作方法，最终返回xml 或者是html 的格式的文件流，且不会记录每一次调用的状态信息，URI 中通常不会包含动词，只有名词，可以是对应的服务。其协议是HTTPs 类的协议，域名是专有的，统一版本管理API，使用子资源来表达资源间的关系，路径则是资源或者服务的对应路径，过滤信息则是在返回的结果数据量特别多的时候进行信息的预处理，一般是限制数据量、排序等。完整的Restful 是需要做到超媒体访问的，在请求后给出一个link 的描述信息，例如：{"link": { "rel":"xxx""href":"xxx","title": "xxx"，"type": "application/xml"}}rel 指的是与当前的API 的关系，href 指的是API 的路径，title 指的是API 的标题，type 指的是API 的返回类型，本文基于Rest 这样的一组架构约束条件和原则设计智能仓库系统的API 接口。

2.3 定时任务

系统中的入库流程自动拉取上游系统的ETL[14]数据库的预到货通知单信息，下发质检规则生成的质检单，下发库位上架单以及移库的任务单都是在无人值守时运行，系统需要定时任务管理的基础服务，首先需要一个管理控制台进行定时任务的发布，这个控制台可以是PC 的网页也可以是手持设备的界面，系统对这些定时任务[15]进行管理和调度，等到了设置好的时间点就把执行指令下发到对应进程上。任务发布需要指定任务的执行单元和路径，任务单元一般是实现某个公共的统一接口，同时需要配置执行进程的环境、资源和资源的预处理，到了执行时间就执行，如果不指定任务的执行节点集群，就随机指定节点和集群执行；有了任务如何调度任务呢，比如明天的11 点59 分59 秒有一个拉取上游数据的任务需要运行，从操作系统的角度就是设置定时器的初始值，每次时钟震荡的时侯减1，当减到0 的时候触发一个硬件中断执行的某个回调方法，执行注册到该回调方法的任务；调度执行的时候远程调用框架，调用具体的执行指令，调度器需要维护好所有执行器的状态，并做到负载的均衡，避免出现把所有的执行指令调度到同一个执行器上进行定时任务的执行等情况，另外大的作业任务需要分片，根据时间或其他数据进行分片到多个节点执行任务的运行。智能仓库系统可以将定时任务分为三个部分：作业、任务和触发器，任务和触发器都是隶属于作业的。任务是有类型的，可以扩展用来实现其他的系统任务。触发器是用来定义触发条件的，例如质检的货品或时间等限制。包括时间触发，手动运行、运行一次、每天、每周、每月、定制，以及条件触发，单触发器、多触发器。一个作业包含时间条件、触发器、任务以及后续任务等。当前的作业运行完，就会运行后续作业，多个后续作业是并行运行的，且其中一个后续作业的运行失败不会影响其他作业的运行，很好地保证了仓库系统的可用性。

3 智能仓库系统实现

3.1 入库实现

入库管理的预到货通知单ASN 支持手工输入、excel 导入审核后支持打印入库清单。系统使用easyexcel[16]来导入入库的数据，ExcelWriterBuilder 创建出ReadWorkbook、WriteWorkbook、ReadSheet、WriteSheet 对象，excelAnalyser 使用XlsxSaxAnalyser解析excel 文件的每个sheet 页中的每个格子的数据。ReadListener 会在每行读取完后调用回调方法来处理数据WriteHandler 在每一个操作包括创建单元格、创建表格等都会调用回调方式来处理数据。导入excel 的方法的注解和签名为：

@PostMapping(“/stock/excel”)

public List＜Object＞ stockExcel(@RequestParam(“stockExcel”) MultipartFile stockExcel,Model model,Class clazz){

List＜Object＞ res=new ArrayList＜＞();

InputStream is=null;

Sheet sheet=null;

try {

is=new FileInputStream(stockExcel.getAbsolutePath());

if (is !=null) {

Workbook workbook=WorkbookFactory.create(is);

sheet=workbook.getSheetAt(0);

if (sheet !=null) {

int i=2;

String values[];

Row row=sheet.getRow(i);

while (row !=null) {

int cellNum=row.getPhysicalNumberOfCells();

values=new String[cellNum];

for (int j=0;j ＜=cellNum;j++) {

Cell cell=row.getCell(j);

if (cell !=null) {

cell.setCellType(Cell.CELL_TYPE_STRING);

String value=cell.getStringCellValue()==null ? null : cell.getStringCellValue();

values[j]=value;

}

}

Field[]fields=clazz.getDeclaredFields();

Object obj=clazz.newInstance();

for(Field f : fields){

if(f.isAnnotationPresent(ImportIndex.class)){

ImportIndex annotation=f.getDeclaredAnnotation(ImportIndex.class);

int index=annotation.index();

f.setAccessible(true);

Object val=TypeUtils.cast(values[index],f.getType(),null);

f.set(obj,val);

}

}

res.add(obj);

i++;

row=sheet.getRow(i);

}

}

}

} catch (Exception e) {

e.printStackTrace();

}

return res;

}

入库管理的表结构如表1所示。

表1 入库的表结构

3.2 质检实现

质检管理对需要质检的货品进行质检后上架，质检模板的触发器的具体实现是指定触发条件，将该触发条件存储在数据库对应的schedulerjobtrgger 表中,每隔一段时间就去检测条件是否满足质检的模板，当满足后，就执行下发质检单的任务，并可以添加多个触发器，并编辑触发器的“与”“或”关系。质检管理表结构如表2所示。

表2 质检的表结构

3.3 上架实现

上架管理这个业务流程需要修改库存的信息，库位的剩余尺寸和剩余承重要减少，相应的货品的所属库位也要更新，货品信息的表结构如表3所示。

3.4 移库实现

移库管理需要更新两个库位的信息以及所属货品的信息，移库信息的自动更新可以使用WebSocket 的推送功能，借用HTTP 将协议转换成为Upgrade 首部所列的协议来达到协议转换，从HTTP 协议切换成WebSocket 通信协议,移库管理的表结构如表4所示。

表4 移库的表结构

3.5 盘点实现

管理员手动创建好盘点计划并维护好表中的数据，到了盘点的指定时间，系统会自动地向库内作业人员下发指令进行盘点，盘点管理的表结构如表5所示。

表5 盘点管理的表结构

3.6 出库实现

收到客户的订单后系统自动生成出货单，拣货出库管理的表结构如表6所示。

表6 出库的表结构

4 智能仓库系统测试

4.1 功能测试

开发完成的系统需要部署到对应的服务器环境中，本文使用的是阿里云服务器ECS，具体的生产环境配置是6 核CPU、62G 内存120G 系统盘、64 位CentOS7.2 的公共镜像、1Mbps 的公网带宽。数据库采用阿里云的RDS，系统使用war 包部署在中间件tomcat 上，修改默认的开启和关闭的端口以提高安全性，RDS 上既有业务资源的库也有审计信息的库，部署的架构图如图2所示。

将系统打为war 包之后，分别部署到两个ECS 上，联机服务器负责主要的仓库业务，管理台服务器负责后台管理主要和数据库进行交互，业务服务器多读少写，因此主要和redis 的缓存集群服务进行交互。逻辑上springboot 的集群作为整个系统与其他的缓存服务以及数据库进行交互。

智能仓库系统功能性的测试主要对需求中的模块进行大功能模块的用户UAT 环境测试，测试的模块和最终的结果如表7所示。

4.2 非功能测试

非功能性的测试主要对高并发下的UAT 环境进行测试，选取的工具是jmeter[17]，智能仓库系统存在多用户操作，大数据量操作的特征。测试中将针对这些多用户操作，大数据量查询等进行如基准、负载、压力、稳定性和健壮性等方面的性能测试，检查并评估在模拟环境中，系统对负载的承受能力，以及在不同的用户连接情况下，系统的吞吐能力和响应能力。通过基准测试，验证测试脚本及后台环境、初步检查事务本身是否存在性能缺陷。通过负载测试，获得各被测事务在不同请求负载下的处理能力、响应时间等性能指标，并分析其性能拐点。通过混合压力测试，在被测系统上不断增加压力，获取系统的最大事务处理能力，并依据压力变化的趋势，分析系统性能瓶颈。通过对比测试，对功能等方面进行对比分析，为系统的进一步优化提供数据参考。测试的软硬件配置如表8所示。

表8 测试的软硬件配置

对50 用户、100 用户和500 用户在10 分钟内不断地对系统模拟压测得到的各个模块的TPS 和响应时间如表9。

表9 系统模拟压测各模块TPS 和响应时间

从表9可以看到在被测系统上不断增加压力后，货品管理的系统吞吐量TPS 下降，响应时间增长的比较高，其余模块的吞吐量和响应时间均在预期的接受范围。

5 结 语

企业运营需要智能仓库系统对仓储管理的流程进行智能化的全流程管理，做到完全的数字化、自动化和智能化，本文对通用的物流仓库业务流程分析研究后，实现构建了全流程管理的数字化智能仓库系统，它对外统一提供Restful 风格的API 接口，方便其他系统直接调用，系统使用微服务的方式进行面对对象的设计，可以灵活快速地响应业务的变化，利用定时任务模块，进行自动派单提升了员工的工作效率。