【系统设计（1）】系统设计入门方法论

文章目录零、 系统设计四步法概览 (Overview)1. 确定问题范围 (Understand Scope) —— 3-10 分钟2. 总体设计 (High-Level Design) —— 10-15 分钟3. 细节设计 (Deep Dive) —— 10-25 分钟4. 总结 (Wrap up) —— 3-5 分钟第一步、理解问题与确定边界 (Understand Scope)1、提问与澄清挖掘出功能与非功能需求2、 估算规模三个核心估算维度流量、存储、带宽第二步高层架构设计 (High-Level Design)1、 如何培养“勾勒蓝图”的能力架构模式与对数据流的敏感度1.1、 储备标准组件库 (The Toolbox)2.2、 掌握经典架构模式 (Architecture Patterns)快速匹配场景2.3、 数据流驱动思维 (Data Flow Driven)数据流决定了架构设计2、 核心组件图第三步深入设计与难点攻克 (Deep Dive)1、 难点一如何防止超卖2、 难点二如何扛住 100万 QPS第四步总结与扩展 (Wrap up)4.1 系统瓶颈4.2 扩展思考总结系统设计万能公式核心思想系统设计不是“背诵架构图”而是从模糊需求到具体方案的推导过程。本文以秒杀系统为例带你走一遍系统设计的标准 4 步流程。零、 系统设计四步法概览 (Overview)系统设计通常遵循“四步法”确定问题范围 → 总体设计 → 细节设计 → 总结。这套框架构成了从“搞清楚要做什么”到“把怎么做写出来”的完整闭环既保证思考的系统性也为后续实现、运维和进一步优化奠定基础。1. 确定问题范围 (Understand Scope) —— 3-10 分钟先与面试官或业务方对话澄清需求、约束与预期规模把模糊命题转化为可度量目标。这样可以避免后续做无用功也能让所有后续设计决策有明确坐标系。关键动作封底估算 (Back-of-the-envelope Estimation)。用少量假设快速判断流量、存储等核心指标是否可行如果连最粗略的数字都通不过后面细节再精巧也无意义。2. 总体设计 (High-Level Design) —— 10-15 分钟基于已确认的范围勾勒高层级蓝图明确客户端、API 网关、负载均衡、缓存、数据库、消息队列等关键组件如何连接以及数据与控制流的方向。这一步相当于在“纸上”做一次快速原型把系统骨架搭起来。获得反馈后才能知道是否需要调整架构思路。3. 细节设计 (Deep Dive) —— 10-25 分钟对关键组件深入如写入路径的一致性模型、读取路径的缓存策略、分区处理等。针对性能、可靠性、成本做更精确的估算和方案比选同时也回答面试官可能提出的“如果流量再大怎么办、机器挂了怎么办”之类追问。此阶段会把接口、数据结构、错误处理、监控告警等细节补齐使设计真正可落地。4. 总结 (Wrap up) —— 3-5 分钟回顾整个设计核心决策、主要权衡如 CAP 选择、一致性 vs. 可用性、尚未解决的瓶颈。明确下一步验证或迭代方向为面试收尾或进入编码阶段做准备。四步的原因逐步收敛从“问题模糊”到“代码可写”分阶段不断缩小未知区域降低一次性决策错误的风险。管理复杂度把一个开放且庞大的题目拆成小块每块可独立思考、并行讨论避免大脑过载。便于沟通每完成一步都与面试官对齐可及时纠正方向展示结构化思考与协作能力。兼顾时间效率早期估算和高层级框图帮助快速判断可行性避免在细节上浪费过多时间。第一步、理解问题与确定边界 (Understand Scope)不要急着画图先搞清楚“我们要解决什么问题”以及“系统的规模有多大”。1、提问与澄清挖掘出功能与非功能需求面试官或业务方给出的需求通常很模糊例如“设计一个秒杀系统”。你需要通过提问来圈定范围。如果你对系统不熟悉大脑一片空白不要慌。最简单的方法是代入用户视角走一遍核心流程 (User Journey)。你“我理解这个系统的核心场景是用户打开 App浏览商品列表然后点击购买。请问我们需要覆盖全流程吗还是只关注下单这一步” 这样你就把“功能范围”的球踢回给了面试官同时展示了你对业务流程的理解。此外可以从 CRUD 角度通过资源来联想 “这个系统的核心资源是‘商品’。那除了‘读商品’和‘买商品’我们需要考虑商家的‘发布商品’吗”示例对话问功能 (Functional)你我们需要做秒杀商品的管理后台吗还是只关注用户抢购的前端流程业务只关注用户抢购流程浏览 - 下单 - 扣库存。你需要支持购物车吗业务不需要秒杀通常是立即购买。问非功能 (Non-Functional)你系统需要多高的可用性允许数据丢失吗业务必须高可用绝对不允许超卖数据一致性是核心。2、 估算规模三个核心估算维度流量、存储、带宽规模决定技术选型。不要试图计算每一个字节而是要关注数量级通常我们需要关注以下 3 个核心维度维度详细说明流量 (Traffic)•DAU/MAU日活/月活用户数。•QPS (Queries Per Second)平均 QPS 和 峰值 QPS (通常是平均的 2-5 倍)。•读写比 (Read/Write Ratio)决定是读多写少用缓存加速访问还是写多读少用 MQ用队列控制写入速度。存储 (Storage)•总量需要存多少数据(1TB vs 1PB)•增长量每天新增多少保留多久带宽 (Bandwidth)• 如果有图片/视频上传下载需要评估网络带宽瓶颈。•计算公式带宽 Q P S × 平均包大小 带宽 QPS \times 平均包大小带宽QPS×平均包大小•示例 (Instagram)假设每秒上传 50 张照片每张 2MB。50 × 2 M B 100 M B / s 50 \times 2MB 100MB/s50×2MB100MB/s。注意这是字节(Byte)换算成网络带宽(bit)通常要乘以 8即 800Mbps。•结论这通常需要 CDN 或对象存储分流不能直接打到 Web 服务器。 通俗理解 CDN (快递驿站模型)没有 CDN所有用户都要去唯一的**总仓库Web 服务器**取货。路途远延迟高且仓库门口容易堵死带宽耗尽。有了 CDN总仓库把货物图片/视频提前发到各地的驿站边缘节点。用户直接去家门口取货速度快且不占总仓库的门路。示例秒杀系统估算用户量假设 1000 万人参与。QPS (每秒查询率)假设活动开始瞬间10% 的用户刷新页面1000 万 × 10 % 100 万 1000万 \times 10\% 100万1000万×10%100万QPS。结论单机数据库MySQL只能抗几千 QPS必须用缓存Redis。库存量只有 100 个 iPhone。结论写请求下单只有 100 个是有效的其余 99.99% 都是无效流量必须在上游拦截。第二步高层架构设计 (High-Level Design)画出系统的宏观蓝图确定核心组件及其交互关系。1、 如何培养“勾勒蓝图”的能力架构模式与对数据流的敏感度很多同学会问“我知道要画图但我怎么知道该画哪些组件怎么知道该把 Redis 放在哪里”这其实考察的是架构模式的储备和数据流的敏感度。要具备这种能力你需要建立以下思维模型1.1、 储备标准组件库 (The Toolbox)建立心中的“乐高积木盒”。遇到需求时如“存数据”、“抗高并发”能迅速条件反射出对应的组件而不是大脑一片空白。熟悉这些标准件的适用场景和优缺点是画出架构图的前提。一、计算 (Compute)也就是我们写的后端代码运行的地方。Web Server (无状态)处理 HTTP 请求不存数据随时可以扩缩容 (Horizontal Scaling)。Worker (异步任务 / 离线任务)也就是常说的Background Jobs。通俗解释Web Server 像是前台服务员负责接待客户必须秒回同步Worker 像是后厨或工厂负责处理耗时的脏活累活异步。场景用户点击“导出报表”。Web Server 只是记下来“好收到了”然后返回“处理中”。Worker 慢慢从 MQ 里拿出任务花 5 分钟生成 Excel最后发邮件给用户。FaaS (Serverless)如 AWS Lambda。适合短时、突发任务如图片上传后自动压缩。二、存储 (Storage)数据到底放哪关系型数据库 (MySQL/PostgreSQL)可信赖的账本。存用户资料、订单、资金流水。必须保证 ACID 事务哪怕慢一点。缓存 (Redis/Memcached)临时记事本。存热点数据如热门商品详情读写极快内存但断电可能丢且容量有限。NoSQL/文档型 (MongoDB/DynamoDB)灵活的档案袋。存商品属性、评论、日志。Schema 灵活不用预先建表写入吞吐高。搜索引擎 (Elasticsearch)全文检索目录。专门做复杂的搜索和筛选如电商搜商品、日志搜错误。对象存储 (S3/OSS)无限大硬盘。存图片、视频、备份文件。便宜且容量无限但不能像数据库那样修改内容通常是覆盖上传。三、网络/分发CDN (静态资源加速)通常搭配对象存储使用。实现阿里云 CDN / AWS CloudFront OSS / S3。用户上传图片到 OSS自动同步到 CDN 边缘节点。DNS (域名解析)实现Route53 / Cloudflare。支持“地理位置路由 (GeoDNS)”让北京用户解析到北京机房 IP。四、通信 (Communication)如何让组件说话取决于你需要多快、多紧密。通信类型具体实现说明 场景同步调用 (Request/Response)HTTP (REST/GraphQL)最通用兼容性好。场景外部 API、前后端交互、简单服务间调用。RPC (gRPC/Thrift)高性能强类型约束节省流量二进制。场景微服务内部的高频调用。异步解耦 (Async/Decoupling)Message Queue (Kafka/RabbitMQ)场景削峰填谷秒杀流量缓冲、解耦下单成功后触发积分/发货/通知、最终一致性事务。实时推送 (Real-time)WebSocket双向持久连接。场景聊天室、即时游戏、协同编辑。注意WebSocket是协议类似 HTTP而Netty是 Java 中用来实现这个协议的高性能框架工具。SSE (Server-Sent Events)服务端单向推送。场景股票行情、站内信通知、大模型流式输出。五、控制 (Control)系统的神经中枢。Gateway (网关)系统的唯一入口保安/前台。功能身份认证 (Auth)、限流 (Rate Limiting)、路由转发、协议转换 (HTTP - RPC)。选型Nginx(高性能反向代理),Spring Cloud Gateway(Java生态),Kong/APISIX(云原生).Service Discovery Config (注册中心/配置)系统的通讯录和公告栏。功能服务 A 找服务 B 的 IP (服务发现)不重启修改降级开关 (动态配置)。选型Zookeeper(老牌强一致),Etcd(K8s标配),Nacos(阿里系, 国内流行).2.2、 掌握经典架构模式 (Architecture Patterns)快速匹配场景架构设计不是“发明创造”而是“模式匹配”。90% 的业务场景如电商、社交、直播在业界都已经有成熟的、经过验证的解决方案。直接套用这些模式能极大地降低设计出错的风险并节省时间去处理真正的业务细节。你需要先识别出你的业务属于哪类场景然后调出对应的“模板”进行微调场景典型例子设计套路 核心架构链路读多写少微博热搜电商首页知乎文章Cache-Aside 多级缓存核心保护数据库架构Client - CDN - Nginx - App Server -Redis- DB写多读少日志收集埋点上报物联网传感器削峰填谷 批量写入核心别把数据库写死架构Client -Kafka- Worker (Batch) - DB / Elasticsearch实时通信微信聊天王者荣耀在线文档协作长连接 推送服务核心保持通道不断架构Client -WebSocket Gateway- Connection Manager - Logic Server2.3、 数据流驱动思维 (Data Flow Driven)数据流决定了架构设计做架构设计时不要先凭空去想要用哪些组件、怎么画架构图而是要跟着数据和请求的流转过程去思考。你可以这样梳理一个完整请求入口用户请求先经过 DNS、CDN、Nginx读写读操作走缓存写操作走 DB 或 MQ计算业务逻辑交给后端服务处理下游通知需要异步处理时通过 MQ 转发给下游服务把这个请求从进入系统到最终处理完成的整条路径梳理清楚架构图自然就出来了。2、 核心组件图对于秒杀系统我们可以画出以下数据流用户网关/负载均衡秒杀服务Redis 缓存消息队列数据库为什么这么设计网关 (Gateway)用于拦截流量限流、黑名单保护后端。Redis 缓存因为估算出有 100万 QPSMySQL 扛不住所以读库存和扣库存必须在 Redis 进行。消息队列 (MQ)因为写请求下单可能有峰值数据库写入慢需要 MQ 来“削峰填谷”慢慢写入数据库。CDN 静态资源秒杀页面包含大量图片带宽估算巨大必须让用户从就近节点加载减少源站压力。服务隔离 (Isolation)秒杀流量太凶猛为了不把主站如购物车、订单查询搞挂通常将秒杀系统作为独立服务部署。第三步深入设计与难点攻克 (Deep Dive)挑选最棘手的问题展示你的技术深度。对于秒杀系统最棘手的是超卖和高并发。1、 难点一如何防止超卖业界通用的最佳实践是使用Redis Lua 脚本来实现高并发下的原子扣减。为什么不用数据库传统数据库如 MySQL的“查库存 - 改库存”在并发下会产生竞态条件导致超卖而使用乐观锁UPDATE ... WHERE num 0虽然能防超卖但高并发下会产生严重的锁竞争拖慢系统响应。Redis Lua 方案详解原子性保证Redis 会将 Lua 脚本作为一个整体执行中间绝不会插入其他命令。这相当于在内存中通过“单线程串行化”解决了并发竞争问题天然防止超卖。执行逻辑检查库存GET stock_id判断库存 0如果 0执行DECR stock_id并返回成功。如果 0直接返回失败。注意上述逻辑在 Lua 脚本中是一次性发给 Redis 执行的。异步落地Redis 扣减成功后立即返回前端“抢购成功”同时通过MQ (消息队列)异步将订单写入数据库实现最终一致性。2、 难点二如何扛住 100万 QPS动静分离秒杀页面HTML/CSS/JS是静态的推送到 CDN内容分发网络用户就近访问流量不打到服务器。只有“获取库存”、“下单”这两个接口打到服务器。漏斗模型 (Funneling)第1层 CDN拦截 90% 的静态资源请求。第2层 网关限流如每秒只放行 10万 请求拦截恶意刷单 IP。第3层 Redis库存扣完后直接返回“已抢光”拦截剩余请求。第4层 DB只有那 100 个抢到库存的请求才会真正写数据库。第四步总结与扩展 (Wrap up)回顾设计指出不足讨论未来优化方向。4.1 系统瓶颈Redis 挂了怎么办- 需要设计 Redis 主从高可用甚至多级缓存本地缓存 Redis。MQ 消息丢了怎么办- 导致库存扣了但没生成订单少卖。需要消息持久化和补偿机制对账。4.2 扩展思考如果不是秒杀而是普通的电商下单架构会有什么不同不需要极致的限流和 Lua 脚本更注重事务完整性。总结系统设计万能公式问搞清需求不要瞎猜。算算算 QPS决定要不要分布式/缓存。画画出大图确立组件。钻钻研难点高并发/一致性/安全。