大作业（一）

背景：

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

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

产品需求：

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

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

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

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

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

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

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

技术方案建议：

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

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

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

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

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

练习要求：

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

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

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

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

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

• 订单状态图模型

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

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

设计目标

• 整体架构弹性可伸缩，支持从零到百万订单量持续扩展的能力；

• 从成本考虑，前期部署采用精简方案（满足需求的情况下，尽量使用少的资源），运行期间可根据（上升的/调整的）业务量可弹性缩扩容。

• 选用适合于主流云厂商的开源组件解决方案，充分利用多云能力的同时，避免特定云厂商的 vendor-lockin；

用例图

用例图说明：

• 订单管理是系统的核心之一，未来可能其它微服务需要调用它，因此将其单独抽象为一个服务。

• 订单创建采用异步的方式，先创建并持久化到数据库。用户支付可能在创建后支付（立刻支付，也可能较长时间后支付），也可能不支付。因此采用异步的方式，支付完后则更新该订单的状态。（而不是创建订单时要求用户付款后才落库）。

• 为简化依赖，并加快“匹配订单与快递员的位置”服务，该服务在订单创建后立刻调用，不直接和订单管理服务交互。

系统架构图

系统架构图说明：

• CDN 租用云服务上的服务

• 负载均衡服务器使用 Nginx，业务量上来后使用 LVS

• 网关服务器采用双机热备，业务量上来后可水平扩展

• 使用消息队列服务器，能达到异步处理的作用，能有效地应对业务高峰，起到削峰填谷的作用。

• MySQL 服务器采用主从架构，读写分离。

• Redis 服务器在早期快递员数量小，其信息有限时，不采用。当快递员数量超过 10 万数量时，采用。

• 推送通知服务器作为单独的服务，其他微服务需要推送时则调用该服务。

下单抢单活动图

订单状态转换图

如图，我们的订单状态有 8 种。订单的起始状态为待支付，订单的终止状态有：支付失败、取件失败、配送失败、配送成功 4 中状态。