美团外卖演化之路

美团外卖演化之路

看了下这个，做好一个大流量的系统真是不容易。学到了很多东西，希望有机会能够参与大流量系统的架构。

设计之初

外卖app,外卖web
移动后台，web后台
DB
订单列表<---电话预订

目标：快速开发，快速调整流程，快速发布上线

信息爆炸化后，走上模块化之后~~

信息爆炸化时的系统

用户业务系统：app i版 web
商家业务系统：pc app 打印机
db(master/slave)
运营业务系统：合同，审核，上单
公共服务器系统：MQ,订单，商家

目标：快速开发多个业务系统，复用工具，复用业务库

模块化的调整的两点：

1 拆，服务化拆分，服务保护自己的数据
2 中间件。kv系统，es搜索系统，  

模块化后的系统（应用级容错-到-机房级容错）

用户层：native h5 外卖app 美团app 点评app 外卖商家
基础服务层：
    性能监控，统一配置中心，MHA
应用层：
    接口层: api,open,web
    服务层: mtthrift,订单，商品，商家 等等
    基础层: MQ,KV,ES
数据层：
    访问层：Atlas
    存储层：DB --databus-》异构DB

目标：系统级容错，服务化重构，中间件，分库分表

挑战：

1 业务场景集中，每天有高峰
2 服务之间的错综复杂的调用情况
3 迭代太快，架构优化工作可能排不上去

系统可用性和订单的可用性：

1 49的指标，全年52分钟，一季度宕机时间不超过13分钟
2 订单可用性 49，按亿年算，每个季度不能损失2w单

完成系统可用性和订单可用性的方案：

1 日常运行
2 事前预警
3 事故处理
4 事后总结

日常运行

日常运行的原则：

    1 大系统小做。
        服务专一
        业务的拆分
    2 依赖稳定性原则。
        只依赖稳定的服务
        将不稳定的拆分
        超时中断
    3 设计稳定性的时候也要考虑用户体验
        异常情况下客户端的呈现
        客户端配合限流
        客户端配合降级

    4 例行的稳定性巡检
        静态梳理
            按照业务场景review
            关键链路调用放大情况梳理
            降低高并发，假并发场景
        专项梳理
            DB健康review，大表，慢查询
            读写qps，出轨，绿帽子
            降级方案演练
        指标巡检
            性能大盘：不要放过尖刺
            业务大盘：定心丸
            报错大盘：定位好帮手

    在线压测
        了解系统的薄弱部分，知道系统的上限和能力
        验证监控和报警机制是否生效
        可以设置合适的监控压测指标

    5 稳定性的处理原则
        线上引流压测
            nginx分组
            thriftRPC分组
            摘掉机器
        全链路压测
            读流量回放
            写事务模拟
            流量染色
            异步阶梯加压
            告警自动终止

        压测目标
            检测性能瓶颈，上探系统容量，验证降级机制
            验证报警响应机制&知道设定警戒行动线

事前预警

log-->flume->kafka->storm->HBase->(下单[各种信息]_-支付-推送)

性能大盘
    cpu idle
    db读写qps
    tp90响应时间
    超时率

业务监控
    业务大盘
    脚印系统

健康分析
    指标变化趋势  

事故处理

1 第一原则及时止损

限流方案：
    1 放刷量-防止用户频繁刷新后台导致流量放大
    2 等待+限时的服务
    3 单机的qps保护

事务总结

1 目标是追踪到根本原因
2 核算损失
3 处理过程和中间流程进行总结，看看哪些地方可以优化
4 力保关键路径不挂，比如保证下单的每个环节都可以降级

性能是功能的一部分，稳定性也是功能的一部分。

标准操作流程sop

    需求，开发，测试，上线，监控，故障处理

SOP详解

    需求管理：
        task追踪，大功能设计review，重大技术方案变更review
        上下游依赖变化review
    项目管理
        分支管理，代码交叉review，代码静态检查，代码规范，日志规范，引入第三方工具，JAR包sop，依赖外部服务SOP,数据库迁移拆分SOP
    测试
        测试环境使用规范
        RD完成冒烟测试
        回归关键路径及主要版本
        项目提测流程规范
        线上压测流程
    发布上线
        新业务上线SOP
        线上发布sop
        线上灰度sop
        数据库线上操作sop
        线上容量调整sop
        验证业务效果
    监控报警
        业务指标监控
        系统监控dashboard
    故障处理
        第一时间向上级反馈
        及时周知业务方：问题，影响范围，解决方案，预计恢复时间
        线上服务降级sop

系统稳定性的处理原则-流程自动化

基本信息
    发布人，内容，时间
发布前验证
    关键业务流程的测试
    新功能测试
    sql review
    代码review
发布步骤
    多系统协同步骤
影响预估
    对下游的影响
    对上游的影响
    自身负载变化评估
回滚措施
    回滚版本号
    回滚步骤
灰度策略
    按城市
    按功能
    按百分比
降级方案
    降级方案1
    降级方案2
发布后验证
    日志报错数
    性能指标
    关键流程回归
    新功能测试
发布总结
    可以改进的点
    case study
完成
    效果分析

系统稳定性的处理原则-流程自动化可能出现的问题

1 一定要灰度，灰度，灰度
2 注意慢查询，
3 防御式编程
4 soap保平安
5 你担心的事情很有可能发送  

转载自美团外卖架构演化