2009 年，加州大學伯克利分校釋出了一篇論文《The Berkeley View on Cloud Computing》，正確預測了接下來十年的雲計算演進和普及。2019 年，伯克利又釋出了一篇有著相同命名風格的論文《A Berkeley View on Serverless Computing》，再次預言未來“無伺服器計算將會發展成為未來雲計算的主要形式”。無伺服器被寄予厚望，但同時也存在一些爭議。如今，距離 2014 年 Amazon Lambda 首次釋出已有七年時間，我們回頭去看，當初那些無伺服器的承諾都能兌現了嗎？
1.無伺服器的承諾和爭議
“無伺服器”術語最早出現在 2012 年左右的一篇文章裡，作者 Ken Fromm 對它的解釋是：
“無伺服器”一詞並不意味著不再涉及伺服器，它只是意味著開發人員不再需要考慮那麼多的物理容量或其他基礎設施資源管理責任。透過消除後端基礎設施的複雜性，無伺服器讓開發人員將注意力從伺服器級別轉移到任務級別。
雖然不少技術先知認為無伺服器架構是“一項重大創新並將很快流行起來”，但這個概念在提出當時並沒有得到很好的反響。
真正讓無伺服器得到廣泛關注的事件是亞馬遜雲科技於 2014 年推出 Amazon Lambda 服務。之後， 隨著谷歌和微軟等企業的服務進入市場，“無伺服器”才逐漸成為行業“熱詞”。
相較於“傳統服務”，無伺服器計算的優勢主要有幾點：
- 在無伺服器平臺上，無需使用者自身去維護作業系統。開發人員只需要編寫雲函式，選擇觸發雲函式執行的事件就可以完成工作。例如載入一個映象到雲端儲存中，或者向資料庫新增一個很小的圖片，讓無伺服器系統本身來處理其他所有系統管理的操作，如選擇例項、部署、容錯、監控、日誌、安全補丁等等。
- 更好的自動擴縮容方式，理論上能應對突發的從“零”到“無窮大”的需求峰值。有關擴充套件的決定由雲提供商按需提供，開發人員不再需要編寫自動擴充套件策略或定義機器級別資源（CPU、記憶體等）的使用規則。
- 傳統雲計算按照預留的資源收費，而無伺服器按照函式執行時間收費。這也意味著更加細粒度的管理方式。在無伺服器框架上使用資源只需為實際執行時間付費。這與傳統雲計算收費方式形成了鮮明對比，後者使用者需要為有閒置時間的計算機付費。
作為雲計算的下一個迭代，無伺服器計算讓開發者可以更關注於構建產品中的應用，而不需要管理和維護底層堆疊，且比傳統雲計算更為便宜，因此無伺服器被譽為“開發新應用最快速的方式，同時也是總成本最低的方式”。
“伯克利觀點”甚至認為，無伺服器計算提供了一個介面，極大地簡化了雲程式設計，這種轉變類似於“從組合語言遷移到高階程式語言”。
從誕生開始，“無伺服器”就被寄予了厚望，但在發展過程中也免不了會存在爭議，之前涉及到的一些問題有：
- 程式語言受限。大多數無伺服器平臺僅支援執行特定語言編寫的應用。
- 供應商鎖定風險。在“函式”的編寫、部署和管理方式上，幾乎不存在跨平臺的標準。這意味著將“函式”從一個特定於供應商的平臺遷移到另一個平臺非常耗時費勁。
- 效能問題如冷啟動。如果某個“函式”之前未在特定平臺上執行過，或是在一段時間內未執行，那麼就需要耗費一些時間做初始化。
2019 年被認為是無伺服器有重大發展的一年。在這一年的年底，亞馬遜雲科技釋出了 Amazon Lambda 的“預置併發（Provisioned Concurrency）”功能，它允許亞馬遜雲科技無伺服器計算使用者使其函式保持“已初始化並準備好在兩位數毫秒內響應”的狀態，這意味著“冷啟動”問題成為過去，行業達到一個成熟點。
雖然這項技術仍然有較長的路要走，但隨著越來越多的公司，包括亞馬遜雲科技、谷歌、微軟在這項技術上的投資，我們看到了無伺服器採用率在持續增長。據 Datadog 2021 年釋出的無伺服器狀態報告，開發人員正加速採用無伺服器架構：2019 年之後 Amazon Lambda 的使用率顯著增加，2021 年初，Amazon Lambda 函式的平均每天呼叫頻率是兩年前的 3.5 倍，且半數 Amazon Web Services 新使用者已採用 Amazon Lambda。雖然微軟和谷歌的份額有所上升，但作為無伺服器技術的先驅，Amazon Lambda 在採用率方面一直保持領先地位，有一半的函式即服務（FaaS）使用者在使用亞馬遜雲科技的服務。據 Amazon Web Services 公佈的資料顯示，已有數十萬家客戶在用 Amazon Lambda 來構建他們的服務。
2.透過 Amazon Lambda 看無伺服器技術的演進
Amazon Lambda 是一種事件驅動的計算引擎，亞馬遜雲科技在 2014 年 11 月的亞馬遜雲科技 re:Invent 大會上釋出了該功能的預覽版本。這馬上引起了競爭對手的跟進，不少企業紛紛開始在雲上提供類似服務，谷歌於次年 2 月釋出了 Cloud Functions， IBM 也於同月釋出了 Bluemix OpenWhisk，微軟於次年 3 月份釋出預覽版 Azure Functions，等等。
在 Amazon Web Services 的產品頁面上，亞馬遜雲科技給 Amazon Lambda 下的定義是：“使用者無需預置或管理基礎設施即可執行程式碼。只需編寫程式碼並將其作為 .zip 檔案或容器映象上傳即可。”
一個簡單的用例是，西雅圖時報使用無伺服器技術自動調整移動、平板電腦和桌面裝置顯示所需的影象大小，每當影象被上傳到 Amazon Simple Storage Service (S3) ，就會觸發 Amazon Lambda 函式呼叫執行調整影象大小的功能。西雅圖時報僅在調整影象大小後才向 Amazon Web Services 付費。
Amazon Lambda 的關鍵進展
對於要探索無伺服器技術的團隊來說，瞭解 Amazon Lambda 至關重要。無伺服器雖然不等於 Amazon Lambda，但自 2014 年釋出以來，Amazon Lambda 幾乎已成為 Amazon Serverless 服務的代名詞。實際上，Amazon Lambda 需要和其它工具一起才能形成一套完整的無伺服器架構，比如透過 Amazon API Gateway 傳送 HTTP 請求，或呼叫 Amazon S3 儲存桶、Amazon DynamoDB 表或 Amazon Kinesis 流中的資源。
在釋出早期，還只有 Amazon S3、Amazon DynamoDB 和 Amazon Kinesis 可用於 Amazon Lambda 函式。但自那之後，亞馬遜雲科技又逐步為 Amazon Lambda 函式集成了許多其它服務，例如 Amazon Cognito 認證、Amazon API Gateway、Amazon SNS 、Amazon SQS、Amazon CloudFormation 和 Amazon CloudWatch 等等。
在 2014 年推出時，Amazon Lambda 只支援 Node.js，2015 年底，Amazon Lambda 中添加了 Java 支援，2016 年的時候又添加了 Python 支援。到現在，Amazon Lambda 原生支援 Java、Go、PowerShell、Node.js、C#、Python 和 Ruby 程式碼，並提供 Runtime API，允許使用者使用任何其它程式語言來編寫函式。
使用 Amazon Lambda ，使用者除上傳程式碼（或在 Amazon Lambda 控制檯中構建程式碼）外，還需要選擇記憶體、超時時間來建立函式。
最開始 Amazon Lambda 函式超時時長為 30 秒，後來被延長為 5 分鐘。2018 年 10 月，Amazon Web Services 將超時時長設定為了 15 分鐘，從此使用者可以執行時間更長的函式，更加輕鬆地執行大資料分析、批次資料轉換、批次事件處理和統計計算等任務。
Amazon Lambda 函式會根據配置的記憶體量線性分配 CPU 和其他資源。2020 年底，Amazon Lambda 函式的記憶體上限調整為了 10 GB ，與之前相比增加了 3 倍多，這也意味著使用者可以在每個執行環境中訪問多達 6 個 vCPU，可以讓使用者的多執行緒和多程序程式執行得更快。
在釋出至今這七年裡，Amazon Serverless 服務各方面都在不斷改進：
2016 年，亞馬遜雲科技釋出了 Amazon Step Functions，可以組合呼叫多個 Amazon Lambda 函式和其它 Amazon 服務，將複雜的業務邏輯視覺化地表達為低程式碼、事件驅動的工作流。
2017 年，Amazon Lambda 的預設併發數提升到了 1000，並提供了分散式跟蹤工具 X-Ray。
2018 年，亞馬遜雲科技釋出了 Amazon Aurora Serverless v1 版本，正式宣告更復雜的關係型資料庫（RDBMS）也能具備 Serverless 的特性，實現了雲資料庫基於負載的自動啟停與彈性擴充套件。隨著雲服務的演化，亞馬遜雲科技相繼釋出了五項 Serverless 資料庫服務，包括 Amazon Aurora Serverless、Amazon DynamoDB、Amazon Timestream（一種時間序列資料庫服務）、Amazon Keyspaces（相容 Apache Cassandra 的託管資料庫服務）和 Amazon QLDB（一種全託管的分類賬資料庫）。目前，Amazon Aurora Serverless 已從 v1 版進化到 v2 版，Aurora Serverless v2 可以在一秒內將資料庫工作負載從數百個事務擴充套件到數十萬個事務，與為峰值負載配置容量的成本相比，最多可節省 90% 的資料庫成本。
2019 年，亞馬遜雲科技釋出了 Amazon EventBridge，它是一種無伺服器事件匯流排服務，作為集中式樞紐連線到 Amazon Web Services 服務、自定義應用程式和 SaaS 應用程式，提供從事件源到目標物件（例如 Amazon Lambda 和其他 SaaS 應用程式）的實時資料流。現在 Amazon Lambda 可與 200 多種 Amazon Web Services 服務和 SaaS 應用程式相整合。
同年，亞馬遜雲科技還推出了 Amazon S3 Glacier Deep Archive，進一步按讀寫冷熱程度完善了 S3 儲存服務的智慧收費檔次。
2021 年 Amazon Lambda 計費功能調整為了 1ms 級別，並且還提供了容器映象支援，以及 Amazon Graviton2 處理器支援，與基於 x86 的同類產品相比，Amazon Graviton2 價效比最高可提升 34%。
冷啟動和廠商鎖定
“冷啟動”的效能改善算得上是一次標誌性事件。FaaS 平臺初始化函式例項需要一些時間。即使對於同一個特定的功能，不同的平臺之間這種啟動延遲可能會有很大差異，從幾毫秒到幾秒不等，取決於使用的庫、函式配置的算力等大量因素。以 Amazon Lambda 為例，Amazon Lambda 函式的初始化要麼是“熱啟動”，要麼是“冷啟動”。“熱啟動”是從前一個事件中重用 Amazon Lambda 函式的例項及其宿主容器，“冷啟動”需要建立一個新的容器例項，啟動函式宿主程序。在考慮啟動延遲時，“冷啟動”更受關注。
亞馬遜雲科技在 2019 年提供了一項名為“預置併發（Provisioned Concurrency）” 的重要新功能，透過讓函式保持初始化狀態，從而更精確地控制啟動延遲。使用者需要做的就是設定一個值，指定平臺需要為特定功能配置多少個例項，Amazon Lambda 服務本身將確保始終有該數量的預熱例項等待工作。“冷啟動”無疑是無伺服器技術批評者指出的最大問題，而亞馬遜雲科技這項功能的出現，代表著關於“冷啟動”的爭議已經結束。
除此之外，“廠商鎖定”也是一個極具爭議的地方。幾年前，作為無伺服器技術的反對方，CoreOS 執行長 Alex Polvi 稱 Amazon Lambda 無伺服器產品“是我們在人類歷史上見過的最糟糕的專有鎖定形式之一”。而為 MongoDB 工作的 Matt Asay 撰文反駁他說，“完全避免鎖定的方法是自己編寫所有底層軟體（事件模型、部署模型等）”。
總之，作為支援方，很多人認為“鎖定”並不是一件非黑即白的事情，而是本身需要反覆權衡的一種架構選擇。還有技術專家表示，可以採用將應用程式和平臺分離的設計方式，以及標準化技術的方法最小化遷移成本：如果使用標準化的 HTTP，那麼可以使用 Amazon API Gateway 將 HTTP 請求轉換為 Amazon Lambda 事件格式；如果使用標準化的 SQL，那麼使用與 MySQL 相容 Amazon Aurora Serverless，可以自然地簡化資料庫的遷移路徑......
最佳實踐案例
發展到現在，使用者在哪些場景下會使用無伺服器計算？實際上，每年的亞馬遜雲科技 re:Invent 大會都會有一些團隊給大家分享實踐經驗，其中不乏具有代表性的案例。
在 2017 年的亞馬遜雲科技 re:Invent 會議上，美國電信 Verizon 的 Revvel 團隊介紹了他們如何使用 Amazon Lambda 和 Amazon S3 進行影片不同格式的轉碼。早先團隊使用的是 EC2 例項，如果影片長達 2 小時或大到幾百 G，問題就變得很棘手，高畫質轉換可能需要 4-6 個小時，而轉換工作中途一旦停止或中斷就意味著前功盡棄。所以，Revvel 團隊採用的新方法是將影片分為 5M 的小塊分別儲存在 Amazon S3 儲存桶中，然後用 Amazon Lambda 啟用上千例項平行計算，完成轉碼後再合併成一個完整的影片，整個過程縮短到不足 10 分鐘，費用也降低到了原來的十分之一。
在 2020 年的亞馬遜雲科技 re:Invent 會議上，Coca-Cola 的 Freestyle 裝置創新團隊分享了他們的非接觸式售賣機解決方案：使用 Amazon Lambda 和 Amazon API Gateway 構建後端託管服務，前端使用 Amazon CloudFront ，從而可以在一週內推出原型，並在三個月內將 Web 應用程式從原型擴充套件到 10000 臺機器，進而在疫情期間快速佔領市場。
在今年的亞馬遜雲科技 re:Invent 會議主題演講裡，Werner Vogels 博士講述了 New World Game 多人遊戲中的無伺服器解決方案。這是一款非常複雜的大規模分散式實時遊戲，可處理 30 次 /s 的動作或狀態，重繪和計算需要大量的 CPU 資源。它透過每 30 秒 80 萬次寫入將使用者的狀態儲存在 Amazon DynamoDB 中，這樣使用者即使意外中斷遊戲也能及時恢復到之前的遊戲狀態。同時透過日誌記錄使用者操作，然後使用 Amazon Kinesis 傳輸日誌事件，速度可達 2300 萬事件 / 分鐘，隨後將事件流推送到 Amazon S3 中，再用 Amazon Athena 進行分析處理。利用該資料流，團隊可即時預測遊戲使用者行為和更改遊戲中的策略。遊戲環境中的運營，比如登入、交易、通知等操作事件，都是透過 Amazon Lambda 無伺服器計算來實現的。
無伺服器在這款多人遊戲中發揮了非常重要的作用，但這種大型架構也對無伺服器的效能提出了非常大的挑戰。Amazon Lambda 達到了每分鐘 1.5 億次的呼叫頻率，這比行業裡的平均水準高出數倍。
3.無伺服器的未來
在今年年底，亞馬遜雲科技一口氣推出了五款無伺服器產品：
Amazon Redshift Serverless，可自動配置計算資源，使用 SQL 跨資料倉庫、運營資料庫和資料湖分析結構化和非結構化資料。
Amazon EMR Serverless（預覽版），是 Amazon EMR 中的一個新選項，讓資料工程師和分析師能夠藉助開源分析框架，例如 Apache Spark、Hive 和 Presto，在雲中執行 PB 級資料分析。
Amazon MSK Serverless（公開預覽版），全新型別的 Amazon MSK 叢集，完全相容 Apache Kafka，且無需管理 Kafka 的容量，服務會自動預置和擴充套件計算及儲存資源。
Amazon Kinesis On-demand，用於大規模實時流資料處理，服務會自動按需擴充套件和縮減。
Amazon SageMaker Serverless Inference（預覽版），讓開發者無需配置或管理底層基礎設施即可部署機器學習模型進行推理，按執行時間和處理的資料量付費。
由此，我們可以看到雲上的 Serverless 服務越來越多，無伺服器計算的能力已經從計算、儲存、資料庫服務擴充套件到資料分析，以及機器學習的推理。以前機器學習的推理需要啟動大量的資源來支撐峰值請求。如果使用 EC2 推理節點，空閒資源會推高成本，而使用 Amazon Lambda 服務，就不需要再考慮叢集節點管理這些事情，服務會根據 Workload 自動預置、擴充套件和關閉計算容量，只為執行時間和處理的資料量付費，相比之下能節省很多。
Amazon Serverless 服務在不斷進化的同時，計算架構也在不斷改進，比如使用者可以將原來的 Intel x86 處理器，透過平臺提供的選項配置為 Amazon Graviton2 ARM 處理器，效能更快且能便宜 20%。有技術專家認為，平臺也會朝著更智慧的方向發展，“現在需要使用者改配置選擇更便宜的 ARM 處理器，未來服務完全可以做到自動選擇計算平臺。”
作為雲計算的一種演進方式，無伺服器的願景必定會改變我們對編寫軟體的看法。以前從來沒有一種方法可以像雲計算這樣考慮如何使用數百萬個處理器核心和 PB 級記憶體進行設計，而現在無伺服器已經進入到通用和可用的階段，使用者無需考慮如何管理這些資源。
就像 Werner Vogels 博士在主題演講裡講的那樣：“如果不用雲計算，這些大型架構根本無法實現。所以現在，用屬於 21 世紀的架構去隨心構建你夢想的系統吧（Build systems the way you always wanted to，but never could）。”
