Serverless：云計算的標配（云計算 sla）
Serverless，字面意思就是不需要服務器，由Iron公司在2012年第一次提出。被大家熟知是2015年，AWS推出Lambda的時候，Lambda產(chǎn)品的推出開啟了云計算時代，之后國內(nèi)外云計算市場一片紅火，微軟、谷歌、IBM都推出了自己的Serverless產(chǎn)品，
國內(nèi)的阿里云和騰訊云早在2017年也推出了Serverless平臺，那個時候被稱之為Faas(Function as a Service) 。國內(nèi)2018年，Serverless的概念突然火了起來，更多的還是支付寶小程序和微信小程序的云開發(fā)平臺，隨后到2019年，國內(nèi)包括華為、百度也都開始做Serverless，現(xiàn)在Serverless已經(jīng)成了各大云廠商的標配。
2019年2月，加州大學伯克利分校發(fā)表了名為《Cloud Programming Simplified: A Berkerley View on Serverless Computing》的論文，對Serverless的形成、現(xiàn)狀以及未來進行了全面的梳理和總結(jié)，并預言Serverless將成為云計算標配。
“We predict that serverless computing will grow to dominate the future of cloud computing” – Berkeley CS Dept
Serverless是什么？
早在2009年，伯克利曾對當時興起的云計算做評論，幫助解釋圍繞云計算的興奮點，提出運用云計算的6個潛在優(yōu)勢：
- 無限可用的計算資源
- 用戶再也不需要承擔服務器運維的工作和責任
- 服務的按需付費成為可能
- 超大型數(shù)據(jù)中心的使用成本顯著降低
- 通過可視化資源管理，運維操作的難度大大降低
- 得益于分時復用，物理硬件的利用率大大提高
2019年伯克利發(fā)表對Serverless計算的觀點時，認為這些優(yōu)勢基本實現(xiàn)，但云用戶仍然承受著來自復雜操作和的負擔，這些不足主要源于未能實現(xiàn)最后兩個潛在優(yōu)勢。
雖然云計算減輕了用戶對物理基礎設施的管理，但他們卻需要管理大量的虛擬資源，為了保障云上服務的穩(wěn)定性，研發(fā)或運維團隊需要解決很多問題，如：
- 提供冗余容錯能力，保證一臺機器出現(xiàn)故障時不會影響到整個服務
- 異地容災和備份機制
- 能夠有效利用硬件資源的負載均衡方案
- 響應式地調(diào)整服務的規(guī)模，實現(xiàn)自動擴容
- 實時監(jiān)控服務器是否正常運行
- 記錄足夠的日志信息，方便debug和性能調(diào)優(yōu)
- 系統(tǒng)升級問題，包括安全補丁
- 能夠快速將服務遷移到新實例的能力
上面每一個問題復雜度都非常高，需要云用戶投入大量的人力物力資源來解決，對小規(guī)模的公司而言，全靠自己來解決幾乎不太可能；另一方面，基于底層硬件虛擬化的方案導致單個服務的開發(fā)成本非常高，如簡單的業(yè)務功能，卻需要添加龐大的框架和中間件，如RPC、緩存、數(shù)據(jù)庫、監(jiān)控、日志等，此案能在云實例上運行，這嚴重拖慢了開放效率。
為了解決這些問題，亞馬遜在2015年推出了AWS Lambda服務，提出Cloud Function的概念，并引起業(yè)界對Serverless的廣泛關注。Cloud Function最終被平臺打包成FaaS（Function as a Service，函數(shù)即服務）的形式，它代表了Serverless的核心理念，當然云平臺也提供以BaaS（Backend as a Service，后端即服務）形式的Serverless服務，簡單來說，Serverless Computing = FaaS BaaS。
Serverless計算的架構(gòu)圖，如下所示：
Serverless應用通過Cloud Function及基礎BaaS服務，如Object Storage、KV、DataBase、Messaging等，提高了應用交付的效率。Serverless 相對于 Serverful，對業(yè)務用戶強調(diào) noserver（serverless 并不是說沒有服務器，只是業(yè)務人員無需關注服務器了，代碼仍然是運行在真實存在的服務器上）的運維理念，業(yè)務人員只需要聚焦業(yè)務邏輯代碼。
伯克利認為，Serverless相比Serverful，有三個顯著的改變：
- 弱化了存儲和計算之間的聯(lián)系，服務的存儲和計算被分開部署和收費，服務的存儲不再是它本身的一部分，而是演變成了獨立的云服務，這使得計算變得無狀態(tài)，更容易調(diào)度和擴縮容，同時降低了數(shù)據(jù)丟失的風險。
- 代碼的執(zhí)行不再需要手動分配資源，我們再也不需要為服務器的運行指定所需的資源，如使用幾臺服務器、多大帶寬、多大磁盤，只需要提交代碼，剩下的由Serverless平臺去處理就行了。
- 按使用量計費，Serverless按照服務的使用量進行計費，如調(diào)用次數(shù)、時長等，而不像serverful服務那樣，按照使用的資源計費，如ECS實例數(shù)量、規(guī)格等。
總結(jié)：Serverless讓開發(fā)人員只需關注業(yè)務邏輯代碼，不需要再關注服務器，Serverless應用可以自動擴縮容，按量計費，并由服務提供方托管運維職責。
Serverless的價值
對云用戶來說，Serverless計算帶來的主要收益是編程生產(chǎn)力的提高，以及許多場景下節(jié)省支出。開發(fā)者不需要完全理解云基礎設施如何運作，也能快速編寫出可用的代碼，而且Serverless節(jié)省了他們部署和運維的時間，讓開發(fā)者專注于解決和優(yōu)化應用本身的問題。
對云服務商來說，Serverless計算簡化了云端編程模型，能夠吸引更多新客戶，而對于已有客戶，Serverless計算使得它們能夠更好地利用云資源。伯克利的一項調(diào)查表明，serverless的使用群體中，24%是第一次接觸云計算；另外，Serverless計算運算時間短、內(nèi)存使用少以及無狀態(tài)的特性讓云服務商能夠充分利用云資源，進一步提高資源利用率。云服務商甚至可以用一些已經(jīng)“過?！钡呐f服務器來運行Serverless服務，增加服務器的折舊年限，從而減少成本。如果ARM或RISC-V能夠提供比x86更好的表現(xiàn)，服務商可以很方便地替換指令集，甚至針對特定的開發(fā)語言進行加速。
有云廠商說云服務是“超賣”的生意，但“超賣”提高資源利用率的同時也導致業(yè)務確定性降低，這對商業(yè)客戶來說是致命的；而AWS通過Serverless服務給客戶提供穩(wěn)定的服務質(zhì)量合同，同時提高了資源利用率，實現(xiàn)雙贏。
Serverless計算最受歡迎的幾個應用場景，如下：
雖然Serverless Cloud Function已經(jīng)被成功應用于很多不同的場景，但仍然有許多場景無法使用Serverless計算，伯克利的報告也分析目前Serverless的一些局限，如云服務商提供的存儲服務仍然存在很大限制（如內(nèi)存存儲成本高，對象存儲吞吐量低），難以支撐需要共享精細狀態(tài)的應用；云服務消息通知能力比較弱，如SQS延遲可能高達上百毫秒；缺乏標準的通信模式，基于函數(shù)的通信模型會導致通信泛濫；性能瓶頸，如冷啟動、異構(gòu)硬件性能的差異。
對于是否應該使用Serverless，可以參考Azure計算選型的示意圖：
Serverless服務
2015年AWS推出Lambda服務，提出了Cloud Function概念，Serverless正式被業(yè)界接受，但Serverless服務形態(tài)并不局限于Cloud Function，只要符合Serverless三大特征的服務都可以視為Serverless服務。
Lambda是一項計算服務，可使你無需預置或管理服務器即可運行代碼，Lambda在高可用的計算基礎設施上運行你的代碼，執(zhí)行計算資源的所有管理工作，其中包括服務器、操作系統(tǒng)維護、容量調(diào)配和彈性伸縮、代碼監(jiān)控和記錄。除AWS Lambda外，還有其它Cloud Function服務，包括Azure Function、Google Cloud Function、Aliyun 函數(shù)計算、騰訊云函數(shù)等。
AWS Fargate是適用于容器的無服務器計算，其與ECS（Elastic Container Service）和EKS（Elastic Kubernetes Service）兼容，使客戶可以專注于構(gòu)建應用程序，為其指定資源付費，而無需預置和管理服務器。除AWS Fargate外，還有其他適用于容器的無服務器計算服務，包括Azure Container Apps、Google Cloud Run、Aliyun ASK等。
此外，AWS還提供了與Serverless計算相配合的其他服務，如EventBridge、Step Functions、SQS、API Gateway，以及數(shù)據(jù)存儲服務，如S3、DynamoDB、Aurora Serverless等，當然其他云服務商也有類似服務。
權威咨詢機構(gòu)Forester發(fā)布2021年Q1 FaaS評估報告，將Alibaba、Amazon和Microsoft評為領導者。
Serverless的發(fā)展狀況
# CNCF（Cloud Native Computing Foundation）調(diào)查報告
2021年CNCF調(diào)查報告表明，39%的受訪者正在使用Serverless，其中75%的用戶采用托管平臺，比2020年增長了24%。
2021年DataDog容器調(diào)查報告表明，AWS ECS容器客戶40%使用Fargate（無服務器容器）。
# State-of-Serverless報告
2021年DataDog發(fā)布Serverless研究報告表明，從云原生初創(chuàng)公司到大型企業(yè)都在關注Serverless，Serverless生態(tài)已經(jīng)超越了FaaS，包含數(shù)十種服務，可以幫助開發(fā)人員構(gòu)建更快、更動態(tài)的應用程序。
Lambda函數(shù)調(diào)用次數(shù)比2年前增長了3.5倍
AWS lambda是最成熟和使用最廣泛的FaaS產(chǎn)品，50%以上的AWS用戶使用了Lambda，同時Azure Functions的使用率從20%增長到36%，而Google Cloud Functions也有近四分之一的用戶使用。
四分之一的CloudFront用戶已采用邊緣Serverless計算，如Lambda@Edge可以根據(jù)用戶特征（如設備類型）動態(tài)轉(zhuǎn)換圖像，或者為不同版本的Web應用程序提供A/B測試。
盡管AWS提供了云開發(fā)工具包（CDK）、Serverless應用程序模型（SAM），開源的Serverless Framework是使用最廣泛的Lambda部署工具，90%的組織使用它來管理他們使用的AWS CloudFormation的Serverless資源。
Python是最流行的Lambda運行時，尤其是在大型企業(yè)中，而小企業(yè)中Node.js應用更廣泛。
思考題
# Serverless服務鎖定問題
通常來說，不同的Serverless服務商所提供的函數(shù)語義是不同的，而且Serverless應用還依賴一些非標準化的BaaS服務，如API網(wǎng)關、對象存儲、KV數(shù)據(jù)庫、認證等，因此Serverless應用一般都是針對特定平臺。如果要實現(xiàn)可移植性，Serverless應用需要使用某種規(guī)范化的API，CNCF下Knative項目為開發(fā)人員提供了一套統(tǒng)一的、跨部署環(huán)境的API，可以作為一個選擇。
服務商鎖定你，頂多問你多要幾分錢，如果不選擇優(yōu)秀服務商，各種服務都選擇自建的話，你的產(chǎn)品可能沒有競爭對手迭代快，而競爭對手會要你的命。
# SAM與Serverless
Serverless Application Model（SAM）是AWS提出的Serverless應用模型，Serverless應用包括函數(shù)（lambda）、事件源（event）以及共同執(zhí)行任務的其他資源，其定義了Serverless應用相關的基礎設施，以在AWS上準備、構(gòu)建和部署Serverless應用，可以將SAM看作Serverless Infrastructure as a Code，一個簡單的SAM示例如下：
基礎架構(gòu)即代碼（IaC）是通過代碼來管理和配置基礎架構(gòu)的方法，Serverless應用中服務提供商來負責基礎架構(gòu)管理，客戶按SAM模型定義應用，SAM將相應的配置轉(zhuǎn)換為AWS的CloudFormation語法，以控制相關的資源。
從上文DataDog的報告中，我們看到Serverless Framework是比SAM應用更廣泛的交付工具。
# Kubernetes與Serverless
Kubernetes是一個容器調(diào)度平臺，通過聲明式配置自動管理容器負載，其本身并不是Serverless，目前一些K8S平臺提供商基于Kubernetes平臺提供了全托管Serverless計算服務，如Google Cloud Run 以容器和Knative開放式標準為基礎構(gòu)建，客戶不需要關心基礎架構(gòu)的運維，并支持各種開發(fā)語言；阿里云提供ASK服務，客戶不需要購買即可直接部署應用，也無需對集群進行節(jié)點和容量規(guī)劃，根據(jù)應用配置的規(guī)格按需付費，并根據(jù)應用負載自動彈性伸縮。
# WebAssembly與Serverless
Serverless主流技術是采用沙箱容器來實現(xiàn)強隔離的安全執(zhí)行環(huán)境，但也帶來了更多的性能損耗。如AWS沙箱經(jīng)過優(yōu)化啟動時間已經(jīng)可以實現(xiàn)低于300ms的冷啟動速度，但仍無法滿足函數(shù)服務毫秒級的啟動要求，目前需要投入通過調(diào)度策略，預留一定的“Warn-up”實例才能滿足，但這樣也引入了更多的資源消耗。
WebAssembly（WASM）是由W3C定義的全新的Web格式規(guī)范，是一個通用、開放、高效、安全的底層虛擬機抽象，它的設計初衷是為了解決JavaScript的性能問題，使得Web應用有接近本機原生應用的性能，可以將現(xiàn)有編程語言，如C/C 、Rust、Golang等，編譯成WASM字節(jié)碼，運行在瀏覽器的沙箱環(huán)境。2019年，Mozilla推出WebAssembly System Interface（WASI），它提供類似POSIX這樣的標準API來標準化WebAssembly與系統(tǒng)資源的交互抽象，如文件系統(tǒng)、內(nèi)存管理、GPU等，WASI的出現(xiàn)拓展了WASM的應用場景，可以讓其作為一個虛擬機運行各種類型的服務器端應用。
WebAssembly所具備的安全、可移植、高效率、輕量化的特點，為應用沙箱的發(fā)展帶來了全新的思路。WASM可以輕松實現(xiàn)毫秒級冷啟動時間和極低的資源消耗，同時WASM字節(jié)碼比原生機器碼有更高的安全級別。此外WASM實現(xiàn)了細粒度基于能力的安全模型，遵循最小權限原則，在執(zhí)行過程中，WASI應用只能訪問由依賴注入的確切資源，相比傳統(tǒng)的操作系統(tǒng)級別隔離，進一步是收斂了安全攻擊面。
正因如此，WASM/WASI得到Serverless、Edge社區(qū)的廣泛關注，F(xiàn)astly、Cloudflare等廠商相繼發(fā)布基于WebAssembly技術實現(xiàn)了更輕量級的Serverless服務器，如Fastly發(fā)布lucet 運行時支持WASM，冷啟動時間只有幾十微秒，Cloudflare的Workers采用V8 Engine支持WASM。
Docker創(chuàng)始人在2019年發(fā)推，回答WASM是否會代替Docker？
WebAssembly也許不會很快取代Docker，但它在有些方面會有很大的應用，包括需要高性能和輕量級的，如JamStack、Edge、Serverless等。
吐槽大會（國內(nèi)云廠商的Serverless服務專場）
# 阿里云：“業(yè)內(nèi)首發(fā)實例級別可觀測性和調(diào)試” 驕傲了
2021年云棲大會，阿里云針對Serverless 聚焦行業(yè)規(guī)?；涞仉y點，發(fā)布7大技術突破，其中一條“業(yè)內(nèi)首發(fā)實例級別可觀測性和調(diào)試”。
為什么要引入實例級別指標？阿里云的說法是方便用戶評估并發(fā)數(shù)，以及排查實例問題，實例指標包括hostname、cpuPercent、memoryUsageMB、concurrentRequest等，一瞬間感覺又回到了Serverful的監(jiān)控場景，用戶要怎么理解cpuPercent跟賬單上的執(zhí)行時間之間的關系。
我們看一下DataDog對WatchCloud做了哪些增強指標，阿里云的產(chǎn)品經(jīng)理要不要反思一下？
# 騰訊云：云函數(shù)接口不全，難道要托關系？
騰訊云Serverless接口一團漿糊，觸發(fā)器有Create沒有Update，有List沒有Get，異步事件管理中連Create都沒有，卻有Terminate，這樣服務是面向開發(fā)人員的嗎？已經(jīng)上線的那些Serverless應用是不是都是托關系找到接口的？
本文介紹了Serverless及其價值，云服務商提供的Serverless服務，客戶的使用狀況，當然目前Serverless仍然有其局限性，具體業(yè)務場景是否適用于Serverless需要具體問題具體分析，希望本文對您理解Serverless及是否采用Serverless有些幫助。
