美团外卖系统架构演进与系统稳定性经验谈_美团外卖
美团技术实现原理
美团技术实现原理美团作为中国领先的生活服务平台，其背后涉及到复杂的技术系统和多样的业务场景。
本文将从美团技术的整体架构、核心技术模块和实现原理等方面进行介绍，帮助读者更好地理解美团技术的运作机制。
一、整体架构美团技术整体架构主要分为前端系统、后端系统和数据存储系统三大部分。
前端系统主要负责用户交互和展示，包括网页端和移动端。
后端系统负责业务逻辑的处理和数据的计算，同时与前端系统交互。
数据存储系统则是对数据进行存储和管理，以支撑业务系统的正常运作。
在这些基础之上，美团还有服务治理、安全技术、性能优化等技术保障的支撑。
二、核心技术模块1. 分布式系统为了支撑庞大的用户量和业务需求，美团采用了分布式系统架构。
分布式系统能够将数据存储在多个节点上，提高了系统性能和容错能力。
美团还采用了一系列分布式计算技术，如分布式调度、分布式事务等，以满足不同业务场景的需求。
2. 大数据技术美团在数据分析、用户画像、智能推荐等方面大量应用大数据技术。
通过Hadoop、Spark等大数据处理框架，能够对海量数据进行快速高效的计算和分析，为美团提供了业务决策和智能化推荐的基础。
3. 微服务架构微服务架构是美团后端系统的核心模式之一，它将整个系统拆分为多个小的服务单元，每个单元都能独立部署和扩展。
这种架构能够带来更好的故障隔离和灵活的业务拓展能力，同时也简化了团队的协作和开发流程。
4. 人工智能技术美团在人工智能技术方面投入力度较大，主要体现在智能推荐、自然语言处理、计算机视觉等方面。
通过机器学习、深度学习等技术手段，美团能够实现个性化推荐、语义理解、图像识别等功能，为用户提供更好的服务体验。
三、实现原理1. 订单系统在美团的订单系统中，主要涉及到用户下单、商家接单、配送员接单等环节。
整个系统借助分布式事务和消息队列等技术，确保了订单的一致性和可靠性。
美团还通过大数据分析用户行为和商家数据，为订单处理提供更精准的推荐和预测。
外卖平台架构总结
外卖平台架构总结引言外卖平台作为现代快节奏生活中的重要组成部分，为人们提供了方便快捷的饮食服务。
然而，背后支持外卖平台正常运行的是一个复杂的信息系统架构。
本文将对外卖平台的架构进行总结，以便更好地了解其运行原理与技术实现。
架构概述外卖平台的架构通常可以分为四个主要组件：客户端、服务器、数据库和第三方服务。
客户端是用户与系统之间的接口，用户通过客户端进行下单、浏览菜单等操作。
服务器是外卖平台的核心部分，负责处理客户端请求、与数据库进行交互，并提供给用户最新的外卖信息。
数据库存储了外卖平台的相关数据，如用户信息、订单信息和菜单信息。
第三方服务包括支付系统、短信验证等，为外卖平台提供必要的支持服务。
客户端外卖平台的客户端通常包括Web端和移动端（Android和iOS）。
客户端通过与服务器进行通信，将用户的请求发送到服务器，并接收服务器返回的信息展示给用户。
客户端需要提供良好的用户体验和友好的界面设计，方便用户进行操作和浏览。
服务器外卖平台的服务器是整个系统的核心部分，负责接收和处理客户端的请求，并将相关数据返回给客户端。
服务器需要具备高并发处理能力和稳定性，以应对大量的用户访问和订单处理。
为了提高性能，服务器通常使用集群架构，通过负载均衡技术将请求分发给多个服务器，实现高效的并发处理。
服务器端的技术栈通常包括以下组件： - Web服务器：常见的Web服务器有Nginx和Apache，用于接收和转发客户端请求。
- 应用服务器：应用服务器用于处理业务逻辑，如订单处理、菜单展示等。
常见的应用服务器有Tomcat和Node.js。
- 数据库连接池：由于数据库操作是相对耗时的，为了提高性能，通常会使用数据库连接池技术。
连接池可以预先创建一定数量的数据库连接，当有请求需要访问数据库时，直接从连接池中获取连接，避免了频繁创建和释放连接的开销。
数据库数据库是外卖平台存储数据的关键组件。
外卖平台通常使用关系型数据库来存储各种数据，如用户信息、订单信息和菜单信息等。
外卖平台架构总结(共3篇)
外卖平台架构总结(共3篇)外卖平台架构总结第1篇好的架构源于不停地衍变而非设计。
美团外卖的架构，历史上也是经历了很多次迭代。
由于外卖业务形态不断地发生变化，原有的设计也需要不断地跟随业务形态进行演进。
在不断探索和实践过程中，我们经历了若干个大的架构变迁。
从考虑如何高效地复用代码支持外卖App，逐渐地衍变成如何去解决多端代码复用问题，再从多端的代码复用到支持其他频道业务的平台架构上。
在平台化架构建设完成后，我们又开始尝试利用动态化技术去支持业务快速上线的诉求。
如今，我们面临着多端复用、平台能力、平台支撑、单页面多业务团队、业务动态诉求强等多个业务场景问题。
下文我们针对美团外卖移动端架构的变迁史，做一些简单的概述，以便读者阅读本文时能有更好的延续性。
外卖平台架构总结第2篇从搜索库拆分的第一次尝试算起，外卖Android客户端在架构上的持续探索和实践已经经历了2年多的时间。
起初为了解决两端代码复用的问题，我们尝试过自上而下的强行拆分和复用，但很快就暴露出层次混乱、边界模糊带来的问题，并且认识到如果不能提供两端差异化的解决方案，代码复用是很难持续的。
后来我们又尝试过运用设计模式约束边界，先实现解耦再进行复用，但在推广落地过程中认识到复杂的设计很难快速推进下去。
在两端代码复用的问题上，我们认识到要实现可持续的代码复用，必须自下向上的逐步统一两端底层的基础依赖，同时又能容易的支持两端上层业务的差异化处理。
使用Flavor管理两端的差异代码，尽量减少向上依赖，在具体实施时应用之前积累的解耦设计的经验，从而满足了架构的可伸缩性。
没有一个方案能获得每个人的赞同。
在平台化的实施过程中，团队成员多次对方案选型发生过针锋相对的讨论。
这时我们会抛开技术方案，回到问题本身，去重新审视业务的痛点，列出要解决的问题，再回过头来看哪一个方案能够解决问题。
虽然我们并不常常这么做，但某些时刻也会强制决策和实施，遇到问题再复盘和调整。
美团外卖架构演变
技术体系架构演进介绍
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 等多个维度的拆库、拆表操作。
美团信息系统研究报告范文
美团信息系统研究报告范文【摘要】美团信息系统是美团公司发展壮大的重要支撑，对于美团的经营管理和业务拓展起到了至关重要的作用。
本报告通过对美团信息系统的研究，从系统架构、功能模块、技术支持等方面进行深入分析，以期为美团信息系统的未来发展提供借鉴和参考。
【关键词】美团、信息系统、系统架构、功能模块、技术支持一、引言美团作为国内领先的O2O平台之一，其信息系统的设计和运营对于公司的发展至关重要。
随着互联网技术的不断发展和O2O市场的日益竞争，美团信息系统需要不断创新和改进，以适应市场的需求和用户的需求。
二、系统架构美团信息系统的系统架构采用了分层架构和微服务架构相结合的设计。
分层架构将系统按照功能划分成不同层次，每一层负责不同的功能模块；微服务架构将每个功能模块划分成独立的服务，在不同的服务器上运行，提高了系统的可伸缩性和可维护性。
三、功能模块美团信息系统的功能模块主要包括用户管理、商家管理、订单管理、支付管理等。
1. 用户管理模块：负责用户注册、登录、个人信息管理等功能，保证用户信息的安全和准确性。
2. 商家管理模块：负责商家入驻、资料管理、店铺管理等功能，提供给商家便捷的经营工具。
3. 订单管理模块：负责订单的生成、分配、处理等功能，保证订单流程的顺利进行。
4. 支付管理模块：负责支付的安全、快捷、方便，保证用户的支付体验。
四、技术支持美团信息系统的技术支持主要包括数据库技术、云计算技术和大数据技术。
1. 数据库技术：采用主从复制和分片技术，保证系统的高可用性和扩展性。
2. 云计算技术：采用云服务器和容器技术，提高了系统的可靠性和弹性。
3. 大数据技术：采用Hadoop和Spark等大数据处理框架，对海量数据进行分析和挖掘，为美团提供精准的商业决策支持。
五、结论美团信息系统是美团公司成功发展的重要支撑，通过对其系统架构、功能模块和技术支持的研究，可以看出其在信息化建设方面取得了显著成果。
然而，随着市场需求和技术的不断变化，美团信息系统仍面临一些挑战和问题。
美团外卖分布式系统架构设计
美团外卖分布式系统架构设计背景美团外卖已经发展了五年，即时物流探索也经历了3年多的时间，业务从零孵化到初具规模，在整个过程中积累了⼀些分布式⾼并发系统的建设经验。
最主要的收获包括两点：1. 即时物流业务对故障和⾼延迟的容忍度极低，在业务复杂度提升的同时也要求系统具备分布式、可扩展、可容灾的能⼒。
即时物流系统阶段性的逐步实施分布式系统的架构升级，最终解决了系统宕机的风险。
2. 围绕成本、效率、体验核⼼三要素，即时物流体系⼤量结合AI技术，从定价、ETA、调度、运⼒规划、运⼒⼲预、补贴、核算、语⾳交互、LBS挖掘、业务运维、指标监控等⽅⾯，业务突破结合架构升级，达到促规模、保体验、降成本的效果。
本⽂主要介绍在美团即时物流分布式系统架构逐层演变的进展中，遇到的技术障碍和挑战：订单、骑⼿规模⼤，供需匹配过程的超⼤规模计算问题。
遇到节假⽇或者恶劣天⽓，订单聚集效应，流量⾼峰是平常的⼗⼏倍。
物流履约是线上连接线下的关键环节，故障容忍度极低，不能宕机，不能丢单，可⽤性要求极⾼。
数据实时性、准确性要求⾼，对延迟、异常⾮常敏感。
美团即时物流架构美团即时物流配送平台主要围绕三件事展开：⼀是⾯向⽤户提供履约的SLA，包括计算送达时间ETA、配送费定价等；⼆是在多⽬标（成本、效率、体验）优化的背景下，匹配最合适的骑⼿；三是提供骑⼿完整履约过程中的辅助决策，包括智能语⾳、路径推荐、到店提醒等。
在⼀系列服务背后，是美团强⼤的技术体系的⽀持，并由此沉淀出的配送业务架构体系，基于架构构建的平台、算法、系统和服务。
庞⼤的物流系统背后离不开分布式系统架构的⽀撑，⽽且这个架构更要保证⾼可⽤和⾼并发。
分布式架构，是相对于集中式架构⽽⾔的⼀种架构体系。
分布式架构适⽤CAP理论（Consistency ⼀致性，Availability 可⽤性，Partition Tolerance 分区容忍性）。
在分布式架构中，⼀个服务部署在多个对等节点中，节点之间通过⽹络进⾏通信，多个节点共同组成服务集群来提供⾼可⽤、⼀致性的服务。
美团软件体系结构分析
架构重构案例
效果
重构后，美团外卖业务处理能力大幅提升，用户体验得到显著改善。
案例二
美团酒店架构重构
背景
美团酒店业务面临订单量大、并发访问高、数据一致性要求高等挑战。
架构重构案例
架构重构案例
采用分布式架构，将系统拆分为多个子系统，实现负载均衡和横向扩展。引入数据库分片技术，提高数据存储和查询效率。同时，加强系统监控和告警机制，确保系统稳定运行。
安全性高
美团软件体系结构采用了多种安全措施，包括数据加密、访问控制、安全审计等，确保用户数据的安全性。
优势分析
随着技术的不断发展，美团软件体系结构需要不断更新和升级，以适应新的业务需求和技术趋势。
技术更新快
不同用户的需求差异较大，美团软件体系结构需要不断优化和改进，以满足用户的个性化需求。
用户需求多样化
感谢您的观看
公司背景
01
02
业务范围
美团还通过与线下实体商家合作，提供线上预订、线下体验的服务模式，为消费者提供更加便捷的消费体验。
美团的业务覆盖了餐饮、酒店、旅游、零售等多个领域，通过提供在线点餐、外卖、团购等服务，满足消费者的日常需求。
技术团队
美团拥有一支强大的技术团队，涵盖了多个领域的技术专家和工程师。
架构优化案例
优化后，美团点评搜索性能大幅提升，用户满意度明显提高。
效果
美团买菜架构优化
案例二
美团买菜业务需要快速响应用户订单需求，对系统响应速度要求高。
背景
架构优化案例
VS
采用缓存技术，减少对数据库的直接访问，提高系统响应速度。引入分布式缓存系统，实现数据的高可用性和一致性。同时，优化数据库查询语句和索引，提高数据查询效率。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
项目周期短
架构优化排不上期 技术欠债
监控难度大
指标覆盖全 规则变化快
目录
• • • • •
个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则
系统稳定性的处理原则
99.99%
系统可用性 订单可用性
系统稳定性的处理原则
日常运行
稳定性架构设计 例行梳理和巡检
做好对自身的保护，对依赖的熔断。
SOP 保平安。
每一步均严谨可信赖，危机时不慌、不乱、不遗不漏。 工具化，自动化。
你所担心的一定会发生，可能马上发生。
例行巡检，DB，调用链。
• • • • • •
新业务上线 SOP 线上发布SOP 线上灰度SOP • 数据库线上操 • 作SOP 线上容量调整 SOP 验证业务效果
• • 业务指标监控 系统监控 Dashboard
•
第一时间想上 级反馈 及时周知业务 方：问题，影 响范围，解决 方案，预计恢 复时间 线上服务降级 SOP
系统稳定性的处理原则
事故处理
及时止损 保护用户体验 99.99% 力保关键路径
全链路在线压测
事前预警
性能大盘 业务大盘 健康分析
事后总结
根本原因分析 影响损失核算 重构系统
系统稳定性的处理原则
日常运行 >>稳定性架构设计
大系统小做
服务专一性 独立的功能拆分为独立的服务
WEB MQ
API JOB
WEB
API
MessageCenter
系统稳定性的处理原则
力保关键路径
支付平台 门店商品中心 门店运营/容器 管理 风控策略 多种接单方式
订单中心
活动计算引擎
APP 打印机
PC
用户
附近商家
进店
下单
推单
接单
派单
配送
RANK 线上营销
个性化推荐 广告系统 基础数据服务
骑手调度中心 GIS路径规划 调度引擎
配送实时 跟踪系统 骑手服务 策略引擎
日常运行 >>例行稳定性巡检 静态梳理
按场景Review 关键链路调用放大情况梳理 降低“高并发”，假高并发场景
banner 定 位
专项梳理
DB健康Reivew，大表，慢查询 读写QPS，出轨，绿帽子 降级方案演练
API
用户
Rank
POI
指标巡检
性能大盘：不要放过尖刺 业务大盘：定心丸 报错大盘：定位好帮手
频 道
定位
系统稳定性的处理原则
日常运行 >>全链路在线压测 线上引流压测
Nginx分组 ThriftRPC 分组 摘掉机器
Nginx WEB 第三 方服 务 Mock
全链路压测
读流量回放 写事务模拟 流量染色 异步阶梯加压 告警自动终止
流量录制
KV
MQ
DB
Thrift RPC 原始 流量 事务 模拟 染 色 异步 阶梯 加压 监控系统
外卖业务稳定性的挑战
业务特点：高峰集中在中午、晚上饭点，爆发快 系统挑战：高并发，一旦发生故障损失较大
外卖业务稳定性的挑战
业务特点：服务链条长 系统挑战：依赖复杂
用户浏览 下单 支付 商家接单 骑手配送中 已送达 用户评价 结算
外卖业务稳定性的挑战
业务特点：发展快 技术挑战：开发迭代快
发版频繁
Task
依赖稳定性原则
只依赖稳定的服务 将易变的部分拆分 超时中断
读 写
Query
Manage
保障用户体验的容错设计
异常情况下客户端的呈现 客户端配合限流 客户端配合降级
失败！ 服务器异常！ null 别看了，啥也没
抱歉，您选的商 家运力不足，请 选择其他商家 下单。
系统稳定性的处理原则
2013/11
2014/11
2015/05
2015/12
2016/05
?
目录
• • • • •
个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则
技术体系架构演进介绍
业务起步：MVP阶段
美团外卖APP 验证需求 寻找产品和需求的切合点 电话点餐->网络点餐 移动后台 WEB后台 美团外卖WEB
技术架构：1.0
快速开发功能 快速调整流程 快速发布上线 订单列表
dbwaimai
技术体系架构演进介绍
业务起步：规模化
寻找规模化的业务产品形态 提高运营效率
App
I版
用户业务系统
Web
PC
App
商家业务系统
打印机
dbwaimai master/slave
技术架构：2.0
快速开发多个业务系统 复用工具库Util：http 复用业务库
API
MTThrift
订单
MQ
Atlas DB
技术架构：3.0
系统级容错 服务化重构 中间件 分库分表
美团App
Open
商品
KV Databus
点评App 外卖商家
Web
商家
ES 异构 DB
...
性能监控
统一配置中心
MHA
技术体系架构演进介绍
问题
系统架构
耦合 相互影响 容错差
目录
• • • • •
个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则
美团外卖业务发展历程
扩展中
扩展中
外卖
配送
美团外卖业务发展历程
供给侧改革 1000w
日交易额过亿 新LOGO 400w 美团专送 全国启动 在线支付 APP占90% WEB上线 业务MVP 200w 100w 300w
将流程自动化进行到底。
1
2
3
4 影响预估
对下游的影响评估
5 回滚措施
回滚的版本号
基本信息
发布内容 发布者 发布时间
发布前验证
关键业务流程测试 新功能测试 SQL Review 代码Review
发布步骤
多系统协同步骤
对上游的影响评估
自身负载变化评估
回滚步骤
6 灰度策略
按城市 按功能 按百分比
7
8
发布后验证
合同
运营业务系统 审核 上单 MQ
公共服务系统 订单
商家
技术体系架构演进介绍
业务增长
校园市场全国开展 白领市场开拓 美团专送启动 平台活动增加 用户激增 订单激增
用户层 接口层 Native H5 外卖App
应用层 服务层 基础层 中间件
数据层 访问层 存储层
Nginx 灰度
多逻辑耦合 直连DB Redis 主从 RabbitMQ 外卖大集群 DB join like
服务化SOA MTThrift Redis Cluster 订单集群 其他集群 DB 异构索 引表
服务级容灾
Cache
共用KV 延迟队列 重试队列
专用KV
MQ
高级查询
演进之路
服务化 中间件 KV 数据总线 异步化
项目开发
分支管理 代码交叉 Review 代码静态检查 代码规范 日志规范 引入第三方工 具、JAR包SOP 依赖外部服务 SOP 数据库迁移/ 拆分SOP
测试
发ቤተ መጻሕፍቲ ባይዱ上线
监控报警
故障处理
• • • • •
测试环境使用 规范 RD完成冒烟测 试 回归关键路径 及主要版本 项目提测流程 规范 线上压测流程
美团外卖系统 架构演进与系统稳定性经验谈
目录
• • • • •
个人简介 美团外卖业务发展历程 技术体系架构演进介绍 外卖业务稳定性的挑战 系统稳定性的处理原则
个人简介
北纬通信
移动增值服务
新美大
创新业务探索 美团外卖架构组
2006.7~2011.2
2011.3~2013.5
2013.5~
网易
网易视频库 网易应用 网易新闻
日志,报错数 性能指标 关键流程回归
9 发布总结
可以改进的点 casestudy
10 完成
效果分析
降级方案
降级方案1 降级方案2 。。。
新功能测试
系统稳定性的处理原则
总结
灰度！灰度！灰度！
发版窗口，晚高峰前发。.
慢查询往往闯大祸。
no join，SQL Review，慢查询巡检。
防御式编程，不要相信任何人和服务。
业务监控
KV
log
flume 下单，各种信息，ip
业务大盘 脚印系统
MQ log flume
支付 推送
健康分析
指标变化趋势
系统稳定性的处理原则
事故处理 及时止损
回滚！ 分流 启动降级预案 限流
APP 客户端启动限流
流控API：jar 接收请求
保护用户体验
客户端配合降级
压测目标
排查性能瓶颈，上探系统容量，验证降级机制 验证报警响应机制 & 指导设定警戒行动线
系统稳定性的处理原则
事前预警
性能大盘
CPU Idle DB读、写QPS TP90 响应时间 超时率
log API flume
Service
log
flume Kafka storm HBase
离线任务
Databus Elasticsearch 分布式调度 Horae 一主多从 Atlas 降级