一个真实的场景
上周五下午，新人小李接到任务："做一个用户注册功能"。
他的第一反应是打开画图工具，开始画架构图——Controller 层、Service 层、Repository 层、Cache 层、消息队列层……
周一 code review，他的"六层架构"被主管打了回来。不是因为分层本身有问题，而是：这个功能连数据库都还没建好。
01 为什么新手喜欢一上来就分层？
你可能也和小李一样——刚学完设计模式、架构原则，满脑子都是"高内聚低耦合"、"分层架构"、"可扩展性"。
这不是你的错。市面上太多教程都在教"标准答案"，却很少告诉你：架构是解决实际问题后的自然结果，不是起点。
三个常见的思维误区：
误区一：把分层当目的
分层只是工具，不是目标。很多小系统，单机单库就能跑，何必非要搞七层架构？
误区二：把"大厂做法"当教条
你以为 BAT 的架构师都爱分层？错了。他们是因为用户量级、业务复杂度逼得不得不分。对于日活 1000 的系统，Monolith（单体）就是最优解。
误区三：先画图再想问题
拿到需求就画架构图，结果画完之后才发现：核心问题没解决，技术债务倒欠了一堆。
02 新手最容易犯的 5 个系统设计错误
错误 1：还没理解需求就开始画架构图
❌ 错误做法
"这个功能用微服务还是单体？我先画个架构图吧。"
✅ 正确做法
先问自己三个问题：
- 这个功能要解决什么业务问题？
- 当前最大的瓶颈是什么？（性能？一致性？可用性？）
- 预计用户量和增长曲线是什么？
核心原则：架构服务于业务，而不是业务服从于架构。
错误 2：为"可能的需求"做过度设计
❌ 错误做法
"万一以后要支持多租户呢？我现在就把租户 ID 加上。"
✅ 正确做法
"先把这个需求解决。等真正需要多租户时，再重构也来得及。"
核心原则：YAGNI（You Aren't Gonna Need It）——你不需要它。
过度设计的代价：
- 开发时间翻倍
- 代码复杂度上升
- 维护成本增加
- 后来者读代码时骂你
错误 3：滥用缓存或完全不用缓存
❌ 错误做法 A
"缓存能提升性能，我给所有接口都加上缓存！"
❌ 错误做法 B
"缓存太复杂了，我们不用，直接查库吧。"
✅ 正确做法
先确定数据特征：
- 数据更新频率如何？
- 一致性要求多高？
- 缓存失效后的雪崩风险大吗？
再决定是否缓存、缓存策略是什么。
核心原则：缓存是双刃剑，用对地方才是利器。
错误 4：把"扩展性"挂在嘴边，却不知道扩展什么
❌ 错误做法
"这个设计没有扩展性，换一种方式吧。"
"什么叫扩展性？""呃……就是以后能加功能。"
✅ 正确做法
先识别具体的扩展场景：
- 用户量从 1 万增长到 100 万？
- 要支持新的支付渠道？
- 要接入新的数据源？
再评估当前设计能否支撑这些场景。
核心原则：脱离具体场景谈扩展性，都是耍流氓。
错误 5：忽视数据层设计
❌ 错误做法
"先把代码写完，数据库后面再优化。"
✅ 正确做法
把数据模型设计放在编码之前：
- 核心实体是什么？关系如何？
- 索引如何设计？查询模式是什么？
- 数据量预估多大？要不要分库分表？
核心原则：大多数系统，瓶颈都在数据层。把数据设计好，事半功倍。
03 正误对比速查表
| 场景 | ❌ 错误做法 | ✅ 正确做法 | 原因 |
|---|---|---|---|
| 接到新需求 | 立即画架构图 | 先分析业务问题和瓶颈 | 架构是解决方案，不是起点 |
| 性能优化 | 上来就加缓存/异步 | 先定位瓶颈点，再针对性优化 | 盲目优化是浪费 |
| 考虑扩展性 | 设计"万能架构" | 识别具体扩展场景，按需设计 | YAGNI 原则 |
| 技术选型 | 选"大厂标配"技术栈 | 根据团队能力和业务需求选型 | 合适的才是最好的 |
| 数据库设计 | 最后再考虑 | 编码前先设计数据模型 | 数据层是大多数系统的瓶颈 |
04 给新手的行动指南
第一步：先问问题，再画图
拿到需求后，先回答这 5 个问题：
- 1.核心业务流程是什么？ 用文字描述，不要画图。
- 2.当前最大的风险是什么？ 性能、一致性、可用性、还是团队能力？
- 3.用户量和增长预期是什么？ 决定技术选型的量级。
- 4.有哪些现成的轮子可以用？ 不要重复造轮子。
- 5.最简单的可行方案是什么？ 先跑通，再优化。
第二步：用最简单的方案先跑起来
"Perfect is the enemy of good."
完美是优秀的敌人。
先让系统跑起来，在实际运行中发现问题，比纸上谈兵强一百倍。
第三步：识别真正的瓶颈再优化
性能问题就像生病——你得先知道哪里疼，才能对症下药。
推荐工具：
- APM 工具：Skywalking、Pinpoint
- 数据库慢查询：MySQL slow log、Explain 分析
- 系统瓶颈：top、vmstat、iostat
第四步：让设计决策有据可依
每个设计决策都应该能回答：
- 解决了什么问题？
- 有什么代价/风险？
- 如果错了，怎么回滚？
05 总结
系统设计不是画图大赛。真正的高手，是能用最简单的方案解决实际问题的人。
记住三句话：
1. 先理解问题，再设计方案。
2. 简单优于复杂，能跑优于完美。
3. 用数据说话，用监控验证。
下次接到设计任务时，别急着打开画图工具。先问自己：我真的理解要解决的问题了吗？
你的第一个设计决定，应该是"不做什么"，而不是"做什么"。
如果这篇文章对你有帮助，欢迎转发给需要的朋友。关注公众号，回复"系统设计"，送你一份我整理的系统设计入门资料包。
