摘要：重新修改圖片大小然后上傳到亞馬遜，是最常見用于解釋事件驅(qū)動的示例，計算即服務(wù)平臺的仍然保留了這個例子，如下圖一個圖片被上傳到一個桶中，觸發(fā)一個執(zhí)行函數(shù)的事件。無服務(wù)器架構(gòu)代表了一種非常不同的心態(tài)。

為什么一名開發(fā)者應(yīng)該使用AWS Lambda？簡單一句話的說，AWS Lambda-是另外一種事件驅(qū)動方式，“function-as-a-service”就像Microsoft Azure 的函數(shù)計算、谷歌云的函數(shù)計算、IBM 的OpenWhisk-simolify，實現(xiàn)了開發(fā)工作的任何事情從代碼和底層的堆棧的分離。開發(fā)者寫一個功能來響應(yīng)特定的事件（例如一項表單提交、創(chuàng)建一個網(wǎng)絡(luò)鏈接、給數(shù)據(jù)庫添加一行），上傳這些代碼，只有代碼運行的時候才付費。

在“無服務(wù)器計算如何改變應(yīng)用發(fā)展”一文中，我指出function-as-a-service(FaaS)如何運行及如何啟用無服務(wù)器軟件架構(gòu)的具體要點。今天我們進一步親自動手在AWS Lambda上創(chuàng)建一個簡單的函數(shù)，然后討論一些常見的讓這項技術(shù)更強大的設(shè)計模式。

在2014年的AWSre:Invent大會上第一次宣布了最早的FaaS運行態(tài)，即AWSLambda。重新修改圖片大小然后上傳到亞馬遜S3，是最常見用于解釋事件驅(qū)動的示例，計算即服務(wù)平臺的仍然保留了這個例子，如下圖：

一個圖片被上傳到一個S3桶中，觸發(fā)一個執(zhí)行Lambda函數(shù)的事件。在事件被觸發(fā)之前，函數(shù)以文件的形式保存到硬盤上，在工作任務(wù)下達之前沒有CPU資源的使用（或者預(yù)留）。一旦觸發(fā)，函數(shù)進入Lambda運行時并且傳遞有關(guān)事件的信息。在這個例子中，函數(shù)從S3中讀取圖片文件到內(nèi)存中并且創(chuàng)建各種尺寸的縮略圖，然后寫入到第二個S3桶。

讓我們走進一點看看，我們不必麻煩到具體實現(xiàn)修改圖片尺寸的代碼，但是，我們將創(chuàng)建實現(xiàn)這個示例所需的Lambda代碼的框架，以實現(xiàn)這個示例，創(chuàng)建觸發(fā)器，然后測試代碼。我們還將深入了解CloudWatch日志，以調(diào)試我遇到的一個小權(quán)限問題。

創(chuàng)建一個AWS lambda 函數(shù)和觸發(fā)器

創(chuàng)建一個AWS lambda 函數(shù)有許多方式，包括使用像Eclipse這樣的IDE工具，或者像無服務(wù)器框架這樣的工具，但是最容易的起步方式是使用AWS提供的藍圖（譯者注：英文原文為blueprint，本意為藍圖，亞馬遜這里應(yīng)該類似產(chǎn)品的代號，在這里還是翻譯為藍圖）。如果我們到AWS Lambda的控制臺，然后點擊創(chuàng)建新函數(shù)，我們將得如下圖的界面：

我們將使用Node.js創(chuàng)建一個響應(yīng)S3事件的函數(shù)，我們從運行菜單選擇Node.js 6.10，并且進入過濾器對話框：

在藍圖上單擊s3 -get-object，然后我們進入到配置觸發(fā)器頁面：

在這里，我們設(shè)置將用于生成事件的桶t(infoworld.d .walkthrough)，并設(shè)置事件類型，以在該桶中創(chuàng)建新對象時觸發(fā)。我們可以進一步過濾事件，只有當(dāng)對象名稱中的某些前綴或后綴出現(xiàn)時才會觸發(fā)，但是我們會跳過它，然后點擊復(fù)選框，在按下Next按鈕之前啟動觸發(fā)器。

下一步將創(chuàng)建基于藍圖的函數(shù)的框架:

我們給我們的函數(shù)命名為infoworldWalkthrough。盡管我們稍后會更仔細地查看代碼，但你可以看到它自動檢索引起觸發(fā)器的對象的信息。

