2009 年，加州大學(xué)伯克利分校發(fā)布了一篇論文《The Berkeley View on Cloud Computing》，正確預(yù)測了接下來十年的云計(jì)算演進(jìn)和普及。2019 年，伯克利又發(fā)布了一篇有著相同命名風(fēng)格的論文《A Berkeley View on Serverless Computing》，再次預(yù)言未來“無服務(wù)器計(jì)算將會發(fā)展成為未來云計(jì)算的主要形式”。無服務(wù)器被寄予厚望，但同時也存在一些爭議。如今，距離 2014 年 Amazon Lambda 首次發(fā)布已有七年時間，我們回頭去看，當(dāng)初那些無服務(wù)器的承諾都能兌現(xiàn)了嗎？

　　1.無服務(wù)器的承諾和爭議

　　“無服務(wù)器”術(shù)語最早出現(xiàn)在 2012 年左右的一篇文章里，作者 Ken Fromm 對它的解釋是：

　　“無服務(wù)器”一詞并不意味著不再涉及服務(wù)器，它只是意味著開發(fā)人員不再需要考慮那么多的物理容量或其他基礎(chǔ)設(shè)施資源管理責(zé)任。通過消除后端基礎(chǔ)設(shè)施的復(fù)雜性，無服務(wù)器讓開發(fā)人員將注意力從服務(wù)器級別轉(zhuǎn)移到任務(wù)級別。

　　雖然不少技術(shù)先知認(rèn)為無服務(wù)器架構(gòu)是“一項(xiàng)重大創(chuàng)新并將很快流行起來”，但這個概念在提出當(dāng)時并沒有得到很好的反響。

　　真正讓無服務(wù)器得到廣泛關(guān)注的事件是亞馬遜云科技于 2014 年推出 Amazon Lambda 服務(wù)。之后， 隨著谷歌和微軟等企業(yè)的服務(wù)進(jìn)入市場，“無服務(wù)器”才逐漸成為行業(yè)“熱詞”。

　　相較于“傳統(tǒng)服務(wù)”，無服務(wù)器計(jì)算的優(yōu)勢主要有幾點(diǎn)：

　　在無服務(wù)器平臺上，無需用戶自身去維護(hù)操作系統(tǒng)。開發(fā)人員只需要編寫云函數(shù)，選擇觸發(fā)云函數(shù)運(yùn)行的事件就可以完成工作。例如加載一個鏡像到云存儲中，或者向數(shù)據(jù)庫添加一個很小的圖片，讓無服務(wù)器系統(tǒng)本身來處理其他所有系統(tǒng)管理的操作，如選擇實(shí)例、部署、容錯、監(jiān)控、日志、安全補(bǔ)丁等等。

　　更好的自動擴(kuò)縮容方式，理論上能應(yīng)對突發(fā)的從“零”到“無窮大”的需求峰值。有關(guān)擴(kuò)展的決定由云提供商按需提供，開發(fā)人員不再需要編寫自動擴(kuò)展策略或定義機(jī)器級別資源（CPU、內(nèi)存等）的使用規(guī)則。

　　傳統(tǒng)云計(jì)算按照預(yù)留的資源收費(fèi)，而無服務(wù)器按照函數(shù)執(zhí)行時間收費(fèi)。這也意味著更加細(xì)粒度的管理方式。在無服務(wù)器框架上使用資源只需為實(shí)際運(yùn)行時間付費(fèi)。這與傳統(tǒng)云計(jì)算收費(fèi)方式形成了鮮明對比，后者用戶需要為有閑置時間的計(jì)算機(jī)付費(fèi)。

　　作為云計(jì)算的下一個迭代，無服務(wù)器計(jì)算讓開發(fā)者可以更關(guān)注于構(gòu)建產(chǎn)品中的應(yīng)用，而不需要管理和維護(hù)底層堆棧，且比傳統(tǒng)云計(jì)算更為便宜，因此無服務(wù)器被譽(yù)為“開發(fā)新應(yīng)用最快速的方式，同時也是總成本最低的方式”。

