快狗打车智能化演进之路

若是让你从 0 组建一个智能化派单系统，日订单量为 40W，你敢接单吗？你会怎么作？作过的人都会说简单，没有作过的人却连想都不敢想，其实技术上并无太大的差距，差就差在“作过一次”的经验。听别人讲述本身的经历，也是积攒经验的一种好方法。咱们曾邀请快狗打车高级经理胡显波讲述他的职业生涯，他讲述了快狗打车的派单系统从 0 到智能化的演进。

石器时代

单一拆分数据库、业务解耦

因为快狗打车是 58 同城当时孵化的 N 个业务线之一，而且短短三周就已上线，最初的版本包含了用户侧 App、商家 App、管理后台三个模块。

上图所示的是业务孵化期总体系统架构，采用的是的单一数据库模式，与其余业务公用数据库，节省成本，这样作是为了快速验证市场对业务接受度。

上图所示是业务孵化期的派单系统，能够理解为一个单元运做。系统核心部分是 OrderPushJar，订单建立、推送等派单逻辑都在这里进行处理。

这个阶段订单调度原理很简单，就是由推送框架 MQTT，把订单推送给设定范围内全部司机，司机凭手速接单，单单都有补贴旨在快速抢占市场，这对平台而言是庞大的浪费。

快狗打车上线以后，市场反响很是好，业务也在短短三个月增加了一万单。但此时数据库达到瓶颈，字段冗余、数据库索引有效性等问题凸显，没办法支持多业务的发展，某个子业务作上线下线等操做时，“同源”业务也会受到影响。

上图是针对数据库瓶颈的解决方案，把快狗打车的数据库，从耦合的业务数据库中拆分出来。方案中采用双向同步模式来业务不停服的状况下进行数据迁移。

总体迁移后，快狗打车总体系统大体分红订单、结算、配置、轨迹等模块，每个模块都有对应单独数据库，这样就很好的避免了业务之间的耦合，轨迹服务数据库出现异常，并不会影响其余业务流程。

铁器时代

双推送通道、象限推送

2015 年，快狗打车进入高速发展阶段，市面上也出现了不少同类竞品，如蓝犀牛、1 号货的及云鸟等。市场争夺战进入白热化阶段，快狗打车采用大量订单补贴的方式来提高市场占有率，产品方面也是争分夺秒的进行迭代，抢占市场先机。

上图是业务高速发展时期的系统架构。App、PC 及其余第三方渠道进入到 OrderCenterServer（订单中心），OrderCenterServer 会根据具体职责进入业务的模块化，分红了像结算、支付、推送、司机任务等模块。

为保证订单可以尽快被司机接收到以及保证消息推送到达率，快狗打车采用自研 TCP 通道与 GeTui 和 MiPush 等三方通道相结合。根据司机的手机品牌择优选择 GeTui 或 MiPush 通道，加上自研的 TCP 通道，保证消息的到达率。

这个阶段订单调度原是按照不一样的象限方式进行予以推送，订单产生时会先在附近 X 千米范围以内，寻找知足该需求的司机，进行推单。若是无人抢单便加部分补贴，激发司机的抢单意愿。

如上图所示，会采用象限推送的模式，若是没人抢单，就增长部分补贴，延象限进行推送，若是抢单人数达到必定上限，就回下降部分补贴。

在指派司机的环节，根据抢单司机的距离、好评率、历史订单完成率等核心评估指标进行择优指派，这种简单的方法既减小了平台派发无效补贴的浪费，又有效避免了凭速度抢单的恶意竞争，进而提高了整个平台的订单完成率。

智能时代

大数据平台引入到智能化

2016 年，快狗打车成为行业佼佼者，进入了平稳期，这时更多考虑的是平台补贴如何高效，起到真正补贴的做用、如何尽可能知足用户的需求、如何分配司机的收益。

进而效率提高成为这一年的总体目标，主要作了引入大数据平台、智能派单算法和智能分流框架等内容。

Ste.1数据收集

如上图，App 用户使用数据、H5 端日志操做，Server 端用户请求日志等数据进行收集并经过日志中心组进行上报，聚集到日志中心，利用 Flume 和 Kafka 同步到大数据平台。DB 则是经过 DTS 和 Canal 形式，也引入到大数据平台。

Ste.2智能模型训练

如上图，是智能模型的训练逻辑。底层是收集信息：

l 订单的信息，包括：始发地、目的地、以及价格。

l 用户的信息，包括：用户位置、以及对于价格的敏感度。

l 司机的信息，包括：接单的意愿等。

l 客户和司机的关系信息，包括：二者可以相匹配的标准。

l 总体订单的推送和接单场景等信息。

凭借着归一化&分桶、XGBoost、特征组合、编码等大数据手段，进行模型训练，目前拥有约 80 万的数据模型用于总体的业务流程。

