架构演进路径#

为什么要讲演进？#

面试中直接给终态架构有两个问题：

1. 面试官会觉得你在背方案，而不是真正理解
2. 你无法解释”为什么用这个而不是那个”——因为你没有讲清楚瓶颈在哪

演进式回答的核心：每一步架构变化都由一个具体瓶颈驱动。

阶段 1：单体应用（DAU < 10 万）#

用户 → Nginx → 单体应用 → MySQL 单机

• 一个 WAR/JAR 包含所有模块
• 单机 MySQL，读写不分离
• 够用就不拆——复杂度低、开发快、部署简单

瓶颈触发点：

• 数据库成为瓶颈（慢查询增多、连接数打满）
• 单机无法承载峰值流量
• 团队超过 5-8 人，代码冲突频繁

阶段 2：垂直优化（DAU 10 万 ~ 50 万）#

用户 → Nginx → 应用集群（多实例） → 读写分离 MySQL + Redis 缓存

关键动作：

• 应用水平扩展：无状态化（Session 外置到 Redis）→ Nginx 负载均衡
• 数据库读写分离：主库写、从库读，解决读瓶颈
• 引入缓存层：Redis 缓存热点数据，减少 DB 压力
• CDN + 静态资源分离

瓶颈触发点：

• 不同模块资源需求差异大（订单 CPU 密集，搜索 IO 密集）
• 某个模块的变更影响全局稳定性
• 数据库单表超过 1000 万行

阶段 3：服务化拆分（DAU 50 万 ~ 500 万）#

用户 → 网关 → 用户服务 / 订单服务 / 商品服务 → 各自数据库
                                                → MQ 异步通信
                                                → Redis 集群

拆分维度：

• 按业务域拆分（DDD 界限上下文）：用户、商品、订单、支付
• 每个服务独立数据库（数据自治）
• 服务间通信：同步 RPC + 异步 MQ

拆分带来的新问题：

阶段 4：大规模微服务（DAU > 500 万）#

用户 → CDN → API 网关集群 → 微服务集群 → 分库分表 / ES / 数据中台
              ↓                              ↑
           限流/熔断/降级               MQ 集群（Kafka）

关键动作：

• 分库分表：单表超过 5000 万，按 ShardingKey 水平拆分
• 搜索独立：ES 承接复杂查询，DB 只负责事务写入
• 全链路治理：限流 → 熔断 → 降级 → 灰度发布
• 可观测性建设：Metrics + Logging + Tracing 三件套

以秒杀系统为例的演进#

每一步都是被具体瓶颈逼出来的，不是一开始就设计成 V4。

我习惯用演进式思路来做系统设计。先从最简单的单体 + 单机 DB 讲起，说清楚这个阶段能支撑多少量级。然后随着用户增长，数据库先遇到瓶颈——引入缓存和读写分离。接着团队和业务复杂度增加，按业务域做服务拆分，引入注册中心、MQ、分布式事务。最后在大规模场景下，做分库分表、全链路治理、可观测性建设。每一步变化都有一个明确的瓶颈驱动——我不会上来就画一个微服务全家桶，因为架构是为了解决问题，不是为了炫技。

追问方向：

• “什么时候该拆服务？”→ 团队规模（>5 人独立迭代）、部署频率（某模块每天发版）、资源隔离需求
• “拆完之后最大的坑是什么？”→ 分布式事务和数据一致性，比架构本身难得多
• “你怎么判断现在是哪个阶段？”→ 看 QPS 量级、团队规模、迭代速度，不要过度设计

易错点：

• ❌ 上来就画微服务全家桶——暴露”背方案”，面试官会追问每个组件的必要性
• ❌ 拆分维度按技术层拆（前端服务/后端服务）——应按业务域拆
• ❌ 只讲拆分不讲代价——分布式事务、运维复杂度、链路追踪都是真实成本