系统是否支持未来扩展？如果业务量扩大 10 倍，是否需要重构？

扩展是支持的，但业务量真的涨 10 倍，部分架构需要做调整，不能算"完全不动"。我们在前期会按"业务量翻 2-3 倍内不动架构、5-10 倍做局部优化、超过 10 倍考虑分布式改造"的节奏来设计。这样既不会一开始就背上过度设计的成本，也不会到时候被迫推倒重来。

具体到不同业务量的应对方式：

当前规模 → 2-3 倍

通常不需要改架构，只要：

• 把云服务器/数据库的配置升一档
• 检查慢 SQL、加几个缓存
• 调整连接池、超时和并发限制

这一阶段几乎是"加钱解决"的范畴，开发改动很少。

3-5 倍

会触碰到一些瓶颈，常见的处理：

• 引入 Redis 缓存高频读
• 重要业务接口异步化（写消息队列）
• 静态资源走 CDN
• 文件存储迁到对象存储
• 数据库读写分离

这一阶段需要 1-2 周的改造工作，业务大体不停服。

5-10 倍

需要更明显的调整：

• 单点应用拆成集群部署
• 关键业务做服务化（订单、用户、消息独立部署）
• 数据库做垂直拆分（不同模块用不同库）
• 引入搜索引擎处理复杂查询
• 监控告警体系完善

这一阶段就是"局部重构"了，要 1-2 个月持续投入，但核心代码大部分还能复用。

10 倍以上

到这个量级，一般会有几件事必须做：

• 水平分片（按用户 ID、地区或时间分库分表）
• 异地多活或容灾备份
• 消息中间件、流量控制、降级熔断
• 大数据平台支撑分析和报表

到这个阶段往往不再是单纯的"重构"，而是"建一个能支撑下一代业务的新平台"。但即使到这里，前期沉淀下来的业务逻辑、数据结构、UI 仍然能复用很大一部分，不会完全推倒。

我们的做法是在首期就预留几个"扩展点"：缓存层、消息队列接口、读写分离的开关、关键表的分片键预留。这些都是"用不到的时候没成本，用到的时候不用大改"的设计，能让后续每一档扩张都比较平滑。