AWS 无服务器开发现状

在这篇文章中，我想分享我对 AWS 无服务器开发人员现状的考虑和个人看法。

多年来，AWS 无服务器产品不断发展。我从 2016 年开始使用 AWS Lambda 函数进行开发，这些进展和最佳实践使我能够构建可扩展的应用程序。可扩展性是一个很重要的词，我们应该用数字来衡量它。就我而言，我无需动一根手指，只需运用 AWS 无服务器 DA 团队多年来不断呈现的实践，就能达到每分钟数百万个请求的处理速度。

Lambda 本身并不算什么，事实上，无服务器产品很早就开始了：

当前的问题是，人们在不了解无服务器架构的必要性的情况下就加入了这趟列车。很多人会说，无服务器架构需要转变思维，或者学习起来更困难，因为你需要连接所有服务。但我发现，对于像我这样已经涉足无服务器架构一段时间，并且体验过两种技术的人来说，这些说法都不成立。

在成为一名优秀的无服务器开发人员之前，您必须了解以下概念：

• 依赖注入
• 领域驱动设计
• CQRS
• 事件溯源
• 六边形架构
• 三层架构
• 对象关系映射
• 存储库模式
• 面向方面编程 (AOP)
• Automocker
• SOAP、WPF、REST
• 事件总线、消息传递
• 以及更多...

除此之外，您还需要打包所有内容并部署到某个服务器上，然后您需要进行专业化或将任务交给下一个团队并希望获得最好的结果。

有了无服务器和单一职责，Lambda 就变得简单了，我不需要上面的大多数概念，因为现在流程很简单：

• 处理输入中的事件
• 做某事、转变等等
• 发出事件
• 返回

这并不意味着您可以跳上无服务器列车并期待奇迹。

如果您想成为无服务器开发人员，那么除了行业中始终有效的基础知识之外，您还必须了解所使用的提供商的最佳实践。

我喜欢说无服务器开发就像

我有许多具有特定配置的组件，必须将它们连接起来才能创造出精彩的作品。作为一名开发人员，我必须尽自己的一份力，因为即使无服务器架构能够凭借内置的并行和并发功能自动扩展，如果我没有正确连接这些组件，我的应用程序也将会失败。所以，以前你只需要“这是我的应用程序，请让它在集群中运行”，但现在这会给你带来麻烦，这就是我写这篇文章的原因。

我认为开发人员有三种类型（非常普遍，实际情况可能更复杂）：

• 只为薪水而工作的人
• 喜欢却懒得学，宁愿一辈子安逸
• 热情的

前两者总是有这样的借口：

• 我没有时间
• 我需要一直训练
• 我不同意这些标准
• 我更清楚
• 好吧，我想这样做
• 我不需要帮助
• 我不想升级它

尽管上述情况很普遍，但事实上这种行为无处不在。人们常常在没有真正尝试的情况下就开始使用无服务器、集群或其他新技术，结果却引发了更多问题甚至更糟的情况，并抱怨说最好还是继续沿用过去十年来的做法。

这就像因为我撞车了就说法拉利并不比菲亚特好一样。

当人们开始使用无服务器架构，特别是 Lambda 架构时，我经常看到一个问题：普通开发人员会抱怨无服务器架构不如传统的集群快。这时，我提出了三个让我感到不舒服的问题，让自己成为了头号敌人：

我发现，几乎每次人们都会不假思索地尝试运行无服务器函数。
使用 AWS Lambda 时，我们应该了解 Lambda 的生命周期：

Lambda 生命周期包括以下 3 个阶段：

初始化

• 启动所有扩展
• 引导运行时设置环境（内存、运行时等）
• 下载代码，
• 运行函数的初始化代码（处理程序之外的代码）

调用

• 调用处理程序
• 函数运行完成后
• 准备处理新请求

关闭

• 提醒扩展程序让它们干净地停止
• 然后，删除环境

简而言之，当请求到达且 Lambda 尚未运行时，AWS 需要部署代码并启动一个包含所有配置的新容器，然后才能开始处理请求（INIT）。容器准备就绪后，它将执行处理程序（INVOKE）。第一次调用后，容器即可处理第二个请求，直到没有请求传入，此时 Lambda 服务将冻结容器或将其关闭。

考虑到生命周期，作为一名开发人员，我知道我可以减少延迟并提高 Lambda 冷启动和调用的吞吐量。

无论我的 Lambda 函数运行的运行时如何，众所周知我都应该遵循以下最佳实践：

• 部署小包
• 使用 Lambda 执行上下文
• 避免使用 Fat Lambda
• 尽可能使用并行
• 使用 Arm64 架构
• 找到最佳内存平衡

我可以向你保证，大多数时候，甚至很多时候，都没有遵守。

无服务器开发在 2022 年将处于一种几乎对所有事物都明确的选择的状态，因为我们已经达到了生态系统成熟（并非完美）的阶段，并且有许多社区可以效仿，例如：

• 无服务器 DA
• 社区建设者
• AWS 英雄
• AWS 无服务器专家

忽略基础知识是相当困难的，但不知何故，我们作为行业仍然忽视最佳实践，而且我常常想知道这怎么可能（参见上面的 3 种类型的开发人员）。

如你所知，我喜欢用 Rust 编写 Lambda 函数。我的职业生涯始于 .NET，2016 年我迁移到 Node.js，从此再也没有回头。我曾努力从编译型语言转向解释型语言，但当时，它是唯一的选择，而且除了编程语言之外，使用 Node 还有一个显而易见的原因。

随着时间的推移，我逐渐习惯了不同的语法以及语言带来的负担，并开始考虑成为一名多语言开发者（目前仍在努力）。当然，就像所有事情一样，多语言开发有利有弊，我经常承认自己记不住正确的语法，或者会把语法搞混。不过，我发现这项技能（如果你愿意这样称呼它）在无服务器开发中很有帮助。随着年龄/职业的发展，我不再对某一门语言感兴趣了，让我来告诉你原因。

我面临一个问题——“构建一个可扩展且成本较低的应用程序”。

有人说，你不可能以更低的价格构建一个可扩展且可靠的应用程序。但现在这种说法已经不再完全正确，因为我们现在已经处于一个可以用任何编程语言编写AWS Lambda 运行时的时代。

让我明确一点：我并不主张改变运行时并重写所有应用程序。有很多因素需要考虑，比如技能、公司政策、心态、管理人员等等，但我相信我们已经进入了无服务器开发的某个阶段，运行时可以发挥重要作用。

在单一职责函数的世界里，复杂性几乎降为零，我们只需要掌握编程语言的语法，这对于软件开发者来说应该不成问题（随便复制粘贴或四处询问）。假设某个运行时不支持某些功能或存在 bug，我可以轻松地运用乐高的思维，在不同的运行时编写 Lambda 函数，而不必局限于某个运行时。

由于所有运行时并非生来平等，我们今天知道最慢和最昂贵的运行时顺序如下：

• Node 和 Python
• Java 和 .NET
• Golang 和 Rust

如果我们考虑以下测试：

我能看到最慢和最快的运行时之间的区别。假设每秒请求数为 1000，每月持续进行，那么计算量将节省 15% 到 35%（基于内存设置），这还不考虑应用程序吞吐量的提升以及最终用户的整体收益。

我们需要用 Rust 或 Golang 重写所有内容吗？当然不需要。我的目标是，无服务器开发不再像以前那样。它允许更多功能，赋予你更强大的能力，如果使用得当，将带来前所未有的回报。

想象一下，你身处一级方程式赛车界，分秒必争。你想加入哪支车队？冠军队，还是垫底的那支？