狄宏林 （東莞開放大學(xué)，廣東 東莞 523000）

0 引 言

近年來人工智能、大數(shù)據(jù)、云計(jì)算、物聯(lián)網(wǎng)等技術(shù)的落地，對(duì)物流倉(cāng)庫(kù)數(shù)字化建設(shè)進(jìn)程有著極大的推動(dòng)作用，現(xiàn)代化倉(cāng)儲(chǔ)系統(tǒng)需要滿足此背景下電子商務(wù)企業(yè)高效靈活的運(yùn)營(yíng)需求[1]，在國(guó)內(nèi)倉(cāng)庫(kù)系統(tǒng)的數(shù)字化建設(shè)浪潮中，在國(guó)家政府的大力推進(jìn)和各類政策的鼓勵(lì)中，數(shù)字化、信息化、智能化的倉(cāng)儲(chǔ)管理系統(tǒng)的研究和探索也正逐步進(jìn)入深水區(qū)，成為很多電子商務(wù)企業(yè)的信息化建設(shè)的重要組成部分[2]。目前中小企業(yè)中擁有的信息管理系統(tǒng)僅限于針對(duì)財(cái)務(wù)管理、人力資源管理、客戶關(guān)系管理和企業(yè)官方信息網(wǎng)站，缺乏部分物流倉(cāng)庫(kù)管理所涉及的專業(yè)知識(shí)，現(xiàn)存的倉(cāng)庫(kù)信息管理系統(tǒng)也僅僅限于對(duì)整個(gè)倉(cāng)庫(kù)的業(yè)務(wù)流程管理，并沒有和現(xiàn)有的ERP 系統(tǒng)等進(jìn)行有效結(jié)合，相關(guān)的分配單和作業(yè)都需要人為的手動(dòng)確認(rèn)和分配，效率較低，并且自動(dòng)化和智能化水平未達(dá)到企業(yè)要求，尤其是系統(tǒng)整站上云對(duì)團(tuán)隊(duì)和現(xiàn)存系統(tǒng)都是巨大的挑戰(zhàn)。本文研究實(shí)現(xiàn)全流程管理的數(shù)字化智能倉(cāng)庫(kù)系統(tǒng)，對(duì)外提供Restful 風(fēng)格的API，方便多個(gè)現(xiàn)存系統(tǒng)的集成，可以協(xié)同處理上下游的業(yè)務(wù)節(jié)點(diǎn)，充分利用微服務(wù)架構(gòu)和定時(shí)任務(wù)進(jìn)行自動(dòng)派單以提升倉(cāng)庫(kù)的流轉(zhuǎn)效率，減少倉(cāng)庫(kù)作業(yè)的人工錯(cuò)誤，選擇標(biāo)準(zhǔn)的云原生底座組件實(shí)現(xiàn)系統(tǒng)，為系統(tǒng)遷移到云廠商的環(huán)境提供一定的便利。

1 智能倉(cāng)庫(kù)系統(tǒng)分析

1.1 通用倉(cāng)庫(kù)業(yè)務(wù)流程

通用倉(cāng)庫(kù)業(yè)務(wù)流程分為入庫(kù)、質(zhì)檢、上架、移庫(kù)、盤點(diǎn)和出庫(kù)。入庫(kù)作業(yè)主要的業(yè)務(wù)流程為倉(cāng)庫(kù)接收到預(yù)到貨通知單ASN，供應(yīng)商將貨物運(yùn)抵倉(cāng)庫(kù)，倉(cāng)庫(kù)員工指引到空閑的月臺(tái)進(jìn)行卸貨，并分類碼貨，貨物分為散貨與托盤貨物，員工線下按ASN 清點(diǎn)貨物后，打印貨物標(biāo)簽后貼標(biāo)然后使用RF 槍掃碼入庫(kù)，貨物在收貨區(qū)的狀態(tài)為待上架。質(zhì)檢上架作業(yè)的主要業(yè)務(wù)流程為管理人員將貨物分為免質(zhì)檢和待質(zhì)檢貨物，將待質(zhì)檢貨物單給員工，員工根據(jù)貨物進(jìn)行抽樣質(zhì)檢并登記合格與否，合格的待質(zhì)檢貨物才能上架，不合格的貨物進(jìn)行退訂處理。上架由管理人員根據(jù)上架策略開具上架庫(kù)位分配單，員工負(fù)責(zé)上架，上架完成后，貨物放置在倉(cāng)庫(kù)對(duì)應(yīng)庫(kù)區(qū)的貨架，狀態(tài)為已上架。移庫(kù)作業(yè)的主要業(yè)務(wù)流程分為有計(jì)劃與無計(jì)劃，有計(jì)劃的移庫(kù)通常用于大規(guī)模的批量庫(kù)內(nèi)移位，比如季節(jié)性的庫(kù)位調(diào)整、大批量翻倉(cāng)理貨，首先管理人員生成移位單，員工按移位單進(jìn)行移位，無計(jì)劃的移位通常是有安全庫(kù)存的限制必須補(bǔ)貨，無需生成移位單，員工直接使用RF 槍掃貨物和貨架即可。此流程不會(huì)改變貨物狀態(tài)，僅僅改變了貨物所屬貨架的屬性。盤點(diǎn)作業(yè)的主要業(yè)務(wù)流程分為全盤、循環(huán)盤、明盤和盲盤，管理人員根據(jù)具體業(yè)務(wù)創(chuàng)建盤點(diǎn)單，員工進(jìn)行盤點(diǎn)并登記，盤點(diǎn)登記允許重復(fù)多次，以最后一次為準(zhǔn)，登記結(jié)束后，管理人員計(jì)算差異，有差異則需要報(bào)損或報(bào)盈處理。出庫(kù)作業(yè)的主要業(yè)務(wù)流程為倉(cāng)庫(kù)接收到揀貨單，通過揀貨規(guī)則分配揀貨單給員工，員工揀貨完成后，按需進(jìn)行打包作業(yè)，復(fù)核打包后，運(yùn)送到備貨庫(kù)位，貨物在備貨區(qū)，狀態(tài)為待發(fā)運(yùn)?？蛻舸_認(rèn)收貨后，貨物在物流車上，狀態(tài)為已出庫(kù)。貨品從入庫(kù)到出庫(kù)的整個(gè)業(yè)務(wù)流程就結(jié)束了，其中涉及到財(cái)務(wù)核對(duì)的可以直接交予財(cái)務(wù)管理系統(tǒng)進(jìn)行處理。

