单体 Lambda 函数和微型 Lambda 函数之间的权衡是什么？

Question

我们一直遇到如何将职责组织到 AWS Lambda 函数中的问题。一个这样的例子涉及 CRUD 操作：

假设我们有四个类，W、X、Y 和 Z，每个类都有一组 CRUD 操作。如果我们为每个操作和每个类都有一个 lambda，那么这些 Lambda 将非常简单，可能太简单而无法证明 lambda 的合理性。我们可以为类的所有 CRUD 操作（创建 W、读取 W、更新 W、删除 W）编写一个 lambda。它将有一个 switch 语句来选择正确的 CRUD 操作。我们还可以为所有类的每个 CRUD 操作编写一个 lambda（创建 W、创建 X、创建 Y、创建 Z）。我们甚至可以让一个 lambda 完成所有工作，在业务逻辑周围使用嵌套的 switch 语句。

我在单台计算机上编程的经验让我讨厌让 lambda 为一个类做一个 CRUD 操作以外的任何事情。我还看过几位主持人说我的厌恶是有道理的。不幸的是，他们没有提供任何解释，所以我无法选择适合我的上下文的内容。

不费吹灰之力，我可以想到两个支持单体 lambda 的原因：

1. Lambda 冷启动将分摊到更多功能中，并且发生的频率会降低。
2. lambda 的编程开销大于函数。每个 lambda 都需要管理（部署、选择适当的资源参数等）。

除了拉取参数并将其传递给 switch 语句带来的复杂性之外，我对微型 lambda 的参数一无所知。

您的经验是否对单体 lambda 和微 lambda 之间的权衡产生了任何其他见解？

Answer 1

“Micro Lambdas”，正如你所说，实际上可能会产生更多的冷启动成本，因为你很可能使用同一个 SDK 来执行所有 4 个 CRUD 操作——你的依赖关系很可能是相同的 &现在，您有 4 次冷启动，而不是 4 次 CRUD 操作的 1 次冷启动。

仅当您需要有意识地拆分业务逻辑或 Lambda 的运行持续时间不断增加时，才拆分 Lambda。

否则，对于 CRUD 操作，100% 的时间将它们保持在一起；对于一个资源上的 CRUD 操作，您只会为自己创建 4 个不同的 Lambda，导致 4 个冷启动创建更多麻烦。

我用来确定 Lambda 是否变得太大的一个很好的个人指标是查看执行角色 - 这个角色中的策略是否有意义在一起？

如果没有，则分开，否则保持在一起，以便更易于管理项目。

为每个新的 CRUD 操作创建一个新的 Lambda 将单一责任原则降低到不应该的水平。