2012年，Iron.io公司提出了一個(gè)名叫“Serverless”的概念，認(rèn)為未來的軟件和應(yīng)用都應(yīng)該是無服務(wù)器的；2019年，伯克利發(fā)表論文《A Berkeley View on Serverless Computing，2019 FEB》，對(duì)于云計(jì)算未來十年作出預(yù)測(cè)，認(rèn)為 Serverless 是云時(shí)代的主宰。
而到了今天，人們?cè)谟懻摰囊巡粌H僅是 Serverless ，而是“Serverless First” —— 也就是說，討論話題從“要不要用”，變成了“怎么用”。它到底是云廠商的宣傳噱頭，前端開發(fā)者的專屬方案，還是真的會(huì)改變整個(gè)研發(fā)現(xiàn)狀呢？
要切實(shí)回答這個(gè)問題，我們來深度了解一下 Serverless 面臨的誤解、挑戰(zhàn)與機(jī)遇。同時(shí)，我們也聯(lián)系獲取了華為應(yīng)用市場(chǎng)AppGallery Connect（簡(jiǎn)稱AGC）在Serverless領(lǐng)域的一手實(shí)踐資料，希望能帶給你啟發(fā)。
Serverless 和微服務(wù)，并非替換關(guān)系
Serverless = FaaS（函數(shù)即服務(wù)） + BaaS（后端即服務(wù)），這是目前接受度最高的 Serverless 定義。Serverless 和微服務(wù)的關(guān)系，卻很少有人能說得明白，甚至很多人都覺得：Serverless 和微服務(wù)是替換關(guān)系，只能選一個(gè)。
然而 Serverless 和微服務(wù)在不同場(chǎng)景下，其實(shí)各有優(yōu)點(diǎn)。以華為 AppGallery Connect Serverless 為例，Serverless 的特點(diǎn)是：
1. 成本低，開發(fā)者僅對(duì)實(shí)際使用的資源付費(fèi)，無需為空閑資源付費(fèi)，顯著降低運(yùn)維與使用成本；
2. 免運(yùn)維，開發(fā)者無需關(guān)注后端服務(wù)的運(yùn)維，自動(dòng)彈性伸縮等傳統(tǒng)云服務(wù)時(shí)代的復(fù)雜運(yùn)維動(dòng)作都由Serverless服務(wù)自動(dòng)完成；
3. 上線快，在Serverless架構(gòu)中，函數(shù)粒度的開發(fā)/部署單元，以及事件觸發(fā)的運(yùn)行機(jī)制，可以大幅簡(jiǎn)化代碼邏輯，提升業(yè)務(wù)的上線速度；
4. 跨平臺(tái)，AGC平臺(tái)還提供了服務(wù)的跨平臺(tái)支撐，幫助開發(fā)者實(shí)現(xiàn)不同平臺(tái)上的用戶互通，進(jìn)一步提升開發(fā)效率。
因此，在實(shí)時(shí)計(jì)算、并行任務(wù)處理、邊緣計(jì)算等計(jì)算密集型場(chǎng)景下，Serverless 往往更合適。而微服務(wù)的特點(diǎn)是服務(wù)簡(jiǎn)單、靈活擴(kuò)展、便于維護(hù)、獨(dú)立演進(jìn)、混合開發(fā)、持續(xù)交付，更適合大型復(fù)雜業(yè)務(wù)系統(tǒng)。
不過，微服務(wù)架構(gòu)對(duì)研發(fā)團(tuán)隊(duì)的技術(shù)能力是個(gè)考驗(yàn)，單是顆粒度劃分，就已經(jīng)成為了各個(gè)技術(shù)大會(huì)的熱門話題。如果將目光轉(zhuǎn)向整個(gè)架構(gòu)層面，在框架選型、服務(wù)治理、彈性伸縮等層面的挑戰(zhàn)會(huì)更大，需要團(tuán)隊(duì)有非常豐富的服務(wù)化經(jīng)驗(yàn)。
實(shí)際上，當(dāng)下最新穎的服務(wù)模式是 Serverless 微服務(wù)。相比于傳統(tǒng)微服務(wù)架構(gòu)，Serverless 微服務(wù)有兩個(gè)特點(diǎn)：
1. 應(yīng)用全托管能力：Serverless 微服務(wù)提供從微服務(wù)代碼打包、部署、監(jiān)控、調(diào)用鏈、服務(wù)治理、彈性伸縮、版本升級(jí)回滾的全生命周期管理能力。
2. 按業(yè)務(wù)運(yùn)行時(shí)間收費(fèi)的計(jì)費(fèi)模式：按照業(yè)務(wù)微服務(wù)使用的 CPU 資源使用量以及內(nèi)存資源使用量進(jìn)行計(jì)費(fèi)，當(dāng)沒有訪問請(qǐng)求的空閑期，微服務(wù)運(yùn)行實(shí)例自動(dòng)縮容到 1 或者 0 ，節(jié)約資源使用量，節(jié)省資源成本，做到資源最優(yōu)化。
總體上，我們可以認(rèn)為 Serverless 微服務(wù) = CI/CD流水線 + 微服務(wù)框架（含注冊(cè)中心和微服務(wù)治理框架）+ Kubernetes/容器 + 云運(yùn)維（含調(diào)用鏈、日志、告警、性能監(jiān)控等） + 彈性伸縮服務(wù) + 流量治理服務(wù)。
Serverless 落地關(guān)鍵：不能一刀切
如果Serverless 微服務(wù)這么好，各個(gè)團(tuán)隊(duì)內(nèi)部，是不是應(yīng)該立刻推動(dòng)落地Serverless 微服務(wù)？通過對(duì)華為應(yīng)用市場(chǎng) AppGallery ConnectServerless的案例分析，我們得出的結(jié)論是，要重視并認(rèn)真規(guī)劃，但不能一刀切。
首先我們簡(jiǎn)單介紹下案例背景。華為應(yīng)用市場(chǎng) AppGallery Connect平臺(tái)致力于為應(yīng)用的創(chuàng)意、開發(fā)、分發(fā)、運(yùn)營、分析各環(huán)節(jié)提供全生命周期服務(wù)，提升應(yīng)用的開發(fā)和運(yùn)營效率，加快應(yīng)用的創(chuàng)新與商業(yè)成功。AppGallery Connect深度整合華為內(nèi)部各項(xiàng)優(yōu)質(zhì)服務(wù)，將華為在技術(shù)研發(fā)、全球化運(yùn)營、質(zhì)量、安全、工程管理等領(lǐng)域長期積累的能力開放給開發(fā)者，大幅降低應(yīng)用開發(fā)與運(yùn)維難度，提高應(yīng)用質(zhì)量，開放分發(fā)和運(yùn)營服務(wù)。架構(gòu)如下所示：
它以Serverless為底座，通過跨端SDK（AppGallery Connect Kit）、AppGallery Connect Portal和 RESTful API向移動(dòng)開發(fā)者提供應(yīng)用創(chuàng)意、開發(fā)、分發(fā)、運(yùn)營和分析相關(guān)的全生命周期服務(wù)。
AppGallery Connect Serverless解決方案更聚焦于解決移動(dòng)應(yīng)用研發(fā)的效率問題，具體有如下幾個(gè)技術(shù)特點(diǎn)：
1. 數(shù)據(jù)安全：云數(shù)據(jù)庫采用了獨(dú)創(chuàng)的端云全密態(tài)加密技術(shù)，實(shí)現(xiàn)端側(cè)和云側(cè)數(shù)據(jù)協(xié)同加密，將基于用戶口令加密的密鑰云端備份，全面保障用戶數(shù)據(jù)安全。
2. 高性能：針對(duì)函數(shù)的冷啟動(dòng)在代碼的傳輸、加載等方面做了大幅優(yōu)化，利用資源池化、代碼緩存、調(diào)用鏈預(yù)測(cè)等技術(shù)，在不改動(dòng)操作系統(tǒng)的情況下使得函數(shù)的冷啟動(dòng)時(shí)延最低可達(dá)10~20ms；云數(shù)據(jù)庫通過網(wǎng)絡(luò)優(yōu)化、協(xié)議優(yōu)化等，實(shí)現(xiàn)了端云數(shù)據(jù)同步 < 120毫秒（業(yè)界通常200毫秒+）。
3. 數(shù)據(jù)庫的彈性伸縮：構(gòu)建Serverless化的云數(shù)據(jù)庫CloudDB，解決端云數(shù)據(jù)同步、多端數(shù)據(jù)同步，以及海量數(shù)據(jù)的存儲(chǔ)問題。與傳統(tǒng)的數(shù)據(jù)庫服務(wù)相比，面向端側(cè)的數(shù)據(jù)庫服務(wù)提供了客戶端與云端、客戶端與客戶端之間的實(shí)時(shí)數(shù)據(jù)同步機(jī)制，移動(dòng)端離線可用等面向移動(dòng)端的特性。底層的數(shù)據(jù)庫引擎采用存算分離的分布式架構(gòu)，可以按照移動(dòng)端的需求自動(dòng)擴(kuò)展存儲(chǔ)容量或者計(jì)算節(jié)點(diǎn)，向開發(fā)者屏蔽分庫分表和數(shù)據(jù)庫擴(kuò)容遷移等問題。
4. 節(jié)省人力成本：AGC云托管免去開發(fā)者應(yīng)用網(wǎng)站的CDN、域名管理、SSL證書管理等工作，且內(nèi)置全球CDN加速和全球域名管理服務(wù)，節(jié)約開發(fā)者的運(yùn)維人力與成本。
目前AppGallery Connect Serverless解決方案在華為內(nèi)部已經(jīng)用于AppGallery Connect APP、華為快應(yīng)用、翻譯服務(wù)、應(yīng)用市場(chǎng)聯(lián)運(yùn)活動(dòng)秒殺系統(tǒng)等多個(gè)項(xiàng)目中，相比于之前的微服務(wù)架構(gòu)，研發(fā)效率得到極大提升。
以華為應(yīng)用市場(chǎng) AppGallery Connect Serverless 對(duì)翻譯服務(wù)的支持為例，據(jù) InfoQ 了解，開發(fā)團(tuán)隊(duì)通過使用Serverless云函數(shù)+云存儲(chǔ)+云數(shù)據(jù)庫服務(wù)，高效構(gòu)建具備高可用和按需擴(kuò)縮容的翻譯服務(wù)，與傳統(tǒng)架構(gòu)模式相比，人力降低45%，研發(fā)周期縮短50%。
在分工方面，Serverless 方案也與傳統(tǒng)的組織方式有所不同。架構(gòu)師主要負(fù)責(zé)整體架構(gòu)設(shè)計(jì)、領(lǐng)域模型設(shè)計(jì)、數(shù)據(jù)模型設(shè)計(jì)、函數(shù)劃分。而研發(fā)工程師的角色會(huì)細(xì)分成兩類，一類是功能開發(fā)，一類是業(yè)務(wù)上線。
負(fù)責(zé)功能開發(fā)的工程師職責(zé)是函數(shù)開發(fā)、單元測(cè)試、聯(lián)調(diào)測(cè)試；負(fù)責(zé)業(yè)務(wù)上線的工程師，職責(zé)頗有 Serverless 特色，要自助開通云函數(shù)、云存儲(chǔ)、云數(shù)據(jù)庫等服務(wù)，此外需要負(fù)責(zé)函數(shù)的上傳、發(fā)布，以及設(shè)置觸發(fā)器。
觸發(fā)器是基于云函數(shù)的事件驅(qū)動(dòng)編程的核心。這個(gè)項(xiàng)目涉及HTTP、CloudDB（云數(shù)據(jù)庫）、CloudStorage（云存儲(chǔ)）等多個(gè)觸發(fā)器，需要以往適應(yīng)串行 API 調(diào)用編程的工程師做思維和習(xí)慣上的轉(zhuǎn)變，快速上手基于事件觸發(fā)的異步編程。有一張對(duì)比圖很形象地說明了兩種編程思維模型的差異：
不可否認(rèn)的是，由于大家對(duì)微服務(wù)架構(gòu)熟悉度高，對(duì) Serverless 架構(gòu)熟悉度相對(duì)較低，推廣 Serverless 落地也可能會(huì)面臨一些組織層面的阻力。對(duì)于主導(dǎo)人而言，落地的關(guān)鍵在于技術(shù)上不能一刀切，不能為了用 Serverless 而用。主導(dǎo)人需要深入下去熟悉業(yè)務(wù)的處理流程和技術(shù)痛點(diǎn)，結(jié)合 Serverless 的優(yōu)勢(shì)進(jìn)行適配和推廣落地。
AGC翻譯服務(wù)最終實(shí)現(xiàn)的技術(shù)架構(gòu)圖示意如下：
落地 Serverless 的技術(shù)障礙：無狀態(tài)函數(shù)、限時(shí)計(jì)費(fèi)、冷啟動(dòng)時(shí)間
說了這么多 Serverless 的優(yōu)勢(shì)，但 Serverless 架構(gòu)仍然存在一些問題，我們只列舉其中最重要的三類問題供你參考，篤定 “Serverless First” 之前，還是要對(duì)此有清晰的認(rèn)知。
第一類是無狀態(tài)函數(shù)問題。為了更好地進(jìn)行水平擴(kuò)展和故障恢復(fù)，云函數(shù)是無狀態(tài)的，不提供緩存能力。但大家一實(shí)踐才發(fā)現(xiàn)，云函數(shù)雖然無狀態(tài)，但業(yè)務(wù)流程通常是有狀態(tài)的。一般的解決方案只能是，工程師自己操作一塊外置存儲(chǔ)保存狀態(tài)，并做好讀寫鎖。
這就導(dǎo)致整個(gè)開發(fā)工作比較復(fù)雜，而且天然不適合低延時(shí)場(chǎng)景。
但這個(gè)問題也正在被解決。還是以前文提到的華為應(yīng)用市場(chǎng) AppGallery Connect Serverless為例，InfoQ 了解到，華為AGC正在研發(fā)有狀態(tài)函數(shù)編程模型和多函數(shù)訪問并發(fā)一致性模型，解決狀態(tài)數(shù)據(jù)并發(fā)訪問導(dǎo)致的死鎖和狀態(tài)不一致、狀態(tài)數(shù)據(jù)高效讀寫等問題。有一個(gè)簡(jiǎn)單的示意方便你理解：
第二類是運(yùn)行時(shí)間限制。Serverless 是按使用時(shí)長計(jì)費(fèi)的，運(yùn)行完的函數(shù)實(shí)例會(huì)被銷毀，所以通常都會(huì)有運(yùn)行時(shí)長的限制，避免因?yàn)橥降却I(yè)務(wù)阻塞等問題，導(dǎo)致云函數(shù)長時(shí)間被掛起消耗資源。這就對(duì)一些強(qiáng)狀態(tài)依賴的服務(wù)造成了影響。
雖然云廠商一般都會(huì)允許開發(fā)者對(duì)云函數(shù)的默認(rèn)運(yùn)行時(shí)長進(jìn)行調(diào)整，但依然不能徹底解決這個(gè)問題。
要想治本，開發(fā)者應(yīng)該盡量避免出現(xiàn)讓函數(shù)長時(shí)間等待獲取狀態(tài)數(shù)據(jù)的場(chǎng)景，一種可行的解決方案是：可以采用有狀態(tài)的函數(shù)，盡量不要把狀態(tài)數(shù)據(jù)外置到第三方系統(tǒng)中，例如通過 REST 接口從三方獲取狀態(tài)數(shù)據(jù)。因?yàn)橐坏顟B(tài)數(shù)據(jù)依賴于第三方系統(tǒng)時(shí)，時(shí)延、性能等指標(biāo)就很難得到保證了。另一方面，通過動(dòng)態(tài)計(jì)價(jià)等新技術(shù)手段，來降低函數(shù)長時(shí)間運(yùn)行的費(fèi)用，逐步做到按需配置運(yùn)行時(shí)長，也是未來的一種技術(shù)探索方向。
第三類是云函數(shù)冷啟動(dòng)問題。如果函數(shù)常駐內(nèi)存，會(huì)導(dǎo)致資源浪費(fèi)，增加成本。如果每次調(diào)用都冷啟動(dòng)，耗時(shí)約在200毫秒左右（不同編程語言數(shù)據(jù)存在較大差異，該數(shù)據(jù)僅作參考舉例），對(duì)于一些時(shí)延敏感型的業(yè)務(wù)無法接受。如何解決函數(shù)冷啟動(dòng)問題，是個(gè)巨大的技術(shù)挑戰(zhàn)，也是云函數(shù)必須要攻克的難題。
反過來看，冷啟動(dòng)問題對(duì)于 Serverless 而言，既是挑戰(zhàn)，也是機(jī)遇。一旦加快了云函數(shù)的冷啟動(dòng)速度，Serverless 的適用領(lǐng)域?qū)⒂瓉泶蠓鶖U(kuò)張，徹底革新主流業(yè)務(wù)架構(gòu)。AppGallery Connect Serverless通過函數(shù)冷啟動(dòng)優(yōu)化、智能化函數(shù)調(diào)度策略，流量快速感知和實(shí)例快速啟動(dòng)等方式來不斷提升函數(shù)的啟動(dòng)和伸縮效率。
中間件、模型化、低代碼，是 Serverless 的進(jìn)階方向
當(dāng)然，除了云函數(shù)的冷啟動(dòng)問題，中間件、模型化、低代碼，也是 Serverless 下一階段比較核心的發(fā)展和進(jìn)化方向。
中間件
未來 Serverless 發(fā)展的一個(gè)重要趨勢(shì)是，會(huì)有越來越多的中間件 Serverless 化。傳統(tǒng)采用 SpringMVC、SpringCloud 或者微服務(wù)框架開發(fā)的業(yè)務(wù)，如果全部使用函數(shù)重寫，成本會(huì)非常高。
但如果有一個(gè) Serverless 微服務(wù)，只需要做一些小的適配性修改，就可以將已有的業(yè)務(wù)代碼直接 Serverless 化，享受 Serverless 帶來的免運(yùn)維、彈性伸縮等能力，那么任何一個(gè)架構(gòu)師都會(huì)開始慎重考慮，從現(xiàn)有架構(gòu)遷移到 Serverless 架構(gòu)的可行性。
模型化
當(dāng)業(yè)務(wù)依賴的 Serverless 服務(wù)比較少時(shí)，尚可以按照服務(wù)的開發(fā)和部署規(guī)則，通過服務(wù)的管理控制臺(tái)或者命令行 CLI 工具來進(jìn)行部署。
但對(duì)于較復(fù)雜的業(yè)務(wù)，涉及同時(shí)使用多個(gè) Serverless 服務(wù)，如果沒有統(tǒng)一的應(yīng)用描述和部署工具，那么每次部署和升級(jí)的成本都會(huì)很高。
如果能將 Serverless 模型化、規(guī)范化，把依賴的服務(wù)都自動(dòng)開通，實(shí)現(xiàn)一鍵式自動(dòng)化部署，將節(jié)省研發(fā)同學(xué)非常多的精力。
低代碼平臺(tái)
隨著企業(yè)數(shù)字化轉(zhuǎn)型的加速，傳統(tǒng)軟件開發(fā)模式的交付效率已經(jīng)無法滿足業(yè)務(wù)需求，企業(yè)的數(shù)字化建設(shè)滯后于業(yè)務(wù)需求，亟需提升開發(fā)效率，低代碼平臺(tái)逐漸成為一個(gè)技術(shù)熱點(diǎn)。
利用低代碼平臺(tái)，通過圖形化、拖拽、配置化和腳本化的方式即可完成應(yīng)用的構(gòu)建，相比于傳統(tǒng)的開發(fā)模式，開發(fā)難度和成本都大幅下降。
因?yàn)?nbsp;Serverless 天生具有的免運(yùn)維、高可用、彈性伸縮等特性，基于 Serverless 構(gòu)建的低代碼平臺(tái)會(huì)進(jìn)一步降低開發(fā)者的代碼量、開發(fā)成本以及上線之后的運(yùn)維工作量，真正實(shí)現(xiàn)應(yīng)用全生命周期的低代碼/低工作量。
所以，Serverless 低代碼平臺(tái)會(huì)是未來 Serverless 演進(jìn)的一個(gè)重要方向，據(jù)透露，華為應(yīng)用市場(chǎng) AppGallery Connect 的下一代 Serverless 解決方案核心就是低代碼平臺(tái)，用以解決應(yīng)用開發(fā)和運(yùn)維效率問題，架構(gòu)示例如下：
看到這里，你可能會(huì)想，又是有狀態(tài)函數(shù)，又是冷啟動(dòng)優(yōu)化，華為應(yīng)用市場(chǎng)投入 Serverless 的熱情來源于何處？我們知道，華為消費(fèi)者業(yè)務(wù)不斷堅(jiān)持“1+8+N”全場(chǎng)景智慧生活戰(zhàn)略，為消費(fèi)者打造全場(chǎng)景智慧生活體驗(yàn)。
而對(duì)華為應(yīng)用市場(chǎng)AGC而言，就是“加載創(chuàng)新源動(dòng)力”，幫助數(shù)百萬應(yīng)用開發(fā)者加速應(yīng)用創(chuàng)新，共同為全球用戶打造更美好的數(shù)字生活體驗(yàn)，是對(duì)華為消費(fèi)者業(yè)務(wù)戰(zhàn)略的一種承接。理解了這一點(diǎn)，看到華為應(yīng)用市場(chǎng)大力投入 Serverless 也就不會(huì)感到過度驚訝了。
無論如何，對(duì)于開發(fā)者而言，這是個(gè)美好的時(shí)代。相信無論是 Serverless First 戰(zhàn)略，還是未來更多場(chǎng)景化的 Serverless 應(yīng)用，都會(huì)給開發(fā)者帶來更多架構(gòu)層面的選擇。越來越高的應(yīng)用交付效率，將是未來一定時(shí)間內(nèi)，相關(guān)平臺(tái)和工具演進(jìn)的主旋律。
