手把手教你使用AWS Lambda構建無伺服器架構

程序員為什麼要使用AWS Lamdba?一言以蔽之，簡單。AWS Lambda和function-as-a-service平台（如Microsoft Azure函數，Google Cloud Functions和IBM OpenWhisk）通過抽象代碼堆棧中的內容來簡化開發。程序員編寫了響應某事件的函數（如表單提交，webhook等），並將其上傳，在代碼執行時付費。

在《程序員請注意，無伺服器將改變應用程序開發》一文中，我們介紹了FaaS運行時的工作原理以及實現無伺服器的軟體架構。今天，我們會通過在AWS Lambda中創建一個簡單函數來展現更多事件操作，並討論這項強大技術的常見設計模式。

在2014年的AWS re:Invent大會上，AWS首次發布了AWS Lambda。用於解釋事件驅動的計算平台平台如何工作的示例如下：

將圖片上傳到S3存儲區，觸發執行Lambda功能的事件。在事件觸發之前，該函數位於磁碟上的文件中，沒有CPU 資源被使用，直到工作到達。一旦觸發器觸發，該函數將被載入到Lambda運行時並傳遞有關該事件的信息。在此示例中，該函數將圖像文件從S3讀入存儲器，並創建不同大小的縮略圖，然後將其寫入第二個S3存儲區。

下面我們就將創建實現此示例所需的Lambda代碼框架，設置觸發器並測試我們的代碼。我們還將挖掘CloudWatch日誌，以調試遇到的一些許可權問題。

創建一個AWS Lambda函數並觸發

創建Lambda函數有很多方法，如Eclipse插件或者是類似Serverless Framework這樣的工具。這其中最簡單的方法之一就是使用AWS提供的藍圖。如果我們轉到AWS Lambda控制台並單擊創建新功能，就會出現如下界面：

接下來使用Node.js來創建一個對S3事件作出響應的函數，所以我們從Select Runtime菜單中選擇Node.js 6.10，並將S3輸入到Filter 對話：

單擊s3-get-object blueprint，進入「配置觸發器」頁面：

在這裡設置用於生成事件（infoworld.walkthrough）的bucket，並將事件類型設置為在每個bucket中創建新對象時觸發。接下來我們也可以進一步過濾 ，僅當存在對象名稱中的某些前綴或後綴時才會觸發事件。但是我們跳過該操作，並單擊「下一步」按鈕啟用觸發器。

這就創建了基於 blueprint的功能骨架：

我們把功能命名為infoworldWalkthrough，我們可以看到它會自動檢索觸發觸發器的對象信息。

在同一配置頁面下，我們需要設置一些許可權：

每個功能必須分配一個IAM角色，以便我們可以控制對AWS資源的訪問。這裡我們要求系統創建一個名為infoworldRole的新角色，並將該角色的只讀許可權賦予給S3。如果我們要實現完整的規範示例並生成縮略圖，我們還要添加S3寫入許可權。但是，由於我們只需讀取有關觸發S3對象的信息，所以只讀許可權應該是足夠的。

最後，我們需要注意一些高級設置：

最重要的工作是我們要設置內存量和執行超時的上限。請記住，Lambda運行時借鑒了容器的流水線，它們預裝了各種語言運行時。當一個事件觸發它會將代碼載入到這些容器中，並執行功能。內存和超時設置決定了容器將有多大，以及我們的功能需要執行多少時間。在這個示例中，默認值設置為128MB和3秒比較好。如果是其它示例，可以根據自己的需求來更改默認值。

點擊「Next」進入到另一個頁面，來查看我們目前為止所有輸入的設置：

點擊「創建函數」按鈕在AWS Lambda中創建函數。

檢查我們的AWS Lambda代碼

以下是blueprint為我們創建的默認代碼：

在第14和15行，Lambda函數提取了bucket的名稱和觸發觸發器的對象名稱（也稱為鍵）。然後使用S3 API獲取有關對象的更多信息，（如果順利）輸出其內容類型。雖然我們在這裡沒有這樣做，但是我們可以很容易地包含，然後讀取對象的代碼，並相應地生成縮略圖。

測試我們的AWS Lambda代碼

