看懂一张应用架构图
先看数据怎么流动
Section titled “先看数据怎么流动”一张常见的应用关系图可以简化成：
用户浏览器 ↓ HTTPS静态页面 / 前端应用 ↓ API 请求后端服务 ───→ 数据库 ├──────→ 文件存储 └──────→ 第三方 API（支付、邮件、模型等）用户看到的是前端；真正的权限判断、密钥保管和数据写入通常应该在后端或受控服务中完成。
每一层负责什么
Section titled “每一层负责什么”| 层 | 负责 | 新手要注意 |
|---|---|---|
| 浏览器 | 展示页面、收集输入、发请求 | 不要把密钥写在前端 |
| 前端 | 交互、状态和页面路由 | 不能单独承担权限安全 |
| 后端/API | 业务规则、权限、调用外部服务 | 要有错误处理和日志 |
| 数据库 | 保存结构化数据 | 需要备份、迁移和访问控制 |
| 文件存储 | 图片、附件、构建产物 | 要限制类型、大小和访问范围 |
| 第三方服务 | 模型、支付、邮件等能力 | 关注额度、隐私、失败和替代方案 |
静态网站和动态应用
Section titled “静态网站和动态应用”静态网站在构建时生成 HTML、CSS、JavaScript，适合官网、文档和博客；动态应用需要运行时处理用户、数据和权限。很多项目会把两者组合起来：页面静态托管，API 和数据库单独部署。
不要一开始就过度架构
Section titled “不要一开始就过度架构”单体应用、托管数据库和一个部署平台，往往足够支撑第一版。微服务、消息队列、多区域和复杂缓存会增加部署、监控、备份和排错成本，应该由真实需求驱动。
画图时至少标注
Section titled “画图时至少标注”- 谁发起请求；
- 哪些连接经过 HTTPS；
- 哪一层保存密钥；
- 数据保存在哪里、多久备份；
- 失败时怎样重试或降级；
- 哪些服务按量收费。