1.2 系統(tǒng)功能模塊

智能倉(cāng)庫(kù)管理系統(tǒng)的主要用戶有三類，一是倉(cāng)庫(kù)管理人員，二是倉(cāng)庫(kù)管理助理，三是庫(kù)內(nèi)作業(yè)人員。倉(cāng)庫(kù)管理人員在系統(tǒng)中負(fù)責(zé)員工、供應(yīng)商、客戶信息的維護(hù)，庫(kù)存的規(guī)劃、分配與盤點(diǎn)，入庫(kù)和出庫(kù)的單據(jù)審核與監(jiān)管以及及時(shí)性的跟蹤。倉(cāng)庫(kù)管理助理在系統(tǒng)中主要負(fù)責(zé)入庫(kù)和出庫(kù)信息的增加、查看、修改、刪除、導(dǎo)出質(zhì)檢單和揀貨單，移庫(kù)計(jì)劃管理查詢、編輯、制定、修改、導(dǎo)出，庫(kù)內(nèi)的作業(yè)人員主要是負(fù)責(zé)根據(jù)管理人員或者管理助理通過系統(tǒng)下發(fā)的質(zhì)檢單和揀貨單等進(jìn)行庫(kù)內(nèi)貨品的物理搬運(yùn)和信息的修改。其中系統(tǒng)支持各個(gè)模塊使用自動(dòng)模式，如設(shè)置好質(zhì)檢貨品的質(zhì)檢單可以自動(dòng)下發(fā)，無需管理人員的審批、上架策略根據(jù)設(shè)定好的庫(kù)存規(guī)劃自動(dòng)尋找空閑的庫(kù)區(qū)下發(fā)上架庫(kù)位分配單給作業(yè)人員、計(jì)劃性的移庫(kù)也支持自動(dòng)生成移位單、貨物盤點(diǎn)單支持自動(dòng)生成且對(duì)接財(cái)務(wù)系統(tǒng)后可以自動(dòng)對(duì)賬、揀貨單也支持根據(jù)設(shè)置的揀貨規(guī)則自動(dòng)下發(fā)給庫(kù)內(nèi)的作業(yè)人員。

系統(tǒng)內(nèi)置的超級(jí)管理員擁有整個(gè)系統(tǒng)所有模塊的操作權(quán)限，其他用戶可以通過LDAP 的方式從其他的信息系統(tǒng)同步獲得權(quán)限，或者具有管理員角色的用戶進(jìn)行創(chuàng)建和管理。倉(cāng)庫(kù)庫(kù)位作為物理上存放實(shí)際貨品的區(qū)域，在智能化的倉(cāng)庫(kù)管理系統(tǒng)中的作用非常重要，它的狀態(tài)是整個(gè)業(yè)務(wù)流程都需要考慮的要素。在收貨入庫(kù)后，每個(gè)ASN 對(duì)應(yīng)的收貨明細(xì)會(huì)更新到系統(tǒng)中，后續(xù)的作業(yè)流程中造成的變更可以直接更新收貨明細(xì)，如質(zhì)檢不合格到貨破損數(shù)會(huì)實(shí)時(shí)更新，線下清點(diǎn)來貨短少、多到貨的數(shù)量。質(zhì)檢業(yè)務(wù)可以通過設(shè)置質(zhì)檢貨品的質(zhì)檢單自動(dòng)下發(fā)給庫(kù)內(nèi)的作業(yè)人員，無需管理人員的審批，也可以由管理人員或助理手動(dòng)錄入待質(zhì)檢的貨品單。

