簡介：越來越多的云產品都會向全托管、Serverless 形態演進。當云的產品體系 Serverless 化達到一個臨界值，通過函數計算這樣的 Serverless 計算服務結合其他 Serverless 形態的云服務，能夠完整的實現整個應用時，Serverless 就會變成了一個確定的技術趨勢，并越來越流行。

作者 | 不瞋

剛剛過去的 2021 年天貓雙 11，阿里云函數計算與阿里巴巴運維體系全面實現標準化對接，打通研發的最后一公里，首次實現了業務全鏈路“ FaaS + BaaS ”的 Serverless 體系化研發，覆蓋淘特、淘系、阿里媽媽、1688、高德、飛豬等業務場景，支撐場景數量同比增加 2 倍，峰值流量總數同比增加 3 倍，實現了百萬 QPS 的突破，人效提升 40%。

前段時間，我與 InfoQ 大咖說合作了一期直播，跟開發者們聊了聊我眼中的 Serverless。大家對于 Serverless 熱情很高，但是顧慮仍然存在，這也是我寫作本文的原因。作為這一技術浪潮的見證者，我想跟大家一起思考 Serverless 誕生的原因，阿里云 Serverless 技術和產品的演進歷程，以及我對 Serverless 未來趨勢的判斷。

01 云產品體系的 Serverless 化推動技術演進

雖然 Serverless 對很多人來說，仍然比較新鮮，但其實 Serverless 這種形態早已有之。

2010 年我剛加入阿里云，參與飛天操作系統研發，飛天操作系統最初是通過管理數千臺的機器來執行大數據處理的。用戶的編程界面是 MapReduce 任務，通過 SQL 語句等來處理海量數據，這就是早期的 Serverless 形態。

阿里云的第一個云服務對象存儲 OSS，亞馬遜云科技的第一個云服務 S3，它們其實也都是 Serverless 形態的存儲服務。用戶不需要關心數據如何被分片存儲到不同的服務器上來實現負載均衡，也不需要考慮如何做到在服務器宕機或者交換機故障時，保證數據的高可靠性和高可用性，他們只需要用簡單的 API 就可以實現海量數據的可靠存儲。他們都屏蔽了 Server 的復雜度，讓用戶有一個非常簡潔的 Serverless 體驗，這些都是 Serverless 形態。

2012 年，Serverless 概念被首次提出，到亞馬遜云科技正式商用 Lambda，Serverless 開始流行并逐漸走紅。近 10 年時間，這樣的演進過程并不偶然、也非一蹴而就，反而是帶著宿命般的必然性，其背后原因是云的產品體系一直都在向 Serverless 化演進。

無論是阿里云、Azure，還是亞馬遜云科技，絕大多數新產品都是全托管的 Serverless 形態。時至今日，公有云的用戶越來越習慣使用全托管的服務，除了省力以外，對很多用戶來說，最重要的是能更高效的解決業務問題。如果全托管的服務能帶來更好的性能、更好的穩定性、更少的運維代價，為什么不用呢？

按照這些邏輯，越來越多的云產品都會向全托管、Serverless 形態演進。當云的產品體系 Serverless 化達到一個臨界值，通過函數計算這樣的 Serverless 計算服務結合其他 Serverless 形態的云服務，能夠完整的實現整個應用時，Serverless 就會變成了一個確定的技術趨勢，并越來越流行。

02 Serverless 走出幻想破滅的低谷

2017 到 2018 年，我們都有體感 Serverless 熱度達到了一個高峰，但和很多新興技術一樣，從概念大討論到企業落地應用，都會經歷幻想破滅的低谷。從 Serverless 這十年的發展來看，無論是學術界還是工業界，都認為這是一項顛覆式的技術，在提升研發效率、資源效率上有著巨大的潛力。但作為一個新概念和新的計算形態，Serverless 最主要的挑戰是對開發者心智的改變，在工具鏈、編程模型、應用架構上，都需要開發者轉換思路。

今天，這些問題正在被快速的、持續的解決。

Serverless 正處于穩步上升期，我們能看到業界最主要的云服務商在不斷推出不同形態的 Serverless 計算服務，比如 Google Cloud Run，亞馬遜云科技的 App Runner，阿里云的 Serverless 應用引擎 SAE。另外，阿里云的函數計算這類最經典的 Serverless 計算服務，也正變得越來越通用，對應用的侵入越來越少。

無論在阿里巴巴上還是在阿里云上，開發者對 Serverless 的認識越來越客觀、務實，并在越來越多的場景中引入 Serverless 技術和相關的工具鏈，驅動 Serverless 生態愈加成熟。

03 給開發者安全感，是最重要的事

