摘要通過(guò)本文可以了解什么是Serverless及Serverless演進(jìn)史，Serverless的常見(jiàn)應(yīng)用場(chǎng)景及價(jià)值。

1. Serverless函數(shù)計(jì)算及應(yīng)用場(chǎng)景

1.1Serverless的概念，特征以及價(jià)值

1.1.1Serverless是什么？

CNCF定義

一種新的云原生計(jì)算模型，無(wú)需服務(wù)器管理而構(gòu)建和運(yùn)行應(yīng)用程序的架構(gòu)。一個(gè)或多個(gè)功能的應(yīng)用上傳到平臺(tái)后執(zhí)行、擴(kuò)展和計(jì)費(fèi)

CNCF定義Serverless的LandScape在多個(gè)層面協(xié)同發(fā)展

信通院定義

以應(yīng)用為中心，無(wú)需關(guān)注基礎(chǔ)設(shè)施的計(jì)算模式，FaaS不是其唯一形態(tài)。Serverless是一整套能力的合集，越來(lái)越多的第3三方

服務(wù)演進(jìn)為全托管的Serverless形態(tài)

Serverless是云上一整套能力的合集，而不是單一的云服務(wù)產(chǎn)品

1.1.2Serverless成國(guó)際研究熱潮，

預(yù)言將成為下一-代默認(rèn)的計(jì)算范式

Serverless函數(shù)計(jì)算的價(jià)值

1.2Serverless函數(shù)計(jì)算的典型應(yīng)用場(chǎng)景

1.2.1Serverless函數(shù)計(jì)算適用場(chǎng)景

Serverless函數(shù)計(jì)算適用場(chǎng)景主要有以下三類，Web類應(yīng)用IoT，媒體處理類應(yīng)用，AI處理應(yīng)用

Web類應(yīng)用

解放端側(cè)開(kāi)發(fā)，讓端開(kāi)發(fā)者更快、更靈活開(kāi)發(fā)各種應(yīng)用，無(wú)需關(guān)注后端服務(wù)

• 小程序后端

• Web后端

• 問(wèn)答機(jī)器人

• 前端BFF

IoT，媒體處理類應(yīng)用

以事件驅(qū)動(dòng)的方式執(zhí)行服務(wù)，按需供給,開(kāi)發(fā)者無(wú)需關(guān)注業(yè)務(wù)波峰波谷，節(jié)省閑時(shí)成本，最終降低運(yùn)維的成本

• 實(shí)時(shí)圖片處理

• 實(shí)時(shí)數(shù)據(jù)流處理

• loT事件處理

• 運(yùn)維告警處理

AI處理應(yīng)用

各行各業(yè)智能化深入帶來(lái)更多的應(yīng)用開(kāi)發(fā)場(chǎng)景，通常需要集成各類服務(wù)快速上線

• 視頻直播

• Al推理

• 人臉識(shí)別

• 車牌識(shí)別

1.2.2六個(gè)典型的應(yīng)用場(chǎng)景

典型場(chǎng)景一: Web/App/小程序后端

場(chǎng)景需求特點(diǎn):

• 業(yè)務(wù)變化快，
• 上線周期短

函數(shù)計(jì)算優(yōu)勢(shì):

• 無(wú)需管理服務(wù)器，
• 開(kāi)發(fā)上線快

典型場(chǎng)景二:BFF/SSR

場(chǎng)景需求特點(diǎn):

BFF/SSR和業(yè)務(wù)強(qiáng)相關(guān)，通常由前端開(kāi)發(fā)，但前端并不擅長(zhǎng)服務(wù)器的部署、運(yùn)維

函數(shù)計(jì)算優(yōu)勢(shì):

• 無(wú)需管理服務(wù)器
• 前端可使用熟悉的技術(shù)棧開(kāi)發(fā)

典型場(chǎng)景三:事件觸發(fā)

場(chǎng)景需求特點(diǎn):
1、業(yè)務(wù)事件頻次不高或波峰波谷明顯

函數(shù)計(jì)算優(yōu)勢(shì):

• 按需付費(fèi)
• 毫秒級(jí)自動(dòng)彈性

典型場(chǎng)景四:服務(wù)間快速集成

場(chǎng)景需求特點(diǎn):

• 1、業(yè)務(wù)需要串聯(lián)多個(gè)服務(wù)，被集成服務(wù)提供了API或SDK
• 2、業(yè)務(wù)創(chuàng)新需要方案能快速打通試錯(cuò)，并具有一定的擴(kuò)展性

