架构师训练营第 1 期 - 大作业 1

背景

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

说明：技术部没技术负责人，由产品负责人兼管（产品负责人为原某互联网大厂的产品总监，研发出身），架构师（你）是技术部最资深的技术人员。

产品需求

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

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

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

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

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

• 快递员将快递送到目的地，并记录到系统中：已送达说明：预计上线后三个月日单超过 1 万，一年日单超过 50 万

系统概要设计

用例图

• 用例 1 ：用户通过 app 下单并支付

• 用例 2 ：快递员通过 app 上报地理位置

• 用例 3：系统向 5km 内的快递员发送抢单通知

• 用例 4：系统向抢单成功的快递员发送用户地址

• 用例 5：快递员收取快递

• 用例 6：快递员送达快递

活动图

• 下单抢单场景的业务活动图

1. 3 个角色：用户、系统和快递员

2. 用户下单之后，系统收到下单请求，同时用户支付订单

3. 订单是已支付状态后，系统发送通知给 5km 内的快递员

4. 快递员收到通知，开始抢单

5. 系统收到抢单请求，对于第一个抢单的快递员，发送用户地址给快递员，对于抢单失败的，快递员收到失败通知

6. 快递员收到用户地址后，去收取快递，系统标记订单为已收件

7. 快递员送达快递后，系统标记订单为已送达

部署图

• 系统部署图

1. App 请求 CDN，请求的静态资源 CDN 中有就直接返回，否则继续

请求反向代理服务器，动态资源就直接转发给反向代理

1. 反向代理服务器接收到的是静态资源的话，就直接返回，是动态资源的

话，就继续请求负载均衡服务器

1. 负载均衡服务器接收到动态请求，继续请求网关服务器

2. 5. 网关服务器本身注册到注册中心，根据请求路径调用不同的微服务

3. 7. 订单微服务本身注册到注册中心，并接收来自网关服务器的请求

4. 9. 快递员微服务本身注册到注册中心，并接收来自网关服务器的请求

5. 订单服务调用快递员微服务

6. 12. 13. 数据库 mysql 服务器采用一主多从架构，写操作发生在主库，

主库有备份库，主库宕机时，备份库可以升级为主，2 个从库负责读操作，

备份库和从库都从主库同步数据

1. 15. 微服务读写数据库

2. 17. 18. 缓存服务器 redis 采用分片部署，每台分片 redis 采用主备部署

3. 20. 微服务读写缓存

4. 22. 23. 消息队列服务器采用集群部署，每台 kafka 分片，提升整体性能

5. 25. 微服务生产消息和消费消息

时序图

• 下单抢单场景的服务器时序图

a. 包括几个子场景：下单、通知快递员、抢单、上报位置

b. 下单场景中，订单入库之后，生成异步消息来处理通知逻辑，然后直接返回给用户

c. 通知快递员场景中，根据待处理订单的位置，从缓存中获取附近的快递员，筛选找

到附近 5km 内的快递员，并发送消息异步通知快递员，启动异步线程每隔一段

时间再检查订单状态，如果没有人抢单，就再发送通知

d. 抢单场景中，第一个抢单的快递员信息保存到订单中并显示抢单成功（快递员信息

在通知场景中用来判断订单是否已经抢单），抢单失败的快递员显示抢单失败

e. 上报位置场景中，快递员的地理位置保存在缓存中，根据地理位置得到所属区域，同

区域的快递员保存在一个列表中

状态图

• 订单状态图

1. 下单之后，是待支付状态

2. 主动取消或者超时未支付，变成取消状态

3. 支付之后，就是已支付状态

4. 系统安排快递员的过程中，都是待收件状态

5. 待收件状态有几个内部转换状态，初始是未接单状态，有快递员就会变成已通知，快递员未抢单，又会变成未接单，5km 内没有快递员，一直就是未接单，快递员抢单之后就是接单状态

6. 快递员去用户地址收取快递，就是已收件状态

7. 快递员配送过程中，就是配送中的状态

8. 快递员送达目的地，就是已送达状态

9. 订单送达之后，最后会变成完成状态

技术难点

• 涉及到外部系统对接，比如 app 消息推送和地图显示快递员配送位置，app 消息推送可以利用成熟的第三方平台，能够加快研发速度；地图服务也可以调用成熟的第三方服务；因为依赖第三方平台，需要尽早调研，评估交付风险

• 上线后日单超过 1 万，尽早做全链路压测或者对关键业务场景抢下单和抢单进行压力测试，根据性能曲线服务器配置适当冗余

• 一年日单超过 50 万，mysql 后续要做分片，需要提前引入分片中间件，以后做分片比较轻松

• 系统通知 5km 内的所有快递员场景中，需要进行算法优化，第一版可以这样设计，比如把地图分成 5km 宽的正方形区域，根据订单的地址位置，找到所在区域，把区域相邻的 8 块区域和当前区域在内的 9 块区域的快递员都找到，再筛选 5km 内的快递员发送通知，这样保证能通知到临界区域的快递员