如果让我从《数据密集型应用系统设计》第1章里提炼三个关键词那一定是可靠、可扩展与可维护。这三个词在架构评审会上经常被挂在嘴边可真到了凌晨两点被数据库连接数打满的告警吵醒、用户在群里刷屏说页面打不开的时候你才会意识到它们不是 PPT 里的形容词而是实打实的生存线。这本书的读者大多是后端工程师、基础设施负责人或者是刚接触分布式系统、想补齐底层认知的同学。第1章不急着给你具体中间件选型也不画架构图而是先把“好系统”的三个判断标准讲透后面的复制、分区、事务、流处理所有技术选择其实都在围绕这三个标准展开。所以这一章值得反复读尤其是结合真实负载和踩坑经历来读。1. 可靠性先搞清楚“故障”到底是什么再来谈不宕机1.1 一次真实的订单故障故障链路是怎么被放大的我参与过一个订单服务模块的改造上线后第一次面对大促预热流量时就出过一次典型事故。当天晚上订单量缓慢爬升数据库连接池从 80% 一路涨到 100%紧接着网关层开始报超时上游网关自动重试下游支付回调也重试重试又加大数据库压力最终整个订单链路 40 分钟不可用。事后复盘根因其实是一条商品库存表的慢查询在峰值时把连接池占满了而所有层的自动重试都是“立即重试”完全没有退避等于故障被链路一层层放大。这个案例特别能说明书里强调的一个点故障不是单点事件而是链路事件。你以为要做的是“保证数据库不慢”实际上要做的是“在数据库变慢时系统依然不至于雪崩”。所以可靠性设计不能只盯着单个组件要从调用链、依赖关系、重试策略、降级开关这几个维度同时下手。1.2 三类可靠性杀手硬件、软件、人书里把故障来源大致分成三类我按实际事故比例重新排了一下序故障类型典型例子实际缓解手段人为失误误操作、错误配置、发布变更引入缺陷灰度发布、变更评审、快速回滚、预检脚本、权限管控软件缺陷内存泄漏、死循环、依赖超时、级联故障监控告警、隔离机制、熔断降级、混沌测试硬件故障磁盘损坏、断电、网卡老化、机房制冷失效冗余副本、自动切换、健康检查很多人一提可靠性就想到硬盘坏了怎么办其实按我自己的经验硬件故障往往是最好防御的冗余加自动切换就能解决大部分问题。真正难搞的是软件故障和人的失误软件故障通常由特定输入触发可能同时打挂所有副本人为失误则更难防因为它不是随机事件而是每个团队每天都在发生的常态。书里还区分了“故障fault”和“失效failure”这两个概念故障是某个组件偏离预期失效是系统整体无法对外提供服务。设计目标不是“永不发生故障”而是“容忍故障避免失效”。想清楚这一层很多争论会少很多。1.3 容错设计的三个层次冗余、自动恢复、流程兜底第一层是冗余。硬件上有主备机、多副本、跨机柜部署服务上有多个实例数据上有定期备份。冗余的本质是给故障留出“发生之后还能继续跑”的空间。第二层是自动恢复。健康检查发现实例异常后自动重启负载均衡自动摘除不健康节点主库宕机后自动切换到备库。需要注意的是自动恢复的前提是“能正确检测故障”而检测本身就是设计难点。超时太短会误判超时太长会拖垮用户体验心跳可能受网络抖动影响出现脑裂问题。这些细节都藏在“看起来很简单”的自动切换背后。第三层是流程兜底。发布之前要有预检上线要有灰度出问题要有回滚方案核心链路要有故障预案。我见过很多系统冗余和自动恢复都做了但第一次真实故障时还是停了两个小时原因就是没人知道该按什么顺序切换、切换之后怎么验证。书里讲可靠性时反复提到“可预期”三个字流程兜底要解决的就是让故障处理变得可预期。2. 可扩展性在加机器之前先把负载和性能讲清楚2.1 描述负载别只报“每日请求量”做技术方案的时候经常有人问你这个系统支持多少并发如果你只回答“每天几百万请求”这个数据没法用来做架构判断。书里给了一个更好的思路先用负载参数把系统描述清楚再谈性能指标。负载参数跟系统类型强相关。对于一个面向 C 端的信息流服务核心负载参数可能不是 QPS而是“每个用户关注了多少人”以及“一次刷新要扇出多少个请求”对于一个订单中心更关心的是 TPS、读写比例、事务边界对于一个短视频平台可能要看的是上传带宽、转码队列长度、冷热视频的访问分布。负载参数含义为什么重要QPS / TPS每秒查询数 / 每秒事务数衡量请求压力最直接的指标读写比例读请求和写请求的比值决定缓存策略和数据分布方式峰值因子平均流量与峰值流量的比值决定资源是按均值还是按峰值预留扇出系数一次外部请求触发的内部请求数量决定热点问题会被放大多少倍数据集大小全量数据量、单条数据大小决定是否需要分区、是否需要冷热分层缓存命中率请求命中缓存的比率命中率变化对后端压力影响极大我接手过的一个信息流项目最开始所有人都把注意力放在 QPS 上后来才发现真正的瓶颈是“关注关系扇出”一个大 V 发一条内容要给几百万粉丝推送这比 QPS 高几个量级。所以每次评估扩展性之前先问一句我的系统里哪个负载参数增长 10 倍之后会最先撑不住2.2 延迟、吞吐量与百分位p99 才是用户真实体验描述性能有两种视角吞吐量和延迟。吞吐量是系统单位时间能处理多少请求延迟是一个请求从发出到返回要多少时间。光说“吞吐量 2 万 QPS”是不够的还得问在这个吞吐量下延迟是多少以及延迟在压力升高之后怎么变化。书里特别强调百分位p99、p95、p50而不是平均值。平均延迟真的会骗人假设系统 99% 的请求耗时 100ms1% 的请求耗时 10 秒平均下来可能才 199ms看着非常健康但真正的那 1% 用户已经崩溃了。在服务端做容量规划时我会习惯看 p99 和 p999而在设置告警时更看重 p99 的变化趋势因为平均值异常时往往是系统已经严重过载了。延迟还有一个特性叫“尾部延迟放大”。如果一个请求要串行调用 10 个下游每个下游的 p99 是 50ms那整体 p99 就可能接近 500ms因为最慢的那一跳会叠加。这也是为什么减少串行调用、降低单跳延迟抖动比单纯提高某一跳的平均性能更有效。2.3 三种扩展路径与选择时机纵向、横向、分区扩展路径一般有三条但它们的适用场景差别很大。纵向扩展就是换更强的机器。优点是开发简单、架构不用动缺点是单价贵、有物理上限而且单点风险不会因为换机器而消失。横向扩展是多实例加负载均衡适合无状态服务但一旦涉及会话状态、本地缓存、定时任务就会冒出各种一致性问题。分区是把数据按某个 key 切到不同节点上适合数据量特别大、访问有明显局部性的场景但分区之后又要面对跨分区查询、热点倾斜、rebalance 时数据迁移等新问题。扩展方式优点典型代价适用场景纵向扩展架构改动小容量模型简单成本高有单点上限数据量小、对延迟敏感的单体应用横向扩展无状态服务扩展方便弹性好有状态场景一致性难做Web 层、无状态计算型服务数据分区可以承载超大数据量跨分区查询、热点、rebalance 问题大规模数据存储与检索书里的意思很清楚可扩展性不是“加机器”三个字而是“当负载参数增长时保持性能指标不恶化”的能力。所以要先量化负载参数找到真正的瓶颈再选择对应的扩展方式。我见过不少项目还没到两万用户就上了微服务和分库分表结果分布式带来的复杂度反而让系统频繁出故障这就是扩展性决策做早了。2.4 什么时候不需要扩展这一节书里没单独讲但我认为是第1章最容易忽略但最有价值的部分。如果你的系统数据量不大、峰值可控、业务还在快速迭代单机完全够用那就没有必要为了“想象中的未来”去拆分布式。单机系统更简单、更容易维护、调试起来也更直接这是真真切切的可靠性优势。但“不用扩展”不等于“不做扩展准备”。我会在模块边界上留好接口隔离在数据库设计上避免把业务逻辑全绑死在存储过程里这样等负载真上来的时候可以平滑地把某个模块拆出去而不是推倒重来。3. 可维护性长期成本的大头不在上线那天3.1 可运维性让值班的人能睡个好觉书里给可维护性拆了三个维度可运维性、简单性、可演化性。先说可运维性核心是“运维团队能轻松保持系统平稳运行”。很多团队只关注功能上线不关注上线之后怎么观测、怎么排查、怎么变更结果系统跑了一年多没人说得清楚配置是从哪个配置中心读的、告警为什么总在半夜响、日志格式每行都不一样。可运维性要做的事情很朴素但很容易被拖到很晚才做完整的监控指标和日志链路自动化的部署和发布流程健康检查与自愈机制清晰的配置管理和文档以及安全的回滚路径。我自己的判断标准很直接如果一个系统上线后一个不熟悉它的人能在 30 分钟内看懂它的架构和关键告警那它的可运维性就算及格了。3.2 简单性消灭“意外复杂度”书里把复杂度分成两类本质复杂度和意外复杂度。业务本身就是复杂的比如订单状态机、财务对账逻辑这是本质复杂度躲不掉。意外复杂度则纯粹是自己制造出来的过度分层、多语言混杂、手写异步流程编排、自定义协议、到处都是全局可变状态。意外复杂度最大的危害不是看不懂而是“不敢改”。一个小功能因为依赖环太多怎么改都可能带崩别的地方。我给团队定的原则是能用成熟工具解决的不自己造轮子能用一个明确清晰的抽象表达的不引入第二套概念。书里提到高层语言、数据库、HTTP 协议都是很好的抽象因为它们隐藏了大量底层细节同时提供了稳定接口。做设计时多问一句这个模块能不能交给一个不知道内部细节的人独立修改3.3 可演化性给未来留一个合理的接口业务一定会变这一点几乎不需要证明。可演化性说的是“系统能否适应未来的变化”。它不是一个抽象口号而是一系列具体实践模块边界清晰上下游依赖尽量通过明确稳定的接口交互数据模型与外部格式隔离必要时做渐进式迁移而不是一次性重写。我做过一个数据导出功能的改造老系统直接把数据库表结构暴露给下游下游按字段名取数后来内部表格改名下游跟着全挂。后来统一改成对外 API 加字段映射层内部怎么改都不影响下游。这就是书里说的“以易于扩展的方式组装系统与使用广泛兼容的接口”演化能力很大程度上取决于你在边界上做了多少隔离。4. 一个真实感的改造复盘订单服务如何把三个属性落地4.1 项目背景负载画像与故障点用一个我实际接触过的订单服务模块来做例子。这个服务面向某电商平台的 C 端用户日常 TPS 大概 800大促预热时会飙到 6000存在明显的热点商品和秒杀场景。数据量不算巨大但读写比例大约是 51而且支付回调、库存扣减、订单创建之间有多条事务链路。上线初期的主要故障点有三个。第一数据库连接池在峰值时被打满慢查询拖垮整个订单写入。第二支付回调重复通知导致重复建单用户被同一订单扣了两次款。第三发布新版本时需要停机每次发布都像一次小型事故。整个改造其实就是在按第1章讲的三个属性逐项补齐。4.2 可靠性改造幂等、重试退避与熔断重复扣款这种问题本质是“至少一次”投递语义下的重复请求。我们做的第一件事是幂等改造。核心思路是给每个业务操作生成一个幂等键在真正执行业务逻辑之前先做一次去重检查idem_key request.headers.get(X-Idempotency-Key) if idem_key and redis.setnx(fidem:{idem_key}, 1, ex600): return process_order(request) # 首次请求执行真正的下单逻辑 else: return get_idempotency_result(idem_key) # 重复请求返回之前的处理结果这里要说明两个细节幂等键放 Redis 是为了挡并发高峰但最终防线还是数据库里的唯一索引。因为 Redis 本身也有故障可能只要唯一索引在重复请求最终会撞出一个约束冲突这样兜底才是可靠的。另外重试不能“立即重试”我们改成指数退避加抖动最大重试次数限制在 5 次避免重试流量把本就紧张的下游压垮。熔断则是做在支付环节像hystrix这类机制能做到当支付服务失败率超过阈值时快速失败不再把请求继续打给下游。这看起来是“不干活”但实际保护了下游不进入雪崩状态。故障期间我们的策略是返回“稍后重试”的提示而不是让用户等待一个必然超时的结果。这套组合拳下来同样的峰值流量再出现时系统最多出现少量超时不会整体挂掉。4.3 扩展性手段缓存、异步队列与分片读多写少且存在热点的场景第一件事一定是缓存。我们把热点商品的库存和商品信息放到 Redis 里配合分布式锁防止缓存击穿再用布隆过滤器拦截大量根本不存在的商品 ID防止穿透打到数据库。这一步直接削掉了峰值时 90% 的读压力。写扩展我们选了按 order_id 做数据分片同时预留了按 user_id 聚合查询的从索引。分片键的选取很关键如果按 user_id 分片同一个用户的订单都落在一个分片上查询方便但可能热点集中在个别大用户按 order_id 分片则分布更均匀但跨分片的用户订单查询要额外聚合。我们最终选择 order_id 分片用一套订单聚合查询服务来兜底这样写入压力摊得最开。峰值削峰靠的是异步队列。支付结果回调不直接写数据库而是投递到消息队列由消费服务异步更新订单状态。这样即使回调短时间内翻 10 倍也只是队列积压数据库负载保持平稳。这个改造对日常用户体验没有感知但对峰值稳定性帮助是决定性的。4.4 维护性配套可观测性、契约测试与文档策略改造进行到一半时我们发现没有可观测性很多优化根本不敢上。所以我们统一了 traceId链路日志从网关到数据库全程贯通监控指标采用 RED 模型Rate请求量、Errors错误数、Duration延迟分布。告警规则不再只看平均值而是以 p95、p99 和错误率为主。告警太多等于没有告警我们把真正需要人工处理的场景收敛到了 5 条以内其余全部只记录不打扰。我们还引入了契约测试下游接口变更前必须先跑契约测试避免字段命名调整直接带崩当前服务。文档方面没有写长篇大论而是给关键决策补了一页 ADR架构决策记录比如“为什么分片键选 order_id 而不是 user_id”“为什么幂等键要放在 Redis 且数据库保留唯一索引”每个决策写清楚背景、选项、取舍。三个月后有人接手这套系统只要读这几页 ADR就能理解大部分当时的设计理由。这套改造的启示是可靠、可扩展、可维护并不是三个独立动作它们在落地时是一套整体方案。幂等解决了可靠缓存和分片解决了扩展而可观测性和 ADR 让这套方案后来者能接得住。5. 读第1章时容易踩的四个理解误区5.1 误区一把三个属性当成并列的“上线指标”很多人读完第1章第一反应是“哦我要让系统既可靠又可扩展还可维护”。但书里的三个词不是并列验收项而是层层嵌套的目标可靠是底线可扩展是在负载增长时依然守住底线可维护是让前两者在一两年的周期里还能持续守住。有些决策甚至会在它们之间冲突比如为了可扩展引入微服务反而降低了可靠性为了简化维护牺牲了扩展性的灵活性。真正要做的是在具体负载和团队条件下做权衡而不是把三者挂在墙上当口号。5.2 误区二认为可靠性等于不宕机可靠性更精确的说法是“即使发生故障也能提供正确服务”这里面包含了快速失败、降级、熔断。服务不可用时尽早返回失败结果也是可靠性的体现因为它让用户知道系统状态而不是无限等待。可用性和可靠性也不是一回事一个服务一年都不宕机但中间悄悄返回了大量错误结果它可用但不可靠一个服务偶尔宕机但每次宕机后恢复迅速、几乎没有错误数据它可以说是相对可靠的。5.3 误区三可扩展性就是“加机器”这个理解对无状态服务偶尔成立对数据密集型系统基本不成立。你的系统如果有状态、有数据倾斜、有串行处理环节加机器不但解决不了问题还会带来数据同步、一致性、运维成本等新复杂度。可扩展性的起点是识别负载参数和瓶颈是“对症下药”没有一种通用的加机器方案能覆盖所有场景。5.4 误区四把可维护性简单等同于“代码写得清楚”代码可读性是可维护性里很小的一部分。可维护性还包括依赖是否能升级、配置是否好管理、监控是否能回答“哪里出了问题”、新同学能不能快速上手、架构决策有没有留下文档。一个代码整洁但完全没有文档、依赖纠缠不清、改一发动全身的系统长期维护成本依然很高。书里把可维护性的目标定义为“让所有会碰这个系统的人无论是开发还是运维都能高效地完成各自的工作”这个定义比“代码风格好”要全面得多。我读第1章最大的收获其实是把模糊的质量属性翻译成了可讨论的工程约束。现在每做一个技术方案我会要求自己在方案里写清楚三件事这个系统可能遇到哪些故障、当负载变成现在的 10 倍时瓶颈在哪里、一年后接手的人需要哪些信息才能独立修改。这个习惯帮我跳过了大量无效争论也让方案讨论从“我觉得应该这样”变成了“我们来逐条过一下故障场景”。如果大家有兴趣后面我可以接着整理第2章数据模型与查询语言的部分或者把这次订单改造里做的具体压测方法和大家分享一下。 
长河君 · 2026/10/24 1:27:28 · 阅读 1.2k 数据密集型系统设计：可靠性、可扩展性与可维护性实践
如果让我从《数据密集型应用系统设计》第1章里提炼三个关键词那一定是可靠、可扩展与可维护。这三个词在架构评审会上经常被挂在嘴边可真到了凌晨两点被数据库连接数打满的告警吵醒、用户在群里刷屏说页面打不开的时候你才会意识到它们不是 PPT 里的形容词而是实打实的生存线。这本书的读者大多是后端工程师、基础设施负责人或者是刚接触分布式系统、想补齐底层认知的同学。第1章不急着给你具体中间件选型也不画架构图而是先把“好系统”的三个判断标准讲透后面的复制、分区、事务、流处理所有技术选择其实都在围绕这三个标准展开。所以这一章值得反复读尤其是结合真实负载和踩坑经历来读。1. 可靠性先搞清楚“故障”到底是什么再来谈不宕机1.1 一次真实的订单故障故障链路是怎么被放大的我参与过一个订单服务模块的改造上线后第一次面对大促预热流量时就出过一次典型事故。当天晚上订单量缓慢爬升数据库连接池从 80% 一路涨到 100%紧接着网关层开始报超时上游网关自动重试下游支付回调也重试重试又加大数据库压力最终整个订单链路 40 分钟不可用。事后复盘根因其实是一条商品库存表的慢查询在峰值时把连接池占满了而所有层的自动重试都是“立即重试”完全没有退避等于故障被链路一层层放大。这个案例特别能说明书里强调的一个点故障不是单点事件而是链路事件。你以为要做的是“保证数据库不慢”实际上要做的是“在数据库变慢时系统依然不至于雪崩”。所以可靠性设计不能只盯着单个组件要从调用链、依赖关系、重试策略、降级开关这几个维度同时下手。1.2 三类可靠性杀手硬件、软件、人书里把故障来源大致分成三类我按实际事故比例重新排了一下序故障类型典型例子实际缓解手段人为失误误操作、错误配置、发布变更引入缺陷灰度发布、变更评审、快速回滚、预检脚本、权限管控软件缺陷内存泄漏、死循环、依赖超时、级联故障监控告警、隔离机制、熔断降级、混沌测试硬件故障磁盘损坏、断电、网卡老化、机房制冷失效冗余副本、自动切换、健康检查很多人一提可靠性就想到硬盘坏了怎么办其实按我自己的经验硬件故障往往是最好防御的冗余加自动切换就能解决大部分问题。真正难搞的是软件故障和人的失误软件故障通常由特定输入触发可能同时打挂所有副本人为失误则更难防因为它不是随机事件而是每个团队每天都在发生的常态。书里还区分了“故障fault”和“失效failure”这两个概念故障是某个组件偏离预期失效是系统整体无法对外提供服务。设计目标不是“永不发生故障”而是“容忍故障避免失效”。想清楚这一层很多争论会少很多。1.3 容错设计的三个层次冗余、自动恢复、流程兜底第一层是冗余。硬件上有主备机、多副本、跨机柜部署服务上有多个实例数据上有定期备份。冗余的本质是给故障留出“发生之后还能继续跑”的空间。第二层是自动恢复。健康检查发现实例异常后自动重启负载均衡自动摘除不健康节点主库宕机后自动切换到备库。需要注意的是自动恢复的前提是“能正确检测故障”而检测本身就是设计难点。超时太短会误判超时太长会拖垮用户体验心跳可能受网络抖动影响出现脑裂问题。这些细节都藏在“看起来很简单”的自动切换背后。第三层是流程兜底。发布之前要有预检上线要有灰度出问题要有回滚方案核心链路要有故障预案。我见过很多系统冗余和自动恢复都做了但第一次真实故障时还是停了两个小时原因就是没人知道该按什么顺序切换、切换之后怎么验证。书里讲可靠性时反复提到“可预期”三个字流程兜底要解决的就是让故障处理变得可预期。2. 可扩展性在加机器之前先把负载和性能讲清楚2.1 描述负载别只报“每日请求量”做技术方案的时候经常有人问你这个系统支持多少并发如果你只回答“每天几百万请求”这个数据没法用来做架构判断。书里给了一个更好的思路先用负载参数把系统描述清楚再谈性能指标。负载参数跟系统类型强相关。对于一个面向 C 端的信息流服务核心负载参数可能不是 QPS而是“每个用户关注了多少人”以及“一次刷新要扇出多少个请求”对于一个订单中心更关心的是 TPS、读写比例、事务边界对于一个短视频平台可能要看的是上传带宽、转码队列长度、冷热视频的访问分布。负载参数含义为什么重要QPS / TPS每秒查询数 / 每秒事务数衡量请求压力最直接的指标读写比例读请求和写请求的比值决定缓存策略和数据分布方式峰值因子平均流量与峰值流量的比值决定资源是按均值还是按峰值预留扇出系数一次外部请求触发的内部请求数量决定热点问题会被放大多少倍数据集大小全量数据量、单条数据大小决定是否需要分区、是否需要冷热分层缓存命中率请求命中缓存的比率命中率变化对后端压力影响极大我接手过的一个信息流项目最开始所有人都把注意力放在 QPS 上后来才发现真正的瓶颈是“关注关系扇出”一个大 V 发一条内容要给几百万粉丝推送这比 QPS 高几个量级。所以每次评估扩展性之前先问一句我的系统里哪个负载参数增长 10 倍之后会最先撑不住2.2 延迟、吞吐量与百分位p99 才是用户真实体验描述性能有两种视角吞吐量和延迟。吞吐量是系统单位时间能处理多少请求延迟是一个请求从发出到返回要多少时间。光说“吞吐量 2 万 QPS”是不够的还得问在这个吞吐量下延迟是多少以及延迟在压力升高之后怎么变化。书里特别强调百分位p99、p95、p50而不是平均值。平均延迟真的会骗人假设系统 99% 的请求耗时 100ms1% 的请求耗时 10 秒平均下来可能才 199ms看着非常健康但真正的那 1% 用户已经崩溃了。在服务端做容量规划时我会习惯看 p99 和 p999而在设置告警时更看重 p99 的变化趋势因为平均值异常时往往是系统已经严重过载了。延迟还有一个特性叫“尾部延迟放大”。如果一个请求要串行调用 10 个下游每个下游的 p99 是 50ms那整体 p99 就可能接近 500ms因为最慢的那一跳会叠加。这也是为什么减少串行调用、降低单跳延迟抖动比单纯提高某一跳的平均性能更有效。2.3 三种扩展路径与选择时机纵向、横向、分区扩展路径一般有三条但它们的适用场景差别很大。纵向扩展就是换更强的机器。优点是开发简单、架构不用动缺点是单价贵、有物理上限而且单点风险不会因为换机器而消失。横向扩展是多实例加负载均衡适合无状态服务但一旦涉及会话状态、本地缓存、定时任务就会冒出各种一致性问题。分区是把数据按某个 key 切到不同节点上适合数据量特别大、访问有明显局部性的场景但分区之后又要面对跨分区查询、热点倾斜、rebalance 时数据迁移等新问题。扩展方式优点典型代价适用场景纵向扩展架构改动小容量模型简单成本高有单点上限数据量小、对延迟敏感的单体应用横向扩展无状态服务扩展方便弹性好有状态场景一致性难做Web 层、无状态计算型服务数据分区可以承载超大数据量跨分区查询、热点、rebalance 问题大规模数据存储与检索书里的意思很清楚可扩展性不是“加机器”三个字而是“当负载参数增长时保持性能指标不恶化”的能力。所以要先量化负载参数找到真正的瓶颈再选择对应的扩展方式。我见过不少项目还没到两万用户就上了微服务和分库分表结果分布式带来的复杂度反而让系统频繁出故障这就是扩展性决策做早了。2.4 什么时候不需要扩展这一节书里没单独讲但我认为是第1章最容易忽略但最有价值的部分。如果你的系统数据量不大、峰值可控、业务还在快速迭代单机完全够用那就没有必要为了“想象中的未来”去拆分布式。单机系统更简单、更容易维护、调试起来也更直接这是真真切切的可靠性优势。但“不用扩展”不等于“不做扩展准备”。我会在模块边界上留好接口隔离在数据库设计上避免把业务逻辑全绑死在存储过程里这样等负载真上来的时候可以平滑地把某个模块拆出去而不是推倒重来。3. 可维护性长期成本的大头不在上线那天3.1 可运维性让值班的人能睡个好觉书里给可维护性拆了三个维度可运维性、简单性、可演化性。先说可运维性核心是“运维团队能轻松保持系统平稳运行”。很多团队只关注功能上线不关注上线之后怎么观测、怎么排查、怎么变更结果系统跑了一年多没人说得清楚配置是从哪个配置中心读的、告警为什么总在半夜响、日志格式每行都不一样。可运维性要做的事情很朴素但很容易被拖到很晚才做完整的监控指标和日志链路自动化的部署和发布流程健康检查与自愈机制清晰的配置管理和文档以及安全的回滚路径。我自己的判断标准很直接如果一个系统上线后一个不熟悉它的人能在 30 分钟内看懂它的架构和关键告警那它的可运维性就算及格了。3.2 简单性消灭“意外复杂度”书里把复杂度分成两类本质复杂度和意外复杂度。业务本身就是复杂的比如订单状态机、财务对账逻辑这是本质复杂度躲不掉。意外复杂度则纯粹是自己制造出来的过度分层、多语言混杂、手写异步流程编排、自定义协议、到处都是全局可变状态。意外复杂度最大的危害不是看不懂而是“不敢改”。一个小功能因为依赖环太多怎么改都可能带崩别的地方。我给团队定的原则是能用成熟工具解决的不自己造轮子能用一个明确清晰的抽象表达的不引入第二套概念。书里提到高层语言、数据库、HTTP 协议都是很好的抽象因为它们隐藏了大量底层细节同时提供了稳定接口。做设计时多问一句这个模块能不能交给一个不知道内部细节的人独立修改3.3 可演化性给未来留一个合理的接口业务一定会变这一点几乎不需要证明。可演化性说的是“系统能否适应未来的变化”。它不是一个抽象口号而是一系列具体实践模块边界清晰上下游依赖尽量通过明确稳定的接口交互数据模型与外部格式隔离必要时做渐进式迁移而不是一次性重写。我做过一个数据导出功能的改造老系统直接把数据库表结构暴露给下游下游按字段名取数后来内部表格改名下游跟着全挂。后来统一改成对外 API 加字段映射层内部怎么改都不影响下游。这就是书里说的“以易于扩展的方式组装系统与使用广泛兼容的接口”演化能力很大程度上取决于你在边界上做了多少隔离。4. 一个真实感的改造复盘订单服务如何把三个属性落地4.1 项目背景负载画像与故障点用一个我实际接触过的订单服务模块来做例子。这个服务面向某电商平台的 C 端用户日常 TPS 大概 800大促预热时会飙到 6000存在明显的热点商品和秒杀场景。数据量不算巨大但读写比例大约是 51而且支付回调、库存扣减、订单创建之间有多条事务链路。上线初期的主要故障点有三个。第一数据库连接池在峰值时被打满慢查询拖垮整个订单写入。第二支付回调重复通知导致重复建单用户被同一订单扣了两次款。第三发布新版本时需要停机每次发布都像一次小型事故。整个改造其实就是在按第1章讲的三个属性逐项补齐。4.2 可靠性改造幂等、重试退避与熔断重复扣款这种问题本质是“至少一次”投递语义下的重复请求。我们做的第一件事是幂等改造。核心思路是给每个业务操作生成一个幂等键在真正执行业务逻辑之前先做一次去重检查idem_key request.headers.get(X-Idempotency-Key) if idem_key and redis.setnx(fidem:{idem_key}, 1, ex600): return process_order(request) # 首次请求执行真正的下单逻辑 else: return get_idempotency_result(idem_key) # 重复请求返回之前的处理结果这里要说明两个细节幂等键放 Redis 是为了挡并发高峰但最终防线还是数据库里的唯一索引。因为 Redis 本身也有故障可能只要唯一索引在重复请求最终会撞出一个约束冲突这样兜底才是可靠的。另外重试不能“立即重试”我们改成指数退避加抖动最大重试次数限制在 5 次避免重试流量把本就紧张的下游压垮。熔断则是做在支付环节像hystrix这类机制能做到当支付服务失败率超过阈值时快速失败不再把请求继续打给下游。这看起来是“不干活”但实际保护了下游不进入雪崩状态。故障期间我们的策略是返回“稍后重试”的提示而不是让用户等待一个必然超时的结果。这套组合拳下来同样的峰值流量再出现时系统最多出现少量超时不会整体挂掉。4.3 扩展性手段缓存、异步队列与分片读多写少且存在热点的场景第一件事一定是缓存。我们把热点商品的库存和商品信息放到 Redis 里配合分布式锁防止缓存击穿再用布隆过滤器拦截大量根本不存在的商品 ID防止穿透打到数据库。这一步直接削掉了峰值时 90% 的读压力。写扩展我们选了按 order_id 做数据分片同时预留了按 user_id 聚合查询的从索引。分片键的选取很关键如果按 user_id 分片同一个用户的订单都落在一个分片上查询方便但可能热点集中在个别大用户按 order_id 分片则分布更均匀但跨分片的用户订单查询要额外聚合。我们最终选择 order_id 分片用一套订单聚合查询服务来兜底这样写入压力摊得最开。峰值削峰靠的是异步队列。支付结果回调不直接写数据库而是投递到消息队列由消费服务异步更新订单状态。这样即使回调短时间内翻 10 倍也只是队列积压数据库负载保持平稳。这个改造对日常用户体验没有感知但对峰值稳定性帮助是决定性的。4.4 维护性配套可观测性、契约测试与文档策略改造进行到一半时我们发现没有可观测性很多优化根本不敢上。所以我们统一了 traceId链路日志从网关到数据库全程贯通监控指标采用 RED 模型Rate请求量、Errors错误数、Duration延迟分布。告警规则不再只看平均值而是以 p95、p99 和错误率为主。告警太多等于没有告警我们把真正需要人工处理的场景收敛到了 5 条以内其余全部只记录不打扰。我们还引入了契约测试下游接口变更前必须先跑契约测试避免字段命名调整直接带崩当前服务。文档方面没有写长篇大论而是给关键决策补了一页 ADR架构决策记录比如“为什么分片键选 order_id 而不是 user_id”“为什么幂等键要放在 Redis 且数据库保留唯一索引”每个决策写清楚背景、选项、取舍。三个月后有人接手这套系统只要读这几页 ADR就能理解大部分当时的设计理由。这套改造的启示是可靠、可扩展、可维护并不是三个独立动作它们在落地时是一套整体方案。幂等解决了可靠缓存和分片解决了扩展而可观测性和 ADR 让这套方案后来者能接得住。5. 读第1章时容易踩的四个理解误区5.1 误区一把三个属性当成并列的“上线指标”很多人读完第1章第一反应是“哦我要让系统既可靠又可扩展还可维护”。但书里的三个词不是并列验收项而是层层嵌套的目标可靠是底线可扩展是在负载增长时依然守住底线可维护是让前两者在一两年的周期里还能持续守住。有些决策甚至会在它们之间冲突比如为了可扩展引入微服务反而降低了可靠性为了简化维护牺牲了扩展性的灵活性。真正要做的是在具体负载和团队条件下做权衡而不是把三者挂在墙上当口号。5.2 误区二认为可靠性等于不宕机可靠性更精确的说法是“即使发生故障也能提供正确服务”这里面包含了快速失败、降级、熔断。服务不可用时尽早返回失败结果也是可靠性的体现因为它让用户知道系统状态而不是无限等待。可用性和可靠性也不是一回事一个服务一年都不宕机但中间悄悄返回了大量错误结果它可用但不可靠一个服务偶尔宕机但每次宕机后恢复迅速、几乎没有错误数据它可以说是相对可靠的。5.3 误区三可扩展性就是“加机器”这个理解对无状态服务偶尔成立对数据密集型系统基本不成立。你的系统如果有状态、有数据倾斜、有串行处理环节加机器不但解决不了问题还会带来数据同步、一致性、运维成本等新复杂度。可扩展性的起点是识别负载参数和瓶颈是“对症下药”没有一种通用的加机器方案能覆盖所有场景。5.4 误区四把可维护性简单等同于“代码写得清楚”代码可读性是可维护性里很小的一部分。可维护性还包括依赖是否能升级、配置是否好管理、监控是否能回答“哪里出了问题”、新同学能不能快速上手、架构决策有没有留下文档。一个代码整洁但完全没有文档、依赖纠缠不清、改一发动全身的系统长期维护成本依然很高。书里把可维护性的目标定义为“让所有会碰这个系统的人无论是开发还是运维都能高效地完成各自的工作”这个定义比“代码风格好”要全面得多。我读第1章最大的收获其实是把模糊的质量属性翻译成了可讨论的工程约束。现在每做一个技术方案我会要求自己在方案里写清楚三件事这个系统可能遇到哪些故障、当负载变成现在的 10 倍时瓶颈在哪里、一年后接手的人需要哪些信息才能独立修改。这个习惯帮我跳过了大量无效争论也让方案讨论从“我觉得应该这样”变成了“我们来逐条过一下故障场景”。如果大家有兴趣后面我可以接着整理第2章数据模型与查询语言的部分或者把这次订单改造里做的具体压测方法和大家分享一下。