AWS Serverless 服務是一種對應用工程師來說無服務器的計算方式，基礎概念是將運行服務所需的基礎設施交由 AWS 管理。使用 AWS Serverless 服務的工程師可以專注於面向客戶邏輯服務層的開發，而不需要在基礎設施的構建、管理、擴容等任務上分散過多精力。AWS Serverless 開發的核心是名爲 Lambda 的計算服務。
今天我們將圍繞 Lambda ，介紹在不同的應用場景下Lambda與各種 AWS 服務的不同組裝模式，來初步探討基於 AWS Serverless 的開發和部署。
What？
首先介紹一下什麼是 Serverless 開發。
和經典的開發、編譯、部署運行方式不同，使用 AWS Serverless 計算服務 Lambda，僅需要上傳源文件，選擇執行環境並執行，便能得到運行結果。在這過程中，服務器部署、runtime 安裝、編譯、都由 AWS Serverless 計算平臺管理執行。對開發人員來說，只需要維護源代碼和 AWS Serverless 執行環境的相關配置即可。
Why？
爲什麼要選擇 Serverless 呢？
對開發人員來說，使用 AWS Serverless 服務能夠節省大量管理基礎設施架構的精力，並更好地專注於業務邏輯的開發。而對服務而言，AWS 本身的服務性質使得它能很好的支持彈性擴展和高併發場景。此外基於 AWS Serverless 的開發往往擁有快速更新、快速部署的優點，其按需收費（on-demand）的收費方式，在如輕量部署測試環境、快速驗證等應用場景下對削減開支也有優勢。
How？
那麼，我們來看一下如何用 AWS Serverless 的相關服務迅速組裝一個簡單的 Web Service。
AWS Serverless 提供了豐富的服務目錄，以覆蓋各種功能的使用需求。搭建 Web Service 服務除了核心的計算服務 Lambda 之外，常常還需要和請求入口路由（API Gateway）、持久化存儲（S3）、CDN（CloudFront）、防火牆（WAF）、域名解析（Route 53）等服務組合使用。如果需要支持 https 協議，還可以使用證書管理服務（ACM）實現。
將上述服務組裝好之後，一個完整的響應請求流程將會是這樣的：
- 用戶請求經由域名解析到達 CloudFront，由 WAF 進行頻率控制、IP 過濾、header 驗證等安全性保障後，通過 API Gateway 路由轉發給核心的 Lambda 計算服務。
- Lambda 會對請求進行處理，處理時如若需要會從持久化存儲 S3 中讀取或存儲數據，並且最終將處理結果通過 API Gateway 返回給用戶端。
- Lambda 在邏輯計算時產生的日誌會輸出到 CloudWatch 提供的日誌管理服務中以便日後查詢。此外，還可以進行額外的優化，比如配置 CloudFront 直接從 S3 中加載靜態資源，以減輕時間和計算開銷。
Lambda 的啓動方式
在剛剛的 Web Service 的例子中，Lambda 的執行是由 API Gateway 服務喚起（Invoke）的。實際上 Lambda 執行可由多種方式喚起。首先 AWS 本身的服務中，常常會和 Lambda 結合使用的有消息發佈（SNS）、消息隊列（SQS）、負載均衡器（ALB）、狀態機（Step Function）等服務。
當然通過 SDK、Command Line 或者 API 接口，也可以啓動 Lambda 函數的執行。執行模式分爲同步和異步兩種：
- 同步模式的調用：需要等待 Lambda 函數執行完畢纔會返回結果
- 異步模式的調用：在調用 Lambda 的執行接口之後會立即返回，Lambda 函數的執行結果需要通過其他途徑獲取。
這兩種調用模式可供不同場景靈活選擇使用。
消息驅動的例子
我們再看一個消息驅動的報警處理系統中使用 AWS Serverless 服務的例子。
比如我們有一個運行中的系統，設定異常報警發生時會將報警消息發送給 SNS 服務。SNS 服務是一個消息的 Pub/Sub 服務，對報警消息執行一個基礎的 fan-out 發佈操作，一方面通過電話、郵件通知負責人，另一方面同時調用 Lambda，Lambda 中可以進行一些對報警的自動化處理。這就是一個最簡單的報警處理系統。
但是在這裏要注意，SNS 服務本身不存儲消息。SNS 接收到消息後，會馬上進行發佈消息。如果此時沒有消息的接受者，那麼這條消息就會被丟棄。除此之外，消息傳遞成功，即調用 Lambda 的接口成功之後，無論處理結果如何，消息都會被丟棄。如果 Lambda 因爲一些內部邏輯錯誤、或者外部依賴系統故障等原因，處理過程執行失敗了，那麼對已經丟失的消息是無法進行重試操作的。要提高消息處理的可靠性，可以通過在 SNS 和 Lambda 之間加入消息隊列服務（SQS）來實現。
SQS 標準隊列提供一個無序可靠、支持高併發的隊列服務，可以存儲消息長達14天。SNS 將消息發佈至 SQS，消息首先會被存儲在 SQS 中。此時，再設置 SQS 爲 Lambda 的事件源（event source），那麼消息就會被髮送至 Lambda 進行下一步處理。SQS 喚起 Lambda 可以配置爲一個同步的過程，也就是說，如果 Lambda 執行失敗並返回錯誤，SQS 就不會從隊列中刪除這條消息。處理失敗的消息暫時會被標記爲不可見，在一段隱藏期限過後，SQS 將會再次重複喚起 Lambda 來處理這條消息。這種方式可以大大提高消息處理的可靠性。
但是上述方式同時也引入了異常消息大量堆積而降低正常消息執行效率的問題。爲了解決這個新問題，我們可以爲消息隊列配置一個 Dead-Letter Queue。如果某條消息經過多次處理依然不成功，可被從原來的隊列中刪除，並且轉移到 Dead-Letter Queue中。標準隊列的 Dead-Letter Queue 本質上也是標準隊列，同樣可以繼續對其中的“廢棄”消息進行其他後續處理。
標準隊列能夠較好地支持高併發場景。一個標準隊列能夠同時接受大量消息，併發地喚起大量 Lambda 實例進行處理。與此對應，標準隊列服務不能保證消息投遞的順序，同一條消息也可能重複投遞。所以在使用 SQS 標準隊列時，需要考慮消息的去重、處理邏輯的冪等性等問題。除了標準隊列，SQS 還有另一種先進先出型（FIFO）隊列。FIFO 犧牲了併發性能，來保證消息投遞的順序性和唯一性。在不同應用場景下，可以根據具體需求來靈活選擇使用不同的隊列類型。
總結
AWS Serverless 服務在解耦合、彈性擴展、跨區域部署等方面有天然的優勢，但同時也有侷限性：
- 單次 Lambda 的執行上限爲15分鐘，對長時間工作支持性較差。
- 構築在 Serverless 架構上服務的可用性非常依賴於 AWS 可用性。
- 基於 Serverless 的開發會產生對 AWS 系統的學習成本，調試、故障處理的難度也會變高。
在實際生產活動中，需要全面考慮需求，平衡好成本與效果。在某些適合微服務的應用場景下，特別在執行短狀態、臨時性等任務時，基於 AWS Serverless 的開發可以成爲十分便利的開發手段。
以上就是本次分享的全部內容，關於本次分享的視頻，也可以點擊【這裏】進行查看。
作者介紹
葛馨霓，網易雲信後端開發工程師，在海外有基於 AWS Serverless 的開發經驗，現在從事雲信後端調度開發。