架构师训练营大作业一



通达物流快递公司是某XX上市公司全资成立的子公司，主要经营同城快递公司。公司刚刚成立，业务在起步阶段，急需快速上线一套核心业务系统实现公司业务，并支持业务后续发展。现进行本公司的快递服务系统第一版的架构设计。

1. 设计概述

快递服务系统是本公司的核心服务系统，承担了公司同城快递核心业务。第一版系统以实现基本的业务为主，要求能核心功能快速上线，同时要保证系统的稳定。

1.1 功能概述

根据本公司的业务特点，系统的应用场景包括以下几部分：用户使用场景、快递员使用场景和系统其它场景。公司主要承担的业务说明请见业务需求说明书《XXXXX》。

1.1.1 角色说明

本系统应用场景的角色包括以下：

• 用户：指有收寄快递需求的城市居民或者企业。

• 快递员：负责接收用户快递并寄出的本公司招聘的员工。

1.1.1 用户使用场景

用户有以下的功能需求通过本公司APP使用快递服务，包括的功能有：

• 注册：注册为本公司服务用户

• 登录：登录APP

• 信息维护：修改用户信息，包括联系电话、地址等

• 快递下单：用户通过下单功能进行同城寄快递，为本公司提供的关键业务

• 订单支付：快递员收取快递后，支付订单商品。

• 订单删除

1.1.2 快递员使用场景



快递员使用场景包括：

• 注册：在公司管理端进行系统快递员注册。

• 登录：快递员使用专用APP登录，登录后即开始记考勤。

• 发送地理位置：定时发送快递员地理位置到本系统

• 抢订单：系统推送通知到快递员APP，进行抢订单

• 快递收取：抢单成功后，到用户地点进行快递收取，随后运送到物流中心

• 快递派送：派送快递到目的地

1.1.3 系统其它功能

系统还包括推送通知到离下单用户5km以内的快递员手机APP上。

1.2 非功能约束

上线后三个月支持日单1万，一年后日单超50万。支持同时100名快递员在线抢单。

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

系统采用微服务框架，划分以下的微服务：

• 订单微服务：负责用户快递单下订、订单状态管理

• 用户微服务：管理用户信息

• 快递员微服务：管理快递员信息

• 支付微服务：对接第三方支付网关，承担支付功能；并与第三方机构进行对账

• 位置信息微服务：定时更新快递员信息

• 推送微服务：推送通知

• 抢单微服务：快递员抢单

2.1 系统组件图

整个系统客户端区分B端和C端，B端是管理端，用户对系统进行管理。C端用手机APP实现，主要分为用户版和快递员版。

主体系统组件如下：



2.2 系统部署图



• 各个微服务部署在一个集群上，初期每个机器部署所有微服务，采用5台服务器建立服务器集群（每个微服务5个实例）

• 初期不考虑分库，所有服务访问同一个服务器集群。数据库读写分离，主从复制。

• 外部请求通过负载均衡服务器接入

• 服务网关进行请求分发

• Redis缓存服务器、消息队列服务器和服务治理服务器，另设机器

• 支付网关对接第三方支付商如支付宝、微信、银联

2.3 下单抢单场景设计

下单抢单是最关键的业务场景，现对其进行设计描述

2.3.1 下单抢单场景活动图



1. 用户下单后提交系统

2. 快递员定时推送地理位置到服务器

3. 系统收到下单的快递单，推送通知到离收取快递地点5km以内的快递员

4. 快递员收到通知后即进行抢单，抢单成功后获取快递详细信息

5. 快递员到用户处收快递，用户进行支付，支持成功则收取快递

6. 快递运往物流中心

7. 由物流中心把快递派送合适快递员发送

8. 快递员把快递发往目的地

2.3.2 下单抢单服务时序图

下单到抢单成功的时序图如下：



1. 用户下单通过APP提交订单下单

2. 订单服务生成发送快递单推送请求到推送服务

3. 推送服务做以下操作：

• 为当前订单生成唯一token保存在Redis，保存时间设抢单持续时间

• 当前订单生成清单消息放在消息队列，时间设为抢单持续时间

• 在Redis保存的快递员位置选择合适快递员（快递收集点5km以内）

• 推送通知给合适快递员（推送内容包括订单号、Token、快递地点等）

1. 快递员收到通知后可以开抢，调用抢单服务

2. 抢单服务检查在Redis检查Token是否合法；然后在消息队列检查是否有该快递单消息，如果有则取出。检查消息队列和取出消息要做并发同步控制，保证一张快递单只能有一个操作。如果不存在该快递单或者Token已经不存在，则抢单失败。

3. 抢单完成后，删除对应的Token，并返回给抢单成功的快递员

4. 发送消息到订单服务，更新订单状态（已接单、以及记录要来收快递员的信息）

2.3.3 订单状态图



1. 快递下单后接入待接单状态

2. 用户可以取消待接单状态的订单

3. 快递员抢到单后，状态变为待支付

4. 快递员收取快递时，用户进行支付，支付完已收件

5. 快递员把快递运往物流中心，由物流中心分配派送快递员，状态改为已分配

6. 派送快递员开始派送，送达目的地后状态为已送达，最后结束

3. 各服务具体设计

3.1 推送服务设计

推送服务在收到订单下单后，负责推送订单5KM以内的快递员通知。包含了推送微服务应用、Redis、消息队列这些组件。

3.1.1 推送服务组件图



3.1.2 推送服务活动图

• 根据订单下单的位置计算5KM范围

• 从Redis缓存获取5KM范围内的快递员列表

• 生成抢单Token，保存在Redis

• 生成抢单消息，放在消息队列里面

• 发送通知到对应有资格的快递员

3.2 抢单服务设计

快递员收到通知后，可以进行抢单，涉及的组件如下。

3.2.1 抢单服务组件图



3.2.2 抢单服务活动图

1. 快递员收到通知后开始抢单

2. 抢单微服务检查送来的Token是否合法

3. 如果合法，这以单线程同步的方式获取消息队列里面的订单信息

4. 如果获取成功，同步删除Redis缓存的Token

5. 返回抢单成功

6. 更新订单状态