質(zhì)檢管理管理的信息主要有：質(zhì)檢貨品模板、待質(zhì)檢貨品單號(hào)、貨品編碼、貨品數(shù)量、所屬庫(kù)位、質(zhì)檢結(jié)果。質(zhì)檢貨品模板中存放的是管理員設(shè)置的待質(zhì)檢的貨品類型、貨品品牌、貨品產(chǎn)地、貨品成本、貨品價(jià)格等內(nèi)容，例如：質(zhì)檢貨品模板的貨品類型為服裝、貨品品牌為貴人鳥、貨品產(chǎn)地為浙江、貨品成本大于500、貨品價(jià)格大于1 000，那么當(dāng)貨品類型為服裝且貨品品牌為貴人鳥且貨品產(chǎn)地為浙江且貨品成本大于500 且貨品價(jià)格大于1 000 時(shí)，貨品就需要質(zhì)檢。質(zhì)檢貨品的模板信息可以根據(jù)需要進(jìn)行修改，當(dāng)管理人員設(shè)置為自動(dòng)下發(fā)時(shí)，倉(cāng)庫(kù)系統(tǒng)就會(huì)自動(dòng)匹配質(zhì)檢貨品的模板信息，下發(fā)給庫(kù)內(nèi)的作業(yè)人員，同時(shí)可以進(jìn)行質(zhì)檢單的手動(dòng)錄入和下發(fā)。

上架業(yè)務(wù)可以同時(shí)使用自動(dòng)和手動(dòng)模式并下發(fā)給庫(kù)內(nèi)的作業(yè)人員，上架完成后，貨物在倉(cāng)庫(kù)對(duì)應(yīng)庫(kù)區(qū)的貨架，貨品管理的貨品狀態(tài)顯示為已上架，所屬庫(kù)位也隨之更新，庫(kù)位管理的庫(kù)位剩余尺寸、庫(kù)位剩余承重也需要更新。自動(dòng)模式會(huì)根據(jù)空庫(kù)位標(biāo)識(shí)和庫(kù)位剩余的尺寸、庫(kù)位剩余承重來合理地分配上架的庫(kù)位。

移庫(kù)作業(yè)改變了貨物管理中貨物所屬庫(kù)位的屬性，移庫(kù)管理主要是移庫(kù)計(jì)劃管理的查詢、刪除、新增、修改、導(dǎo)出，移庫(kù)計(jì)劃本質(zhì)上是一個(gè)定時(shí)任務(wù)，季節(jié)性的移庫(kù)翻倉(cāng)理貨可以進(jìn)行設(shè)定，線下移庫(kù)作業(yè)完成后，庫(kù)位管理的庫(kù)位剩余尺寸、庫(kù)位剩余承重的信息會(huì)同步更新。管理人員維護(hù)盤點(diǎn)的主要信息有盤點(diǎn)單號(hào)、盤點(diǎn)時(shí)間、盤點(diǎn)次數(shù)、盤點(diǎn)結(jié)果，盤點(diǎn)后會(huì)將當(dāng)前的貨品管理信息與財(cái)務(wù)系統(tǒng)通過API 進(jìn)行數(shù)據(jù)核對(duì)，省去人工核對(duì)的過程。

當(dāng)客戶下訂單后，系統(tǒng)會(huì)自動(dòng)或手動(dòng)生成對(duì)應(yīng)的揀貨單，貨物可能是散貨或托盤貨物，倉(cāng)庫(kù)接收到揀貨單，通過揀貨規(guī)則下發(fā)揀貨單，揀貨規(guī)則有按訂單先進(jìn)先出、按波次揀貨、按品類揀貨等。庫(kù)內(nèi)作業(yè)員工揀貨后，按需進(jìn)行打包作業(yè)，運(yùn)送到備貨區(qū)，相關(guān)貨品的狀態(tài)顯示為待發(fā)運(yùn)?？蛻粑锪魉緳C(jī)收貨確認(rèn)后，相關(guān)貨品的狀態(tài)顯示為已出庫(kù)。按訂單先進(jìn)先出的揀貨規(guī)則適用于緊急需求可快速揀選、大批量的少品種揀選單的場(chǎng)景，按波次揀貨適用于在一個(gè)時(shí)間段內(nèi)訂單爆發(fā)，貨品類型較多且?guī)煳环稚⑿枰喜泦螢橐粋€(gè)波次的場(chǎng)景，按品類揀貨適用于訂單集中分布于某幾個(gè)類型貨品的場(chǎng)景。

