滴滴2500万日订单背后的系统架构

滴滴在2017年即达到了2500万日订单，仅次于淘宝的日订单量，2500万日订单的系统背后是怎么样的系统架构，滴滴出行的系统架构重点要解决哪些问题，经过了哪些发展阶段？怎么样的系统架构能够支撑起每日千万的订单量呢？

滴滴出行产品的三个阶段与架构的三个阶段

CSDN：如果从产品角度来看，滴滴打车发展有几个阶段？作为CTO，你的工作重点有哪些？
张博：滴滴打车成立初衷就是为了解决司机与乘客之间的信息不对称的问题。乘客和司机通过传统手段往往无法实现信息对接，一方是打不到车或被拒载；另一方是空车行驶耗时耗力耗费资源。这是信息的壁垒，完全可以通过移动互联网和智能手机来打破。而在后续运营中，我们发现即使出租车空驶降低到O，也无法满足早晚高峰乘客出行需求。以北京为例，出租车10.6万辆，但人口却有2000万常住人口，1000万流动人口。要匹配这样的需求需要集中社会用力，调度社会资源，这就是滴滴打车的第二款产品——滴滴专车。目前专车订单量已经逼近出租车订单量，而车租车订单量没有下降，显然撬动的是新增量市场。第三款产品是顺风车，满足的场景很有代表性。通过滴滴大数据分析系统，发现很多人居住地和工作地都比较接近，收入水平相当，行业属性相近，这些人往往都会使用出租车或专车，如果能够将需求合并，显然无论是帮助乘客提供低成本出行，还是节省社会资源，都很有价值。更有趣的是，其上增加了社交属性，人们可以结交新的朋友，出行变得更有意思。作为CTO，我的工作主要有三部分：第一是产品，第二是工程技术，第三是大数据。

产品的三个阶段：滴滴出租车（解决信息不对称）=》 滴滴专车（调度社会资源，满足增量市场） =》 顺风车（资源共享，社交）
架构的三个阶段：搬腾讯云（CDN，安全，基础平台） =》 通用服务下沉架构部 （支付/账号/计算/存储）  => 大数据智能调度

滴滴的数据智能

CSDN：2015年在滴米系统、用户画像系统、精准营销、智能匹配、需求预测系统和运能预测系统等方面，滴滴大数据技术逐步深入。那么研发的整体思路是怎么样的？
张博：是的。大数据是滴滴打车的心脏。不只是滴滴打车产品的心脏，还是滴滴打车商业的心脏。我们的研发的基本原则是想办法撮合乘客和司机，满足他们的需求，保证他们的体验。举个例子，某一个时刻在中关村，同时出现很多订单，周围有很多司机。我们要做的决策是：将订单发送给合适的司机。因为司机在任何时刻都只能听到同时爆发订单中的一个。所以匹配要准确，那么背后就是推荐算法要准确，匹配效率要高，计算要快，推送要及时。这还不够。我们在推送订单到这位司机之前，应该先预测他对订单感兴趣的程度，广告领域称为CTR，我们称为STR。在后验过程中，滴滴可以做到80%的准确度。其中，不仅要计算司机的个人特征，还要结合其决策体系，如喜好，是对小费敏感，长短途敏感，时间敏感，还是对方向敏感等静态特征和司机和订单之间的位置关系、时间关系等动态特征进行综合分析。除此以外，还有补贴，给乘客什么样的补贴，给司机什么样的补贴，谁更敏感，多少金额影响更积极，这些策略的背后都是大数据在起作用。我们希望用有限的资源最大化提升用户的质量和活跃度，这不可能通过人肉实现，只有技术才能实现这些。而实现的过程中，对架构、运营、产品等挑战都很大。

人工智能在滴滴的应用场景：从目的地预测、智能派单、路径规划，到供需预测、拼车、服务评价等等。

滴滴的大数据

