基于Web的高性能智能快遞柜管理系統(tǒng)

馬梓昂 賈克斌

(北京工業(yè)大學(xué)信息學(xué)部 北京 100124) (先進(jìn)信息網(wǎng)絡(luò)北京實(shí)驗(yàn)室 北京 100124)

0 引 言

智能快遞投遞箱將快件暫時(shí)保存在投遞箱內(nèi)，并將信息通過短信等方式發(fā)送用戶，為用戶提供24小時(shí)自助取件服務(wù)。用戶還可以通過寄存功能將物品進(jìn)行短暫的存放，通過發(fā)送的驗(yàn)證碼再次開柜取走寄存物品。廣告模塊可以由廣告商申請(qǐng)權(quán)限進(jìn)行物料的上傳和廣告計(jì)劃的添加，用戶亦可上傳需要發(fā)布的物料，類似尋人尋物啟事等。

目前基于Web的管理系統(tǒng)主要采用固定化的模塊方式，底層邏輯只針對(duì)相應(yīng)的功能模塊，當(dāng)功能之間有交叉重疊時(shí)，代碼復(fù)用率很低。此外，傳統(tǒng)的快遞柜系統(tǒng)較難添加不同類型的機(jī)柜。廣告系統(tǒng)也大多與管理系統(tǒng)分離，造成廣告監(jiān)管不便、收益查詢不便等問題。

為此，本文介紹了一種重用底層邏輯的開發(fā)模式。該模式劃分更多固定模塊并集成配置模塊，以便用戶自定義配置內(nèi)容。廣告和收入系統(tǒng)也被集成在了管理平臺(tái)上。由此，基于當(dāng)前流行的開發(fā)模型SSH和SSM，研究了Spring、Spring MVC、Mybatis、Hibernate的優(yōu)勢(shì)以及適用于該系統(tǒng)的方案。本文采用SpringMVC設(shè)計(jì)模式和MyBatis框架，同時(shí)在端與端的通信上采用Redis,最終實(shí)現(xiàn)的系統(tǒng)滿足了業(yè)務(wù)及性能需求，成功上線為廣大用戶提供服務(wù)。

1 研究背景

1.1 當(dāng)前問題研究

從供給端和需求端去看待當(dāng)前行業(yè)問題及對(duì)應(yīng)需求。

(1) 供給端：快遞企業(yè)?？爝f從業(yè)人員缺口大，未來幾年，全國(guó)快遞日均配送量將由1.14億件上升至2億件，按照目前的配送效率計(jì)算，幾年后快遞員的缺口預(yù)計(jì)將在100萬人左右。

(2) 供給端：快遞員?？爝f員工作時(shí)間長(zhǎng)，配送壓力大，已成高壓職業(yè)。據(jù)估計(jì)，目前快遞員日均配送量為60～100件。超過八成的快遞員平均工作時(shí)長(zhǎng)在8個(gè)小時(shí)以上，在電商促銷旺季甚至?xí)^12個(gè)小時(shí)。

(3) 需求端：市場(chǎng)需求普遍。市場(chǎng)方面存在著需求持續(xù)增長(zhǎng)的問題。根據(jù)國(guó)家郵政局統(tǒng)計(jì)數(shù)據(jù)，“十二五期間”，國(guó)內(nèi)快遞業(yè)務(wù)量連續(xù)5年保持50%左右的高速增長(zhǎng)。2017年，業(yè)務(wù)總量達(dá)到400.6億件，收入達(dá)到4 957億元。據(jù)國(guó)家郵政局發(fā)布的《郵政業(yè)發(fā)展“十三五”規(guī)劃》預(yù)計(jì)，2020年快遞業(yè)務(wù)量將達(dá)到700億，收入將接近8 000億元。

1.2 后臺(tái)系統(tǒng)研究

針對(duì)以上問題，本文設(shè)計(jì)開發(fā)了一套高效的基于Web的快遞柜后臺(tái)管理系統(tǒng)，將廣告商系統(tǒng)、快遞員管理系統(tǒng)、機(jī)柜硬件自檢系統(tǒng)等集成到統(tǒng)一管理平臺(tái)，實(shí)現(xiàn)代碼自檢、廣告流程審核優(yōu)化、分布式業(yè)務(wù)開發(fā)等功能，提高了后臺(tái)的覆蓋業(yè)務(wù)面，簡(jiǎn)化了管理流程，同時(shí)減少了所需人力。

2 功能模塊設(shè)計(jì)

2.1 關(guān)鍵模塊設(shè)計(jì)

