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

大作业（一）

背景：

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

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

升级后部署图：