第0章 從云計(jì)算到Serverless

表0-1　云計(jì)算面臨的問題和機(jī)遇

image-20220125072643731

圖0-3　IaaS、PaaS、SaaS的區(qū)別

image-20220125072716062

• 2018年馋吗，Serverless的發(fā)展速度要比想象中的更快鲁冯。在這一年，Google發(fā)布了Knative延届，一個(gè)基于Kubernetes的開源Serverless框架，具備構(gòu)建容器贸诚、流量調(diào)配方庭、彈性伸縮、零實(shí)例酱固、函數(shù)事件等能力械念。AWS發(fā)布了Firecracker，一個(gè)開源的虛擬化技術(shù)运悲，面向基于函數(shù)的服務(wù)龄减，創(chuàng)建和管控安全的、多租戶的容器班眯。Firecracker的目標(biāo)是把傳統(tǒng)虛擬機(jī)的安全性和隔離性與容器的訴求和資源效率結(jié)合起來希停。在這一年，CNCF也正式發(fā)布了Serverless領(lǐng)域的白皮書CNCFServerlessWhitepaperV1.0署隘，闡明Serverless技術(shù)概況宠能、生態(tài)系統(tǒng)狀態(tài)，為CNCF的下一步動(dòng)作做指導(dǎo)
• Serverless將會在接下來的十年間被大量采用磁餐，將會得到飛速的發(fā)展

1. 新的BaaS存儲服務(wù)會被發(fā)明违崇，以擴(kuò)展在Serverless計(jì)算上能夠運(yùn)行更加適配的應(yīng)用程序類型。這樣的存儲能夠與本地塊存儲的性能相匹配，而且具有臨時(shí)和持久兩個(gè)選項(xiàng)
2. 將出現(xiàn)比現(xiàn)有的x86微處理器更多的異構(gòu)計(jì)算機(jī)
3. Serverless架構(gòu)下的編程更安全羞延、易用
4. Serverless將會接入更多的后臺支撐服務(wù)渣淳，如OLTP數(shù)據(jù)庫、消息隊(duì)列服務(wù)等
5. Serverless將會成為云時(shí)代默認(rèn)的計(jì)算范式

圖0-4　Serverless發(fā)展歷程

image-20220125072758522

• 從IaaS伴箩、FaaS到SaaS水由，再到如今的Serverless，云計(jì)算在十余年中發(fā)生了翻天覆地的變化赛蔫，從虛擬空間到云主機(jī)砂客，從自建數(shù)據(jù)庫等業(yè)務(wù)到云數(shù)據(jù)庫等服務(wù)，云計(jì)算發(fā)展迅速呵恢，沒人知道云計(jì)算的終態(tài)是什么

第一部分 概念與產(chǎn)品

• 應(yīng)用或服務(wù)來管理服務(wù)器端邏輯和狀態(tài)的應(yīng)用鞠值，這些應(yīng)用通常是富客戶端應(yīng)用（單頁應(yīng)用或者移動(dòng)端App），建立在云服務(wù)生態(tài)之上渗钉，包括數(shù)據(jù)庫（Parse彤恶、Firebase）、賬號系統(tǒng)（Auth0鳄橘、AWSCognito）等声离。這些服務(wù)最早被稱為Baas（BackendasaService，后端即服務(wù)）
• 運(yùn)行在一個(gè)無狀態(tài)的計(jì)算容器中瘫怜，由事件驅(qū)動(dòng)术徊，生命周期很短（甚至只有一次調(diào)用），完全由第三方管理鲸湃。這種情況被稱為FaaS（Functionsasaservice赠涮，函數(shù)即服務(wù)）。AWSLambda是目前的熱門FaaS實(shí)現(xiàn)之一
• 通過MartinFowler的描述可以總結(jié)出FaaS暗挑、BaaS以及Serverless之間的關(guān)系笋除，如圖11所示

圖1-1　Serverless架構(gòu)的組成

image-20220125072839051

