作为一名独立创始人，我的 SaaS 基础设施

UserJot完全是我一个人创建和运营的。没有团队，没有外包人员，只有我一个人。

UserJot是一款面向 SaaS 公司的反馈、路线图和变更日志工具。它帮助产品团队收集用户反馈、构建公开路线图，并让用户及时了解产品发布情况。其基础设施需要能够处理巨大的流量。仅在 8 月份，我们就迎来了 52,000 名用户访问平台、客户网站上加载反馈组件以及数千个后台作业的处理。

经过数月的反复试验，我最终确定了以下方案。

准备工作

我有三个前端，全部部署在 Cloudflare Workers 上：

• Astro用于营销页面、博客和文档（大部分是静态的，只包含少量 JavaScript）。
• TanStack 启动仪表盘（服务器端渲染，然后变成 SPA）
• TanStack 启动公共反馈委员会（方法相同）

为什么选择 TanStack Start？它汲取了 Remix 的优秀理念并加以进一步发展。Next.js 已经变得臃肿，包含了过多的功能和抽象。TanStack Start 则更加简洁、更可预测。

一个后端集群：

• Hetzner 上的 Docker Swarm（美国东部）
• Node.js 和 TypeScript
• PostgreSQL
• 用于反向代理的 Caddy

这就是全部基础设施。部署通过 GitHub Actions 完成，它运行 CI/CD 流程并将应用部署到 Docker Swarm。简单、乏味，但有效。

为什么没有 Redis

PostgreSQL 处理一切：

• 使用pg-boss的作业队列
• JSONB 表中的键值存储
• 发布/订阅并启用收听/通知
• 使用 pg-vector 进行向量搜索以查找重复反馈
• 会话存储
• 限速

pg-boss 在任务队列方面一直非常稳定可靠。它每天处理数千个任务：电子邮件营销活动、通知触发、数据同步等等。由于它基于 PostgreSQL 构建，因此与专用队列系统相比存在一些局限性，但这些局限性在实践中几乎可以忽略不计。

Redis 在某些方面能做得更好吗？或许可以。但管理一个数据库比管理两个要简单得多。单打独斗时，每增加一项服务，就意味着多了一项可能出错的服务。

更重要的是，每个依赖项都会直接影响您的正常运行时间。两项服务意味着两倍的故障风险，两倍的监控需求，两倍的备份需求，两倍的升级需求。您的可用性取决于最薄弱的服务。每新增一项服务，就意味着凌晨两点可能又多了一个崩溃的环节。

当然，将来我可能确实需要 Redis 来进行缓存，或者用 RabbitMQ 来处理复杂的队列模式，或者用 Kafka 来进行事件流处理。但这还很遥远。说实话，我并不期待添加这些依赖项。

单区域，全球用户

后端运行地点位于：美国东部。

有三件事使这项技术在全球范围内得以应用：

1. Cloudflare Argo通过其网络路由流量来降低延迟
2. 用户界面中积极主动的更新使操作感觉即时生效
3. 预取会在用户点击之前加载数据

前端在 Cloudflare 的边缘进行渲染，因此用户可以从附近的服务器获取 HTML，而数据则从后端加载。

无服务器架构的适用场景

我使用 Serverless 架构来构建前端，因为它们是无状态的。前端只负责渲染 HTML 和代理 API 调用。没有持久连接，没有后台任务，也不需要管理任何状态。

但后端仍然是传统的服务器。PostgreSQL 需要连接池，作业队列需要长时间运行的进程，实时功能需要 WebSocket 连接。Serverless 在这些方面表现不佳。

这种拆分方式效果很好：

• 前端在边缘自动缩放
• 后端在专用服务器上运行稳定。

自托管的利弊

我自行托管 PostgreSQL 和后端集群。这比使用托管服务需要更多工作，但我可以获得：

• 完全控制 PostgreSQL 扩展和配置
• 能够运行 pg-boss、pg-vector 和其他工具
• 可预测的成本，不会随使用量增加而扩展
• 无供应商锁定

缺点是：备份、更新和监控都需要我自己处理。如果您更看重时间而非控制权，那么托管服务可能更适合您。

何时这样做才有意义

这种架构在以下情况下效果最佳：

• 你是一个人还是一个小团队
• 你想拥有自己的基础设施
• 您熟悉 PostgreSQL 和 Docker。
• 您不需要多区域数据复制
• 您的功能不需要复杂的实时同步

如果出现以下情况，这可能就说不通了：

• 您拥有一支需要托管服务的大型团队。
• 你需要真正的多区域布局。
• 你不擅长管理服务器
• 特定功能需要专门的数据库。

我学到了什么

PostgreSQL 的功能比你想象的要多。作业队列、缓存、发布/订阅，它都能很好地处理。你可能暂时还不需要 Redis 实例。

无状态前端简化了一切。当边缘工作节点只负责渲染和代理时，无需担心分布式状态。

对于大多数 SaaS 应用来说，单区域部署就足够了。只要缓存机制完善，用户界面更新及时，用户就不会察觉到服务器距离很远。

枯燥的技术也能奏效。Docker Swarm 虽然不如 Kubernetes 那么花哨，但它更简单，也能完成任务。

服务器容量要预留充足。虚拟机很便宜。拥有四倍于实际需求的容量意味着您无需担心流量高峰期的扩展问题。每月多花 50 美元，就能获得安心保障。

维护的现实

最难的部分是初始设置。理解所有组件如何协同工作需要时间和经验。但一旦运行起来了呢？我每个月可能只需要花两三个小时在基础设施上。

其他一切都是开发功能和与用户沟通。

展望未来

这种模式会永远持续下去吗？不会，但它的规模会远远超出大多数人的想象。

人们严重低估了单个 PostgreSQL 实例的处理能力。现代硬件的性能极其强大。您可以垂直扩展到拥有数百个核心和 TB 级内存的机器。在合适的硬件上，PostgreSQL 每秒可以处理数百万次查询。

这套方案可以轻松应对数十万甚至数百万活跃用户，具体取决于你的使用模式。它或许就能满足我的所有需求了。

目前来看，PostgreSQL 和一个简单的架构就足够了，而且可能在未来几年内也足够了。我可以发布新功能、与用户沟通、发展业务。基础设施运行良好。

如果您对 UserJot 感兴趣，请访问UserJot 网站。我非常乐意与您探讨基础设施方面的决策。您也可以在Twitter 上找到我（@X）。