可用性七级图表

当一个服务挂了的时候，它到底”挂成什么样”，可以用一张七级图表来定位自己的服务当前处在哪个可用性级别上——级别越高，代表故障时对用户的实际影响越小。第1级：Crash with data corruption/destruction（崩溃且数据损坏或丢失），常见于内存数据库，写硬盘写到一半挂了，不仅进程内数据没了，连老数据都可能丢光，遇到这种系统只能表示同情。第2级：Crash with new data loss（崩溃但只丢新数据），正常服务至少应该做到这一点——挂了之后最多丢几秒之内的数据。第3级：Crash without data loss（崩溃但不丢数据），要做到这一级需要一定的技术投入，起码要搞清楚如何绕过操作系统的各种Cache、如何绕过硬件层面的各种坑。第4级：No crash, but with no or very limited service, low service quality（不崩溃，但服务严重受限、质量低），做得好一点的系统不应该动不动就崩溃——如果程序能正常处理异常输入异常数据，就为高级流控系统创造了条件，可以把其他正常流量导入过来、把问题流量单独隔离处理，不至于造成太大的容量损失。第5级：Partial or limited service, with good to medium service quality（部分或受限服务，质量中等偏上），如果多个业务跑在同一个实例上，起码不要全部一起坏掉，有部分服务总比完全没服务要好。第6级：Failover with significant user visible delay, near full quality of service（有明显用户可感知延迟的故障转移，接近完整服务质量），到这一级才算摸到高可用的门——已经有容灾措施，只是自动化程度可能不高、或还有一些关键问题没解决，所以业务能恢复但比较慢。第7级：Failover with minimal to none user visible delay, near full quality of service（故障转移对用户几乎无感知，接近完整服务质量），这是高可用的终极目标——哪怕一整个机房被打掉，业务完全不受影响，高可用架构的全部准备就是为了应对这种极端场景。

结构图：

flowchart TD
    L1["第1级：崩溃且数据损坏/丢失\n（内存数据库常见）"] --> L2["第2级：崩溃但只丢新数据\n（合格服务的最低要求）"]
    L2 --> L3["第3级：崩溃但不丢数据\n（需绕过OS/硬件Cache）"]
    L3 --> L4["第4级：不崩溃但服务严重受限\n（为高级流控创造条件）"]
    L4 --> L5["第5级：部分/受限服务\n中等偏上质量"]
    L5 --> L6["第6级：故障转移有明显延迟\n接近完整服务质量"]
    L6 --> L7["第7级：故障转移用户几乎无感知\n接近完整服务质量\n（真正的高可用）"]