62 lines
2.2 KiB
Markdown
62 lines
2.2 KiB
Markdown
|
# 系统架构
|
|||
|
|
|
|||
|
|
**我是卡若。**
|
|||
|
|
|
|||
|
|
架构不是为了画图好看，是为了**省事**和**赚钱**。
|
|||
|
|
|
|||
|
|
我们的架构设计，核心围绕两个字：**分离**。
|
|||
|
|
- 内容和代码分离。
|
|||
|
|
- 前端和后端分离。
|
|||
|
|
- 静态和动态分离。
|
|||
|
|
|
|||
|
|
## 1. 架构全景图
|
|||
|
|
|
|||
|
|
\`\`\`mermaid
|
|||
|
|
graph TD
|
|||
|
|
subgraph "内容生产 (Content)"
|
|||
|
|
Typora[本地写作] --> Git[Git 仓库]
|
|||
|
|
Git --> AutoSync[自动同步脚本]
|
|||
|
|
end
|
|||
|
|
|
|||
|
|
subgraph "应用层 (Next.js)"
|
|||
|
|
AutoSync --> FileSys[文件系统 book/]
|
|||
|
|
FileSys --> Backend[后端 API]
|
|||
|
|
Backend --> Frontend[前端 UI]
|
|||
|
|
end
|
|||
|
|
|
|||
|
|
subgraph "用户触达 (User)"
|
|||
|
|
Frontend --> Wechat[微信环境]
|
|||
|
|
Frontend --> Browser[手机浏览器]
|
|||
|
|
end
|
|||
|
|
\`\`\`
|
|||
|
|
|
|||
|
|
## 2. 核心设计理念
|
|||
|
|
|
|||
|
|
### 2.1 “内容即产品”
|
|||
|
|
我们的核心资产不是代码，是 `book/` 目录下的文章。
|
|||
|
|
- 代码丢了可以重写，文章丢了就完了。
|
|||
|
|
- 所以，文章用 Markdown 存，Git 管，最安全。
|
|||
|
|
|
|||
|
|
### 2.2 前后端分离 (即使在 Next.js 里)
|
|||
|
|
为了以后能扩展（比如招人开发，或者把后端换成 Java），我们在代码逻辑上做了强制隔离。
|
|||
|
|
- 详见：**[前后端架构分离策略](file:///Users/karuo/Documents/个人/2、我写的书/《一场soul的创业实验》/开发文档/2、架构/前后端架构分离策略.md)**
|
|||
|
|
|
|||
|
|
### 2.3 极简部署
|
|||
|
|
- 不要 Docker（除非必要）。
|
|||
|
|
- 不要 K8s。
|
|||
|
|
- 既然是 Node.js 项目，PM2 或者 Vercel 就够了。宝塔面板配个 Webhook 自动拉代码，是最适合个人开发者的方案。
|
|||
|
|
|
|||
|
|
## 3. 关键约束
|
|||
|
|
|
|||
|
|
1. **本地优先**: 写作在本地，代码开发也在本地。
|
|||
|
|
2. **稀疏检出 (Sparse Checkout)**: 如果你只负责写作，就别拉取代码；如果你负责开发，就拉取全部。
|
|||
|
|
3. **单向流动**: 数据流向是 `Markdown -> API -> UI`。除非是评论或订单，否则 UI 不反向修改 Markdown。
|
|||
|
|
|
|||
|
|
## 4. 详细技术栈
|
|||
|
|
|
|||
|
|
详见：**[技术选型与全景图](file:///Users/karuo/Documents/个人/2、我写的书/《一场soul的创业实验》/开发文档/2、架构/技术选型与全景图.md)**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
**总结：**
|
|||
|
|
保持架构的简单性，就是保持业务的灵活性。能在文件里解决的，就别上数据库；能在 Next.js 里解决的，就别拆微服务。
|