　　“伯克利觀點(diǎn)”甚至認(rèn)為，無服務(wù)器計(jì)算提供了一個接口，極大地簡化了云編程，這種轉(zhuǎn)變類似于“從匯編語言遷移到高級編程語言”。

　　從誕生開始，“無服務(wù)器”就被寄予了厚望，但在發(fā)展過程中也免不了會存在爭議，之前涉及到的一些問題有：

　　編程語言受限。大多數(shù)無服務(wù)器平臺僅支持運(yùn)行特定語言編寫的應(yīng)用。

　　供應(yīng)商鎖定風(fēng)險。在“函數(shù)”的編寫、部署和管理方式上，幾乎不存在跨平臺的標(biāo)準(zhǔn)。這意味著將“函數(shù)”從一個特定于供應(yīng)商的平臺遷移到另一個平臺非常耗時費(fèi)勁。

　　性能問題如冷啟動。如果某個“函數(shù)”之前未在特定平臺上運(yùn)行過，或是在一段時間內(nèi)未運(yùn)行，那么就需要耗費(fèi)一些時間做初始化。

　　2019 年被認(rèn)為是無服務(wù)器有重大發(fā)展的一年。在這一年的年底，亞馬遜云科技發(fā)布了 Amazon Lambda 的“預(yù)置并發(fā)（Provisioned Concurrency）”功能，它允許亞馬遜云科技無服務(wù)器計(jì)算用戶使其函數(shù)保持“已初始化并準(zhǔn)備好在兩位數(shù)毫秒內(nèi)響應(yīng)”的狀態(tài)，這意味著“冷啟動”問題成為過去，行業(yè)達(dá)到一個成熟點(diǎn)。

　　雖然這項(xiàng)技術(shù)仍然有較長的路要走，但隨著越來越多的公司，包括亞馬遜云科技、谷歌、微軟在這項(xiàng)技術(shù)上的投資，我們看到了無服務(wù)器采用率在持續(xù)增長。據(jù) Datadog 2021 年發(fā)布的無服務(wù)器狀態(tài)報告，開發(fā)人員正加速采用無服務(wù)器架構(gòu)：2019 年之后 Amazon Lambda 的使用率顯著增加，2021 年初，Amazon Lambda 函數(shù)的平均每天調(diào)用頻率是兩年前的 3.5 倍，且半數(shù) Amazon Web Services 新用戶已采用 Amazon Lambda。雖然微軟和谷歌的份額有所上升，但作為無服務(wù)器技術(shù)的先驅(qū)，Amazon Lambda 在采用率方面一直保持領(lǐng)先地位，有一半的函數(shù)即服務(wù)（FaaS）用戶在使用亞馬遜云科技的服務(wù)。據(jù) Amazon Web Services 公布的數(shù)據(jù)顯示，已有數(shù)十萬家客戶在用 Amazon Lambda 來構(gòu)建他們的服務(wù)。

　　2.通過 Amazon Lambda 看無服務(wù)器技術(shù)的演進(jìn)

　　Amazon Lambda 是一種事件驅(qū)動的計(jì)算引擎，亞馬遜云科技在 2014 年 11 月的亞馬遜云科技 re:Invent 大會上發(fā)布了該功能的預(yù)覽版本。這馬上引起了競爭對手的跟進(jìn)，不少企業(yè)紛紛開始在云上提供類似服務(wù)，谷歌于次年 2 月發(fā)布了 Cloud Functions， IBM 也于同月發(fā)布了 Bluemix OpenWhisk，微軟于次年 3 月份發(fā)布預(yù)覽版 Azure Functions，等等。

　　在 Amazon Web Services 的產(chǎn)品頁面上，亞馬遜云科技給 Amazon Lambda 下的定義是：“用戶無需預(yù)置或管理基礎(chǔ)設(shè)施即可運(yùn)行代碼。只需編寫代碼并將其作為 .zip 文件或容器鏡像上傳即可。”

　　一個簡單的用例是，西雅圖時報使用無服務(wù)器技術(shù)自動調(diào)整移動、平板電腦和桌面設(shè)備顯示所需的圖像大小，每當(dāng)圖像被上傳到 Amazon Simple Storage Service (S3) ，就會觸發(fā) Amazon Lambda 函數(shù)調(diào)用執(zhí)行調(diào)整圖像大小的功能。西雅圖時報僅在調(diào)整圖像大小后才向 Amazon Web Services 付費(fèi)。