在同樣的配置頁面下，我們需要做一些權(quán)限設(shè)置:

每個函數(shù)都必須有一個IAM角色，這樣我們就可以控制它對AWS資源的使用。在這里，我們要求系統(tǒng)創(chuàng)建一個名為infoworldRole的新角色，并將這個角色設(shè)置為S3的只讀權(quán)限。如果我們要實現(xiàn)完整的規(guī)范示例并生成縮略圖，我們還需要添加S3寫權(quán)限。但是，因為我們只會讀取觸發(fā)的S3對象的信息，所以只讀權(quán)限應(yīng)該是足夠的。

最后，我們需要注意一些高級設(shè)置:

最重要的項目是在頂部的部分，我們設(shè)置了內(nèi)存的數(shù)量和執(zhí)行超時。請記住，Lambda運行時使用的是容器，這些容器預(yù)裝了不同的語言運行時。當(dāng)事件觸發(fā)時，它將把我們的代碼加載到其中一個容器中并執(zhí)行我們的函數(shù)。內(nèi)存和超時設(shè)置決定了容器的大小，以及我們的函數(shù)必須執(zhí)行多少時間。就我們的目的而言，128MB和3秒的默認值將會很好。對于其他用例，這些設(shè)置通常被更改。按下Next我們到一屏，我們可以回顧我們已經(jīng)輸入的所有設(shè)置:

按下Create Function按鈕，將保存我們的輸入并在AWS Lambda中創(chuàng)建我們的函數(shù)。

檢查我們的AWS Lambda代碼

下面是藍圖為我們創(chuàng)建的默認代碼:

在第14行和第15行，Lambda函數(shù)提取了bucket的名稱和引發(fā)觸發(fā)器的對象名稱(也稱為鍵)。然后它使用S3 API獲取關(guān)于該對象的更多信息，并(如果順利的話)輸出其內(nèi)容類型。我們還沒有這樣做，但是我們可以很容易地包含代碼，然后在對象中讀取，并相應(yīng)地生成縮略圖。

測試我們的AWS Lambda代碼

現(xiàn)在讓我們到S3控制臺中，觀察下桶的問題，在這個例子中，開始完全是空的:

然后上傳一張PNG的圖片到這個桶:

然后……到底是什么?

從S3控制臺上，不清楚我們的函數(shù)是否執(zhí)行了，如果你進入Lambda控制臺，你將會發(fā)現(xiàn)類似的信息缺乏。然而，每個Lambda函數(shù)都通過CloudWatch記錄信息，因此如果我們檢查CloudWatch，我們就會看到我們現(xiàn)在有了一個新的日志組:

檢查這個日志顯示對S3 bucket的訪問被拒絕:

出于某種神秘的原因，當(dāng)我們的代碼試圖讀取關(guān)于S3對象的信息時，它被拒絕訪問該數(shù)據(jù)。但是為什么呢?我們是否設(shè)置了IAM角色，以便我們的函數(shù)在S3存儲桶上具有只讀權(quán)限?讓我們在IAM控制臺進行雙重檢查:

是的，事實上這個角色有一個策略。讓我們來看看這個策略:

奇怪的是，我們有在CloudWatch中創(chuàng)建日志的權(quán)限，但是在任何地方都沒有提到S3。不知何故，我們的S3只讀permissons策略沒有接受。讓我們解決這個問題。

如果我們按下附加策略按鈕，我們將看到下面這個屏幕:

通過選擇AmazonS3FullAccess選項并按下附加策略按鈕，我們應(yīng)該提供所需的所有權(quán)限。

這次我們將使用內(nèi)置的測試鉤子，而不是像以前那樣手動地將PNG文件添加到S3 bucket中來測試函數(shù)。回到主頁，我們的函數(shù):

現(xiàn)在，如果我們按下測試按鈕，我們將會得到一個對話框，讓我們從許多例事件中進行選擇。我們想測試S3 put。我們需要在S3 key和bucketname字段中編輯值，以對應(yīng)我們的圖像文件和bucket的名稱:

在這里可以設(shè)置的事件中有各種其他字段，但是因為我們知道代碼只查看鍵和桶名，所以我們可以忽略其余部分。按下保存和測試按鈕將觸發(fā)事件并導(dǎo)致我們的函數(shù)執(zhí)行。不像上次，當(dāng)我們通過S3控制臺觸發(fā)事件時，這次我們看到了實時反饋。我們還得到了CloudWatch日志的相關(guān)部分，在Lambda UI中:

