企业官网建设流程全解析

写一套能直接拿来用的 system design 笔记，是我做架构评审和面试准备这两件事交叉进行时，慢慢养成的习惯。最开始只是想整理自己的知识盲区，后来发现这套东西的用处远超预期：它既能让你在系统设计面试里从“卡壳边缘”拉到“有条理地说完”，也能让你回到日常工作时，面对“这个模块要不要加缓存”“消息队列用在哪儿合适”这类决定，不再拍脑袋。这篇文章就把我这套 system-design-notes 的核心框架、组件选型逻辑、一套完整的实操案例和踩坑记录一并摊开，希望对正在准备面试、或者想建立系统设计知识体系的同学有帮助。

系统设计这个词看起来很大，但其实拆开来看，就那么几件事：先搞清楚你要解决什么问题，再估算这个问题大概多大，然后决定用哪些组件拼出方案，最后把方案讲得别人能听懂、能落地。这四步中的每一步都有套路可循，也有坑可踩。我的笔记一开始是东一篇西一篇记录，后来迭代成了“方法论 + 组件库 + 案例库”的结构，这次就把这部分内容完整梳理一遍，尽量讲透，不讲废话。

1. 项目概述：为什么系统设计值得单独建一份笔记

1.1 这套笔记解决的核心问题

系统设计和写业务代码完全是两种思考方式。写业务代码的时候，你面对的是明确的需求和现成的框架，大方向早就定好了，你负责把每个接口、每个状态流转写对就行。系统设计不同，它给你的往往就是一句很抽象的话，比如“设计一个短链接服务”“设计一个打车派单系统”，既没有明确的接口定义，也没有指定的技术栈。你需要在几十分钟内，从零到一把一个可扩展、可维护、能落地的架构方案拿出来，还要给出一套能说服人的理由。

我见过太多基础不错的同学栽在系统设计上，不是因为他们不懂技术，而是因为他们不知道从哪开口。有人上来就画架构图，画到一半发现漏了关键组件；有人一上来就聊具体技术细节，结果面试官问他“这个方案要支撑多大流量”的时候愣住了。这些问题的根源不是能力不够，而是缺少一套结构化的设计流程。我这份笔记的首要价值，就是把“系统设计到底应该按照什么顺序做”这件事固定下来，让你在不同题目之间能复制的不是答案本身，而是思考的路径。

1.2 为什么系统设计面试和日常开发都离不开组件决策

系统设计面试很少要求你发明新东西，绝大多数题目考的都是现有成熟组件的组合能力。负载均衡怎么选、缓存放在哪一层、消息队列是解耦还是削峰、数据库到底该用关系型还是非关系型，这些决策在真实的分布式系统里每天都在发生，面试只是把它们压缩到一个小时之内。所以你会发现，准备系统设计面试的过程，本质上就是在为自己建立一套高密度的技术决策知识库，而这套知识库在平时做方案评审、做性能优化的时候，一样能派上大用场。

我的笔记就是把这么散落的组件决策逻辑，整理成了一份可以反复翻阅的资料。

1.3 这份笔记适合谁看

我把这份笔记的使用场景总结成三句话：准备高端岗位面试的人拿它当备赛手册；刚入行两三年、开始接触模块设计的工程师拿它当知识框架；带小团队、需要经常做技术决策的人拿它当自查清单。如果你正处在任意一个阶段，这套内容都能给你提供一套可以落地的思路。如果你只是想了解一下大厂的高并发系统是怎么设计的，顺着这套框架读下来，也能建立比较完整的认知。

它不是一份单纯记录“是什么”的资料，核心在于教你“怎么做”以及“为什么要这样做”。所以不管你是为了面试突击，还是想补上系统设计这块短板，这套笔记的学习成本都算低的，但收益周期很长。

2. 方法论拆解：系统设计的五步设计法

2.1 需求澄清：先把问题定准，再谈方案

几乎每一次我帮别人模拟面试，都会反复强调同一句话：不要跳过需求澄清阶段的。这不是套话，而是系统设计最关键的兜底动作。面试官抛出来的题目往往很宽泛，宽到“设计一个XX系统”本身没有意义，你必须通过提问把它收敛成一个可设计的问题。我会建议从四个维度去问：一是核心功能，也就是用户能做什么；二是非功能需求，也就是我们关心的QPS、延迟、可用性指标；三是数据规模，包括存量数据和增长趋势；四是约束条件，比如团队规模、成本、部署环境的限制。

