通达系统架构设计文档

项目背景

为了抓住快递业务的新风口，通达公司主要开展同城快递业务。现组建 20 人的技术部门进行系统研发工作支持公司战略目标的实现。

需求分析

通达系统用例图如下：

通达系统用例图

通达的核心功能是用户下单后，5 公里范围内的快递员抢单并完成配送服务。基于核心功能，处于接单状态的快递员通过客户端每 30 秒上送自己的实时位置，通达需要保存他们的位置信息，用户下单后系统要根据下单地址快速计算、查找出 5 公里范围内的快递员。随后，系统需要把订单信息及时推送给符合条件的快递员。相关交互模型如下：

活动图

快递员收到推送的订单信息后进行抢单，通达业务持续发展需要长期稳定投入、并且能为客户提供满意服务的快递员。抢单决策子模块需要使用大数据技术和人工智能算法让优质快递员有更高的抢单成功率。同时为了鼓励新成员的加入，抢单子系统需要适当的向新注册快递员倾斜。

长期、稳定的客户能帮助公司业务平稳、快速增长的关键，订单系统进行派单时需要使用适当向优质客户以及营销获得的新客进行适当的倾斜。

负载指标估算

通达的设计目标是日订单 50 万，平均每个用户一天下一单，日活用户占总用户量的 10%，即总的注册用户量是 500 万。快递员平均送 30 单，日活快递员 1.67 万左右。

通达的总存储量、吞吐量、宽带负载估算如下：

l 总存储量

每条订单占用 10KB 的存储空间，每天的存储空间是 50 万 x 10KB = 5G,每年需要占用 5G x 366 天= 1.8TB 的存储。只需保存 1 个月的订单热数据，即 155G 的存储空间，其它归档存储。

快递员的位置信息每条大约 100B，以 2 万日活快递员计算，需要 2MB 的存储空间。

l QPS

系统需要满足的平均 QPS: 50 万/ (24 * 60 * 60)  约等于 6。高峰期 QPS 为平均 QPS 的 2 倍，即 12。

l 宽带负载

6 * 10KB = 60KB/s = 480Kb/s，高峰期宽带负载为 960Kb/s。

非功能需求

1. 数据存储方面：通达系统热数据存储量每天大约需要 5G，每个月 155G 左右，这些数据需要支持快速读写。其它的数据需要归档供大数据处理技术进行分析处理，产出支撑公司决策的信息。

2. 并发方面：系统高峰期的并发 QPS 是 12 请求/秒，并发度不高。但是需要支持横向扩展，以应对公司后期发展的需要。

3. 流量负载：根据公司的战略，如果是全国同时铺开推广业务，则需要在不同的区域部署系统，就近为用户提供服务。

4. 安全性：需要验证接口调用的权限，数据安全方面需要确保用户支付以及快递员佣金技术的准确计算以及安全存储。

5. 性能要求：用户下单后需要在 5 分钟内匹配 5 公里范围内的快递员。Tp80 的匹配时间需要控制在 30S。

6. 高可用：下单以及快递员匹配服务可用性目标是 99.99%。

概要设计

为了实现通达系统的功能性与非功能性需求，通达系统架构采用典型的微服务架构架构设计方案，具体方案如下图：

通达系统部署模型

由上图可知，静态资源文件存储在 CDN 服务器，客户端也会缓存不经常变化的数据。这样可以降低数据中心的网络带宽压力，而且可以大幅降低客户端的白屏时间，提高用户体验。

为了保证整个服务的高可用，通达系统采用多级限流机制，负载均衡服务器集群配置每秒钟接收的请求数量，控制转发到下游服务的总请求数。微服务间调用会进行限流和降级设置。

服务网关主要的职责是根据用户的地理位置、下游服务的健康状况等把请求转发给下游微服务。另外服务网关屏蔽下游服务的具体地址，通过读取注册中心的数据进行请求转发。

安全性方面，用户登录的时候，服务网关把登录请求转发到 OAuth2 集群，获取 JWT 令牌，客户端后续每次请求都会携带 Token，具体的微服务每次处理请求都会校验 Token 的有效性，有效才会处理请求并返回结果。

用户管理服务集群负责用户以及快递员的注册以及信息（姓名等）维护，用户登录的时候 OAuth2 集群需要请求该集群验证用户的用户名和密码。考虑到该集群的负载压力不是太大，该集群也会包括快递员佣金汇总、提现等实时性要求不高的批次任务逻辑处理。

因为需要快速计算 5 公里以内的快递员，避免计算速度慢导致请求积压，位置管理使用单独的集群处理，并且使用 Redis Cluster 保存处于接单状态的快递员的 30 秒内的位置信息。 位置管理服务还需要根据当前订单池，帮助快递员规划配送路线，这样快递员可以沿途在不超时且不超载的情况下同时配送多个订单，实现资源最优配置。

消息发送微服务负责从 Kafka 消息队列拉取需要发送的消息并把消息发送到客户端。不同类型的消息有不同的主题。

抢单微服务接到抢单请求后使用分布式锁保证只有一个符合条件的快递员能抢到单。当同一订单有锁记录时，所有的抢单请求都会快速返回。如果抢到单的快递员取消接单，则释放锁，5 分钟内不重新进行位置计算。抢单信息分批次下发到快递员客户端，以解决快递员接单后取消的场景。

订单微服务负责用户的下单、快递员改变订单状态、订单金额计算等逻辑处理。进行金额计算时，订单微服务需要调用营销微服务的接口获取折扣、优惠信息。另外订单微服务需要对接第三方支付系统完成订单支付。

大数据处理以及预决策系统负责处理系统沉淀的历史数据，根据人工智能算法、模型预测用户的下单情况，提前给潜在符合要求的快递员发送上线接单提醒，加快订单的处理效率。建立快递员的业务熟练程度模型，订单属性模型供抢单微服务进行决策时使用，实现资源配置的最优。

为了提高用户的满意度并且降低运营成本，还需要搭建智能客服系统。另外，为了能及时发现服务可能出现的宕机等问题以及快速排查问题，需要部署日志以及运维监控集群。

详细设计

详细设计关注用户下单时各个微服务的下单时序模型、位置查找算法以及订单的状态模型。

用户下单时序模型如下：

用户下单时序模型

可以使用距离算法、SQL 临近算法、动态网格算法或 GeoHash 算法来实现查找 5 公里内快递员的功能。为了能够从 1 万多个在线快递员中快速查找到符合条件的成员，通达系统最终选择使用 GeoHash 算法。

用户下单后，位置服务需要找出 5 公里内在线的快递员，只需要采用 5 位的 Geohash 就能满足通达系统的查询需求。把在线快递员的经纬度以及 Geohash 保存到 redis cluster 集群，用户下单后，根据发货地址通过 Geohash 范围查询出可能匹配的快递员，再使用经纬度计算位置或根据位置进行排序，分批次把订单信息下发给快递员进行抢单。

从下图的订单状态模型看出，可能会出现长时间没有快递员进行抢单的情况。为了缩短接单时间，位置服务需要有路线规划能力，根据现有快递员的配送中订单以及新订单信息，把订单分配给路线重回度高的快递员。另外，需要分批次下发抢单信息，避免短时间内重新进行位置计算匹配。

订单状态模型