函數(shù)計(jì)算優(yōu)勢(shì):

• 多語(yǔ)言開(kāi)發(fā)，事件驅(qū)動(dòng)特性方便對(duì)接各類服務(wù)
• 按需自動(dòng)彈性即保證了擴(kuò)展性又兼顧了成本

典型場(chǎng)景五：視頻轉(zhuǎn)碼函數(shù)工作流

場(chǎng)景需求特點(diǎn):

• 多步驟彈性并發(fā)處理，步驟耗時(shí)長(zhǎng)
• 需要容錯(cuò)

函數(shù)工作流優(yōu)勢(shì):

• 自動(dòng)彈性滿足大并發(fā)

• 狀態(tài)維護(hù)，失敗重試保證可靠

典型場(chǎng)景六: 安全運(yùn)維函數(shù)工作流

場(chǎng)景需求特點(diǎn):

• 靈活編排
• 自動(dòng)化和人工處理相結(jié)合

函數(shù)工作流優(yōu)勢(shì):

• 編排更靈活，支持深度自定義邏輯
• 通知+回調(diào)的方式支持人工介入流程

2.FunctionGraph產(chǎn)品能力與應(yīng)用案例

2.1Serverless趨勢(shì)及服務(wù)全景

2.1.1Serverless趨勢(shì)及華為云Serverless服務(wù)

Serverless是下一-代默認(rèn)的計(jì)算范式，將在未來(lái)5- 10年內(nèi)成為云的首要交付模式
Serverless的價(jià)值:能夠?yàn)閼?yīng)用屏蔽基礎(chǔ)設(shè)施，提供自動(dòng)化運(yùn)行環(huán)境、隨時(shí)按實(shí)際用量計(jì)費(fèi)、免運(yùn)維的能力

2.1.2FunctionGraph2.0使用場(chǎng)景與客戶選擇

2.2典型客戶場(chǎng)景

2.2.1華為視頻:前端基于函數(shù)開(kāi)發(fā)中間層，實(shí)現(xiàn)前后端解耦，開(kāi)發(fā)上線效率提升1 00%+

1.場(chǎng)景&問(wèn)題

場(chǎng)景:視頻App前端展示的內(nèi)容隨業(yè)務(wù)需要經(jīng)常變化，包括排版更新，新功能上線
問(wèn)題:前端變化的內(nèi)容往往只涉及后端數(shù)據(jù)的重新組合或者格式轉(zhuǎn)換，但卻需要前后端一起配合修改，溝通成本高，版本上線慢

2.解決方案
前端使用自己熟悉的Node.js語(yǔ)言開(kāi)發(fā)函數(shù)，作為中間層調(diào)用后端微服務(wù)，對(duì)數(shù)據(jù)裁剪、聚合以適配前端業(yè)務(wù)需要。

3.價(jià)值&收益

前后端徹底解耦，前端聚焦業(yè)務(wù)，后端僅需提供通用接口，不再關(guān)心數(shù)據(jù)如何展示，減少了

溝通成本

前端只需開(kāi)發(fā)中間層業(yè)務(wù)函數(shù)，業(yè)務(wù)服務(wù)器的部署、運(yùn)維和擴(kuò)容，都由函數(shù)計(jì)算平臺(tái)托管，開(kāi)發(fā)上線效率提升100%以上

2.2.2阿聯(lián)酋xx: Serverless化構(gòu)建 車隊(duì)管理系統(tǒng)，上線周期縮短一 半，總成本降低30%

2.2.3XX車企:函數(shù)結(jié)合AI等服務(wù)，毫秒級(jí)彈性伸縮和NoOps支持實(shí)時(shí)小碰撞檢測(cè)

2.3FunctionGraph主要能力

2.3.1FunctionGraph 2.0:基于華為元戎的新一代函數(shù)計(jì)算與編排服務(wù)，8大特性發(fā)布

2.3.2特性1:豐富的函數(shù)開(kāi)發(fā)語(yǔ)言及觸發(fā)方式讓設(shè)計(jì)更靈活

2.3.3特性2:可視化拖拽式函數(shù)流支持編排復(fù)雜業(yè)務(wù)場(chǎng)景

2.3.4特性3:統(tǒng)一-插件支持云上和云下的開(kāi)發(fā)與調(diào)試