我們經歷了一個從 Serverless 非常受關注到落地困難，再到 Serverless 被廣泛使用的全過程。這個過程中也確實遇到了不少挑戰，解決 Serverless 落地困難的關鍵，在于給開發者安全感。對開發者來說，Serverless 把更多的技術層面的東西交給了云廠商去做，所以怎么給他們安全感，讓他們無負擔使用是非常關鍵的，也是他們做技術選型時最關注的點。

開發者這種安全感的擔憂主要來自于兩方面：

• 云廠商鎖定問題：Serverless 讓應用更深度的依賴于云服務商的能力，如何避免 vendor lock-in，從一個云遷移到另一個云，會有哪些障礙？
• 控制黑盒問題：云廠商接管了應用的運行平臺，怎么能提供給用戶控制力？比如用戶怎么能看到足夠豐富的指標來優化應用或者掌控應用運行的情況？云平臺出問題了怎么辦？出現問題時，用戶有什么手段能快速查明問題，恢復服務？

對于供應商鎖定的擔憂。阿里云是以公有云、阿里集團、開源三位一體的方式打造 Serverless 產品，堅定的擁抱開源開放。阿里云函數計算的 Runtime 運行時采用無侵入的標準的 http-server 協議，用戶使用 Golang 或者 PHP 寫的 Web server 放上來就可以跟 Serverless 平臺去交互。

另外函數計算的可觀測能力基于開源開放的 OpenTelemetry、OpenTracing 等標準。阿里云推出的 Serverless Devs 工具鏈也是開源開放的，提供了多個云廠商的 Serverless 應用部署的能力。承載阿里云事件生態的 EventBridge 也是采用 CNCF CloudEvents 開放標準。這些都是希望開發者能夠通過開源開放的方式來使用產品，未來，我們會積極推進 Serverless 領域的標準。

對于控制黑盒問題，最主要的是要做好產品設計的平衡，既能給開發者控制力，又能減小開發者的復雜度。阿里云函數計算把給開發者安全感看作最重要的事情，我們在可觀測性上是業界首個，也是目前唯一一個透出了實例級別的指標，讓用戶能更容易調優 Serverless 應用。我們透出了非常細粒度的資源計量數據，讓用戶能更容易判斷費用是否符合預期。

在未來，我們會將系統事件和狀態以合適的方式透出給開發者，讓他們能更容易預期系統的行為。我們也會在問題診斷等方面開放更多的能力，去貼合開發者已有的開發習慣，讓他們能更平滑的使用 Serverless。

04 正在全面落地的 Serverless

在應用場景上來看，Serverless 不再僅僅是小程序，還有電商大促、音視頻轉碼、AI 算法服務、游戲應用包分發、文件實時處理、物聯網數據處理、微服務等場景。Serverless 正持續與容器、微服務等生態融合，降低開發者使用 Serverless 技術的門檻，反過來也將促進傳統應用的云原生化。

在企業賦能方面，尤其是疫情之后，能夠看到用戶對 Serverless 的認知變深，在很多場景下，切換到 Serverless 架構確實能夠為用戶帶來明顯的收益，用戶逐漸認可這項技術。

1、Serverless 全鏈路、全場景覆蓋天貓雙 11

2020 年天貓雙 11，阿里云實現了國內首例 Serverless 在核心業務場景下的大規模落地，扛住了全球最大規模的流量洪峰，創造了 Serverless 落地應用的里程碑。

今年天貓雙 11，阿里云 Serverless 支撐業務場景更多，范圍更廣，阿里云函數計算與集團內的運維體系全面實現標準化對接，打通研發的最后一公里，首次實現了業務全鏈路“ FaaS + BaaS ”的 Serverless 體系化研發，覆蓋淘特、淘系、阿里媽媽、1688、高德、飛豬等業務場景，支撐場景數量同比增加 2 倍，峰值流量總數同比增加 3 倍，實現了百萬 QPS 的突破，人效提升 40%。

2、網易云音樂音視頻算法的 Serverless 探索

網易云音樂產品背后，實際有非常多的算法服務支撐，比如多種碼率的音頻轉碼、聽歌識曲中應用的音頻指紋生成和識別、副歌檢測、小語種音譯歌詞等等。這些任務的資源需求和執行時間變化很大，需要使用 C++、Python 等多種語言實現，對算力的彈性要求非常大。

原先網易是在自己的數據中心搭建這樣一個算法服務平臺，落地了 60+ 音視頻算法，對接 100+ 的業務場景。但隨著業務增長，基礎設施管理的負擔越來越大。雖然通過了很多方式去簡化了內部業務場景、算法等的對接，但越來越多夾雜存量、增量處理的算法；不同流量的業務場景規模，以及不同業務場景可能會復用同一類算法的，導致在業務上的時間越來越少。

