我有一个具有3个模块和25个端点(模块之间)的应用程序。模块:用户、CRM、PQR
我希望优化AWS成本，并总体上尊重架构最佳实践。
- 我应该为每个端点构建一个lambda函数吗?
- 使用多个函数比只使用一个函数成本高吗?
Gustavos回答中的链接提供了一个不错的起点。我将根据你在评论中提到的标准详细说明。
您提到您希望针对成本和体系结构最佳实践进行优化，让我们从成本组件开始。Lambda定价相当简单，您可以在定价页面上查看。基本上，您要为代码运行的时间付费，以1MS为单位。每毫秒花费多少取决于您为Lambda函数提供了多少资源。Lambda通常不是你账单上最昂贵的项目，所以一旦它成为一个问题，我会开始优化它。
从定价的角度来看，Lambda函数的数量是少还是多并不重要。
就架构最佳实践而言，不存在放之四海而均通的参考架构，但Gustavo提到的帖子是一个很好的起点:组织大型无服务器应用程序的最佳实践。如何构建应用程序取决于许多因素:
- 开发团队规模
- 开发团队成熟度/经验(基于AWS技术)
- 应用程序中的加载模式 开发过程
- […]
您提到三个主要组件/模块，总共有25个端点:
用户- CRM
- PQR
由于您没有告诉我们太多关于技术栈的信息，我将假设您正在尝试构建一个REST API，作为某些前端应用程序的后端。
在这种情况下，您可以将这三个模块视为三个微服务，它们为应用程序实现特定的功能。它们每个都实现了几个端点(HTTP-Method和path的组合)。如果您开始使用API网关作为体系结构的入口点，则可以将其用作客户端内部体系结构的抽象。API Gateway可以根据HTTP方法和路径将请求路由到不同的Lambda函数。现在可以选择如何实现后端。我可能会从构建多个Lambda的公共代码库开始，并使用API网关将每个端点映射到Lambda函数。你也可以从更大的多用途lambda开始，并及时重构它们以提取特定的端点，然后使用API Gateway路由到更专门的lambda。
你可能已经注意到，这有点模糊，这是故意的。我认为你最终会得到和端点一样多的，但这并不意味着你必须这样开始。如果您刚刚开始使用AWS，那么管理一堆lambda和它们之间的交互似乎令人望而生畏。从更熟悉的架构开始，然后随着时间的推移重构它们，使其更加云原生。
这取决于您的体系结构以及您希望它如何解耦。下面是您了解最佳实践的一个很好的起点:
https://aws.amazon.com/blogs/compute/best-practices-for-organizing-larger-serverless-applications/