amazon-web-services - 每个路由具有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处理一个单独的事件，因此更易于测试。

部署的粒度更细。更新功能仅会影响特定功能，因此您有不同的关注点。

缺点

由于某些lambda可能不经常访问，因此它们可能会更冷启动。

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

部署速度较慢，因为要部署多个功能。

您可能很快就会遇到单个堆栈(200个资源)的cloudformation资源限制。我个人碰到过这个。

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

优点

冷启动/性能更好，因为lambda会被频繁调用并保持温暖。

较少的lambda函数来管理。

部署速度更快，因为要部署的功能较少。

缺点

较难调试和分析cloudwatch日志，该函数可处理多种类型的事件。

您需要编写和维护路由器。

函数的大小更大，因此您可以达到部署大小的限制。

更新功能可能会导致回归并破坏其他功能。

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