给奔跑中的火车换轮子，58速运订单调度系统架构大解密[转]

2017-12-15

给奔跑中的火车换轮子，58速运订单调度系统架构大解密[转]

今天很荣幸给大家介绍 58 速运从艰苦创业到成为同城货运行业领头人的整个系统演进过程。

简单来说我们的业务是做同城货运，比如您去买一个大型家具，自己的家用车肯定是装不下的，这时你可能需要找路边的小型面包车或者金杯车来帮你搬运。

一般来讲，很容易遇到黑车，而且价格不标准，我们做的这个行业就是将这种传统的黑车行业进行线上化，在产品形态上可理解为滴滴打车的出租车版。

本次分享内容主要分为4个部分：

创业之初：快速迭代试错
高速发展：稳定、高效
智能时代：效率、精准
总结

创业之初：快速迭代试错

58 速运在 2014 年是作为 58 集团下 20 多个孵化业务中的其中一个，那个时期基本上是平均三个星期一个业务孵化上线，当时有 20 多个业务孵化同时进行。这个时间我们不断的试错，不断去寻找 58 同城新的增长点。

从上图中，大家可以看到，我们所有的服务都是基于一个数据库来运行的，这个系统之间只需要通过一些简单的 tag 标记就可以区分开业务，系统迭代非常快。

对于新孵化的业务，我们增加了一些简单的业务逻辑就能实现这个产品的快速上线，我们在两周内实现了速运用户、商家的 APP 以及后端的产品上线。

派单-石器时代

这时的系统架构是非常简单的，我们称之为“石器时代”，当时所有的订单调度的逻辑放在一个 Jar 包，然后通过 MQTT 服务将订单推送到司机的 APP 上。

当时的订单调度（也是我们最初级的订单调度方案）是一个订单搜索附近的司机，然后由近到远的距离将订单推送出去，司机抢单后即中单。因为在创业阶段，我们需要吸引客户、司机，对于每单都会有补贴。

这个阶段面临的痛点如下：

系统不稳定，一个慢 SQL，全业务受影响，这里举个非常普遍的例子，其他业务线小伙伴在上线时，不小心写了一个慢 SQL，一个慢 SQL 就会把数据库的所有连接占满，导致所有的业务全部挂掉了，当时听到的最多的反馈是：什么情况，怎么你们又挂了。
多业务并存，订单表索引多，性能下降，当时有很多个业务在同时孵化，多业务并存，每一个业务都会根据它自己的业务需求在订单表中建立索引，结果索引越来越多，整体的性能也越来越差。
订单字段冗余，新增和修改字段非常痛苦。每个业务都有特殊的业务字段，单标数据量已经到达了千万级，每增加一个字段和修改一个字段，都需要耗费很长的时间，而且会造成锁库导致系统异常。
业务增长迅猛，数据库已成瓶颈，58 速运整体的订单增长非常迅速，在成立三个月以后，每天的单已达到了1 万+，系统性能已成为瓶颈。

针对以上痛点，我们做了第一次的技术引进——迁库、集群拆分。

第一次技术演进：迁库、集群解耦

为什么要迁库？谁痛谁知道！不想受到其他业务小伙伴的影响，就要做到解耦。

一个最简单的方案就是停服，把所有的服务停掉，然后把数据库抽离出来，相对来讲这是成本最简单的。

但是停服会产生的影响：

凌晨时间业务仍然有订单，会影响到用户访问。
需要给用户发公告。
停服迁移如果失败，无法向业务方解释，会丧失信任。

我们采用的方案：将订单表单独地拆离出来，放在单独的数据库里，两个数据库之间使用双向同步。

双向同步需要解决的问题：

主键冲突：速运的订单会标记一个比较特殊的标记 ID（如 80 开头标记为速运，其他业务都是 10 开头的），与其他的业务线区分开发，这样就可以保证它在双向同步时不会出现主键冲突的问题。
更新覆盖：update 的操作在同步的过程中因为时间差的问题可能存在写覆盖的情况，我们采用订单日志的记录，迁库完成后做数据的校验。

经过多次的迁移，将原有的数据库按照业务划分成了订单库、结算库、配置库和轨迹库等，每个数据库会根据业务量容量的大小来配置数据库物理机的内核、内存，减少成本。

高速发展：稳定、高效

2015 年我们进入了高速发展的阶段，市场上出现了蓝犀牛、1 号货的、云鸟的等多个强劲的竞争对手。各方都是争分夺秒，一个系统、功能，我需要抓紧把它给迭代上来，谁也不能比谁落后。

