2. 服务可用性定义:可用性指标(SLA/SLO/SLI)、常见的故障模式、可用性计算模型
在微服务架构中,服务可用性并非一个模糊的“系统是否运行”的概念,而是一套可量化、可追踪、可问责的指标体系。本章将深入剖析可用性的核心定义,从指标框架、故障分类到数学计算模型,为后续的健康检查与自愈策略奠定理论基础。
2.1 可用性指标框架:SLI / SLO / SLA
业界通用的可用性管理模型由三个层次构成:SLI(服务等级指标)、SLO(服务等级目标)和SLA(服务等级协议)。三者之间的关系如同“测量 → 目标 → 契约”的递进链条。
| 术语 | 定义 | 示例 | 责任方 |
|---|---|---|---|
| SLI | 服务实际表现的可量化度量指标 | 请求成功率 99.95%、P99 延迟 200ms | 技术团队定义并采集 |
| SLO | 团队承诺达到的 SLI 目标阈值 | 月度请求成功率 ≥ 99.99% | 技术团队内部承诺 |
| SLA | 对外承诺的可用性协议,含违约赔偿 | 月度可用性 ≥ 99.9%,否则退还 10% 费用 | 业务/法务 + 客户 |
关键原则:SLO 应比 SLA 更严格(例如 SLA 为 99.9%,SLO 设为 99.95%),为故障响应留出缓冲空间,避免直接触发违约赔偿。
2.2 常见的故障模式
微服务架构中,故障不再局限于单机宕机,而是呈现出多样化的“部分失效”特征。理解故障模式是制定健康检查策略的前提。
| 故障模式 | 典型表现 | 影响范围 | 健康检查检测难度 |
|---|---|---|---|
| 进程崩溃 | 进程退出,端口无响应 | 单实例 | 低(TCP 探测即可) |
| 死锁/活锁 | 进程存活但无法处理请求 | 单实例 | 中(需应用层探测) |
| 资源耗尽 | 内存泄漏、连接池满、磁盘满 | 单实例 → 级联 | 中(需指标阈值告警) |
| 依赖服务故障 | 数据库超时、下游 gRPC 调用失败 | 级联扩散 | 高(需分布式追踪) |
| 网络分区 | 节点间延迟剧增、丢包 | 集群局部 | 高(需心跳 + 多数派) |
| 配置错误 | 路由规则错误、限流阈值过低 | 全局 | 极高(需配置审计) |
避坑提示:仅依赖进程级健康检查(如 TCP 端口探测)无法发现死锁、资源耗尽和依赖故障。生产环境必须采用多层健康检查策略:Liveness(存活)+ Readiness(就绪)+ 依赖探测。
2.3 可用性计算模型
可用性的经典计算公式为:
可用性(A)= 正常运行时间 /(正常运行时间 + 故障时间)× 100%
在微服务场景下,我们通常使用请求成功率作为更精确的 SLI:
请求成功率 = 成功请求数 / 总请求数 × 100%
以下是常见可用性等级对应的年度/月度不可用时间:
| 可用性等级 | 年度不可用时间 | 月度不可用时间 | 典型场景 |
|---|---|---|---|
| 99% (两个9) | 87.6 小时 | 7.3 小时 | 内部开发环境 |
| 99.9% (三个9) | 8.76 小时 | 43.8 分钟 | 一般商业应用 |
| 99.99% (四个9) | 52.56 分钟 | 4.38 分钟 | 金融核心交易 |
| 99.999% (五个9) | 5.26 分钟 | 25.9 秒 | 电信/基础设施 |
2.4 复合服务的可用性计算
在微服务架构中,一个请求通常经过多个服务串联处理。整体可用性遵循串联模型:
A_total = A_1 × A_2 × A_3 × ... × A_n
例如,一个请求经过 4 个服务,每个服务可用性为 99.9%(三个9):
A_total = 0.999^4 ≈ 0.996 = 99.6%
这意味着整体可用性从三个9降到了两个9。为了达到整体三个9,每个服务的可用性必须更高,或者引入冗余/降级策略。
实战启示:在 gRPC 健康检查设计中,必须为每个依赖服务配置独立的健康检查端点,并在客户端实现熔断和降级逻辑,避免单点故障拖垮整条调用链。
2.5 可用性目标设定建议
- 核心链路服务(如用户鉴权、支付):SLO 设定为 99.99%,采用多副本 + 自动故障转移。
- 基础中间件(如配置中心、服务发现):SLO 设定为 99.999%,需跨可用区部署。
- 非关键服务(如日志聚合、报表):SLO 设定为 99.9%,允许计划内停机维护。
- 错误预算:将 SLO 转化为可消耗的“错误预算”,例如月度 99.99% 可用性对应 4.38 分钟不可用时间,团队在此预算内进行发布和变更。