第一章可靠、可扩展与可维护的应用系统这一章是全书的总纲。Kleppmann 不讨论任何具体技术而是先确立评价一切数据系统的三个基本维度可靠性、可扩展性、可维护性。后续每一章的技术权衡最终都可以归结为在这三者之间的取舍。一、为什么需要这三个维度现代应用系统早已不是一台机器跑一个程序的形态。一个典型系统可能包含数据库存储状态缓存加速读取搜索索引支持全文检索消息队列异步解耦批处理框架离线分析这些组件通过网络连接运行在多台机器上。系统一旦复杂就会面临三类根本问题出错时怎么办→ 可靠性数据量/流量增长时怎么办→ 可扩展性长期维护和演化怎么办→ 可维护性这三个问题构成了全书所有讨论的出发点。二、可靠性Reliability1. 定义系统在出现故障fault时仍能继续正确工作。这里有一个关键区分术语含义例子故障fault系统的一部分偏离正常状态一块硬盘坏了、一个进程崩溃失效failure系统整体停止提供服务整个数据库不可用可靠性高的系统不是不会出故障而是故障不会升级为失效。这就是所谓的容错fault-tolerant或韧性resilient。2. 故障的三种来源Kleppmann 把故障分为三类这个分类贯穿全书1硬件故障硬盘损坏、内存位翻转、电源故障、网络中断传统做法冗余RAID、双电源、备用机器现实在大规模集群中硬件故障是常态而非例外。Google 的统计显示同时有数千块硬盘在坏。趋势从单机高可靠转向软件层面容忍多机故障2软件故障系统性 bug、配置错误、级联失效特点跨节点相关——一个 bug 可能同时击垮所有副本例子2012 年某公司因一个配置错误导致全网瘫痪闰秒 bug 导致多系统同时崩溃难点软件故障没有冗余能直接解决因为所有副本跑的是同一份代码3人为错误运维误操作、配置失误、代码逻辑错误统计上人为错误是导致系统失效的首要原因应对策略设计能最小化犯错机会的接口如安全默认值提供沙箱环境测试快速回滚机制完善的监控与遥测3. 可靠性的价值对用户数据不丢失、服务不中断对企业声誉、收入、合规对工程师可靠性是可以被设计的而不是靠运气三、可扩展性Scalability1. 定义系统应对负载增长的能力。关键点可扩展不是一个二元属性而是一个动态问题。不能简单说系统 X 可扩展而要说系统 X 在负载从 A 增长到 B 时用什么手段应对。2. 第一步描述负载在讨论扩展之前必须先量化负载。不同系统的负载参数不同Web 服务每秒请求数RPS数据库读写比例、缓存命中率社交网络粉丝数分布幂律分布少数用户有海量粉丝聊天系统消息发送速率、在线用户数关键洞察平均值会骗人。必须看分布尤其是尾部。3. 第二步描述性能两个核心指标1吞吐量Throughput单位时间处理的请求数/数据量适合批处理、消息队列等场景2响应时间Response Time从发出请求到收到响应的时间注意响应时间不是一个固定值而是一个分布百分位数Percentile——本章最重要的概念之一p50中位数一半请求快于此值p95、p99、p999尾部延迟为什么关注尾部尾部延迟直接影响用户体验一个用户可能同时发多个请求只要一个慢就整体慢尾部延迟往往由排队引起而排队是系统过载的早期信号尾延迟放大Tail Latency Amplification如果一个用户请求需要调用 100 个后端服务只要 1 个慢整体就慢。所以 p99 的 1% 会变成用户侧的 63%。实践建议监控 p95/p99而非只看平均值用直方图而非平均值来聚合延迟在高负载下尾部延迟会急剧恶化4. 第三步应对负载增长两种基本策略1垂直扩展Scaling Up换更强的机器更多 CPU、内存、磁盘优点简单无需改代码缺点成本非线性增长有物理上限2水平扩展Scaling Out增加更多机器分布式处理优点理论上无上限成本线性缺点复杂性剧增分区、复制、一致性Kleppmann 的核心观点没有万能的可扩展架构。适合 10 万用户的架构未必适合 1000 万用户。可扩展性是针对特定负载的需要根据实际访问模式来设计。例子读多写少 → 加缓存、加读副本写多读少 → 分区、LSM-Tree 存储复杂查询 → 列式存储、预聚合四、可维护性Maintainability1. 定义系统在长期运行中能被团队高效地理解、修改、扩展和运维。Kleppmann 指出软件的大部分成本不在初始开发而在持续维护。维护包括修复 bug适应新需求迁移到新平台应对新负载修复技术债务2. 可维护性的三个设计原则1可运维性Operability让运维团队能轻松保持系统运行。具体包括提供良好的监控与日志支持自动化部署与配置避免依赖特定机器的雪花服务器提供清晰的文档与操作手册支持滚动升级、回滚2简单性Simplicity降低系统的复杂度让新工程师能快速理解。复杂性的表现状态空间爆炸隐式依赖命名混乱过度抽象应对手段抽象好的抽象能隐藏实现细节如 SQL 隐藏了存储引擎消除偶然复杂性区分本质复杂性问题本身难和偶然复杂性工具/设计导致的难模块化、清晰的接口3可演化性Evolvability让系统能适应需求变化。也称为可扩展性extensibility或可修改性modifiability。关键点需求永远在变系统必须能跟着变数据模型、接口、协议都要支持演化这与第四章编码与演化直接呼应五、本章的核心思想总结维度核心问题关键概念应对手段可靠性出错时能否继续工作故障 vs 失效冗余、隔离、快速恢复可扩展性负载增长时能否应对百分位数、尾延迟垂直/水平扩展、针对性设计可维护性长期能否高效维护可运维、简单、可演化抽象、自动化、良好接口三个贯穿全书的底层判断没有免费的午餐可靠性、可扩展性、可维护性之间经常需要权衡。没有万能方案所有技术选型都必须结合具体负载和场景。复杂性是最大的敌人好的系统设计本质上是不断对抗复杂性的过程。六、这一章在全书中地位第一章确立了全书的价值坐标系后面讲复制、分区、事务、共识时每个技术选择都要回答“它对可靠性、可扩展性、可维护性分别意味着什么”例如单主复制提高了一致性可靠性但牺牲了写可扩展性无主复制提高了可用性但增加了冲突处理的复杂性可维护性下降。一句话概括本章数据系统的设计本质上是在可靠性、可扩展性、可维护性这三个维度上针对具体负载和场景做出清醒的、有意识的权衡。
