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

馬梓昂 賈克斌

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

0 引 言

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

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

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

1 研究背景

1.1 當前問題研究

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

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

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

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

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

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

2 功能模塊設(shè)計

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖4 MVC組織圖

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

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

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

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

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

3.2.1Struts2與SpringMVC的研究

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

圖5 Struts2交互機制

圖6 SpringMVC交互機制

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

3.2.2Hibernate與MyBatis的研究

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

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

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

3.2.3SSH與SSM的性能比較

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3.1整體模塊

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

4.3.2核心功能

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

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

圖10 機柜管理添加信息界面

圖11 機柜管理添加機柜個性化界面

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

5.1 測試環(huán)境

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

圖12 系統(tǒng)測試拓撲圖

5.2 測試結(jié)果

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

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

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

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

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

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

圖18 測試結(jié)果圖

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

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

6 結(jié) 語

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