背景：

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

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

产品需求：

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

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

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

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

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

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

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



1 设计概述：



通达快递系统，主要进行同城快递业务，兼顾用户体验的同时，系统需要在2个月内上线，实现公司在同城配送业务市场拓展的战略目标。

1.1 设计目标：

1. 整体架构弹性可伸缩，满足订单从零到一百万的的持续增长

2. 从节约成本角度，早期精简部署，满足需求的需求情况下使用尽量少的服务器

3. 未来迁移到云计算平台， 所以技术选型尽量选取兼容主流云厂商的开源技术方案



2020年12月31日 参考老师讲解更新：

涉及概述过于简单，对于架构的思路没有描述， 相对于在非功能概述中一些性能目标的描述还需要一个总体的涉及思路的说明



1.2 功能概述



系统主要功能：　用户通过app下单， 系统收到下单请求后，通知距离用户附近的快递员， 快递员进行抢单， 枪单成功后， 快递员获取用户详细地址，快递员上门收取货物，确定配送货物配送价格支付， 快递员配送， 将货物送达目的地。





1.3 非功能概述



系统未来预计预计上线后三个月日单超过 1 万，一年日单超过 50 万



1. 查询性能⽬标：平均响应时间<300ms，95%响应时间<500ms，单机TPS>100；

2. 下单性能⽬标：平均响应时间<800ms，95%响应时间<1000ms，单机TPS>30；

3. 支付性能⽬标：平均响应时间<800ms，95%响应时间<1000ms，单机TPS>30；

4. 系统核⼼功能可⽤性⽬标：>99.97%；

5. 系统安全性⽬标：系统可拦截XSS 、SQL注入攻击、CSRF攻击，密码数据散列加密，客户端数据 HTTPS加密，外部系统间通信对称加密；

6. 数据持久化⽬标：>99.99999%。



2. 概要设计



2.1 系统用例图



用户用例





用户用例





2020年12月31日 参考老师讲解更新：

增加订单管理用例，统一由订单管理更新订单状态



• 用户登录后通过 App 发起快递下单请求并支付

• 可以通过App对订单状态进行查询



快递员用例



快递员用例



2020年12月31日 参考老师讲解更新：

增加订单管理用例，统一由订单管理更新订单状态



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

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

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

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

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



2.2　抢单业务活动图





• 用户通过App下单请求， 并发给定位信息，系统根据请求生成订单信息

• 根据订单地理坐标，已经目前系统中块递员地理位置，将向订单范围5Km内的快递员推送订单

• 快递员收到通知后进行抢单

• 抢单失败继续接收订单通知， 抢单成功后可以接收到地址信息通知

• 快递员上门取件确认运费后，用户进行支付，订单支付成功后快递员取件

• 快递员完成配送工作。



2.3　系统部署模型





系统部署模型



• 数据库使用使用3台服务器安装数据库MySQL一主多从模式

• 应用服务器2台提供订单，用户相关服务。

• 管理端服务器2台，提供业务人员用户管理， 订单查询，交易查询， 报表查询等工作

• 缓存服务器2台， 缓存相关应用使用数据，如快递员地理位置， 前期交易量少可以不使用

• 推送服务器2台， 推送订单及用户地址信息

• 反向代理服务器2台，静态文件存放以及粘性会话

• 负载均衡 2台 ，用于请求均匀分发。

• 代理服务器2台，用于消息推送。

• CDN服务器可以租用公有云CDN服务



操作系统选用Linux （CentOS等）， 缓存可以选用Redis， 方向代理，负载使用nginx，内部消息提送可以使用kafka。先进行压测后续可以通过横向扩展提高吞吐率，

网关服务，用户管理、订单服务、支付服务等子系统。

支付功能考虑现在常用的，支付宝、微信、商业银行在线支付， 可考虑成熟的商业银行聚合支付方案。



2020年12月31日 参考老师讲解更新：

增加CDN服务器，前端开发，物理部署这部分还是有些盲点，需要了解一下CDN具体使用方式；

平时硬件资源申请基于现有系统的评估，针对新的业务硬件资源，CPU，内存，硬盘申请没有具体参考，默认配置4Cpu 8G内存， 后续通过系统上线监控统计，再动态调整。

Redis服务器由于前期交易量较少可以不配置，应用服务器的配单服务内存中处理。



2.4 下单抢单场景子系统序列图





系统序列图





2.5 订单状态图模型



状态模型图





3.关键算法

3.1 位置匹配算法

1. 早期通过位置信息， 通过欧氏距离公式，直接计算两点最短距离进行匹配

2. 中期使用经纬度精度小数点后两位（距离误差1KM）， 做区域定位，先选定区域在在区域内进行快递员匹配

3. 后期，在区域定位基础上，通过导航服务预估需要上门时间

3.2 抢单加锁算法

1. 早期使用Redis实现抢单加锁

2. 后期通过Zookeeper实现分布式锁



2020年12月31日 参考老师讲解更新：

这部分参考老师讲解添加，架构评审中除了梳理业务流程外， 也要对关键的算法进行讨论， 避免核心算法问题导致后续系统问题。



4. 团队分工



团队建设， 如何拆分小组，开发规范， 流程规范， 版本规范及管理（代码，文档）， 上线流程规范， （开发，测试，投产， 运维）



5. 实施计划



实施计划 2到排期方式指定实施计划。



























参考引用



架构师训练营作业-李智慧老师相关讲义

Photo by Marco Trinidad from Pexels