簡介

初階課程 | 10 分鐘

「無伺服器 - 深入了解」課程介紹了可幫助您開始建立無伺服器應用程式的基礎概念、參考架構、最佳實務和實作活動。如果您不熟悉無伺服器,那麼這是入門的理想之地。對於經驗豐富的無伺服器開發人員,我們提供與進階主題相關的資源和連結。

什麼是無伺服器?

無伺服器可讓您建立和執行應用程式與服務,而無需擔心伺服器的問題。這種做法可免除基礎架構管理工作,例如伺服器或叢集佈建、修補、作業系統維護和容量佈建。您可以為幾乎任何類型的應用程式或後端服務建立無伺服器應用程式,它可為您包辦執行和擴展高可用性應用程式所需的一切工作。

無伺服器應用程式由事件驅動,並透過與技術無關的 API 或訊息傳遞進行鬆散耦合。事件驅動的程式碼用於回應事件,例如狀態變更或端點請求。事件驅動型架構使程式碼與狀態解偶。鬆散耦合的元件之間的整合通常透過訊息傳遞非同步完成。

AWS Lambda 是一種無伺服器運算服務,非常適合事件驅動型架構。Lambda 函數由來自整合事件來源 (例如可用於建立非同步整合的 Amazon Simple Queue Service (SQS)、Amazon Simple Notification Service (SNS) 和 Amazon Kinesis) 的事件觸發。Lambda 函數使用並產生其他服務可以使用的事件。

無伺服器架構模式將 Lambda 與其他無伺服器受管服務一起使用。除了訊息和串流服務之外,無伺服器架構還使用受管服務,例如用於 API 管理的 Amazon API Gateway、用於資料儲存的 Amazon DynamoDB 和用於協調的 AWS Step Functions。此無伺服器平台還包含一組開發人員工具,其中包括 Serverless Application Model (SAM),可幫助簡化 Lambda 函數和無伺服器應用程式的部署和測試。

為什麼使用無伺服器解決方案?

無須管理伺服器:無須佈建或維護任何伺服器。無須安裝、維護或管理軟體或執行時間。

可彈性擴展:您的應用程式可自動擴展,或透過切換使用單位 (例如,輸送量、記憶體) 而非個別伺服器單位來調整容量。

為價值付費:依穩定的輸送量或執行的持續時間支付費用,並非按伺服器單位付費。

自動化高可用性:無伺服器解決方案提供內建的可用性和容錯能力。您不需要建構這些功能,因為執行應用程式的服務預設都已提供這些功能。

核心無伺服器服務

無伺服器應用程式通常使用全受管的服務作為建置組塊進行構建,這些服務包括運算、資料、訊息傳遞和整合、串流以及使用者管理和身分層的服務。諸如 AWS Lambda、API Gateway、SQS、SNS、EventBridge 或 Step Functions 之類的服務是大多數應用程式的核心,並由諸如 DynamoDB、S3 或 Kinesis 之類的服務提供支援。

類別
服務
描述
運算 AWS Lambda AWS Lambda 讓您可以在受管平台上執行無狀態無伺服器應用程式,
該平台在函數層支援微型服務架構、部署
和執行管理。
API 代理 API Gateway Amazon API Gateway 是一項全受管的服務,使開發人員可以輕鬆
建立、發佈、維護、監控和保護任何規模的 API 的安全。它
API 管理提供全面的平台。API Gateway 讓您可以處理
數十萬個並行 API 呼叫和進行流量管理、
授權和存取控制、監控以及 API 版本管理。
簡訊和整合 SNS Amazon SNS 是一種全受管的發佈/訂閱簡訊服務,讓您可以輕鬆
解偶和擴展微型服務、分散式系統及無伺服器應用程式。
SQS Amazon SQS 是一項全受管的訊息佇列服務,讓您可以輕鬆
解偶和擴展微型服務、分散式系統及無伺服器應用程式。
EventBridge Amazon EventBridge 是一種無伺服器事件匯流排,
讓您可以使用您自己的應用程式、整合的軟體即服務 (SaaS) 應用程式和 AWS 服務中的資料,
輕鬆地將應用程式連接在一起。
協調 Step Functions
借助 AWS Step Functions,您可以使用視覺化工作流程
輕鬆協調分散式應用程式和微型服務的元件。

開始建立!

以下這些資源可幫助您了解我們的核心無伺服器服務。

執行無伺服器的 "Hello, World!"

使用 AWS Lambda 主控台建立 "Hello World" Lambda 函數,並了解在不佈建或管理伺服器的狀況下執行程式碼的基礎知識。

開始教學 >>