比如上線一種新算法，首先要對超過 6000 萬首存量歌曲進行處理，這要求平臺在短時間內彈出大量算力，可靠的執行任務，同時提供完善的應用、實例等多維度的監控信息。這些需求是非常匹配函數計算的。網易在函數計算上高峰期一天處理超過 2000 萬個任務，算法應用到業務 10 倍速的提升，稀疏調用的算法成本大幅縮減。

網易這個案例最有意思的點，在于他們在應用層融合了自有機房和公有云上的服務。以往大家談到 Serverless，覺得它很難在混合云的場景下應用。網易的案例證明了專有云和公有云融合不是只有資源納管這一種方式，在應用層考慮融合方案，有時候效果會更好。

網易云音樂音視頻算法的 Serverless 探索之路

3、南瓜電影 7 天全面 Serverless 化

另一個比較有意思的案例是南瓜視頻使用 SAE 實現傳統微服務應用的零遷移改造，只用了一周就完整遷移到 SAE 平臺。

南瓜原有的微服務平臺面臨幾個挑戰：

• 運維成本高。要管理基礎設施，要規劃網絡，要升級系統等等，大量的時間花在這些低價值的工作上，而不是專注于業務的發展；
• 機器難以規劃容量。熱點電影經常造成訪問熱點，臨時擴容操作復雜、慢。南瓜經歷了業務的爆發式增長，因為一部熱映電影，1 小時新增 80 萬注冊用戶，比正常流量高了 80 倍，系統很快就崩了。

這次經歷促使南瓜進行了技術升級。用戶也對比了 K8s 和 SAE，最后認為要玩轉 K8s ，需要組建好專業團隊，代價不小。SAE 的產品形態非常有親和力，南瓜只花了很短的時間就遷移到 SAE，現在所有的應用都運行在 SAE 上。

南瓜電影 7 天內全面 Serverless 化實踐

05 Serverless 不是未來，是現在

云的發展一定是往更高的抽象層面發展，讓用戶研發效率更高更敏捷，資源使用更高效。因此云的產品體系一定是 Serverless 化，也就是越來越多的云服務是全托管、Serverless 的形態。如果我們把云看作一臺計算機，那么 IaaS 層是硬件，以 K8s 為代表的容器編排系統是操作系統，而 Serverless 計算則是應用的運行時。所以 Serverless 是云的未來，這實際上不算是對未來的預測，而是正在發生的事實。

接下來，Serverless 的產品形態會變得多樣，早些年大家都把 Lambda 這樣形態的產品等同于 Serverless 計算，這幾年我們看到 Google Cloud Run，亞馬遜云科技 App Runner 等針對 Web 應用場景的 Serverless 服務，阿里云函數計算也在不斷演進，比如支持容器鏡像、更少的運行限制等等。而且針對傳統微服務等存量市場，我們還推出了 SAE 這樣形態的服務，讓用戶能夠非常方便的把存量應用遷移上來，享受 Serverless 的紅利。

Serverless 底層技術發展上也有一些值得關注的趨勢。包括在資源調度上更加智能，因為 Serverless 的計算模式給平臺提供了更多的負載信息，使得平臺有機會通過數據驅動的方式在資源調度、流量路由等方面做得更加精準。另外，Serverless 有望支持更多類型的硬件，包括 ARM 類型的 CPU、GPU 或者 FPGA 等異構硬件，給用戶提供更有性價比的計算類型。

談未來，就不免說到對 Serverless 終點的判斷，我想云就像一臺計算機，在過去的 10 年，云主要是通過 Cloud Hosting 的模式，在兼容原有編程模式的同時，為開發者提供了海量的算力。但這種模式有點像使用匯編語言編程，開發者需要處理相當多的細節。微軟預測未來 5 年將新增 5 億個應用，超過過去 40 年的總和，這是傳統的開發模式難以支撐的。

所以我們看到現代應用、低代碼等理念開始流行。下一個 10 年，云的編程模型將迎來巨大的創新。過去 PC、移動互聯網，都從一開始的硬件創新，發展到形成自己的原生編程模型，形成完整的、繁榮的產業生態，云也正在經歷這樣的過程。最終，云會有屬于自己的、原生的、高效的編程模型和應用研發模式。而 Serverless 在云的生態中，扮演應用運行時的角色，是承載應用運行的基礎設施。

作者簡介：

不瞋：阿里云 Serverless 產品研發負責人，致力于構建下一代彈性、高可用的無服務器計算平臺。

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的解决 Serverless 落地困难的关键，是给开发者足够的“安全感”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。