• Serverless所謂的“無服務(wù)器”并不是“沒有服務(wù)器”，而是說Serverless的用戶不再需要在服務(wù)器配置炸裆、維護(hù)垃它、更新、擴(kuò)展和容量規(guī)劃上花費(fèi)時(shí)間和資源烹看，可以將更多的精力放到業(yè)務(wù)邏輯本身国拇，至于服務(wù)器，則“把更專業(yè)的事情交給更專業(yè)的人”去做听系，即由云廠商來提供統(tǒng)一的運(yùn)維

圖12　不同角度上的Serverless的定義

image-20220125072929780

圖16　FaaS解決方案組成

image-20220125072950062

1. EventSources：將Event觸發(fā)或流式傳輸?shù)揭粋€(gè)或多個(gè)函數(shù)實(shí)例中
2. FunctionInstance：可以根據(jù)需要擴(kuò)展單個(gè)函數(shù)/微服務(wù)
3. FaaSController：部署贝奇、控制和監(jiān)視函數(shù)實(shí)例及其來源
4. 平臺服務(wù)：FaaS解決方案使用云廠商提供的其他云服務(wù)虹菲，例如云數(shù)據(jù)庫靠胜、身份校驗(yàn)等

圖1-7　函數(shù)部署流水線示意圖

image-20220125073025254

圖1-9　函數(shù)調(diào)用類型

image-20220125073047102

圖1-14　虛擬機(jī)、容器、Serverless架構(gòu)演進(jìn)簡圖

image-20220125073106228

圖1-15　傳統(tǒng)項(xiàng)目上線和Serverless下項(xiàng)目上線對比圖

image-20220125073123686

• Serverless的缺點(diǎn)也逐漸地暴露了出來浪漠，例如函數(shù)的冷啟動(dòng)問題陕习，就是如今頗為嚴(yán)峻且備受關(guān)注的問題

圖1-16　函數(shù)計(jì)算根據(jù)流量進(jìn)行函數(shù)擴(kuò)縮示意圖

image-20220125073144965

圖1-17　函數(shù)冷啟動(dòng)產(chǎn)生示意圖

image-20220125073201919

• 當(dāng)新的請求或者說是事件到來時(shí)，在廣義上可能出現(xiàn)以下兩種情況

1. 存在空閑且可以直接復(fù)用的實(shí)例：熱啟動(dòng)
2. 不存在空閑且可以直接復(fù)用的實(shí)例：冷啟動(dòng)

圖1-18　本地與FaaS的函數(shù)調(diào)用區(qū)別示意圖

image-20220125073227200

圖1-20　函數(shù)啟動(dòng)的四個(gè)部分

image-20220125073251863

• 通常情況下址愿，冷啟動(dòng)的解決方案包括幾個(gè)部分：實(shí)例復(fù)用该镣、實(shí)例預(yù)熱以及資源池化

圖1-21　函數(shù)冷啟動(dòng)常見解決方案

image-20220125073312301

圖1-22　函數(shù)預(yù)熱常見方案

image-20220125073334337

• 資源池化帶來的效果可能不是熱啟動(dòng)，可能是溫啟動(dòng)响谓。所謂的溫啟動(dòng)是指實(shí)例所需要的相關(guān)資源已經(jīng)提前準(zhǔn)備了损合，但是并沒有完全準(zhǔn)備好的情況。所謂的池化就是在實(shí)例從零到一的過程中所進(jìn)行的每一步準(zhǔn)備工作娘纷，如圖123所示

圖1-23　函數(shù)池化程度示意圖

image-20220125073352393

• 通常情況下嫁审，在冷啟動(dòng)的過程中，比較耗時(shí)的環(huán)節(jié)包括網(wǎng)絡(luò)資源的打通赖晶、實(shí)例的底層資源的準(zhǔn)備以及運(yùn)行時(shí)等準(zhǔn)備
• 除了冷啟動(dòng)之外律适，Serverless架構(gòu)還存在著廠商鎖定等比較嚴(yán)重的問題。廠商鎖定問題是很多人非常在意的

