无服务器模式并非骗局。

你现在读到的这篇文章包含很多事实，但也包含很多我的个人观点。这篇文章是对以下帖子的回应：

无服务器模式是个骗局。

乔纳斯·舒尔茨 ・ 4月16日

#无服务器 #Docker #云 #Web开发

请务必留言告诉我你的想法！

“每当有人选择使用无服务器架构来构建简单的后端时，我内心的一个容器就会死去。”
Jonas Scholz ( @code42cate ) 的文章《无服务器架构是个骗局》就是这样开头的。

每次看到这样的帖子，我内心深处的无服务器部署理念都仿佛被扼杀了🥲
其实，每次看到这样的帖子，我都觉得无服务器和容器的概念被误解了。在这篇文章里，我想谈谈关于无服务器和容器的很多问题，尤其是Jonas帖子里的一些观点。当然，我绝对没有不尊重Jonas的意思。🙂

什么是无服务器？

原文：

无服务器架构意味着你将各个功能部署到云平台，云平台会负责资源调配、扩展和执行。你无需管理服务器——只需将代码上传即可。

作者将无服务器定义为“部署单个函数”。这就是函数即服务 (FaaS)，它是无服务器架构的一种。像 Vercel、Netlify、Cloudflare 等无服务器提供商，其功能早已远不止于函数。例如，许多提供商支持Fluid Compute、边缘中间件、长时间运行的后台函数（尽管这确实更复杂）、完整的 Web 应用等等。

当然，一个合理的批评是，这些方案大多是对FaaS核心局限性的“修补”。例如，长时间运行的后台任务通常需要集成或单独的服务，因为原生FaaS平台通常对持久性或定时任务的支持不佳。这是一个实实在在的限制，在设计系统时应该权衡利弊。

容器……

原文：

你知道什么方法有效吗？

一个容器。

• 启动很快
• 跑遍任何地方
• 保持状态（只需添加一个 Docker 卷！）
• 没有任意的时间限制
• 你可以附加调试器，使用你喜欢的运行时环境，并在本地或生产环境中运行——无需任何特殊技巧或规则

例子：

docker run -v my-data:/data my-app

Boom——有状态工作负载，可在您的笔记本电脑、VPS 或边缘节点上运行。
无厂商锁定。无隐藏费用。无需重写应用程序以适应他人的限制。

容器固然好用，但管理起来却并不简单！你仍然需要搭建 CI/CD 流水线；管理负载均衡、自动扩缩容、监控等等；还要处理故障和回滚。
在你告诉我“但是有很多工具可以帮你搞定这些繁琐的工作”之前，请先停下来。的确有一些工具可以处理容器相关的工作，也有一些工具可以处理无服务器架构相关的工作。但是，你不能一边抱怨无服务器提供商的厂商锁定和配置问题，一边又给我推荐一个同样被厂商锁定的容器管理器。
话虽如此，厂商锁定确实是使用无服务器提供商时需要考虑的一个问题。一旦你使用了他们的存储、后台任务和队列，迁移就会变得非常困难。这可能需要重写应用程序的部分代码，而这确实很麻烦。

我希望事情真像这么简单docker run -v my-data:/data my-app，但我自己的网站就遇到过这种情况，并非如此。你经常会写出冗长复杂的Dockerfile文件，还要用到诸如此类的工具docker-compose来解决一些简单的问题。

无服务器定价模式令人困惑？

原文标题是“无服务器定价：旨在让你感到困惑”。实际上，无服务器定价的设计正是基于其自身的工作方式。由于它会随着使用量而扩展，因此可能会比较复杂。这与全天候运行、不受流量影响的容器截然不同。

原文：

无服务器定价是一种不正当的定价模式。

• 每次调用都需要付费
• 内存使用量
• 每执行时长
• 每GB传输量
• 按地区
• 每次访问秘密（没错，是真的），定价页面有五层之多，充斥着诸如此类的自造术语：
• 已配置并发单元
• GB秒
• 请求分为 1/2/3 级。更糟糕的是，你直到收到账单才知道自己要付多少钱。带宽价格尤其离谱。2025 年出站流量居然要 0.55 美元/GB？为什么？相比之下，每月 5 美元的 VPS 价格固定，而且完全可控。容器服务完胜。