2.3.5特性4: Http函數(shù)讓W(xué)EB服務(wù)近乎0成本改造，享受Serverless優(yōu)勢(shì)能力

2.3.6特性5:函數(shù)支持容器鏡像，簡(jiǎn)化應(yīng)用Serverless化

2.3.7特性6:函數(shù)支持在運(yùn)行時(shí)動(dòng)態(tài)指定資源，靈活調(diào)度節(jié)省成本

2.3.8特性7:百毫秒冷啟動(dòng)時(shí)延,單實(shí)例多并發(fā)，毫秒級(jí)彈性

2.3.9特性8: 1ms粒度按量計(jì)費(fèi),節(jié)省開(kāi)支

3.FunctionGraph技術(shù)原理與實(shí)踐

3.1.函數(shù)計(jì)算關(guān)鍵技術(shù)原理

3.1.1Serverless架構(gòu)優(yōu)勢(shì)

3.1.2Serverless函數(shù)帶來(lái)的挑戰(zhàn):冷啟動(dòng)

• 函數(shù)被伯克利稱為“異步調(diào)用的微服務(wù)”;
• 從Long Running變?yōu)镋vent Driven,函數(shù)的啟動(dòng)時(shí)延成為關(guān)鍵指標(biāo)，直接影響哪些應(yīng)用能夠函數(shù)化;

3.1.3冷啟動(dòng)時(shí)延優(yōu)化

平臺(tái)側(cè)優(yōu)化

1.池化
大小自適應(yīng)的空實(shí)例池，按當(dāng)前池消耗速率和容器產(chǎn)生速度動(dòng)態(tài)調(diào)整容器池大小，優(yōu)化啟動(dòng)速度同時(shí)降低增加空函數(shù)實(shí)例的成本
2.網(wǎng)絡(luò)優(yōu)化
簡(jiǎn)化網(wǎng)絡(luò)配置，提升啟動(dòng)速度
3.函數(shù)代碼預(yù)加載
基于LRU ( Least Recently Used )的多級(jí)代碼包緩存，預(yù)創(chuàng)建不含代碼包的空實(shí)例，優(yōu)化容器首次啟動(dòng)與調(diào)度時(shí)延
4.解壓縮優(yōu)化
高性能的壓縮算法提升解壓速度和壓縮比

用戶側(cè)優(yōu)化

預(yù)留實(shí)例:

預(yù)留實(shí)例是將函數(shù)實(shí)例的創(chuàng)建和釋放交由用戶管理,當(dāng)您為某一函數(shù)創(chuàng)建了預(yù)留實(shí)例，函數(shù)_ I作流收到此函數(shù)的調(diào)用請(qǐng)求時(shí)，會(huì)

優(yōu)先將請(qǐng)求轉(zhuǎn)發(fā)給您的預(yù)留實(shí)例，當(dāng)請(qǐng)求的峰值超過(guò)預(yù)留實(shí)例處理能力時(shí)，剩余部分的請(qǐng)求將會(huì)轉(zhuǎn)發(fā)給按量實(shí)例，由函數(shù)工作流自動(dòng)為您

分配執(zhí)行環(huán)境。預(yù)留實(shí)例在創(chuàng)建完成后，會(huì)自動(dòng)加載該函數(shù)的代碼、依賴包以及執(zhí)行初始化入口函數(shù)，且預(yù)留實(shí)例會(huì)常駐環(huán)境，消除冷啟

動(dòng)對(duì)業(yè)務(wù)的影響。

1.減少代碼包大小

代碼包過(guò)大會(huì)增加傳輸、解壓、加載時(shí)間，通過(guò)去冗余文件等減少代碼包大小對(duì)冷啟動(dòng)時(shí)延優(yōu)化效果較明顯

2.選擇合適語(yǔ)言

nodjs、python、 golang- -般優(yōu)于java, 針對(duì)java也可以嘗試編譯成本地代碼方式

3.降低代碼初始化時(shí)間

升級(jí)依賴包，合并依賴文件等

4.選擇合適的內(nèi)存

函數(shù)內(nèi)存越大，計(jì)算能力越強(qiáng)，冷啟動(dòng)表現(xiàn)越優(yōu)

5.預(yù)留實(shí)例

1.根據(jù)業(yè)務(wù) 波峰波谷配置固定預(yù)留實(shí)例，超出部分通過(guò)彈性實(shí)例解決

2.定制自己業(yè)務(wù) 需要的預(yù)留實(shí)例策略

