大作业（一）

背景：

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

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

产品需求：

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

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

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

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

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

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

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

技术方案建议：

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

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

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

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

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

练习要求：

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

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

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

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

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

• 订单状态图模型

系统关键用例图

系统用户分别是：用户（寄件人）、快递员和系统。

寄件人功能包括：下单、支付以及订单查看。

快递员功能包括：抢单、位置上报、更新订单状态。

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

下单、抢单时序图

系统部署图

订单状态图

以下是老师给的一种解法

通达核心业务架构设计方案（草案）

设计目标

1. 整体架构弹性可伸缩，满足订单量从零到一百万的持续增长过程。

2. 从节约成本角度，早期部署方案采用精简部署，满足需求的前提下部署尽量少的服务器。

3. 未来可能会迁移到第三方云计算平台，因此技术选型尽量选取能兼容主流云厂商的开源技术方案。

用例模型

用例说明

1. 核心业务都需要通过订单进行管理，因此抽象出“订单管理”用例，供其他用例使用。

2. 为了加快并简化核心用例“订单匹配快递员”的操作，该用例不和订单管理用例交互。

部署模型

部署说明

1. CDN 用来加速用户图片访问速度

2. 负载均衡服务器早期采用 Ngnix 部署，将来并发量大的时候用 LVS

3. 网关服务器早期采用双机部署，未来根据业务量持续扩容

4. 微服务框架采用 Dubbo

5. 消息队列采用 ActiveMQ

6. 早期不准备部署 Redis，快递员位置直接记录在配单微服务中

7. 数据库采用 MySQL 并配置主从复制

下单抢单活动模型

订单状态模型

关键算法方案

订单位置匹配算法

1. 早期，快递员少的情况下，订单位置匹配采用全量遍历法，用取件地址经纬度和快递员最新经纬度，根据欧氏距离计算直线距离，进行匹配。

2. 中期，合并快递员位置，用经纬度精度为小数点后两位（距离误差 1KM）做区域定位，先选定区域，后进行区域内快递员位置匹配。

3. 后期，在中期匹配定位的基础上，根据导航路线距离及预估上门时间进行匹配。

抢单加锁算法

1. 早期用 Redis 实现抢单加锁

2. 未来计划用 Zookeeper 实现分布式锁