2 智能倉(cāng)庫(kù)系統(tǒng)設(shè)計(jì)

2.1 微服務(wù)架構(gòu)系統(tǒng)

現(xiàn)有的倉(cāng)庫(kù)系統(tǒng)是傳統(tǒng)的單體MVC 的架構(gòu)，在系統(tǒng)需要重構(gòu)時(shí)無法將業(yè)務(wù)分層很好地?cái)U(kuò)展和遷移到云廠商的平臺(tái)上，因此使用微服務(wù)架構(gòu)來重新設(shè)計(jì)系統(tǒng)。微服務(wù)架構(gòu)[3-8]的核心是服務(wù)治理，其關(guān)鍵是服務(wù)劃分，（DDD，Domain-Driven Design）領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)，其是一種拆解業(yè)務(wù)、劃分業(yè)務(wù)、確定業(yè)務(wù)邊界的通用方法論，它盡量從業(yè)務(wù)的視角去劃分領(lǐng)域邊界，領(lǐng)域指業(yè)務(wù)的某一個(gè)部分，例如倉(cāng)庫(kù)系統(tǒng)的入庫(kù)、出庫(kù)，DDD 將問題范圍限定在了特定的邊界內(nèi)，在這個(gè)邊界內(nèi)建立領(lǐng)域模型，進(jìn)而編碼實(shí)現(xiàn)該領(lǐng)域模型，解決相應(yīng)的業(yè)務(wù)問題。將領(lǐng)域進(jìn)行進(jìn)一步劃分的問題域就是子域，所有領(lǐng)域中最關(guān)鍵的部分就是核心域。通用域指的是除了核心領(lǐng)域之外，還需要自己做的一些領(lǐng)域，例如鑒權(quán)、日志等，特點(diǎn)是可能被多個(gè)領(lǐng)域公用的域，支撐域則是在業(yè)務(wù)分析中僅僅為了支撐業(yè)務(wù)的正常運(yùn)轉(zhuǎn)而存在的[9]。微服務(wù)架構(gòu)本質(zhì)上是分布式系統(tǒng)架構(gòu)，各個(gè)服務(wù)需要配合協(xié)同來完成系統(tǒng)的需求，下游服務(wù)直接單向依賴并使用上游服務(wù)，通過上游服務(wù)提供的Restful API[10]對(duì)上游服務(wù)的序列化數(shù)據(jù)進(jìn)行讀寫操作，接口的實(shí)現(xiàn)需要考慮冪等性，如果不冪等，就不能影響下游的服務(wù)。微服務(wù)的架構(gòu)可以很好地維持業(yè)務(wù)和代碼的邏輯一致性。由于整個(gè)應(yīng)用被DDD 劃分為了多個(gè)微小的服務(wù)，服務(wù)與服務(wù)之間的技術(shù)選型靈活，可用性高，每個(gè)微小的應(yīng)用服務(wù)可以獨(dú)立開發(fā)、測(cè)試、構(gòu)建和部署。如智能倉(cāng)庫(kù)系統(tǒng)的微服務(wù)的架構(gòu)圖，見圖1。

如上圖所示，客戶端的類型主要是電腦和倉(cāng)庫(kù)作業(yè)時(shí)的手持設(shè)備，它們與系統(tǒng)的API 統(tǒng)一網(wǎng)關(guān)進(jìn)行交互，由統(tǒng)一網(wǎng)關(guān)zuul進(jìn)行統(tǒng)一調(diào)度。zuul 在云環(huán)境中提供了動(dòng)態(tài)的路由、監(jiān)控和安全等邊緣服務(wù)。它的核心是一系列處理用戶請(qǐng)求的過濾器，兩兩之間沒有直接的通信，過濾器按用途分為PRE、ROUNTING、POST 和ERROR 四類，并通過Request Context 進(jìn)行數(shù)據(jù)傳遞。PRE 用于身份驗(yàn)證、在云環(huán)境中選擇請(qǐng)求的微服務(wù)和記錄調(diào)試信息等；ROUNTING 用于將請(qǐng)求路由到具體的微服務(wù)，將使用Apache Http 或者Netflix Ribbon 請(qǐng)求微服務(wù)；POST 用于添加標(biāo)準(zhǔn)的HTTP 頭部信息、統(tǒng)計(jì)指標(biāo)將微服務(wù)的響應(yīng)發(fā)送給對(duì)應(yīng)的客戶端等；ERROR 過濾器在其他步驟發(fā)生錯(cuò)誤時(shí)執(zhí)行。云計(jì)算中的中間層服務(wù)器的負(fù)載平衡和故障轉(zhuǎn)移，云環(huán)境中的每個(gè)節(jié)點(diǎn)都至少有一個(gè)zuul Server 可以處理節(jié)點(diǎn)所在區(qū)域的故障，防止該區(qū)域的服務(wù)不可用。zuul 的另一個(gè)作用則是限流，保護(hù)微服務(wù)，防止緩存的雪崩。所有的用戶請(qǐng)求在處理之前都需要一個(gè)可用的令牌，令牌以一定的速率加入隊(duì)列中，隊(duì)列滿時(shí)，新的令牌就會(huì)直接被丟棄，利用這樣的隊(duì)列可以限制流量的突變。

