滴滴出行 陈宜明 - 滴滴出行平台的高可用实践

顿尔阳

2017/12/18 发布于 技术 分类

ArchSummit全球架构师峰会是InfoQ中国团队推出的面向高端技术管理者、架构师的技术大会,参会者中超过50%拥有8年以上的工作经验。 ArchSummit秉承“实践第一、案例为主”的原则,展示新技术在行业应用中的最新实践,技术在企业转型中的加速作用,帮助企业技术管理者、CTO、架构师做好技术选型、技术团队组建与管理,并确立技术对于产品和业务的关键作用。

文字内容
1. 滴滴出行平台的高可用实践   陈宜明   滴滴出行-技术专家  
5. 陈宜明   滴滴出行  技术专家   来自滴滴稳定性和效率团队,负责异地多活、一键降级、 防火放火等工作。   16年加入滴滴,之前在百度工作,有多年架构开发经验。  
6. •  滴滴的出行业务架构   •  高可用方法论   •  异地多活   •  一键降级   •  防火放火  
7. 滴滴业务简介   乘客! ❶发单     ❸等待接驾     ❺上车     ❼到达     ❾支付     …   服务交互! 登录、鉴权   订单、司机   分单   计价、收银、支付   反作弊、管控、运营   …   平台! 服务交互! 交易状态流转   交易业务:  实时、多状态、长链条   司机! ❷接单     ❹接驾     ❻开始行程     ❽结束行程     …  
8. 业务架构演进   lvs   lvs   DGW   外包   nginx   DFE   DFE   司机、订单、计价   收银、运营   MQ   核心业务ap i  专快 出租 Ubera 代驾 ap i  车ap i  p i  ap i  storage   分单系统   㽟草创时代   •  2012.9滴滴打车上线   •  2013.8  1kw+用户   㽠红包大战   •  2014.3  单量300万单/天 乘客1亿  司机100万   订司计 收 运 单   机   价   银   营   storage   分单引擎   㽡专快车上线   •  2014.8  专车上线   •  2015.5  快车上线   •  2016.3  1000万单/天   storage   storage   storage   storage   storage   订司计收 运 单   机   价   银   营   登收 录 银运地 鉴 支营图 分单引 权 付 擎2.0   㽢Uber合并   •  2016.8  收购Uber中国   •  2016.10  2000万单/天   日订单量:  15年几百万  ->  目前2500w+(仅次于淘宝)  
9. 高可用面临的挑战     业务增长迅速   节假日效应明显     实时   多状态   交易型   链路长     新场景多   迭代快     流量增 长迅猛   业务复杂   高速路上 换轮子   业务调用链路   稳定性 挑战大   接口调用链条示例  
10. •  滴滴出行的业务架构   •  高可用方法论   •  异地多活   •  一键降级   •  防火放火  
11. 高可用的常见措施   不可用因素   典型case   增大MTBF   缩短MTTR   程序、数据和配置 程序出core、配置格式出错   研发质量、测试质量、变更分级、监控告警、快速回滚   bug   解耦减少变更   机器和网段级故障   宕机、边缘交换机板卡故障、 硬件冗余   光纤抖动   预警预迁移服务、切流到本机 房冗余、数据主从切换   多网段和机房级故 障   流量   核心交换机故障、链路割接、 机房掉电   大促、节假日和特殊天气、外 部攻击、上游重试雪崩   硬件冗余(包括多机房)   上游容错调度防雪崩   预警预迁移服务,切流到其他 机房   容量规划、防攻击、其他同容 量不足   容量   依赖服务   主流程服务容量不足   容量规划、容量预警   限流、切流其他冗余、降级、 熔断弱依赖、快速扩容   账单依赖的到达时间预估故障、 递归使用前述方法提高该依赖的 熔断弱依赖,或递归使用前述 分单依赖的特征服务故障   可用性   方法提高该依赖的可用性  
12. 高可用的8大抓手   抓手   典型做法   业务   平台   服务   研发质量   容错设计、cr、单测、稳定性 弱依赖化(主流程瘦身)、 评审   数据流治理、研发流程   scmpf流程平台   rpc框架、服务组 件   测试质量   线下仿真   仿真环境建设、测试流程   仿真环境解决方案、测试 支持引流、dump   框架   变更管理   按机器或流量分级发布、多 灰度发布、检查和回滚流程   部署系统、分级发布系统   服务发现、配置中 维度质量检测   心   监控告警   机器/进程/业务监控及报警   监控大盘、多级报警   监控系统、告警系统   metrics、trace   故障预案   容量规划   放火盲测   值班巡检   定位和止损的预案   全链路压测、子链路压测、 哨兵压测   弱依赖验证、预案有效性和 完备性验证   例行值班表、节假日值班   预案建设   改造支持各压测   异地多活、一键预案/降级   中间件支持切流、 限流、熔断、降级   压测平台   中间件支持压测   请求级放火、资源放火   放火盲测平台   中间件支持放火   例行值班、集中应急处理   值班平台   ——  
13. 高可用的5级演进目标—43210   智能化! ⼿手⼯工! 5! 4! 3! 2! 1! 0! x年! x+1年! 未来! ⼯工具化! 43210召回占⽐比演进! ⾃自动化! 平台化!
14. •  滴滴出行的业务架构   •  高可用方法论   •  异地多活   •  一键降级   •  防火放火  
15. 异地多活   ? ⼀一个脚本引发的“⾎血案”… 哪些服务多活?     同城还是异地?     https://bbsimg.feidee.com/data/attachment/forum/ 201508/19/155520wtajnigimiz3jqgk.jpg
16. 如何实现多活?   流量路由! 流量标记! 分层路由! 单元化! 数据同步! 中间件同步! 业务双写! 降级预案! 单活降级! 数据故障兜底!
17. 多活架构   Native  App   用户层   WebApp   短连接   接入层   长连接   业务核心ap i  订司分收 单机单银 系系系支 统   统   统   付   业务层   坐 登 标地录 …   系 图   鉴 统   权   数据库   缓存   数据层   列式特征   消息队列   … 流量路由   数据同步   Native  App   WebApp   用户层   短连接   长连接   接入层   业务核心ap i  订司分 单机单 系系系 统   统   统   坐 登 标地录 …   系 图   鉴 统   权   业务层   数据库   缓存   列式特征   消息队列   … 数据层  
18. 流量路由   Native  App   用户层   WebApp   流量如何划分?   流量标识如何传递?   路由如何决策?   单活如何访问多活?   跨城、漫游如何处理?   为什么分层切换?   Native  App   WebApp   用户层   短连接   接入层   长连接   流量路由   单元内访问、不要跨机房   短连接   长连接   接入层   业务核心ap i  订司分收 单机单银 系系系支 统   统   统   付   业务层   坐 登 标地录 …   系 图   鉴 统   权   业务核心ap i  订司分 单机单 系系系 统   统   统   坐 登 标地录 …   系 图   鉴 统   权   业务层  
19. 数据同步   一致性挑战:成功率、延迟、有序、不重     业务层的挑战:  不同系统有不同的数据特性   司机系统:短时问题可容忍,但数据修复麻烦   订单系统:强一致性要求,但修复相对简单   分单系统:短时问题可容忍   坐标流:获取最近的数据,部分丢失无影响   业务核心ap i  订司分收 单机单银 系系系支 统   统   统   付   业务层   坐 登 标地录 …   系 图   鉴 统   权   数据库   缓存   数据层   列式特征   消息队列   … 数据同步   业务核心ap i  订司分 单机单 系系系 统   统   统   坐 登 标地录 …   系 图   鉴 统   权   业务层   数据库   缓存   列式特征   消息队列   … 数据层  
20. 数据同步   系统   数据特征   分析   身份信息   静态变化小   司机 系统   是否忙碌、是否出车、座位数   关键因子     策略数据(服务分、围栏、新政) 非  关键因子   存储   一致性   系统特性   数据库、缓存   无需考虑   1、短时问题可容忍   2、db出问题修复麻烦   数据库、缓存、 中偏高   列式特征   列式特征   中偏低   起始位置等信息   订单 系统   订单状态6-7个(状态机)     静态变化小   状态错误,无法继 续   数据库、缓存   无需考虑   相对修复简单   数据库、缓存   高   1、乘客直接结束订单再次发单   2、客服通过接口强制关单   同步方案   1、数据库主从同步,写主读从   2、缓存通过proxy互写同步   1、数据库主从同步,成交主流程写主读主   2、缓存:有序不重   •  双集群校验   •  binlog反冲,最终一致   分单 司机和乘客特征   系统   坐标  司机乘客坐标信息   流   mq       短时可接受           列式特征   内存   消息队列   中偏低   低   低   特征出问题,可从数据库回捞:   1、手工,听单检测  à  收车出车   2、服务端旁路检测司机状态   获取最近产生的数据,可容忍数据 丢失   异步数据,一致性要求不高   在业务proxy层实现主从同步(类数据库)   实现容易,在业务proxy层互写   全量互同步  
21. 降级预案   多活:  切流   单活:  熔断   无状态业务   特征库数据异常:  DB 回捞   DB挂了:  主从切换   网络抖动:  短时限流 防雪崩、长时切流到主 机房   抖动+主力机房挂:超 小概率、最小系统   计价、服务分有损: 善后补偿   数据故障   DB主从延迟   有损降级   故障  
22. •  滴滴出行的业务架构   •  高可用方法论   •  异地多活   •  一键降级   •  防火放火  
23. What?   限⼤限大流⼝促口制:流时⼊量入 ! ⻚页⾯面去 掉⾮非核 ⼼心功能! 同步转 异步! 到流切正量流常切: 集群! 尽可能保住服务  
24. Why?   p  业务出问题不可避免   p  需要上线,止损慢   p  预案有冲突、容易失效   p  业务压力大,精力有限   ü  要有降级预案   ü  快速生效止损   ü  预案管理   ü  降低接入成本  
25. How?   ü  场景预案,一键快速生效   •  L1: 业务无损:  号码保护、不作弊、导流、切流   •  L2: 部分效果受损:  动调,计价(路面距离降级为直线距离)   •  L3: 核心支付效果有损:  收银熔断、乘客未支付可以发单   •  L4: 核心主流程效果受损:  发单限流、内部丢单   ü  移动+pc双端  随时触达   ü  生效率监控、灰度发布、平台双活、互斥管理  安全生效   ü  切流、限流、熔断、普通降级配置语义+中间件action实 现   ü  评分系统驱动接入和演练   高效 快速 接入   止损   有效演练  
26. Detail  
27. 切流实现   举例:   路由成环问题?         服务   实例         流量标识   目的机房     路由   算法     输入   路由   规则   降级中间件   路由表   平台动态配置   通路实时配送  
28. 限流实现         服务   实例         {caller、   callee、   method}   是否限流   令牌桶:支持突发   漏桶:强限固定的速度     令牌桶   算法     输入   限流   规则   降级中间件   限流配置   平台动态配置   通路实时配送  
29. 熔断实现         服务   实例         熔断标记   是否熔断     开关   语义   识别     输入   熔断   规则   降级中间件   熔断配置   平台端动态配置   通路实时配送  
30. •  滴滴出行的业务架构   •  高可用套路   •  异地多活   •  一键降级   •  防火放火  
31. 防火灭火放火的重要项目   降低不可用发生概率:   -  线下仿真   -  灰度发布   防火   缩短止损时间:   -  异地多活   -  一键降级   灭火   验证灭火是否有效完 备:   -  故障注入   -  压测   放火  
32. 防火-灰度发布   人群灰度?X  开关维护成本高   机器灰度?X  指标不聚焦不敏感   So  人群灰度+机器灰度     预发   idc-pre   城市   灰度   idc-small   10%   idc1-g1   40%   100%   idc1-g2   idc1-g2   上线过程   …   idc2  
33. 放火-压测   哨兵系统   -  小规模损失风险换取及时预警   -  物理隔离   -  流量大于正常集群   -  动态调控   单链路压测   -  注重子系统压测   -  隔离压测数据   -  构造上游请求   -  Mock下游结果   全链路压测   -  仿真司乘行为   -  透传压测标识   -  隔离压测数据  
34. 放火-故障注入   目标   •  预案完备性检查   •  强弱依赖验证   •  提升异常分支覆盖率   协议层   层次   •  线下环境   •  线上测试账号   •  线上单个城市   THRIFT   HTTP   故障类型   LATENCY   ERRCODE   控制中心   command   REQ  LEVEL   INTERFACE   CITY   PERCENT   FLOW  TAG   SYS  LEVEL   CPU   MEM   NET   I/O   实现    IPTABLES    NGINX  MODULE    RPC    MIDDLEWARE   故障类型   HIGH  USAGE   PACK  LOSS   SLOW  NET     CONN  REFUSE              …  
35. 高可用落地   组织结构支撑   -  公正的第三方组织(星辰花):复盘、 定级追责、Trace  进展   -  专项FT:虚线汇报、项目经理协助推动   狠抓细节   -  QA验证   -  8大抓手竞赛形式推进:如定位止损流 程图   收益   -  可用性达到99.95%   -  以前可用性不到99.9%  
36. 高可用实践小结   •  业务演进:  流量增长迅猛、业务复杂、5年内已迭代4次   •  高可用方法论:  8大抓手,终极目标43210   •  异地多活:分层单元化路由、数据同步、业务双写、降级预案   •  一键降级:  场景、预案灰度、生效、切流、限流、熔断   •  防火放火:  城市灰度发布、多样化压测、三级放火   •  特色实践:组织结构支撑、狠抓细节