最近，我們為Sigma Cloud IDE上的無服務器項目引入了兩個新的AWS Lambda事件源（觸發類型）： SQS隊列和DynamoDB流 。 （是的，AWS在幾個月前就向他們介紹了；但是我們仍然是一個很小的團隊，還遇到了其他一千件事！）

在開發對這些觸發器的支持時，我注意到Lambda事件源觸發器配置的常見模式（是的，很明顯）。 我覺得值得分享。

為什么AWS Lambda觸發器搞砸了

Lambda –或更確切地說，AWS –具有一個相當奇怪且混亂的觸發器架構； 輕輕地說。 對于不同的觸發類型，您必須在各處進行配置。 CloudWatch Events規則的目標 ，API Gateway端點的集成 ，S3存儲桶事件的通知配置等。 考慮到其他平臺（例如GCP），您可以在一處配置所有東西，這真是一團糟：實際目標函數的“觸發”配置。

到處都是。

如果您已經使用基礎結構作為代碼（IAC）服務（例如CloudFormation（CF）或Terraform（TF）） ，那么您已經知道我的意思了。 您到處都需要映射，鏈接，權限和其他提示，以使簡單的HTTP URL正常工作。 （ SAM確實確實簡化了這一點，但它有其自身的局限性 -我們已盡力避免Sigma IDE中的此類復雜性。）

考慮到AWS提供的服務的多樣性及其時間表（也許畢竟，Lambda只是一個四歲的孩子 ），這也許是意料之中的。 AWS當然應該必須進行一些瘋狂的黑客操作，以支持從眾多服務中觸發Lambda。 從而造成混亂，分散的配置。

事件源映射：隧道盡頭的光？

幸運的是，最近引入的流類型觸發器遵循一種常見的模式：

• 一個AWS Lambda事件源映射 ，以及
• Lambda的執行角色上的一組權限聲明 ，使它可以分析，使用和確認/刪除流上的消息
• 服務級別權限，允許事件源調用該函數

這樣，您確切地知道應在何處配置觸發器，以及如何讓Lambda使用事件流。

沒有更多的跳躍。

當您基于IAC（例如CloudFormation）時，這非常方便：

{ ... // event source (SQS queue) "sqsq" : { "Type" : "AWS::SQS::Queue" , "Properties" : { "DelaySeconds" : 0 , "MaximumMessageSize" : 262144 , "MessageRetentionPeriod" : 345600 , "QueueName" : "q" , "ReceiveMessageWaitTimeSeconds" : 0 , "VisibilityTimeout" : 30 } }, // event target (Lambda function) "tikjs" : { "Type" : "AWS::Lambda::Function" , "Properties" : { "FunctionName" : "tikjs" , "Description" : "Invokes functions defined in \ tik/js.js in project tik. Generated by Sigma.", ... } }, // function execution role that allows it (Lambda service) // to query SQS and remove read messages "tikjsExecutionRole" : { "Type" : "AWS::IAM::Role" , "Properties" : { "ManagedPolicyArns" : [ "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole" ], "AssumeRolePolicyDocument" : { "Version" : "2012-10-17" , "Statement" : [ { "Action" : [ "sts:AssumeRole" ], "Effect" : "Allow" , "Principal" : { "Service" : [ "lambda.amazonaws.com" ] } } ] }, "Policies" : [ { "PolicyName" : "tikjsPolicy" , "PolicyDocument" : { "Statement" : [ { "Effect" : "Allow" , "Action" : [ "sqs:GetQueueAttributes" , "sqs:ReceiveMessage" , "sqs:DeleteMessage" ], "Resource" : { "Fn::GetAtt" : [ "sqsq" , "Arn" ] } } ] } } ] } }, // the actual event source mapping (SQS queue -> Lambda) "sqsqTriggertikjs0" : { "Type" : "AWS::Lambda::EventSourceMapping" , "Properties" : { "BatchSize" : "10" , "EventSourceArn" : { "Fn::GetAtt" : [ "sqsq" , "Arn" ] }, "FunctionName" : { "Ref" : "tikjs" } } }, // grants permission for SQS service to invoke the Lambda // when messages are available in our queue "sqsqPermissiontikjs" : { "Type" : "AWS::Lambda::Permission" , "Properties" : { "Action" : "lambda:InvokeFunction" , "FunctionName" : { "Ref" : "tikjs" }, "SourceArn" : { "Fn::GetAtt" : [ "sqsq" , "Arn" ] }, "Principal" : "sqs.amazonaws.com" } } ... }

（實際上，這就是這篇文章的全部原因/目的。）

提示：你并不需要擔心這整個IAC / CloudFormation啄-或寫冗長的JSON / YAML -如果你喜歡一個完全自動化的資源管理工具去SLAppForge西格瑪無服務器云IDE 。

但是...事件源映射是否已準備好參加大型比賽？

它們看起來確實很有希望，但是在我們可以在全自動的生產環境中使用它們之前，似乎事件源映射確實需要更成熟一些。

您無法通過IAC更新事件源映射。

例如，即使事件源從開始以來已經超過四年，但事件源在通過IaC（例如CloudFormation或無服務器框架）創建后仍無法更新 。 這會造成嚴重的麻煩； 如果更新映射配置，則需要手動刪除舊的并部署新的。 第一次正確設置它，否則您將不得不進行繁瑣的手動清理以使整個事情重新開始。 自動化非常重要！

The event source arn (aaa) and function (bbb) provided mapping already exists. Please update or delete the existing mapping...

聽起來很老派。

還有其他一些不太明顯的問題。 首先，事件源映射是由輪詢機制驅動的 。 如果您的源是SQS隊列，則Lambda服務將繼續對其進行輪詢，直到收到下一條消息為止。 盡管這完全無法控制，但這確實意味著您要為輪詢支付費用 。 另外，作為一名開發人員，我不認為輪詢完全適合事件驅動的無服務器范例。 當然， 一切都歸結為最后的投票 ，但仍然……

最后：為什么不嘗試事件源映射？

是否準備就緒，似乎事件源映射將保留下來。 隨著數據流 （ Kinesis ），隊列驅動的分布式處理和協調 （ SQS ）和事件分類帳 （ DynamoDB Streams ）的日益普及，隨著時間的流逝，它們將變得越來越受歡迎。

您可以通過多種方式嘗試事件源映射的工作方式： AWS控制臺 ， aws-cli ， CloudFormation ， Serverless Framework和易于使用的圖形化IDE SLAppForge Sigma 。

只需拖放即可輕松管理事件源映射！

在Sigma IDE中，您可以簡單地將事件源（ SQS隊列 ， DynamoDB表或Kinesis流 ） 拖放到Lambda函數代碼的event變量上。 Sigma將彈出一個包含可用映射配置的對話框，因此您可以輕松配置源映射行為。 您甚至可以在彈出窗口中配置一個全新的源（隊列，表或流），而不使用現有的源。

部署后，Sigma將為您的新事件源自動生成所有必要的配置和權限，并為您將其發布到AWS。 全部都是完全托管，完全自動化和完全透明的。

聊夠了。 讓我們開始吧！

翻譯自: https://www.javacodegeeks.com/2019/05/aws-lambda-source-mappings-bringing-your-triggers.html

總結

以上是生活随笔為你收集整理的AWS Lambda事件源映射：使您的触发器混乱无序的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。