注：Doordash 明天要上市，市值估计能冲到 400 亿。程序君想起了之前写过的一篇旧文，于是将其翻出来，供大家回顾。想起 17 年还是 18 年有个读者问我 doordash 和 facebook 的 offer 如何选，我推荐 doordash，但他最终去了 facebook。。。人生的选择啊。不过这种「擦肩而过」也许才是人生最大的乐趣。
---
（题图：doordash创始人，年轻得让程序君想哭）
受朋友之托，研究米国估值破亿的top 10餐饮O2O公司。这10家是：
1) Eatclub：为公司人士提供午餐配送服务。
2) Munchery：提供私人定制晚餐服务。
3) sprig：3种套餐，12美元统一价，15分钟送达。
4) Caviar：提供餐馆在线订餐，面向高档餐馆，且主要提供团餐服务，如团队，公司或家庭订餐。
5) spoonrocket：8美元15分钟内准时上门。
6) fluc：在线订餐，45分钟送达。
7) doordash：外卖界的uber，YC的孵化项目，商业模式学习打车软件uber，提供餐馆的在线订餐，不限总价，每单6美元送餐费。
8) blue apron：提供食材预定。每人每顿9.99美元，自己做，免配送费，随时取消。目前月营收60M USD（尼玛这是奔上市的节奏啊）。
9) plated：食材预定，有大厨开发各种菜谱。
10) Good eggs：有机食品运送服务。
民以食为天。程序可以不写，饭不能不吃。如果吃顿饭还能get新技能，那再好不过。平时时间比较紧张，上周日中午，趁着加班的机会，程序君花了点时间，体验了一下米国的送餐服务。虽然sunnyvale属于湾区上风上水的核心地带，公司云集，但毕竟整个湾区除了旧金山圣何塞外就都是大农村，除非你身处downtown，否则随便去个地方都要开车10km（6mi）以上，所以榜单里那些15分钟送达的不用说，一定是只针对大城市服务的了。
我把整个列表过了一下，只有6和7能在sunnyvale用。朋友让我研究下7，正中下怀，那就恭敬不如从命了。
送餐服务有两道坎：a) 距离 b) 人工费。
所以国内的方式美国的方式拿到国内来行不通。我们来看看doordash整个产品和服务是怎么做的。
产品/服务流程
doordash提供网站和app来方便用户订餐。根据你输入的地址，它会告诉你你所在的城市（地区）时候是否在送餐范围内，如果不是，你可以提交邮件，然后等待通知；如果是，它会显示附近可送餐的餐厅列表，供你选择。每个餐厅都有预估的送达时间，一般在35-60分钟。餐厅可以通过一些简单的搜索来过滤，比如：chinese，则显示所有类别是中餐的餐厅。
选定了餐厅后，可以从菜单上选择想吃的菜，每道菜有菜名，大致介绍和价格，却没有图片。这对我来说是个大问题，本来就看不懂大部分菜是什么玩意，更别说它们之间的微妙差别，你跟我说说Koobideh Kabob和Top Sirloin Kabob有什么区别！所以无图无真相还是很有道理的。但不知为何，fluc也不提供图片，我就闹不明白这是商家不愿意呢还是什么别的原因，不过本着「不要在意这些细节」的精神，我随便选了加中餐馆，随便点了个宫爆三丁，然后就下单了。现在是推广期，6美元送餐费直接减免（好烧钱的赶脚）。
填信用卡，联系电话等略去不表，一提交，钱就被扣了。我是11:47下的单，11:51餐厅就confirm了，然后系统显示大概会在12:42送到。我一看这时间，乐了，一般都是给个大概，比如说12:30-13:00送到，哪有这么精确的？不过，这也让我对送餐服务有了一点期待。
12:23我收到短信，菜品已经被送货人员取走；12:41又收到短信，说送货人员快到你的地址了；然后12:43我就收到了电话，让我下去取餐。拿到菜品，签收完毕，体验堪称完美。
doordash手机上的体验和网站上几乎一致，但有一点："become a driver"，网站上没有这个功能。原来doordash并不雇佣自己的配送团队，而是采用一种类似于众包的方式，只有你有车，有智能手机，就能申请并赚取$20/hour的收入（还可能有不菲的小费）。doordash通过强大的技术能力让这种松散的众包配送服务能够玩得起来。
怎么实现？且听程序君不靠谱拍脑门的狂想。。。
技术手段
先说点靠谱的。
doordash的网站是典型的bootstrap UI风格，选餐厅和选菜都用了Single Page Application技术，减少页面刷新，提高体验。整个后端服务应该是构建在AWS上的，至少用了S3存放静态文件。tracking的服务用了ga和mixpanel，几乎是现在创业公司的标配。提高转化率方面它使用adroll，现在也是很多创业网站的标配，这货可以追踪访问过你网站的的用户，在他们访问其它网站的时候展示你的广告，唤醒他们对你产品的回忆（还记得那条泡妞秘籍么：在女神面前出现的频率越高，女神对你的印象会越深）。在性能监控和分析管理（Application Performance Engineer）方面使用了newrelic - 这货我是有次在highscalability上一篇文章上看到的。
接下来就是假想了。第一个问题是：如何将送达时间预估得如此精准？
订餐后到餐品送达的时间分成两部分。烹饪时间 送餐时间。我猜想doordash和餐厅间就烹饪时间有个SLA，超过这个时间就要受罚。当然，如果餐厅无法提供餐品（比如原料用光，忙不过来等），可以拒绝这单生意，但一旦接受，那么就要满足SLA，美国商业的契约精神比较浓厚，会按SLA来执行的。
送餐时间分为司机取餐和送餐两部分。一旦餐厅接受订餐，那么系统就根据所有送餐车辆的实时位置和空闲状态，选择较优的车主进行推送，告知取餐的餐厅和预计取餐时间。车主可以选择接受或者拒绝，第一个接受的车主将会拿到这单生意（这点和滴滴打车类似）。这里有个问题，如果当前可用的送餐车辆资源不足怎么办（没人接受这单生意）？
两种情况：
1) 送餐人员都在送餐的路上。那么，在第一步选择餐厅的时候就需要把送餐时间拉长 —— 比如说，位置最好的几个送餐人员中最晚何时取餐何时能送到，然后把这个作为预计的等待时间。当然，用户点餐和餐馆确认都有时间上的延迟，当这两步完成后，情况已经发生变化，可以给用户一个比较准确的ETA。
2) 给定地址附近没有送餐人员。直接告诉用户无法服务。
3) 给定地址附近送餐人员还很少，可能在推送时直接拒绝，导致做出来的餐品没法配送。这是体验最差的情况了，需要给用户退款，并赔偿餐厅的损失（可能是SLA的一部分）。
感觉 2)和3) 都属于可控的管理问题 —— 对那些还没有准备好服务的区域先不提供服务（比如还没招募到足够多的送餐员）
第二个问题是：如何做到配送的体验如此良好（和预估时间差一两分钟）？
斗胆猜一下，doordash的后台系统运行着mesos或者yarn这样的分布式任务集群，每个司机都是在集群里运行的一个driver task。空闲情况下，只要司机连线，就会有GPS信息传回，当有订单被确认，根据集群里各个driver task的状态（idle且距离近）有选择地推送。一旦司机接下订单，司机的状态就会变为working。task会计算到达餐馆的时间，以便在合适的时候（比如快到了）通知餐厅，餐厅的人就可以将打包好的食物直接交给司机，装入保温包后就可以继续上路 —— 这样能最大程度减少交接耽搁的时间。
交接完毕，task根据司机手机传回的GPS发现其已经离开餐厅，就会触发「成功取餐」的事件，对于用户而言，就是一条通知的短信和网页/app上订单状态的更新；而用户收到的司机即将到达的信息，也通过task计算得出并出「即将到达」的事件。
最后，当司机离开目的地，task会触发「成功配送」的事件，将订单状态更新，然后将司机状态置为idle。
当然，以上两个问题的回答还离不开机器学习。系统需要不断地学习以便获得这些知识：
1) 哪些是靠谱的餐馆，哪些不靠谱
2) 哪些是靠谱的司机，哪些不靠谱
3) 哪些是靠谱的用户，哪些不靠谱
4) 对于1,2,3的各种组合，如何能为用户提供最靠谱的预估时间，而且这时间和实际配送的时间相差无几？
以上都没有考虑各种异常情况，比如车坏了（如果你有上万个甚至更多的配送司机，跟MTBF一乘，就会成为一个不小的数字），餐厅接受了订单却没做，司机手机没电了/没网了，司机送到了但联系不上客人等等）。
下次呆得时间上我会申请"become a driver"，从司机的角度彻底体验其流程。
不要小看一件简单的送餐服务。
