2019年11月29日，在滴滴拼车上线4周年之际，滴滴发布全新的拼车产品，同时宣布2019年12月3日在北京、上海、广州、成都等26个城市推出拼成一折的活动，打造首个“全民拼车日”。面对类似双11的一折促销活动，如何应对瞬间的流量峰值，以及平滑、高效的实现司乘撮合，本文就滴滴的派单引擎来阐述这些问题的解决思路。

　0.

目录

　　1. 背景

　　2. 滴滴分单架构概述

　　   ○ 分单模式

　　   ○ 滴滴分单架构

　　3. 拼车日带来的挑战

　　   ○ 拼车原生属性

　　   ○ 拼成出发预约模式

　　   ○ 服务化架构

　　4. 稳定性保障之路

　　   ○ 架构优化

　　   ○ 拼成出发预约模式 - 临近指派

　　   ○ 过滤逻辑优化 - 架构与性能的折衷

　　   ○ 超时重试配置化

　　   ○ 预案建设

　　   ○ 全链路压测

　　   ○ 监控告警

　　   ○ 告警

　　   ○ 监控

　　   ○ 集中值班

　　   ○ 通报机制

　　   ○ 快速决策方案拟定

　　5. 展望

　　   ① 背景

　　   11月29日，在滴滴拼车上线4周年之际，滴滴发布全新的拼车产品。同时宣布12月3日将在北京、上海、广州、成都等26个城市推出拼成打一折的活动，打造首个“全民拼车日”。

　　   拼车推出新模式“拼成出发”和拼成打一折的活动给分单引擎带来成倍的压力增长，本文介绍其中的挑战。

　　   ②滴滴分单架构概述

　　   滴滴分单引擎主要做的是司机和订单的匹配，也就是来决策如何更好的将用户的订单分配给司机。

　　   ▍分单模式

　　   从分单模式上，主要抽象为独乘分单和合乘分单(拼车分单):

　　   独乘分单解决的是单个订单和司机的最优决策分单，分为多种场景模式，目前承载了滴滴快车、专车、出租车、豪华车的独乘分单业务。

　　   对于拼车单，会将顺路的订单进行打成一个“包”，在独乘分单的基础上，拼车分单还要解决“包”和司机的最优决策分单，承载了目前快车拼车、出租车拼车、跨城拼车的合乘分单业务。

　　   ▍滴滴分单架构

　　   分单整体流程如漏斗，订单司机对会从顶层，层层向下筛选，最终形成一个个可匹配的订单司机对。

　　  假设参与计算的订单有1000，司机有4000，那么进入第一层的订单司机对数是400万，计算压力与订单数和司机数的乘积成正比。

　　  ③拼车日带来的挑战

　　  滴滴分单引擎主要做的就是司机和订单的匹配，所以司机订单匹配计算量基本上表征了整个系统的压力。

　　  活动当天：司机订单匹配计算量峰值相比日常峰值增长2.24倍，其中拼车计算量相比日常峰值增长6.6倍。

　　  总结下来主要是以下几方面的原因:

　　  ▍拼车原生属性

　　  对于一个普通的快车单来说，分给一个司机之后，在这个司机快到达目的地之前，这个司机可以认为不参与分单了，对于系统压力变小。

　　  但是对于一个拼车单来说，分给一个司机之后，这个司机会继续进到分单系统里面来，和别的拼车单执行“拼”的逻辑，所以相比于快车单，司机的匹配周期更长，计算也更复杂，除了考虑司机和乘客的匹配外、还需要考虑乘客和乘客的顺路度。

　　  ▍拼成出发预约模式

　　  在正常情况下，一个快车单的生命周期只有有限几分钟，生命周期内没应答，就会自动取消，那么系统就没有压力了。

　　  拼成出发，分为随时可走和预约模式，预约模式最长生命周期1天，虽然初期预约单占比不高，但随着时间推移，预约单越堆积越多，系统压力越来越大。

　　  拼成出发只能分配载人车，或者作为一个包分给司机，本身条件就更苛刻，在订单池里面的存活时间也更长一些。

　　  总结来说，拼成出发模式使得订单的生命周期更长。

　　  ▍服务化架构

　　  目前的司机订单过滤架构简化图如下:

　　  整体分单流程是一种漏斗形式，输入是需要匹配的司机和订单，输出是匹配成功的匹配对。

　　  第一层漏斗是通用过滤层，对于通过了通用过滤模块的司机订单组合，才会漏到拼成过滤层进行过滤。

　　  无论是通用过滤模层还是拼车过滤层，都是先进行过滤，对于没有被过滤的司机订单组合，再进行访问下游的工作。

　　  对于在2.1部分过滤的司机订单组合来说，在1.2部分访问的下游数据很多是无用的，也就是说给下游带来的压力是浪费的，这也是服务化架构引入的代价。