举个具体的例子，如果题目是设计短链接服务，你需要确认的问题大致是：生成和跳转这两个接口哪个是核心？跳转的平均延迟要求是多少？预计每天新增多少条短链？要不要支持自定义短链？需不需要统计点击次数？这些问题问完，设计目标就已经清楚一半了。面试官并不会因为你问问题觉得你水平低，恰恰相反，会问问题说明你在有意识地控制设计范围，而不是一头扎进方案里。

2.2 容量估算：用一张纸算清楚系统要扛多少压力

容量估算是很多人的薄弱环节，因为它涉及一堆数字，而数字是最能暴露思路不清晰的地方。但容量估算其实不需要很高深的数学知识，核心就两个动作：先设定一个用户规模基数，再做一下单位换算。我一直用的参考基数是日活跃用户数（DAU），比如假设DAU是1亿，平均每个用户每天使用系统10次，那一天的请求总量就是10亿；如果这些请求集中在4个小时的有效时间窗口内，那每秒大概是10亿除以14400秒，约等于7万QPS。不要小看这种粗糙的估算，它能帮你在设计的第一分钟就建立一个量级概念。

有了量级概念之后，系统设计的很多决策就开始自动浮出水面了：单机QPS撑到1万都算不错，所以如果估算出来是7万QPS，你就知道必须要做集群化、负载均衡和缓存；如果估算出来只有几百QPS，那很多复杂的架构根本没必要上，单体应用加一个读写分离可能就够用了。容量估算的最大价值不是精确，而是帮你判断复杂度的温度——它高还是低，决定了你接下来要做的是减配还是加码。

2.3 接口设计与数据模型：先定义契约还是先画架构

我见过不少同学一上来就画整个系统架构的框图，把网关、微服务、集群全画出来，看起来很完整，但面试官追问一句“那你的核心接口长什么样”，就马上露怯。我更习惯的顺序是先定义核心接口，再设计数据模型，最后才是整体架构图。接口是系统对外的契约，它决定了你能响应什么，数据模型决定了系统能不能高效地支撑这个响应。这两件事没定下来，架构图画得再漂亮也是空中楼阁。

接口设计时，要抓住最核心的两个场景，不要贪多。继续以短链接服务为例，核心接口其实就两个：一个是生成短链的接口，入参是原始URL，出参是短码；另一个是跳转的接口，入参是短码，出参是一次302重定向到原始URL。数据模型上，短链映射表需要一个自增ID、一个短码字段、一个原始URL字段、一个创建时间字段，再加一个过期时间字段。就这么一张表，已经能支撑起整个服务的核心功能了。先把这个最小闭环定义清楚，后面再谈扩展就顺理成章。

2.4 从方案到表达：设计好的系统也要讲得好

说一个比较容易被忽略的点：系统设计是做出来的，也是讲出来的。面试官在有限的时间里能接收到的信息总量是有限的，你的表达结构直接决定了他对你的评价。我的经验是，方案表达也要结构化：先一句话说明整体思路，再用容量估算的数据作为决策依据，然后分模块说清楚关键组件的作用，最后抛出一个可以讨论的取舍点或者演进方向。这样给面试官的感觉是，你不但能把方案做出来，还能把方案讲清楚，这在真实的架构评审中是比技术本身更稀缺的能力。

实际说话的节奏上，每个模块都遵循“设计目标→技术选型→关键机制”的结构，不要在一个细节上纠缠太久。记得有一次模拟面试，一个同学设计了一个很完整的Feed流系统，但他的表达方式是平铺直叙地介绍每个组件，讲完负载均衡讲MySQL，讲完MySQL讲Redis，面试官全程没有听到一次“我这个方案的目标是什么”。这种表达方式会极大削弱方案的冲击力。我笔记里专门记了一条：每次开口讲设计之前，先说明你在解决什么问题，再谈你怎么解决。

3. 核心组件选型：高并发场景的四件套

3.1 负载均衡：流量入口的第一道闸门

流量只要稍微大一点，负载均衡就是绕不开的组件。它的职责很简单：把请求分发到多台后端服务器上，让每个节点都能稳定地扛住自己的份额，同时在一台机器挂掉的时候能自动把流量摘除。选型上，L4的负载均衡（如LVS）工作在传输层，转发效率极高，但只能基于IP和端口做分发；L7的负载均衡（如Nginx、HAProxy）工作在应用层，可以按URL、Header、Cookie做更细粒度的分发，多用于HTTP和HTTPS流量的治理。

分发算法上，最基础的Round Robin轮询适合各后端性能相近的场景；Weighted Round Robin适合后端机器规格不同、需要按权重分配的场景；Least Connections适合请求处理时长差异比较大的场景；IP Hash能保证同一IP的请求总是落到同一台机器，适合需要会话保持的服务。我这里会记一个经验：不要迷信某个算法的独特性，大多数系统里，带权重的最少连接算法（Weighted Least Connections）已经能解决90%的问题。

