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