請(qǐng)求被調(diào)度到具體的微服務(wù)后，由對(duì)應(yīng)的微服務(wù)對(duì)請(qǐng)求進(jìn)行處理，有效性比較敏感的數(shù)據(jù)調(diào)用都內(nèi)聚封裝到微服務(wù)的內(nèi)部，即業(yè)務(wù)領(lǐng)域內(nèi)，不要暴露給其他微服務(wù)的調(diào)用方，數(shù)據(jù)的緩存預(yù)處理和失效的策略也在業(yè)務(wù)領(lǐng)域內(nèi)做處理，盡量減少微服務(wù)之間的rpc 的調(diào)用[11]。智能倉(cāng)庫(kù)系統(tǒng)涉及大量需要查詢的場(chǎng)景，因此微服務(wù)與數(shù)據(jù)庫(kù)層面的緩存是最容易且性價(jià)比相對(duì)較高的。緩存的實(shí)時(shí)性和一致性得不到完全的保證，如果使用實(shí)時(shí)將寫入數(shù)據(jù)庫(kù)的數(shù)據(jù)放入緩存，數(shù)據(jù)庫(kù)的壓力會(huì)達(dá)到最高，異步間隔地寫入緩存就會(huì)存在不一致的問題。緩存雪崩的問題在統(tǒng)一網(wǎng)關(guān)zuul 中使用令牌生成的方式，可以限制流量實(shí)現(xiàn)一定程度的緩解，但該問題還是存在，緩存可以看作是數(shù)據(jù)庫(kù)的一道“防火墻”，防止請(qǐng)求的數(shù)據(jù)大量的命中數(shù)據(jù)庫(kù)，造成數(shù)據(jù)庫(kù)宕機(jī)，影響整個(gè)系統(tǒng)的運(yùn)行。針對(duì)緩存穿透[12]和緩存雪崩的情況，智能倉(cāng)庫(kù)系統(tǒng)使用布隆過濾器對(duì)緩存Key 校驗(yàn)，將緩存存儲(chǔ)進(jìn)行高可用的處理，熱點(diǎn)數(shù)據(jù)定時(shí)更新避免自動(dòng)失效。

每個(gè)微服務(wù)得益于現(xiàn)代容器和自動(dòng)化運(yùn)維技術(shù)的普及和應(yīng)用，可以被視為SOA[13](Service-Oriented Architecture,面向服務(wù)的架構(gòu)思想)的一個(gè)落地方案。其中的用戶管理服務(wù)、入庫(kù)服務(wù)、出庫(kù)服務(wù)等方面都可以被不同的容器所管理、調(diào)度和編排，數(shù)據(jù)也可以根據(jù)網(wǎng)站的應(yīng)用流量情況動(dòng)態(tài)地分散在不同的數(shù)據(jù)庫(kù)。日志、認(rèn)證和鑒權(quán)的模塊是基礎(chǔ)服務(wù)模塊，涉及整個(gè)應(yīng)用的運(yùn)維和安全，在業(yè)務(wù)上一般不會(huì)被獨(dú)立拆分出來的，集中和外部化日志存儲(chǔ)是個(gè)簡(jiǎn)單直接的方式，通過將運(yùn)行在不同容器上的每個(gè)微服務(wù)的日志，跨節(jié)點(diǎn)、定期、集中發(fā)送給一個(gè)外部的存儲(chǔ)位置，整個(gè)智能倉(cāng)儲(chǔ)系統(tǒng)可以直接從這個(gè)外部的存儲(chǔ)位置去獲取日志。由于每個(gè)微服務(wù)的運(yùn)行日志都可能不同，因此需要將日志數(shù)據(jù)進(jìn)行結(jié)構(gòu)化處理，利用日志編碼器生成JSON 結(jié)構(gòu)的日志關(guān)聯(lián)每個(gè)微服務(wù)的ID，以及所有微服務(wù)的的調(diào)用關(guān)系的關(guān)聯(lián)ID，這樣就可以跟蹤每個(gè)微服務(wù)的日志。

2.2 Restful 風(fēng)格接口

