基于微服务架构的区域物流信息共享服务平台研究

廖雪花，苟乐怡，马智勤，张 俊

（四川师范大学 计算机科学与技术学院，四川 成都 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 方案搭建了区域物流信息共享服务平台，并对平台性能进行了测试，测试结果表明，该平台能够满足物流末端用户的使用需求。但是，平台仍然有需要改进的地方，如货物的安全保障机制等，值得进一步研究。