作者 | 不瞋，阿里云 Serverless 負責人

"唯有超越，才能讓我們走下去。"

這是不瞋在阿里的第十年。從2010 年加入阿里云，不瞋參與了阿里云飛天分布式系統的研發，歷任批量計算的架構師、表格存儲（NoSQL）研發經理，深度參與了阿里云系統研發和產品迭代的全過程。2016 年不瞋成為阿里云函數計算產品研發負責人，致力于構建下一代彈性、高可用的無服務器計算平臺。

無服務器（Serverless）是不瞋下一個十年要攻克的技術難題。在這波 Serverless 浪潮里，阿里云一直走在最前面，無論是技術還是產品，在國內的豐富度都是第一。“從不敢掉以輕心，Serverless 在國內還處于早期階段，只有把技術和產品打磨成熟，讓用戶體驗做到更好，這一戰才算勝利。”

我們對不瞋做了一個簡單的采訪，針對大家比較關心的 Serverless 發展、技術難點以及落地情況，聽聽他的想法。

接受還是觀望？

云計算未來一定會成為整個社會和商業的基礎設施，屆時使用云計算就應該像現在我們使用水電煤一樣簡單，不需要了解水從哪里來、怎么過濾、怎么鋪設管道等一系列問題，只需要打開水龍頭接一杯水而已。而 Serverless 的概念正好可以幫助云計算朝這個方向往前走一步，它提倡的是人們不需要關心應用邏輯以外的服務相關的事情，包括管理、配置、運維等，用多少就付多少。

從這個角度來看， Serverless 是真正讓云計算變成社會商業基礎設施的一個實現路徑，也更接近現在業內提倡的云原生的方式，因此人們在使用云計算的過程中自然就應該按照 Serverless 的方式來使用。

國外的開發者在 Serverless 領域的心智明顯比國內開發者建立的更好。因為國外很多公司一開始就是基于 Lambda 生態來創業的，而國內一些大企業已經陸續開始使用 Serverless 的工具和產品，還有很大一部分企業處于觀望狀態。

一個新產品的出現也是要有一個適應期的，所以在 Serverless 這樣一系列產品出現之后，用戶對于是否使用、是否遷移、如何遷移是有很多顧慮的。經常會有企業咨詢關于函數計算的安全性如何保證，函數計算的穩定性如何保證，以及傳統項目遷移到 Serverless 架構是否有比較大的改造成本和改造風險等。這些顧慮很正常，但是我相信，隨著 Serverless 的發展， FaaS 定義的越發廣泛，工具鏈建設的越發完整，這些問題都會逐漸被解決。理論上，技術能解決的問題，都不算問題。

沒有規模，不要自建 Serverless

Serverless 帶來的彈性體驗、成本節約、開發效率提升等，都是非常具有吸引力的。傳統業務在開發上線的過程中，需要團隊合作，每個人開發一部分，合并代碼，開發聯調，然后進行資源評估，測試環境搭建、線上環境搭建、測試上線、運維。但是在 Serverless 時代下，開發者只需要開發自己那部分功能/函數，然后部署到測試環境、線上環境即可，后期很大一部分運維工作都不用考慮和擔心。

可以毫不夸張的說，如果企業自己通過云主機搭建的數據庫服務，一般情況下可用性不如云廠商提供的數據庫服務，此外，API網關、數據存儲服務等也是云廠商提供的產品性能更好，也更安全可靠。

小企業最好不要自己去建設 Serverless。因為 Serverless 的核心要素是按量使用，這就意味著如果今天的量很小，你就用很少的資源；如果今天的量很大，就需要調動更多的資源。“雙十一”的時候，流量都是億的量級，如果你的企業內部沒有按億級做單位的這種流量的機器資源，你怎么去調度這些資源給他人使用呢？沒辦法實現按量調度，就別提 Serverless 了。那些不具備資源規模化的企業不建議去自建 Serverless 能力，但是可以通過使用公有云的產品來實踐 Serverless。

當下，各大廠商都看準了 Serverless 是未來，就算它不是云計算的終態，也是通往終態的一個途徑，一方面是因為 Serverless 可以解決很多實際問題，更“像”或者說更“貼近”真正的云計算；另一方面，大家都不想在云計算發展的浪潮中掉隊。所以， Serverless 成了必爭之地。

關于 Serverless 能力的競爭主要有三部分：

一是性能，包括安全、穩定、彈性等在內，性能這部分如果做不好，我覺得不用說做不做 Serverless ，就算云計算也別做了，因為性能是 Serverless 的核心能力，一切都建立在安全、穩定、性能之上。

二是功能，想要把 Serverless 做好，功能是不可缺少的。因為 Serverless 不僅僅是 FaaS ，就算是 FaaS 也不僅僅是在線運行，還包括很多東西，如 BaaS 、觸發器、日志、監控、告警等。只有在功能上滿足開發者的訴求，開發者才有可能愿意使用。

最后是體驗， Serverless 的體驗太重要了，體驗包括方方面面，如功能的易用性、穩定性、安全性、產品的靈活性、工具鏈的完整性等。除了前面說的三點，我覺得社區、生態、開放等，也非常重要。

