如何進行Serverless 開發和應用

如何進行Serverless 開發和應用，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

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 的開發可以成為十分便利的開發手段。

看完上述內容，你們掌握如何進行Serverless 開發和應用的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！