　　Amazon Lambda 的關(guān)鍵進(jìn)展

　　對于要探索無服務(wù)器技術(shù)的團(tuán)隊(duì)來說，了解 Amazon Lambda 至關(guān)重要。無服務(wù)器雖然不等于 Amazon Lambda，但自 2014 年發(fā)布以來，Amazon Lambda 幾乎已成為 Amazon Serverless 服務(wù)的代名詞。實(shí)際上，Amazon Lambda 需要和其它工具一起才能形成一套完整的無服務(wù)器架構(gòu)，比如通過 Amazon API Gateway 發(fā)送 HTTP 請求，或調(diào)用 Amazon S3 存儲桶、Amazon DynamoDB 表或 Amazon Kinesis 流中的資源。

　　在發(fā)布早期，還只有 Amazon S3、Amazon DynamoDB 和 Amazon Kinesis 可用于 Amazon Lambda 函數(shù)。但自那之后，亞馬遜云科技又逐步為 Amazon Lambda 函數(shù)集成了許多其它服務(wù)，例如 Amazon Cognito 認(rèn)證、Amazon API Gateway、Amazon SNS 、Amazon SQS、Amazon CloudFormation 和 Amazon CloudWatch 等等。

　　在 2014 年推出時，Amazon Lambda 只支持 Node.js，2015 年底，Amazon Lambda 中添加了 Java 支持，2016 年的時候又添加了 Python 支持。到現(xiàn)在，Amazon Lambda 原生支持 Java、Go、PowerShell、Node.js、C#、Python 和 Ruby 代碼，并提供 Runtime API，允許用戶使用任何其它編程語言來編寫函數(shù)。

　　使用 Amazon Lambda ，用戶除上傳代碼（或在 Amazon Lambda 控制臺中構(gòu)建代碼）外，還需要選擇內(nèi)存、超時時間來創(chuàng)建函數(shù)。

　　最開始 Amazon Lambda 函數(shù)超時時長為 30 秒，后來被延長為 5 分鐘。2018 年 10 月，Amazon Web Services 將超時時長設(shè)置為了 15 分鐘，從此用戶可以運(yùn)行時間更長的函數(shù)，更加輕松地執(zhí)行大數(shù)據(jù)分析、批量數(shù)據(jù)轉(zhuǎn)換、批量事件處理和統(tǒng)計(jì)計(jì)算等任務(wù)。

　　Amazon Lambda 函數(shù)會根據(jù)配置的內(nèi)存量線性分配 CPU 和其他資源。2020 年底，Amazon Lambda 函數(shù)的內(nèi)存上限調(diào)整為了 10 GB ，與之前相比增加了 3 倍多，這也意味著用戶可以在每個執(zhí)行環(huán)境中訪問多達(dá) 6 個 vCPU，可以讓用戶的多線程和多進(jìn)程程序運(yùn)行得更快。

　　在發(fā)布至今這七年里，Amazon Serverless 服務(wù)各方面都在不斷改進(jìn)：

　　2016 年，亞馬遜云科技發(fā)布了 Amazon Step Functions，可以組合調(diào)用多個 Amazon Lambda 函數(shù)和其它 Amazon 服務(wù)，將復(fù)雜的業(yè)務(wù)邏輯可視化地表達(dá)為低代碼、事件驅(qū)動的工作流。

　　2017 年，Amazon Lambda 的默認(rèn)并發(fā)數(shù)提升到了 1000，并提供了分布式跟蹤工具 X-Ray。

