在架构师眼里，一份美团外卖是如何做出来的？

作为日千万订单级别的业务，美团外卖的后端服务是怎么支撑的？ 文章转载自infoQ（ 微信号： infoqchina）

写在前面

2018年4月，中国外卖市场迎来巨变，外卖从无人问津开始，到现在已经培育成互联网巨头必争之地。作为为数不多能够达到日千万订单级别的业务，其后端服务是怎么支撑的？InfoQ采访了ArchSummit出品人、美团点评技术总监方建平，请他回顾及展望美团外卖的后端架构史，本文根据采访整理而成。

美团外卖后端架构迭代各阶段

美团外卖发展到今天差不多有 4 年多的时间，按照外卖业务发展的几个特征，可以相应地把外卖技术分成三个主要阶段：

第一阶段：业务初探期

大约截止到 2015 年初，持续差不多一年左右的时间。这个阶段的主要特征就是美团对于外卖的业务还处于市场摸索期，研发人员相对也比较少，差不多 10 来个同学，产品上需要快速迭代、试错。

所以这个阶段的系统架构比较简单，就是典型的单系统 Web 应用服务，主要是需要满足产品需求上的快速上线，验证业务模型的市场可行性。

第二阶段：业务爆发期

外卖业务在 2015 年初开始了爆发式增长。基于当前外卖的业务特性，90% 以上的交易都是在午高峰和晚高峰这个期间完成的，对业务系统来说高峰期负载重，压力大。这个阶段，我们主要是从最早期的基于单系统的 Web 应用架构，向分布式服务架构的迁移改造。期间主要优化工作如下：

一、做架构的拆分，应对高并发、保证高性能

对系统的拆分，主要体现在系统服务层、以及数据存储层上。

通过对线上业务流程的分解，将外卖系统分成数据浏览体系、用户订单交易体系、商户接单配送体系、用户信息 UGC 服务等，同时也针对大的业务服务体系内的流量分布、以及功能差异性，再做进一步的拆解。比如浏览体系中会有门店服务、商品服务、搜索推荐服务等等。

针对并发的读写数据压力，我们也针对性地搭建了相应的分布式缓存服务、针对特定数据库表，例如订单表，也进行了基于订单 ID、门店 ID、用户 ID 等多个维度的拆库、拆表操作。

二、构建系统化运维体系，保障服务高可用

分布式系统拆分，提升了外卖服务的并发处理能力，同时也给线上运维带来了负担。需要对线上近百个服务应用、几千台机器资源进行运维管理，才能保证整个业务链路服务的稳定体验。这个期间，我们在业务系统的可运维方面，做了大量的工作。例如：

1. 通过完整业务链路的梳理，形成关联各服务接口的 SLA，保障核心链路的稳定 ;

2. 通过定期的全链路压测，验证各子系统的处理极限，合理规划系统容量；

3. 通过链路故障模拟演练，验证各服务系统在功能层面、系统层面的故障降级处理能力

第三阶段：业务扩展期

这个期间是伴随着业务爆发期逐步开始的。外卖的业务中，除了传统的餐饮品类外，还逐步提供了鲜花、生鲜、果蔬、商超、以及跑腿服务等业务的扩展。7 月 6-9 日，我除了在 ArchSummit 深圳站 上担任《大型分布式系统架构》出品人，也会现场分享美团外卖这个阶段在服务端的架构迭代，包括数据处理上的技巧经验，这里简单总结下：

业务扩展期阶段外卖业务和产品，我们期望以最小的代价，支持不同品类的差异性服务，能够在当前的系统中快速上线。对技术来说，就需要将系统由业务的功能化向业务的平台化方向发展。

我们通过对通用电商逻辑的抽取，形成公共服务平台，将差异性的品类业务特性，通过系统插件或者流程配置的方式，集成到公共服务平台上，以达到整个链路的整合复用。例如：

1. 将订单交易流程通过类似工作流引擎的方式，针对不同的品类，配置不同的流程模板，使其能够灵活的运行在整个外卖的核心交易体系之中；

2. 商家促销活动平台，支持从门店、商品、区域等等不同品类进行各种活动配置，满足不同品类的营销需求。

美团外卖后端新项目

当前美团外卖业务依然处于持续增长期，年前我们的日订单刚突破了 1800 多万。伴随着业务的发展，基于业务背后的技术系统也日趋复杂。无论是对于机器资源规模，还是系统服务之间的调度关联，都对线上服务的运维带来很大的挑战。

为保证外卖线上服务规模的可扩展和可运维，近期我们正在开展两大项目：一个是外卖的 Set 化部署项目、另一个是智能化业务运维系统建设。

外卖 Set 化部署项目