对于初创公司和自由开发者来说，无服务器架构非常棒，因为许多平台都提供完全免费的无服务器部署（例如 Netlify）。
至于计费的可预测性，它确实可以做到。大多数无服务器提供商都允许您轻松设置消费限额。而且，这种出口定价模式适用于所有云提供商，而不仅仅是无服务器架构。

好吧，我得公平地说。如果你用的不是免费套餐，你的体验可能会截然不同。如果你流量远超预期，并且在没有消费限额的情况下大量调用函数，你可能会收到一张相当惊人的账单！

无服务器架构=意大利面条式架构？

原文：

“但是无服务器架构可以扩展！”

当然可以——理论上是这样。但那又怎样呢？为了你那只有4个用户的应用吗？

大多数应用并不需要“无限扩展性”。它们需要的是：

• 可预测性
• 可观测性
• 合理的资源限制
• 一个可用的开发/测试环境

你知道什么最适合做这件事吗？容器。

水平扩展非常简单（这就是 Docker Swarm）：

replicas: 5

或者把它放在负载均衡器后面。这样既能获得可扩展性，又能控制代码——而无需将应用程序重写成一堆互不相连的函数。

首先，就上面列出的所有要点而言，无服务器架构表现良好。但无服务器架构是否会造成“意大利面条式代码”则取决于你的应用构建方式。如果你将每个功能都设计成微服务，那么确实可能会出现意大利面条式代码。但这正是框架（例如 Next.js、Remix 等）的意义所在。你可以在同一代码库中编写包含 API 路由、后台任务和前端的完整应用。它非常结构化，完全不会出现意大利面条式代码。
此外，无论你的应用是无服务器架构还是容器化架构，在应用中出现“互不关联的功能意大利面条式代码”都是很常见的现象。

无国籍并不一定是坏事！

原文：

无状态设计 = 人为问题
Serverless 无服务器架构强制实现无状态。这意味着：

• 没有内存缓存
• 没有临时文件
• 没有粘滞会话
• 没有长期的联系

所以现在你需要：

• 外部数据库
• 分布式缓存
• 文件存储桶
• 活动巴士
• 用于协调状态机的状态机

突然间，你那“简单”的无服务器应用竟然依赖于六个 SaaS 平台（每个平台都有自己的计费方式、API 和故障处理机制）。
与此同时，在一个容器中：

• 你可以将缓存存储在内存中
• 写入磁盘（Docker 卷）
• 保持会话
• 跑多久都行

你知道——就像一个正常的程序一样。

正如我的标题所示，首先要澄清的误解是“无状态就是不好的”。无状态有时可能令人烦恼，但它鼓励最佳实践。它：

• 便于扩展
• 防止会话粘滞问题（是的，没有会话粘滞是一件好事）
• 鼓励使用持久存储、Redis 等。

顺便说一句，出于诸多原因，将会话保存在内存或 Docker 卷中都是非常糟糕的
做法。它既不安全也不持久。 尤其不应该将重要数据保存在容器内存中。这样做既不安全也不可扩展。Docker 卷并不能神奇地让系统实现分布式或可靠运行。

尽管如此，要实现无状态系统，往往需要将多个外部服务拼接在一起。对于简单的用例来说，这可能属于过度设计，而且会引入更多组件。Serverless 的优势在于合适的工具和规划，但并非适用于所有情况。

“不想管理服务器？那就用 X 吧！”

原文：

“但我不想管理服务器！”
太好了。你不需要管理服务器。

有些工具可以让你无需通过 SSH 连接到任何设备即可使用基于容器的平台：

[工具列表已移除]

你仍然可以获得基于 Git 的部署、回滚、日志、指标——但你可以决定事情如何运行，而且你实际上可以了解系统。

作者说“直接用 X/Y/Z 就行了”，这些都是抽象概念。你不能一边抱怨无服务器架构是抽象概念，一边又给我提供一个抽象概念，你应该用同样的标准来评判它们！
另外，非无服务器架构的回滚体验非常糟糕。使用无服务器架构，你可以在几秒钟内（通常甚至更短）启动任何先前的部署！而在容器中，除非你存储了所有先前的构建输出，否则你必须在特定版本或提交中重新构建，这需要时间，通常很长。远不止几秒钟。

