本文最初发布于 Seve 的个人博客，经原作者授权由 InfoQ 中文站翻译并分享。

无服务器 10%的情况令人惊叹。剩下的 90%则是一个危险的黑洞，里面是云锁定、糟糕的测试、差劲的开发体验和复杂的设置。这就是为什么会有一些老人发誓不使用无服务器，同时又有大量的支持者（像我一样）试图把它推广到任何适合的地方。

不管是哪一方，都有一些事项需要留意。对于无服务器的支持者而言：

• 无服务器应用程序的架构并没有更简单；
• 无服务器消除/简化了 devops，因此，部署/devops 更简单了；
• 为了让无服务器产生预期的效果，你必须采用无服务器架构，这与许多公共框架（如 Rails）的最佳实践建议不相符；
• 没有哪个云提供商的最佳实践是真正的最佳实践。他们的兴趣在于把你锁定，因此，他们会尝试将自己融入到你的开发/测试工作流，或者在开发中需要云连接；
• 在同一个项目中使用多种语言并不是一项特性。

对于无服务器的反对者来说：

• 几乎可以肯定，遵循云提供商的最佳实践已经让你吃不消了，忽略那些试图锁定你的云提供商，你会过得更好。
• 运行本地版本是有效的无服务器 DX 的必要条件，任何像样的无服务器架构都很容易像 docker 容器一样运行。
• 有一种无服务器架构可以让每个人在大多数情况下都满意。但这通常不明显，因为它处于无状态服务器最佳实践和云提供商最佳实践的交叉点上，但永远不会完全是哪一个。

有效的无服务器架构

好了，现在我们已经冷静下来，我们已经认识到，无服务器不是编程和应用程序架构的救世主。现在可以开始构建简单、易于维护、可测试的应用程序了。

下面是无服务器架构必须做到的一些要点：

• 一切都必须能够在本地运行，与传统的有状态服务器一样（你需要能够运行自己的系统）；
• 每个端点都应该有针对本地运行的无服务器实例运行的测试；
• 以一种简单、易于理解的方式处理路由，例如使用文件路径作为端点或一个中心化的 JSON 配置；
• 完全正常。它应该看起来像一个 npm 包、一个 pip 模块等等。没有人需要通过看图表来理解它是如何工作的；
• 每个端点所需的样板文件都尽可能少；
• 整体式的代码组织，每个应用程序一个库，其中包含多个端点。

云提供商应提供以下特性：

• 自动扩展端点；
• 自动部署和版本控制；
• 易于回滚。

关于无服务器的恐怖故事

我曾见过有人在云提供商的云 IDE 中编写代码，两次测试之间要等 2 分钟。有时，一个端点连接到如此多的云服务，所以真的只能在生产环境中进行测试。有时不是所有端点都在一个库中，而是有很多库，每个库包含不同的系统组件。

开发体验是快速实施的关键，你应该努力保持快速的反馈循环和测试，让你可以快速前进，而不必担心整个系统崩溃。

优质的无服务器提供商

每个无服务器提供商都必须经过改造才能成为有效的架构。

每个无服务器提供商都试图让你不可逆转地将它们融入。你不需要把它们融入。遵循最佳实践，除非它违反了“必须在本地运行”的原则，否则你应该没事。

现在，我喜欢以下这两家无服务器提供商：

• Vercel——基于 AWS Lambda 构建，重视开发体验。优秀的自动部署和版本控制。非常友好的价格。我在把collegeai.com重构到 Vercel 之后遭遇了峰值流量，而它在第一天扩展时就没有出现任何严重的问题。你可能需要放弃他们的开发系统（vc dev ），以获得一个有效的容器化/本地运行的应用程序，但这并不困难。
• Cloudflare Workers——Wrangler（worker 的命令行开发工具）意识到本地开发的重要性，而 cloudflare worker 非常便宜。但是，我要提醒的是，它们对 NodeJS 模块的支持不是很好，所以它们还不是一个重要的选项，除非在低成本扩展绝对关键的情况下。

对于下面这两家提供商，我要提醒你注意：

• AWS Lambda（直接）——对于应用程序开发人员来说，AWS Lambda 太复杂了，我从未见过一个让人感觉正常、易于理解并且使用 Lambda 在本地运行的架构。
• Fastly——如果需要一个销售电话来开始，那么我可以打赌开发体验将很垃圾。

我还没有足够的经验，听说得也不是很多：

• Netlify——它似乎有一个正确的方法，但是我不理解他们的专业级无服务器定价，为什么人们通常是从这里开始。

这个领域正在迅速变化，当看到新的竞争者和新的架构时，我会更新这里的内容。

无服务器 90%的情况都很糟糕，但也有 10%的情况令人惊叹

炒作没问题，但要有理由支撑。无服务器使应用程序易于扩展和维护。我在7年前编写的无服务器应用程序仍然在运行，几乎不需要维护，也几乎不需要任何成本。我相信，无服务器可以使个人能够维护大型应用程序，否则将需要一个团队和稳定的收入流。