通达同城快递架构方案

1. 项目背景

通达是一家物流快递公司，主营同城快递业务，较传统快递服务相比，有更快的处理速度。将投入 20 人技术团队，于 2 个月后系统开发完成上线。预计上线后 3 个月日订单超过 1 万,一年日订单超过 50 万。

2. 产品需求

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

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

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

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

• 快递员到用户处收取快递,并记录到系统中:已收件

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

3. 设计概述

同城快递系统包含用户端、快递员端、后台管理系统。为同城快递业务提供底层技术支持。提供对用户、快递员易用、可靠、快速的服务。后台管理系统对订单、支付、物流相关信息进行聚合，在有问题时及时响应。

3.1 功能概述

• 用户端包含登录、下单、支付、查看物流进度等功能。

• 快递员端包含登录、上报位置、抢单、收件、确认送达功能。

• 后台管理系统包含查看订单、物流进度、用户管理、财务报表等功能。

3.2 非功能约束

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

• 查询性能目标：平均响应时间<200ms,95%响应时间<500ms，单机 QPS>100。

• 下单性能目标：评价响应时间<200ms,95 响应时间<500ms，单机 TPS>80。

• 系统核心功能可用目标:大于 99.99%。

4. 系统部署图与整体设计

系统上线时预计部署 7 台物理机，4 个子系统，和外部第三方 1 个系统（微信支付）交互

4.1 系统部署图

• 网关服务器部署 1 台，对请求进行分发和简单的负载均衡。

• 微服务系统部署 2 台，每台上要部署订单服务，用户服务，财务服务。避免服务单点

• 数据库系统部署 2 台，需要配置主从复制，保障数据安全。

• 分布式缓存服务系统部署 2 台，实现数据缓存和分布式锁功能。

• 外部需要和微信支付系统交互。

• 后期订单量激增时再引入消息队列，来提供更好的写入性能。现阶段一万日订单按一小时处理完计算，单机处理完全够用。

• 使用微信小程序替代 APP，不做 PC 端。APP 需要投入的人力较多，而且 IOS、安卓应用市场的上架标准，审核速度不一致。小程序可以很好的屏蔽安卓、IOS 系统的差异，应用上线审核周期较短，与微信支付对接会更加方便。如果时间充足，可以考虑接入支付宝。

4.2 系统关键用例图

4.3 下单抢单业务活动图

• 将整个城区分成若干个 500 米为边长的正方形区域，对其进行编号。

• 小程序中可以获取用户、快递员的地理位置。

• 快递员上报地理位置时，计算出对应编号再将其存储在分布式缓存 Redis 中，存取速度更快。

• 下单时获取当前用户直线距离 5km 内区域的编号，匹配对于区域编号内的快递员。

• 直接推送小程序通知。

• 初期路径规划，让快递员决定。

• 后期可以对订单合并，送快递路线规划做优化。

4.4 下单抢单场景时序图

• 用 Redis 分布式锁对订单进行锁定，以防止订单被多人抢到。

• 后期可使用 Zookeeper 做分布式锁，以提供更高的可靠性。

• 初期订单量小，优先使用 Redis 实现简单的分布式锁

4.5 订单状态图

5. 人员分配

中间件搭建

1. 分布式缓存 Redis 1 人

2. MySQL 主从复制 1 人

3. 网关服务 1 人

4. 运维 1 人

业务开发

1. 订单功能 下单、订单状态变更全流程 2 人

2. 支付功能 支付对接 1 人

3. 财务报表 1 人

4. 用户功能 注册、登录、用户管理 2 人

5. 客户位置、快递员位置 1 人

6. 抢单 1 人

7. 前端 用户端、快递员端、后台管理系统 3 人

8. 产品 1 人

9. 测试 3 人