每个路由具有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

此处的这篇博客文章解释了各种无服务器模式的优缺点。以下是一些注意事项：

每个路由一个Lambda，也称为微服务模式：

优点

• 由于每个lambda都具有非常特定的功能并且cloudwatch日志被很好地分开，因此调试起来更容易。
• 由于每个lambda处理一个单独的事件，因此更易于测试。
• 部署更细粒度。更新功能仅会影响特定功能，因此您有不同的关注点。

缺点

• 对于lambda，可能会有更多的冷启动，因为其中一些可能不会被频繁访问。

• 您可能最终需要管理许多lambda函数。

• 部署速度慢，因为要部署多个功能。
• 您可能很快就会遇到单个堆栈（200个资源）的cloudformation资源限制。我个人碰到过这个。

一个Lambda，具有多个路线，又称为服务/整体模式，具体取决于路线的分组方式：

优点

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

缺点

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

如您所见，每种方法都各有利弊，没有唯一正确的方法来做事情。另外，正如其他答案所暗示的那样，您还需要考虑诸如CICD，项目和时间限制之类的问题。

Answer 2

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

我在不同的项目中都做过，我想这归结为 CICD 的偏好、架构、时间限制。

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

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

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

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