　　2018 年，亞馬遜云科技發(fā)布了 Amazon Aurora Serverless v1 版本，正式宣告更復(fù)雜的關(guān)系型數(shù)據(jù)庫（RDBMS）也能具備 Serverless 的特性，實(shí)現(xiàn)了云數(shù)據(jù)庫基于負(fù)載的自動啟停與彈性擴(kuò)展。隨著云服務(wù)的演化，亞馬遜云科技相繼發(fā)布了五項(xiàng) Serverless 數(shù)據(jù)庫服務(wù)，包括 Amazon Aurora Serverless、Amazon DynamoDB、Amazon Timestream（一種時間序列數(shù)據(jù)庫服務(wù)）、Amazon Keyspaces（兼容 Apache Cassandra 的托管數(shù)據(jù)庫服務(wù)）和 Amazon QLDB（一種全托管的分類賬數(shù)據(jù)庫）。目前，Amazon Aurora Serverless 已從 v1 版進(jìn)化到 v2 版，Aurora Serverless v2 可以在一秒內(nèi)將數(shù)據(jù)庫工作負(fù)載從數(shù)百個事務(wù)擴(kuò)展到數(shù)十萬個事務(wù)，與為峰值負(fù)載配置容量的成本相比，最多可節(jié)省 90% 的數(shù)據(jù)庫成本。

　　2019 年，亞馬遜云科技發(fā)布了 Amazon EventBridge，它是一種無服務(wù)器事件總線服務(wù)，作為集中式樞紐連接到 Amazon Web Services 服務(wù)、自定義應(yīng)用程序和 SaaS 應(yīng)用程序，提供從事件源到目標(biāo)對象（例如 Amazon Lambda 和其他 SaaS 應(yīng)用程序）的實(shí)時數(shù)據(jù)流?，F(xiàn)在 Amazon Lambda 可與 200 多種 Amazon Web Services 服務(wù)和 SaaS 應(yīng)用程序相集成。

　　同年，亞馬遜云科技還推出了 Amazon S3 Glacier Deep Archive，進(jìn)一步按讀寫冷熱程度完善了 S3 存儲服務(wù)的智能收費(fèi)檔次。

　　2021 年 Amazon Lambda 計(jì)費(fèi)功能調(diào)整為了 1ms 級別，并且還提供了容器鏡像支持，以及 Amazon Graviton2 處理器支持，與基于 x86 的同類產(chǎn)品相比，Amazon Graviton2 性價比最高可提升 34%。

　　冷啟動和廠商鎖定

　　“冷啟動”的性能改善算得上是一次標(biāo)志性事件。FaaS 平臺初始化函數(shù)實(shí)例需要一些時間。即使對于同一個特定的功能，不同的平臺之間這種啟動延遲可能會有很大差異，從幾毫秒到幾秒不等，取決于使用的庫、函數(shù)配置的算力等大量因素。以 Amazon Lambda 為例，Amazon Lambda 函數(shù)的初始化要么是“熱啟動”，要么是“冷啟動”?！盁釂印笔菑那耙粋€事件中重用 Amazon Lambda 函數(shù)的實(shí)例及其宿主容器，“冷啟動”需要創(chuàng)建一個新的容器實(shí)例，啟動函數(shù)宿主進(jìn)程。在考慮啟動延遲時，“冷啟動”更受關(guān)注。

　　亞馬遜云科技在 2019 年提供了一項(xiàng)名為“預(yù)置并發(fā)（Provisioned Concurrency）” 的重要新功能，通過讓函數(shù)保持初始化狀態(tài)，從而更精確地控制啟動延遲。用戶需要做的就是設(shè)置一個值，指定平臺需要為特定功能配置多少個實(shí)例，Amazon Lambda 服務(wù)本身將確保始終有該數(shù)量的預(yù)熱實(shí)例等待工作?！袄鋯印睙o疑是無服務(wù)器技術(shù)批評者指出的最大問題，而亞馬遜云科技這項(xiàng)功能的出現(xiàn)，代表著關(guān)于“冷啟動”的爭議已經(jīng)結(jié)束。

　　除此之外，“廠商鎖定”也是一個極具爭議的地方。幾年前，作為無服務(wù)器技術(shù)的反對方，CoreOS 首席執(zhí)行官 Alex Polvi 稱 Amazon Lambda 無服務(wù)器產(chǎn)品“是我們在人類歷史上見過的最糟糕的專有鎖定形式之一”。而為 MongoDB 工作的 Matt Asay 撰文反駁他說，“完全避免鎖定的方法是自己編寫所有底層軟件（事件模型、部署模型等）”。

