面向失败设计（32页）——高可用架构专场.pdf

《面向失败设计（32页）——高可用架构专场.pdf》由会员分享，可在线阅读，更多相关《面向失败设计（32页）——高可用架构专场.pdf（32页珍藏版）》请在三个皮匠报告上搜索。

1、面向失败设计张军（游骥）阿里云智能资深技术专家引言面向失败设计01Everything Fails,All the Time无论是在传统软件时代还是在互联网、云时代，系统终究会在某个时间点失败无所不在的失败场景硬件问题软件BUG配置变更错误系统恶化超预期流量外部攻击依赖库问题依赖服务问题02容灾面向失败设计容灾服务能力与依赖调用自我保护为一切不可预料的情况备好预案自动化运维精细化的监控体系故障与攻防演练锤炼容灾应急能力容灾通过冗余设计来规避局部失败对系统的影响容灾-航空是如何保障飞行安全的冗余设计冗余设计面向失败设计为了万分之一的紧急情况出现的可能，每年要进行多次的模拟机训练或者实景演练一架飞

2、机上都会配备至少两名飞行员，二者相互合作的同时相互监督每一个航段前，光是一个绕机检查，可能就有几十个项目需要检查绕机检查是由地面机务人员和飞行机组分别完成，同样也是为了更仔细的检查，降低错误率每架飞机还有短期全面检查和长期全面检查飞机上的每一个设备都是独立的双系统在工作气象雷达可以让飞行员感知到几十甚至几百海里范围内的天气情况飞机防撞系统可以让飞行导航显示仪上显示正在接近的可能存在威胁的飞机盲降系统是由地面发射的两束无线电信号实现航向道和下滑道指引，飞机通过机载接收设备，进行降落人机环境容灾的核心思想基于隔离的冗余容灾评价指标RPO（Recovery Point Objective）即数据恢复

3、点目标，以时间为单位，即在灾难发生时，系统和数据必须恢复的时间点要求。RTO（Recovery Time Objective）即恢复时间目标，以时间为单位，即在灾难发生后，信息系统或业务功能从停止到必须恢复的时间要求。RTO标志系统能够容忍的服务停止的最长时间。系统服务的紧迫性要求越高，RTO的值越小。分析阶段业务影响分析风险分析可恢复性评估设计阶段实施阶段面向业务面向技术容灾领域沉淀方法论灾难恢复预案设计容灾演练和维护容灾方案设计制定恢复策略按用户分流阿里巴巴容灾架构演进容灾发展历程交易单元化启动2013交易单元化走出杭州2014交易异地多活千里之外2015单元化配套一键建站2016全网容灾

4、体系搭建2017异地多活商业化20182012交易同城双活同城双活架构异地多活架构CDN按用户分流接入层应用中间件，缓存数据库IDC-1单元一接入层应用中间件，缓存数据库IDC-3单元三接入层应用中间件，缓存数据库IDC-2单元二数据同步同步调用异步消息强中心依赖Copy类型中心域名解析ADNSKeyCenter统一接入层APP 2DiamondNotifyHbaseMDB/LDBMetaQDB(主)VIPVipServerDiamond-clientAPP 1HSFHbaseRPC tair-clientIDC 1AsyncConfigServerTDDlAsyncKeyCenter统一接入

5、层APP 2DiamondNotifyHbaseMDB/LDBMetaQDB(备)VIPVipServerDiamond-clientAPP 1HSFTair-client HbaseRPCIDC 2AsyncConfigServerTDDlAsyncAsyncAsyncTDDLDRCJingweiIBack按用户分流同步调用异步消息容灾1.020002015now1980容灾2.0容灾3.0IT作为业务支撑系统容灾以数据为中心恢复以人工为主容灾系统做为备用系统IT作为业务使能容灾以业务为中心双活、AQ模式使得容灾系统支撑部分业务容灾及业务容灾以客户为中心智能流量分配多中心部署容灾系统即业务系

6、统冷备两地三中心异地多活同城双活基于隔离的冗余容灾发展历程服务能力与依赖调用自我保护03容灾服务能力与依赖调用自我保护为一切不可预料的情况备好预案自动化运维精细化的监控体系故障与攻防演练锤炼容灾应急能力CacheMessage3rdParty ApplicationDatabase服务内部业务链路入口服务与依赖客户端GatewayFirewallWeb ServersLoad BalancerServicesNetwork 链路入口流控 热点漏斗 按照服务水位流控 消峰填谷 匀速器 慢SQL发现熔断 慢方法熔断 热点探测 流量实时监控 水位诊断分析对应不同组件的防护和熔断典型场景流量控制 应对