Restful 是Representational State Transfer 的縮寫，直接可以翻譯為表現(xiàn)層狀態(tài)轉(zhuǎn)化，使用GET、POST、PUT、DELETE4 個(gè)表示操作方式的動(dòng)詞來調(diào)用對(duì)象的操作方法，最終返回xml 或者是html 的格式的文件流，且不會(huì)記錄每一次調(diào)用的狀態(tài)信息，URI 中通常不會(huì)包含動(dòng)詞，只有名詞，可以是對(duì)應(yīng)的服務(wù)。其協(xié)議是HTTPs 類的協(xié)議，域名是專有的，統(tǒng)一版本管理API，使用子資源來表達(dá)資源間的關(guān)系，路徑則是資源或者服務(wù)的對(duì)應(yīng)路徑，過濾信息則是在返回的結(jié)果數(shù)據(jù)量特別多的時(shí)候進(jìn)行信息的預(yù)處理，一般是限制數(shù)據(jù)量、排序等。完整的Restful 是需要做到超媒體訪問的，在請(qǐng)求后給出一個(gè)link 的描述信息，例如：{"link": { "rel":"xxx""href":"xxx","title": "xxx"，"type": "application/xml"}}rel 指的是與當(dāng)前的API 的關(guān)系，href 指的是API 的路徑，title 指的是API 的標(biāo)題，type 指的是API 的返回類型，本文基于Rest 這樣的一組架構(gòu)約束條件和原則設(shè)計(jì)智能倉(cāng)庫(kù)系統(tǒng)的API 接口。

2.3 定時(shí)任務(wù)

系統(tǒng)中的入庫(kù)流程自動(dòng)拉取上游系統(tǒng)的ETL[14]數(shù)據(jù)庫(kù)的預(yù)到貨通知單信息，下發(fā)質(zhì)檢規(guī)則生成的質(zhì)檢單，下發(fā)庫(kù)位上架單以及移庫(kù)的任務(wù)單都是在無人值守時(shí)運(yùn)行，系統(tǒng)需要定時(shí)任務(wù)管理的基礎(chǔ)服務(wù)，首先需要一個(gè)管理控制臺(tái)進(jìn)行定時(shí)任務(wù)的發(fā)布，這個(gè)控制臺(tái)可以是PC 的網(wǎng)頁也可以是手持設(shè)備的界面，系統(tǒng)對(duì)這些定時(shí)任務(wù)[15]進(jìn)行管理和調(diào)度，等到了設(shè)置好的時(shí)間點(diǎn)就把執(zhí)行指令下發(fā)到對(duì)應(yīng)進(jìn)程上。任務(wù)發(fā)布需要指定任務(wù)的執(zhí)行單元和路徑，任務(wù)單元一般是實(shí)現(xiàn)某個(gè)公共的統(tǒng)一接口，同時(shí)需要配置執(zhí)行進(jìn)程的環(huán)境、資源和資源的預(yù)處理，到了執(zhí)行時(shí)間就執(zhí)行，如果不指定任務(wù)的執(zhí)行節(jié)點(diǎn)集群，就隨機(jī)指定節(jié)點(diǎn)和集群執(zhí)行；有了任務(wù)如何調(diào)度任務(wù)呢，比如明天的11 點(diǎn)59 分59 秒有一個(gè)拉取上游數(shù)據(jù)的任務(wù)需要運(yùn)行，從操作系統(tǒng)的角度就是設(shè)置定時(shí)器的初始值，每次時(shí)鐘震蕩的時(shí)侯減1，當(dāng)減到0 的時(shí)候觸發(fā)一個(gè)硬件中斷執(zhí)行的某個(gè)回調(diào)方法，執(zhí)行注冊(cè)到該回調(diào)方法的任務(wù)；調(diào)度執(zhí)行的時(shí)候遠(yuǎn)程調(diào)用框架，調(diào)用具體的執(zhí)行指令，調(diào)度器需要維護(hù)好所有執(zhí)行器的狀態(tài)，并做到負(fù)載的均衡，避免出現(xiàn)把所有的執(zhí)行指令調(diào)度到同一個(gè)執(zhí)行器上進(jìn)行定時(shí)任務(wù)的執(zhí)行等情況，另外大的作業(yè)任務(wù)需要分片，根據(jù)時(shí)間或其他數(shù)據(jù)進(jìn)行分片到多個(gè)節(jié)點(diǎn)執(zhí)行任務(wù)的運(yùn)行。智能倉(cāng)庫(kù)系統(tǒng)可以將定時(shí)任務(wù)分為三個(gè)部分：作業(yè)、任務(wù)和觸發(fā)器，任務(wù)和觸發(fā)器都是隸屬于作業(yè)的。任務(wù)是有類型的，可以擴(kuò)展用來實(shí)現(xiàn)其他的系統(tǒng)任務(wù)。觸發(fā)器是用來定義觸發(fā)條件的，例如質(zhì)檢的貨品或時(shí)間等限制。包括時(shí)間觸發(fā)，手動(dòng)運(yùn)行、運(yùn)行一次、每天、每周、每月、定制，以及條件觸發(fā)，單觸發(fā)器、多觸發(fā)器。一個(gè)作業(yè)包含時(shí)間條件、觸發(fā)器、任務(wù)以及后續(xù)任務(wù)等。當(dāng)前的作業(yè)運(yùn)行完，就會(huì)運(yùn)行后續(xù)作業(yè)，多個(gè)后續(xù)作業(yè)是并行運(yùn)行的，且其中一個(gè)后續(xù)作業(yè)的運(yùn)行失敗不會(huì)影響其他作業(yè)的運(yùn)行，很好地保證了倉(cāng)庫(kù)系統(tǒng)的可用性。

