Featured image of post 为什么我们总是把简单的事情搞复杂

为什么我们总是把简单的事情搞复杂

从 Capsule 单文件应用说起,聊聊技术圈的过度工程问题。当所有人都在搞云原生、微服务、Docker 时,有人在做减法。技术总是在简单和复杂之间摇摆,而我们可能走得太远了。

昨天刷 Hacker News,看到一个叫 Capsule 的项目,评论区炸了。

这东西干的事情很简单:把整个 Web 应用(前端 + 后端 + 数据库)打包成一个 .capsule 文件。没有云,没有账号,没有 Docker,双击就能跑。数据存在本地 SQLite 里,想分享给别人?直接发文件。

听起来像是回到了 2005 年,那时候我们还在用 .exe 安装包。但评论区一堆人在喊"这才是未来"。

我当时就愣住了。

技术圈的钟摆

想想这些年我们走过的路:

2010 年之前:物理机,一台服务器跑所有东西,MySQL + Apache + PHP 一把梭。简单粗暴,但扩展性差。

2010-2015:虚拟机来了,VMware、VirtualBox,开始搞隔离。然后是 OpenStack,私有云。

2015-2020:Docker 革命,容器化,微服务。一个应用拆成十几个服务,每个服务一个容器。Kubernetes 成了标配。

2020-2025:Serverless,FaaS,完全托管。连服务器都不用管了,按调用次数付费。

2025-现在:有人开始说"等等,我们是不是走太远了?"

Capsule 就是在这个背景下出现的。它不是在发明新技术,而是在做减法。SQLite + 单文件打包,这些技术十年前就有了。但它把"简单"这件事做到了极致。

我的部署血泪史

说到"简单",我有太多话想说。

去年折腾一个个人项目,先是部署在 Vercel。免费额度用完了,每月 20 刀。心想算了,迁移到 Cloudflare Pages。结果 Worker 的 D1 数据库限制太多,又迁移到 Supabase。Supabase 的免费额度也见底了,最后买了个 DigitalOcean 的 VPS,自己装 Docker。

Docker 跑起来之后,内存不够。2GB 的 VPS,跑个 Next.js + PostgreSQL + Redis,天天 OOM。最后加了 swap,性能掉得一塌糊涂。

现在想想,这个项目日均访问量不到 100,我折腾这一圈图什么?

如果当初用 Capsule 这种思路:一个单文件应用,数据存本地 SQLite,部署在任何一台最便宜的 VPS 上,甚至直接跑在 GitHub Pages + Cloudflare Workers 上,可能早就上线了。

但我们总觉得"这样不够专业"。

过度工程的代价

技术圈有个怪现象:复杂的方案总是看起来更专业。

面试的时候,你说"我用了一个单文件应用",面试官可能会皱眉。但你说"我设计了微服务架构,用了 Kubernetes、gRPC、Event Sourcing",对方眼睛就亮了。

问题是,有多少项目真的需要这些?

我见过太多这样的案例:

  • 一个内部工具,日活 50 人,用了微服务架构,结果维护成本比开发成本还高
  • 一个静态博客,用了 Headless CMS + Next.js + Vercel,结果每次改个错别字都要等 CI/CD 跑 5 分钟
  • 一个简单的 API,用了 GraphQL + Apollo + Code Generation,结果查询复杂度爆炸,性能还不如直接写 REST

过度工程的代价不是即时的,而是延迟的。开发的时候觉得"这样扩展性好",但三个月后接手的人(可能是你自己)就会骂娘。

SQLite 的逆袭

Capsule 的核心技术之一是 SQLite。这个数据库很有意思,它可能是世界上部署最广泛的数据库,但也是最被低估的。

很多人觉得 SQLite 只能用于移动端或者嵌入式场景,“生产环境得用 PostgreSQL”。但事实是:

  • SQLite 的单表性能在很多场景下优于 PostgreSQL
  • SQLite 的备份就是复制文件,恢复也是
  • SQLite 不需要运维,不需要连接池,不需要调优

当然,SQLite 也有局限:不支持高并发写入,不适合分布式场景。但对于 90% 的 Web 应用来说,这些限制根本不是问题。

Capsule 选择了 SQLite,不是因为"新技术不成熟",而是因为"这个场景下它就是最优解"。

从复杂回到简单

我最近在想,技术选型是不是应该有个"复杂度预算"。

就像财务预算一样,每个项目的复杂度应该有个上限。超过这个上限,就要问自己:“真的需要这么复杂吗?”

比如:

  • 如果日活不到 1000,可能不需要微服务
  • 如果数据量不到 100GB,可能不需要分布式数据库
  • 如果团队不到 10 人,可能不需要 Kubernetes

Capsule 的价值不在于它本身,而在于它提醒我们:简单也是一种技术能力。

能把复杂的事情做简单,比把简单的事情做复杂难得多。

技术钟摆的下一站

我不确定 Capsule 会不会成为主流。也许它只是一个小众工具,也许它会引发一场"反过度工程"的运动。

但我确定的是,技术圈正在经历一次钟摆回归。

从云原生回到本地,从微服务回到单体,从分布式回到单文件。这不是倒退,而是修正。我们走得太远了,现在需要往回走一点。

就像 Capsule 的 slogan 说的:“No cloud. No account. Just a file.”

有时候,最简单的方案就是最好的方案。


参考资源

Built with Hugo
Theme Stack designed by Jimmy