表1-1　不同云廠商/產(chǎn)品所提供的典型場景表

image-20220125073413351

圖1-25　數(shù)據(jù)ETL處理示例

image-20220125073431301

• AI模型完成訓(xùn)練后遏插，在對外提供推理服務(wù)時(shí)捂贿，可以使用Serverless架構(gòu)將數(shù)據(jù)模型包裝在調(diào)用函數(shù)中，在實(shí)際用戶請求到達(dá)時(shí)再運(yùn)行代碼胳嘲。相對于傳統(tǒng)的推理預(yù)測厂僧，這樣做的好處是，無論是函數(shù)模塊了牛、后端的GPU服務(wù)器吁系，還是對接的其他相關(guān)的機(jī)器學(xué)習(xí)服務(wù)，都可以按量付費(fèi)以及自動(dòng)伸縮白魂，從而在保證性能的同時(shí)確保服務(wù)的穩(wěn)定汽纤，如圖127所示

圖1-27　AI推理預(yù)測處理示例

image-20220125073449676

• 隨著容器、IoT福荸、5G蕴坪、區(qū)塊鏈等技術(shù)的快速發(fā)展，對去中心化敬锐、輕量虛擬化背传、細(xì)粒度計(jì)算等技術(shù)的需求也愈發(fā)強(qiáng)烈，Serverless必將借勢迅速發(fā)展

圖2-1　CNCF列出的FaaS平臺

image-20220125073510073

• AWSLambda的函數(shù)管理頁面有一個(gè)比較有特色的設(shè)計(jì)台夺，即Designer（函數(shù)概覽）径玖。Designer可以直觀地顯示用戶的函數(shù)及其上游和下游資源。用戶可以使用它跳轉(zhuǎn)到觸發(fā)器颤介、目標(biāo)和層配置
• GoogleCloudFunction采用運(yùn)行時(shí)機(jī)制梳星，支持Node.js赞赖、Java以及Python等語言。用戶可以通過直接上傳代碼冤灾、對象存儲前域、云代碼庫、CLI等方法對代碼進(jìn)行部署韵吨、發(fā)布以及更新匿垄。函數(shù)超時(shí)時(shí)間最長為540秒，具有自動(dòng)調(diào)節(jié)能力归粉。開發(fā)者工具包括CLI命令行工具以及WebIDE等

圖2-4　GoogleCloudPlatform的Functions產(chǎn)品頁面

image-20220125073533000

• Kubernetes（簡稱K8S）是Google開源的一個(gè)容器編排引擎椿疗，支持自動(dòng)化部署、大規(guī)目返浚可伸縮变丧、應(yīng)用容器化管理。在生產(chǎn)環(huán)境中部署應(yīng)用程序時(shí)绢掰，通常要部署該應(yīng)用的多個(gè)實(shí)例痒蓬，以便對應(yīng)用請求進(jìn)行負(fù)載均衡
• 阿里云函數(shù)計(jì)算處于“領(lǐng)導(dǎo)者梯隊(duì)”，在2020年下半年率先推出CustomContainerRuntime滴劲。眾所周知攻晒，在云原生時(shí)代，容器鏡像已經(jīng)逐漸變成軟件部署和開發(fā)的標(biāo)準(zhǔn)工具班挖，阿里云函數(shù)計(jì)算為了簡化開發(fā)者體驗(yàn)鲁捏、提升開發(fā)和交付效率，特別提供了CustomContainerRuntime萧芙。開發(fā)者將容器鏡像作為函數(shù)的交付物给梅，通過HTTP協(xié)議和函數(shù)計(jì)算系統(tǒng)交互
• 有了CustomContainerRuntime的加持，絕大部分的傳統(tǒng)Web應(yīng)用都可以以極低的改造成本體驗(yàn)到Serverless架構(gòu)帶來的優(yōu)勢双揪，甚至可以做到0改造上云动羽。為了協(xié)助更多用戶快速遷移傳統(tǒng)Web應(yīng)用，阿里云函數(shù)計(jì)算開發(fā)了應(yīng)用中心渔期，可以實(shí)現(xiàn)快速在線遷移运吓，如圖27所示
• SCF是實(shí)時(shí)文件處理和數(shù)據(jù)處理等場景下理想的計(jì)算平臺
• 在開源領(lǐng)域也有諸多優(yōu)秀的Serverless項(xiàng)目。包括OpenWhisk疯趟、Fission拘哨、Knative以及Kubeless等在內(nèi)的眾多優(yōu)秀的開源FaaS平臺都已得到CNCF認(rèn)可

