无服务器90%的情况都很糟糕

文章来源：infoqSeve

本文最初发布于 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——它似乎有一个正确的方法，但是我不理解他们的专业级无服务器定价，为什么人们通常是从这里开始。

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