在雲端原生應用程式開發中,AWS Lambda 函式的效能至關重要。除了良好的程式碼撰寫習慣,還需考量冷啟動、初始化流程、資源組態等因素。本文將探討如何有效管理冷啟動,包括使用預置併發和最佳化初始化程式碼,並介紹 SnapStart 技術的應用。此外,文章也涵蓋 IaC 的重要性,特別是使用 AWS CloudFormation 管理基礎設施,以提升佈署效率和可靠性,並說明如何分析效能指標以調整資源組態,最終達到最佳效能和成本效益。
最佳化AWS Lambda函式的效能
在使用AWS Lambda函式時,執行速度越快越好。遵循前面建議的Lambda程式碼編寫方法,可以很好地構建高效函式,但是在最佳化效能時,還需要注意一些額外的因素。本文將介紹一些最佳化技巧。
管理冷啟動
冷啟動(初次載入)發生在Lambda服務必須初始化函式時,這涉及載入函式程式碼、啟動執行時環境和執行函式的初始化階段。一旦函式被初始化,其環境將在短時間內保持可用狀態,以便處理後續的呼叫請求。這些函式有時被稱為“溫暖”函式,可以避免冷啟動的需要。
冷啟動對應用程式的影響將完全取決於您的使用場景和業務流程。例如,對時間非常敏感的函式可能無法忍受任何冷啟動,而背景程式可能能夠在執行時間具有不可預測的變異性時正常執行。
您應該能夠觀察函式並衡量冷啟動對應用程式的影響。確定一個可接受的效能閾值,並決定在哪裡進行權衡。我們將在本章後面進一步討論在生產環境中儘早執行函式以瞭解其行為(包括使用模式和冷啟動)的重要性。
使用預置併發
AWS Lambda提供了預置併發功能作為一種減輕冷啟動的策略。通常,您不需要為大多數無伺服器應用程式組態預置併發,但瞭解這一功能以備不時之需仍然很重要。
最佳化函式初始化
每次建立新的Lambda執行環境時(即每次冷啟動),都會執行函式的靜態初始化程式碼。這是執行環境生命週期中“init”階段的一部分。init階段僅在啟動時執行一次,不會在使用溫暖執行環境的呼叫中再次執行。
您可以將init階段視為執行處理程式外部的程式碼,將invoke階段視為執行處理程式內部的程式碼。為了最佳化冷啟動時間,請儘量減少函式的init程式碼。然而,有些任務在init階段比invoke階段更高效,例如匯入依賴項、開啟資料函式庫連線、初始化AWS客戶端或為X-Ray跟蹤instrumenting AWS SDK呼叫。
示例:最佳化init程式碼
// init階段
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
const dynamoDBClient = new DynamoDBClient();
export const handler = async () => {
// invoke階段
};
透過將必要的初始化任務移到init階段,可以減少冷啟動時間並提高函式效能。
使用AWS Lambda SnapStart
AWS Lambda SnapStart是一項功能,可以最佳化函式並減少冷啟動。目前,Lambda SnapStart僅適用於Java執行時。
圖表:Lambda執行環境生命週期
flowchart TD A[init階段] --> B[invoke階段] B --> C[執行環境關閉]
圖表翻譯:
上述Mermaid圖表展示了Lambda執行環境的生命週期,包括init階段、invoke階段和執行環境關閉。init階段僅在冷啟動時執行一次,而invoke階段則在每次函式呼叫時執行。
透過遵循這些最佳化技巧和使用AWS Lambda提供的功能,可以顯著提高Lambda函式的效能並減少冷啟動時間。
最佳化計算效能
玄貓可以透過多種方式最佳化計算效能。例如,使用Graviton2處理器的函式通常會表現得更好,成本也會更低。此外,Graviton2處理器還可以減少能耗,相比於根據x86的處理器,可以節省多達60%的能量。
分析效能
Lambda Insights是一個效能監控功能,允許您瞭解Lambda函式的效能。透過Lambda Insights,您可以檢視函式的平均執行時間、平均成本等指標。這些資料可以幫助您決定函式的最佳組態。例如,如果您的函式分配了512 MB的記憶體,並且經常消耗95%或以上的記憶體,您可能需要增加記憶體分配以避免超過限制。
伺服器無Serverless計算
Serverless計算是一種新的計算模式,允許您在不需要管理伺服器的情況下執行應用程式。AWS Lambda是一種Serverless計算服務,允許您執行程式碼而不需要管理伺服器。透過使用AWS Lambda,您可以專注於編寫程式碼,而不需要擔心伺服器的管理。
基礎設施即程式碼
基礎設施即程式碼(IaC)是一種管理基礎設施的方法,允許您使用程式碼定義和管理基礎設施。IaC可以幫助您自動化基礎設施的建立、修改和刪除,從而提高效率和降低錯誤率。AWS CloudFormation是一種IaC工具,允許您使用JSON或YAML定義基礎設施。
AWS CloudFormation
AWS CloudFormation是一種基礎設施管理工具,允許您使用JSON或YAML定義基礎設施。您可以使用CloudFormation建立、修改和刪除基礎設施資源,從而自動化基礎設施的管理。CloudFormation還提供了一種版本控制功能,允許您跟蹤基礎設施資源的變化。
flowchart TD A[開始] --> B[定義基礎設施] B --> C[建立基礎設施] C --> D[修改基礎設施] D --> E[刪除基礎設施]
圖表翻譯:
此圖表展示了使用AWS CloudFormation管理基礎設施的流程。首先,您需要定義基礎設施,然後建立基礎設施,接下來可以修改基礎設施,最後可以刪除基礎設施。
內容解密:
上述內容介紹了最佳化計算效能、分析效能、Serverless計算、基礎設施即程式碼和AWS CloudFormation等概念。透過使用Graviton2處理器和Lambda Insights,可以最佳化計算效能和分析效能。Serverless計算是一種新的計算模式,允許您在不需要管理伺服器的情況下執行應用程式。基礎設施即程式碼是一種管理基礎設施的方法,允許您使用程式碼定義和管理基礎設施。AWS CloudFormation是一種基礎設施管理工具,允許您使用JSON或YAML定義基礎設施。
##雲端基礎設施的穩健性 雲端基礎設施的組態如果不正確,可能會導致安全漏洞、應用程式效能問題,甚至服務中斷。將基礎設施定義為程式碼可以幫助防範這些風險。 為了使基礎設施對變化具有韌性,它必須是可驗證的(是否能夠成功佈署?)、可測試的(是否按預期行為?)、可適應的(是否能夠安全快速地更新?)和可攜帶的(是否能夠在任何時間和任何地方佈署?)。
具有這些屬性的基礎設施也可以支援伺服器端工程社群中觀察到的幾個趨勢:
寫少的商業邏輯
每一行你寫的程式碼都可以被視為一個負債,這也可以擴充套件到封裝這些程式碼的Lambda函式。隨著應用程式整合的概念逐漸受到重視,Lambda函式越來越多地被用於轉換資料,而不是傳輸資料。整個無伺服器架構(見第5章詳細內容)正在被佈署到生產工作負載中。這些程式碼正在被玄貓取代。
快速雲端開發
雲端提供商(AWS CodeCatalyst)和初創公司(SST、Wing)正在發現新的方法來改善雲原生軟體的開發便捷性。工程師們要求更緊密的反饋迴圈,以瞭解他們的程式碼是否正確工作,並希望盡可能接近雲端,零模擬。基礎設施即程式碼通常是這些努力的核心,佈署工作流程被自動化,模式之間的雲元件之間分享可重複使用的集合。
基礎設施和組態測試
受管理的服務將操作責任從工程團隊轉移到AWS。工程師們負責組態這些受管理的服務,並需要在不佈署和執行應用程式的情況下測試組態的方法。將基礎設施組態定義為程式碼意味著它可以像應用程式中的任何其他程式碼片段一樣被靜態驗證和測試。
最小許可權原則
最小許可權原則是雲端中授予許可的金標準(見第4章關於此主題的更多內容)。但是,AWS IAM的粒度和語法通常會使得應用它變成一項乏味的任務。現代的IaC工具,如AWS CDK,可以在大多數情況下自動生成最小許可權策略和每資源執行角色。例如,如果你定義了一個Step Functions工作流程,它對DynamoDB發出AWS SDK請求,則工作流程將被分配一個唯一的IAM執行角色,其策略具有執行此任務所需的最小許可。
所有東西皆為程式碼
基礎設施即程式碼運動已經擴充套件到涵蓋定義軟體的許多其他操作方面,包括交付管道、監控儀錶板、警示、合成金鴿和存取控制策略。接受*即程式碼正規化將幫助你快速安全地構建應用程式。
環境和階段
無伺服器資源的短暫、無狀態性質以及按使用付費的定價模型允許採用將應用程式例項視為可隨意丟棄的商品的策略。應用程式例項可以輕鬆且廉價地啟動和終止。
寵物與牛
在過去,IT和營運團隊負責管理資料中心中整個伺服器或伺服器群的生命週期。這些物理機器對團隊來說是熟悉的,並且專門用於提供其應用程式的服務;它們不會與公司內其他團隊或甚至組織內其他部門分享。由於團隊對個別伺服器的健康狀況和效能投入很大,因此它們經常被賦予名稱和個性。早在2012年,我(Luke)曾經為一家公司工作,該公司有一臺名叫Rodney的伺服器。
從產業生態圈的動態變化來看,AWS Lambda 作為 Serverless 計算的代表,正在深刻影響雲端應用程式的開發和佈署模式。本文深入探討了提升 Lambda 函式效能的關鍵策略,涵蓋冷啟動管理、預置併發、初始化最佳化、SnapStart 技術,以及 Graviton2 處理器的應用,並佐以 Lambda Insights 效能監控,展現了多維度的效能最佳化路徑。此外,文章也闡述了 Serverless 計算、IaC 和 AWS CloudFormation 的核心概念及相互關係,並以「寵物與牛」的比喻,精闢地揭示了雲端時代基礎設施管理思維的轉變。
技術限制深析方面,儘管 Lambda 提供了諸多最佳化手段,但冷啟動延遲仍是某些場景下的挑戰。開發者需要根據業務需求權衡效能與成本,並審慎評估預置併發的適用性。同時,SnapStart 等新技術的出現,也為 Java 應用帶來了新的最佳化契機。IaC 的推廣,雖能提升基礎設施管理效率,但也對開發者的程式碼能力和自動化技能提出了更高要求。
展望未來,隨著 Serverless 生態的持續完善,預計 Lambda 將在更多場景下取代傳統伺服器架構。IaC 將成為雲端基礎設施管理的標準實踐,而「一切皆程式碼」的理念將進一步深化。同時,雲端供應商也將持續投入資源,簡化開發流程,降低使用門檻,例如 AWS CodeCatalyst 等工具的發展,便體現了這一趨勢。
玄貓認為,Serverless 計算和 IaC 代表了雲端技術發展的重要方向。開發團隊應積極擁抱這些新技術和理念,並著重於解決冷啟動、IaC 複雜度等關鍵挑戰,才能充分釋放雲端技術的潛力,在快速變化的市場競爭中保持領先地位。