1. 项目概述这不是一份普通笔记而是一套可落地的系统设计知识骨架“system-design-notes”这个标题乍看平平无奇像极了某位工程师随手建的GitHub仓库名或是技术分享会上一页被快速翻过的PPT。但如果你在CSDN、知乎或LeetCode讨论区搜过“system design”就会发现——90%的初学者卡在同一个地方不是不会写代码而是根本不知道该从哪下笔画第一张架构图不是不懂数据库原理而是面对“支撑千万日活的短链服务”这种题干时连QPS怎么估算都无从下手不是没看过CAP理论但在选型Redis集群还是TiDB分片时依然靠直觉拍板。我带过37个校招新人做过12场一线大厂面试官也陪5家创业公司从0到1搭过后端体系最终发现真正阻碍系统设计能力跃迁的从来不是知识碎片而是缺乏一套可复用、可验证、可演进的知识骨架。这份notes就是我在过去八年里把分布式系统、高并发架构、容错设计、可观测性等模块反复拆解、重构、压测、推翻后沉淀下来的实战框架。它不讲抽象概念每一条都对应一个真实场景比如“如何让订单服务在秒杀峰值下不雪崩”对应的是限流熔断策略的参数计算表“为什么用户中心要拆成user-core和user-profile两个服务”背后是领域驱动设计中限界上下文的划分逻辑甚至包括“MySQL主从延迟突增时监控告警阈值该设多少毫秒”这种连官方文档都不写的细节。它适合三类人准备技术晋升答辩的中级工程师需要快速搭建MVP架构的创业者以及正在啃《Designing Data-Intensive Applications》却总感觉“知道但不会用”的学习者。核心关键词“system”“design”“notes”在这里不是泛指而是特指以终为始的工程决策记录——每个设计选择都标注了当时业务规模、团队能力、SLA要求和后续验证结果这才是能真正长进你肌肉记忆里的东西。2. 内容整体设计与思路拆解为什么放弃“教科书式”笔记选择“决策日志”结构2.1 传统系统设计资料的三大失效点我试过把《DDIA》《SRE手册》《AWS Well-Architected》全打印出来贴满整面墙结果半年后发现笔记上全是荧光笔划的重点但实际做架构评审时还是得临时翻文档查“Kafka分区数怎么算”。问题出在哪不是内容不专业而是知识组织方式与工程实践严重脱节。具体有三个致命缺陷第一因果倒置。教科书按技术栈分章节先讲消息队列原理再讲数据库索引最后讲缓存一致性。但现实中你接到的需求永远是“首页PV要从5万涨到50万现有架构扛不住”。这时候你需要的不是“Kafka是什么”而是“当流量突增300%时消息积压告警阈值该设多少怎么验证这个阈值合理”——前者是知识后者才是决策。第二参数真空。几乎所有资料都会说“用Redis做缓存”但没人告诉你当缓存穿透发生时布隆过滤器的误判率设0.01%还是0.1%对内存占用的影响差4倍或者“数据库读写分离”但不说明主从延迟超过200ms时业务层重试逻辑必须从“最多3次”改成“指数退避降级开关”。这些参数不是凭空来的而是我在电商大促压测中用JMeter跑出127组数据后反推出来的。第三演进断层。教科书只展示“最终架构图”但真实系统是长出来的。比如用户中心服务最早可能就一个单体Java应用后来拆成auth-service和profile-service再后来profile-service又拆出address-service和preference-service。每次拆分的触发条件如单服务QPS超3000、拆分成本DB迁移耗时17小时、回滚预案灰度期间保留双写——这些血泪经验恰恰是新人最需要的“拐杖”。2.2 “决策日志”结构的设计逻辑用时间轴锚定技术选择所以这份notes彻底抛弃了“技术分类法”改用时间维度决策树来组织内容。举个典型例子“支付回调幂等性设计”这一条不是罗列“用Redis SETNX”“用数据库唯一索引”“用状态机”三种方案而是按真实项目时间线展开阶段1日订单1000单用MySQL唯一索引业务状态字段。理由开发成本最低DBA已熟悉且当时支付渠道回调失败率0.02%冲突概率可忽略。实操注意唯一索引必须包含商户号订单号支付流水号三元组漏掉任一字段都会导致跨商户冲突。阶段2日订单5万单引入Redis原子操作本地缓存。触发条件支付渠道升级后回调重试频率提升DB唯一索引冲突报警每天超200次。关键参数Redis TTL设为订单超时时间30分钟防时钟漂移本地缓存用Caffeine最大size10000expireAfterWrite10分钟避免内存泄漏。这里有个坑早期用Guava Cache结果GC停顿导致回调超时换成Caffeine后P99延迟从800ms降到45ms。阶段3日订单50万单改用分布式状态机事件溯源。原因业务方要求支持“部分退款”“冲正”等复杂状态流转原方案无法满足审计要求。技术选型对比自研状态机 vs Camunda vs Temporal。最终选Temporal因为其内置的“重试策略超时补偿人工干预”能力比自研节省67%开发量。但代价是运维复杂度上升必须给Temporal Server配专用节点且监控指标要单独接入Prometheus。看到没每一步都带着业务规模、触发条件、量化指标、踩坑记录。这不是知识搬运而是把八年踩过的坑、算过的账、压过的测全部摊开给你看。当你下次面对类似需求不用再从零开始论证直接查“支付回调”这条目就能拿到适配你当前阶段的完整方案包。2.3 为什么坚持手写而非工具生成参数背后的物理世界约束有人问现在AI都能画架构图了还要手写notes干嘛我反问你知道为什么Kafka的replication.factor默认是3吗不是因为“3是个吉利数字”而是源于数据中心的物理部署约束——我们通常把Broker分布在3个可用区AZ这样即使一个AZ整体宕机剩余2个AZ仍能组成多数派quorum。如果你们公司只有2个AZ硬设replication.factor3反而会导致ISRIn-Sync Replicas频繁收缩吞吐量暴跌。这类参数AI永远算不出来因为它不懂你机房的拓扑、不懂你运维团队的夜班排班规则、更不懂你老板对“年度故障时间≤5分钟”的KPI压力。所以这份notes里所有参数都标注了物理约束来源。比如“API网关限流阈值设为5000 QPS”后面跟着小字备注“基于AWS ALB每实例最大连接数65536当前部署4台t3.xlarge16GB内存实测单实例承载1250 QPS时CPU达78%预留20%余量后得出”。再比如“Elasticsearch分片数设为16”备注是“集群共8个数据节点每个节点分配2个分片确保分片均匀分布同时16是2的幂便于后续水平扩容时分片重平衡”。这些细节只有亲手调过参数、看过监控曲线、跟运维吵过架的人才写得出来。3. 核心细节解析与实操要点从“知道”到“做到”的关键断点3.1 架构图不是装饰画而是可执行的契约文档很多人画完架构图就扔进Confluence结果开发时各干各的。我见过最离谱的案例架构图上写着“订单服务通过gRPC调用库存服务”结果上线后发现库存服务用的是REST API因为开发同学觉得“gRPC太重”。问题出在哪架构图缺少契约定义。在这份notes里每个服务间的交互必须包含三要素协议层契约明确指定gRPC版本v1.32.0、IDL文件路径/proto/inventory/v1/inventory.proto、服务端口50051。特别注明禁止使用gRPC-Web因前端团队不支持Protobuf解析。语义层契约定义接口的业务语义比如ReserveStock方法必须声明“此调用仅预留库存不扣减预留有效期为30分钟”。这直接影响下游实现——如果库存服务把预留当成扣减整个履约链路就崩了。SLA层契约约定P99延迟≤200ms错误率≤0.1%超时时间设为1500ms3倍P99。更重要的是注明“若连续5分钟错误率0.5%自动触发熔断降级返回兜底库存数”。这个SLA不是拍脑袋而是基于压测数据用Gatling模拟1000并发请求观察库存服务在不同负载下的错误率曲线找到拐点。实操心得我强制要求所有新服务上线前必须提交一份《服务契约说明书》包含上述三要素。最初团队抱怨“太啰嗦”直到某次大促支付服务因库存接口超时未熔断导致订单创建失败率飙升至12%大家才明白架构图上的线条必须能翻译成可执行的代码和配置。3.2 数据库设计别再迷信“范式”先算清IO成本新手常犯的错误是看到“用户表”就立刻拆分成users、user_profiles、user_addresses三张表美其名曰“符合第三范式”。但现实是一次用户详情查询要JOIN 5张表磁盘IO直接拉满。在这份notes里数据库设计遵循IO成本优先原则所有表结构都附带成本测算以“订单表”为例方案A完全范式化orders表order_id, user_id, status...order_items表item_id, order_id, sku_id, qty...skus表sku_id, name, price...。查询订单详情需3次JOIN。方案B适度冗余orders表包含user_name、user_phone冗余用户基础信息order_items表包含sku_name、sku_price冗余商品信息。查询只需1次SELECT。成本测算过程统计线上慢SQL订单详情页90%的慢查询集中在JOIN操作平均耗时420ms。模拟数据量日订单10万orders表年增长3650万行order_items表年增长1.2亿行。计算IOSSD随机读取延迟约0.1ms3次JOIN至少产生3次随机IO理论下限300ms而单表查询只需顺序扫描10MB数据块读取耗时5ms。权衡冗余代价user_name字段冗余占用空间增加约12MB/年远小于IO成本节省的300ms×10万次/日3000秒/日。结论采用方案B并加注“冗余字段更新策略用户改名时异步任务批量更新orders表允许10分钟内数据不一致”。这就是典型的“用空间换时间”但每一步都有数据支撑。3.3 缓存策略失效不是终点而是新问题的起点“缓存雪崩”“缓存穿透”“缓存击穿”这三个词几乎出现在所有面试题里但很少有人告诉你缓存失效后的重建策略比失效本身更危险。我亲眼见过一次事故Redis集群因网络抖动集体失效所有服务瞬间涌向MySQLQPS从2000飙到15000DB直接OOM。根源在于缓存重建逻辑——每个请求发现缓存为空就自己去DB查再写回缓存。这叫“缓存击穿”但更致命的是“重建风暴”。在这份notes里缓存策略分为三层防御第一层预防设置随机TTL。比如商品详情缓存基础TTL3600s但实际设为3600±300s。避免大量key在同一时刻失效。第二层拦截本地缓存布隆过滤器。对高频查询如用户登录态先查Caffeine本地缓存maxSize10000命中率95%未命中时先过布隆过滤器判断key是否存在误判率控制在0.05%经测试1GB内存可支撑10亿key。第三层重建分布式锁懒加载。Redis失效后第一个请求获取分布式锁RedLock由它负责重建缓存其他请求等待锁释放后直接读新缓存。关键细节锁超时时间必须大于DB查询写缓存的最长耗时我们设为10秒实测DB最慢查询8.2秒。提示布隆过滤器的误判率不是越低越好。误判率0.01%需要更多哈希函数和更大内存而0.05%在1GB内存下能支撑10亿key且对业务影响微乎其微——误判时多一次DB查询但避免了重建风暴。3.4 部署与发布灰度不是功能而是可控的实验很多团队把灰度发布当成“先放10%流量”结果发现指标异常时已经来不及回滚。真正的灰度是分阶段验证的科学实验。在这份notes里灰度发布流程强制包含四个验证阶段配置灰度新版本上线后先关闭所有新功能开关Feature Flag只验证基础链路是否通畅。监控项HTTP 5xx错误率、JVM GC频率、线程池活跃线程数。达标标准5xx0.01%GC次数/分钟5次。流量灰度开启1%真实流量重点验证核心接口如下单、支付。监控项P99延迟、成功率、下游服务错误率。达标标准P99延迟波动10%成功率下降不超过0.1个百分点。功能灰度逐步打开新功能开关按用户分群如按地域、设备类型分批放量。监控项功能使用率、业务转化率、异常埋点上报量。达标标准转化率不低于基线95%异常埋点0.5%。全量验证100%流量后持续监控24小时重点看长尾指标磁盘IO wait、网络丢包率、慢SQL数量。达标标准所有指标回归基线水平。实操心得我们曾在一个搜索服务升级中在“功能灰度”阶段发现iOS用户点击率下降12%。排查发现新算法对iPhone SE屏幕适配有问题。如果跳过这一步直接全量损失的是百万级DAU。灰度不是流程而是用最小成本暴露最大风险的实验设计。4. 实操过程与核心环节实现从0到1搭建可验证的笔记体系4.1 工具链选择为什么用MarkdownGit而不是Notion或飞书很多人问我为什么不用Notion这种现代化笔记工具答案很实在协作与可追溯性。Notion的页面修改历史只能看到“谁在什么时候改了什么”但看不到“为什么这么改”。而Git的commit message可以精确记录每一次调整的背景git commit -m refactor: update cache strategy for order service per Black Friday stress test (see /docs/perf-test-20231125.md)git commit -m fix: adjust Kafka replication factor from 3 to 2 due to AZ constraint change (see infra/ticket-4567)更重要的是MarkdownGit天然支持代码化管理。比如数据库表结构变更不是写一段文字描述而是直接放SQL脚本-- /sql/migrations/20231201_add_user_profile_index.sql CREATE INDEX idx_user_profile_user_id ON user_profiles(user_id) WHERE status active; -- 理由解决用户详情页慢查询实测提升查询速度83%所有SQL都经过CI流水线验证语法检查、执行计划分析EXPLAIN、影响行数预估避免误删。这种“笔记即代码”的模式让知识真正变成可执行、可测试、可回滚的资产。4.2 目录结构设计让新人30秒定位到关键决策目录不是随便分的而是按工程师解决问题的思维路径设计。根目录下只有五个文件夹/decisions所有重大架构决策记录按时间倒序排列20231201-payment-idempotent.md。每个文件包含背景、选项对比、最终选择、验证结果、后续演进。/patterns可复用的设计模式如“Saga分布式事务”“CQRS读写分离”。每个模式附带适用场景判断树、代码片段、性能基准测试数据。/configs生产环境配置模板如Nginx超时参数、JVM GC参数、Kafka消费者配置。每项参数标注推荐值、取值范围、调整依据如“-XX:MaxMetaspaceSize512m基于线上Metaspace内存泄漏分析报告”。/troubleshooting典型故障排查指南如“MySQL主从延迟突增”。按“现象→指标→根因→修复→验证”五步展开附带真实监控截图脱敏和命令行操作记录。/benchmarks压测报告归档如“订单服务10万QPS压测”。包含测试环境配置、JMeter脚本片段、性能曲线图、瓶颈分析如“CPU 95%由JSON序列化占用改用Jackson Streaming API后降至42%”。新人入职第一天只要打开/decisions/README.md就能看到最近三个月所有关键决策摘要30秒内找到“支付服务改造”相关条目点击进去就是完整决策链。这比让他花三天读完所有文档高效得多。4.3 决策记录模板拒绝模糊表述强制量化输出每份决策记录必须填满以下字段缺一不可字段示例强制要求业务背景“双11大促预计峰值QPS 8万当前订单服务QPS上限3.2万”必须含具体数字和来源如“基于去年大促流量预测模型v2.1”技术选项A. 垂直拆分按业务域 B. 水平分片按user_id哈希 C. 读写分离缓存至少列出3个可行选项禁用“其他方案”评估维度开发周期人日、运维复杂度1-5分、扩展性支持QPS 20万、数据一致性强/最终每个维度必须量化禁用“较高”“较好”等模糊词最终选择选B理由开发周期最短12人日 vs A的28人日且分片键user_id与查询高频条件一致必须说明“为什么不是其他选项”验证结果压测达成QPS 12.5万P99延迟186msCPU峰值72%必须含实测数据截图存于/benchmarks/20231120-order-sharding后续演进当QPS超15万时需引入分片中间件ShardingSphere明确下一个决策触发点注意所有“理由”必须可验证。例如不能写“B方案性能更好”而要写“B方案在同等硬件下TPC-C测试得分比A高37%见/benchmarks/tpcc-comparison.xlsx”。4.4 知识更新机制让笔记活起来而不是变成电子古董最怕笔记写完就吃灰。我们建立了一套“反馈闭环”机制每周五下午架构师主持15分钟站会每人分享一个本周遇到的、notes里没覆盖的问题。当场决定是否新增条目或修订现有条目。每次线上故障复盘必须更新对应条目的/troubleshooting文件补充新发现的现象和根因。例如上次支付超时故障我们在/troubleshooting/payment-timeout.md里新增了“网络抖动导致TLS握手超时”的排查步骤。季度知识审计用脚本扫描所有/decisions文件统计“被引用次数”。引用次数3的条目进入待淘汰清单引用次数20的条目升级为团队标准规范。实操心得曾经有个条目“Redis连接池配置”三年没更新直到某次故障才发现旧配置在新版本Jedis里已废弃。现在我们规定任何条目超过6个月未被引用或更新自动触发邮件提醒作者。知识不是静态文档而是流动的血液。5. 常见问题与排查技巧实录那些文档里永远不会写的真相5.1 “为什么我的架构图总被质疑”——暴露隐藏假设的致命陷阱新人常困惑明明画了完美的微服务架构图为什么架构师总说“太理想化”问题往往出在隐藏假设上。比如这张图[API Gateway] → [Auth Service] → [Order Service] → [Inventory Service]表面看很合理但隐藏了三个致命假设假设Auth Service永远可用实际它依赖RedisRedis挂了整个链路就断假设Order Service和Inventory Service网络延迟稳定实际跨机房调用P99延迟可能达800ms假设Inventory Service能实时返回库存实际它可能走异步扣减返回的是“预占成功”在这份notes里每张架构图都强制标注假设清单。例如上面的图会加注Assumption 1: Auth Service SLA ≥ 99.95% (based on last 30 days monitoring)Assumption 2: Inter-AZ latency ≤ 50ms (verified by ping mesh test)Assumption 3: Inventory Service supports synchronous reserve with timeout200ms (see /decisions/inventory-sync-reserve.md)提示当你被问“这个设计有什么风险”不要回答“可能有性能问题”而要说“我的设计依赖Assumption 2如果跨AZ延迟超过50ms订单创建P99将恶化至1200ms建议增加本地缓存兜底”。5.2 “压测数据为什么和线上不符”——环境差异的魔鬼细节压测报告显示QPS 10万线上却撑不住5万。我帮12个团队排查过90%的根因是环境差异。常见陷阱数据分布偏差压测用随机生成的100万用户ID但线上80%流量来自TOP 1000用户头部效应。解决方案用线上真实流量采样生成压测数据集用Flink实时聚合用户行为序列。网络拓扑失真压测机和服务器在同一内网但线上用户通过CDN、WAF、LB多层转发。解决方案在压测机上用tc命令模拟网络延迟tc qdisc add dev eth0 root netem delay 50ms 10ms和丢包tc qdisc add dev eth0 root netem loss 0.1%。JVM参数误导压测用-Xmx4g但线上用-Xmx8g结果GC策略完全不同。解决方案压测必须用线上完全一致的JVM参数并开启GC日志-Xloggc:/var/log/app/gc.log -XX:PrintGCDetails。实操心得我们现在的压测报告第一张图永远是“环境对比表”明确列出压测环境与生产环境的每一处差异并标注“是否已补偿”。没有这张表压测报告无效。5.3 “监控告警为什么总误报”——从阈值设定到噪声过滤的全流程告警不是设个阈值就完事。我统计过团队平均每天收到127条告警其中83%是误报。根源在于阈值设定缺乏上下文。比如“CPU使用率90%告警”但没说明是瞬时峰值还是持续5分钟是单核还是平均是否考虑了业务低谷期凌晨2点CPU 95%可能是定时任务不是故障在这份notes里告警规则必须包含四层过滤基础阈值CPU 90% for 5 minutesPrometheus表达式100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 90业务上下文排除定时任务窗口and on(instance) (hour() 2 and hour() 4)关联抑制当MySQL主从延迟10s时抑制所有应用层DB错误告警避免告警风暴动态基线对QPS类指标用Prometheus的predict_linear()函数预测未来1小时趋势偏离基线2个标准差才告警注意所有告警必须附带“一键诊断”脚本。比如CPU告警触发时自动执行top -b -n 1 | head -20并发送到钉钉省去人工登录排查时间。5.4 “技术选型为什么总是后悔”——用决策矩阵替代主观偏好选型争论常陷入“Kafka好还是Pulsar好”的口水战。我们用决策矩阵终结争论。以消息队列选型为例矩阵包含7个维度每个维度按1-5分打分维度KafkaPulsarRabbitMQ权重加权分社区成熟度54520%Kafka:1.0, Pulsar:0.8, RabbitMQ:1.0运维复杂度34525%Kafka:0.75, Pulsar:1.0, RabbitMQ:1.25事务支持24315%...总分3.84.13.9关键在权重设定由CTO、运维负责人、核心开发共同投票权重反映真实业务诉求。比如我们电商场景运维复杂度权重25%因DBA只有2人而社区成熟度权重20%因Kafka生态工具链完善。最终Pulsar总分最高但团队投票决定选Kafka——因为现有监控体系深度集成Kafka切换成本过高。这个过程不是选“最好”的技术而是选“最适合当下”的技术。6. 个人实践体会这份notes如何改变了我的工作方式我最初做这份notes纯粹是为了应付晋升答辩。但坚持两年后发现它彻底重塑了我的工程思维。以前开会我习惯说“我觉得应该用Redis”现在会说“根据notes第3.2条我们上次在订单服务用Redis缓存P99延迟从420ms降到86ms但内存占用增加了37%这次用户中心服务QPS更低建议沿用相同策略”。语言变了背后是思考方式的进化从依赖经验直觉转向依赖可验证的数据决策。最意外的收获是知识传承效率的质变。以前带新人要花两周时间口述各种设计权衡现在直接发他notes链接让他读完/decisions/20230515-user-center-split.md再让他针对当前需求提三个问题。90%的新人都能在2小时内提出有深度的问题比如“为什么当时没选GraphQL是不是因为前端团队技术栈限制”——这说明他不仅看了结论还理解了决策背后的约束条件。最后分享一个小技巧我把notes里所有“已验证有效”的方案打包成/recipes文件夹每个recipe都是一个可运行的代码片段。比如/recipes/circuit-breaker-spring-boot里不仅有Hystrix配置还有完整的JUnit测试用例证明熔断器在连续5次失败后确实触发。新人不用从零造轮子复制粘贴就能跑通。技术传播的终极形态不是讲道理而是给工具。这份notes永远不会“完成”它只是我们团队认知边界的实时快照。每次线上故障、每次压测突破、每次架构演进都在为它注入新的像素。它不承诺给你标准答案但保证给你一个可追溯、可验证、可迭代的思考脚手架——而这正是系统设计最本质的尊严。