架构师训练营大作业一

用户头像
子豪sirius
关注
发布于: 2020 年 09 月 16 日



通达物流快递公司是某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. 更新订单状态



用户头像

子豪sirius

关注

还未添加个人签名 2018.05.03 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营大作业一