智能快遞柜后臺(tái)管理系統(tǒng)Web應(yīng)用，主要功能有機(jī)柜管理、廣告計(jì)劃、快遞員管理、快遞員APP配置管理等模塊。其整體框架如圖1所示。

圖1 系統(tǒng)核心模塊設(shè)計(jì)

機(jī)柜管理模塊：該模塊顯示機(jī)柜的基礎(chǔ)信息詳情，包括機(jī)柜編碼、機(jī)柜名稱、機(jī)柜別名、所在省份、詳細(xì)地址、所屬者等信息，也能添加機(jī)柜的基礎(chǔ)信息。較復(fù)雜的模塊有關(guān)聯(lián)機(jī)柜的投資者，關(guān)聯(lián)機(jī)柜的運(yùn)營(yíng)維護(hù)人員，關(guān)聯(lián)機(jī)柜的初始化硬件，機(jī)柜整體布局等自定義模塊。

機(jī)柜整體布局自定義模塊：包含主柜的初始化操作和副柜的添加。實(shí)現(xiàn)按業(yè)務(wù)需求進(jìn)行自定義格口，將不局限于傳統(tǒng)快遞柜的大、中、小固定模式。

機(jī)柜自檢模塊：該模塊通過對(duì)機(jī)柜端信息的采集，解析到后臺(tái)，實(shí)現(xiàn)了后臺(tái)管理人員對(duì)機(jī)柜實(shí)時(shí)的智能監(jiān)控以及相關(guān)運(yùn)維人員的工單派發(fā)維護(hù)工作。

機(jī)柜編組模塊：該模塊將快遞柜根據(jù)管理需求(廣告下發(fā)、機(jī)柜報(bào)修、地域派發(fā)等)進(jìn)行分組。

物料管理模塊：進(jìn)行物料的上傳提交，審核成功的物料才可以在廣告計(jì)劃中進(jìn)行編輯操作，與相應(yīng)的機(jī)柜編組進(jìn)行關(guān)聯(lián)。

廣告計(jì)劃管理模塊：該模塊集成了廣告計(jì)劃，機(jī)柜編組，審核計(jì)劃的操作。

快遞員管理模塊：可對(duì)快遞員信息進(jìn)行添加、審核、刪除操作。

快遞員APP配置管理模塊：主要分為首頁(yè)輪播圖管理和系統(tǒng)消息管理。前者，后臺(tái)管理者上傳相應(yīng)的輪播圖圖片，包括設(shè)置輪播順序，以及啟用禁用該輪播圖。后者只有添加和刪除功能，不可編輯。

2.2 核心功能數(shù)據(jù)庫(kù)設(shè)計(jì)

數(shù)據(jù)庫(kù)設(shè)計(jì)中涉及到比較復(fù)雜的關(guān)系有：機(jī)柜基礎(chǔ)信息及機(jī)柜編組關(guān)系、機(jī)柜與運(yùn)維者配置關(guān)系、廣告計(jì)劃及物料關(guān)系。

智能快遞柜核心功能的數(shù)據(jù)庫(kù)關(guān)系如圖2、圖3所示。

圖2 機(jī)柜業(yè)務(wù)數(shù)據(jù)庫(kù)關(guān)聯(lián)設(shè)計(jì)

圖3 人員配置樣例數(shù)據(jù)庫(kù)關(guān)聯(lián)設(shè)計(jì)

其中，機(jī)柜基礎(chǔ)信息表是整個(gè)數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)的中心，相關(guān)聯(lián)的廣告編組、運(yùn)維人員、機(jī)柜編組、副柜等信息都需要依靠中間表與機(jī)柜基礎(chǔ)信息及機(jī)柜編組表做關(guān)聯(lián)。

3 高性能技術(shù)架構(gòu)設(shè)計(jì)

3.1 主流架構(gòu)性能的研究和比較

本文對(duì)目前較為流行兩種開發(fā)MVC開源框架——SSH和SSM進(jìn)行了研究。MVC交互過程如圖4所示。

圖4 MVC組織圖

3.2 SSH與SSM架構(gòu)分析

SSH 通常指的是 Struts2 做主控器，Spring 管理各層的組件，Hibernate 負(fù)責(zé)持久化層；SSM 則指的是 SpringMVC 做控制器，Spring 管理各層的組件，MyBatis 負(fù)責(zé)持久化層。它們的共同點(diǎn)是：

(1) 中間層都使用Spring注入DI來管理各層的組件。

(2) 整體都使用面向切面編程AOP管理事物、日志、權(quán)限等。

而二者的主要區(qū)別在于控制層與數(shù)據(jù)底層的差異，下文將詳細(xì)比較其應(yīng)用于本系統(tǒng)的優(yōu)劣勢(shì)。