这个项目的目标是为了解决外卖当前大数据、高并发场景下的机房集群资源规模限制问题。我们希望将用户与商家的大规模请求流量，按照特定的规则，拆分到不同 Set 内，同时在 Set 内做到整个用户交易流程的闭环。这样我们并可以通过可控容量大小的 Set 划分，达到分散系统压力，快速支持扩容的能力。

Set 化不是一项新技术，当前业界也有部分公司已经在线上实施了，我们计划 2018 年下半年进入部署状态。这块涉及到的基础服务改造，应用服务改造非常多，我想等我们上线后，可以总结下经验，再来给大家详细分享下。

外卖智能化业务运维建设项目

在美团外卖的稳定性建设过程中，我们希望通过一套智能化运维系统，帮助快速、准确地识别各链路子系统服务异常，发现问题根因，并自动执行对应的异常解决预案，从而避免或减少线上事故影响。

当前业界关于 AIOps 这块的探索也有很多，我们也在同步的跟进摸索中，目前主要还处于基础性建设期间，包括核心链路的故障演练系统、全链路压测系统、告警分析诊断系统，服务自保护系统等等。

高并发应对策略

这里简单介绍下我们的高峰低谷策略、动态调度设计、目前的瓶颈，以及我们的优先级策略。

高峰低谷策略

针对当前外卖的周期性峰值波动特性，我们的主要采取如下几个策略：

系统基础运行能力的适度冗余

外卖系统在系统架构的设计上，无论是在服务层面系统部署，还是数据层面的存储资源都会做适当的冗余。比如我们大部分的核心系统服务，会保持线上高峰时 1.5 倍左右的冗余，以保证高峰期间的业务异常流量情况下的系统可用。

系统资源的动态调配

美团外卖的服务系统都是部署在美团私有云上的，最近一年来，我们也在很多的服务上使用了美团内部的弹性计算容器，以应对外卖系统的突增压力时，可以做到近实时的系统快速扩容。同时在低峰期也可以释放资源，提升机器资源利用率。

系统在极限压力下的自我保护

除了从基本的资源部署上来保证以外，在外卖的系统设计中，也会采取大量的自保护策略，其中包括各系统服务的限流、降级、熔断等自我保护策略，以保证系统在异常流量压力下核心链路的可用性。

动态调度设计

外卖业务链路较长，其中关联角色有三方：用户、商家、骑手，简单的业务流程是：用户下单 ->商家接单 / 发配送 ->骑手接单配送。

外卖服务是一个强履约服务，需要尽最大可能，保障用户下单之后，以最快的时间内送达商品，保障用户的体验。外卖当前主要基于餐饮的商品，属于非标品服务，同时也是基于人员配送的即时物流服务，所以一定时间内的服务规模是有限的。一旦商家商品供给能力不足、或者配送资源不足的时候，都需要通过系统来调节。

例如，当运力充足但商家订单过多，出餐瓶颈出现的时候，为保证用户的体验，我们会从产品上提示用户商家忙，继续下单需要能够让用户有延迟送达的预期；同时针对订单较多，出餐较慢的商家，也会在门店列表排序上给予一定的关联因子降级。

对于运力不足的情况下，也会通过适当的实时策略调整，来保证现有运力的供给平衡，比如在高峰期之外降低配送费，高峰期间提升配送费来调节需求的平衡分布。在极端天气，爆单的情况下，可以通过动态调整特定区域商家的配送范围，来保证用户体验。

总之在外卖的整个交易链路中，用户、商家、配送等系统之间的实时数据是互通的，各业务系统通过关注不同的实时数据变化，采用不同的策略应对，从而调节整个业务的运作模式，保证外卖链路三方的平衡。

当前瓶颈

随着业务规模的进一步扩展，当前外卖分布式架构体系中，系统各层的水平扩展性是我们可能会面临的瓶颈。 具体来说，我们面临的问题包括如下两点：

服务层单个集群大小受限

服务层虽然是无状态服务，理论上可以无限增加，但是单个集群规模越大，运维成本就会越高，比如基础服务治理对于服务状态的维护、更新、同步等。

数据存储单个集群大小受限

单个集群的从库个数是受限的，从库越多，主库消耗越大，导致从库个数是受限的。

所以总的来说，系统集群规模是存在上限的，导致实时线上服务的系统处理能力受限。近期我们启动了外卖服务 Set 化升级，结合外卖的强地域特征，将流量按照地域拆分开，每部分流量由单独集群提供服务，从将整个大的分布式集群拆分为多个小集群，从而可以通过从业务逻辑层的设置，来达到控制集群规模大小的目的。

在当前我们的非 Set 化架构体系中，受限于上面提到的两点，大约可以满足两倍于当前业务的数据量，可以支撑近一年左右的业务增长。随着我们的 Set 化项目 2018 年完成部署，理论上通过增加新的 Set 集群，进一步扩展系统能力，可很好地支持未来 3~5 年的业务增长。

