一文掌握Serverless中的异常处理 _云计算

来源：JavaEdge

0 介绍

在无服务器计算的世界中，AWS Lambda 已经成为构建可伸缩和高效应用程序的基石。虽然 Lambda 简化了代码的部署和执行，但强大的错误处理对于确保无服务器函数的可靠性至关重要。本指南探讨在 AWS Lambda 中进行错误处理的最佳实践，帮助构建具有弹性的无服务器应用程序。

1 Lambda 错误类型

深入研究错误处理策略之前，先了解 AWS Lambda 中可能发生的错误类型。

1.1 调用错误

当 Lambda 函数被触发但无法正确执行时发生。可能是由于诸如不正确的函数输入或权限不足等问题。

如通过 API Gateway 端点触发 Lambda 函数，但输入有效负载与预期格式不匹配。

1.2 运行时错误

运行时错误发生在 Lambda 函数执行期间。示例包括未处理的异常、语法错误或与外部依赖项的问题。

如在执行 Lambda 函数时，由于第三方 API 暂时无法访问，导致未处理的异常发生。

1.3 超时错误

Lambda 函数受到时间限制。如果函数的执行时间超过配置的超时时间，将导致超时错误。

如处理大型数据集的 Lambda 函数超过了配置的超时时间，导致超时错误。

2 错误处理的最佳实践

2.1 死信队列 (DLQs)

AWS SQS 中的死信队列 (DLQ) 是一个单独的队列，用于捕获和存储 Lambda 函数在处理 SQS 队列时无法成功处理的消息。

场景

假设有一个处理来自 SQS 队列的消息的 Lambda 函数。由于各种原因如意外数据格式、处理逻辑中的错误或外部依赖项的间歇性问题，一些消息始终无法被 Lambda 函数成功处理。

解决方案

为 SQS 队列配置死信队列，以捕获和存储无法成功处理的消息。使用 DLQ 进行调查并重新处理失败的消息。

DLQ好处

错误隔离： DLQ 有助隔离和包含错误，防止它们影响主流程
诊断洞察： DLQ 中捕获的消息作为有价值诊断信息，有助识别和解决bug
保持数据完整性： 与丢失潜在重要的消息相比，DLQ 允许通过为失败的消息提供辅助存储来保持数据完整性

2.2 带有指数回退的重试

场景

调用外部服务时，Lambda 函数经常遇到瞬时故障，这通常是暂时的，可能由于网络故障或外部服务的临时不可用导致。

解决方案

实现带有指数回退的自动重试，以减轻瞬时故障。这有助在暂时问题期间防止向下游服务发送过多请求。

指数回退是一种技术，其中重试尝试之间的时间呈指数增长。系统不会立即重试，而是在每次重试之间等待逐渐增加的时间。

2.3 日志记录

场景

Lambda 函数行为出现异常时，有效日志记录成为你发现异常行为背后的秘密的侦探工具。

解决方案

使用 logger 模块实现详细日志记录
利用 CloudWatch Logs 分析日志并识别异常行为的根本原因

详细的日志记录提供 Lambda 函数内部事件的踪迹。助你了解操作序列、变量值以及执行过程中遇到的任何潜在问题。

实现步骤

在 Lambda 函数代码中导入 logging 模块
根据需要的详细级别设置日志级别（例如 logging.INFO、logging.DEBUG）
在代码的关键点上，特别是在关键操作之前和之后，战略地放置日志语句

importlogging

logger=logging.getLogger()
logger.setLevel(logging.INFO)

deflambda_handler(event,context):
logger.info('Lambdaexecutionstarted...')

try:
#YourLambdafunctionlogichere

logger.info('Functionlogicexecutedsuccessfully.')

return{
'statusCode':200,
'body':'Functionexecutedsuccessfully!'
}
exceptExceptionase:
#Logtheerror
logger.error(f'Error:{str(e)}')

#Returnacustomerrorresponse
return{
'statusCode':500,
'body':'InternalServerError'
}
finally:
logger.info('Lambdaexecutioncompleted.')

2.4 自定义错误响应

场景

API 的消费者在收到缺乏细节的通用错误响应时面临挑战，使得他们难以诊断解决问题。

解决方案

增强 Lambda 函数以提供自定义错误响应，提供有关错误类型的有意义信息，并建议潜在解决方案。

如何实施自定义错误响应

错误代码标准化：建立 API 可返回的标准化错误代码集。这确保一致性，并使消费者更容易解释错误响应
带有上下文的错误消息：包括提供有关错误性质的描述性错误消息。这可能涉及指示问题是否与身份验证、数据验证或外部依赖项相关
HTTP 状态码：使用适当 HTTP 状态码传达错误的严重性。如对于客户端错误使用 400 Bad Request，对于与服务器相关的问题使用 500 Internal Server Error
包括诊断信息：如适用，包括错误响应中的诊断信息。这可能涉及到请求 ID、时间戳或与失败操作相关的特定标识符