從上傳的影像建立縮圖

建立由 Amazon S3 叫用的 Lambda 函數,以在每次將影像檔案上傳到 S3 儲存貯體時,自動建立該影像的縮圖。

開始教學 >>

使用 AWS Lambda 建立您的第一個應用程式
建立簡單的微型服務

使用 Lambda 主控台建立 Lambda 函數,並使用 Amazon API Gateway 端點觸發該函數。

開始教學 >>

建立無伺服器工作流程

了解如何使用 AWS Step Functions 設計和執行協調多個 AWS Lambda 函數的無伺服器工作流程。

開始教學 >>

基礎知識

中級課程 | 20 分鐘

在本節中,您將了解事件驅動的設計,這是建立可擴展無伺服器應用程式的核心原理。

事件驅動的設計

事件驅動型架構利用事件來觸發服務和進行解偶服務之間的通訊。事件是狀態的變更或更新,就好像電子商務網站上放置在購物車中的商品。事件可以帶有狀態 (例如,所購買的商品、價格和送貨地址),也可以是識別符 (例如,訂單已發貨的通知)。

事件驅動型架構具有三個關鍵元件:事件生產者、事件路由器和事件使用者。生產者將事件發佈到路由器,路由器對事件進行篩選並將其推送給使用者。生產者服務和使用者服務是解偶的,這使它們可以獨立擴展、更新和部署。

要了解為什麼需要使用事件驅動型架構,讓我們看一下同步 API 呼叫。

Serverless deep dive synchronous api call

客戶透過進行 HTTP API 呼叫來使用您的微型服務。Amazon API Gateway 託管 RESTful HTTP 請求和給客戶的回應。AWS Lambda 包含用於處理傳入 API 呼叫的業務邏輯,並使用 DynamoDB 作為持久性儲存。

同步呼叫時,API Gateway 會期望立即回應並具有 30 秒的逾時時間。對於同步事件來源,如果 Lambda 的回應需要 30 秒以上,則您需要編寫重試和錯誤處理程式碼。因此,下游用戶端任何元件 (例如 DynamoDB 中的讀取/寫入容量單元) 一旦發生錯誤或擴展問題,都將被推送回用戶端,以使用前端程式碼進行處理。透過使用非同步模式並解偶這些元件,您可以建立更穩健的高度可擴展系統。

傳送散發事件通知

了解如何實作散發簡訊案例,其中訊息會「推送」到多個訂閱者,如此即無須定期檢查或輪詢更新,而且可依訂閱者平行非同步處理訊息。

開始教學 >>

將 Amazon EventBridge 整合到您的無伺服器應用程式中

了解如何在 AWS Lambda 中建立事件生產者和使用者,以及如何建立事件路由規則。

開始教學 >>

遷移到事件驅動型架構
觸發器和事件來源

Lambda 函數由事件觸發。然後,它們透過執行程式碼回應觸發器,並且還可以產生自己的事件。觸發 Lambda 函數的選項很多,而且您可以靈活地建立自訂事件來源,以滿足您的特定需求。

事件來源的主要類型包括:

  • 資料儲存,例如 Amazon S3、Amazon DynamoDB 或 Amazon Kinesis,它們都可以觸發 Lambda 函數。如果其中儲存了您想要追蹤變更的資料,則可以將其用作事件來源。
  • 發出事件的端點可以叫用 Lambda。例如,當您要求 Alexa 做某事時,她會發出一個觸發 Lambda 函數的事件。
  • 訊息傳遞服務,例如 Amazon SQS 或 Amazon SNS,它們也可以是事件來源。例如,當您將某些內容推送到 SNS 主題時,它可能會觸發 Lambda 函數。
  • 儲存庫中發生某些操作時,例如將程式碼提交到 AWS CodeCommit 儲存庫時,它可以觸發 Lambda 函數,例如開始 CI/CD 建立過程。
Serverless deep dive event source trigger
叫用 AWS Lambda 函數

透過我們的開發人員指南了解有關呼叫 AWS Lambda 函數的所有資訊。

查看開發人員指南 >>

在無伺服器應用程式中選擇事件、佇列、主題和串流
參考架構

