文章目录引言系统设计为什么这么难一、从客户端到服务器请求是怎么走完一圈的二、数据的落地数据库与存储体系三、分布式系统的核心理念四、把这些概念串成一个系统设计思路引言系统设计为什么这么难对大多数开发者来说系统设计之所以难是因为一上来就面对「高并发」「分布式」「一致性」这些抽象概念却缺少一套清晰的核心积木。这篇文章把系统设计拆成 30 个关键概念只要把这些概念吃透再看面试题或真实架构图你就会有一条清晰的思路。一、从客户端到服务器请求是怎么走完一圈的客户端 - 服务器架构几乎所有 Web / App 应用本质都是「客户端-服务器」模型浏览器或移动端作为客户端发起请求后端服务器常驻在线处理请求并返回响应。客户端通常请求的是“存、取、改”数据服务器完成业务逻辑后把结果返回给客户端。问题在于客户端如何找到服务器靠的是下面一整套寻址与协议体系。IP 地址与 DNS服务器在互联网上都有一个唯一的 IP 地址相当于机器的电话号码数据包靠它“送货上门”。但人类不可能记一堆数字于是有了域名和 DNS浏览器输入域名后会先向 DNS 服务器查询对应 IP再用这个 IP 去连真正的服务端。你可以在终端用ping 域名快速看到当前解析到的 IP。代理与反向代理正向代理位于客户端与互联网之间替客户端转发请求可以隐藏客户端 IP起到隐私和访问控制作用。反向代理位于互联网与后端服务器之间所有外部请求先打到它再由它按规则转发到某个后端实例可做安全隔离、IP 隐匿以及负载均衡。延迟Latency与地理分布客户端和服务器之间总会有延迟其中物理距离是重要因素例如印度用户访问位于纽约的服务器数据需要跨洲往返一次。降低延迟的方法之一是把服务部署在多个区域的数据中心让用户连到最近的节点而不是跨半个地球。HTTP / HTTPS 协议浏览器和服务器之间使用 HTTP/HTTPS 这套规则交流请求包含头和可选的请求体服务器返回响应头和响应体。HTTP 明文传输存在安全风险因此现代应用普遍使用 HTTPS在其上通过 SSL/TLS 加密防止中途窃听或篡改。API 与 API 风格HTTP 只是传输通道真正定义“有哪些操作、参数怎么传、返回什么结构”的是 API。API 相当于一层抽象客户端只需要知道“我调这个接口就能拿到某种数据”。常见的两种风格是 REST 和 GraphQL它们面向的需求不同。REST APIREST 把一切当作「资源」如/users、/orders通过标准 HTTP 动词GET/POST/PUT/PATCH/DELETE对资源进行增删改查。它的特点是无状态、简单、易缓存但有时会导致「多请求」或「返回数据过多」的问题。GraphQLGraphQL 允许客户端精确声明自己需要哪些字段并且把原本要对多个 REST 端点发起的请求合并成一次查询返回。它可以显著减少冗余数据与往返次数但在服务器实现、权限控制以及缓存方面比 REST 更复杂。二、数据的落地数据库与存储体系数据库系统的“记忆”小量数据可以放内存但现代应用通常要持久化海量数据需要专门的数据库服务器来保证高效、安全、一致和持久。服务器在处理业务请求时会与数据库交互读写数据再把结果返回客户端。SQL 与 NoSQLSQL 数据库表结构固定模式严格强调 ACID原子性、一致性、隔离性、持久性适用于强一致和复杂关系场景如金融系统。NoSQL为可扩展性和高性能设计模式灵活包含键值、文档、图、宽列等多种模型更适合高并发、数据结构多变的业务。许多大型系统会“混搭”核心交易类逻辑用 SQL推荐、日志、会话等用 NoSQL。垂直扩容与水平扩容垂直扩容Scale Up给单台机器加 CPU、内存、磁盘见效快但有物理与成本上限而且易形成单点故障。水平扩容Scale Out增加更多机器一起分担负载提高容量与可用性成本更可控但需要配合负载均衡与分布式治理。负载均衡器负载均衡器位于客户端与后端集群之间相当于“交通警察”把请求按算法路由到某个健康实例。常见算法包括轮询、最少连接数、IP 哈希等既提高吞吐和利用率也增强容错能力。数据库索引索引类似书末的索引页为经常被查询的列建立额外的数据结构从而避免全表扫描加速读操作。索引能显著提升查询性能但会拖慢写操作并占用更多空间因此只应给高频查询列建索引。复制Replication通过一主多从/多副本结构把写操作集中在主库读操作分散到多个只读副本可极大缓解读压力并提升可用性。当主库故障时其中一个副本可以被提升为新的主库保证系统持续可用。分片Sharding当单库存储和吞吐到达极限时可按某个分片键如用户 ID把数据水平切成多个分片由不同数据库实例负责。这样每个实例只处理一部分数据与请求整体吞吐、读写性能都大幅提升。垂直拆分Vertical Partitioning如果问题在“列太多”而不是“行太多”可以按功能把宽表拆成多张窄表例如 User_Profile、User_Login、User_Billing 等。这样查询某一类信息时只扫描必要列减少 IO、加速响应。缓存Caching缓存把热点数据放在内存中如 Redis、Memcached大幅减少数据库压力和响应时间。典型模式是 Cache-Aside先查缓存命中则直接返回未命中则查库并回填缓存并通过 TTL 控制过期和刷新。反规范化Denormalization规范化把数据拆成多表减少冗余但读多写少的场景中过多 JOIN 会拖慢查询。反规范化通过合并表或冗余字段换取更快的读性能代价是存储变大、更新逻辑更复杂。三、分布式系统的核心理念CAP 定理与一致性选择在分布式系统中不可能同时完美满足一致性C、可用性A、分区容错性P三者只能在网络分区不可避免的前提下在 C 与 A 之间做权衡。典型 CP 系统更偏向强一致部分场景会拒绝请求AP 系统则偏向高可用可能短暂返回旧数据很多 NoSQL 会采用“最终一致性”。最终一致性Eventual Consistency更新先在某个副本上成功然后异步地传播到其他副本系统会尽快收敛到一致状态但在传播窗口期不同节点上看到的数据可能不一致。这样可以保证高可用与高吞吐适合对“瞬时不一致”容忍度较高的业务如社交 Feed、统计计数等。Blob 存储传统数据库并不擅长存储大文件图片、视频、PDF 等于是出现了对象/Blob 存储如 Amazon S3用来以极低成本和高可靠性存储海量非结构化文件。文件存于“桶 / 容器”中每个对象有唯一 URL可经由 REST API 或直链访问并自动跨机房冗余复制。CDN内容分发网络CDN 在全球部署大量边缘节点缓存静态内容HTML、CSS、JS、图片、视频让用户从离自己最近的节点获取资源而不是从远端源站拉取。这显著降低延迟和带宽压力是大规模内容分发场景的标配组件。WebSocket 与实时通信传统 HTTP 是“请求-响应”一次性连接要实现实时更新只能轮询浪费带宽和服务器资源。WebSocket 建立后保持长连接客户端与服务器可以双向推送消息非常适合聊天、行情、游戏等实时场景。四、把这些概念串成一个系统设计思路当你拿到一个系统设计题比如“设计一个短视频平台”大致可以按以下顺序思考并映射到上面的概念入口与协议客户端如何访问用 HTTP/HTTPS API是否需要 WebSocket 做实时寻址与边界域名、DNS、负载均衡、反向代理如何设计存储层哪些数据用 SQL哪些用 NoSQL是否需要分片、复制、索引、反规范化性能优化数据库瓶颈在哪里用缓存、CDN、垂直/水平扩容、Blob 存储来缓解。分布式权衡强一致 vs 最终一致更重视可用性还是一致性如何在 CAP 约束下做取舍一旦能自觉用这 30 个概念去拆和重构问题你就已经站在系统设计的“共同语言”之内了。