2.2 KiB
2.2 KiB
系统架构
我是卡若。
架构不是为了画图好看,是为了省事和赚钱。
我们的架构设计,核心围绕两个字:分离。
- 内容和代码分离。
- 前端和后端分离。
- 静态和动态分离。
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),我们在代码逻辑上做了强制隔离。
- 详见:前后端架构分离策略
2.3 极简部署
- 不要 Docker(除非必要)。
- 不要 K8s。
- 既然是 Node.js 项目,PM2 或者 Vercel 就够了。宝塔面板配个 Webhook 自动拉代码,是最适合个人开发者的方案。
3. 关键约束
- 本地优先: 写作在本地,代码开发也在本地。
- 稀疏检出 (Sparse Checkout): 如果你只负责写作,就别拉取代码;如果你负责开发,就拉取全部。
- 单向流动: 数据流向是
Markdown -> API -> UI。除非是评论或订单,否则 UI 不反向修改 Markdown。
4. 详细技术栈
详见:技术选型与全景图
总结: 保持架构的简单性,就是保持业务的灵活性。能在文件里解决的,就别上数据库;能在 Next.js 里解决的,就别拆微服务。