【.com原稿】如果让你从0开始搭建一个智能派单系统，日单量40W，你敢接单吗？你会怎么办？做过的人会说简单，但没做过，很多人想都不敢想。其实在技术上并没有太大区别，区别只是“做一次”的体验。听别人讲述自己的经历也是积累经验的好方法。我们曾经请来过快狗打车的高级经理胡先波，聊一聊他的职业生涯。他谈到了快狗打车调度系统从零到智能的演进。以下为文字版整理，希望大家看完后能有所启发。石器时代，单一数据库拆分，业务解耦由于快狗打车是当时58同城孵化的N个业务线之一，上线仅三周，初期版本包括用户端App、商家App、管理后台三个模块。上图为业务孵化期的整体系统架构。采用单一数据库模式，与其他业务共享数据库，节省成本。这样做是为了快速验证市场对业务的接受程度。上图是业务孵化期的订单调度系统，可以理解为一个单元操作。系统的核心部分是OrderPushJar，处理订单创建、推送等调度逻辑。这个阶段的订单调度原理很简单，就是推送框架MQTT把订单推送给设定范围内的所有司机，司机根据手速接收订单，每个都有补贴为了快速抢占市场，这对于平台来说是巨大的浪费。快狗打车上线后，市场反响非常好，仅三个月业务量也增加了1万单。但此时数据库已经达到了瓶颈，字段冗余、数据库索引有效性等问题凸显，无法支撑多种业务的发展。当一个子服务上线下线时，“同源”业务也会受到影响。上图是针对数据库瓶颈的解决方案，将快狗打车的数据库从耦合的业务数据库中拆分出来。该方案采用双向同步方式，在业务不中断的情况下进行数据迁移。整体迁移后，快狗打车Taxi整体系统大致分为订单、结算、配置、轨迹等模块。每个模块都有对应的独立数据库，避免了业务之间的耦合。不会影响其他业务流程。铁器时代双推渠道，象限推送2015年，快狗打车进入快速发展阶段，市场上出现了蓝犀牛、一号货、云鸟等众多同类竞品。市场竞争进入白热化阶段。快狗打车利用大量的订单补贴来提高市场份额。也在争分夺秒地迭代产品，抢占市场先机。上图是业务高速发展时期的系统架构。App、PC等第三方渠道进入OrderCenterServer（订单中心），OrderCenterServer会根据具体职责进入业务模块化，分为结算、支付、推送、司机任务等模块。为了保证司机能尽快收到订单，保证消息推送的到达率，快狗采用了自研的TCP通道，并结合个推、米推等三方通道。根据司机手机品牌选择个推或米推通道，加上自研TCP通道，保证消息到达率。这个阶段原本是按不同象限推送订单派送。当订单产生时，它会首先在附近X公里范围内搜索满足需求的司机，并推送该订单。如果无人抢单，则增加部分补贴，以刺激司机的抢单意愿。如上图所示，将采用象限推送方式。如果没人抢单，会增加一些补贴，把推送扩大到象限。如果抢单数量达到一定上限，将减少部分补贴。在分配司机的过程中，根据司机抢单距离、好评率、历史订单完成率等核心评价指标分配优胜者。恶意抢单，从而提高整个平台的订单完成率。智能时代的大数据平台被引入智能时代。2016年，快狗打车成为行业龙头，进入平稳期。这时候，更多的考虑是平台补贴的效率如何，如何发挥真正的补贴作用，如何尽可能满足用户的需求。,如何分配司机的收入。此外，效率提升成为今年的总体目标，主要包括引入大数据平台、智能派单算法、智能配送框架等。Step1：数据采集如上图所示，通过日志中心组采集上报APP用户使用数据、H5端日志操作、服务端用户请求日志等数据，收集到日志中心，以及使用Flume和Kafka同步到大数据平台。DB也通过DTS和Canal引入大数据平台。Step2：智能模型训练如上图所示，是智能模型的训练逻辑。底层是收集信息：订单信息，包括：始发地、目的地、价格。用户信息，包括：用户位置、价格敏感度。司机信息，包括：接单意愿等。客户与司机的关系信息，包括：两者匹配的条件。整体订单的推送、接单场景等信息。依托Normalization&Bucketing、XGBoost、特征组合、编码等大数据方法进行模型训练，目前约有80万个数据模型用于整个业务流程。下面通过具体场景来讲解大数据智能派单系统的应用，涉及定价、推单、中单等主要场景。场景一：定价先分享定价场景，因为打车用户都是司机对价格非常敏感。具体为：用户先上来询价，根据询价信息，给予用户一定的A元优惠，同时对司机进行B元补贴。抽取D元以保证平台的运行。那么如何计算ABCD之间的关系呢？显然，在保证整体抢单率的情况下，A和B应该尽量小。也就是说，在尽可能降低平台补贴的前提下，根据给定补贴的预算，提高抢单率。根据以上两种定价模型不难发现：要保证订单完成率，至少要保证有两个司机抢单：通过对司机和用户的行为分析，需要了解司机对订单的大概接受价格；同时，也会通过接单司机的总体数量依次验证模型的有效性。上述报价模型是一种分析用户流失率的手段。根据用户的日常活跃度、订单价值贡献等可以了解到，由于某些原因可能存在用户流失的风险，应该通过在平台发放优惠券的方式刺激他回流用户。场景二：推送订单上图是接收订单的场景。将订单推送给愿意接单的司机，不仅可以减少用户的等待时间，提高用户的满意度，还可以通过订单完成率增加司机的兴趣。那么司机的接单意愿从何而来呢？包括：订单与司机的距离、订单价格、小费补贴、起点终点。通过大规模逻辑回归，平台可以计算出附近司机的接单意愿，然后推送给相应的司机。场景三：中单场景，如果有50个司机争单，那么谁的好感度、距离、服务态度、免费接送的意愿是最合适的策略，谁就能“中奖””。这里的服务模型比较简单，主要涉及距离、等级、评分、耦合度等指标。为防止部分假司机扰乱平台秩序，快狗打车采用：设备交叉、订单跟踪、客流分配、虚拟识别识别订单作弊概率。如发现作弊订单，平台将对用户和司机进行处罚。场景四：整体运行如上图所示，为整体应用场景。当用户下单时，快狗会根据订单的定价模型来判断用户是否需要调价、折扣或补贴。系统推送时，快狗打车会预测司机的接单意愿和推送顺序。当司机抢单时，快狗打车会预测收到的订单总数。一旦数量达到上限，将通过减少订单补贴等方式进行动态微调。分配订单时，快狗还会预测司机的完成概率，获取司机的素质。订单完成后，快狗打车会预测用户是否会流失，并根据其留存值来决定是否给他更多优惠。上图从一侧展示了整体学校的建筑。核心在于政策应用服务端、通用逻辑服务层、底层数据服务端的划分。上图展示了智能调度的核心流程。左边的核心模块是特征数据，通过数据采集和训练得到对应的特征数据值。通过特征匹配系统，将数据应用于整体业务系统。同时，这里的订单队列引擎和司机队列引擎根据订单状态的实时变化，将订单推送给司机。此外，业务监管平台用于确保新模型或算法在上线时进行分发和监控。具体来说，就是根据用户设备的特点，模拟流量的分布情况，然后实时上报数据。例如：用户是否仅在查询阶段完成后才流失。如果流失率很高，则将通过实时报告关闭新的在线分流设置。接下来分享一下快狗打车的监控平台。具体定义如下：该算法需要一个稳定的系统来支撑业务波动。您必须第一时间了解业务波动。提高故障排除效率就是挽回损失。监控部分截图，涉及关键字监控、接口监控、流量、端口、JVM、CPU、线程、缓存、DB等监控。业务指标的监控包括订单的整体波动和补贴的整体波动。订单波动是监控附近司机的平均数量和订单波动。补贴波动是监测用户和司机实时发放补贴的数据。对这些核心业务指标的监控，需要实时反馈，出现波动时第一时间报警。如果优惠券订单数量突然暴涨？补贴订单数量为何突然下降？这些核心业务指标的监控需要实时反馈。综上所述，2014年至今，快狗打车团队一路走来不断壮大，业务也在不断迭代优化。最后总结出以下几点：架构与团队和业务保持一致，保持服务的持续演进，以应对快速的业务变化。推荐使用Dualpushchannels保证推送的到达率监控很重要。第一时间发现问题，降低影响并持续改进。团队的能力要跟上业务的节奏。【原创稿件、合作站点，请注明原作者和出处为.com】
