基于微服務架構的區域物流信息共享服務平臺研究

廖雪花，茍樂怡，馬智勤，張 俊

（四川師范大學 計算機科學與技術學院，四川 成都 610101）

1 引言

區域物流的末端配送是近幾年物流配送中的熱點問題，傳統的配送方式受限于快遞員與消費者在時間差上的影響（如快遞員的等候時間、用戶不在家產生二次配送等），以及快遞量的猛增，使得配送效率難以實現規模化提升。

不同于其他平臺功能的分散，共享服務平臺將末端配送所需的功能匯集在一起，為用戶提供了一站式服務，融合現有共享配送模式的特點，提出了“順手取”的新模式，即每一位用戶都可注冊加入順手取，在自己取件或活動的同時，能夠幫助別人一起取快遞或“順手”取物，讓每一位用戶都能輕松成為“快遞員”，與大家共享時間資源。同時，用戶可以自由設置快遞送貨上門的時間與地點，避免快遞員二次上門。

本文通過市場調研獲取用戶對于平臺新模式的接受程度及建議，并在此基礎上，運用微服務架構的思想，搭建出區域物流信息共享服務平臺。

2 市場調研與需求分析

2.1 市場調研

為了判斷“順手取”模式的可行性，項目組開展了問卷調研。本次調研以問卷星形式展開，對不同年齡段包括18歲以下、19-25歲、26-30歲、31-40歲、40 歲以上的人群進行了調研。調研結果表明，參與調研的以19-25歲的人群居多，占72%，其次為40歲以上人群，占12%，26-30 歲與31-40 歲人群分別占6.94%與5.44%，18 歲以下人群占總人數的3.38%。在這些人群中，男女比例幾乎相同，分別為42.78%與57.22%。以上數據說明，參與調研的人群以喜愛購物的青年人群為主，且男女比例相對平衡，能夠為此次調研提供有效數據。

本次調研總計533 份有效問卷，其中QQ 提交306 份，微信提交227 份。共有24 道題，包括參與調研者的年齡、工作狀態等個人基本信息以及參與者對于物流配送環節的實際體驗與感受等。

2.1.1 “送貨上門”配送需求。在本次調研樣本中，共有71.48%的人看中送貨上門這項配送服務，其中，正式工作者與退休在家者所占比例最高，如圖1所示。

由圖1可知，不論是很看重還是比較看重，各個職業類型的人都會重視送貨上門這項服務，這也將成為今后物流配送的一個趨勢：一切為了用戶的便利，節約用戶時間。

在統計樣本中，共有37.34%的人勉強愿意因為送貨上門而延長到件時間，有44.84%的人是愿意的，有17.82%是不愿意的，在前面的82.18%的基本愿意的人員中，若為了“送貨上門”而延長到件時間，能夠接受延長1天以內或1-3天，這表明人們為了能夠更方便的收取快遞，是能夠接受一定程度的延遲或付出的。

2.1.2 取快遞方式調查。在調查樣本中，大部分用戶采用步行取快遞，有少數采用自行車或電動車。其中，用戶到距離家最近的物流運營點（或取快遞點）需要花費的時間與取快遞全程所需時間的時間關系如圖2所示，用戶到快遞點5min以內路程的，取快遞需總共花費10min以內居多，5-20min路程的，總花費 10-30min 居多；20-40min 路程的，30-60min 居多；40min以上路徑的，1h以上居多。

圖1 各個職業類型對送貨上門的重視比例

圖2 用戶到快遞點花費時間與取快遞總時間比例

在這些用戶里，大部分用戶認為離自取點較近，取快遞還是比較方便，這也得益于近年來物流業及其服務模式的不斷發展，但是，仍然有少數的用戶認為自取點較遠，往往錯過取件時間，有少數的用戶認為家離自取點太遠，取件比較麻煩，因此，這就需要我們對物流最后一公里的配送提出更新的模式。

2.1.3 新模式接受度。本文提出的“順手取”模式，是為了讓人民能夠更方便、更高效率的取快遞，當然，別人在“順風”為用戶取了快遞后，用戶也需要為幫忙取快遞者支付一定的費用，因此，此次調研也對用戶對于“對幫忙取快遞支付費用”和“順手取”這種模式的接受度進行了調研，在接收調研的用戶中，有60.6%的用戶表示能接受“順手取”這一模式，并相信平臺能夠為其保障貨物安全，同時有54.6%的用戶愿意為了取件方便而多花1-3元。這表明人們對于這一新模式還是抱有期待的，只要能夠保障安全與消費者權益，大家能夠接受并期待這一新模式。

