作者：不瞋，阿裡雲 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，覺得它很難在混合雲的場景下應用。網易的案例證明了專有雲和公有雲融合不是隻有資源納管這一種方式，在應用層考慮融合方案，有時候效果會更好。
南瓜電影 7 天全面 Serverless 化
另一個比較有意思的案例是南瓜視訊使用 SAE 實作傳統微服務應用的零遷移改造，隻用了一周就完整遷移到 SAE 平台。
南瓜原有的微服務平台面臨幾個挑戰：
- 運維成本高。要管理基礎設施，要規劃網絡，要更新系統等等，大量的時間花在這些低價值的工作上，而不是專注于業務的發展；
- 機器難以規劃容量。熱點電影經常造成通路熱點，臨時擴容操作複雜、慢。南瓜經曆了業務的爆發式增長，因為一部熱映電影，1 小時新增 80 萬注冊使用者，比正常流量高了 80 倍，系統很快就崩了。
這次經曆促使南瓜進行了技術更新。使用者也對比了 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 在雲的生态中，扮演應用運作時的角色，是承載應用運作的基礎設施。