在本節中,您將了解一套涵蓋了常見無伺服器應用程式使用案例的參考架構。

  • RESTful 微型服務

    無伺服器技術建立在高度可用的容錯基礎設施之上,讓您能夠為關鍵任務工作負載建立可靠的服務。AWS 無伺服器核心服務與許多其他 AWS 服務緊密整合,並受益於豐富的 AWS 生態系統和第三方合作夥伴工具。該生態系統讓您可以簡化建立過程、自動化任務、協調服務和相依性以及監控微型服務。借助 AWS 無伺服器服務時,您僅需按實際用量付費。這讓您可以在業務需要時提高用量,並在使用率較低時降低成本。所有這些功能使無伺服器技術成為建立彈性微型服務的理想選擇。

    RESTful 微型服務架構範例

    Serverless deep dive restful microservice architecture

    客戶透過進行 HTTP API 呼叫來使用您的微型服務。理想情況下,您的使用者應該就對 API 的使用與您簽訂嚴格限定的服務合約,以期能夠獲得一致的服務水平和變更控制。

    Amazon API Gateway 託管 RESTful HTTP 請求和給客戶的回應。在這種情況下,API Gateway 提供內建的授權、調節、安全性、容錯、請求/回應映射以及效能優化功能。

    AWS Lambda 包含用於處理傳入 API 呼叫的業務邏輯,並使用 DynamoDB 作為持久性儲存。

    Amazon DynamoDB 持久儲存微型服務的資料並根據需求進行擴展。由於微型服務通常設計用於處理一件事情,因此通常使用無結構描述 NoSQL 資料存放區。

  • 影像處理

    影像處理是一種常見的工作負載,可以由事件驅動,並且需要動態擴展和縮減。無伺服器技術非常適合這類工作負載。通常,影像儲存在 Amazon S3 中,Amazon S3 可以觸發 Lambda 函數進行處理。處理之後,Lambda 函數可以將修改後的版本返回給另一個 S3 儲存貯體或 API Gateway。

    下圖顯示您可以使用解決方案的實作指南和隨附的 AWS CloudFormation 範本在幾分鐘內完成無伺服器影像處理常式部署的架構。

    Serverless deep dive image handler

    AWS Lambda 從您的 Amazon Simple Storage Service (Amazon S3) 儲存貯體擷取影像,並使用 Sharp 將影像的修改版本返回給 Amazon API Gateway。該解決方案產生一個 Amazon CloudFront 網域名稱,提供對影像處理常式 API 的快取存取。

    此外,該解決方案還部署一個可選的演示使用者界面,您可以在其中使用帳戶中已存在的影像檔案直接與影像處理常式 API 端點進行互動。演示 UI 部署在 Amazon S3 儲存貯體中,讓客戶能夠立即開始使用簡單的 Web 界面處理影像。CloudFront 用於限制對解決方案中網站儲存貯體內容的存取。

    部署解決方案 >>

  • 串流處理

    您可使用 AWS Lambda 和 Amazon Kinesis 處理即時串流資料,以便追蹤應用程式活動、處理交易訂單、處理點擊串流、分析點擊串流、清理資料、產生指標、篩選記錄、編製索引,以及物聯網裝置遙測和量測。

    串流處理架構範例

    serverless deep dive stream processing

    此圖中描述的架構可以使用 AWS CloudFormation 範本建立。範本將執行以下操作:

    • 建立 Kinesis Stream
    • 建立名為 EventData 的 DynamoDB 表
    • 建立 Lambda 函數 1 (-DDBEventProcessor),該函數從 Kinesis 擷取記錄並將記錄寫入 DynamoDB 表
    • 建立 IAM 角色和策略,以允許事件處理 Lambda 函數讀取來自 Kinesis Stream 的資料並寫入 DynamoDB 表
    • 建立一個具有將事件放入 Kinesis 串流中的權限以及允許使用者在 API 用戶端中使用的登入資料之 IAM 使用者
  • Web 應用程式

    透過使用 AWS 上的無伺服器運算,您可以部署整個 Web 應用程式堆疊,而無需管理伺服器、佈建容量或為閒置資源付費。此外,您不必在安全性、可靠性或效能上妥協。使用無伺服器技術建立的 Web 應用程式可提供高可用性,並可根據需要在全球範圍內擴展。

    serverless deep dive web application
    1. 該 Web 應用程式的使用者可能集中在某個區域,也可能分散在全球各地。透過利用 Amazon CloudFront,不僅可以透過快取和最佳原始路由為這些使用者提供更好的效能體驗,而且還可以限制對後端的冗餘呼叫。
    2. Amazon S3 託管 Web 應用程式靜態資產,並透過 CloudFront 安全地提供服務。
    3. Amazon Cognito 使用者池為 Web 應用程式提供使用者管理和身分提供商功能。
    4. 在許多情況下,在使用者從 Amazon S3 下載靜態內容時,需要將動態內容傳送到應用程式或由應用程式接收。例如,當使用者透過表單提交資料時,Amazon API Gateway 充當安全端點,以進行這些呼叫並返回透過 Web 應用程式顯示的回應。
    5. AWS Lambda 函數讓 Web 應用程式可以對 DynamoDB 進行建立、讀取、更新和刪除 (CRUD) 操作。
    6. Amazon DynamoDB 可以提供後端 NoSQL 資料存放區,以根據 Web 應用程式的流量彈性地擴展。