优先级策略

作为一个线上即时交易服务系统，在线上资源不足，或者故障发生时，我们首先会优先保护和订单交易相关的核心业务链路。这条链路从用户能感知到的服务就是：商家列表的浏览、商家内的商品展示、用户提单支付、商品骑手配送。

这就需要我们梳理最小化的核心服务链路，除此之外的其他链路分支所关联的所有服务，都可以在故障时刻被降级。比如针对商家列表的排序、推荐、广告服务、评论服务、搜索服务等等。

而实现最小化交易链路保证的前提是：各系统具备能够降级非核心服务接口依赖的能力。外卖服务经过这几年的不断业务梳理与积累，逐步开发实现了各业务链路的限流开关、功能服务开关、依赖服务降级开关百余个。这些开关通过我们的事故紧急预案，被分类组织到我们的业务运维系统中，一旦对应的事故发生，我们可以快速的通过系统，来完成批量的服务降级处理，从而避免事故的发生、或减少事故造成的损失。

外卖高峰期的入口请求 QPS 达到 20W 左右，这其中包含了部分恶意攻击或抓取流量。针对恶意爬虫抓取这块，我们会与公司内部的反爬团队一起做这块的防范工作。而针对突发的攻击性流量，除了公司上层流量入口层的控制以外，外卖自身的服务也会根据用户或地域维度做一定的限流策略，避免恶意攻击造成对正常流量的影响。

架构优化
扩容还是性能优化

为达到目标系统的容量，一般有扩容和性能优化两种手段，这两种手段会根据服务当前的具体情况配合使用。大的原则是：长期保持系统的优化、紧急状况扩容或按照长期业务趋势规划扩容。具体我们在扩容和性能优化上做的事情如下：

关于扩容能力

外卖的业务技术系统，构建在美团内部分布式基础中间件之上（例如分布式缓存、消息队列、服务治理中间件等），这些通用的分布式组件，为上层应用的水平扩容，提供了基础能力保证。

对外卖业务系统，我们也进行了对应的系统拆分 (例如交易服务、营销服务、评论服务、商品门店服务等)，拆分中保证各服务均采用无状态设计，可以快速支持水平扩容。另外类似营销这样存在突发流量的服务，也接入到美团弹性计算容器中，可以支持根据流量变化，来进行自动化的扩缩容。

关于性能优化

针对外卖高并发场景，合并分散的调用接口，降低各服务系统间访问频次，防止一次调用链中对依赖服务的请求次数放大；提升数据获取性能，优化存储结构设计（分库、分表、建索引），采用适当的存储方式（DB、分布式缓存、文件索引、本地内存等）；将部分请求处理异步化，非实时处理离线化等。

对于如何避免过度依赖扩容，大的方面还是从系统的性能优化入手，当机器资源达到服务瓶颈的时候，需要深入分析具体瓶颈点在哪里，是存储、CPU、带宽还是其他的原因。然后针对具体的点，再考虑是否必须扩容。在外卖定期进行的全链路压测场景中，我们会根据压测的数据，结合各服务的 SLA 要求，来评估各服务的处理能力，再结合未来业务的增长趋势，做较长期的容量扩容规划。

系统架构拆分原则

架构的拆分需要匹配业务规模的发展程度，并具备一定的超前性。过早的拆分会造成不必要的资源浪费，而过晚的拆分，则又会累积现有系统的风险，增加拆分业务的梳理难度。

在外卖的技术发展过程中，由于外卖早期的业务爆发太快，相对技术资源储备不足，拆分的时机是落后于业务发展的，所以早期也出现过很多的线上事故。后来我们通过快速的系统架构拆分与调整，逐步完善起外卖的后端体系架构，减少了线上事故的发生。总结起来，我们针对系统架构的拆分遵循以下三个原则：

流量拆分原则

外卖服务流量按类型，我们可以简单的分为 To C 流量和 To B 流量，也就是面向外卖用户和面向商家、运营的流量。针对不同流量的服务系统会拆分，典型的比如：针对商家或 BD 运营的门店管理、商品管理、营销活动配置管理等，就会和线上的门店、商品、营销等服务分开。除了服务系统上，存储 DB 上也会拆分，中间我们会采用一些实时的数据同步机制，保证数据的一致性。

另外一个维度的流量拆分是按照同步与异步的请求分类。 就是从用户流量的发起方来看，在请求的处理链条中，那些可以异步处理的逻辑服务，会从实时链路处理系统中分拆。比如我们的用户提单系统、与商家接单处理系统、发配送系统等之间都是异步拆分的。

功能闭合原则