　　  拼成出发模式因为拼成了才能派车，而是否可以拼成的逻辑都在拼车过滤模块中，随着时间的积累，能通过1.1但是无法通过2.1的司机订单组合越来越多，这也是下游压力增长过大的一个原因。

　　  ④稳定性保障之路

　　  我们的稳定性保障工作主要分为架构优化、容量评估、预案建设、监控告警、全链路压测几个部分:

　　  ▍架构优化

　　  我们对现有架构进行了审视：

　　  其中拼成出发预约模式和服务化架构引入的代价部分，给下游带来的压力过大，不能完全按照现有模式进行扩容，我们需要对现有架构进行优化。

　　  拼成出发预约模式 - 临近指派

　　  针对拼成出发预约模式，用户发单之后，订单会同时进入分单的订单池和拼车的拼友池。拼友池：进入拼友池的订单，拼车打包模块会给当前用户寻找拼友，也就是进行打包操作。

　　  订单池：进入订单池的订单，就会进入分单引擎进行分单。但拼成出发预约模式，会在订单出发时间的前k分钟，才真正开始给用户找车，在找车之前的计算都是无效的。

　　  针对这种情况，对拼成出发预约模式进行了优化，将发单进入订单池的操作改为临近进入订单池，有效降低订单池规模。

　　  过滤逻辑优化 - 架构与性能的折衷

　　  针对服务化架构引入的代价，拼车分单的同学将拼车过滤中过滤比例较高的策略，迁移到了通用过滤模块中。这算是在现有架构下，为了性能的一种妥协。

　　  后续应该会探讨出一种更合理的架构来解决这种问题。

　　  经过评估，上面2部分的业务架构优化，在同样用户呼叫单量的前提下，对下游的访问压力可以下降50%以上。

　　  超时重试配置化

　　  为了更加灵活的控制下游的超时重试，整个分单主流程的调度周期，下游的超时时间，重试次数，都实现了配置化，修改秒级生效。

　　  为了防止流量突增时引发下游雪崩，在拼车日之前，我们将整个分单主流程的下游重试都调成了1，也就是不再重试。

　　  ▍预案建设

　　  因为活动中可能会有很多不可预知的事情发生，针对可能发生的异常，我们做了一系列的预案。

　　  预案的底线目标是：保障评估容量内无异常，超出评估容量不被打挂;包括五部分：

　　  提前降级功能：活动前操作，主要提前降级的功能

　　  入口预案：活动中操作，出现重大风险和异常时执行

　　  最小核心链路预案：活动中操作，核心节点出现风险和异常时执行

　　  业务指标异常预案：活动中，系统无异常，但是业务指标出现异常

　　  崩溃恢复预案：核心服务出现雪崩，如何快速恢复

　　  每项预案都需要提前演练，保证预案有效、且符合预期。

　　  ▍全链路压测

　　  全链路压测是评估系统容量最有效的手段，拼车日一共进行了8次演练，9次正式压测，发现了45个有效问题。

　　  经过一轮又一轮的压测，大家对自己的服务容量都有了更清晰的认识。

　　  在压测过程中，到达系统容量之后，我们还会继续加压，观察多个系统在系统超限情况下，是否会被打挂。

　　  在压测过程中，我们也会演练提前制定好的预案，把压测场景当成活动日看待。

　　  ▍监控告警

　　  告警

　　  拼成日之前，我们重新梳理了各模块告警。分以下几大类：

　　  机器信息类：包括cpu、磁盘、句柄数、网卡错误、协议栈错误

　　  自身服务：包括存活性、服务容量水位线、服务总耗时最大值、服务各阶段耗时最大值

　　  依赖服务：包括请求耗时、超时或者错误率、是否限流

　　  client端：请求耗时99分位、成功率

　　  同时对于各个告警都进行了报警升级，拼车日当天宁可误报，不可错过任何一个错误信息。

　　  针对每个告警，都有至少一个预案阈值对应，保证系统稳定性。

　　  监控

　　  除了完善系统各项指标监控，我们还建立了多个监控大盘。

　　  拼车业务指标大盘：各个指挥者需要实时关注该大盘。

　　  系统机器性能大盘：运维人员需要实时关注该大盘。

　　  各个服务监控：为每个服务指定负责人，实时关注。

　　  ▍集中值班

　　  通报机制

　　  各个方向值班长需要在值班群里实时通报异常情况。

　　  每隔10分钟，各个方向值班长需在值班群里通报系统是否正常。

　　  快速决策方案拟定

　　  拼车日之前，已经确定好。遇到何种问题需上报，何种问题需立即快速解决，何种问题需上下游配合解决。解决方案要尽可能得覆盖异常情况。

　　  我们采用了扁平化的人员组织方式，以达到更高效率的问题处理。

　　  拼车相对于快车对系统在匹配复杂度、路径规划等方面的挑战更大，难度更大，基于这次拼车日保障的积累，我们将不断提升能力，提供稳定可靠的技术保障。

　　  文章来源：滴滴技术