写点什么

极客大学架构师训练营大作业

用户头像
Meow
关注
发布于: 2021 年 01 月 08 日

大作业(一)

背景:

通达是某上市公司全资投资成立的一家物流快递公司,主要进行同城快递业务,公司刚刚成立,组建 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 进行离线存储。


下单抢单场景


业务活动图

服务器时序图


说明:

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


订单状态图

说明:

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


用户头像

Meow

关注

还未添加个人签名 2018.05.09 加入

还未添加个人简介

评论

发布
暂无评论
极客大学架构师训练营大作业