部署

微型服務架構部署的最佳實務是,確保變更不會破壞使用者的服務合約。如果 API 擁有者進行變更而違反了服務合約,而使用者沒有為此做好準備,則可能會發生故障。

如需了解部署變更的影響,您需要知道哪些使用者正在使用您的 API。您可以使用 API​​ 金鑰收集用量中繼資料,如果對 API 進行了重大變更,這些也可以作為合約的一種形式。

當客戶希望減輕對 API 所做變更的影響時,他們可以克隆 API 並將客戶路由到其他子網域 (例如 v2.my-service.com),以確保不影響現有的客戶。這種方法允許客戶僅將新變更部署到新的 API 服務合約中,但需要做出一些犧牲。採用這種方法的客戶需要維護兩個版本的 API,並將承擔基礎設施管理和佈建開銷。

部署
客戶影響
轉返 事件模型因素
部署速度
一次全部 一次全部 重新部署舊版本 低並行率的任何事件模型 即時
藍/綠 一次全部但預先進行某些程度的生產環境測試 將流量恢復到以前的環境 適合中等並行工作負載下的非同步和同步事件模型 幾分鐘到幾小時的驗證,然後立即提供給客戶
Canary/線性 典型的初始流量轉移為 1–10%,然後逐步增加或一次全部轉移 將 100% 的流量恢復到以前的部署 適合高並行工作負載 幾分鐘到幾小時
  • 一次全部部署

    一次全部部署涉及在現有設定之上進行變更。這種部署方式的一個優點是,對資料存放區 (例如關聯式資料庫) 的後端變更在變更週期內需要較少的精力來協調交易。儘管這種部署方式省力,並且對低並行性模型的影響很小,但它在轉返時會增加風險,經常導致停機。使用此部署模型的範例是在對使用者影響很小的開發環境中使用。

    嘗試一次全部部署 >>

  • 藍/綠部署

    使用藍/綠部署模式時,客戶將一部分流量轉移到正在使用的新環境 (綠色),同時保持舊環境 (藍色) 隨時可用,以便系統在需要時進行轉返。使用此模式時,進行的變更最好不要太大,以便可以快速、輕鬆地完成轉返。藍色/綠色部署旨在減少停機時間,許多客戶正在部署方式在生產中進行部署。API Gateway 讓您可以輕鬆定義將多少流量轉移到新的綠色環境,使其成為此部署模式的有效工具。

    這種部署方式特別適用於無伺服器架構,因為該架構既無狀態又與基礎設施解偶。

    您需要適當的指標來了解是否需要轉返。作為最佳實務,我們建議客戶使用 CloudWatch 高解析度指標,該指標可以每隔 1 秒監控一次,并快速捕獲下降趨勢。與 CloudWatch 警示結合使用時,您可以實現快速轉返。您可以在 API Gateway、Step Functions、Lambda (包括自訂指標) 和 DynamoDB 上捕獲 CloudWatch 指標。

  • Canary 部署

    Canary 部署是您在受控環境中利用軟體的新版本,並實現快速部署週期的一種漸進方式。Canary 部署涉及將少量請求部署到新變更中,以分析對少量使用者的影響。

    透過在 API​​ Gateway 中進行 Canary 部署,您可以將變更部署到後端端點 (例如 Lambda),同時仍為使用者維護相同的 API Gateway HTTP 端點。此外,您還可以控制將多少百分比的流量路由到新部署,並​​控制流量切換。新網站就適合採用 Canary 部署。在將所有流量轉移到新部署之前,您可以監控少量最終使用者的點擊率。

    利用別名流量轉換,實作 AWS Lambda 函數的 Canary 部署

    了解如何實作 AWS Lambda 函數的 Canary 部署。

    閱讀部落格文章 >>

    漸進式部署無伺服器應用程式

    AWS SAM 為您的無伺服器應用程式提供漸進式 Lambda 部署。

    查看開發人員指南 >>

其他資源

實作教學
存取無伺服器教學的完整清單,獲得更多實作學習。
查看實作教學 >>
AWS 無伺服器部落格
前往 AWS 無伺服器部落格,閱讀有關無伺服器一切事物的最新消息和更新。
閱讀部落格文章 >>
類別深入了解
深入探究特定技術,並善盡利用 AWS 雲端。
查看類別深入了解 >>