外卖平台案例

这是一个给海外用户做的外卖平台。

值得一提的是，我们在参与这个项目的时间是2020年之前，因此一些在当下看起来很平常的功能和架构设计，在当时看来，是非常先进甚至是超前的。

项目的开始只在微信中做H5页面实现点餐的功能，直到形成一个成熟的外卖平台系统，Android、iOS、小程序，全部原生开发。

这个项目，是一个能让我把自己所掌握的一切（知识、经验、技能、思维），充分发挥出来的项目，所以直到现在，也是很让我印象深刻且十分满意的项目。

众所周知，一个外卖平台，应该包括客户端（消费者使用），商家端，骑手端。某些大型平台还会存在一个供应链端。

先从平台上的各种角色说起：

后台，有运营、客服、骑手、派单员、商家五个角色。

后台运营人员：需要查看到每天、每个地区的订单量。骑手接单、派单的情况。商家上新、优惠的数据等等的内容，并对其进行管理操作。

客服，需要看到所有的订单内容，便于处理客诉，还要监管评论区，决定是否要回复、删评、或者是联系客户。

骑手和派单员是一个协同工作的关系，派单员需要把已经付款的订单，指派给附近的骑手。骑手在规定时间内完成接单、送达、结单等动作。

商家归为后台的角色，是因为有他的被动操作，创建账户、与平台协调费率等等的事项，无直接操作。直接操作在后期开发的商家专属应用中。

前台，有商家、用户、骑手三个角色。

说到这里大家可能会有疑问了，前台和后台是如何区分的。

后台主要是从平台视角，对平台上的业务进行监控和管理，是管理的角色。

前台，是给用户角色使用，让用户使用设计好的业务流程。在这里简单概括为：引导消费者下单、商家接单、骑手送单这个流程。

再来讲一下技术层面的内容。

平台最核心的流程，就是外卖从点餐到送达的流程，其他业务流程，都是围绕着这个流程进行设计。看似简单，但其实这个业务流程图比淘宝上最长的商品详情页还要长的多。

我们要支持每天5-10万的下单量，后端采用的ROR（Ruby on Rails）+MySql单实例，项目从开始设计的时候，就采取了前后端分离的模式，真正需要服务器计算的数据，就是提交订单、支付、商家出餐、骑手送餐和送达几个节点；大部分的压力，是交给前端去承载的。

初期：ROR提供全部Api，React做的H5页面，当时只用到了一点Redis，支付功能，地图只用到了定位功能，平台后台用的Angular.js。后面陆续做出了商家端、骑手端，也是用React实现的。

中期：最大的需求变更是要做移动端的App了，做需求分析的时候，其中有一个重点，就是ROI，最小的成本，让App上线。这样选择先用混合开发，因为之前有React的底子，用React Native也很好上手，学习成本，相对低一些。

移动App涉及到的端，忽然一下就增加了，商家端的Android和iOS、骑手端的Android和iOS，用户端的Android、iOS和微信小程序，这需要很大的工作量才能完成。

这次大型迭代，还有一个用户、商家、骑手等前端用户都看不到的功能，派单平台，比较完整的使用了Google Map，用React实现。当时没有使用系统自动派单，是出于两个方面的考虑，一是平台没有那么大的用户量，相应也就没有那么大的订单量，另外，做算法，是一个很烧钱的事情；在当时那种情况，使用人工而非算法完成派单动作，无疑是更具性价比的。

后期：主要的工作，一是把用户端的Android和iOS改为原生开发，二是不断的代码优化、功能迭代。

优化分为前端和后端，前端的优化，是以用户体验为主导，后端是以性能为主导，还要考虑一些接口、子系统、子服务的拆分，这也是一项非常庞杂的工作，篇幅所限这里不加赘述。

其中还包括页面纯静态处理、在原生系统中嵌入H5的活动页、移动端App使用Sqlite做本地存储、缓存，等等。

一些小的、新的技术的实际应用，在这个项目上，还是比较多的，这也是我喜欢这个项目的原因之一，它让我的创造性和知识储备得到了充分发挥。

后台做的最多的优化，就是派单平台，为了用最短的时间把餐品送到消费者手上，我们做了算法的优化和派单平台前端页面的优化。最后形成了一个”半自动“的派单平台，大幅提升了使用效率，将平均每单的派送时间缩短了15.2%。

在这种大型系统中，队列是一个非常重要的工具。它可以用于短信通知、登录过期处理、各种定时任务以及临时统计数据等。以及搜索、推荐、埋点和数据采集等工作。随着功能的不断增加，应用程序从最初的十几兆逐渐增长到超过一百兆。

在项目的后期阶段，我们仅使用了8台服务器，加上第三方接口的服务费，一年的成本控制在了8万美元左右。考虑到平台的用户量级，这样的运维成本是非常节制的；同时，研发团队人数也控制在了60人左右，也体现了我们是一个高效的团队。