1 系统概述

1.1 系统目的

通达物流系统是一个解决同城用户与快递员快速寄件/取件、下单/抢单、支付/提现、综合查询的物流系统。

该系统通过对用户周围寄件资源（快递员）的合理调配，提高了社会资源的利用率，实现了优势快递资源的共享，以达到用户快速寄件的目的。

该系统是公司同城物流战略的核心系统，承担着公司主要的业务功能，是实现公司上市基石。

该系统后续还会支持后台管理，如订单、物流信息的汇总、生成业务报表、统计等功能。

1.2 系统使用范围

通达物流系统的使用(App)并无地理位置限制，全世界只要有因特网的地方都能登录、查看、浏览系统网页。

但寄件/取件功能使用范围目前为：中国大陆（港澳台除外）内的同一个城市，即用户与快递员必须在同一个城市内。

1.3 引用文档

通达物流系统需求文档.docx

2 系统需求

2.1 功能需求

通达物流系统主要包含以下功能：

·        用户通过手机 App(iOS/Android) 发起快递下单请求并支付

·        快递员通过自己的手机 App 上报自己的地理位置，每 30 秒上报一次

·        系统收到快递请求后，向距离用户直线距离 5km 内所有的快递员发送通知

·        快递员需要进行抢单，第一个抢单的快递员得到配单，系统向其发送用户详细地址

·        快递员到用户处收取快递，并记录到系统中：已收件

·        快递员将快递送达到目的地，并记录到系统中：已送达

系统使用者包括：用户、快递员、管理员。

2.2 非功能性需求

预计系统上线后三个月日单超过 1 万，一年日单超过 50 万。

综合业务、性能、安全、运维目标，系统需要满足以下非功能性需求：

1.      查询性能目标：

a.      平均响应时间<300ms, 95%响应时间<500ms，单机 TPS >100

2.      下单性能目标：

a.      平均响应时间<800ms, 95%响应时间<1000ms，单机 TPS >30

3.      抢单性能目标：

a.      平均响应时间<800ms, 95%响应时间<1000ms，单机 TPS >30

4.      可用性：

a.      系统核心功能可用性目标 > 99.97%

5.      安全性：

a.      系统可拦截 XSS、SQL 注入、CSRF 攻击

b.      密码数据散列加密

c.      客户端数据 HTTPS 加密

d.      外部系统间通信对称加密

e.      防止恶意外挂 下单/抢单

6.      数据持久化目标：> 99.99999%

7.      可维护性：

a.      支持 DevOps 自动化运维、持续集成/部署/交付、监控、报警等。

3. 功能概述

• 用户通过 app 发起快递下单请求并支付

• 快递员通过自己的 APP 上报自己的物理地位，每 30 秒上报一次

• 系统收到快递请求后，向距离用户直线距离 5km 内的所有快递员发送通知

• 快递员需要进行抢单，第一个抢单的快递员得到配单，系统向其发送用户详细地址

• 快递员用户处收到快递，并记录到系统中：已收件

• 快递员将快递送到目的地，并记录到系统中：已送达

用例图

3.1 系统部署图与整体设计

• 先上线 ios 和 Android 客户端，采用混合应用开发

• 后端系统使用微服务架构——Spring cloud，以适应日后的弹性伸缩

• 由于系统上线时间紧，现阶段运维成本较高，系统将直接部署在阿里云容器镜像服务上

• 直接使用阿里云提供的 DNS、CDN、Load Balance、API GateWay、Redis、Object Storage，Rocket MQ，短信服务，以及 MySql 主从服务

• 用户 Auth 服务通过微信授权登陆

• 客户端集成支付宝和微信支付

部署图

系统第一版（三月版）业务相对简单，流量有限——峰值 QPS 预计不超过 10，所以保证尽快上线为第一目标。如上有色区域为核心业务，分成三个独立的微服务：订单服务、定位服务、推送服务：

• 订单服务：主要包括订单的创建、销毁、进度更新，发起抢单，派单等等服务

• 定位服务：主要用途是通过 Redis 记录快递员位置信息；并提供位置匹配算法

• 推送服务：顾名思义，与客户端保持长连接的服务：推送抢单，推送订单进度等等

3.2 订单服务活动图

活动图

该场景的主要流程如下：

1. 寄件人下单并支付

2. 系统向附近 5km 内的快递员发起抢单

3. 快递员抢单

4. 抢单成功后，系统给寄件人发送寄件码；快递员收到订单详细信息，并上门取件

5. 快递员上门取件后，输入取件码，开始派件；系统给收件人发送收件码

6. 快递员派送成功，输入收件码

7. 订单完成

3.3 订单状态图

状态图

3.4 下单抢单时序图

3.4.1 下单前

快递员 APP 每 30 秒上报一次位置，并存于 Redis；用户打开 APP 即可看到附近骑手定位。

用户

定位匹配算法：

• 早期，快递员少的情况下，订单位置匹配采用全部遍历法，用取件地址经纬度和快递员最新经纬度，根据欧氏距离公式计算直线距离，进行匹配

• 中期，合并快递员位置，用经纬度精度为小数点后两位（距离误差 1KM）做区域定位，先选定区域，后进行区域内快递员位置匹配

• 后期，在中期区域定位的基础上，根据导航路线距离及预估上门时间进行匹配

3.4.2 下单时

下单过程如下所示：

1. 用户提交订单，服务器创建订单

2. 用户完成支付，通知服务器开始抢单

3. 推送服务向附近 5 公里以内的快递员广播抢单（快递员抢单见下图）

4. 抢单成功，用户收到寄件码

订单时序图

3.4.3 快递员抢单过程

快递员的抢单流程如下所示：

1. 接上图，推送服务向附近快递员发起抢单

2. 快递员收到抢单通知后，立即抢单

3. 抢单成功，系统返回订单详情

4. 推送服务同时给用户发送寄件码

骑手

抢单规则：

• 早期仅使用 DB 锁，先到先得

• 中期将订单状态置于 Redis，使用分布式锁

• 后期再增加预估匹配算法

4. 三个月后系统升级

第一版计划是尽快上线，因此只是设计的移动端的部署图。三个月后，若业务稳定，系统需要进一步升级，实现日订单 50 万的目标。改造计划如下：

1. 同时上线 PC 端和移动端；并增加 BFF 层，解耦前后端部署设计

2. 后台系统由先前简单的读写分离模式，细分更多的微服务应用集群，包括用户服务、骑手服务、订单服务、推送服务、支付服务、后台系统、评价系统、通讯系统等等

3. 订单结束后，设计基于 MySql 到 MongoDB 的冷热分离

4. 建立后台系统的大数据分析平台

5 一些技术点

寻找算法-系统收到新的快递请求后，如何快速寻找用户 5km 内的快递员，提醒他们抢单？

将快递员的实时位置缓存在 Redis?