![](https://intranetproxy.alipay.com/skylark/lark/0/2021/webp/22456429/1638941724124-66b6a938-467c-4c0e-925f-d89add851d7e.webp#clientId=u8bd526af-81e2-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=udced2562&margin=%5Bobject%20Object%5D&originHeight=456&originWidth=1080&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u4b14631b-7bdf-4939-9bae-d9218e4a98f&title=)
作者：不瞋，阿里雲 Serverless 技術負責人

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

前段時間，我與 InfoQ 大咖說合作了一期直播，跟開發者們聊了聊我眼中的 Serverless。大家對於 Serverless 熱情很高，但是顧慮仍然存在，這也是我寫作本文的原因。作為這一技術浪潮的見證者，我想跟大家一起思考 Serverless 誕生的原因，阿里雲 Serverless 技術和產品的演進歷程，以及我對 Serverless 未來趨勢的判斷。
# 雲產品體系的 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 就會變成了一個確定的技術趨勢，並越來越流行。
# Serverless 走出幻想破滅的低谷

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

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

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

無論在阿里巴巴上還是在阿里雲上，開發者對 Serverless 的認識越來越客觀、務實，並在越來越多的場景中引入 Serverless 技術和相關的工具鏈，驅動 Serverless 生態愈加成熟。
# 給開發者安全感，是最重要的事

我們經歷了一個從 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。
# 正在全面落地的 Serverless

在應用場景上來看，Serverless 不再僅僅是小程式，還有電商大促、音影片轉碼、AI 演算法服務、遊戲應用包分發、檔案實時處理、物聯網資料處理、微服務等場景。Serverless 正持續與容器、微服務等生態融合，降低開發者使用 Serverless 技術的門檻，反過來也將促進傳統應用的雲原生化。

在企業賦能方面，尤其是疫情之後，能夠看到使用者對 Serverless 的認知變深，在很多場景下，切換到 Serverless 架構確實能夠為使用者帶來明顯的收益，使用者逐漸認可這項技術。
### Serverless 全鏈路、全場景覆蓋天貓雙11

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

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

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

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

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

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

![](https://intranetproxy.alipay.com/skylark/lark/0/2021/webp/22456429/1638941724278-943d1f1d-7834-4c75-8f63-a57ae02236fd.webp#clientId=u8bd526af-81e2-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u12a1d8e6&margin=%5Bobject%20Object%5D&originHeight=375&originWidth=1080&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u56251b3e-79da-4c2d-8cbe-2984050cf70&title=)
### 南瓜電影 7 天全面 Serverless 化

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

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

- 運維成本高。要管理基礎設施，要規劃網路，要升級系統等等，大量的時間花在這些低價值的工作上，而不是專注於業務的發展；

- 機器難以規劃容量。熱點電影經常造成訪問熱點，臨時擴容操作複雜、慢。南瓜經歷了業務的爆發式增長，因為一部熱映電影，1 小時新增 80 萬註冊使用者，比正常流量高了 80 倍，系統很快就崩了。

![](https://intranetproxy.alipay.com/skylark/lark/0/2021/webp/22456429/1638941724328-ad2768ba-5b7b-4cff-894b-73cda710db92.webp#clientId=u8bd526af-81e2-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u1adca41c&margin=%5Bobject%20Object%5D&originHeight=292&originWidth=1080&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u742a617b-1400-428f-80a9-1e3dd7af4f8&title=)

這次經歷促使南瓜進行了技術升級。使用者也對比了 K8s 和 SAE，最後認為要玩轉 K8s ，需要組建好專業團隊，代價不小。SAE 的產品形態非常有親和力，南瓜只花了很短的時間就遷移到 SAE，現在所有的應用都執行在 SAE 上。
# 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 落地困難的關鍵，是給開發者足夠的“安全感”

相關文章