圖3 平臺功能結構圖

2.2 需求分析

通過電子問卷以及對各大配送平臺的調研我們發現，目前末端配送的形式多種多樣，其中最具代表性的有以下三種末端配送共享模式：

（1）第三方代收平臺共享模式：如菜鳥驛站、熊貓快收等平臺。

（2）智能快遞柜共享模式。

（3）共同配送模式：如城市100 快遞、美團、餓了么等。

通過對現有末端配送模式的研究與調查可以發現，每種模式都各有優缺點，如果能將這些模式的優點融合起來，取長補短，那么將會更大的提高配送效率、節約配送資源。因此，本文在現有末端配送模式的基礎上，通過對信息技術、網絡技術、平臺構建技術等的研究，構建了區域物流信息共享服務平臺，利用平臺線上技術和“順手取”模式整合線下企業、商品和服務資源，以實現“區域物流線上線下一體化，充分利用線上平臺資源融合線下資源，為物流企業、線下商家、個體用戶等群體提供線上線下融合服務新模式”。

3 區域物流信息共享服務平臺詳細設計

3.1 功能結構圖

系統平臺的功能結構如圖3所示。

平臺功能主要包括：系統首頁、寄快遞服務、企業服務、順手取服務、用戶中心以及后臺管理服務6大功能。各模塊功能與使用流程為：

（1）用戶可以在不登錄狀態下查詢物流信息。

（2）用戶登錄后，可以在寄快遞模塊根據自身需求選擇“網點自寄”、“預約取件”、“順手寄”三種寄件模式之一進行寄件。其中，“網點自寄”需下單后自行到快遞網點進行寄件；“預約取件”為預約快遞員上門取件；“順手寄”為發布寄件需求，由其他用戶接單配送。

（3）用戶寄件后，可在用戶中心對寄件信息與寄件地址等進行管理，并能夠在用戶中心預約快遞員送達快遞的時間段與地點，避免二次上門送貨。

（4）用戶不僅能在平臺寄快遞，也可以在“順手取”模塊注冊加入“順手取”會員，在自己取快遞或活動過程中能夠與別人共享送件資源。

（5）用戶加入“順手取”后，在主頁將會展示待取貨的“順手寄”訂單，用戶搶單后，即可在“順手取”模塊查看到自己的“待取貨”、“待送達”和“已送達”訂單，用戶到達取貨點后，從寄件人處獲得取貨碼，即可完成“取貨”。

（6）指定物流公司指用戶可以選擇平臺提供的物流公司中的任一公司進行配送，其中平臺提供的物流公司選項即為入駐了平臺的物流公司。物流公司、第三方物流服務商等若想入駐平臺，則需在企業服務模塊提交申請，管理員批準后即可入駐。

最后，在后臺管理模塊，平臺提供了管理員對申請入駐的企業進行審核批準功能，和對加入了“順手取”的人員進行審核管理功能，若發現有違規人員，即可停止其順風取資格。

3.2 平臺優勢

送貨上門體現了電商購物的便利性，已成為顧客普遍接受的快遞配送模式。但隨著顧客消費理念的轉變、市場環境的影響、新型配送模式的出現，送貨上門企業在實際運營中存在著以下問題：顧客需求分散，配送成本高；延時配送頻繁，配送時效低；配送價格待優化。自提服務緩解了末端配送的困境，給顧客提供了靈活的取貨時間，但由于顧客偏好差異、網點密度較低等原因，自提點在實際運營中仍存在以下幾個問題：顧客偏向于送貨上門，使得設立的自提點運行效率較低，存在資源閑置的情況；自提點選址不合理，取貨距離較遠，不在顧客的期望范圍內，直接的影響就是顧客放棄自提，而選擇送貨上門服務；自提點容量不夠，且時間存在局限性。

為了解決以上問題，本文提出“順手取”的新模式，讓每一個用戶在取快遞的過程中都能“順手”幫助別人取，且能得到一定的報酬，這樣雙方都能得到所需的便利，并解決了快遞“二次”上門以及用戶無法及時取快遞的問題。同時，平臺將寄、取快遞，“順手取”等功能進行匯總，實現用戶的一站式服務。