3.2 缓存层：为什么说缓存是性能的第一解药

缓存的本质是用一份额外的存储空间，去换一次网络或数据库访问的开销。加缓存需要考虑的是四个问题：缓存什么、缓存多久、放在哪里、缓存失效了怎么办。最常见的选择是把热点数据缓存到Redis这类内存型存储中，设置了过期时间，用LRU或LFU这样的淘汰策略来限制缓存大小。但加了缓存之后，所有技术人都应该警惕的三个经典问题是：缓存穿透、缓存击穿、缓存雪崩。

穿透说白了就是缓存和数据库里都没有这条数据，请求每次都直接打到数据库上，等于缓存白加了。应对办法是布隆过滤器或者缓存空值。击穿是指一个热点key的缓存突然失效，瞬时大量请求直接命中数据库。应对办法是热点key不过期，或者用互斥锁重建缓存。雪崩是指大量缓存key在同一个时间点失效，数据库短时间内压力陡增。应对办法是把过期时间打散，加一个随机值避免集体失效。在设计时遇到过这几个问题，才能说缓存这层你真的想清楚了。

3.3 消息队列：解耦、削峰、异步，但别乱用

消息队列在系统设计里出现频率很高，但我一直提醒大家：消息队列不是不要钱的面包，它带来了解耦，也引入了复杂性。它的经典使用场景有三个：一是解耦，上游只管发消息，下游自己去订阅，两边互不依赖；二是削峰，面对突刺型的高流量，先把消息放进队列，让下游消费者按照自己的节奏处理；三是异步化，比如用户下单之后，先把订单状态写成功，再异步发送短信通知，这样用户体感更快。

选型上，具体技术选型因场景差异而不同。延迟要求极高的即时消息场景和需要持久化和顺序消息保障的场景，选择的队列是完全不同的。设计时，关键要讲清楚的是消费模型和异常处理：如果消费者挂了，消息在队列里积压怎么办？如果消费成功但确认消息丢失怎么办？这些问题比“用什么消息队列”更能体现设计的成熟度。我笔记里有一条提醒：只有当你真正需要解耦、削峰或异步时才引入消息队列，否则用同步调用更简单可靠。

3.4 数据库选型：关系型与NoSQL的边界在哪里

数据库选型是系统设计里最需要功底的部分之一。我的判断标准通常基于数据关系和访问模式。如果数据之间有复杂的关系，需要事务支持，有大量按条件查询的需求，那关系型数据库（如MySQL、PostgreSQL）是首选；如果数据量大、访问模式比较固定（key-value按ID查询居多），且不太需要跨表关联时，NoSQL（如Redis、MongoDB、Cassandra）往往更合适。我把这个决策逻辑做成了一张速查表：

这里面有一个容易被忽略的点：数据库选型从来不是非黑即白，很多系统是混合使用的。比如核心订单数据落在MySQL，热点商品信息放在Redis，用户行为日志存入Elasticsearch。方案优雅与否，取决于你有没有为每种数据选择最合适的载体。

4. 案例实战：从零设计一个短链接服务

4.1 第一步：明确需求与估算规模

我们拿短链接服务这个经典题目，把前面那套方法论完整走一遍。假设面试官只说了一句“设计一个短链接系统”，你需要先問清楚需求。确认核心功能有两个：把一个长URL压缩成短URL；用户访问短URL时302跳转到原网址。再确认非功能需求：跳转延迟要低于100毫秒；预估日新增短链100万条；系统运行三年后，短链总量约10亿条；跳转请求的峰值QPS约5万。

拿到这些数字之后，容量估算就很清晰了。10亿条短链的映射关系，对应关系型数据库里大概需要几十GB的存储空间，完全可以通过MySQL单库+缓存支撑。5万QPS的跳转请求，如果全部打到数据库上，单库完全扛不住，但在Redis缓存命中率90%以上的前提下，打到数据库的量只有5000QPS，分库分表之前，单主库加从库集群已经可以稳稳扛住。这套数字立刻告诉我们：这个系统不需要过于复杂的架构，但缓存层是必须的。

4.2 第二步：设计API与数据模型，先画最小闭环

接口设计紧扣两个核心场景。生成短链的接口收到长URL后生成唯一短码返回；跳转接口在收到短码后查到原始URL并302重定向。这两个接口本身很简单，但生成短码的方案可以展开很多讨论。我比较推荐的做法是使用全局发号器（比如数据库自增ID或者分布式ID生成器），拿到十进制ID之后转换为62进制字符串作为短码。5位62进制能表示9亿个组合，6位能表示560亿，对当前数据规模来说，6位短码是合适的选择。

