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。less
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 的開發經驗，如今從事雲信後端調度開發。