《美团外卖系统架构演进及系统稳定性经验谈_美团外卖》由会员分享，可在线阅读，更多相关《美团外卖系统架构演进及系统稳定性经验谈_美团外卖（32页珍藏版）》请在金锄头文库上搜索。
1、美团外卖系统 架构演进与系统稳定性经验谈 目录 个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则 个人简介 北纬通信北纬通信 移动增值服务 2006.72011.22011.32013.52013.5 新美大新美大 创新业务探索 美团外卖架构组 网易网易 网易视频库 网易应用 网易新闻 目录 个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则 美团外卖业务发展历程 扩展中 扩展中 外卖 配送 美团外卖业务发展历程 100w 400w 200w 300w 2013/112014/112015/05201
2、5/122016/05 ? WEB上线 业务MVP 在线支付 APP占90% 美团专送 全国启动 日交易额过亿 新LOGO 供给侧改革1000w 目录 个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则 技术体系架构演进介绍 技术架构：1.0 业务起步：MVP阶段 验证需求 寻找产品和需求的切合点 电话点餐-网络点餐 快速开发功能 快速调整流程 快速发布上线 美团外卖APP美团外卖WEB 移动后台WEB后台 dbwaimai 订单列表 技术体系架构演进介绍 技术架构：2.0 业务起步：规模化 寻找规模化的业务产品形态 提高运营效率 用户业务系统商家
3、业务系统 dbwaimai master/slave 运营业务系统公共服务系统 快速开发多个业务系统 复用工具库Util：http 复用业务库 AppWebI版PCApp打印机 合同审核上单MQ订单商家 技术体系架构演进介绍 技术架构：3.0 业务增长 校园市场全国开展 白领市场开拓 美团专送启动 平台活动增加 用户激增 订单激增 系统级容错 服务化重构 中间件 分库分表 API订单 数据层用户层应用层 接口层服务层基础层访问层存储层 性能监控统一配置中心MHA 外卖App 美团App 点评App 外卖商家 Native H5 Nginx 灰度 MTThrift 中间件 Open Web 商品
4、 商家 MQ KV ES . Atlas DB 异构 DB Databus 技术体系架构演进介绍 演进之路 问题 耦合 相互影响 容错差 服务化 中间件 KV 数据总线 异步化 系统架构 多逻辑耦合 直连DB 服务化SOA MTThrift 服务级容灾 Cache Redis 主从 Redis Cluster 共用KV专用KV MQ RabbitMQ 外卖大集群 订单集群 其他集群 延迟队列 重试队列 高级查询 DB join like DB 异构索 引表 Databus Elasticsearch 离线任务 Crontabquartz 分布式调度 Horae DB 一主 一从 一主多从 LV
5、S 一主多从 Atlas 基础服务基本功能 分流 限流 降级 目录 个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则 外卖业务稳定性的挑战 业务特点：高峰集中在中午、晚上饭点，爆发快 系统挑战：高并发，一旦发生故障损失较大 外卖业务稳定性的挑战 用户浏览 下单 支付 商家接单 骑手配送中 已送达 用户评价 结算 业务特点：服务链条长 系统挑战：依赖复杂 外卖业务稳定性的挑战 业务特点：发展快 技术挑战：开发迭代快 指标覆盖全 规则变化快 引入bug，稳定性风险 发版频繁发版频繁 架构优化排不上期 技术欠债 项目周期短项目周期短 监控难度大监控难度
6、大 目录 个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则 系统稳定性的处理原则 99.99% 系统可用性 订单可用性 系统稳定性的处理原则 日常运行 事前预警事后总结 事故处理 99.99% 稳定性架构设计 例行梳理和巡检 全链路在线压测 及时止损 保护用户体验 力保关键路径 性能大盘 业务大盘 健康分析 根本原因分析 影响损失核算 重构系统 系统稳定性的处理原则 日常运行日常运行 稳定性架构设计稳定性架构设计 大系统小做大系统小做 依赖稳定性原则依赖稳定性原则 保障用户体验的容错设计保障用户体验的容错设计 WEBAPI MQJOB WEBAP
7、I MessageCenter Task 读写 QueryManage 失败！ 服务器异常！ null 别看了，啥也没 抱歉，您选的商抱歉，您选的商 家运力不足，请家运力不足，请 选择其他商家选择其他商家 下单。下单。 异常情况下客户端的呈现 客户端配合限流 客户端配合降级 只依赖稳定的服务 将易变的部分拆分 超时中断 服务专一性 独立的功能拆分为独立的服务 系统稳定性的处理原则 日常运行日常运行 例行稳定性巡检例行稳定性巡检 静态梳理静态梳理 专项梳理专项梳理 指标巡检指标巡检 POIPOI APIAPI 定位定位 bannerbanner 定定 位位 频频 道道 用户用户RankRank
8、按场景Review 关键链路调用放大情况梳理 降低“高并发”，假高并发场景 DB健康Reivew，大表，慢查询 读写QPS，出轨，绿帽子 降级方案演练 性能大盘：不要放过尖刺 业务大盘：定心丸 报错大盘：定位好帮手 系统稳定性的处理原则 日常运行日常运行 全链路在线压测全链路在线压测 线上引流压测线上引流压测 全链路压测全链路压测 压测目标压测目标 Nginx WEB Thrift RPC KVMQDB 监控系统 原始 流量 事务 模拟 第三 方服 务 Mock 染 色 异步 阶梯 加压 流量录制 Nginx分组 ThriftRPC 分组 摘掉机器 读流量回放 写事务模拟 流量染色 异步阶梯加
9、压 告警自动终止 排查性能瓶颈，上探系统容量，验证降级机制 验证报警响应机制 & 指导设定警戒行动线 系统稳定性的处理原则 事前预警 性能大盘性能大盘 业务监控业务监控 健康分析健康分析 MQ API Service CPU Idle DB读、写QPS TP90 响应时间 超时率 业务大盘 脚印系统 指标变化趋势 KV flume log flume log flume log flume log KafkastormHBase 下单，各种信息，ip 支付 推送 系统稳定性的处理原则 事故处理 及时止损及时止损 保护用户体验 力保关键路径力保关键路径 应 用 APP 接收请求 请求令牌 处理请
10、求拒绝请求 统一配置管理 流控API：jar 策 略 生 成 K E Y 获取令牌 添加令牌 熔 断 本地令牌 日志监控 KV 降级 管理 客户端启动限流 回滚！ 分流 启动降级预案 限流 客户端配合降级 非关键路径模块降级 系统稳定性的处理原则 事故总结 根本原因分析 损失核算损失核算 系统系统& &流程改进流程改进 Incident Reviews Incident Reviews - - Ask the key questions:Ask the key questions: What went wrong? How could we have detected it sooner? H
11、ow could we have prevented it? How can we prevent this class of problem in the future? How can we improve our behavior for next time? 1 10 0：0000 收到收到DBDB CPUCPU 高的报警高的报警 1 10 0：2020 收到服务收到服务A A接口超时报警接口超时报警 1 10 0：2323 DBADBA定位分析定位分析 1 10 0：2525 xxxx同学回滚服务同学回滚服务 1 10 0：3 34 4 服务恢复服务恢复 5whys 损失的订单 系统
12、改进 流程改进 开发红线 系统稳定性的处理原则 RANK 用户 个性化推荐 附近商家 门店商品中心 订单中心 下单 推单 多种接单方式 支付平台 进店 广告系统线上营销 搜索引擎 行为数据收集 实时数据收集平台 风控策略 商业分析 /运营/BI 门店运营/容器 管理 接单 APPPC 打印机 派单配送 骑手调度中心 GIS路径规划 调度引擎策略引擎 骑手服务 配送实时 跟踪系统 离线/实时数据计算 挖掘平台 特征抽取与机器学习 模型训练 基础数据服务 活动计算引擎 力保关键路径 系统稳定性的处理原则 预案建设 上下游的超时约定。 性能是功能的一部分性能是功能的一部分 容错处理：超时，幂等，重试
13、。 稳定是功能的一部分稳定是功能的一部分 用户端，商家端的体验保障。 用户体验是一个完整的过程用户体验是一个完整的过程 开启 商家列表将按照默认排序 预案A A动作 B动作 C动作 规则引擎 统一配置中心 应用 操作 审计 监控 告警 系统稳定性的处理原则 系统稳定性的处理原则 需求管理项目开发测试发布上线监控报警故障处理 Task追踪 大功能设计 Review 重大技术方案 变更Review 上下游依赖变 化Review 分支管理 代码交叉 Review 代码静态检查 代码规范 日志规范 引入第三方工 具、JAR包SOP 依赖外部服务 SOP 数据库迁移/ 拆分SOP 测试环境使用 规范 R
14、D完成冒烟测 试 回归关键路径 及主要版本 项目提测流程 规范 线上压测流程 新业务上线 SOP 线上发布SOP 线上灰度SOP 数据库线上操 作SOP 线上容量调整 SOP 验证业务效果 业务指标监控 系统监控 Dashboard 第一时间想上 级反馈 及时周知业务 方：问题，影 响范围，解决 方案，预计恢 复时间 线上服务降级 SOP 稳定性的护航者：SOP。 每一步操作都是经过认真思考的。 系统稳定性的处理原则 发布内容 发布者 发布时间 基本信息基本信息 1 多系统协同步骤 发布步骤发布步骤 3 对下游的影响评估 对上游的影响评估 自身负载变化评估 影响预估影响预估 4 回滚的版本号
15、回滚步骤 回滚措施回滚措施 5 按城市 按功能 按百分比 灰度策略灰度策略 6 降级方案1 降级方案2 。 降级方案降级方案 7 日志,报错数 性能指标 关键流程回归 新功能测试 发布后验证发布后验证 8 可以改进的点 casestudy 发布总结发布总结 9 效果分析 完成完成 10 关键业务流程测试 新功能测试 SQL Review 代码Review 发布前验证发布前验证 2 将流程自动化进行到底。 系统稳定性的处理原则 发版窗口，晚高峰前发。. 灰度！灰度！灰度！灰度！灰度！灰度！ no join，SQL Review，慢查询巡检。 慢查询往往闯大祸。慢查询往往闯大祸。 做好对自身的保护，对依赖的熔断。 防御式编程，不要相信任何人和服务。防御式编程，不要相信任何人和服务。 每一步均严谨可信赖，危机时不慌、不乱、不遗不漏。 工具化，自动化。 SOP 保平安。保平安。 例行巡检，DB，调用链。 你所担心的一定会发生，可能马上发生。你所担心的一定会发生，可能马上发生。 总结