　　總之，作為支持方，很多人認(rèn)為“鎖定”并不是一件非黑即白的事情，而是本身需要反復(fù)權(quán)衡的一種架構(gòu)選擇。還有技術(shù)專家表示，可以采用將應(yīng)用程序和平臺分離的設(shè)計(jì)方式，以及標(biāo)準(zhǔn)化技術(shù)的方法最小化遷移成本：如果使用標(biāo)準(zhǔn)化的 HTTP，那么可以使用 Amazon API Gateway 將 HTTP 請求轉(zhuǎn)換為 Amazon Lambda 事件格式；如果使用標(biāo)準(zhǔn)化的 SQL，那么使用與 MySQL 兼容 Amazon Aurora Serverless，可以自然地簡化數(shù)據(jù)庫的遷移路徑......

　　最佳實(shí)踐案例

　　發(fā)展到現(xiàn)在，用戶在哪些場景下會使用無服務(wù)器計(jì)算？實(shí)際上，每年的亞馬遜云科技 re:Invent 大會都會有一些團(tuán)隊(duì)給大家分享實(shí)踐經(jīng)驗(yàn)，其中不乏具有代表性的案例。

　　在 2017 年的亞馬遜云科技 re:Invent 會議上，美國電信 Verizon 的 Revvel 團(tuán)隊(duì)介紹了他們?nèi)绾问褂?Amazon Lambda 和 Amazon S3 進(jìn)行視頻不同格式的轉(zhuǎn)碼。早先團(tuán)隊(duì)使用的是 EC2 實(shí)例，如果視頻長達(dá) 2 小時或大到幾百 G，問題就變得很棘手，高清轉(zhuǎn)換可能需要 4-6 個小時，而轉(zhuǎn)換工作中途一旦停止或中斷就意味著前功盡棄。所以，Revvel 團(tuán)隊(duì)采用的新方法是將視頻分為 5M 的小塊分別存儲在 Amazon S3 存儲桶中，然后用 Amazon Lambda 啟用上千實(shí)例并行計(jì)算，完成轉(zhuǎn)碼后再合并成一個完整的視頻，整個過程縮短到不足 10 分鐘，費(fèi)用也降低到了原來的十分之一。

　　在 2020 年的亞馬遜云科技 re:Invent 會議上，Coca-Cola 的 Freestyle 設(shè)備創(chuàng)新團(tuán)隊(duì)分享了他們的非接觸式售賣機(jī)解決方案：使用 Amazon Lambda 和 Amazon API Gateway 構(gòu)建后端托管服務(wù)，前端使用 Amazon CloudFront ，從而可以在一周內(nèi)推出原型，并在三個月內(nèi)將 Web 應(yīng)用程序從原型擴(kuò)展到 10000 臺機(jī)器，進(jìn)而在疫情期間快速占領(lǐng)市場。

　　在今年的亞馬遜云科技 re:Invent 會議主題演講里，Werner Vogels 博士講述了 New World Game 多人游戲中的無服務(wù)器解決方案。這是一款非常復(fù)雜的大規(guī)模分布式實(shí)時游戲，可處理 30 次 /s 的動作或狀態(tài)，重繪和計(jì)算需要大量的 CPU 資源。它通過每 30 秒 80 萬次寫入將用戶的狀態(tài)存儲在 Amazon DynamoDB 中，這樣用戶即使意外中斷游戲也能及時恢復(fù)到之前的游戲狀態(tài)。同時通過日志記錄用戶操作，然后使用 Amazon Kinesis 傳輸日志事件，速度可達(dá) 2300 萬事件 / 分鐘，隨后將事件流推送到 Amazon S3 中，再用 Amazon Athena 進(jìn)行分析處理。利用該數(shù)據(jù)流，團(tuán)隊(duì)可即時預(yù)測游戲用戶行為和更改游戲中的策略。游戲環(huán)境中的運(yùn)營，比如登錄、交易、通知等操作事件，都是通過 Amazon Lambda 無服務(wù)器計(jì)算來實(shí)現(xiàn)的。

