一个人做产品，最容易踩的坑是技术铺得太大——上来就微服务、K8s、自建数据库，三个月过去一行业务代码没写，运维问题倒是处理了一堆。
MVP 阶段的技术判断标准只有一个：能不能最快验证核心假设。其余全是负担。
这篇聊一下最小可用架构的取舍逻辑。
一、MVP 阶段真正需要的四层
1. 入口层 域名 + HTTPS + CDN（可选）
2. 应用层 一个能跑业务逻辑的服务
3. 数据层 数据库 + 对象存储
4. 外部能力 模型 API、支付、消息通知等第三方服务
就这四层。没有网关、没有服务网格、没有消息队列。这些在单人或小流量场景下都是过度设计。
二、哪些必须自己写，哪些直接用
| 组件 | 建议 | 理由 |
|---|---|---|
| 业务逻辑 | 必须自建 | 这是产品的核心价值 |
| 数据库 | 用托管 | 自建要处理备份、主从、扩容、监控 |
| 对象存储 | 用托管 | 文件存储的可靠性靠自己搭很难达到 |
| 缓存 | 前期可跳过 | 流量小时不是瓶颈，加了反而多一处故障点 |
| 消息队列 | 前期可跳过 | 用数据库轮询或同步调用就够 |
| 搜索 | 用数据库全文索引 | 数据量小时够用 |
| 监控 | 用平台自带 | 自己搭 Prometheus + Grafana 是奢侈 |
| CI/CD | 用平台或简单脚本 | 单人项目不需要复杂流水线 |
核心原则：凡是"运维问题比业务问题多"的组件，一律用托管。
三、应用层怎么组织
单人项目的应用层有两个务实选择：
单体服务。 一个进程包含所有业务逻辑，按模块分目录。优点：部署简单、调试方便、不用处理服务间通信。缺点：耦合，后期拆分麻烦。
前后端分离 + 单体后端。 前端静态托管（CDN + 对象存储），后端一个 API 服务。这是当前最主流的做法，前后端可独立迭代。
不建议 MVP 阶段就做微服务。拆分的前提是"有多个团队独立开发"，一个人拆成五个服务只是给自己制造麻烦。
四、数据层的关键决策
数据库选型。 关系型数据库（MySQL / PostgreSQL）覆盖绝大多数场景。除非数据模型天然是文档型或时序型，否则不要为了"先进"选 NoSQL——关系型的事务和查询能力在小项目里更有价值。
数据放在哪。 结构化数据进数据库，文件（图片、视频、文档）进对象存储。不要把文件存数据库（备份和迁移会非常痛苦），也不要存本地磁盘（换机器就丢）。
备份策略。 托管数据库通常有自动备份，但要确认两件事：备份保留多久、能不能恢复到某个时间点。自己再定期导出一份到对象存储，成本很低。
五、外部能力怎么接
模型 API、支付、短信、地图这类能力，全部用第三方，不要自己实现。
接入时的技术要点：
1. 凭证管理。 所有第三方 Key 放环境变量或密钥管理服务，绝不进代码仓库。
2. 抽象一层。 把第三方调用封装成自己的接口（比如 translate() 内部调谁），将来换供应商只改一处。
3. 失败要能降级。 第三方服务会挂。调用失败要有重试、超时、降级逻辑，不能让一个外部依赖拖垮整个服务。
4. 用量监控。 第三方按量计费，要有用量统计和告警，避免某个 bug 导致调用量暴涨。
六、单人项目的架构演进路径
阶段1：单体 + 托管数据库 + 对象存储 + CDN
↓ 什么时候动？流量上来单机扛不住
阶段2：应用层多实例 + 负载均衡 + 托管缓存
↓ 什么时候动？模块间互相拖累、发布影响面大
阶段3：按业务域拆分服务
↓ 什么时候动？多个团队协作
阶段4：微服务 / 服务网格（多数项目到不了这步）
关键判断：每一步的触发条件是"真的遇到问题"，不是"预判可能会遇到"。 提前架构升级是最常见的浪费。
七、几个容易被忽视的技术细节
1. 环境隔离。 至少要有开发和生产两套。共用一套环境时，调试代码会把线上数据搞乱。
2. 配置外置。 数据库地址、API Key、开关配置都放环境变量，不要硬编码。这样同一份代码能跑在不同环境。
3. 日志要能查。 应用日志打到 stdout，由平台收集；关键业务操作写数据库。出问题时能定位，比什么监控都重要。
4. 域名与证书自动化。 证书到期忘续是经典事故。用自动续签方案，或者至少在日历上设提醒。
5. 部署要能一键回滚。 新版本出问题，五分钟内能退回上一版。这是最基本的安全网。
八、写在最后
单人做产品的技术策略，本质是"把有限的精力放在业务上"。托管服务换掉的是运维负担，换来的是验证速度。等业务真的跑起来了，再按实际瓶颈做架构升级，比一开始就搭一套完整体系务实得多。
一站式的创业技术基建与产品组合可以看官方页面——查看 OPC 一人公司创业装备库的产品组合。具体产品内容与价格以页面实际展示为准。
你做个人项目时，技术栈是怎么砍的？有没有搭过后来完全没用上的组件？评论区聊聊。
