大作业（一）

背景：

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

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

产品需求：

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

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

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

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

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

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

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

技术方案建议：

用户下单请求通过负载均衡服务器分发给下单网关集群

使用消息队列向 5km 内的快递员发送通知（消费者服务器获取的消息内容包括：用户地址，快递员列表）

快递员实时位置缓存在分布式缓存 Redis 中

数据存储使用 MySQL，第一个上线版本不要求做数据分片，但要做主从复制

说明：以上技术方案建议是公司请的外部技术顾问（该顾问是产品负责人的朋友）给出的，具体是否合适请架构师自己定夺

练习要求：

以 PPT 方式输出系统概要设计（顶层架构设计），包含以下模型，进行架构设计评审：

• 系统关键用例图，描述产品主要功能需求

• 下单抢单场景的业务活动图，角色领域泳道模型（角色：用户，快递员，系统）

• 系统部署模型：描述系统服务器关系（如：网关服务器，微服务服务器，负载均衡，分布式缓存，消息队列服务器，消息消费者服务器，数据库读写分离）

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

• 订单状态图模型

系统关键用例图

系统整体部署图

分析：

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

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

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

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

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

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

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

下单抢单场景

业务活动图

服务器时序图

说明：

在下单抢单这个场景中，涉及到用户、快递员、系统三个角色，用户提交订单并支付成功后，系统会生成该笔订单并计入数据库，然后调用位置计算服务筛选出快递员，并推送抢单通知；快递员抢单成功后，系统将快递员信息、用户信息更新到订单，并将订单推送给快递员，同时用户端的订单详情也会显示快递员的信息。

订单状态图

说明:

考虑了订单出现异常的情况，包括支付失败、无法联系上用户取件、配送失败，另外订单还应当有取消和删除状态。