　　無服務(wù)器在這款多人游戲中發(fā)揮了非常重要的作用，但這種大型架構(gòu)也對無服務(wù)器的性能提出了非常大的挑戰(zhàn)。Amazon Lambda 達(dá)到了每分鐘 1.5 億次的調(diào)用頻率，這比行業(yè)里的平均水準(zhǔn)高出數(shù)倍。

3.無服務(wù)器的未來

　　在今年年底，亞馬遜云科技一口氣推出了五款無服務(wù)器產(chǎn)品：

　　Amazon Redshift Serverless，可自動配置計(jì)算資源，使用 SQL 跨數(shù)據(jù)倉庫、運(yùn)營數(shù)據(jù)庫和數(shù)據(jù)湖分析結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。

　　Amazon EMR Serverless（預(yù)覽版），是 Amazon EMR 中的一個新選項(xiàng)，讓數(shù)據(jù)工程師和分析師能夠借助開源分析框架，例如 Apache Spark、Hive 和 Presto，在云中運(yùn)行 PB 級數(shù)據(jù)分析。

　　Amazon MSK Serverless（公開預(yù)覽版），全新類型的 Amazon MSK 集群，完全兼容 Apache Kafka，且無需管理 Kafka 的容量，服務(wù)會自動預(yù)置和擴(kuò)展計(jì)算及存儲資源。

　　Amazon Kinesis On-demand，用于大規(guī)模實(shí)時流數(shù)據(jù)處理，服務(wù)會自動按需擴(kuò)展和縮減。

　　Amazon SageMaker Serverless Inference（預(yù)覽版），讓開發(fā)者無需配置或管理底層基礎(chǔ)設(shè)施即可部署機(jī)器學(xué)習(xí)模型進(jìn)行推理，按執(zhí)行時間和處理的數(shù)據(jù)量付費(fèi)。

　　由此，我們可以看到云上的 Serverless 服務(wù)越來越多，無服務(wù)器計(jì)算的能力已經(jīng)從計(jì)算、存儲、數(shù)據(jù)庫服務(wù)擴(kuò)展到數(shù)據(jù)分析，以及機(jī)器學(xué)習(xí)的推理。以前機(jī)器學(xué)習(xí)的推理需要啟動大量的資源來支撐峰值請求。如果使用 EC2 推理節(jié)點(diǎn)，空閑資源會推高成本，而使用 Amazon Lambda 服務(wù)，就不需要再考慮集群節(jié)點(diǎn)管理這些事情，服務(wù)會根據(jù) Workload 自動預(yù)置、擴(kuò)展和關(guān)閉計(jì)算容量，只為執(zhí)行時間和處理的數(shù)據(jù)量付費(fèi)，相比之下能節(jié)省很多。

　　Amazon Serverless 服務(wù)在不斷進(jìn)化的同時，計(jì)算架構(gòu)也在不斷改進(jìn)，比如用戶可以將原來的 Intel x86 處理器，通過平臺提供的選項(xiàng)配置為 Amazon Graviton2 ARM 處理器，性能更快且能便宜 20%。有技術(shù)專家認(rèn)為，平臺也會朝著更智能的方向發(fā)展，“現(xiàn)在需要用戶改配置選擇更便宜的 ARM 處理器，未來服務(wù)完全可以做到自動選擇計(jì)算平臺。”

　　作為云計(jì)算的一種演進(jìn)方式，無服務(wù)器的愿景必定會改變我們對編寫軟件的看法。以前從來沒有一種方法可以像云計(jì)算這樣考慮如何使用數(shù)百萬個處理器內(nèi)核和 PB 級內(nèi)存進(jìn)行設(shè)計(jì)，而現(xiàn)在無服務(wù)器已經(jīng)進(jìn)入到通用和可用的階段，用戶無需考慮如何管理這些資源。

　　就像 Werner Vogels 博士在主題演講里講的那樣：“如果不用云計(jì)算，這些大型架構(gòu)根本無法實(shí)現(xiàn)。所以現(xiàn)在，用屬于 21 世紀(jì)的架構(gòu)去隨心構(gòu)建你夢想的系統(tǒng)吧（Build systems the way you always wanted to，but never could）?！?/p>