3.1.4Serverless運(yùn)行模型帶來(lái)的注意事項(xiàng)

• Serverless運(yùn)行模型與傳統(tǒng)模型最大區(qū)分在于動(dòng)態(tài)伸縮，最小可以縮小到0
• 如果有預(yù)留實(shí)例，請(qǐng)求優(yōu)先發(fā)到預(yù)留實(shí)例，預(yù)留實(shí)例是LongRunning
• 函數(shù)平臺(tái)為了盡量避免冷啟動(dòng)，一般在一次請(qǐng)求執(zhí)行完并不會(huì)立刻銷毀，一般會(huì)保留N分鐘左右，在后續(xù)請(qǐng)求會(huì)進(jìn)行實(shí)例復(fù)用。如果N分鐘無(wú)請(qǐng)求則會(huì)銷毀函數(shù)實(shí)例，內(nèi)存變量和臨時(shí)文件也同時(shí)銷毀
• 因?yàn)閷?shí)例復(fù)用，在同一個(gè)函數(shù)的多次請(qǐng)求之間可能會(huì)復(fù)用內(nèi)存變量和臨時(shí)文件，如果需要在上一-次請(qǐng)求和本次請(qǐng)求調(diào)用之間做隔離則需要在代碼里做刪除文件操作和變量清除
• 如果需要長(zhǎng)期保持和共享文件，可以通過(guò)掛載文件系統(tǒng)( sfs、sfs turbo、ecs等)，文件系統(tǒng)上的數(shù)據(jù)不會(huì)刪除

3.1.5函數(shù)調(diào)用機(jī)制

同步調(diào)用

客戶端請(qǐng)求需要明確等到響應(yīng)結(jié)果，也就是說(shuō)這樣的請(qǐng)求必須等調(diào)用到用戶的函數(shù)調(diào)用完成才返回

異步調(diào)用

異步調(diào)用是指客戶端不關(guān)注請(qǐng)求調(diào)用的結(jié)果，服務(wù)端收到請(qǐng)求后將請(qǐng)求排隊(duì)，排隊(duì)成功后請(qǐng)求就返回，服務(wù)端在空閑的情況下會(huì)逐個(gè)處理排隊(duì)的請(qǐng)求。

如何選擇

• 看是否需要等待返回的結(jié)果
• 看函數(shù)執(zhí)行時(shí)長(zhǎng)，如果超過(guò)90秒，建議異步
• 異步支持執(zhí)行完通知特性， 可配置通知機(jī)制

3.1.6單實(shí)例多并發(fā):支持更多調(diào)用

3.2.函數(shù)計(jì)算實(shí)踐分享

3.2.1架構(gòu)模式的變化:從微服務(wù)化逐步向Serverless化演進(jìn)，并將長(zhǎng)期共存

3.2.2客戶Serverless化推薦路徑:新業(yè)務(wù)試點(diǎn)，漸進(jìn)式改造

3.2.3如何提高調(diào)用可靠性

平臺(tái)側(cè)

多AZ、多集群、反親和、內(nèi)部重試、鏈路優(yōu)化等

用戶側(cè)

• 1.同步調(diào)用從客戶端重試、
• 2.異步調(diào)用配置重試策略， 如果想獲知結(jié)果可以配置成功時(shí)或失敗時(shí)的通知目的端

3.2.4如何從架構(gòu)層面提升可靠性

• 1.應(yīng)用程序部署采用跨AZ
• 2.針對(duì)高并發(fā)高可靠場(chǎng)景， 函數(shù)入口之前采用消息隊(duì)列如Kafka, kafka觸發(fā)函數(shù)執(zhí)行
• 3.函數(shù)交互過(guò)程按需使用消息隊(duì)列

3.2.5如何定位性能問(wèn)題

如何定位性能問(wèn)題，除了可以通過(guò)監(jiān)控、日志，我們對(duì)接了APM2.0， 可以做到免侵入式調(diào)用鏈能力，支持自動(dòng)采集jvm,sql， exception, redis, httpclient, kafka,tomcat等框架， 支持多函數(shù)調(diào)用攔截

3.2.6如何灰度發(fā)布

用戶可以創(chuàng)建別名，指向特定函數(shù)版本。別名的優(yōu)勢(shì)在于:如果需要回滾到之前的函數(shù)版本，則可以將相應(yīng)別名指向該版本，不再需要修

改代碼信息。

