每条路线有1个Lambda函数更好吗？还是1个处理子路线的Lambda？

Question

如果我有一个具有以下路由的API

POST /slack
POST /slack/hook
POST /slack/another-hook
POST /slack/hook/nested

在API网关中有4个独立的Lambda函数和4个路由更好吗？或者为根路由设置1个Lambda并让Lambda从那里处理路由？

例1

POST /slack --> lambda1
POST /slack/hook --> lambda2
POST /slack/another-hook --> lambda3
POST /slack/hook/nested --> lambda4

例2

POST /slack --> lambda1
POST /slack/hook --> lambda1
POST /slack/another-hook --> lambda1
POST /slack/hook/nested --> lambda1

这是最好的做法吗？如果是这样的话？

Answer 1

这篇博客文章here解释了各种无服务器模式的优缺点。以下是一些要记住的事项：

每个路由一个Lambda又称微服务模式：

优点

• 更容易调试，因为每个lambda都有一个非常特定的功能，而且cloudwatch日志很好地分开。
• 因为每个lambda处理一个单独的事件，所以更容易测试。
• 部署更精细。更新功能只会影响特定功能，因此您可以分离关注点。

缺点

• lambdas可能会有更多冷启动，因为其中一些可能不经常访问。
• 您可能最终需要管理很多lambda函数。
• 部署较慢，因为有多个部署功能。
• 您很快就会遇到单个堆栈（即200个资源）的cloudformation资源限制。我亲自遇到过这个问题。

一个Lambda具有多个路由，即服务/整体模式，具体取决于路由的分组方式：

优点

• 较少的冷启动/更好的性能，因为lambda会经常被调用并保持温暖。
• 更少的lambda函数来管理。
• 由于部署的功能较少，因此部署速度更快。

缺点

• 更难调试和分析云计算日志，功能处理多种类型的事件。
• 您需要编写和维护路由器。
• 更大的函数大小，因此您可以达到部署大小限制。
• 更新函数可能会导致回归并破坏其他一些功能。

正如您所看到的，每种方法都有利有弊，没有一种正确的方法可以做到。另外，正如另一个答案所示，您还需要考虑CICD，项目和时间限制等事项。

Answer 2

如果有人说有正确和错误的答案，我会感到惊讶。

我已经完成了不同的项目，我想它归结为CICD偏好，架构，时间限制。

从理论上讲，一个lambda可以简化您的体系结构，但有效地构建一个具有适用于该体系结构的所有缺点的单一应用程序，但是，如果您是单个开发人员，它可以显着减少构建，测试和部署过程，因此您不必担心lambda之间的依赖关系并且有一个可部署的工件。

另一方面，多个lambda函数为您提供类似于微服务的灵活性，但它需要您拥有单独的管道，整个CICD生态系统变得更加复杂和耗时。

在一个lambda函数中包含所有代码时要注意的更多事情是，大小限制和潜在的依赖性地狱，取决于您的语言。

不知道你的组织/项目和时间限制，我可能会从一个lambda开始，如果需要，稍后将其拆分为多个lambda函数...