3.2.1Struts2與SpringMVC的研究

Struts2和SpringMVC控制視圖和模型的交互機(jī)制的不同。Struts2是Action類級(jí)別，如圖5所示。SpringMVC是方法級(jí)別，如圖6所示，它更容易實(shí)現(xiàn)RESTful風(fēng)格。

圖5 Struts2交互機(jī)制

圖6 SpringMVC交互機(jī)制

從圖5和圖6中可以看出，Strusts2的類級(jí)操作更加耦合，操作一些詳細(xì)的邏輯操作很不方便，因此有必要設(shè)計(jì)分類程序。添加服務(wù)層和DAO層，替換模型層，細(xì)化數(shù)據(jù)模型，這樣當(dāng)我們更改表時(shí)，只需要更改DAO層的實(shí)現(xiàn)，最大化減少代碼的更改成本。

3.2.2Hibernate與MyBatis的研究

二者都支持JDBC和JTA事務(wù)處理，其實(shí)現(xiàn)邏輯如圖7所示。

圖7 數(shù)據(jù)事務(wù)處理邏輯

相對(duì)而言，MyBatis可以執(zhí)行更詳細(xì)的SQL優(yōu)化，進(jìn)而減少查詢字段。但是，MyBatis只實(shí)現(xiàn)了SQL語(yǔ)句和對(duì)象的映射，需要為特定數(shù)據(jù)庫(kù)編寫SQL語(yǔ)句。此外，它具有很強(qiáng)的處理數(shù)據(jù)庫(kù)更改的能力，優(yōu)化SQL語(yǔ)句更方便。

3.2.3SSH與SSM的性能比較

在文獻(xiàn)[2]中構(gòu)建了簡(jiǎn)單的SSM和SSH框架，進(jìn)行了數(shù)據(jù)操作，量化如表1所示。

表1 Mybatis與Hibernate執(zhí)行效率對(duì)比

表1中執(zhí)行時(shí)間為每條數(shù)據(jù)的平均執(zhí)行時(shí)間，Insert測(cè)試數(shù)據(jù)為1 000條，每次測(cè)試均為隨機(jī)選擇、刪除、更新一條數(shù)據(jù)，執(zhí)行次數(shù)為100次。

本系統(tǒng)選用SSM框架進(jìn)行高性能智能快遞柜管理后臺(tái)系統(tǒng)的開發(fā)。SSM 的輕量化特性更適合基于項(xiàng)目的研究，而且其靈活性更利于后期對(duì)高性能框架的研究。

4 SSM關(guān)鍵技術(shù)設(shè)計(jì)

4.1 Spring-MVC原子化Model層設(shè)計(jì)

使用MVC的目的是分離M和V的實(shí)現(xiàn)代碼，以便相同的程序可以使用不同的形式。Model整體化結(jié)構(gòu)與原子化分離結(jié)構(gòu)分別如圖8、圖9所示。

圖8 封裝完整的Model層結(jié)構(gòu)

圖9 原子化的Model層替換結(jié)構(gòu)

可以看出，在我們開發(fā)的高效后臺(tái)管理系統(tǒng)中，模型層被移除并被更加霧化的DAO層取代。同時(shí)，Controller層的業(yè)務(wù)邏輯分為多個(gè)服務(wù)。因此當(dāng)我們更改表時(shí)，只需要更改DAO層的實(shí)現(xiàn)，最大化減少代碼更改的成本。這使得智能快遞柜的獨(dú)立系統(tǒng)功能共享底層服務(wù)，使框架真正實(shí)現(xiàn)高性能。

4.2 Redis的特定通信協(xié)議

本文利用Redis訂閱發(fā)布模式的特點(diǎn)，將機(jī)柜端設(shè)計(jì)一個(gè)訂閱模塊，訂閱后臺(tái)發(fā)布的指令，使用Redis主要是把耦合點(diǎn)單獨(dú)抽離出來作為第三方，隔離易變化的發(fā)送方和接收方。發(fā)送方只負(fù)責(zé)向第三方發(fā)送消息，如店家把快遞包裹交給快遞公司，接收方被動(dòng)接收消息。第三方作用是：存儲(chǔ)訂購(gòu)產(chǎn)品的接收方，并在包裹過來時(shí)送給接收方。應(yīng)用Redis進(jìn)行通信的好處在于不僅可以將通信指令進(jìn)行傳達(dá)，同時(shí)可以在相應(yīng)的鍵值內(nèi)存儲(chǔ)一些必要的信息。

4.3 智能快遞柜系統(tǒng)實(shí)現(xiàn)

4.3.1整體模塊

