架构师 01 期，大作业一

背景：

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

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

产品需求：

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

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

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

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

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

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

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

技术方案建议：

用户下单请求通过负载均衡服务器分发给下单网关集群

使用消息队列向 5km 内的快递员发送通知（消费者服务器获取的消息内容包括：用户地址，快递员列表）

快递员实时位置缓存在分布式缓存 Redis 中

数据存储使用 MySQL，第一个上线版本不要求做数据分片，但要做主从复制

说明：以上技术方案建议是公司请的外部技术顾问（该顾问是产品负责人的朋友）给出的，具体是否合适请

架构师自己定夺

设计目标：

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

2.从节约成本的角度，早期方案采用精简服务部署，在满足业务前提下尽量少部署服务器

3.未来可能会迁移到云计算服务上，技术选型尽量选择主流的云计算厂商开源的技术方案

用例模型

用例说明

1. 核心的业务都需要订单来管理，因此抽象了一个“订单管理”用例，给其他用例使用

2.为了加快核心用例“订单配备快递员”的操作，该用例不和订单管理用例进行交互

部署模型

部署说明

1.CDN 用来加速用户图片的访问速度

2.负载均衡服务器用 nginx，将来并发量大的时候可用用 LVS 部署

3.网管服务器早期用双机部署，将来根据业务量扩容

4.微服务框架用 dubbo

5.消息队列采用 RabbitMQ

6.早期不准备部署 redis ，快递员位置直接记录配单微服务

7.数据库采用 mysql，并配置主从复制

下单抢单活动模型

订单状态模型

关键算法方案

订单位置匹配

1.早期，快递员数量少，订单位置匹配采用遍历全部快递员的方案，用取件的经纬度和快递员最新的经纬度进行判断

2.中期，用区域的方式合并快递员，然后在此基础上订单位置匹配该区域的所有快递员，然后根据经纬度进行判断

3.后期，在中期的基础上根据导航的路线和预估的上面时间进行综合判断

抢单加锁算法

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

2.未来计划用 zookeeper 来实现分布式锁