現在讓我們來到S3控制台來解決這個問題，在這種情況下，bucket最開始是空的：

我們將InfoWorld徽標的PNG上傳到該存儲區：

從S3 控制台還無法看出函數是否被執行，即使訪問Lambda控制台，也無法完全獲得。每個Lambda函數都通過CloudWatch記錄信息，所以如果我們檢查CloudWatch，就會看到有一個函數的新日誌組。

檢查該日誌，其顯示訪問S3 bucket 被拒絕：

當我們的代碼嘗試讀取S3對象的信息時，被拒絕訪問數據。為什麼呢？是因為我們沒有設置IAM角色，以便我們的函數在S3 bucket上具有隻讀許可權嗎？我們需要在IAM控制台上仔細檢查一下：

沒錯，這個角色有一個策略，我們來看一下：

我們有權在CloudWatch中創建日誌，但是S3隻讀許可權策略不知為何沒有被採取。點擊附加策略按鈕之後，我們會看到下方界面：

通過選擇AmazonS3FullAccess選項並按附加策略按鈕，為函數添加所需的許可權。通過手動將PNG文件添加到S3 bucket中來測試功能：

現在，如果我們按測試按鈕，我們將得到一個對話框，讓我們從許多示例事件中進行選擇。我們要測試S3 put。我們需要編輯S3 key和bucket名稱欄位中的值，分別對應於我們的圖像文件和存儲bucket的名稱：

事件中各種各樣的其他欄位也可以在這裡設置，但是由於我們的代碼僅查看關鍵字和bucket名稱，所以先暫時忽略其餘的欄位。按保存和測試按鈕將觸發事件並執行函數。與上一次不同，當通過S3控制台觸發事件時，我們看到了現場反饋。我們還可以在Lambda UI中獲取CloudWatch日誌的相關部分：

您可以看到我們的代碼執行並按預期標識了內容類型。

IDE集成和命令行工具（如Serverless Framework）能夠顯著加速此過程，但是這次演示顯示了通過CloudWatch創建具有正確許可權，設置事件和調試代碼的功能以及兩種不同的方式觸發事件，以便可以測試該功能。

我們來看看一些常見的Lambda設計模式。

AWS Lambda設計模式

針對無伺服器應用程序架構出現了許多設計模式。AWS re：Invent上「 無服務架構模式」和「最佳實踐 」的會議上強調了四個模式。接下來，我會介紹兩個自己很喜歡的模式，因為它們適用於剛剛開始使用無伺服器架構！

首先，構建Web應用程序，使用S3和CloudFront進行靜態內容，使用由Lambda和DynamoDB支持API網關的動態需求：

這種基本模式可以在多個級別的安全性下緊密鎖定：

Web應用程序的大部分內容對於用戶來說是只讀的，並且可以從S3和CloudWatch獲得此模型。授權數據可以利用IAM hook API網關以及與DynamoDB進行交互的單個Lambda函數的IAM角色。

我第二個最喜歡的用例 - 由Capital One為其Cloud Custodian項目實施 - 是使用Lambda設置自動化hook。 在Capital One的實施中，CloudWatch日誌事件觸發Lambda函數，以針對Capital One特有的合規性和策略規則執行檢查。 當發現潛在問題時，該功能將通過Amazon SNS生成通知，可通過Amazon SNS配置發送簡訊，電子郵件和其他一些機制，以便向正確的人員發出需要注意的違規策略。

我喜歡這種自動化模式，因為它為現有流程增加了巨大的價值，而不會以任何方式擾亂該流程。系統合規性是自動化的，而不會觸及被監控的系統。

更多思考

如我們所見，設置Lambda功能，配置事件，應用安全策略和測試結果是一個沒有IDE或命令行工具的快照。 Microsoft，Google和IBM為他們的FaaS運行時提供了類似的輕鬆onboarding功能。 加上設計模式的出現，這無疑將為更高級的工具和重用鋪平道路。

無伺服器應用程序體系結構表現出非常不同的心態。 代碼段較小，僅在觸發時才執行，降低了成本，並通過鬆散耦合的事件而不是靜態定義的API綁定在一起。 無伺服器可以實現比之前可能更快的開發周期，並且利用簡單的自動化和Web應用程序設計模式，風險更低。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！