3 智能倉(cāng)庫(kù)系統(tǒng)實(shí)現(xiàn)

3.1 入庫(kù)實(shí)現(xiàn)

入庫(kù)管理的預(yù)到貨通知單ASN 支持手工輸入、excel 導(dǎo)入審核后支持打印入庫(kù)清單。系統(tǒng)使用easyexcel[16]來導(dǎo)入入庫(kù)的數(shù)據(jù)，ExcelWriterBuilder 創(chuàng)建出ReadWorkbook、WriteWorkbook、ReadSheet、WriteSheet 對(duì)象，excelAnalyser 使用XlsxSaxAnalyser解析excel 文件的每個(gè)sheet 頁中的每個(gè)格子的數(shù)據(jù)。ReadListener 會(huì)在每行讀取完后調(diào)用回調(diào)方法來處理數(shù)據(jù)WriteHandler 在每一個(gè)操作包括創(chuàng)建單元格、創(chuàng)建表格等都會(huì)調(diào)用回調(diào)方式來處理數(shù)據(jù)。導(dǎo)入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;

}

入庫(kù)管理的表結(jié)構(gòu)如表1所示。

表1 入庫(kù)的表結(jié)構(gòu)

3.2 質(zhì)檢實(shí)現(xiàn)

質(zhì)檢管理對(duì)需要質(zhì)檢的貨品進(jìn)行質(zhì)檢后上架，質(zhì)檢模板的觸發(fā)器的具體實(shí)現(xiàn)是指定觸發(fā)條件，將該觸發(fā)條件存儲(chǔ)在數(shù)據(jù)庫(kù)對(duì)應(yīng)的schedulerjobtrgger 表中,每隔一段時(shí)間就去檢測(cè)條件是否滿足質(zhì)檢的模板，當(dāng)滿足后，就執(zhí)行下發(fā)質(zhì)檢單的任務(wù)，并可以添加多個(gè)觸發(fā)器，并編輯觸發(fā)器的“與”“或”關(guān)系。質(zhì)檢管理表結(jié)構(gòu)如表2所示。

表2 質(zhì)檢的表結(jié)構(gòu)

3.3 上架實(shí)現(xiàn)

上架管理這個(gè)業(yè)務(wù)流程需要修改庫(kù)存的信息，庫(kù)位的剩余尺寸和剩余承重要減少，相應(yīng)的貨品的所屬庫(kù)位也要更新，貨品信息的表結(jié)構(gòu)如表3所示。

3.4 移庫(kù)實(shí)現(xiàn)

移庫(kù)管理需要更新兩個(gè)庫(kù)位的信息以及所屬貨品的信息，移庫(kù)信息的自動(dòng)更新可以使用WebSocket 的推送功能，借用HTTP 將協(xié)議轉(zhuǎn)換成為Upgrade 首部所列的協(xié)議來達(dá)到協(xié)議轉(zhuǎn)換，從HTTP 協(xié)議切換成WebSocket 通信協(xié)議,移庫(kù)管理的表結(jié)構(gòu)如表4所示。

表4 移庫(kù)的表結(jié)構(gòu)

3.5 盤點(diǎn)實(shí)現(xiàn)

管理員手動(dòng)創(chuàng)建好盤點(diǎn)計(jì)劃并維護(hù)好表中的數(shù)據(jù)，到了盤點(diǎn)的指定時(shí)間，系統(tǒng)會(huì)自動(dòng)地向庫(kù)內(nèi)作業(yè)人員下發(fā)指令進(jìn)行盤點(diǎn)，盤點(diǎn)管理的表結(jié)構(gòu)如表5所示。

表5 盤點(diǎn)管理的表結(jié)構(gòu)

3.6 出庫(kù)實(shí)現(xiàn)

收到客戶的訂單后系統(tǒng)自動(dòng)生成出貨單，揀貨出庫(kù)管理的表結(jié)構(gòu)如表6所示。

表6 出庫(kù)的表結(jié)構(gòu)

4 智能倉(cāng)庫(kù)系統(tǒng)測(cè)試

4.1 功能測(cè)試

