架构设计

---

为什么新手也要懂架构？

你可能在想："我连 Hello World 都没写过，就要学架构？"

对，就是要学。而且要在写代码之前学。

我的教训

第一次用 AI 做项目时，我直接让 AI "帮我做一个微信公众号 RSS 项目"。

AI 问我："用什么技术栈？前后端分离吗？数据库用什么？"

我当时完全懵了。什么是技术栈？什么是前后端分离？

我回答："你看着办吧。"

结果：

• AI 给了一个 Node.js + React + MongoDB 的方案
• 我不熟悉 Node.js
• AI 生成的代码我看不懂
• 改来改去，最后推倒重来，换成 Python + Vue

浪费了2周时间。

如果我一开始就懂架构，直接告诉 AI "用 Python + Vue + SQLite"，2周就能做完。

---

架构不是"高大上"，是"做选择"

你以为的架构

• 画复杂的架构图
• 写几十页的设计文档
• 研究微服务、分布式、K8s
• 需要很深的技术功底

这些是大厂的架构，不是个人项目的架构。

实际的架构

就是回答3个问题：

1. 用什么技术？（Python 还是 Node.js？）
2. 前端后端怎么分？（分离还是一体？）
3. 数据库用什么？（SQLite 还是 PostgreSQL？）

回答完这3个问题，架构就定了。

这一章教你什么

不是:

• ❌ 教你成为架构师
• ❌ 教你画架构图
• ❌ 教你设计复杂系统

而是:

• ✅ 和 AI 讨论时，能听懂 AI 在问什么
• ✅ AI 给方案时，能判断是否适合你
• ✅ 避免被 AI 带偏，做出过度复杂的架构

你只需要有"基本架构概念"，能和 AI 有效沟通就够了。

---

新手最大的困惑

很多新手不是不想把项目做好，而是脑子里根本没有"架构"的概念。

"前后端分离"是什么意思？架构图要怎么画？单体、微服务这些词都是啥？

我第一次听到这些词时，也是懵的。

但后来我发现，架构其实很简单，就是"项目有几个部分，它们怎么配合"。

---

我怎么做架构设计

直接和 AI 讨论，不画图、不写文档

为什么？

画图慢，还要学工具。文档写了也不一定看。直接和 AI 聊，更快，AI 还能给建议。

怎么讨论？

我做 AI News RSS 时是这样的:

我: "我想做新闻聚合，爬新闻→AI分析→生成RSS。
我会Python，不太会前端。需要前端吗？"

AI: "建议要前端，因为需要展示新闻列表、用户配置订阅。"

我: "那用什么？我不太会"

AI: "Vue + Element Plus，学习曲线平缓，有现成组件，
文档齐全，我能帮你写"

我: "好。数据库呢？"

AI: "MVP 阶段 SQLite，不需要额外部署，够用，
后期能轻松迁移到 PostgreSQL"

我: "部署呢？"

AI: "单台VPS，Docker部署，前后端都在一台机器，成本低"

我: "就这个方案"

最后定下来的架构:

• 前后端分离
• 前端: Vue 3 + Element Plus
• 后端: FastAPI
• 数据库: SQLite
• 部署: 单服务器 Docker

---

我的固定套路

Python + Vue 打天下

我基本就用这一套:

• 前端: Vue 3 + Element Plus
• 后端: Python + FastAPI
• 数据库: 根据阶段选

为什么固定这套？

• 熟悉了，开发快
• AI 对这些技术支持好
• 生态成熟，搜得到答案
• 部署方便

数据库怎么选

开源项目 → SQLite

• 单文件数据库，部署简单
• 不需要额外服务
• 小项目够用

SaaS 产品 → PostgreSQL + Redis

• PostgreSQL: 多用户并发
• Redis: 缓存，提升性能

AI News RSS 就是这么演进的: MVP 用 SQLite 快速上线，SaaS 版本改成 PostgreSQL + Redis。

前后端分离 vs 单体

前后端分离:

浏览器 ← → 前端(Vue) ← → 后端(FastAPI) ← → 数据库

前端和后端是两个独立项目。

单体:

浏览器 ← → 后端(FastAPI) ← → 数据库
             ↓
         返回HTML页面

后端直接返回页面。

我的选择: 大部分项目用前后端分离。

为什么？前端能独立开发部署，后端能被多个前端复用（Web/App），职责清晰。

什么时候用单体？特别简单的工具，比如一个表单，不需要复杂交互，快速验证想法。

简单够用原则

MVP 阶段:

• 架构越简单越好
• 单服务器部署
• 不过度设计

成熟后再优化:

• 用户量大了，考虑分布式
• 性能不够了，加缓存
• 需要扩展了，做微服务

大部分个人项目，永远用不到复杂架构。

---

真实案例: AI News RSS 怎么演进的

MVP 阶段

技术栈:

• 前端: Vue 3
• 后端: FastAPI
• 数据库: SQLite
• 部署: 单台VPS，Docker

为什么这么设计？

• 快速上线验证需求
• 成本低，一台VPS搞定
• 够用就行

前后端分离是为了方便后续扩展。SQLite 简单够用。单服务器成本低。

SaaS 版本

什么时候改的？

MVP 上线运行2个月后，用户开始增长，SQLite 扛不住了。

改了什么？

• SQLite → PostgreSQL（多用户并发）
• 加了 Redis（新闻缓存，减少重复爬取）
• 其他不变

为什么只改这些？

用户量还不大，单服务器够用。前后端不需要改。代码改动最小。

教训:

架构不是一开始就设计好的，是根据实际需求演进的。够用就行，不提前优化。

---

和 AI 讨论架构

讨论模板

你: "我要做[项目名]，功能是[核心功能]。
我会[技术栈]，不太会[技术栈]。
约束条件:
1. 个人开发
2. MVP阶段
3. 预算有限
4. 要快速上线

帮我设计架构，给2-3个方案，说明优劣。"

AI 会给你几个方案、优劣对比、技术栈建议。

你要做的: 对比方案，结合实际情况选择，确认细节。

讨论前准备清单

• [ ] 明确核心功能（3-5个）
• [ ] 确定技术栈偏好（你会什么）
• [ ] 确定约束条件（预算、时间、人力）
• [ ] 确定项目阶段（MVP/正式产品）

讨论时确认

• [ ] 前后端如何组织？
• [ ] 数据库用什么？
• [ ] 缓存需要吗？
• [ ] 部署方案是什么？
• [ ] 成本如何？

AI 的局限

AI 可以:

• 提供多种架构方案
• 对比不同方案的优劣
• 解释技术术语
• 根据你的约束调整方案

AI 不能:

• 替你做决策（它不知道你的实际情况）
• 保证架构一定适合你
• 预测未来的需求

你要做的: 基于 AI 的建议，结合实际情况，做最终决策。

---

常见架构问题

问题1: 一开始就设计完美架构

MVP 阶段就规划微服务、考虑百万用户量、部署用 K8s。

后果: 架构很复杂，开发周期长，等不到上线就放弃了。

正确做法: MVP 用最简单的架构，先验证需求可行，需要时再优化。

问题2: 盲目模仿大厂架构

看到某大厂用微服务，我也要用。学到分布式，就想用上。不考虑自己的实际情况。

后果: 架构过度复杂，维护困难，个人根本搞不定。

记住: 大厂架构解决的是大厂的问题，你的问题和他们不一样。

问题3: 频繁重构架构

学到新技术就想重构，看到更好的方案就换，架构一直在改，功能做不完。

后果: 永远在重构，项目做不完。

正确做法: 架构够用就行，除非有明确的痛点，否则不重构。功能优先于架构。

---

实用架构模板

模板1: 标准 Web 应用（推荐）

适合: 大部分个人项目（新闻聚合、博客系统、管理后台）

架构:

前端(Vue) ← → 后端(FastAPI) ← → 数据库(SQLite/PostgreSQL)

技术栈:

• 前端: Vue 3 + Element Plus
• 后端: Python + FastAPI
• 数据库: SQLite(MVP) / PostgreSQL(SaaS)
• 部署: 单台VPS，Docker Compose

模板2: 纯后端工具

适合: 不需要界面的工具（爬虫、数据处理、API 服务）

架构:

API/CLI ← → 后端服务 ← → 数据库

技术栈:

• 后端: Python + FastAPI
• 数据库: SQLite

模板3: 简单单页应用

适合: 特别简单的项目（聊天界面、工具网站）

架构:

前端(Vue) ← → 第三方API（不需要自己的后端）

技术栈:

• 前端: Vue 3
• API: 直接调用第三方（如 OpenAI API）

注意: API key 要后端保护，不能暴露在前端。

---

核心要点

1. 架构是演进出来的，不是设计出来的
   MVP 简单架构 → 根据需求优化 → 成熟架构

2. 跟着需求和技术栈走
   不需要从零设计，有固定套路

3. 和 AI 讨论，不画图
   讨论更快，AI 能给建议

4. 够用就行，不过度设计
   大部分个人项目，简单架构就够了

架构是为了解决问题，不是为了炫技。简单、够用、能快速上线，就是好架构。