无服务函数：规避无限递归成本陷阱

MofCloud
FinOps
28 May, 2025

无服务器函数的无限递归可能导致成本失控，遵循最佳实践可有效避免陷入此类困境。云服务中的成本失控问题屡见不鲜：

例如未关闭高成本的虚拟机、泄露安全密钥，或无服务器函数的无限递归。无服务器函数的无限递归尤为棘手，因其近乎即时的调用和无限扩展能力，可能导致成本呈指数级激增，而非如其他服务般线性增长。虽然无法完全消除这一风险，但通过最佳实践，开发者能够显著降低陷入成本陷阱的可能性。

无限递归的原因与案例

在研究无服务函数时，许多开发者因误操作触发无限递归，导致成本超出预期。有时，开发者登录时发现账单已远超出预算。尽管新手或学生更容易遇到此类问题，但经验丰富的高级开发者也可能犯错，无人能完全免疫。

架构设计问题

无限递归的常见原因是架构设计缺陷

函数被某服务触发后，又直接或间接向同一服务写入数据，形成反馈循环。
在对象存储场景中，函数向对象存储写入数据，该存储触发函数，函数再次写入，从而形成无限循环。

类似问题也可能发生在消息通知、消息队列或 NoSQL 数据库等服务中，函数与这些服务的交互导致递归调用。虽然许平台提供内置递归检测机制以中断部分循环，但并非所有场景都能被覆盖。

重试机制问题

另一常见原因是重试机制，可能是手动编码或外部服务导致。

一个手动编写的重试逻辑在函数每次调用时触发，导致函数持续被调用，成本激增至数百美元。
外部服务重试。函数通过 Webhook 触发，但 API 网关的 30 秒超时返回 504 错误，外部服务未收到 200 OK 响应而重发请求，形成循环。尽管该循环因函数偶尔完成而非完全无限，但增加了调试难度。

退款与预防

了解这些常见的失败模式有助于开发者避免代价高昂的错误。对于正在面临成本失控的开发者，许多云服务商可能在第一次提供部分或全部退款。然而，依赖退款存在风险，且无服务商保证退款，处理过程可能耗时。

最佳的策略是通过合理的架构设计和预防措施，从根本上规避无限递归风险。

如何规避无限递归？

虽然无法完全杜绝无限递归风险，且云服务商通常不提供基于成本的自动关闭功能，但通过遵循最佳实践，开发者可显著降低风险并减轻潜在损失。

意识提升、研究最佳实践与测试

提升意识是首要步骤，了解无限递归的可能性及其高昂成本可促使开发者更加谨慎。熟悉常见原因（如架构缺陷、重试机制）有助于识别风险点，降低重复他人错误的概率。在编写代码前，开发者应深入研究并精心规划架构，明确函数交互的服务及其潜在风险区域。

例如，若函数与云服务交互，推荐确保触发函数的服务与其写入的资源不同，以避免反馈循环。对于对象存储触发的函数，使用独立的输入和输出存储桶可防止递归触发。例如，阿里云 OSS 或 Azure Blob Storage 可配置不同桶。若必须使用同一资源，建议采用正向触发机制，如基于命名规则或元标签的触发条件，仅在首次调用时激活。

对于重试机制，建议尽量避免函数直接调用其他函数，而应使用工作流编排工具（如阿里云函数或 Azure Logic Apps）。此外，无服务器函数通常默认重试两次，额外重试机制可能冗余。对于 API 调度的场景，可考虑使用函数 URL（如 Google Cloud Functions 的 HTTP 端点）直接触发，绕过 API 调度超时风险。

新手开发者往往不熟悉具体场景的最佳实践，因此在实施前深入研究尤为重要。此外，通过自动化和手动测试可提前发现潜在问题。模拟边缘场景、测试超时设置，并分析函数在不同条件下的行为，有助于避免意外创建递归循环。

内置递归检测

许多平台提供内置递归检测功能，可在特定场景下中断循环，例如涉及对象存储、消息队列或消息通知的循环，通常在约 16 次调用后停止。然而，该功能并非万能。例如，若循环涉及 NoSQL 数据库（如 Google Firestore 或 Azure Cosmos DB），可能仍形成无限递归。此外，部分运行时（如自定义运行时）可能不支持此功能。