基础层面是数据平台，主要是大数据计算和存储，用的是业内比较成熟的开源系统，Hadoop。
基础层上是自建的数据仓库，然后是策略架构，通过实验平台让策略迭代更加敏捷，如快速提取特征完成模型训练，并通过小流量测试验证模型，通过后迅速上线。这些都是工程方面的研发。再上面是机器学习，滴滴打车现在每天涌入的数据接近10TB，通过不断搜集用户标准数据特征，优化机器学习模型。比如推送给司机订单，司机是否抢单，这就是一个天然的标注。而通过这些标注，就可以优化学习体系。最上面就是整个大数据体系，支持新产品开发和策略决策。在我看来，目前很多开源项目演化的比较稳定，性能表现也不错，没有必要从头开始搭积木了，尽快将技术服务于应用最重要。而在不断实践中，通过对开源技术的改进和优化，在反馈给社区，我们是愿意这样做的。

滴滴的架构经验

第一是如何应对大流量、高并发的挑战。比如每一个接口可能被访问频次如何设计，背后访问多少次缓存，数据库会读写多少次，后端每一个服务，瞬间并发量能到什么级别，每一层压力测试要扛住多大读写并发，10台机器能扛住多大读写并发等，都要做到心中有数。再比如每一次营销活动前，要对系统做一次体检，评估到底可以承接多大的量。
第二是要有非常好的运维工具，要能实时监测线上每一个后端服务模块的负载，能够及时发现问题并报警。
第三是设定多套应急预案，当问题发生时，团队可以尽快反应，做准备好的动作。
第四是要有降级策略，在大流量冲击下，要优先保证主流层。对滴滴而言就是发单，用户发单、司机抢单是主流程，在这样的特殊情况中，积分商城等都是非主流层，可以被舍弃。

滴滴七天七夜重写服务端架构

七天七夜，是滴滴CTO张博最难忘也流传很广的“励志故事”。2014年1月，滴滴发起补贴大战，背后是微信和支付宝的“支付决战”。两周时间里，订单量上涨50倍，眼看40台服务器撑不住了。张博向程维求助，程维连夜电话马化腾，马在腾讯调集一支精锐技术部队，一夜间准备了1000台服务器。在苏州街的银科大厦，张博和技术团队、腾讯部队奋战七天七夜，重写服务端架构。

滴滴订单分配的挑战

滴滴一个架构重点/核心是订单分配，全国每天有几百万的乘客通过滴滴叫车出行，有近百万司机接滴滴的订单，如何将订单分配给司机使得更多的人更快地打到车？至少有如下问题需要考虑：

• 从大的层面，如何设计一套分配策略，能够保证目标最大？
• 从小的层面，分配订单时应该考虑到哪些因素？（距离？是否顺路？司机习惯偏好？天气？供求关系) 这些因素如何组合？
• 如何在更长的时间维度上做更优的分配？（比如，当前时刻将乘客A分给司机B是最优的，但几秒之后司机C出现了，司机C离乘客A要近得多）
• 拼车更环保也能帮乘客省钱，如何在订单分配中让尽可能多的人在保证体验的同时拼上车？
• 乘客加价如何影响订单分配？

架构发展的五个阶段

滴滴整体架构演进

1.远古时代

滴滴打车最早的架构简单而粗暴，为单体架构。 此时的滴滴打车流量<100万、团队成员：3研发、0运维。

架构遇到的问题:

2.石器时代

此时期的滴滴打车已初具规模，架构压力越来越大，此时的滴滴打车流量<3000万、团队成员：5研发、1运维。

架构遇到的问题

3.滴滴打车架构：“青铜时代”

此时期的滴滴打车流量已到达单机瓶颈，此时的滴滴打车流量>=3000万、团队成员：12研发、2运维。集群架构是必然选择：

架构遇到的问题

4.铁器时代： 

此时期的滴滴打车看似架构已渐入佳境， 3000万~2亿、团队成员：>12研发、>2运维。

架构遇到的问题

5.滴滴打车架构：终极时代之“工业时代”

滴滴打车本次经历巨大的突破，架构上变化很大，足以应对接下来很长一段时间内的整个业务的增长。

终极时代之“工业时代”: 流量5亿、团队成员：50+研发、7运维。