数据模型上，一张短链映射表就够：自增ID是唯一标识，短码列建立唯一索引，原始URL列存储长链接，创建时间和过期时间列分别记录生成时间和有效期。核心跳转链路是：用户请求短码，先查Redis缓存，如果有则直接返回长URL；如果缓存没命中，再查数据库，返回长URL并把结果写回缓存；如果数据库也没有，则返回404。这条链路虽然简单，但它囊括了缓存、存储、回源写入三个关键操作，是整套系统的主心骨。

4.3 第三步：扩展性演进，从单机到集群的平滑过渡

任何系统都不是一天长大的，短链接服务也不例外。这套设计的好处是它留好了扩展台阶。初期流量小的时候，单台Nginx加一台MySQL加一台Redis已经完全够用。当跳转QPS持续上涨，就把Nginx升级成负载均衡集群，后端多挂几台无状态的应用服务器，数据库做一主多从、读写分离，Redis从单机切换到哨兵集群模式。再往后，如果数据量接近单库瓶颈，可以用短码做分片键，把数据水平拆分到多个数据库实例里。

扩展过程中还有两个需要提前规划的细节：一个是发号器的高可用，因为发号器一旦挂掉，全链路的短码生成都会失败，所以生产环境要用带容灾的多节点发号方案；另一个是短码的过期与清理策略，长期不访问的短码要有巡检删除机制，避免无效数据持续占用缓存和数据库空间。把这些演进路径想清楚，面试官看到的就不再只是一个静态草图，而是一个有生命力、能随着流量一起成长的设计。

5. 实操中的常见问题与排查技巧

5.1 五个让我栽过跟头的设计误区

第一个误区是过度设计。一个只有几千QPS的系统，上来就上微服务、上分布式事务，这不仅是浪费，还会让系统复杂到无人能维护。第二个误区是忽略缓存一致性。加了缓存之后，数据库更新了但缓存还是旧值，导致用户读到过期数据。这个问题在设计阶段就要给出方案，比如先更新数据库再删除缓存，或者使用带版本号的双删策略。第三个误区是低估数据量。有的设计看上去很完美，但把数据增长算进去之后，存储方案和索引设计都需要推翻重来。第四个误区是忘记可用性设计，只关心正常流程，不关心流量高峰、机房故障、网络抖动时的表现。第五个误区是表达没有重点，把大量时间花在细节上，反而让主要决策淹没在信息里。

5.2 拿什么工具验证你的设计是否靠谱

设计做完之后，我习惯用三个视角来复盘。第一是用容量数据来反推：如果我现在把QPS提升十倍，每个环节会不会出现瓶颈？瓶颈会最先出现在哪里？第二是用故障模拟来排查：假如缓存集群整体挂了，数据库能扛多久？假如消息队列积压了十万条，会不会影响核心链路？第三是用扩展性视角审视：如果业务方要求新增一个功能模块，现有架构要不要伤筋动骨？这三个问题回答得越流畅，方案的质量就越有保障。

日常积累的时候，我也会关注一些公开的技术博客和大厂架构分享，用来补充自己的组件库。但我的经验是，不要贪多，不要追求面面俱到，每个组件记住三件事就行：它解决什么问题、它的核心机制、它的局限性是什么。记住这三件事，你在设计时就能做出比“我知道这个名词”更靠谱的决策。

5.3 笔记怎么用才能发挥最大价值

最后说点实际的。system-design-notes这类内容，不是读过一遍就完事的。我自己的做法是，每个周末挑一个经典题目（短链接、Feed流、秒杀系统、聊天系统、网盘系统），按照这套方法论完整走一遍设计流程，然后对照笔记找差异。一开始你可能需要两个小时才能走完一个题目，但练到第五个、第六个，你会明显感觉到自己的思考路径开始自动化了——需求问完，容量估算完，脑子里自动开始排组件出场顺序。这个感觉一旦出现，你离掌握系统设计就不远了。

我在实际使用中还有一个体会：设计系统的时候，不要追求让每个部分都完美，那是做不到的。真正好的系统设计，是在一堆约束条件里找到那个“够用、可扩展、可维护”的平衡点，然后明确说出“我在这里做了什么取舍，为什么这样取舍”。能把这个逻辑表达清楚，不管是面试还是真实项目，你都已经赢过了大多数人。

最后再分享一个我个人的小技巧：把每次设计练习画在一张A4纸上，画完拍照存进自己的笔记库里，过两周再看一遍。你一定会发现，当初觉得无懈可击的方案，其实有不少可以改进的地方。这种回看和迭代，才是让系统设计能力真正沉淀下来、不断成长的方式。