从 10 万到 100 万用户的实战指南：系统扩容不是加机器那么简单

10 万用户和 100 万用户，中间只差一个 0。

但对系统来说，这个 0 往往意味着整个世界变了。

在 10 万用户阶段，很多问题还能靠勤奋补：

• 服务器不够就先扩两台
• 查询慢了就补一个索引
• 活动来了就人工盯着
• 某个接口抖了就临时重启

一旦到 100 万用户，这些办法会开始失效。

不是因为大家不努力，而是因为系统进入了另一个数量级：

• 峰值流量不是线性增长，而是会被活动和热点放大
• 一个小问题的影响半径更大
• 数据规模和调用链长度同时上升
• 人工兜底开始跟不上系统速度
• 组织协作会变成技术成败的一部分

所以从 10 万到 100 万用户，真正要升级的，不只是机器规格，而是：

系统面对复杂度的组织方式。

这篇文章不会假装有一条万能路线图。它会更现实一点，讲清楚这一路最重要的几类升级：

1. 容量规划怎么做，才不是拍脑袋
2. 哪些瓶颈最先暴露：应用、数据库、缓存、链路还是发布
3. 系统边界、数据治理、流量保护该如何升级
4. 哪些事情必须自动化，不能再靠人守
5. 什么才算“具备 100 万用户能力”，而不是“侥幸撑过一次活动”

如果你正在做一个持续增长的产品，这篇很适合提前看。

一、先统一认知：用户数不是唯一指标，峰值和行为模式才是关键

很多团队做容量判断时，习惯直接看“注册用户数”或“DAU”。

这两个指标当然重要，但真正决定系统压力的，通常是下面几件事：

• 峰值并发
• 请求结构
• 写入比例
• 热点集中度
• 用户行为同步性

1.1 为什么 100 万用户不一定比 10 万用户难十倍

因为压力不只来自总量，还来自模式。

举例：

• 一个工具产品 100 万用户，但访问分布很平滑
• 一个活动型产品 20 万用户，却会在 10 分钟内同时涌入

后者在系统层面反而更难。

1.2 三个最该看的容量指标

这三个指标，比“用户数到了多少”更接近系统真相。

二、从 10 万到 100 万，最先暴露的往往不是机器，而是结构问题

2.1 调用链开始变长

小系统时，一个页面也许只需要 2~3 个接口。规模上来后，页面往往会变成：

• 主数据接口
• 推荐接口
• 营销接口
• 实验接口
• 权限接口
• 埋点配置接口

任何一个环节慢一点，尾延迟都会被放大。

2.2 数据开始长大，原本可接受的写法变成炸点

例如：

• 深分页开始明显变慢
• 扫描型 SQL 出现抖动
• 报表和在线查询互相争资源
• 热点 key 逐渐集中

2.3 发布开始变成风险放大器

用户少时，出点问题影响有限；用户多时，同样一个 bug 会被瞬间放大成客诉、退款、舆情和财务问题。

所以规模化系统的升级，很多时候先从：

• 灰度
• 回滚
• 开关控制
• 监控告警
• 演练

这些“看起来不产出功能”的地方开始。

三、容量规划：别等打满了才知道自己没有预算

很多团队做容量规划像看天气：大概猜一下，希望别下雨。

真正可用的容量规划，至少要回答 4 个问题：

1. 峰值从哪里来
2. 哪条链路最容易先满
3. 满了以后会怎么传导
4. 还能不能在不伤主业务的情况下退化运行

3.1 一个实用容量表

这张表的价值，不是看“今天还够不够”，而是看：

• 哪个组件离边界最近
• 哪个组件最值得优先扩容或优化
• 某个新活动会不会压过安全线

3.2 压测的正确姿势

压测不该只测一条 happy path。

应该至少覆盖：

• 热点读场景
• 核心写场景
• 高峰登录 / 下单 / 支付场景
• 缓存失效场景
• 某个下游变慢的场景

真正有价值的压测，不是证明“系统很强”，而是找出“系统先死在哪”。

四、架构升级的第一原则：优先拆最贵的路径

当系统增长时，不是每条链路都值得同等投入。

4.1 把链路分成三类

A 类：收入和核心体验直接相关

例如：

• 登录
• 搜索
• 下单
• 支付

这些路径必须优先保。

B 类：对转化有影响，但可有限降级

例如：

• 推荐位
• 评论摘要
• 个性化标签
• 营销提示

C 类：装饰性或可延后

例如：

• 非关键埋点
• 次要统计接口
• 某些后台分析项

4.2 为什么这一步最重要

因为系统到 100 万用户阶段，资源永远有限。

你必须清楚：

• 高峰时什么必须成功
• 什么可以返回旧数据
• 什么可以暂时关闭

如果没有这层优先级设计，所有请求在系统里地位相同，最后最容易发生的就是：

非核心流量把核心链路一起拖死。

五、数据库和数据治理：最容易后知后觉的风险源

5.1 从“能查出来”升级到“可持续地查出来”

10 万用户阶段，很多 SQL 还能靠索引和缓存扛住。

100 万用户阶段要开始考虑：

• 热冷数据分层
• 在线查询和分析查询隔离
• 汇总表和明细表拆分
• 读写分离
• 数据生命周期治理

5.2 一个典型演进过程

初期

一个订单表什么都查：

• 用户查历史订单
• 财务查对账
• 运营查活动效果
• BI 跑周报

中期

开始出现：

• 慢查询
• 锁争用
• 索引越来越多
• 写入抖动

后期更合理的做法