接下来，经过具体场景来诠释大数据的智能化派单系统的应用，涉及主要场景有计价、推单、中单等。

场景一：计价

先分享计价场景，是由于不管是打车用户仍是司机，对于价格都是很敏感的。

具体说来：用户先上来询价，根据询价信息给予用户必定的优惠 A 元，同时也要据此来补贴司机 B 元，另外，在订价 C 元的基础上，快狗打车还要经过必定的抽佣 D 元，来保证平台的运营。

那么该如何计算 ABCD 之间的关系呢？显然，在保证总体抢单率的状况下，应使得 A 和 B 尽量的小。

也就是说，在尽可能下降平台补贴的前提下，根据给定补贴的预算状况，来提升抢单率。

根据上述两个计价模型，不难发现：为了保证订单的完成率，至少要保证两个司机的抢单：经过对司机和用户的行为分析，要掌握司机对于订单大体的接受价位；同时，也会经过总体的接单司机数量，来反过来验证该模型的有效性。

上述优惠模型是分析用户流失率的手段。根据用户天天的活跃度，订单价值贡献等，可以获悉：可能因为某些缘由，用户存在流失的风险，就应该经过平台发券的方式将他刺激用户的回流。

场景二：推单

上图是一个接单的场景。把订单推送给愿意接单的司机，既能下降用户的等待时间、提高用户的满意度，又能经过订单的成单率，来提高司机的兴趣度。

那么司机的接单意愿又是从何而来呢？其中包括：订单与司机之间的距离、订单的价格、小费&补贴、以及起点&终点等方面。

平台经过大规模的逻辑回归，能够计算出附近司机的接单意愿，进而推送给相应的司机。

场景三:中单

在中单场景中，若是有 50 位司机抢单，那么哪位司机的好评率、距离、服务态度、以及是否愿意免费搬运等策略最为切合，谁就可以“中签”。

此处的服务模型相对较为简单，主要涉及到距离、等级、评分、耦合度等指标。

为了防止一些假司机来扰乱平台秩序，快狗打车经过：设备交叉、订单轨迹、客司金额分配、以及虚拟识别等手段，来识别订单中的做弊几率。若是发现有做弊的订单，平台会对用户和司机予以惩罚。

场景四：总体运营

如上图，是总体运用场景。

l 在用户下单时，快狗打车运用订单的订价模型，来肯定用户是否须要调价、优惠、或是补贴。

l 在系统推送时，快狗打车预测司机的接单意愿，以及推送的顺序。

l 在司机抢单时，快狗打车预测总体的接单人数，一旦人数到达上限，就会经过下降订单补贴等方式进行动态微调。

l 在订单指派时，快狗打车也会预测司机的完成几率，并获取司机的质量度。

l 在订单完成后，快狗打车会预测用户是否流失，并根据其留存价值，来肯定是否给他更多的优惠。

上图展现的是总体派单侧的架构。核心在于策略应用服务侧、通用逻辑服务层，以及底层数据服务侧的划分。

上图展现的是智能派单的核心流程。左侧的核心模块是特征数据，它经由数据的收集与训练，获得相应的特征数据值。经过特征匹配系统，将数据应用到总体的业务系统中。同时这里的订单队列引擎和司机队列引擎，根据订单状态的实时变化，将订单推送给司机。

另外，经过业务监督平台，来保证新的模型、或算法在上线时获得相应的分流与监测。具体而言，根据用户的设备特色，来模拟流量的分配，进而实时地获得数据上报。

例如：用户是否仅在询价阶段完成后就流失了。假若流失率较高的话，就会经过实时报告将线上新的分流设置关闭掉。

接下来分享快狗打车的的监控平台，具体的定义以下三点：

l 算法须要稳定的系统支撑

l 业务的波动要快速知悉

l 提升问题排查效率就是在挽回损失

如上图，是快狗打车侧立体化监控部分截屏，涉及关键字监控、接口监控、流量，端口、JVM、CPU，线程、缓存、DB 等监控。

业务指标监控包含订单总体波动以及补贴总体波动等。订单波动就是对附近平均司机数量，推单波动进行监控。补贴波动就是对用户和司机的补贴实时投放的数据进行监控。这些核心业务指标监控须要作到实时反馈，有波动快速告警。

若是优惠券订单数为何忽然间在暴涨？补贴订单数为何忽然之间降低？等等这些核心业务指标监控须要作到实时反馈。

总结

2014 年至今，一路走来快狗打车团队不断壮大，业务也是不断地迭代和优化，总结以下几点：

l 架构与团队、业务对齐，保持服务的持续演进，以响应业务的快速变化

l 建议使用双推送通道，保证推送的到达率

l 监控很重要，快速发现问题，减小影响l 持续提高，团队的能力，要跟得上业务的节奏

以上文字版根据《大咖·来了》第2期整理，但愿您看了能有所启发。
原视频连接：http://aix.51cto.com/activity/10010.html?dk=wz