架构师训练营大作业（一）

背景：

通达是某上市公司全资投资成立的一家物流快递公司，主要进行同城快递业务，公司刚刚成立，组建 20 人技术部门，准备两个月后系统开发完成上线，你是后端架构师，请你完成系统顶层架构设计，并组织架构评审会议。

产品需求：

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

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

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

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

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

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

• 说明：预计上线后三个月日单超过 1 万，一年日单超过 50 万

功能概述

1. 用户在用户端 APP 自助下单并支付

2. 快递员端 APP 每隔 30 秒自动上报一次位置信息

3. 用户支付后，系统会将订单推送给距离用户 5km 以内的所有快递员

4. 快递员抢单后，由系统下发用户的取件地址给抢到单的快递员

5. 系统将得到配单的快递员信息发送给用户，用户可以查看该快递员的位置、联系方式

6. 快递员取件后在快递员端 APP 标注订单状态为已收件

7. 快件运送过程中，用户可以持续查看快递员的位置、联系方式

8. 快递员将快件送达后在快递员端 APP 标注订单状态为已送达

9. 用户可以查询三个月内的历史订单

非功能性需求

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

技术要点分析

1. 快递员的位置信息是一个近实时数据，并发读写压力较大，使用 MySQL 会严重影响性能，并且位置数据没有必要进行持久化，因此使用 Redis 集群以 KV 方式存储快递员位置，其中 Key 是快递员的 ID，Value 是序列化的位置数据，并且新版的 Redis 已经有 Geo 组件可以直接支持基于位置信息的计算。

2. 订单信息的查询性能同样使用 Redis 缓存进行优化，这一批 Redis 服务器可以与负责位置信息的 Redis 服务器分开部署。

3. 支付服务调用第三方支付接口完成订单支付。

4. 订单服务在下单时会向位置计算服务发送用户的地址，位置计算服务计算出所有距离用户 5km 以内的快递员 ID，并将这些 ID 发送给消息队列，由推送服务拉取后异步通知各快递员。

5. 抢单是一个类似于秒杀的操作，需要在网关和抢单服务侧进行一定的限流措施，直接由抢单服务来处理并发请求，并将真正抢到单的快递员 ID 写入订单中。

6. 用户查询订单信息，使用 Redis 集群进行性能优化。

7. MySQL 中存储所有的快递员信息（联系方式）、以及近三个月内的所有订单信息，三个月以上的订单迁移至 ElasticSearch 进行离线存储。

用例图

部署图

状态图