• 在线订单主表服务主业务
• 汇总查询走报表层
• 旧数据归档
• 热数据保留在高性能路径

这不是为了“架构优雅”，而是为了让核心链路别被外围需求拖死。

六、缓存体系升级：从“加一个 Redis”到分层保护

用户规模变大后，缓存不再只是加速器，而是保护层。

6.1 三个必须思考的问题

1. 哪些数据适合放在浏览器 / CDN
2. 哪些热点必须本地缓存 + Redis 双层保护
3. 哪些数据根本不该缓存

6.2 三类高风险缓存问题

• 热点 key 击穿
• 整批 key 同时过期
• 个性化维度太多导致缓存污染

6.3 一个更成熟的思路

系统增长到这一阶段，缓存设计必须同时考虑：

• 命中率
• 回源代价
• 失效方式
• 一致性边界
• 保护主链路的优先级

如果你还在用“哪里慢就缓存哪里”的临时策略，规模一大很容易出事故。

七、流量治理：不是流量大了才需要，而是流量大了你来不及补

很多团队直到第一次大促失败，才开始认真做：

• 限流
• 熔断
• 降级
• 灰度
• 开关控制

其实这些能力应该在规模上来之前就补齐。

7.1 一个务实的高峰保护策略

7.2 为什么开关系统很值钱

功能开关不是为了方便产品试验而已，它在规模化系统里还有一个重要价值：

故障时可以快速剪掉非核心能力。

例如：

• 推荐位关闭
• 评论摘要关闭
• 某些营销提示关闭
• 某个高成本接口切到旧缓存

你会发现，很多真正保命的手段，都不是在事故现场新写出来的，而是平时先准备好的。

八、发布和回滚：用户越多，越要把“可恢复性”当核心能力

8.1 100 万用户阶段，发布已经不是开发动作，而是经营动作

因为每次发布都可能影响：

• 订单
• 收入
• 口碑
• 客诉
• 合作方 SLA

所以发布系统需要升级成：

• 分批灰度
• 监控联动
• 一键回滚
• 配置与代码分离
• 关键指标自动看护

8.2 一个简单的灰度策略

1% 内部员工
  ↓
5% 白名单用户
  ↓
20% 低风险地区
  ↓
50% 全量观察
  ↓
100% 正式放量

每一步都要看：

• 错误率
• P95 / P99
• 关键业务转化
• 下游依赖负载

没有这些指标联动，灰度就只剩“慢一点出事”。

九、组织也要升级：很多系统问题，其实是协作问题

技术系统变大后，组织如果没跟上，会出现一种很常见的现象：

• 每个人都在优化局部
• 但没人对全链路结果负责

9.1 规模化阶段的三个组织变化

A. 明确 owner

核心域必须有明确 owner，不然问题来了永远在拉群找人。

B. 指标归属明确

接口慢了、缓存命中低了、数据库抖了，到底谁负责，不应该靠临时协调。

C. 例行容量和故障复盘机制

增长型系统必须把这些变成制度：

• 容量评审
• 大促演练
• 变更评审
• 故障复盘

没有这些机制，系统增长越快，失控也越快。

十、一个从 10 万到 100 万用户的阶段性路线图

阶段 1：10 万到 20 万

重点：补基础工程能力

• 监控告警
• 日志和 tracing
• 索引与热点 SQL 治理
• 缓存初步分层
• 基本压测能力

阶段 2：20 万到 50 万

重点：识别系统边界和热点路径

• 核心链路拆分
• 热点接口专项优化
• CDN / 网关治理
• 灰度与开关系统完善

阶段 3：50 万到 100 万

重点：从“能扛”升级到“可预测”

• 容量规划常态化
• 数据生命周期治理
• 核心链路故障演练
• 组织 owner 和 SLA 明确
• 自动化扩容与回滚

10.1 一个收益对比示例

某内容电商平台做完这一轮升级后：

注意，真正的收益不只是“更快”，而是：

• 更稳
• 更省
• 更可恢复
• 更少依赖英雄主义

十一、给团队的百万用户升级检查清单

容量层

• 是否有核心链路峰值容量表
• 是否知道最先会打满哪个组件
• 是否有接近生产的压测结果

架构层

• 是否明确了 P0 / P1 / P2 业务优先级
• 是否拆出了最重、最贵、最危险的路径
• 是否具备缓存、流量治理、故障隔离能力

数据层

• 是否区分在线与分析查询
• 是否有热冷数据治理
• 是否控制了核心表的查询和索引膨胀

发布治理层

• 是否支持灰度和一键回滚
• 是否有功能开关和快速降级能力
• 是否有关键指标自动监控

组织层

• 是否有明确 owner
• 是否有容量评审和故障复盘机制
• 是否把系统升级当成长期工程，而不是临时救火

总结

把 10 万到 100 万用户这段路讲透，可以收敛成 5 句话：

1. 用户规模增长，真正放大的不是机器压力，而是系统复杂度。
2. 先看峰值、尾延迟和依赖放大系数，不要只看 DAU。
3. 架构升级的重点不是全都优化，而是优先保住最值钱的链路。
4. 规模化系统必须把灰度、回滚、开关、容量评审做成基础设施。
5. 没有组织升级的技术升级，最终会被协作成本吃掉。

如果你只记住一句话，我希望是这一句：

从 10 万到 100 万用户，不是把原来的系统放大十倍，而是把原来的侥幸全部暴露出来。

所以真正的目标，从来不是“扛住一次高峰”，而是——

让系统在每次增长后都更可预测。