函數(shù)別名支持綁定兩個(gè)版本，-個(gè)對(duì)應(yīng)版本和開(kāi)啟灰度版本，并且支持配置同一個(gè)別名下兩個(gè)不同版本分流權(quán)重。

3.2.7如何零改動(dòng)遷移現(xiàn)有Web應(yīng)用到函數(shù)

場(chǎng)景問(wèn)題

微服務(wù)和函數(shù)在未來(lái)幾年會(huì)是一個(gè)共存的形態(tài)，當(dāng)前存在著大量微服務(wù)應(yīng)用，如何高效的支撐其Serverless化，讓現(xiàn)有微服務(wù)快速享用到
Serverless的優(yōu)勢(shì)能力，是一個(gè)待解決的問(wèn)題。

方案

針對(duì)Web服務(wù)，推出API網(wǎng)關(guān)加FunctionGraph的Http函數(shù)方案，用戶只需把原有的Web Server代碼打包為一個(gè)Http函數(shù)，即可完成Serverless化改造。

價(jià)值體現(xiàn)

• 多語(yǔ)言WEB框架支持，例如: Java - Spring Boot, Nodejs - Express等框架開(kāi)發(fā)的應(yīng)用極小修改就是能完成Serverless函數(shù)化改造。
• 開(kāi)發(fā)人員可以繼續(xù)使用熟悉的開(kāi)發(fā)框架和測(cè)試工具， AP|網(wǎng)關(guān)服務(wù)隨函數(shù)自動(dòng)化創(chuàng)建，降低開(kāi)發(fā)人員學(xué)習(xí)負(fù)擔(dān)。
• 改造后無(wú)需運(yùn)維資源，簡(jiǎn)單配置即可實(shí)現(xiàn)100ms級(jí)自動(dòng)彈性和灰度升級(jí)。

3.2.8HTTP函數(shù)原理

事件函數(shù)

事件函數(shù)的請(qǐng)求經(jīng)過(guò)API網(wǎng)關(guān)或者其他觸發(fā)器時(shí)，會(huì)對(duì)請(qǐng)求的消息進(jìn)行編碼成固定的事件格式，FunctionGraph 直接調(diào)用用戶函數(shù)里的方法并將事件消息作為參數(shù)傳入。

HTTP函數(shù)

用戶發(fā)送的HTTP請(qǐng)求經(jīng)過(guò)API網(wǎng)關(guān)后，網(wǎng)關(guān)會(huì)將原生HTTP請(qǐng)求直接透?jìng)鞯牡紽unctionGraph, FunctionGraph講請(qǐng)求直接轉(zhuǎn)發(fā)到用戶函數(shù)代碼里起的webserver里。

3.2.9數(shù)據(jù)庫(kù)連接池實(shí)戰(zhàn)

方案一(單實(shí)例多并發(fā)+預(yù)留實(shí)例)

• 預(yù)留實(shí)例確保了連接池是常駐

• 單實(shí)例多并發(fā)確保函數(shù)實(shí)例可以處理更多請(qǐng)求

• 另外需要注意配置函數(shù)總并發(fā)實(shí)例數(shù)

• 數(shù)據(jù)庫(kù)最大連接數(shù)盡 量配置大些

方案二(數(shù)據(jù)庫(kù)代理方式)

• 通過(guò)數(shù)據(jù)庫(kù)代理來(lái)訪問(wèn)數(shù)據(jù)庫(kù)， 代理到數(shù)據(jù)庫(kù)之間為長(zhǎng)連接
• 數(shù)據(jù)庫(kù)代理可以通過(guò)讀寫分離支持更多請(qǐng)求

3.2.10函數(shù)調(diào)用如何降低成本

網(wǎng)絡(luò)訪問(wèn)相關(guān)實(shí)踐

3.3.高階特性:有狀態(tài)

3.3.1函數(shù)和有狀態(tài)的關(guān)系

3.3.2有狀態(tài)函數(shù)運(yùn)行邏輯

3.3.3有狀態(tài)應(yīng)用模式

總結(jié)

通過(guò)上面的一些解釋，我們了解什么是Serverless及Serverless演進(jìn)史，Serverless的常見(jiàn)應(yīng)用場(chǎng)景及價(jià)值。Serverless的六個(gè)典型的應(yīng)用場(chǎng)景，以及FunctionGraph的八大特性，以及對(duì)函數(shù)計(jì)算實(shí)踐分享的一些分享。

總結(jié)

以上是生活随笔為你收集整理的从0到1入门Serverless的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。