4 區域物流信息共享服務平臺架構搭建

為了實現高并發、高性能和高可用，平臺使用Spring Boot + Spring Cloud Netflix 相關組件進行微服務架構的搭建。在微服務架構中，為了使代碼更優雅、邏輯更清晰，使用響應式Spring Boot WebFlux 框架，此框架支持基于注解的編程模型，對于代碼的復用非常重要。最后，平臺采用Sql Server數據庫，以及具有可移植性及高性能的java語言進行開發。

微服務架構的搭建是平臺搭建的關鍵與重點。微服務（Microservice）這個概念由 Martin Fowler 與James Lewis 于2014年共同提出，微服務架構是一種架構思想，根據這種思想搭建出的平臺是一個分布式的應用。Spring Cloud是一個基于Spring Boot實現的云應用開發工具，它利用Spring Boot的開發便利性巧妙地簡化了分布式系統基礎設施的開發[4]，如API網關、服務發現注冊、配置中心、消息總線、負載均衡、斷路器、數據監控等。通過使用Spring Cloud Netflix，我們可以很好地解決微服務架構搭建過程中客戶端訪問服務、服務之間的通信、服務的治理、服務的容錯等問題，讓平臺能夠更好地實現高并發、高性能、高可用。

4.1 平臺服務劃分

通過圖3可以看到，平臺共有6 大功能模塊，其中第一個模塊包括查快遞和“順手取”搶單功能，根據微服務的特點之一：服務是圍繞業務功能構建，因此我們將平臺一共拆分為7 個服務，即物流查詢服務、“順手取”搶單服務、寄快遞服務、企業入駐申請服務、“順手取”服務、“用戶中心”服務以及“后臺管理”服務。

4.2 平臺微服務架構解決方案

在構建分布式微服務架構過程中，我們將會主要面臨以下幾個問題：平臺的應用程序在被拆分為多個小服務之后，客戶端如何去訪問每一個服務？各個服務之間的通信應該采用什么方式？如何對這些服務進行統一的管理？如果服務出現問題了，應該怎樣解決？為了解決這些問題，我們需要實現服務網關（API Gateway）、服務注冊與發現中心、服務間通信和服務容錯保護等關鍵技術環節，本平臺將采用Spring Cloud的以下組件來解決微服務搭建過程中的一些問題：

（1）服務發現與注冊中心Eureka。當我們將平臺劃分為若干個服務后，需要有一個地方對這些服務進行統一的管理，這個地方就叫做服務發現與注冊中心。每一個服務的提供者上線后，都需要將自己注冊到服務發現與注冊中心中，當服務消費者需要使用服務時，就到中心去拉取一份服務清單，從而進行遠程調用。這個環節使用Spring Cloud 提供的Eureka組件來實現。

（2）服務間通信。在眾多的服務中，每一個服務之間的通信都是特別重要的。我們共有兩種實現服務之間通信的方案，一種是使用Ribbon+Rest Template，另一種是使用Feign。其中Feign 集成了Ribbon，也具有負載均衡的作用，最終本文選擇是使用Feign來實現服務間通信。

（3）服務的容錯Hystrix。為了保證在整個微服務鏈式調用的過程中，不會因為個別服務的出錯導致整個系統出現故障，需要采取一些辦法。通過使用Spring Cloud提供的Hystrix組件，可以實現服務調用出錯時的熔斷降級。

（4）服務網關Spring Cloud Gateway。服務網關是一個服務器，作為系統的唯一入口，它封裝了系統內部架構，為每個客戶端提供一個定制的API。API網關主要是進行請求路由管理與過濾器功能[9]，實現了前臺UI 與后臺服務之間的通信，是非常重要的一個環節，本文使用Spring Cloud 提供的Spring Cloud Gateway組件來實現服務網關。

4.3 平臺架構搭建

通過對上述組件的合理組合，能夠解決平臺微服務架構搭建過程中的關鍵問題，使用這些組件搭建的服務平臺微服務架構如圖4所示。

為了緩解大量請求的壓力，將“物流查詢服務”等7個服務都分別部署為集群，同時為了避免單點故障等問題的出現，將API 網關Spring Cloud Gateway、服務注冊與發現中心Eureka 以及分布式配置中心Config都部署為集群。

圖4 平臺微服務架構圖

