Amazon Lambda無伺服器函式作為亞馬遜雲科技主推的雲原生技術，是不折不扣的雲原生第一梯隊。Lambda無伺服器函式自2014年由亞馬遜雲科技推出以來，被越來越多的雲原生應用所使用，到目前為止已經累計關聯了100餘項創新雲服務，同時為數百萬級的使用者提供服務，而每天的呼叫次數更是高達數百億次。
為什麼Lambda無伺服器函式具有如此大的魅力呢？
從開發者的角度來說，Lambda無伺服器函式充分利用了伺服器虛擬化技術，將過去開發者需要關注的伺服器配置、伺服器管理等工作進行了充分的封裝，讓開發者可以從伺服器管理的繁雜事務中脫離出來，將注意力集中到應用的開發工作中。
這種對於伺服器資源的封裝和抽象，毫無疑問地給開發者提供了極大的便利，讓開發者可以更快地迭代開發週期，可以以更精細的粒度來管理應用內的一個一個邏輯。這樣的便利對於提升開發者的生產效率十分有益。
從應用的運維角度而言，Lambda無伺服器函式則提供了前所未有的低成本高效率的執行平臺，各種自動化工具和自動化配置讓應用的運維變得更加方便。這一切的收益，都來自亞馬遜雲科技在伺服器虛擬化技術上的不斷迭代和創新。
自從亞馬遜雲科技最初推出的Amazon EC2伺服器以來，就打破了資訊科技業內對於伺服器的傳統印象。科技公司從自建伺服器機房，到租用虛擬伺服器VPS，再到擁抱雲端計算平臺EC2伺服器，到如今可以直接使用“無伺服器”的Lambda 函式，亞馬遜雲端計算平臺就在伺服器的虛擬化和抽象化不斷精進，讓一個一個的伺服器單元變得越來越小巧，也越來越高效，越來越易用。
這一切都是為著一個目的，就是讓雲端計算真正成為一種公共事業，如同自來水、電網和網際網路接入一般，可以高效率地服務更廣泛的使用者群體。
說了這麼多Lambda無伺服器函式的優點，但它也不是十全十美的。隨著越來越多的應用開始採用 Lambda 函式，它的一些缺點也慢慢開始暴露出來。其中一個最為使用者所詬病的問題就是冷啟動速度太慢的問題。
Lambda無伺服器函式的本質，實際上是一個小型的虛擬伺服器，或者稱為虛擬機器VM。這些虛擬機器在Lambda 函式沒有被呼叫的時候，會暫時處於休眠狀態以節省執行的算力和成本。
而當 Lambda 函式被呼叫的時候，虛擬機器則會經歷一段啟動、載入執行程式碼、初始化各種所需的資源這樣一個初始化呼叫過程，這一過程被稱為Lambda 函式的“冷啟動”。我們以執行java程式碼的Lambda 函式為例，它的冷啟動過程如下：
- Lambda函式提取部署程式碼包並將其內容複製到函式執行環境的新目錄中；
- Lambda函式確定程式碼的入口點；
- Lambda 函式將程式碼和依賴關係載入到記憶體中；
- Lambda 函式初始化任何所需的資源或服務；
- Lambda 函式設定任何必要的網路連線或安全策略；
- Lambda函式開始真正執行程式碼。
這個冷啟動過程有時候會需要消耗數十毫秒到數秒的時間，這就會導致呼叫Lambda 函式的應用變得反應遲緩，因此Lambda函式冷啟動的問題也成為了使用者詬病最多的問題。
亞馬遜雲科技積極響應使用者的需求，把降低冷啟動延遲的問題提上工作議程，經過數年的研發，終於在2022亞馬遜雲科技 re:Invent全球大會上推出了Amazon Lambda SnapStart技術，將執行java程式碼的Lambda函式的冷啟動時間降低了90%，而且也不需要使用者支付額外的費用即可享用Lambda SnapStart帶來的便捷。
下面的圖中對比了使用SnapStart技術啟動的過程和不使用SnapStart的啟動過程。很容易看出，SnapStart簡化了冷啟動過程，從而使得冷啟動的時間消耗大幅降低。
那麼，這麼一個猶如魔術般的 Lambda SnapStart 是如何做到將冷啟動時間降低的呢？這一技術進步，依然是得益於亞馬遜雲科技在伺服器虛擬化上的持續投入。
在re:Invent 2018上，亞馬遜雲科技推出了一個叫做Amazon Firecracker的高效虛擬機器，採用最新的容器化技術，在伺服器作業系統核心層面對伺服器資源做出了更細顆粒度的抽象，提升了虛擬機器的效能以及安全性。
而四年後的2022年，亞馬遜雲科技更是在Firecracker技術的基礎上，採取對Firecracker底層微型虛擬機器MicroVM加入快照功能，來實現微型虛擬機器的快速啟動。這一創新技術為我們帶來的，就是Lambda函式將史無前例地可以將啟動延遲壓縮到亞秒級，在過去的基礎上實現了數量級（10倍）上的提升。
目前Lambda SnapStart暫時僅支援執行Java 11程式碼的Lambda函式，但由於這項技術並不依賴於Java或者任何一門程式語言，未來亞馬遜雲科技也一定會將這項技術用於所有的Lambda無伺服器函式。
所以說，這個Lambda SnapStart的神奇之處就在於在微型虛擬機器上的快照功能。微型虛擬機器所採用的容器技術在近五年裡得到長足的發展，而容器作為伺服器作業系統核心提供的資源隔離技術，讓亞馬遜雲科技把雲端計算平臺上的“最小計算單元”向下推進了一層，讓微型虛擬機器MicroVM以容器的方式被啟動和管理。
並且，因為容器本身能夠提供快照，將容器的狀態定格記錄下來，如此一來就能在下次啟動微型虛擬機器MicroVM的時候，直接載入容器快照，從而繞過繁瑣的虛擬機器啟動和程式碼、依賴以及計算資源的載入過程。
不過，在工程領域永遠都沒有銀彈。Lambda SnapStart技術雖然神奇，卻也不是完美無缺的，它同樣有著使用上的限制。亞馬遜雲科技給予了開發者一個使用Lambda SnapStart的指引，裡面列舉了三個SnapStart不適用的場景：
1、在Lambda函式里包含具備唯一性的資訊，例如獨一無二的ID數。當Lambda函式從快照中快速啟動，其快照儲存的之前的獨一無二的ID數字就無法保證其唯一性。亞馬遜雲科技建議此型別的Lambda函式要在啟動後驗證該“獨一無二”的ID數以確保後續的執行邏輯正確；
2、在Lambda函式中的網路連線。因為網路連線發生於Lambda函式啟動以後，因此Lambda函式上一次快照中的網路狀態，在從快照恢復後應該檢查其網路連線狀態；
3、在Lambda函式中存在臨時資料。例如在Lambda函式中包含登入token，在從快照中恢復後，其臨時的登入token可能已經失效，因此需要Lambda函式來重新建立所需的臨時資料。
不難看出，因為Lambda SnapStart依賴於該微型虛擬機器MicroVM過去的狀態，凡是狀態依賴於時間變化的Lambda函式，都需要在引入SnapStart後細緻管理那些根據時間變化而變化的狀態，而不能預設這些狀態維持不變。
re:Invent 2022 全球大會上推出的Amazon Lambda SnapStart是本年度雲端計算領域的重磅科技進步，Lambda SnapStart進一步鞏固了亞馬遜雲端計算在無伺服器計算領域的優勢。這既是亞馬遜雲科技的研發實力的體現，也是亞馬遜雲科技以客戶為本的理念的表現。
即刻點選https://www.awsevents.cn/reIn...，觀看 INNOVATE 線上大會精彩回放！