阿里云作為國內第一批推出 Serverless 平臺的公有云廠商，其 FaaS 平臺產品被稱為函數計算。從事件觸發、支持語言以及用戶體驗等方面考量，函數計算有很多數據值得關注：

• 事件觸發：阿里云函數計算可以被阿里云上的服務事件觸發，例如阿里云對象存儲（OSS）、日志服務（SLS）、消息服務（MNS）、表格存儲（OTS）、API 網關、CDN 等，其特性在于獨特的 Callback 機制大大減少開發者對于異步模型的架構和代碼成本；

• 支持語言：阿里云函數計算目前支持主流開發語言如 Node.js、Java、Python，并通過 Custom Runtime 支持 Go、C/C+、Ruby、Lua 語言等；

• 用戶體驗：阿里云函數計算提供了基于 Web 的控制臺和 SDK ；用戶可以通過 Web 控制臺管理函數應用，也可以通過交互式的命令行來操作；

• 服務模式：函數可以被服務和應用管理，單個函數實例可以并行執行多個請求，有效節省計算資源成本。

棘手的難題

Serverless 的痛點很棘手，例如傳統項目如何快速遷移到 Serverless ，如何平滑過渡，如何 Serverless 化， Serverless 架構下如何進行更優的調試，如何更好的節約成本等，每一個都是難題。我的同事許曉斌在《喧嘩的背后：Serverless的概念及挑戰》一文中曾提到落地 Serverless 面臨的挑戰：

在主流的場景大規模的落地 Serverless，并不是一件容易的事情，面臨的挑戰有很多，下面我具體分析一下這些挑戰：

挑戰一：業務輕量化困難

要實現徹底的自動彈性，按實際使用資源付費，就意味著平臺需要能夠在秒級甚至毫秒級別擴容出業務實例。這對基礎設施是一個挑戰，對業務，尤其是比較龐大的業務應用來說，更提出了很高的要求。如果一個應用的分發和啟動需要十分鐘，那么自動彈性的響應能力就基本無法跟上業務流量的變化了……

挑戰二：基礎設施響應要求極高

一旦 Serverless 的應用或者函數的實例能夠實現秒級，甚至毫秒級擴容，相關基礎設施就很快會面臨巨大的壓力。最常見的基礎設施就是服務發現和日志監控系統，原本整個集群實例的變化頻率可能是每小時幾次，現在這個頻率變成了每秒幾次；此外，如果這些系統的響應能力跟不上實例變化的速度，那么整個體驗也就大打折扣了。

挑戰三：業務進程生命周期與容器不一致

Serverless 平臺依賴標準化的應用生命周期，才能實現完全自動的容器騰挪，應用自愈等特性。而在基于標準容器及 Kubernetes 的體系下，平臺能控制的生命周期就是容器的生命周期。因此就需要業務做到業務進程的生命周期和容器的生命周期保持一致，具體包括啟動、停止、以及 readiness probe 和 liveness probe 的規范等等……

挑戰四：可觀測能力需完善

在 Serverful 的模式下，如果生產環境出現任何問題，服務器是不會消失的，用戶會很自然的想到登陸到服務器上去。到了 Serverless 模式下，用戶不需要關心服務器了，也就是說默認情況下是看不到服務器了，那么這個時候如果系統出現異常了，而且平臺無法完成自愈怎么辦呢？……當圍繞 Serverless 模式的全面可觀測能力不足的時候，用戶必然不會對此感到放心。

挑戰五：研發運維心智需要改變

幾乎所有的研發，在職業生涯中第一次部署自己的應用程序的時候，都是面向一臺服務器的，或者說是面向一個 IP 的，這是一種非常強大的習慣。在 Serverless 逐漸落地的過程中，研發需要轉換一些思維的模式，逐步地去適應 “IP 隨時可能會發生變化” 這樣一種心智，轉而更多的從服務版本，以及從流量的視角去運維自己的系統。

打個比喻，Serverless 目前確切來說已經有了一個形態，也就是有一個框架，但是這個框架里還有很多格子（問題）沒有被填滿（解決），這也是大家今天對是不是該用Serverless 存在疑問的地方，原因之一是還沒有看到足夠多的成功案例。但事實上，阿里在2019年雙十一就已經成功實踐了 Serverless。不僅如此，阿里云還帶動了一批企業使用函數計算產品，從而節省了大量的 IT 成本。?

"成為用戶需要的 Serverless"

函數計算有幾個非常典型的應用場景，比如 Web 應用、AI 推理、音視頻處理、圖文處理、實時文件處理、實時流處理等，目前函數計算擁有大量的客戶群體，如石墨文檔、芒果TV、新浪微博、碼隆科技等。

以微博為例，函數計算平均每天承載微博幾十億次請求，其毫秒級伸縮計算資源能夠確保在熱點事件發生時，應用仍能保證穩定的延時，用戶體驗完全不受訪問次數的影響。通過函數計算運行圖片處理服務，微博實現了持續的成本節省，再也不需要為平滑處理業務高峰帶來的流量激增而提前預留大量閑置機器資源，同時由于不需要維護復雜的機器狀態，工程師可以集中精力與產品團隊合作增加業務價值，而不是花時間管理基礎設施。