圖213　開源FaaS平臺

image-20220125073624904

表2-1　常見開源FaaS平臺基本信息

image-20220125073606252

• 在諸多Serverless開源項(xiàng)目中，Knative的優(yōu)勢也是較為明顯的

1. Knative以Kubernetes為底層框架信峻，與Kubernetes生態(tài)結(jié)合得更緊密倦青。無論是云上Kubernetes服務(wù)還是自建Kubernetes集群，都能通過安裝Knative插件快速地搭建Serverless平臺
2. Knative聯(lián)合CNCF盹舞，把所有事件標(biāo)準(zhǔn)化為CloudEvent产镐，提供事件的跨平臺運(yùn)行隘庄，同時(shí)讓函數(shù)和具體的調(diào)用方法解耦。在彈性層面磷账，Knative可以監(jiān)控應(yīng)用的請求峭沦，并自動(dòng)擴(kuò)縮容贾虽，借助于Istio（Ambassador逃糟、Gloo等）支持藍(lán)綠發(fā)布、回滾的功能蓬豁，方便應(yīng)用發(fā)布绰咽。同時(shí)，Knative支持日志的收集地粪、查找和分析取募，并支持VAmetrics數(shù)據(jù)展示、調(diào)用關(guān)系跟蹤等

Knative工作原理如圖2-14所示

image-20220125073710226

第二部分 開發(fā)入門

• Serverless還有一些特性蟆技，所以要轉(zhuǎn)變開發(fā)觀念

文件上傳方法

1. 一般情況下玩敏，一些云平臺的API網(wǎng)關(guān)觸發(fā)器會將二進(jìn)制文件轉(zhuǎn)換成字符串，不便直接獲取和存儲质礼；
2. 一般情況下旺聚，API網(wǎng)關(guān)與FaaS平臺之間傳遞的數(shù)據(jù)包有大小限制，很多平臺限制數(shù)據(jù)包大小為6MB以內(nèi)眶蕉；
3. FaaS平臺大多是無狀態(tài)的砰粹，即使存儲到當(dāng)前實(shí)例中，也會隨著實(shí)例釋放而使文件丟失

圖4-1　在Serverless架構(gòu)下文件上傳文件示例

image-20220125073756996

文件讀寫與持久化方法

• 由于FaaS平臺是無狀態(tài)的造挽，并且用過之后會被銷毀碱璃，因此文件并不能直接持久化在實(shí)例中，但可以持久化到其他的服務(wù)中饭入，例如對象存儲嵌器、NAS等
• 所謂的簡單調(diào)試，就是在控制臺進(jìn)行調(diào)試谐丢。以阿里云函數(shù)計(jì)算為例嘴秸，其可以在控制臺通過“執(zhí)行”按鈕，進(jìn)行基本的調(diào)試庇谆，如圖44所示

圖4-4　函數(shù)在線簡單調(diào)試頁面

image-20220125073819331

• 必要的時(shí)候岳掐，我們也可以通過設(shè)置Event來模擬一些事件，如圖45所示

圖4-5　通過設(shè)置Event模擬事件

image-20220125073838427

圖4-6　函數(shù)在線斷點(diǎn)調(diào)試頁面（一）

image-20220125073855713