在软件设计领域有一个著名的康威（Conway）定律，其中提到组织架构与软件架构相互影响的辩证关系。我们在按照业务功能垂直拆分的过程中，也会有同样的考虑，尽量在一个组织架构中，将功能性业务系统闭合，减少跨团队之间的沟通成本，提升产品开发迭代效率。比如我们的的搜索服务、推荐服务、订单交易服务、UGC 服务、营销服务、门店商品服务等等。

平台服务原则

对不同业务系统公用逻辑或服务的抽取，形成基础性中间件平台，服务于多个业务系统，从而降低维护与开发的成本。

比如我们的数据算法工程平台，我们发现在很多的业务系统中，都会有些算法策略迭代，它们都需要线上特征数据、策略 A/B 实验、效果分析、工程系统支撑等。所以我们将此抽取成一个公共的工程平台，算法只需要提供策略逻辑代码，上传到平台上，平台提供针对业务系统对接的标准化服务接口、特征的统一管理服务、算法的版本管理、A/B 实验、以及效果分析等等。这样的业务中间平台，可以很好的提升了各业务系统的开发效率。

如何梳理核心链路思路

作为线上即时 O2O 电商业务，外卖业务核心是为用户提供订单交易履约，因此我们的核心链路是根据订单交易的业务场景来梳理的。主要包括门店浏览、商品选购、交易支付、订单配送环节，这四大业务环节强依赖的服务接口组合起来的链路，就是核心链路。而不在此关键链路中的服务或非强依赖服务链路，我们将此归集为非核心链路。

对于如何合理地对业务链路进行分级，需要看业务规模的发展阶段，早期可以只划分核心链路和非核心链路两级即可，后期可以再针对非核心链路，进一步向下划分，用以确定更细粒度的降级容错控制。

比如我们在外卖入口 API 层，调度外卖红包服务的链路中，会按照红包的使用、红包的浏览、红包的获取等进行进一步的分级，当红包的系统压力过大时，按照核心与非核心链路的分级方式，我们就只能直接降级红包系统服务了，这样对整个下单交易不会有太大问题，但不能使用红包，会影响用户的下单体验。所以按照进一步的链路梳理降级，我们会优先保证红包的使用接口服务，而降级其他的红包调用链路。

当然，如果针对非核心链路分级太细，也会同时带来服务维护成本的提升，这块需要针对业务做相应的平衡。

人工智能探索

美团外卖自成立以来，就开始做一些 AI 方面的研究和尝试。比如：

OCR 方面，针对商家的证件照识别、营业执照识别等，这块的识别召回达到了 85% 以上，准确率我们达到 99% 以上；

机器人 方面，我们在和业界的一些智能音箱和家庭服务类机器人公司对接外卖服务，通过语音对话交流的方式，完成整个外卖订单的交易；

用户 方面，我们不久前上线了外卖智能助手服务，目前大家可以在微信钱包的美团外卖入口看到，也有部分 App 灰度用户可以看到。通过与智能助手小袋对话，她可以帮你快速的完成商家、商品的自动选择和推荐，体验还不错，大家可以去试试；

骑手配送 方面，美团外卖也在积极开发配送机器人，前不久刚刚发布了一个测试版本，大家可以在网络上搜到。

总之，正如王兴之前在“中国发展高层论坛 2018 年会”中说的，美团将会在科技创新、人工智能方面积极发展，普惠所有大众。外卖作为一个重要的连接线上线下的服务体，也会不断在 AI 方面做更多的尝试。

外卖的业务目标是能够在几年内达到每天上亿次的用户服务，那么针对外卖后端架构的发展，我想后续会更多的关注在多品类支撑的平台化改造方面，以及在越来越复杂的系统关系调度与智能化运维方向，更多这方面的细节，欢迎各位在 ArchSummit 深圳站 上与我们多多探讨。

如读者对报名ArchSummit感兴趣，可使用美团技术团队专属优惠码：meituantech，报名时享有特别优惠，如有问题可联系小助手豆包（微信：aschina666）

嘉宾介绍

方建平，美团点评技术总监，ArchSummit 出品人，致力于大型互联网分布式后台技术架构建设相关工作近十年。于 2014 年加入美团，目前主要负责美团外卖的后端技术。在美团外卖时期，从无到有，设计并主导构建了高效的分布式外卖后端技术架构体系，支撑了外卖业务背后亿级用户日访问处理请求。

个人对大型分布式服务建设过程中，不同阶段所需要解决的关键问题，以及对应的解决方案，有较多的认知与实践。在加入美团之前，任职于百度，主要参与负责百度开放平台、移动云平台等后端服务技术架构与团队管理工作。

----------  END  ----------

也许你还想看：

美团外卖Android Lint代码检查实践

美团外卖骑手背后的AI技术

美团外卖Android平台化架构演进实践