如果让你从 0 组建一个智能化派单系统，日订单量为 40W，你敢接单吗?你会怎么做?
做过的人都会说简单，没有做过的人却连想都不敢想，其实技术上并没有太大的差距，差就差在“做过一次”的经验。
听别人讲述自己的经历，也是积攒经验的一种好方法。我们曾邀请快狗打车高级经理胡显波讲述他的职业生涯，他讲述了快狗打车的派单系统从 0 到智能化的演进。
下面是整理的文字版，希望您看了能有所启发。
石器时代
单一拆分数据库、业务解耦
由于快狗打车是 58 同城当时孵化的 N 个业务线之一，并且短短三周就已上线，最初的版本包含了用户侧 App、商家 App、管理后台三个模块。

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

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

这个阶段订单调度原理很简单，就是由推送框架 MQTT，把订单推送给设定范围内所有司机，司机凭手速接单，单单都有补贴旨在快速抢占市场，这对平台而言是庞大的浪费。
快狗打车上线之后，市场反响非常好，业务也在短短三个月增长了一万单。但此时数据库达到瓶颈，字段冗余、数据库索引有效性等问题凸显，没办法支持多业务的发展，某个子业务做上线下线等操作时，“同源”业务也会受到影响。

上图是针对数据库瓶颈的解决方案，把快狗打车的数据库，从耦合的业务数据库中拆分出来。方案中采用双向同步模式来业务不停服的情况下进行数据迁移。
整体迁移后，快狗打车整体系统大致分成订单、结算、配置、轨迹等模块，每一个模块都有对应单独数据库，这样就很好的避免了业务之间的耦合，轨迹服务数据库出现异常，并不会影响其他业务流程。
铁器时代
双推送通道、象限推送
2015 年，快狗打车进入高速发展阶段，市面上也出现了很多同类竞品，如蓝犀牛、1 号货的及云鸟等。市场争夺战进入白热化阶段，快狗打车采用大量订单补贴的方式来提升市场占有率，产品方面也是争分夺秒的进行迭代，抢占市场先机。

上图是业务高速发展时期的系统架构。App、PC 及其他第三方渠道进入到 OrderCenterServer(订单中心)，OrderCenterServer 会根据具体职责进入业务的模块化，分成了像结算、支付、推送、司机任务等模块。
为保证订单能够尽快被司机接收到以及保证消息推送到达率，快狗打车采用自研 TCP 通道与 GeTui 和 MiPush 等三方通道相结合。根据司机的手机品牌择优选择 GeTui 或 MiPush 通道，加上自研的 TCP 通道，保证消息的到达率。

这个阶段订单调度原是按照不同的象限方式进行予以推送，订单产生时会先在附近 X 公里范围之内，寻找满足该需求的司机，进行推单。如果无人抢单便加部分补贴，激发司机的抢单意愿。
如上图所示，会采用象限推送的模式，如果没人抢单，就增加部分补贴，延象限进行推送，如果抢单人数达到一定上限，就回降低部分补贴。
在指派司机的环节，根据抢单司机的距离、好评率、历史订单完成率等核心评估指标进行择优指派，这种简单的方法既减少了平台派发无效补贴的浪费，又有效避免了凭速度抢单的恶意竞争，进而提升了整个平台的订单完成率。
智能时代
大数据平台引入到智能化
2016 年，快狗打车成为行业佼佼者，进入了平稳期，这时更多考虑的是平台补贴如何高效，起到真正补贴的作用、如何尽量满足用户的需求、如何分配司机的收益。
进而效率提升成为这一年的整体目标，主要做了引入大数据平台、智能派单算法和智能分流框架等内容。
第一步：数据收集

如上图，App 用户使用数据、H5 端日志操作，Server 端用