python - 在 Python 3.9 中编写 AWS lambda 代码时应遵循哪种设计模式

Question

我是一名Java开发人员，刚刚开始使用 Python。我写了一个AWS lambdapython 3.9中的代码。在第一次尝试中，我将完整的代码写在一两个文件中。但是在某处我读到我们不应该创建胖文件。然后我尝试将代码隔离到不同的文件夹和文件中。文件夹，如 handlers、services、utils、dao、entity。每个文件夹都有一个文件，每个文件都有许多函数，可以通过导入独立于另一个文件调用。然后一位 Python 专家告诉我应用 OOPS 概念，并遵循 DDD 设计或 MVC 模式。是否有必要遵循 OOPS 概念并在无服务器架构中创建类？您能否指出一些示例 GIT 存储库，展示用于开发面向对象 lambda 的框架？AWS lambda 在请求时被激活，并在请求被提供时消失。它不像没有请求的 24 小时活跃的服务器。

在还支持模块化编程的 Python 语言的 AWS lambda 代码中遵循的最佳设计模式或架构或编码范式是什么？

标签： pythonamazon-web-servicesdesign-patternsaws-lambda

Answer 1

这在很大程度上取决于您的用例。

Lambda 是无状态的。在 Lambda 中为大多数情况构建类没有什么意义，因为您无法将该类实例化传递到 lambda 之外。（这意味着您必须在连续调用的不同 lambda 中再次重新实例化它）此外，由于 Lambda 中时间和内存的限制，如果它们的范围较小，则最好 - 他们会做一两件事然后更新数据库或调用另一个 lambda 或在 Step Function 中继续。您可能创建的最有可能的类是 Struct 类型——在 python 中实际上并没有这种类型。python 中的字典执行与结构几乎相同的功能，并且开销要少得多。

清洁代码和 TDD 意识形态表明，最好在 Lambda 处理程序中连续调用许多小函数。这可以让您获得更好的测试模式和行为测试，而无需在测试组件时模拟一堆东西。

这也很有帮助，因为虽然您可以在本地运行您的 lambda 处理程序作为任何其他函数，但如果您尝试在 lambda 中使用其中的一些内容，并且在本地运行不会轻松访问模拟上下文，那么您将无法轻松访问意味着 lambda 将在部署后成功运行。所以测试很好，但不是确定的。但是，如果您可以验证所有较小函数的行为，那么在云中的 lambda 级别进行故障排除的工作就会少得多。

至于任何其他建筑模式......任何让你舒服的东西。您可以在 MVC 中使 lambda 成为控制器。然后，您可以围绕它组织您的文件结构。或者，您可以在 DDD 中为某个域收集一组 lambda，然后围绕它进行组织。老实说，一般来说没有最好的方法，只有对您的项目最有效和最有效的方法。

然而，当您进入多个 lambda 时，需要注意的一件事是它们是如何通过各种系统（如 CDK 或 Cloudformation）进行部署的。在这种情况下，最好让每个 lambda 在其自己的目录中仅在内部引用它自己（您必须使用 Python Imports 来获得乐趣才能使其在本地工作）