---

受朋友之托，研究米国估值破亿的 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"，从司机的角度彻底体验其流程。

不要小看一件简单的送餐服务。