主要系統(tǒng)模塊包含:微信用戶管理，機(jī)柜管理，快遞員管理，運(yùn)營(yíng)管理員管理，訂單管理，廣告管理，內(nèi)部消息，短信記錄管理，柜口配置，充值套餐配置，第三方支付配置，快遞員APP配置，合作商管理，地址管理，客服電話管理，程序版本管理及其相應(yīng)子模塊。

4.3.2核心功能

機(jī)柜管理下設(shè)的模塊關(guān)聯(lián)運(yùn)營(yíng)管理者管理、機(jī)柜硬件管理、地圖選點(diǎn)功能以及可視化界面編輯，自定義個(gè)性化柜口配置可以根據(jù)長(zhǎng)寬百分比進(jìn)行相應(yīng)柜口操作。

圖10和圖11展示了機(jī)柜管理的關(guān)聯(lián)添加功能，機(jī)柜管理關(guān)聯(lián)的相關(guān)組織有:運(yùn)營(yíng)管理員，投資者以及相關(guān)硬件。機(jī)柜柜口信息可視化模塊可以對(duì)機(jī)柜進(jìn)行自定義布局，左右移動(dòng)副柜。柜口類型關(guān)聯(lián)柜口配置模塊可以橫向縱向添加個(gè)性化配置，添加好的柜口可以上下移動(dòng)交換位置。

圖10 機(jī)柜管理添加信息界面

圖11 機(jī)柜管理添加機(jī)柜個(gè)性化界面

5 智能快遞柜系統(tǒng)性能測(cè)試

5.1 測(cè)試環(huán)境

本系統(tǒng)對(duì)服務(wù)器的內(nèi)存、CPU及可靠性等方面都有很高的要求。測(cè)試結(jié)構(gòu)如圖12所示。

圖12 系統(tǒng)測(cè)試拓?fù)鋱D

5.2 測(cè)試結(jié)果

模擬測(cè)試環(huán)境在我們忽略思考時(shí)間的前提下，運(yùn)用Loadrunner錄制腳本的功能進(jìn)行單個(gè)用戶調(diào)用微信用戶管理模塊以及查看、編輯、刪除等操作的腳本錄制。模擬參數(shù)化的200個(gè)用戶進(jìn)行訪問網(wǎng)頁(yè)，壓力測(cè)試條件為200個(gè)用戶同時(shí)啟動(dòng)，持續(xù)運(yùn)行5分鐘，200個(gè)用戶同時(shí)結(jié)束。其測(cè)試結(jié)果監(jiān)控圖如圖13-圖18所示。

圖13 訪問用戶數(shù)量變化圖

圖14 系統(tǒng)吞吐量變化圖

圖15 系統(tǒng)每秒點(diǎn)擊數(shù)變化圖

圖16 系統(tǒng)事務(wù)概要圖

圖17 系統(tǒng)平均事務(wù)響應(yīng)時(shí)間

圖18 測(cè)試結(jié)果圖

根據(jù)圖14、圖15可知，兩圖的大體趨勢(shì)相同，說明系統(tǒng)的功能響應(yīng)較好，吞吐量峰值可達(dá)12 000 000且每秒點(diǎn)擊量峰值達(dá)到1 050。該數(shù)據(jù)反映了系統(tǒng)在同一時(shí)間內(nèi)能處理業(yè)務(wù)的最大能力，數(shù)值越高，說明系統(tǒng)處理能力越強(qiáng)。

從圖18中可以看出，系統(tǒng)在200個(gè)用戶并發(fā)條件下，整體運(yùn)行良好，事務(wù)處理TPS指數(shù)為7.5，并且錯(cuò)誤的事務(wù)數(shù)量為0。

6 結(jié) 語(yǔ)

本文依據(jù)智能樓宇快遞柜后臺(tái)管理系統(tǒng)的特點(diǎn)以及業(yè)務(wù)需求對(duì)其進(jìn)行快速開發(fā)。主要采用整合框架SSM的設(shè)計(jì)思想，剝離了Model層，細(xì)化Service和DAO層。并且結(jié)合了SSM的高性能框架實(shí)現(xiàn)了業(yè)務(wù)邏輯層、數(shù)據(jù)持久層與表示層的分離，使機(jī)柜管理的副柜信息個(gè)性化設(shè)置功能和柜口配置等功能進(jìn)行最大效率的復(fù)用，大大降低了系統(tǒng)開發(fā)的耦合度。實(shí)驗(yàn)采用200個(gè)用戶無思考期望的5分鐘并發(fā)操作，證明了系統(tǒng)的可靠性和穩(wěn)定性，實(shí)現(xiàn)了預(yù)期的功能。