写点什么

【架构师训练营 1 期】大作业一

用户头像
诺乐
关注
发布于: 2021 年 01 月 10 日

大作业(一)

背景:

通达是某上市公司全资投资成立的一家物流快递公司,主要进行同城快递业务,公司刚刚成立,组建 20 人技术部门,准备两个月后系统开发完成上线。

需求分析:

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

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

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

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

快递员到用户处收取快递,并记录到系统中:已收件。

快递员将快递送到目的地,并记录到系统中:已送达。


用例图:


其他因素分析:

预计上线后三个月日单超过 1 万,一年日单超过 50 万。

查询性能:平均响应时间 < 500ms, 95%响应时间 < 800ms

下单性能:平均响应时间 < 800ms, 95%响应时间 < 1000s

系统核心功能可用性: > 99%

系统安全性目标:可拦截 XSS 攻击,SQL 注入,CSRF 攻击,密码数据散列加密,客户端数据 HTTPS 加密,外部系统间通信加密。

系统整体设计:

先上线 ios 和 Android 客户端,采用混合应用开发。

后端系统使用微服务架构——Spring cloud,以适应日后的弹性伸缩。

由于系统上线时间紧,现阶段运维成本较高,系统将直接部署在阿里云容器镜像服务上。

直接使用阿里云提供的 DNS、CDN、Load Balance、API GateWay、Redis、Object Storage,Rocket MQ,短信服务,以及 MySql 主从服务。

用户 Auth 服务通过微信授权登陆。

客户端集成支付宝和微信支付。


第一个版本部署图:


系统第一版业务相对简单,流量有限——峰值 QPS 预计不超过 10,所以保证尽快上线为第一目标。

如上有色区域为核心业务,分成三个独立的微服务:订单服务、定位服务、推送服务:

订单服务:主要包括订单的创建、销毁、进度更新,发起抢单,派单等等服务。

定位服务:主要用途是通过 Redis 记录快递员位置信息;并提供位置匹配算法。

推送服务:顾名思义,与客户端保持长连接的服务:推送抢单,推送订单进度等等。


业务活动图:


该场景的主要流程如下:

1、寄件人下单并支付。

2、系统向附近 5km 内的快递员发起抢单。

3、快递员抢单。

4、抢单成功后,系统给寄件人发送寄件码;快递员收到订单详细信息,并上门取件。

5、快递员上门取件后,输入取件码,开始派件;系统给收件人发送收件码。

6、快递员派送成功,输入收件码。

7、订单完成。


订单状态图:


下单前快递员 APP 每 30 秒上报一次位置,并存于 Redis;用户打开 APP 即可看到附近骑手定位。


下单时序图:


下单过程:

1、用户提交订单,服务器创建订单。

2、用户完成支付,通知服务器开始抢单。

3、推送服务向附近 5 公里以内的快递员广播抢单(快递员抢单见下图)。

4、抢单成功,用户收到寄件码。


定位匹配算法:

早期,快递员少的情况下,订单位置匹配采用全部遍历法,用取件地址经纬度和快递员最新经纬度,根据欧氏距离公式计算直线距离,进行匹配。

中期,合并快递员位置,用经纬度精度为小数点后两位(距离误差 1KM)做区域定位,先选定区域,后进行区域内快递员位置匹配。

后期,在中期区域定位的基础上,根据导航路线距离及预估上门时间进行匹配。


派单时序图:


抢单流程:

1、推送服务向附近快递员发起抢单。

2、快递员收到抢单通知后,立即抢单。

3、抢单成功,系统返回订单详情。

4、推送服务同时给用户发送寄件码。


抢单时序图:


抢单规则:

1、中期使用分布式缓存(Redis)锁。

2、后期再增加预估匹配算法。


三个月后升级:

第一版计划是尽快上线,因此只是设计的移动端的部署图。三个月后,若业务稳定,系统需要进一步升级,实现日订单 50 万的目标。改造计划如下:

同时上线 PC 端和移动端;并增加 BFF 层,解耦前后端部署设计。

后台系统由先前简单的读写分离模式,细分更多的微服务应用集群,包括用户服务、骑手服务、订单服务、推送服务、支付服务、后台系统、评价系统、通讯系统等等。

订单结束后,设计基于 MySql 到 MongoDB 的冷热分离。

建立后台系统的大数据分析平台。


升级后部署图:


用户头像

诺乐

关注

还未添加个人签名 2018.12.01 加入

还未添加个人简介

评论

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