容器确实提供了更大的控制权，尤其是在您想要自定义部署管道、使用自己的 CI/CD 工具或运行不适合无服务器执行模型的工作负载时；这真的取决于项目。

无服务器模式更便宜

其实这取决于你的具体使用场景。但对于大多数情况（也就是无服务器架构的设计初衷），无服务器架构更经济。
很多服务商都允许你部署 200 个甚至更多项目，超过 50 个域名，而且部署数据保留期无限。这一切都只需0 美元。这两种方案的定价都非常优惠，也充分体现了无服务器架构的高效性。

原文：

“无服务器模式更便宜！”真的
是这样吗？

或许，每天可以念诵五次。但当你：

• 保持稳定的流量
• 需要更多内存
• 实际计算
• 传输数据

成本飙升。而且由于平台将所有东西都抽象化了，所以你几乎无法进行任何优化。

与此同时，集装箱：

• 在廉价硬件上全天候运行
• 可以与存储或缓存共置
• 易于进行基准测试和调优
• 不要按毫秒收费

每天 5 次调用是对无服务器架构的严重误解。在 Netlify 或 Vercel 的免费套餐中，我每天可以进行超过3 万次的
中间件调用。 无服务器架构能够很好地处理稳定和不稳定的流量，因为它具有可扩展性。但是，一旦计算量增大、内存使用量增加、数据传输量增大等等，无服务器架构的成本确实会迅速增长。而且，由于平台抽象了很多内部细节，因此在那种情况下优化性能或成本会更加困难。

不过，我想指出的是，容器（特别是托管在VPS等服务器上的容器）是按时间收费，而不是按使用量收费。所以“不按毫秒收费”的说法在技术上是正确的……但这仅仅是因为他们通常按月或按年收费。

无服务器架构何时真正适用

原文：

好吧，公平地说——无服务器架构有其适用的领域：

• 事件驱动函数（例如，图像大小调整）
• 不经常执行的任务或网络钩子
• 轻型内工具
• 概念验证
• 真正需要快速扩展和缩减规模的事物

如果您的工作负载确实是间歇性的、无状态的，并且您希望零运维投入，那么无服务器架构可能适合您。

但对于真正的应用程序来说呢？你会遇到瓶颈。而这个瓶颈会让你损失金钱、时间和精力。

呃……什么？“事件驱动函数、Webhook、概念验证、轻量级工具、真正需要扩展的东西”这个列表，涵盖了大多数初创公司、最小可行产品、内部工具和JAMstack网站。Serverless正是为这些而设计的。

如果你要搭建 YouTube、实时游戏服务器或其他类似应用，或者需要用到 WebSocket 的应用，容器可能是更好的选择。但对于作品集、博客、电商平台、MVP 等应用来说，无服务器架构才是最佳选择。

总而言之

总结如下：

无服务器架构并不完美，容器也一样。
容器非常适合需要完全控制、持久化工作负载等情况。
而无服务器架构在追求速度、简洁性、可扩展性和零运维时则无可匹敌。
你不必非此即彼，选择合适的工具即可。

未来不是“无服务器与容器之争”，而是混合模式，平台无关的开发者将会胜出。

之后

我对原文有两点主要怀疑。

首先，原文是由人工智能生成的。我一开始不确定是否值得花时间写一篇回应文章，但后来还是决定写，因为我已经很久没写东西了，而且最近一直在思考无服务器架构。

@muos12的置顶评论很好地概括了我的第二个怀疑：

测试1 rtest3 • 4月17日

这篇博文只是 sliplane.io 创始人的一篇营销文章。
读着读着，感觉有点失望，因为它太片面了。文章完全没有解释服务器管理的挑战，比如操作系统补丁、扩展时如何保持高可用性等等。
像 Netflix 这样的大公司已经使用无服务器架构好几年了。还有很多相关的白皮书和 TED 演讲。

本文仅用于营销目的。

希望这篇文章对你有所帮助！欢迎在评论区留下你的看法！