高可用概述：为什么接口高可用如此重要？
各位同学好。
咱们今天聊一个特别基础、但又特别核心的话题 —— 高可用。
你可能听过这个词无数次了。但我要问一句：你真的理解它吗？
我记得刚带团队那会儿，有个新同事问我：“接口挂了重启不就行了？搞那么复杂干嘛。” 嗯，当时我就带他复盘了一个线上事故。一个第三方支付回调接口，因为单点故障挂了 12 分钟。就这 12 分钟，直接导致用户重复扣款，客服电话被打爆，业务方差点冲到运维机房拍桌子。
从那儿以后，我就认清了一件事：高可用不是锦上添花，是生存底线。
高可用，到底是什么？
说白了，高可用就是让你的服务一直在线。用户发请求，你得能正常响应。
但这句话背后，藏着一些硬指标。你想想看，用户说“系统好慢”，到底是多慢才算慢？系统“挂了”几分钟，算不算事故？
所以我们需要一些客观、量化的东西。下面这三个缩写，你肯定经常见到：
- SLI (Service Level Indicator) —— 你实际测出来的指标。
- SLO (Service Level Objective) —— 你想达成的目标。
- SLA (Service Level Agreement) —— 你对客户承诺的底线。
我个人的习惯是，把它们看作一个层层递进的关系：先看 SLI，再定 SLO，最后签 SLA。千万别跳步骤，否则很容易给自己挖坑。
三个指标，一表看懂
它们到底有什么区别？我整理了个表格，你对比着看会更清楚：
| 指标 | 定义 | 例子 | 粒度 | 后果 |
|---|---|---|---|---|
| SLI | 实际测量值 | 过去一周，接口平均响应延迟是 120ms | 细粒度，按分钟/按请求 | 没有后果，只是数据 |
| SLO | 内部目标值 | 未来一年，99.9% 的请求延迟必须低于 200ms | 中粒度，按月/按季度 | 内部复盘，改进优化 |
| SLA | 对外承诺值 | 承诺可用率 99.99%，否则赔偿用户 | 粗粒度，按年 | 经济赔偿，法律责任 |
SLA 里的「几个 9」到底怎么算？
我们常说的“三个 9”、“四个 9”，算的是全年允许的停机时间。
我见过不少团队，一上来就喊“我们要做到 99.999%”。其实大可不必。你得先算笔账：
- 99%（2个9） —— 全年允许停机 87.6 小时。适合开发测试环境。
- 99.9%（3个9） —— 全年允许 8.76 小时。适合内部工具、非核心业务。
- 99.99%（4个9） —— 全年允许 52.56 分钟。适合大部分面向用户的生产接口。
- 99.999%（5个9） —— 全年允许 5.26 分钟。适合金融、支付等核心链路。
我曾经在一个项目中，看到业务方拍脑袋定了 99.999%。结果一算成本，光是机器资源和冗余架构的钱，就占了预算的一大半。后来大家冷静下来，最终定在了 99.99%。够用就好，别盲目追高。
为什么数据接口的高可用格外重要？
跟传统 Web 页面不同，数据接口一旦挂了，影响的不是“一个用户”，而是“一个系统”。
你想想看，你提供一个查询用户信息的接口。下游有订单系统、客服系统、营销系统。万一套了十万个服务。接口一宕，这十万个服务全都拿不到数据。这就是典型的 雪崩效应。
我个人认为，数据接口的高可用要关注三点：
- 下游无限重试 —— 接口挂了，下游不会乖乖等着。它们会疯狂重试，把你的流量打穿。
- 无状态化 —— 接口最好不存状态，挂了直接拉起另一台。这是我设计接口的基本原则。
- 降级与熔断 —— 扛不住的时候，宁可给下游返回一个降级结果，也别死扛导致全盘崩溃。
最后，我用一张图来总结这一章的核心逻辑，你一看就明白了：
这张图清晰地展示了从 SLI 到 SLO 再到 SLA 的层次关系。你衡量什么，决定了你能承诺什么。所以，别跳过 SLI 直接定 SLA，那是对自己不负责任。