用信封背面算清Facebook：系统设计的起点不是画图

“一台服务器能扛住这些请求吗？”——在设计 Facebook、WhatsApp、Netflix、亚马逊或者 Instagram 这种量级的系统时，这个问题总是最先被甩到桌面上。紧接着还有一连串追问：到底要多少存储？缓存该不该上？缓存内存得配多大？最终要部署多少台机器？在还未触及数据库选型、负载均衡策略、微服务拆分甚至缓存层厚度之前，我们急需一个能快速锚定量级的粗糙答案。这就是信封背面计算（Back-of-the-Envelope Calculation）的用武之地。

很多人一接到系统设计任务，就下意识地开始画架构图：最上边是负载均衡器，往下连应用服务器集群，旁边再挂一个 Redis 缓存层，底部摆上数据库。那副图看起来工整又经典，但如果你并不清楚系统要承载多大流量、每秒钟会涌入多少次读写，这幅图就和盲画没什么两样。系统设计的本质是在无数约束中做权衡，而要想明智地权衡，首先得有估算数字——哪怕它们只是一个数量级的近似。信封背面计算就是用来回答这些问题的：系统会承受多少流量？会生成多少数据？缓存内存需要多大？又要动用多少服务器？数字不需要完美，只要足够逼近真实，就足以支撑架构决策。

信封背面计算究竟是一种什么手法？它是一套快速估算的思维习惯，利用一些常识性的假设，对流量、存储、内存和服务器能力进行数量级上的逼近。它的精髓不是追求精确到个位数的结果，而是保证你的答案恰好落在正确的数量级上——“抓准量级”远比“算对个位数”重要得多。在系统设计的面试场景里，面试官从来不会期待你掏出一个分毫不差的数字，他们想看到的，是你能否基于合理假设给出令人信服的估算，从而为后续的架构讨论搭建一个可靠的起点。

既然估算要先于设计，那就需要遵循一套固定的推演顺序。当你拿到一个系统设计题目，请先按住自己想画图的手，从用户开始，一层层往下推算：用户规模 → 流量 → 存储 → 内存/缓存大小 → 服务器数量 → 最后才是架构设计。永远记住：先估后画，而不是对着空白的架构图发呆。只要顺着这个顺序摸索下去，你总能把模糊的需求转化成一组看得见、摸得着的硬件边界。

在做这类估算时，有几个领域的基本常识要烂熟于心，比如存储单位、时间单位，还有一些面试中反复出现的常见假设数值。这些量级概念就像骑行的自行车，一旦掌握，往后再复杂的系统也能在短短几分钟内理出个头绪。这中间没有任何晦涩的理论，只是把 “8 比特等于 1 字节，1 KB 是 1024 字节，1 MB 是 1024 KB” 这种换算融进直觉，把 “一天有 86400 秒” 刻进条件反射，然后再记住几个粗略的吞吐量参照值就够了。

现在，让我们用一个完整的例子来演练一遍：假如你被要求设计 Facebook 的容量规划。第一步，先锚定用户规模。假设 Facebook 拥有 10 亿注册用户，这个假设定下来之后，立刻就要意识到不是每个注册用户每天都会活跃。通常可以假设每天的活跃用户占比为 20%，于是日活跃用户（DAU）就是 10 亿 × 20%，等于 2 亿。这就是我们后续所有流量推算的基数。

第二步，把用户行为翻译成流量。假设每位活跃用户每天平均打开 Facebook 10 次，那么全天的总请求次数就是 2 亿 × 10，等于 200 亿次请求。到了这一步，我们还需要把这个数字换算成系统设计里最常用的指标——每秒请求数（Requests Per Second, RPS）。全天有 86400 秒，那么平均 RPS 就是 200 亿除以 86400，约等于 23000 次/秒。这个平均数字让我们对常态负载有了概念，但它还不能直接用来配置服务器，因为流量从来都不会均匀地铺开。

系统设计之中必须考虑峰值流量的冲击，而一个常用的经验法则是：峰值流量大约是平均流量的 3 倍。因此，峰值 RPS 可以取 23000 乘以 3，大约为 70000 次/秒。这个数字才是我们需要真正面对的瞬时压力。从这里开始，你会意识到，原先那个简单的架构图必须能够承接每秒七万次的请求，而且是在最坏的情况下仍要稳定服务。

第三步，将峰值请求换算成服务器的数量。你需要对单台应用程序服务器的处理能力做一个假设：比如一台服务器可以稳定处理 10000 RPS。那么，承载 70000 RPS 所需的理论服务器数量就是 70000 除以 10000，等于 7 台。但系统设计绝不能只盯着理论下限，你永远要为故障和意外的流量尖刺留出冗余。所以保守起见，我们会多部署几台，最终定为 10 台应用程序服务器。这就是一个从用户假设一路推演到硬件清单的完整过程。

有了计算能力的基准，还要考虑存储层面的估算。对于 Facebook 这样体量的产品，需要多少存储空间来存放用户数据呢？你可以从用户剖面数据入手：假设每个用户的个人资料、头像、设置等结构化和非结构化信息占用的平均空间，然后乘以 10 亿注册用户，再乘以一个膨胀系数。虽然这部分估计同样只需要抓准数量级，但它的推导逻辑跟计算服务器完全同源——都是先定基本单元，再乘上用户数和冗余倍数。存储类型也会进一步细分，比如关系图谱、动态消息、图片、视频都需要各自的容量预估，不过任何一项都逃不出信封背面计算的基本框架。

整套方法之所以被称作信封背面的计算，就是因为它在极短的时间内、用随手可得的几个假设，就能帮助系统设计师摸清系统的大致轮廓。这不仅仅是为了应对面试题，更是日常工作中避免“过度设计”或者“设计不足”的保险丝。当你把 10 亿用户、20% 日活跃率、平均每天打开 10 次、峰值是均值 3 倍、单机 10000 RPS 这些假设串成一条线，你看到的就不再只是抽象的数字，而是一张清晰的资源配置地图。而这张地图，才是你真正开始绘制架构设计图的底稿。

回到最初的那个问题：“一台服务器能扛住这些请求吗？”在信封背面计算之后，答案不再是“可能吧”或者“试一试”，而是一个有理有据的：“不，需要十台，而且有冗余。” 这个从模糊到清晰的过程，恰恰就是系统设计的起点。