背景
通达是一款本地即时配送平台。公司秉承“通派无障，使命必达”的信念，专注于用移动和众包的方式解决 O2O 领域最大的痛点：居民的最后 5 公里配送。
公司刚成立，已组建了 20 人的技术部门，准备两个月后系统开发完成上线。第一季目标日订单 1 万。
功能概述
- 用户通过 app 发起快递下单请求并支付
- 快递员通过自己的 APP 上报自己的物理地位，每 30 秒上报一次
- 系统收到快递请求后，向距离用户直线距离 5km 内的所有快递员发送通知
- 快递员需要进行抢单，第一个抢单的快递员得到配单，系统向其发送用户详细地址
- 快递员用户处收到快递，并记录到系统中：已收件
- 快递员将快递送到目的地，并记录到系统中：已送达
用例图
非功能性需求
系统预计上线三个月，日订单超过 1 万；一年后，日单超过 50 万
- 查询性能：平均响应时间 < 500ms, 95%响应时间 < 800ms
- 下单性能：平均响应时间 < 800ms, 95%响应时间 < 1000s
- 系统核心功能可用性： > 99%
- 系统安全性目标：可拦截 XSS 攻击，SQL 注入，CSRF 攻击，密码数据散列加密，客户端数据 HTTPS 加密，外部系统间通信加密。
系统部署图与整体设计
- 先上线 ios 和 Android 客户端，采用混合应用开发
- 后端系统使用微服务架构——Spring cloud，以适应日后的弹性伸缩
- 由于系统上线时间紧，现阶段运维成本较高，系统将直接部署在阿里云容器镜像服务上
- 直接使用阿里云提供的 DNS、CDN、Load Balance、API GateWay、Redis、Object Storage，Rocket MQ，短信服务，以及 MySql 主从服务
- 用户 Auth 服务通过微信授权登陆
- 客户端集成支付宝和微信支付
部署图
系统第一版（三月版）业务相对简单，流量有限——峰值 QPS 预计不超过 10，所以保证尽快上线为第一目标。如上有色区域为核心业务，分成三个独立的微服务：订单服务、定位服务、推送服务：
-
订单服务：主要包括订单的创建、销毁、进度更新，发起抢单，派单等等服务
-
定位服务：主要用途是通过 Redis 记录快递员位置信息；并提供位置匹配算法
-
推送服务：顾名思义，与客户端保持长连接的服务：推送抢单，推送订单进度等等
订单服务活动图
活动图
该场景的主要流程如下：
- 寄件人下单并支付
- 系统向附近 5km 内的快递员发起抢单
- 快递员抢单
- 抢单成功后，系统给寄件人发送寄件码；快递员收到订单详细信息，并上门取件
- 快递员上门取件后，输入取件码，开始派件；系统给收件人发送收件码
- 快递员派送成功，输入收件码
- 订单完成
订单状态图
状态图
下单抢单时序图
下单前
快递员 APP 每 30 秒上报一次位置，并存于 Redis；用户打开 APP 即可看到附近骑手定位。
用户
定位匹配算法：
-
早期，快递员少的情况下，订单位置匹配采用全部遍历法，用取件地址经纬度和快递员最新经纬度，根据欧氏距离公式计算直线距离，进行匹配
-
中期，合并快递员位置，用经纬度精度为小数点后两位（距离误差 1KM）做区域定位，先选定区域，后进行区域内快递员位置匹配
-
后期，在中期区域定位的基础上，根据导航路线距离及预估上门时间进行匹配
下单时
下单过程如下所示：
- 用户提交订单，服务器创建订单
- 用户完成支付，通知服务器开始抢单
- 推送服务向附近 5 公里以内的快递员广播抢单（快递员抢单见下图）
- 抢单成功，用户收到寄件码
订单时序图
快递员抢单过程
快递员的抢单流程如下所示：
- 接上图，推送服务向附近快递员发起抢单
- 快递员收到抢单通知后，立即抢单
- 抢单成功，系统返回订单详情
- 推送服务同时给用户发送寄件码
骑手
抢单规则：
-
早期仅使用 DB 锁，先到先得
-
中期将订单状态置于 Redis，使用分布式锁
-
后期再增加预估匹配算法
三个月后系统升级
第一版计划是尽快上线，因此只是设计的移动端的部署图。三个月后，若业务稳定，系统需要进一步升级，实现日订单 50 万的目标。改造计划如下：
-
同时上线 PC 端和移动端；并增加 BFF 层，解耦前后端部署设计
-
后台系统由先前简单的读写分离模式，细分更多的微服务应用集群，包括用户服务、骑手服务、订单服务、推送服务、支付服务、后台系统、评价系统、通讯系统等等
-
订单结束后，设计基于 MySql 到 MongoDB 的冷热分离
-
建立后台系统的大数据分析平台
升级计划
网友评论