面向失败的系统容灾架构设计
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
D RC Jing w e i IBack
MetaQ
MDB/LDB
Hbase
交易异地多活 千里之外
2015
单元化配套 一键建站
2016
全网容灾 体系搭建
2017
异地多活 商业化
2018
▌异地多活架构
按用户分流
ID C -1
单元一
接入层
应用
中间件，缓存
数据库
同步调用 异步消息
CDN
按用户分流
IDC-2
服务与依赖
• 慢S Q L发现熔断 • 慢方法熔断 • 热点探测
典型场景
流量控制
• 应对洪峰流量: 秒杀，大促，下 单，订单回流处理
• 消息型场景: 削峰填谷，冷热启动 • 付费系统:根据使用流量付费
熔断降级
• 适用于任何结构复杂的应用。当系 统内部或者外部出现不稳定因素， 迅速降级不稳定因素，让应用保持 稳定
单元二
接入层
应用
中间件，缓存 数据库
同步调用 异步消息
数据同步
按用户分流
IDC-3
单元三
接入层 应用
中间件，缓存 数据库
强中心依赖
中
C o p y类型
心
容灾发展历程
1980
2000
2015
容灾1.0
容灾2.0
‣ IT作为业务支撑系统 ‣ 容灾以数据为中心 ‣ 恢复以人工为主 ‣ 容灾系统做为备用系统
基于隔离的冗余
‣ IT作为业务使能 ‣ 容灾以业务为中心 ‣ 双活、A Q 模式使得容灾系统支
撑部分业务
冷备
两地三中心
同城双活
异地多活
容灾3.0
‣ 容灾及业务 ‣ 容灾以客户为中心 ‣ 智能流量分配 ‣ 多中心部署 ‣ 容灾系统即业务系统
now
服务能力与依赖 调用自我保护
03
容灾 服务能力与依赖调用自我保护 为一切不可预料的情况备好预案 自动化运维 精细化的监控体系 故障与攻防演练锤炼容灾应急能力
IDC 1
域名解析
ADNS VIP
KeyC e n ter
APP 1
Diamond-client
Diamond
H b a seRP C tair-client
统一接入层
VipServer
HSF
APP 2
ConfigServer Async
TDDl
Notify
Async
TDDL
VIP
IDC 2
统一接入层
系统保护
• 根据R T动态调节入口流量
刷单流量
正常流量
正常流量
刷单流量
正常流量
刷单流量
正常流量
热点防控
• 自动识别热点。应用于刷单（例如 来自单个ip，单个用户，单个商品 的请求）
为一切不可预料 的情况备好预案
04
容灾 服务能力与依赖调用自我保护 为一切不可预料的情况备好预案 自动化运维 精细化的监控体系 故障与攻防演练锤炼容灾应急能力
容灾
面向失败设计
02
容灾 服务能力与依赖调用自我保护 为一切不可预料的情况备好预案 自动化运维 精细化的监控体系 故障与攻防演练锤炼容灾应急能力
容灾
通过冗余设计来规避局部失败对系统的影响
容灾-航空是如何保障飞行安全的
人
‣ 为了万分之一的紧急情况出现的可能，每年要进行多次的模拟机训练或者实景演练 ‣ 一架飞机上都会配备至少两名飞行员，二者相互合作的同时相互监督
面向失败的系统容灾架构设计
技术创新，变革未来
引言
面向失败设计
01
Everything Fails, All the Time
无论是在传统软件时代还是在互联网、云时代，系统终究会在某个时间点失败
无所不在的失败场景
硬件问题 软件B U G 配置变更错误 系统恶化
超预期流量 外部攻击 依赖库问题 依赖服务问题
机
‣ 每一个航段前，光是一个绕机检查，可能就有几十个项目需要检查 ‣ 绕机检查是由地面机务人员和飞行机组分别完成，同样也是为了更仔细的检查，降低错误率 ‣ 每架飞机还有短期全面检查和长期全面检查 ‣ 飞机上的每一个设备都是独立的双系统在工作
环境
‣ 气象雷达可以让飞行员感知到几十甚至几百海里范围内的天气情况 ‣ 飞机防撞系统可以让飞行导航显示仪上显示正在接近的可能存在威胁的飞机 ‣ 盲降系统是由地面发射的两束无线电信号实现航向道和下滑道指引，飞机通过机载接收设备，进行降落
对应不同组件的防护和熔断
Network
Firewall
Gateway
Load Balancer
客户端
• 流量实时监控 • 水位诊断分析
Βιβλιοθήκη Baidu业务链路入口
• 链路入口流控 • 热点漏斗
Web Servers
Services
服务内部
• 按照服务水位流控 • 消峰填谷 • 匀速器
3rd Party Application Database Message Cache
VipServer
KeyCenter
APP 2
HSF
APP 1
Diamond-client
Async ConfigServer
Diamond
TDDl
Async Tair-client H b a s eRPC
Async
N otify Async
Hbase
MDB/LDB
MetaQ
D B ( 主)
D B ( 备)
为一切不可预料的情况备好预案
业务预案
去除单点
预发布
冗余数据
灰度发布
双机预热
依赖变化识别
分批发布
应用拆分
主备双备
容量评估
发布
强弱依赖
跨地域方案
上线前
回滚预案
设计阶段
限流预案
隔离预案
切流预案
降级预案
切库预案
熔断预案
弹性伸缩 巡检
开关预案 硬件容灾
问题报警 流量调度
线上 故障预案 回滚预案
数据对账 监控
要求越高， R T O 的值越小。
容灾领域沉淀–方法论
分析阶段
业务影响分析 风险分析
可恢复性评估
设计阶段
容灾方案设计 制定恢复策略
面向业务 面向技术
实施阶段
灾难恢复预案设计 容灾演练和维护
容灾架构演进
▌容灾发展历程
交易同城双活
交易单元化 启动
2012
2013
交易单元化 走出杭州
2014
▌同城双活架构
资损预案
会发生哪些失败？ 失败会带来什么问题？ 应对策略是什么？ 预期的恢复时间多久？ 恢复后的影响面有多大？ 需要通知到哪些角色？
预案生命周期
1.事前-预案制定及相关准备
• 对业务进行分析，来指定紧急事件处理及应对流程 • 确定预案覆盖的紧急复杂程度以及影响范围 • 识别关键措施以及人员 • 变更历史维护追踪
冗余设计 冗余设计 面向失败设计
容灾的核心思想
冗余 基于 隔离 的
容灾评价指标
RPO （Recovery Point Objective）
即数据恢复点目标，以时间为单位，即在灾难发生 时，系统和数据必须恢复的时间点要求。
RTO （Recovery Time Objective）
即恢复时间目标，以时间为单位，即在灾难发生后，信息 系统或业务功能从停止到必须恢复的时间要求。R T O 标志 系统能够容忍的服务停止的最长时间。系统服务的紧迫性
MetaQ
MDB/LDB
Hbase
交易异地多活 千里之外
2015
单元化配套 一键建站
2016
全网容灾 体系搭建
2017
异地多活 商业化
2018
▌异地多活架构
按用户分流
ID C -1
单元一
接入层
应用
中间件，缓存
数据库
同步调用 异步消息
CDN
按用户分流
IDC-2
服务与依赖
• 慢S Q L发现熔断 • 慢方法熔断 • 热点探测
典型场景
流量控制
• 应对洪峰流量: 秒杀，大促，下 单，订单回流处理
• 消息型场景: 削峰填谷，冷热启动 • 付费系统:根据使用流量付费
熔断降级
• 适用于任何结构复杂的应用。当系 统内部或者外部出现不稳定因素， 迅速降级不稳定因素，让应用保持 稳定
单元二
接入层
应用
中间件，缓存 数据库
同步调用 异步消息
数据同步
按用户分流
IDC-3
单元三
接入层 应用
中间件，缓存 数据库
强中心依赖
中
C o p y类型
心
容灾发展历程
1980
2000
2015
容灾1.0
容灾2.0
‣ IT作为业务支撑系统 ‣ 容灾以数据为中心 ‣ 恢复以人工为主 ‣ 容灾系统做为备用系统
基于隔离的冗余
‣ IT作为业务使能 ‣ 容灾以业务为中心 ‣ 双活、A Q 模式使得容灾系统支
撑部分业务
冷备
两地三中心
同城双活
异地多活
容灾3.0
‣ 容灾及业务 ‣ 容灾以客户为中心 ‣ 智能流量分配 ‣ 多中心部署 ‣ 容灾系统即业务系统
now
服务能力与依赖 调用自我保护
03
容灾 服务能力与依赖调用自我保护 为一切不可预料的情况备好预案 自动化运维 精细化的监控体系 故障与攻防演练锤炼容灾应急能力
IDC 1
域名解析
ADNS VIP
KeyC e n ter
APP 1
Diamond-client
Diamond
H b a seRP C tair-client
统一接入层
VipServer
HSF
APP 2
ConfigServer Async
TDDl
Notify
Async
TDDL
VIP
IDC 2
统一接入层
系统保护
• 根据R T动态调节入口流量
刷单流量
正常流量
正常流量
刷单流量
正常流量
刷单流量
正常流量
热点防控
• 自动识别热点。应用于刷单（例如 来自单个ip，单个用户，单个商品 的请求）
为一切不可预料 的情况备好预案
04
容灾 服务能力与依赖调用自我保护 为一切不可预料的情况备好预案 自动化运维 精细化的监控体系 故障与攻防演练锤炼容灾应急能力
容灾
面向失败设计
02
容灾 服务能力与依赖调用自我保护 为一切不可预料的情况备好预案 自动化运维 精细化的监控体系 故障与攻防演练锤炼容灾应急能力
容灾
通过冗余设计来规避局部失败对系统的影响
容灾-航空是如何保障飞行安全的
人
‣ 为了万分之一的紧急情况出现的可能，每年要进行多次的模拟机训练或者实景演练 ‣ 一架飞机上都会配备至少两名飞行员，二者相互合作的同时相互监督
面向失败的系统容灾架构设计
技术创新，变革未来
引言
面向失败设计
01
Everything Fails, All the Time
无论是在传统软件时代还是在互联网、云时代，系统终究会在某个时间点失败
无所不在的失败场景
硬件问题 软件B U G 配置变更错误 系统恶化
超预期流量 外部攻击 依赖库问题 依赖服务问题
机
‣ 每一个航段前，光是一个绕机检查，可能就有几十个项目需要检查 ‣ 绕机检查是由地面机务人员和飞行机组分别完成，同样也是为了更仔细的检查，降低错误率 ‣ 每架飞机还有短期全面检查和长期全面检查 ‣ 飞机上的每一个设备都是独立的双系统在工作
环境
‣ 气象雷达可以让飞行员感知到几十甚至几百海里范围内的天气情况 ‣ 飞机防撞系统可以让飞行导航显示仪上显示正在接近的可能存在威胁的飞机 ‣ 盲降系统是由地面发射的两束无线电信号实现航向道和下滑道指引，飞机通过机载接收设备，进行降落
对应不同组件的防护和熔断
Network
Firewall
Gateway
Load Balancer
客户端
• 流量实时监控 • 水位诊断分析
Βιβλιοθήκη Baidu业务链路入口
• 链路入口流控 • 热点漏斗
Web Servers
Services
服务内部
• 按照服务水位流控 • 消峰填谷 • 匀速器
3rd Party Application Database Message Cache
VipServer
KeyCenter
APP 2
HSF
APP 1
Diamond-client
Async ConfigServer
Diamond
TDDl
Async Tair-client H b a s eRPC
Async
N otify Async
Hbase
MDB/LDB
MetaQ
D B ( 主)
D B ( 备)
为一切不可预料的情况备好预案
业务预案
去除单点
预发布
冗余数据
灰度发布
双机预热
依赖变化识别
分批发布
应用拆分
主备双备
容量评估
发布
强弱依赖
跨地域方案
上线前
回滚预案
设计阶段
限流预案
隔离预案
切流预案
降级预案
切库预案
熔断预案
弹性伸缩 巡检
开关预案 硬件容灾
问题报警 流量调度
线上 故障预案 回滚预案
数据对账 监控
要求越高， R T O 的值越小。
容灾领域沉淀–方法论
分析阶段
业务影响分析 风险分析
可恢复性评估
设计阶段
容灾方案设计 制定恢复策略
面向业务 面向技术
实施阶段
灾难恢复预案设计 容灾演练和维护
容灾架构演进
▌容灾发展历程
交易同城双活
交易单元化 启动
2012
2013
交易单元化 走出杭州
2014
▌同城双活架构
资损预案
会发生哪些失败？ 失败会带来什么问题？ 应对策略是什么？ 预期的恢复时间多久？ 恢复后的影响面有多大？ 需要通知到哪些角色？
预案生命周期
1.事前-预案制定及相关准备
• 对业务进行分析，来指定紧急事件处理及应对流程 • 确定预案覆盖的紧急复杂程度以及影响范围 • 识别关键措施以及人员 • 变更历史维护追踪
冗余设计 冗余设计 面向失败设计
容灾的核心思想
冗余 基于 隔离 的
容灾评价指标
RPO （Recovery Point Objective）
即数据恢复点目标，以时间为单位，即在灾难发生 时，系统和数据必须恢复的时间点要求。
RTO （Recovery Time Objective）
即恢复时间目标，以时间为单位，即在灾难发生后，信息 系统或业务功能从停止到必须恢复的时间要求。R T O 标志 系统能够容忍的服务停止的最长时间。系统服务的紧迫性