这个阶段我们存在的问题：

补贴大战，大量无效补贴，运营成本高，各大竞争对手投放大量的订单补贴（高达 30 元+），使得整体运营成本呈现水涨高船的趋势。
快速迭代多人维护一套工程，效率差，Bug 频发，最开始创业时团队只有几个人，工程都集中在几个集群中，后面扩大到 30 多个人时，大家都集中在这些集群上去开发，平均每天都要进行多次上线，遇到了个最核心、最痛点的问题，代码合并，合并代码就意味着出错的几率大大提升，当时 Bug 率很高。
业务高速发展，数据量急速增长，我们在 2015 年时，订单增长了好几倍，同时每个订单大概会推送给 50 多个司机，这个数据量级，数据量高速的增长。
运营分析需求越来越复杂，另外运营需要对现在的市场和用户进行分析，整体的运营需求分析逐渐复杂。

这时我们进行了第二次技术演进，我们称之为“进行了奔跑中的火车换轮子”，我们进行了服务化解耦；缓存、分库分表，提升系统性能；接入大数据平台，进行复杂需求的分析。

第二次技术演进：奔跑中的火车换轮子

派单-铁器时代

我们将所有的系统都按服务模块进行了拆分，比如说结算、充值、推送、司机任务等，现在大概已有 20+ 个服务，每个服务都有独立的数据库，有独立的负责人。

这样就可以做到我自己的代码我自己来写，别人都不允许去插手。

此外我们进行了推送的多通道化，从上图可以看到，我们针对每个司机选取了两种推送通道，同时我们也建议大家在做推送消息时采取这种方案。

拿小米的手机来说，“小米”推送通道的到达率是最高的，但小米的通道在华为的手机上，到达率不如“个推”的推送到达率高。

我们就会根据司机的机型来选取一个到达率最高的三方通道。同时在设计上不能有单点，假如说小米的通道出现了问题，那我们的服务就不可用了，司机接收不到订单，用户的需求就没法得到满足。

所以我们还有一个自研渠道 TCP 通道，这个 TCP 通道除了和我们三方通道做一个双通道保活外，它还可以做一些数据的上传。

这时的订单调度，被称为探索阶段，初期的距离推送效果有限，谁抢到谁就中单，司机的服务质量我们没有办法去评判，补贴也是大众化的。

所以我们自己研究了一个按象限推送的方法：

首先我先推送一个很短的距离，比如说我先把一公里以内的所有司机都推送一遍，这时我是不给补贴的，当推完一公里以后没有人抢，或者是抢的人非常的少，我会按象限去推。
在第一个象限，我给一块钱补贴，如果没人抢，第二个象限给两块钱补贴，第三个象限给三块钱，这样逐步地去增加。
最后当司机抢了单，我们会根据司机的好评、完成率这些方面选择一个最优质的司机。

分库分表

前面提到数据库性能已经成为瓶颈了，所以这里以一个用户服务给大家讲一下我们的分库分表是怎么做的：

业务初期，我们一个库可以完成支撑所有的访问。
随着数据量的增长，我们做了一些读写的分离，把一些读取 SQL 放在从库上，但这里给大家一个建议——订单状态的读取尽量不要在从库上读，网络一抖动，你的订单状态就很可能会出现不一致情况。
加上从库，当表的数据量达到千万级，查询的性能依然会下降，这样我们就需要去做水平拆分和垂直拆分。

水平拆分比较简单，大家也容易理解，而垂直拆分就是比如说我把一个用户 10 个最常用的属性放到一个组表里，把不常用的属性放到另外一张表里面去，这样可以减少 I/O 的操作，也可以提高整体的产品性能。

数据库水平拆分以后，再给拆分后的库增加从库。

在这里水平拆分要重点提一下，就是如果资源允许，水平拆分还是建议分库。

数据库的性能瓶颈也是会受到硬件设备和网络 IO 的影响，如果访问量持续增加，数据库还是会成为瓶颈。

我们的水平拆分有两种方法：

范围法：用户 ID 在 1K 万以下的放到一个库，1K 万~2KW 以上的放到另外一个库，这样切分简单，扩容也方便，但是会存在数据库之间的负载不均匀。

哈希法：根据用户 ID 进行哈希运算，切分简单，整体负载比较均衡，平滑迁移可能是需要我们去解决的难点。

拆分后的问题：

部分查询变慢了：非 patition key 查询，需要遍历全部库，做完水平拆分以后，我们遇到了一个新的问题，实用 Patition key 水平拆分，非 patition key 查询需要扫库，性能反而变慢了。
运营需求无法实现：各种维度统计，没办法联表查询，运营小伙伴原来在单库的时候，因为复杂 SQL 跑的特别慢，导致无法统计特别情况，分完库以后，他连 Join 都用不了，更无法查询统计了。

