如何使服务具备高可用性

上次介绍了《如何搭建高可用Web集群》,有不少同学反馈让我继续发些高可用相关的内容。本文将继续高可用系列内容,介绍一下SRE和架构师角度对『实现高可用性』的理解。

一、概述

可用性案例

在开始之前,先给大家看下可用性的badcase案例:

可用性问题后果

  • 用户损失

–用户体验伤害

–经济损失

  • 公司损失

–经济损失

–客户信任

–技术形象

本文探讨范围

  • 以请求访问型的用户产品为示例

–用户产品

–平台化产品

–内部系统

  • 目录

–高可用性定义

–如何度量

–影响要素分析

–如何保障

 

二、高可用性定义

可用性等级(Availability)定义

Availability = Uptime / (Uptime + Downtime)

通常情况下,Availability达到99.99%或99.999%即可称为服务具备高可用性。

从用户角度出发

  • 对于提供的服务,用户能够获得符合质量预期的服务比例
  • 不可用

–不可访问

–DNS解析失败、链接失败

–服务不存在,或被封禁

–服务内部错误

–低质

–慢,页面错乱、核心元素缺失

相关名词

  • SLA

–服务可用性等级,常说的几个九

  • MTTR

–平均故障恢复时间,即从故障发现到止损点的时间差

  • MTBF

–平均故障间隔时间,即从上一次故障到本次故障的间隔时间,常用于硬件产品

 

三、如何度量

困难

  • 部分Down

–部分功能:子系统、页面、元素等

–部分用户

–间歇性:时间难以衡量

  • 一个指标

–不同功能、用户是否一视同仁?

–浏览 vs 购买 vs 优惠卷

  • 服务端指标 到 用户端 的“漫漫长路”

–服务端指标 vs 用户实际感受指标

–难以全面采集(端支持)

计算方法

  • 时间 => 请求计数

–有效处理的请求次数 / 总合法的请求次数

  • 用户指标 << 服务指标 << 模块指标 << 详细指标

–用户指标反映用户实际感受质量

–服务指标反映服务综合质量

–细分加权求和

–分功能指标反应模块服务质量

–详细指标有助于发现和定位问题

  • SLA

–服务可用性等级,常说的几个九

–计算公式:1 –(失败次数 + 超时次数)/ 总请求次数

  • MTTR

–平均故障恢复时间,即从故障发现到止损点的时间差

–计算公式:(故障恢复时间点 – 故障发生时间点) / 故障次数 * 模块重要性权重 * 模块流量权重

  • MTBF

–平均故障间隔时间,即从上一次故障到本次故障的间隔时间,常用于硬件产品

–计算公式:(服务总可用时间-服务总故障时间) / 总故障次数

相关度量

  • 关联其他指标

–服务容量

–流量:QPS

–性能:平响

–收入

  • 关注变化

–变更

  • 设置预警

–报警策略

 

四、影响要素分析

故障分布

下图是一个常见的服务故障分布情况:

故障时间

  • 计划中的” Downtime”

–非兼容性升级

–数据一致性处理

–故障演练

  • 故障(Failure)导致的” Downtime”

故障位置

  • 硬件故障

–机器(含机器的各组成部分,如磁盘)

–IDC设施:交换机、链路、空调、电力等

–外部设施:运营商网络

  • 软件缺陷

–代码BUG

–异常应对能力

故障触发

  • 外部操作变更

–硬件及系统、网络

–软件:程序、配置、数据

  • 外部流量因素引发的软件故障

–漏洞请求引发:特殊请求导致系统变慢、崩溃

–请求量、频次及构成引发:超出容量

 

五、如何保障

原则

  • 减少发生

–降低故障出现频次

  • 降低影响

–一旦发生,确保尽可能小的影响面

  • 加快恢复

–能够快速发现、定位、修复

方法

变更控制

  • 架构环节

–Design for Failures

–单机故障

–机房/区域故障

–流量异常

–自身异常

–下游异常

–清晰的服务部署

–避免单点

–消除跨逻辑机房的交互

–合理的容量评估

–模块承担容量限额

–Cache崩溃对流量的影响

–第三方容量

–安全设计

  • 编码环节

–严谨的编码,主动容错

–主动容错:函数执行失败、RPC调用失败、经过推敲的错误处理(任何一个函数、外部输入)

–超时控制

–使用NS名字服务

–重试的考虑:链路连锁反应,重试雪崩(容量计算/重试位置)

–模块隔离:高内聚、低耦合

–代码性能、安全性、可测性

–全分支覆盖自测;CodeReview

  • 测试环节

–功能/性能/稳定性/兼容性/安全性测试

–交付确定性

  • 上线环节

分级发布、回归测试

快速回滚

重视数据变更的风险

服务容量管理

  • 服务冗余

–实例N+2

–支持熔灾 + 发布时摘流量

  • 容量评估

–合理评估

–适当降低冗余

  • 容量压测

–建立例行压测机制,定期获取系统容量瓶颈

–容量管理:根据流量合理部署实例,实现实例分配最优化

入口流量调度

  • 能力

–流量的接入与调度能力

–粒度 && 速度

–限流:屏蔽与限制能力

–上下游的流量分配协调

–服务流量IDC调度 >> DB IDC流量激增

  • 场景

–机房规模的故障

–接入故障、骨干网故障

–攻击

服务降级

  • 先分级

–功能分级,开关

–区分核心功能

–流量分级,调度

–区分流量的相互影响

–区分流量的价值

  • 分级场景

–服务过载:超出处理能力

–全局流量增加

–部分用户流量增加

–容量降低

–服务的子组件整体故障

–依赖的第三方服务整体崩溃

  • 再降级

–功能降级

–丢弃非核心功能

–质量降级(减少计算)

–降低服务质量

–流量降级

–丢弃非核心流量

–配额

  • 降级实例

–微信红包,异步延迟对账事物

–地图,基础地图功能,优先于动态路况

快速回滚

  • 做好灾难恢复

–可恢复性

–备份的有效性

–恢复速度

  • PaaS化

–故障自动发现,NS自动摘除

–分级发布

–一键回滚

  • 自运维规范化

–备份与回滚

预案与演练

  • 预案

–把预案内容转换为系统的设计和实现

–优先从系统设计和实现角度保证可用性

  • 定期演练

–制造真实故障

监控报警

  • 有效的指标

–整体及细分可用性

–核心业务指标

–程序指标

–依赖指标

  • 回答如下问题

–会发生问题吗?

–发生问题了吗?

–哪里发生了问题?

–发生了什么问题?

–会自动恢复吗?

其他事项—可用性CheckList

  • 感知

–服务关键指标

–关键依赖指标

  • 隔离

–逻辑服务单元拆分

–单点消除

–核心功能逻辑独立

–核心服务资源优先

–流量成分的细分

–线上线下隔离

–容量规划

–关联解耦

–外部依赖消除

–分级发布

–变更流程规范

  • 止损

–配置热加载

–快速回滚

–防攻击

–单机容错

–过载保护

–服务单元级流量调度

–服务降级

总结

  • 建立对变更的控制能力(减少发生)

–架构、编码、测试、上线

  • 建立对系统的控制能力(降低影响,加快恢复)

–容量管理、隔离、入口流量调度、服务降级、回滚

  • 建立故障模型(减少发生,降低影响,加快恢复)

–考虑每一种可能出现的故障,以及是否都能够自动或手动应对

  • 建立度量和监控(快速发现)

–对系统运转指标有清晰的度量和检测

 

yan 19.12.19

发表评论

电子邮件地址不会被公开。