開發(fā)完成的系統(tǒng)需要部署到對(duì)應(yīng)的服務(wù)器環(huán)境中，本文使用的是阿里云服務(wù)器ECS，具體的生產(chǎn)環(huán)境配置是6 核CPU、62G 內(nèi)存120G 系統(tǒng)盤、64 位CentOS7.2 的公共鏡像、1Mbps 的公網(wǎng)帶寬。數(shù)據(jù)庫(kù)采用阿里云的RDS，系統(tǒng)使用war 包部署在中間件tomcat 上，修改默認(rèn)的開啟和關(guān)閉的端口以提高安全性，RDS 上既有業(yè)務(wù)資源的庫(kù)也有審計(jì)信息的庫(kù)，部署的架構(gòu)圖如圖2所示。

將系統(tǒng)打?yàn)閣ar 包之后，分別部署到兩個(gè)ECS 上，聯(lián)機(jī)服務(wù)器負(fù)責(zé)主要的倉(cāng)庫(kù)業(yè)務(wù)，管理臺(tái)服務(wù)器負(fù)責(zé)后臺(tái)管理主要和數(shù)據(jù)庫(kù)進(jìn)行交互，業(yè)務(wù)服務(wù)器多讀少寫，因此主要和redis 的緩存集群服務(wù)進(jìn)行交互。邏輯上springboot 的集群作為整個(gè)系統(tǒng)與其他的緩存服務(wù)以及數(shù)據(jù)庫(kù)進(jìn)行交互。

智能倉(cāng)庫(kù)系統(tǒng)功能性的測(cè)試主要對(duì)需求中的模塊進(jìn)行大功能模塊的用戶UAT 環(huán)境測(cè)試，測(cè)試的模塊和最終的結(jié)果如表7所示。

4.2 非功能測(cè)試

非功能性的測(cè)試主要對(duì)高并發(fā)下的UAT 環(huán)境進(jìn)行測(cè)試，選取的工具是jmeter[17]，智能倉(cāng)庫(kù)系統(tǒng)存在多用戶操作，大數(shù)據(jù)量操作的特征。測(cè)試中將針對(duì)這些多用戶操作，大數(shù)據(jù)量查詢等進(jìn)行如基準(zhǔn)、負(fù)載、壓力、穩(wěn)定性和健壯性等方面的性能測(cè)試，檢查并評(píng)估在模擬環(huán)境中，系統(tǒng)對(duì)負(fù)載的承受能力，以及在不同的用戶連接情況下，系統(tǒng)的吞吐能力和響應(yīng)能力。通過基準(zhǔn)測(cè)試，驗(yàn)證測(cè)試腳本及后臺(tái)環(huán)境、初步檢查事務(wù)本身是否存在性能缺陷。通過負(fù)載測(cè)試，獲得各被測(cè)事務(wù)在不同請(qǐng)求負(fù)載下的處理能力、響應(yīng)時(shí)間等性能指標(biāo)，并分析其性能拐點(diǎn)。通過混合壓力測(cè)試，在被測(cè)系統(tǒng)上不斷增加壓力，獲取系統(tǒng)的最大事務(wù)處理能力，并依據(jù)壓力變化的趨勢(shì)，分析系統(tǒng)性能瓶頸。通過對(duì)比測(cè)試，對(duì)功能等方面進(jìn)行對(duì)比分析，為系統(tǒng)的進(jìn)一步優(yōu)化提供數(shù)據(jù)參考。測(cè)試的軟硬件配置如表8所示。

表8 測(cè)試的軟硬件配置

對(duì)50 用戶、100 用戶和500 用戶在10 分鐘內(nèi)不斷地對(duì)系統(tǒng)模擬壓測(cè)得到的各個(gè)模塊的TPS 和響應(yīng)時(shí)間如表9。

表9 系統(tǒng)模擬壓測(cè)各模塊TPS 和響應(yīng)時(shí)間

從表9可以看到在被測(cè)系統(tǒng)上不斷增加壓力后，貨品管理的系統(tǒng)吞吐量TPS 下降，響應(yīng)時(shí)間增長(zhǎng)的比較高，其余模塊的吞吐量和響應(yīng)時(shí)間均在預(yù)期的接受范圍。

5 結(jié) 語

企業(yè)運(yùn)營(yíng)需要智能倉(cāng)庫(kù)系統(tǒng)對(duì)倉(cāng)儲(chǔ)管理的流程進(jìn)行智能化的全流程管理，做到完全的數(shù)字化、自動(dòng)化和智能化，本文對(duì)通用的物流倉(cāng)庫(kù)業(yè)務(wù)流程分析研究后，實(shí)現(xiàn)構(gòu)建了全流程管理的數(shù)字化智能倉(cāng)庫(kù)系統(tǒng)，它對(duì)外統(tǒng)一提供Restful 風(fēng)格的API 接口，方便其他系統(tǒng)直接調(diào)用，系統(tǒng)使用微服務(wù)的方式進(jìn)行面對(duì)對(duì)象的設(shè)計(jì)，可以靈活快速地響應(yīng)業(yè)務(wù)的變化，利用定時(shí)任務(wù)模塊，進(jìn)行自動(dòng)派單提升了員工的工作效率。