问题分析，“任何脱离业务架构的设计都在耍流氓”：

我们拿数据库的 Binlog 日志看了一下，根据用户 ID 的访问大概是占 99%，根据用户姓名、手机号、Email 的这些属性的查询大概只有在 1% 的量。
运营会根据年龄、性别、头像、登录时间、注册时间这些复杂的数据去做统计和分析。

前端解决方案：

索引表法：非 Patition key 与 uid 建立索引表，拿非 Patition key 和 uid 做一个索引表。

这样我直接通过这个表和 Patition key 进来后先去找一下 uid，这样就可以找到这个 uid 在哪个库，但是增加了一次数据库的查询。

缓存映射法：非 Patition key 与 uid 映射关系放入缓存，缓存命中率高，我们把 Patition key 与 uid 的映射关系放在缓存里面去，只会第一次比较慢，后面都会从缓存中取，而且这个缓存基本上不用淘汰。
非 Patition key 生成 uid，根据 Patition key 生成一个 uid，这个需要一定的生成技巧，同时这个可能有主键冲突的风险。
基因法，根据非 Patition key 的其中部分基因生成一个字段，如下图：

运营侧需求解决方案：

冗余后台库：通过 MQ/Canal 实时同步到后台库，通过 MQ 或者是 Canal 读取 MySQL 的 binlog，将几个前台的数据库实时地同步到后台库里去，后台库不对前台业务提供服务，仅供运营侧查询。

注意这个后台库是千万不能用于现场生产的，因为运营会在上面做一些复杂的慢查询，数据库的响应会非常慢。

外置搜索引擎：ES/Solr/XXXX，接入外键索引，如 ES/Solr 提供搜索服务。
大数据平台，使用大数据平台，通过 MySQL 的 binlog 和日志上报，将数据读取到大数据平台进行实时地分析，供运营查询。

到了 2016 年，竞争对手基本上已经被消灭了，58 速运已经成为行业的领头者了，如何使用更少的补贴获取最大化的收益？

我们有如下几点反思：

平台补贴是不是真的起到了作用，然后我们到底需要补多少钱才能帮助用户完成订单？

如何去尽量满足用户的需求？每个新用户进入平台是有成本的，一个用户的成本在几十甚至到一百块左右，如何满足用户的需求，让用户持续的留在平台中。

平台的司机良莠不齐，司机的收益应如何分配？

第三次技术演进：战斧项目

我们进行了第三次的技术引进，我们称之为战斧项目，项目的定义：精准、高效。

我们做了以下优化：

策略服务的细化
智能模型的接入
智能的分流框架

智能时代：效率、精准

智能模型训练

上图为智能模型训练图，首先我们会将订单信息、用户信息、司机信息、客司关系信息、订单总体推送、司机接单等场景信息统一上传到大数据平台。

通过这种归一化&分桶、XGBoost、特征组合、独热编码等将这些数据分析为特征数据。

针对分析出来的特征数据，我们需要对它进行训练，如：订单价格、订单距离等特征在整个订单派单中起到的权重。

因为特征很多，计算出来的权重可能并不是一个完美的解，只能说是近优、最优的一个解法，通过不断地迭代优化，最终训练出来最终的模型。

订单-模型运用

订单模型的运用：

下单阶段：在用户下单时，我们会采用这种用户订单定价的模型，观察这个订单所在的商圈的运力饱和度，如果司机少，而订单需求多，我们会进行一个订单的调价。
推送阶段：系统推送的过程中，会根据司机的接单意愿来捞取。有的司机喜欢高价格订单，有的司机喜欢短程订单，有的司机喜欢去中关村等。我们会根据订单与司机意愿的匹配程度进行优先推送的排序。
抢单阶段：先预估这个订单的接单人数，计算出来订单的价值，如果订单的价值高（价格高、地点好）、那么这个订单不会发放补贴了，同时会扣取司机的一些积分或优先抢单次数等。
如果订单价值比较低（价格低、偏远地区），会给这个订单适当地增加补贴，来确保订单的完成。
指派阶段：当司机抢完单以后，我们会根据所有司机历史完成订单的数据，取司机的质量，来决定哪个司机中单，保证订单尽可能完成。
订单完成阶段：订单完成了以后预测这个用户的流失概率，如果可能流失，会送一些券或者其他权益吸引用户留在平台。

派单-智能时代