不僅像新浪這樣的早期互聯網企業已經落地 Serverless，一些新興的創業公司也正在加入Serverless 陣營。

藍墨是一家由美國留學生回國創業的高科技公司，專注于移動互聯時代數字出版和移動學習領域的新技術研究及平臺運營。隨著在線教育迎來需求爆發，藍墨加大了整合業界優質課程資源的力度，不斷拓展自身的業務邊界，在贏得機遇的同時，技術團隊也面臨了前所未有的挑戰。

視頻處理相關業務是藍墨技術團隊遇到的最棘手的問題之一。藍墨每天都要處理大量視頻教材資源，涉及到視頻剪輯、切分、組合、轉碼、分辨率調整、客戶端適配等一系列復雜的技術工作。在前幾年的技術實踐中，藍墨技術團隊通過 FFmpeg 等技術已經建立起一整套自主可控視頻處理機制，支撐了業務的快速發展。但今年的業務增長速度是藍墨的工程師們始料未及的，高峰期數十倍于往年的視頻處理需求讓現有的架構不堪重負，嚴重影響了用戶體驗。

?

藍墨現在的核心訴求概括有三個：節省成本、極致彈性、免運維，而這些恰恰是 Serverless 最擅長解決的問題。經過對國內云廠商提供的 Serverless 服務的多方面調研后，藍墨技術團隊一致認為在視頻處理領域阿里云函數計算是最適合他們的方案。

?

由于FC完全兼容現有的代碼邏輯，也能夠支持各類主流的開發語言，所以藍墨技術團隊可以把代碼邏輯以近乎無縫銜接的方式從原有的架構遷移到FC上，并且成本極低。通過對接 OSS 觸發器，只要 OSS 上有新的視頻源文件上傳，就能自動拉起函數計算實例，開啟一次視頻處理業務的生命周期。

通過整合 Serverless 工作流，還能對分布式任務進行統一編排，實現對于大文件切片后進行并行處理并最終合并的復雜操作，能夠在短時間內迅速調集上萬個實例的計算資源，實現視頻處理任務的快速執行；

另一方面，相比于傳統的方式，基于函數計算 FC 的 Serverless 方案在視頻處理場景下，可以幫助藍墨節省了?60%?左右的 IT 成本投入。

下一個十年的主戰場

理想中的 Serverless，應該是：更完善的產品形態，更極致的彈性能力，更好用的工具鏈，更節約的成本，更高效的開發效率，更便捷快速的遷移速度，更簡便強大的上云體驗。要做到能讓開發者以一種方式專注于業務代碼的開發，無需關注運行平臺的差異性，一處編寫可以處處運行，開發者只要掌握一種方式就可以在不同業務之間沒有學習成本地切換。

站在開發者的視角，Serverless 的整個研發模型對研發體系也帶來了挑戰。對于前端來說，Serverless 不僅補足了前端工程師現有的能力，還可能使整個前端行業的定位發生變化。原來經常有人會認為前端的工作很簡單，面向 UI 做好開發就行，剩下的工作可以交給后端。但是前端和 Serverless 結合之后，大家對前端的訴求就不僅僅是開發一個頁面了，而是要能交付整個應用的開發。

但是相應來講，后端同學可能第一反應就是，那這是不是把我革命了？我就不需要干活了？其實不是這樣的。Serverless 研發模式的演進有助于幫助他們往更底層演進，讓他們聚焦于真正需要做技術研究的部分。比如，這些數據的能力、服務的能力，怎么做得更好、更扎實，這是我們期望看到的。

阿里云正在通過工具鏈、社區以及產品能力的結合，打一張非常有趣且會對Serverless 的整體發展非常有利的牌。阿里云 Serverless 的目標是成為“大家需要的 Serverless ”，這是與其他云廠商截然不同的地方。只有將用戶需求放在首位的 Serverless 廠商，才能將 Serverless 產品做好。

未來，Serverless 將無處不在，任何足夠復雜的技術方案都可能被實現為全托管、Serverless 化的后端服務。不只是云產品，也包括來自合作伙伴和三方的服務，云及其生態的能力將通過 API + Serverless 來體現。事實上，對于任何以 API 作為功能透出方式的平臺型產品或組織，如釘釘、滴滴、微信等，Serverless 都將是其平臺戰略中最重要的部分。

推薦閱讀

• 什么？一個核同時執行兩個線程？
  

• 征戰云時代，為什么安全是關鍵命題？
  

• 25 張圖讀懂「文件系統」
  

• 數據平臺、大數據平臺、數據中臺……傻傻分不清？這次終于有人講明白了！
  

• Java 二十五載，正在 Kotlin 化！
  

• 維度爆炸？Python實現數據壓縮如此簡單

總結

以上是生活随笔為你收集整理的为什么说下一个十年的主战场在Serverless？的全部內容，希望文章能夠幫你解決所遇到的問題。

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