一、设计概述

同城快递订单管理系统是公司“同城战略”的核⼼管理系统，承担着公司同城快递业务高效率，低成本的⽬标任务。

1.1 功能概述

系统主要功能包括：

1.1.1 客户可通过 App 下单，日后为了拓展渠道，还可能通过微信小程序，公众号, 在线 Web，400 人工客服等途径下单，微信，支付宝扫码等途径支付，同时可查看订单状态，轨迹。

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

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

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

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

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

1.2 非功能约束

系统未来预计上线三个月后⽇订单量超过一万，年订单量超过 50 万。

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

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

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

4. 系统安全性⽬标：系统可拦截 sql 注入、XSS 等攻击，密码数据散列加密，客户端数据

HTTPS 加密，外部系统间通信对称加密；

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

1.3 系统用例图

1.4 性能目标分析

按照三个月后日订单 1.2 万进行估算，每日可以下单时间，也就是同城快递员工作的时间，按 14 小时估算(08:00 - 22:00)，每小时可能的下单量也就是 1200 单。再根据二八法则 (1200 * 0.8) / (60*60*0.2) = 1.3 单/秒，因此根据此推算，依据业务目标分析，下单场景的性能不会是本系统的设计重点，查询场景按照 50 万用户估算。

1.5 系统划分分析

1.5.1 业务模型

1.5.2 问题域

同城快递业务基础流程实现电子化管理

二、系统部署图与整体设计

2.1 系统部署图

直接采用 4 台 8C16G 的 K8S 集群采用容器的形式实现熔断限流负载等策略，持久化方面配合 Redis(2 台 2C8G 落盘)+MySQL 读写实例 RDS(2 台 8C16G)

客户 App 端的职责为有快递需求的客户提供工具，依赖业务后端⼦系统 和 订单交付子系统，实现了登录、注册等普通功能，下单、支付、查看订单轨迹 的功能。

快递员 App 端的功能职责是为快递员的工作提供支持的工具，依赖业务后端和抢单秒杀⼦系统，实现的功能包括快递员的登录，抢单，更新订单状态的功能。

业务后端子系统的功能职责包括客户和快递员登录，接收快递员上报地理位置(每 30 秒一次)请求，快递员的地理位置直接存入 redis 集群。

订单交付子系统的功能职责为订单管理，包括接受用户的订单，RPC 调用交易中心子系统进行支付，发布订单，依赖于 Redis 集群，MySQL RDS 和交易中心⼦系统，实现订单管理的相关功能。

抢单秒杀子系统的功能职责为给快递员抢单，依赖于 Redis 集群，实现抢单的功能。

交易中心系统的功能职责为支付收钱，部署于 1 个 k8s 容器，依赖第三方支付包括微信支付宝银联等第三方服务，实现 了支付功能，它被订单交付子系统回掉，支付完成后同步回复结果更新。

财务结算系统系统的功能职责为算账，直接部署于 k8s 容器中，只依赖于 MySQL 数据库，来计算实际收入所得。

2.2 下单场景业务活动图

2.4 下单抢单场景的服务器时序图

2.5 订单状态图