本文最初发布于 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年前编写的无服务器应用程序仍然在运行,几乎不需要维护,也几乎不需要任何成本。我相信,无服务器可以使个人能够维护大型应用程序,否则将需要一个团队和稳定的收入流。
查看英文原文:
评论