Introduction > Lambda高阶 > Lambda Destinations

Lambda Destinations

2019年Lambda推出了新特性，对于异步调用和Event Source Mapping方式可以配置Destination，将执行结果(无论是成功还是失败)发送到其他AWS服务。

这个特性改善了函数执行的结果可见性，简化了事件驱动型应用的开发。

使用Destinations，可以将异步调用的执行环境发送到其他AWS服务，里面包括了Lambda执行时的变量环境及执行结果。异步调用时，

有可能执行成功也有可能执行失败，针对这两种情况可以将结果发送到不同的destination： Lambda function, SNS, SQS, 或 EventBridge：

Asynchronous Function Execution Result

在讲异步调用时，我们也配置了DLQ(2016年推出的特性)，用于接收执行失败时的Lambda环境。和DLQ比起来：

Destination提供了额外的信息，包括执行时的参数值及Lambda执行结果。并且可选的目的服务更多，除了SQS外，还增加 SNS、Lambda、EventBridge服务。
DLQ和Destination可以一起用，但目前AWS更推荐使用Destination。
如果DLQ和Destination一起用，则两者同时生效，互不影响。

理论总是枯燥的，下面一个实验将有助于理解上面所有的描述。

本节我们将复用上一节搭建的资源——S3 Event Notification + Lambda。在此基础上添加两个Destination配置，将成功执行的结果发送到success-sqs里，将执行失败的结果发送到failure-sqs:

请先完成上一节的内容，再进行本节

创建两个SQS, 分别用于接收Lambda执行成功和失败时的信息:

回到Lambda页面，点击Add destination :

对于Lambda异步调用失败时，Destination选择failure-sqs:

添加完成后，再次Add Destination。这次对于Lambda异步调用成功时，Destination选择success-sqs:

再次点击保存。Lambda界面的Destination此时显示有两个SQS：

Lambda要想往Destination写数据，前提是Lambda有访问对应SQS的权限。在添加Destination时，不用提前向Lambda Role里添加对应的访问权限，AWS会帮我们自动完成，这个设计非常人性化。

向S3中上传一个文件：

上传完成后，S3 Event Notification将调用Lambda，Lambda在执行成功后，会将消息发送到success-sqs这个Destination。

回到SQS页面，发现success-sqs中此时新增了一条消息：

查看这条消息内容：

里面是Lambda的event参数及执行结果等信息：

上面是Lambda异步调用成功时的逻辑，我们再测试下调用失败时的行为。

更新hello-world代码，人为的触发执行异常：

import json

def lambda_handler(event, context):
    # TODO implement
    print(event)
    raise Exception("something went wrong")

重新往S3中上传一个文件。

此时的流程为：

S3 Event Notification异步调用Lambda => Lambda执行失败并触发重试机制 => 等3min过后依然执行失败 => 将结果发送到failure-sqs Destination

等3min过后，查看SQS：

进入queue查看消息具体内容：

Lambda会将执行时的环境参数及异常报错信息一同发送到SQS中

对于Event Source Mapping类型的调用，一样可以配置Destination：

当Lambda从DynamoDB或Kinesis拿到数据时，如果处理失败，可以将当时的环境发送到SNS或SQS。