Spring Cloud Gateway 集群與各個服務集群都需要注冊到Eureka 中，以便服務消費者進行調用，同時，需要連接Config 服務器，將配置文件放置在遠程GitLab倉庫中進行統一管理。用戶的請求經過nginx負載均衡后，到達Spring Cloud Gateway，由Spring Cloud Gateway根據從Eureka獲得的服務列表對請求進行轉發。Spring Cloud Gateway 對服務進行轉發時，由Ribbon進行負載均衡。

服務之間需要互相調用時，通過Feign進行遠程調用。在整個過程中，都集成了服務容錯機制，可以通過Hystrix 對出錯服務的請求進行處理，同時通過HystrixDashboard或turbine來進行健康監控。

通過使用微服務架構進行平臺重構，能夠讓平臺具有更好的擴展性與靈活性，能夠更好的實現高性能、高并發、高可用。同時，微服務架構這一架構思想是近幾年才提出的分布式系統解決方案，使用這一架構模式也使得平臺具有一定的創新性，有利于未來系統的發展與更新。

5 區域物流信息共享服務平臺性能測試

5.1 JMeter腳本編寫

Apache JMeter 是一款純java 編寫負載功能測試和性能測試開源工具軟件，本文使用JMeter 進行性能測試，如圖5所示，配置用戶數為600人，并在1s啟動這600 個用戶線程，并且每個用戶線程發送10 次請求，即總請求數為6 000。

為了更真實的模擬對一個請求的并發測試場景，平臺設置了一個集合點，即一個閥值，當請求數達到閥值時，允許請求同時發出，JMeter 中提供了同步定時器，如圖6所示，設置請求集合數量為400，即當用戶數量達到400 個時再同步發送請求；設置超時時間為800ms，即當請求數不足400，但等待時間超過800ms 時，依然放行。

5.2 執行性能測試

設置好測試參數后，啟動測試，待性能測試執行完成后，得到并發用戶聚合報告，如圖7所示。

圖5 設置線程組

圖6 設置并發數

圖7 并發用戶400的聚合報告

由圖7可知，對于6 000個樣本的請求，當并發用戶數量為400時，平均響應時間為0.369s,有90%的請求響應時間不大于0.71s，有95%的請求響應時間不大于0.763s，99%的請求響應時間不大于1.17s。服務器響應的最短時間為0.01s，最長時間為1.64s，錯誤率為0，系統吞吐量為每秒722.4個請求。

將并發用戶數量設置到500，得到如圖8所示的聚合報告，由圖8可知，此時99%的請求響應時間不大于1.034s。服務器響應的最短時間為0.007s，最長時間為1.048s，錯誤率為0，系統吞吐量為每秒666.4個請求。

圖8 并發用戶500的聚合報告

將并發用戶數量設置到1 000，得到如圖9所示的聚合報告，由圖9可知，此時99%的請求響應時間不大于2.123s。服務器響應的最短時間為0.005s，最長時間為2.169s，錯誤率為0，系統吞吐量為每秒739個請求。

圖9 并發用戶1 000的聚合報告

5.3 測試結論

通過對平臺的測試結果可知，當用戶的并發量分別為400、500、1 000時，系統的響應時間依次有所增長，但都小于3s，其中99%的響應時間都小于2.5s,請求的錯誤率都為0，這表明此平臺能夠滿足物流末端用戶的使用需求，能夠提供至少1 000級的用戶并發數，且系統響應時間在3s 以內，實現了系統高并發、高性能的特性。平臺在連續使用與測試過程中，總體表現穩定，具有7×24h的連續運行能力。

6 結語

區域物流一體化是區域物流經濟發展的未來方向與模式，是突破現代物流發展瓶頸的新思路，與政府宏觀調控目標高度契合。本文通過對區域物流現有模式的分析總結以及調研，收集了用戶對物流末端配送的相關需求以及對“順手取”這一新模式的接受程度及建議，提出了區域物流一體化線上線下融合新模式—“順手取”。基于此新模式，通過分析平臺搭建過程中的主要問題，采用Spring Boot+Spring Cloud Netflix 方案搭建了區域物流信息共享服務平臺，并對平臺性能進行了測試，測試結果表明，該平臺能夠滿足物流末端用戶的使用需求。但是，平臺仍然有需要改進的地方，如貨物的安全保障機制等，值得進一步研究。