造夢者 | 不瞋，阿里雲 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 都將是其平臺戰略中最重要的部分。
