务器函数都面临着相同

Mitu46544

发现将有状态行为引入到无状态环境中会遇到一些困难。让我们深入了解如何有效利用无服务器功能同时避免常见的陷阱。常见的无服务器缺点抛开底层运行时的差异不谈所有无服的挑战它们是短暂的部署。现有的函数实例可以随时关闭而新实例可以在不了解先前处理的情况下创建。这对于需要访问非临时数据存储的服务非常不利。例如考虑如果出现以下情况会发生什么某个功能在交易过程中被关闭扩展策略会导致一万个新函数连接到数据库长时间运行的查询或多个查询使函数调用。

时间比平均值长得多在为无服务器环境开发应用程序时假设此类问题可能并且将会发生始终很重要。避免无服务器头痛为了说明问题是如何出现的让我们看一个简单的例子。以下是一个简单的处理 电话号码清单 程序它接受在数据库中查询具有该的项目然后返回结果对象。在非无服务器环境中此函数不会对性能产生任何影响但在无服务器环境中如果没有某些保护此函数可能会对您的应用程序和您的钱包造成严重损害。例如如果此应用程序的使用量大幅增加您可能会看到数据库很快耗尽连接。这可能会导致响应时间变慢和超时从而降低您的有效处理速度。



为了避免这种并行化问题让我们看一下可以对应用程序进行的三个简单配置更改。这些更改按照影响最小最不困难到影响最大最困难的顺序排列。更改客户端连接池大小大多数包括都有一种方法可以修改客户端与底层数据库保持打开的连接数量称为连接池。默认情况下池中的连接数可能会有所不同但通常在到个连接之间。如果您参考上面的示例如果每个函数保持个连接打开即使考虑大量连接也可能会减少一个数量级在大多数情况下将池大小设置为最大值将使您的应用程序保持运行同时还保证来自函数的连接数永远不会超过并发运行的函数数。