开源产品部署原本要 22 个服务才能跑起来，现在默认只需三个容器

如果你尝试过自托管某个开源产品，一定熟悉那个瞬间：你克隆了仓库，打开部署指南，然后意识到在任何东西跑起来之前，你得先搭建十几个甚至更多的服务。很多人就在这一步放弃了，甚至还没见过产品真正运行起来。我们自己的开源平台（一个用于测试和监控 AI 应用与智能体的工具）一开始也是这样，而且这个设计在当时是有道理的。 **部署一开始为什么这么大** 我们的架构是围绕真实生产环境的需求搭建的：流量、各自独立的服务、需要单独扩展的组件。它们当中的每一个，在规模化运行时都有存在的价值。问题在于，只想在笔记本上试试看的人，必须先扛下这一切，才能拿到哪怕一个有用的结果。 **现在默认部署长什么样** 我们重新审视了整个部署流程，对每个服务都问了同一个问题：第一次使用的用户，需要这个服务运行起来才能获得价值吗？大多数情况下，答案是否定的。现在默认只有三个容器：一个应用容器，装着不需要独立扩展的部分，与 Postgres 和 ClickHouse 并排运行。它能在一台两核 CPU、分配约 4GB 内存给 Docker 的笔记本上跑起来。首次拉取镜像大约 800 MB。那个会分散成 22 个服务的更大部署方案仍然保留，作为生产环境的可选配置。外部连接也是可选的：本地运行不需要配置任何外部服务，每个集成默认关闭，直到你添加对应的密钥。 **这件事让我们重新思考了两点** 第一次安装体验和它背后的功能一样重要。我们过去一直把部署当作通往产品途中必须熬过的一关。但对一个开源项目来说，部署流程在最初十分钟里就是产品本身，而这十分钟决定了有没有人愿意留下来。 减少服务数量是一个架构问题。仅仅重新打包是解决不了的。搞清楚哪些组件可以共用一个容器、哪些仍然必须独立运行，让我们多次回到核心设计中去推翻重来。把所有东西塞进一个巨大的镜像当然会简单得多，但那只是捷径。让简单路径和扩展路径都能成立的拆分方案，才是最耗费精力的部分。 最后，给所有自托管玩家留一个问题：在放弃一个东西之前，你最多愿意忍受多复杂的部署流程？