作业要求

背景

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

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

产品需求

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

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

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

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

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

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

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

技术方案建议

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

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

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

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

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

练习要求

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

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

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

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

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

• 订单状态图模型

说明：ppt 需要在备注区对模型图进行必要的备注说明

PS：练习要求是大作业的最低要求，建议自己代入角色，思考如何交出一份漂亮的设计文档，奠定自己在公司的地位。

设计文档

系统关键用例图

关键用例图

系统关键用例图主要描述用户和快递员在对应的 app 中的主要的场景用例。

联机系统部署图

联机部署图

本部署图非完整部署图，主要以联机应用架构的角度去描述部署逻辑。RPC 中间件的架构、Mysql（TDSQL）主从复制的架构、Redis 集群的架构以及消息中间件的架构这边就不再图中完整描述。本图增加一个 GlobalNamingService（GNS）域的部署部分，用于描述对于应用分片的大致架构设计。

子系统描述

一个集群满足如下条件：

• 无状态模式

• 配置一套 MySQL 主从节点（采用 TDSQL 一主两从的模式）

• 配置一套 Redis 集群（集群间不共享）

• 分片采用应用分片，每个分片为一个集群，分片统一使用 userId 进行，通过 GNS 基础服务完成

• 应用节点采用边车模式，边车完成 RPC 请求以及应用集群分片处理

• 配置一套基于 Nginx 的 LoadBalancer 集群，用于提供 http 相关的服务

一个集群的基本部署模式如下图：

单集群部署模式

Global Naming System - 全局名称系统

功能类似于 DNS 服务，用于公司内部用户信息的应用分片信息查询。获取应用分片后可以调用对应分片的应用集群。

在 RPC 的请求中，携带 userId:[userId]格式的 KV 信息后，sidecar 代理会到 GNS 系统中查询 userId 对应的应用分片集群名称，之后将请求转发到对应的应用分片集群进行处理。

GNS运作原理

User Domain（用户域）

功能描述

1. 用户基本信息：姓名、电话等身份信息

2. 收发地址信息的维护

3. 用户账户信息（钱包）

4. 用户支付信息（支付宝、银联、微信支付）

...

用户域采用应用分片，基于 GNS 全局名称服务，分片中不再进行数据分片，应用分片和应用分片之前无感知，应用按照无分片的模式进行开发和部署，分片问题前置至 GNS 系统。

部署模式

用户域部署模式图

Order Domain（订单域）

功能描述

1. 订单的新增

2. 订单状态修改

3. 订单的查询

...

部署模式

订单域部署模式图

Courier Domain（快递员域）

功能描述

1. 快递员的身份信息

2. 快递员账户信息

3. 快递员当前位置信息缓存

4. 5km 快递员信息匹配

...

部署模式

快递员域部署模式图

Payment Domain（支付域）

功能描述

1. 扣用户款进用户钱包

2. 扣用户款进平台中间账户

3. 扣平台中间账户进快递员账户

4. 对接各类第三方支付平台

5. 生成与第三方平台及财务域的对账信息

...

部署模式

支付域部署示意图

其中 DB 基础设施增加使用 TiDB，用于存储大批量的对账信息，并且增加 RocketMQ 作为消息中间件用于异步的支付请求处理。

Finance Domain（财务域）

功能描述

1. 用户账户的账务流水信息

2. 公司账户的账务流水信息

3. 快递员账户的账务流水信息

4. 生成与银行托管账户的对账信息

...

部署模式

财务域部署模式图

其中 DB 基础设施增加使用 TiDB，用于存储大批量的账务信息，并且增加 RocketMQ 作为消息中间件用于异步处理记账任务。

Auth Domain（鉴权域）

鉴权域提供用户登录的鉴权功能，提供两种登录鉴权的模式：

1. SSO 单点登录

2. OAuth2.0

ApiGateway（应用网关域）

功能描述

1. 用户登录鉴权

2. 用户会话保持

3. 限流熔断

4. 请求日志记录

...

部署模式

应用网关部署模式图

1. Nginx 集群用于处理 app 端的请求

2. Admin 集群用于修改网关配置相关数据，并可以控制网关集群的行为

Admin Domain（管理台域）

管理台域为系统管理员提供配置功能。

Push Domain（推送域）

推送域对接第三方消息推送平台为 app 提供消息推送功能

Delivery Domain（配送域）

配送域提供对 app 所有接口逻辑的接收转发（如用户信息查询，快递员信息查询等），除此之外主要还提供：

1. 快递员当前的配送会话

2. 对当前不在配送会话中的快递员进行抢单消息推送

3. 快递员的抢单功能

...

系统关键活动图

下图描述了从用户下单到配送完成的整个流程活动图，涉及角色包含下单用户、系统以及配送快递员。

下单及配送活动图

订单状态图

订单状态图

关键状态描述

1. 订单支付成功后的状态流转至订单取消状态时，需要退回已支付费用

2. 订单如果配送失败则需要支付退回的配送费用，这部分没有在图中明确指出，可以在几个设计点上进行考虑：（1）支付时预支付退回费用（2）退回收货时进行当面支付

下单抢单时序图

时序图仅描述各个领域之间的主要交互流程，诸多细节不在本图进行详细的展示

下单抢单时序图