• 大部分FaaS平臺都會為用戶提供相對完備的命令行工具饭耳，包括AWS的SAMCLI串述、阿里云的Funcraft，同時(shí)也有一些開源項(xiàng)目例如ServerlessFramework寞肖、ServerlessDevs等對多云廠商的支持
• Knative是一款基于Kubernetes的Serverless框架纲酗。其目標(biāo)是制定云原生衰腌、跨平臺的Serverless編排標(biāo)準(zhǔn)。Knative通過整合容器構(gòu)建（或者函數(shù)）觅赊、工作負(fù)載管理（動(dòng)態(tài)擴(kuò)縮）以及事件模型這三者實(shí)現(xiàn)其Serverless標(biāo)準(zhǔn)

圖5-1　在Knative體系架構(gòu)下各角色的協(xié)作關(guān)系

image-20220125073911844

• 作為一個(gè)通用的Serverless框架右蕊，Knative由3個(gè)核心組件組成

1. Tekton：提供從源碼到鏡像的通用構(gòu)建能力。Tekton組件主要負(fù)責(zé)從代碼倉庫獲取源碼并編譯成鏡像吮螺，推送到鏡像倉庫饶囚。所有這些操作都是在KubernetesPod中進(jìn)行的
2. Eventing：提供事件的接入、觸發(fā)等一整套事件管理能力鸠补。Eventing組件針對Serverless事件驅(qū)動(dòng)模式做了一套完整的設(shè)計(jì)萝风，包括外部事件源的接入、事件注冊紫岩、訂閱以及事件過濾等功能规惰。事件模型可以有效地解耦生產(chǎn)者和消費(fèi)者的依賴關(guān)系。生產(chǎn)者可以在消費(fèi)者啟動(dòng)之前生成事件泉蝌，消費(fèi)者也可以在生產(chǎn)者啟動(dòng)之前監(jiān)聽事件
3. Serving：管理Serverless工作負(fù)載歇万，可以和事件很好地結(jié)合，并且提供了基于請求驅(qū)動(dòng)的自動(dòng)伸縮能力勋陪，而且在沒有服務(wù)需要處理的時(shí)候可以縮容到零贪磺。Serving組件的職責(zé)是管理工作負(fù)載以對外提供服務(wù)。Serving組件最重要的特性就是自動(dòng)伸縮的能力粥鞋。目前缘挽，其伸縮邊界無限制。Serving還具有灰度發(fā)布能力

第三部分 工程實(shí)踐

• 雖然基于Serverless架構(gòu)的音視頻處理會具備更高的效能呻粹，但是在進(jìn)行大視頻處理的時(shí)候壕曼，往往比較慢，此時(shí)還需要進(jìn)一步優(yōu)化業(yè)務(wù)代碼等浊。以視頻轉(zhuǎn)碼為例腮郊，當(dāng)有一個(gè)比較大的視頻需要轉(zhuǎn)碼時(shí)，為了提升整體的效能筹燕，可先對視頻進(jìn)行切片轧飞，然后分別轉(zhuǎn)碼之后再進(jìn)行合并，如圖712所示

圖7-12　并行視頻轉(zhuǎn)碼案例流程簡圖

image-20220125073940563

圖8-4　基于Serverless架構(gòu)的圖像識別功能流程簡圖

image-20220125073957082

圖9-1　前端技術(shù)發(fā)展簡史

image-20220125074012028

• 以SSR技術(shù)為例撒踪，在Serverless架構(gòu)下过咬，前端團(tuán)隊(duì)不需要關(guān)注SSR服務(wù)器的部署、運(yùn)維和擴(kuò)容制妄，可以極大地減少部署運(yùn)維成本掸绞，從而更好地聚焦于業(yè)務(wù)開發(fā)，提高開發(fā)效率耕捞。此外衔掸，前端團(tuán)隊(duì)也不必?fù)?dān)心SSR服務(wù)器的性能問題烫幕，從生產(chǎn)力的釋放到性能的提升，更為明顯地降本提效