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