您可以看到我們的代碼執(zhí)行并確定了內(nèi)容類型。

使用IDE集成工具和命令行工具Serverless框架可以大幅加速這個過程，但是這個例子已經(jīng)展示了創(chuàng)建具有正確權(quán)限的函數(shù)所涉及的基本步驟，搭建事件，通過監(jiān)測和調(diào)試代碼，以及兩種不同的方式觸發(fā)事件的函數(shù)進行測試。

讓我們總結(jié)一下一些常見的Lambda設(shè)計模式。

AWS Lambda設(shè)計模式

已經(jīng)出現(xiàn)了許多用于服務(wù)器應(yīng)用架構(gòu)的設(shè)計模式。在12月的AWS re:Invent大會上，一個名為“無服務(wù)器架構(gòu)模式和較佳實踐”的會議強調(diào)了四個這樣的模式。在這里，我將介紹我的兩個最喜歡的內(nèi)容，因為它們代表任何想要開始使用無服務(wù)器架構(gòu)的組織的甜蜜果實。

首先，很容易構(gòu)建web應(yīng)用程序，使用S3和CloudFront用于構(gòu)建靜態(tài)內(nèi)容，并使用Lambda和DynamoDB支持的API網(wǎng)關(guān)以滿足動態(tài)需求:

這種基本模式可以與多個級別的安全緊密聯(lián)系在一起:

對于所有的用戶來說，web應(yīng)用程序的大部分內(nèi)容都是只讀的，并且這種模型可以從S3和CloudWatch中得到很便宜的服務(wù)。被授權(quán)的數(shù)據(jù)可以利用IAM鉤子進入API網(wǎng)關(guān)，以及IAM角色，以多帶帶的Lambda函數(shù)與一個DynamoDB交互。

我的第二個最喜歡的用例，一個由CapitalOne實現(xiàn)的云托管項目，即使用Lambda建立自動化掛鉤。在CapitalOne的實現(xiàn)中，CloudWatch日志事件觸發(fā)Lambda函數(shù)對特定于Capital One的遵從性和策略規(guī)則進行檢查。當(dāng)發(fā)現(xiàn)潛在問題時，該函數(shù)會通過Amazon SNS生成通知，可以將其配置為發(fā)送SMS消息、電子郵件和其他一些機制，以提醒正確的人注意那些需要注意的違反政策的行為。

我喜歡這種自動化模式，因為它為現(xiàn)有過程增加了巨大的價值，而不會以任何方式干擾這個過程。系統(tǒng)的遵從性是自動化的，不涉及被監(jiān)視的系統(tǒng)。和之前的模式一樣，它為組織提供了一種簡單的方法，讓企業(yè)能夠輕松使用無服務(wù)器計算。

服務(wù)之外的思考

正如我們所看到的，即使沒有IDE或命令行工具，搭建Lambda函數(shù)、配置事件、應(yīng)用安全策略以及測試出結(jié)果是小菜一碟，微軟、谷歌和IBM的FaaS運行態(tài)也同樣輕松。此外，更好的設(shè)計模式正在出現(xiàn)，這無疑將為工具的多次使用更好的鋪平道路。

無服務(wù)器架構(gòu)代表了一種非常不同的心態(tài)。代碼塊更小，降低成本，只有在觸發(fā)時才執(zhí)行它們，它們通過松散耦合的事件而不是靜態(tài)定義的api來綁定在一起。服無務(wù)器提供了比以前更快速的開發(fā)周期，并且通過簡單的自動化和web應(yīng)用程序設(shè)計模式來繪制，很容易以低風(fēng)險開始。

本文翻譯源：

https://www.infoworld.com/article/3204669/application-development/get-started-with-aws-lambda.html

軟件開發(fā)技術(shù)群

興趣范圍包括：Java，C/C++，Python，PHP，Ruby，shell等各種語言開發(fā)經(jīng)驗交流，各種框架使用，外包項目機會，學(xué)習(xí)、培訓(xùn)、跳槽等交流

QQ群：26931708

Hadoop源代碼研究群

興趣范圍包括：Hadoop源代碼解讀，改進，優(yōu)化，分布式系統(tǒng)場景定制，與Hadoop有關(guān)的各種開源項目，總之就是玩轉(zhuǎn)Hadoop

QQ群：288410967?