蟒蛇AWS蟒蛇蟒启动钩子？

Question

假设我有一些资源，我想在用python编写的aws lambda中的不同请求之间共享。我应该如何实现这一点？

是否有“启动后”挂钩，或者我应该在第一次调用时惰性地创建资源？“延迟初始化”的缺点是，它意味着一些请求会随机变慢，因为您选择了一个消费者来承担启动成本。

此外…这些资源会在lambda可执行文件被“冻结”后幸存下来吗？

本页https://docs.aws.amazon.com/lambda/latest/dg/runtimes-context.html谈论“初始化”阶段。如何在init阶段执行？这似乎表明Init包含“解冻”操作和冻结操作。

跨lambdas的AWS中的连接池

Answer 1

有几种方法取决于您的用例，但lambda尽可能“无状态”是非常重要的-您永远不能保证对lambda的任何调用都将重用同一个容器，或者容器将在下一次调用中保留-容器的decom时间（几乎）完全由AWS后端控制，而不是您真正可以预测的

方法一、使用案例：通用功能：

如果您已经编写了一堆通用实用程序功能，您希望在执行不同操作的多个lambda中包含这些功能（而不是对同一lambda的多次调用），那么您应该压缩您的助手/实用程序目录并将该zip作为图层添加到每个lambda。位于图层中的代码可以像任何其他自定义代码一样访问。此代码对该图层的当前版本是不可变的，但您可以随时上传新版本。当然，对于给定lambda的每个调用，图层都是相同的，无论它在哪个容器中

方法2：全局变量，在执行过程中不会更改的用例通用数据

如果您有一些资源密集的繁重工作，对于同一个lambda的多次调用只需要执行一次，并且每次都可以重复使用，并且在这个过程中不会发生变化（例如解析引擎要遵循的几个指令文件或加载pickled内存状态），然后可以将这些函数作为全局调用（在python文件中任何给定的def之外）。当容器第一次运行时，它们被加载/运行。这将导致冷启动lambda的启动速度慢得多，但它们可用于使用同一容器的任何调用。

您可以通过使用CloudWatch Events定期向您的lambda发送“保持活动”（即空白ping事件）来减轻容器的分解，以便它继续处于活动状态并且AWS后端不会分解该容器。（因此上面的“几乎”评论）

这可能会产生意想不到的后果，即启动并运行许多不需要的容器。这也降低了 lambda 的一些优势，即只“支付您需要的费用”，因为您实际上是在从持续运行的 lambda 中创建服务器。有一些高级方法依赖于在流量较高时发送事件，并在流量下降时停止这些事件，以允许大多数容器死亡，但何时解压缩它仍然在 AWS 上 - 这意味着如果 AWS 认为需要它，则给定容器的停留时间可能比您预期的要长得多。

当容器被分解时，此数据会丢失，当然是在内存中。

方法3：您自己的容器（用例-…取决于）

您可以提供自己的容器映像来运行lambda。如果这样做，您可以对任何其他容器映像执行任何操作，例如启动脚本等。结合保持活动事件，您可以更多地访问可能存储在内存中的值，这些值可以在lambda spin up时初始化，但维护、更新和访问要复杂得多，但功能也更强大。

整体

你不应该依赖以上任何一种技术，尽管在边缘情况下把它们放在你的工具带上有一些好处。相反，您应该考虑您的用例以及如何最好地利用云原生架构。需要什么数据？如果是只需要访问的普通数据，一个设计良好的dynamodb模式可以在一个200毫秒或更短的查询中检索所有数据。

如果其逻辑/初始化复杂，您应该考虑lambda是否适合您尝试做的事情，或者EC2集群是否是更好的解决方案——或者EC2集群Lambda其他资源的组合。

如果这是比较迟钝的，那么您应该花一些时间研究其他aws服务，看看其中一个是否可以为云提供您所需的服务