美团外卖系统架构演进及系统稳定性经验谈_美团外卖
美团外卖管理组织信息系统分析
美团外卖管理信息系统分析指导老师：李蕴、孙小晴组长：周琳惠组员：孙迎秋、武少溥、尚雪容、史振蕾分工：规划和整理：第一部分：周琳惠第二部分：孙迎秋、武少溥第三部分：尚雪容、史振蕾第四部分：周琳惠完成时间：2017-一、系统简介1.名称：美团外卖管理信息系统2.开发者：周琳惠、孙迎秋、武少溥、尚雪容、史振蕾3.背景：随着互联网技术的快速发展，网络早已成为现代人群日常生活中不可或缺的部分，网上订餐由于其独有的便捷性和直观性，能够轻而易举的被现代人群认同和接受。
从一方面来看，互联网上诞生出这种便捷的订餐形式，是电子商务应用的全新体现；从另一各方面来看，网上订餐还起到了帮助推进电子商务的普及和应用进程的作用，网上订餐的形式，同时也在帮助加速电子商务应用的步伐。
美团外卖是目前学生、白领、宅男宅女进行网络订餐的首选系统平台，然而“送餐慢”、“送错餐”等现象却屡屡发生，极大地耽误了顾客与配送员的时间，降低了效率，损坏了口碑，只有对当前的外卖管理系统进行整合改进优化，才能最大限度的满足多样化的顾客需求，促进美团外卖自身的发展。
4.目标：建立健全现有的美团外卖管理信息系统：对订单进行区域分类，改善订单追踪困难的问题；及时更新商家接单、配送员到达商家及顾客收到餐的信息，便于处理催单等的信息；根据订餐的高低峰时期，合理分配外卖人员，提高效率；改善客户终端网络系统，简洁方便联系客户；根据顾客往日订餐状况，智能推测顾客的消费偏好，满足更多顾客多样化的需求。
5.可行性分析：（1）组织可行性：我们组有五个人，通过合理的分工协作：制定合理的项目实施进度计划，设计合理组织机构，选择经验丰富的管理人员及技术人员，建立良好的协作关系等，保证该系统能顺利执行。
（2）经济可行性：如今是信息化时代，信息化管理可以使外卖管理更加系统化，全面化、快速化，这样可以为美团外卖带来高效的工作效益和经济效益，开发出本系统可以精简人员，提高效率，便捷管理，快速实现各项功能。
外卖平台架构总结
外卖平台架构总结引言外卖平台作为现代快节奏生活中的重要组成部分，为人们提供了方便快捷的饮食服务。
然而，背后支持外卖平台正常运行的是一个复杂的信息系统架构。
本文将对外卖平台的架构进行总结，以便更好地了解其运行原理与技术实现。
架构概述外卖平台的架构通常可以分为四个主要组件：客户端、服务器、数据库和第三方服务。
客户端是用户与系统之间的接口，用户通过客户端进行下单、浏览菜单等操作。
服务器是外卖平台的核心部分，负责处理客户端请求、与数据库进行交互，并提供给用户最新的外卖信息。
数据库存储了外卖平台的相关数据，如用户信息、订单信息和菜单信息。
第三方服务包括支付系统、短信验证等，为外卖平台提供必要的支持服务。
客户端外卖平台的客户端通常包括Web端和移动端（Android和iOS）。
客户端通过与服务器进行通信，将用户的请求发送到服务器，并接收服务器返回的信息展示给用户。
客户端需要提供良好的用户体验和友好的界面设计，方便用户进行操作和浏览。
服务器外卖平台的服务器是整个系统的核心部分，负责接收和处理客户端的请求，并将相关数据返回给客户端。
服务器需要具备高并发处理能力和稳定性，以应对大量的用户访问和订单处理。
为了提高性能，服务器通常使用集群架构，通过负载均衡技术将请求分发给多个服务器，实现高效的并发处理。
服务器端的技术栈通常包括以下组件： - Web服务器：常见的Web服务器有Nginx和Apache，用于接收和转发客户端请求。
- 应用服务器：应用服务器用于处理业务逻辑，如订单处理、菜单展示等。
常见的应用服务器有Tomcat和Node.js。
- 数据库连接池：由于数据库操作是相对耗时的，为了提高性能，通常会使用数据库连接池技术。
连接池可以预先创建一定数量的数据库连接，当有请求需要访问数据库时，直接从连接池中获取连接，避免了频繁创建和释放连接的开销。
数据库数据库是外卖平台存储数据的关键组件。
外卖平台通常使用关系型数据库来存储各种数据，如用户信息、订单信息和菜单信息等。
美团外卖管理信息系统分析
消费者信息管理流程分析
01
用户信息管理流程分析
顾客 输 入 网 址
P2 信息录入
客 户 信 息
所有客户信息
D0
用户信息表
P1 登录网站
客 户 信 息
商家
02
餐馆 密用 码户 名
营业者信息管理流程分析
顾客 P2 录入商 品信息 商品信息 D1 商品信息
P1 登录网站
商 品 信 息 餐 厅 信 息
商品信息表
（1）美团以35%美团股权、 65%的现金收购摩拜单车。 （2）美团旅行与银联国际将
在技术、大数据与购物体验方
面加深探索，让旅行购物更加 优惠、便捷。
美团外卖简介
（1）美团外卖品类包括附近美食、水果、蔬 菜、超市、鲜花、蛋糕等，无论是早午晚餐、 下午茶、宵夜，还是中餐、西餐、家常菜、 小吃、快餐、海鲜、火锅、川菜、蛋糕、烤 肉、水果、饮料、甜点等； （2）大量品牌入驻，如必胜客、肯德基、 KFC、麦当劳、汉堡王、星巴克、COCO都 可奶茶、U鼎冒菜、真功夫、每日优鲜、美 食天下等 美团外卖是美团网旗下网上订餐平台，于 2013年11月正式 （3）美团外卖还提供送药上门、美团专送、 上线，总部位于北京。美团外卖用户数达 2.5亿，合作商户数超 跑腿代购等多种服务； 过200万家，活跃配送骑手超过 50万名，覆盖城市超过 1300个， （4）电脑、手机 APP、微信均可下单，支持 日完成订单1800万单。 美团支付、微信支付、支付宝、Apple pay 等多种支付方式
02
品牌简介
1、企业概况 2、发展历程
企业概况
美团网，2010年3月4日成立的团购 网站，是中国大陆第一个精品团购形式 的电子商务网站，在北京、上海等地设 有分站。 美团网有着“吃喝玩乐全都有 ”和“美团一次美一次”的服务宣传宗 旨。并且遵循“消费者第一、商家第二 ”的原则，为消费者提供优质服务，同 时给商家提供最大的收益。
美团外卖架构演变
技术体系架构演进介绍
0 1.0 MVP阶段
1
2013.10
0 2.0 规模化阶段
2
Deficiencies in work
03 3.0 业务增长阶段 Rationalization suggestions
0 技术总结
4
Work plan for next year
01
MVP阶段
所谓最小化可用产品(MVP)，是让开发团队用最小的代价实现一个产品，以 此最大程度上了解和验证对用户问题的解决程度
04
技术总结
总结一下的话，我们的演进大概分了这样一个阶段：整体上有一个多逻辑耦合在一起 的情况按服务化拆分出来，每一个服务独立专注地做一个事情，然后我们再做应用级 的容错，到现在我们在做多机房的容错。
在缓存上，我们早期使用了 Redis，在 Redis Cluster 还没发布之前我们用了他们的 Alpha 版本，当然也踩了很多坑。后来我们用了自研的 KV 系统，最早的时候我们把 所有业务的 KV 都是共用的，这个也有很大的问题：如果所有的业务共用的 KV 集群， 其中某一个业务导致这个 KV 集群有问题的话，所有的业务都受影响。后来我们也做 了每一个业务拆分自己专用的 KV 集群。
日常运行
事前预警
事故处理
事故总结
谢
谢
THH
看
技术迭代
外卖业务稳定性挑战
高峰期的时 候，有一分 钟接进 2 万 单的巨大流 量
大家理解送外卖是一个很简单 的事情，我点了餐，送过来， 我愉快的把它吃掉就结束了， 但是做外卖的事情上我们发现 确实蛮复杂的，因为我们发现 用户要下单，要支付，我们还 要调度一个配送员，我们找一 个最快最合理的骑手，让他到 时间取餐送过去，同时还要给 这个骑手最好的路径规划，告 诉他走这条路是最快的。所以 整个是一个非常复杂的过程， 有非常非常多的服务。下面中 图是我们服务治理的情况，是 服务之间错综复杂的调用情况；
美团外卖IT系统架构演进
美团外卖IT系统架构演进作为日千万订单级别的业务，美团外卖的后端服务是怎么支撑的？写在前面2018年4月，中国外卖市场迎来巨变，外卖从无人问津开始，到现在已经培育成互联网巨头必争之地。
作为为数不多能够达到日千万订单级别的业务，其后端服务是怎么支撑的？InfoQ采访了ArchSummit出品人、美团点评技术总监方建平，请他回顾及展望美团外卖的后端架构史，本文根据采访整理而成。
美团外卖后端架构迭代各阶段美团外卖发展到今天差不多有4 年多的时间，按照外卖业务发展的几个特征，可以相应地把外卖技术分成三个主要阶段：第一阶段：业务初探期大约截止到2015 年初，持续差不多一年左右的时间。
这个阶段的主要特征就是美团对于外卖的业务还处于市场摸索期，研发人员相对也比较少，差不多10 来个同学，产品上需要快速迭代、试错。
所以这个阶段的系统架构比较简单，就是典型的单系统Web 应用服务，主要是需要满足产品需求上的快速上线，验证业务模型的市场可行性。
第二阶段：业务爆发期外卖业务在2015 年初开始了爆发式增长。
基于当前外卖的业务特性，90% 以上的交易都是在午高峰和晚高峰这个期间完成的，对业务系统来说高峰期负载重，压力大。
这个阶段，我们主要是从最早期的基于单系统的Web 应用架构，向分布式服务架构的迁移改造。
期间主要优化工作如下：一、做架构的拆分，应对高并发、保证高性能对系统的拆分，主要体现在系统服务层、以及数据存储层上。
通过对线上业务流程的分解，将外卖系统分成数据浏览体系、用户订单交易体系、商户接单配送体系、用户信息UGC 服务等，同时也针对大的业务服务体系内的流量分布、以及功能差异性，再做进一步的拆解。
比如浏览体系中会有门店服务、商品服务、搜索推荐服务等等。
针对并发的读写数据压力，我们也针对性地搭建了相应的分布式缓存服务、针对特定数据库表，例如订单表，也进行了基于订单ID、门店ID、用户ID 等多个维度的拆库、拆表操作。
美团一站式业务稳定性保障平台的 AIOps 实践
美团配送稳定性保障平台的AIOps实践
⽬目录1、什么是AIOps
2、为什么要AIOps
3、如何搭建智能运维的能力
4、美团配送的实践
5、机器学习能力的探索
Gartner 2016 : AI + ops + data，用数据+算法解决IT问题，替代传统运维 什什么是
AIOps
⽤用户⻆角度的美团外卖配送RD⻆角度的美团外卖配送
传统运维智能运维
保障系统各环节运行流畅，以快速解决问题为目标 •网络监控
•硬件监控
•系统监控聚焦业务，提升业务运行稳定为主
•关注用户体验
•关注业务核心指标
•强调SLA、MTTR
•深入业务链路拓扑
•1个人运维几百个服务、几十个DB集群、几千台vm •善用数据、挖掘数据
如何搭建智能运维的能⼒力力
实施准则
•AI只是辅助手段
•更适合大规模业务、服务、集群的运维
•关注ROI、实验和实战才能结合好
•运维数据、经验的积累，会极大的影响AIOps的效果 •无人值守的运维，是AIOps的最后一公里（L5） •AIOps是趋势，是浪潮。
美团外卖分布式系统架构设计
美团外卖分布式系统架构设计背景美团外卖已经发展了五年，即时物流探索也经历了3年多的时间，业务从零孵化到初具规模，在整个过程中积累了⼀些分布式⾼并发系统的建设经验。
最主要的收获包括两点：1. 即时物流业务对故障和⾼延迟的容忍度极低，在业务复杂度提升的同时也要求系统具备分布式、可扩展、可容灾的能⼒。
即时物流系统阶段性的逐步实施分布式系统的架构升级，最终解决了系统宕机的风险。
2. 围绕成本、效率、体验核⼼三要素，即时物流体系⼤量结合AI技术，从定价、ETA、调度、运⼒规划、运⼒⼲预、补贴、核算、语⾳交互、LBS挖掘、业务运维、指标监控等⽅⾯，业务突破结合架构升级，达到促规模、保体验、降成本的效果。
本⽂主要介绍在美团即时物流分布式系统架构逐层演变的进展中，遇到的技术障碍和挑战：订单、骑⼿规模⼤，供需匹配过程的超⼤规模计算问题。
遇到节假⽇或者恶劣天⽓，订单聚集效应，流量⾼峰是平常的⼗⼏倍。
物流履约是线上连接线下的关键环节，故障容忍度极低，不能宕机，不能丢单，可⽤性要求极⾼。
数据实时性、准确性要求⾼，对延迟、异常⾮常敏感。
美团即时物流架构美团即时物流配送平台主要围绕三件事展开：⼀是⾯向⽤户提供履约的SLA，包括计算送达时间ETA、配送费定价等；⼆是在多⽬标（成本、效率、体验）优化的背景下，匹配最合适的骑⼿；三是提供骑⼿完整履约过程中的辅助决策，包括智能语⾳、路径推荐、到店提醒等。
在⼀系列服务背后，是美团强⼤的技术体系的⽀持，并由此沉淀出的配送业务架构体系，基于架构构建的平台、算法、系统和服务。
庞⼤的物流系统背后离不开分布式系统架构的⽀撑，⽽且这个架构更要保证⾼可⽤和⾼并发。
分布式架构，是相对于集中式架构⽽⾔的⼀种架构体系。
分布式架构适⽤CAP理论（Consistency ⼀致性，Availability 可⽤性，Partition Tolerance 分区容忍性）。
在分布式架构中，⼀个服务部署在多个对等节点中，节点之间通过⽹络进⾏通信，多个节点共同组成服务集群来提供⾼可⽤、⼀致性的服务。
美团软件体系结构分析
架构重构案例
效果
重构后，美团外卖业务处理能力大幅提升，用户体验得到显著改善。
案例二
美团酒店架构重构
背景
美团酒店业务面临订单量大、并发访问高、数据一致性要求高等挑战。
架构重构案例
架构重构案例
采用分布式架构，将系统拆分为多个子系统，实现负载均衡和横向扩展。引入数据库分片技术，提高数据存储和查询效率。同时，加强系统监控和告警机制，确保系统稳定运行。
安全性高
美团软件体系结构采用了多种安全措施，包括数据加密、访问控制、安全审计等，确保用户数据的安全性。
优势分析
随着技术的不断发展，美团软件体系结构需要不断更新和升级，以适应新的业务需求和技术趋势。
技术更新快
不同用户的需求差异较大，美团软件体系结构需要不断优化和改进，以满足用户的个性化需求。
用户需求多样化
感谢您的观看
公司背景
01
02
业务范围
美团还通过与线下实体商家合作，提供线上预订、线下体验的服务模式，为消费者提供更加便捷的消费体验。
美团的业务覆盖了餐饮、酒店、旅游、零售等多个领域，通过提供在线点餐、外卖、团购等服务，满足消费者的日常需求。
技术团队
美团拥有一支强大的技术团队，涵盖了多个领域的技术专家和工程师。
架构优化案例
优化后，美团点评搜索性能大幅提升，用户满意度明显提高。
效果
美团买菜架构优化
案例二
美团买菜业务需要快速响应用户订单需求，对系统响应速度要求高。
背景
架构优化案例
VS
采用缓存技术，减少对数据库的直接访问，提高系统响应速度。引入分布式缓存系统，实现数据的高可用性和一致性。同时，优化数据库查询语句和索引，提高数据查询效率。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
多逻辑耦合 直连DB Redis 主从 RabbitMQ 外卖大集群 DB join like
服务化SOA MTThrift Redis Cluster 订单集群 其他集群 DB 异构索 引表
服务级容灾
Cache
共用KV 延迟队列 重试队列
专用KV
MQ
高级查询
演进之路
服务化 中间件 KV 数据总线 异步化
压测目标
排查性能瓶颈，上探系统容量，验证降级机制 验证报警响应机制 & 指导设定警戒行动线
系统稳定性的处理原则
事前预警
性能大盘
CPU Idle DB读、写QPS TP90 响应时间 超时率
log API flume
Service
log
flume Kafka storm HBase
业务监控
KV
log
flume 下单，各种信息，ip
业务大盘 脚印系统
MQ log flume
2013/11
2014/11
2015/05
2015/12
2016/05
?
目录
• • • • •
个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则
技术体系架构演进介绍
业务起步：MVP阶段
美团外卖APP 验证需求 寻找产品和需求的切合点 电话点餐->网络点餐 移动后台 WEB后台 美团外卖WEB
频 道
定位
系统稳定性的处理原则
日常运行 >>全链路在线压测 线上引流压测
Nginx分组 ThriftRPC 分组 摘掉机器
Nginx WEB 第三 方服 务 Mock
全链路压测
读流量回放 写事务模拟 流量染色 异步阶梯加压 告警自动终止
流量录制
KV
MQ
DB
Thrift RPC 原始 流量 事务 模拟 染 色 异步 阶梯 加压 监控系统
外卖业务稳定性的挑战
业务特点：高峰集中在中午、晚上饭点，爆发快 系统挑战：高并发，一旦发生故障损失较大
外卖业务稳定性的挑战
业务特点：服务链条长 系统挑战：依赖复杂
用户浏览 下单 支付 商家接单 骑手配送中 已送达 用户评价 结算
外卖业务稳定性的挑战
业务特点：发展快 技术挑战：开发迭代快
发版频繁
离线任务
Databus Elasticsearch 分布式调度 Horae 一主多从 Atlas 降级
Crontab 一主 一从 基本功能 一主多从 LVS 分流 限流
quartz
DB
基础服务
目录
• • • • •
个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则
目录
• • • • •
个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则
美团外卖业务发展历程
扩展中
扩展中
外卖
配送
美团外卖业务发展历程
供给侧改革 1000w
日交易额过亿 新LOGO 400w 美团专送 全国启动 在线支付 APP占90% WEB上线 业务MVP 200w 100w 300w
日常运行 >>例行稳定性巡检 静态梳理
按场景Review 关键链路调用放大情况梳理 降低“高并发”，假高并发场景
banner 定 位
专项梳理
DB健康Reivew，大表，慢查询 读写QPS，出轨，绿帽子 降级方案演练
API
用户
Rank
POI
指标巡检
性能大盘：不要放过尖刺 业务大盘：定心丸 报错大盘：定位好帮手
技术架构：1.0
快速开发功能 快速调整流程 快速发布上线 订单列表
dbwaimai
技术体系架构演进介绍
业务起步：规模化
寻找规模化的业务产品形态 提高运营效率
App
I版
用户业务系统
Web
PC
App
商家业务系统
打印机
dbwaimai master/slave
技术架构：2.0
快速开发多个业务系统 复用工具库Util：http 复用业务库
引入bug，稳定性风险
项目周期短
架构优化排不上期 技术欠债
监控难度大
指标覆盖全 规则变化快
目录
• • • • •
个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则
系统稳定性的处理原则
99.99%
系统可用性 订单可用性
系统稳定性的处理原则
日常运行
稳定性架构设计 例行梳理和巡检
美团外卖系统 架构演进与系统稳定性经验谈
目录
• • • • •
个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则
个人简介
北纬通信
移动增值服务
新美大
创新业务探索 美团外卖架构组
2006.7~2011.2
2011.3~2013.5
2013.5~
网易
网易视频库 网易应用 网易新闻
事故处理
及时止损 保护用户体验 99.99% 力保关键路径
全链路在线压测
事前预警
性能大盘 业务大盘 健康分析
事后总结
根本原因分析 影响损失核算 重构系统
系统稳定性的处理原则
日常运行 >>稳定性架构设计
大系统小做
服务专一性 独立的功能拆分为独立的服务
WEB MQ
API JOB
WEB
API
MessageCenter
合同
运营业务系统 审核 上单 MQ
公共服务系统 订单
商家
技术体系架构演进介绍
业务增长
校园市场全国开展 白领市场开拓 美团专送启动 平台活动增加 用户激增 订单激增
用户层 接口层 Native H5 外卖App
应用层 服务层 基础层 中间件
数据层 访问层 存储层
Nginx 灰度
Task
依赖稳定性原则
只依赖稳定的服务 将易变的部分拆分 超时中断
读 写
Query
Manage
保障用户体验的容错设计
异常情况下客户端的呈现 客户端配合限流 客户端配合降级
失败！ 服务器异常！ null 别看了，啥也没
抱歉，您选的商 家运力不足，请 选择其他商家 下单。
系统稳定性的处理原则
API
MTThrift
订单
MQ
Atlas DB
技术架构：3.0
系统级容错 服务化重构 中间件 分库分表
美团App
Open
商品
KV Databus
点评App 外卖商家
Web
商家
ES 异构 DB
...
性能监控
统一配置中心
MHA
技术体系架构演进介绍
问题
系统架构
耦合 相互影响 容错差