原標題：百度史南勝：百度Serverless架構揭祕與應用實踐

備受關注的Distributed Cloud|2021全球分佈式雲大會·北京站於4月7日隆重召開，分佈式雲是2021年全球十大重要戰略科技趨勢，利用分佈式架構技術創新，連接邊緣節點、私有云和公有云的IT資源組成分佈式混合雲。

全球分佈式雲聯盟力求打造分佈式雲計算旗艦級技術盛會，本次大會共設有分佈式雲報告會、邊緣計算論壇、Serverless雲原生論壇、分佈式數據庫論壇、分佈式存儲論壇，跨境SD-WAN諮詢會等六大論壇，圍繞分佈式雲、分佈式算力、Serverless、雲原生、HTAP、IPFS等技術與實踐展開。聯合阿里雲、騰訊雲、百度雲、金山雲等全棧技術引領者與全球分佈式雲聯盟攜手打造這場技術饕餮盛宴。

在4月7日下午舉辦的分佈式雲報告會上，百度函數計算平臺業務負責人 史南勝發表了題爲《百度Serverless架構揭祕與應用實踐》的主題演講。

01 爲什麼引入SERVERLESS

爲什麼要做Serverless？Serverless能給我們帶來什麼？爲什麼要引入Serverless？我們現在服務化不是做的挺好嗎？PAAS平臺不是也做得挺好嗎？爲什麼要用Serverless呢？對於所有的場景都適用降本增效一說嗎？史南勝首先站在客戶的角度發出了一連串的提問。

金融領域、國有企業這樣的領域，對於資源的利用率上不拘小節，沒有像中小型客戶那樣應用資源非常的謹小慎微，所以對於金融領域，或者說一些對資源利用率要求不至於嚴苛的場景，主要提供人效開發，讓開發成本降低。對於中小型客戶，尤其是兩三個人創業的場景，比如小程序的開發者，需要考慮到他們推向產品的市場的時間，以及業務佈局的快速度，推薦他走Serverless的場景，這樣的場景可以快速的提高他的開發速度，以及降低運維的成本。

哪些場景合適，哪些場景不合適呢？史南勝表示，Serverless並不是解決方案，並不能短期內替代掉服務化，或者微服務化的技術，它也是在服務化或微服務化發展到一定程度以後，基於容器計算的新技術。經常有客戶問，我們怎麼從一個單邊應用，或者從一個微服務架構應用遷移到Serverless場景呢？並不是每個場景都能夠遷移的。所以說需要區分一些場景，將一些合適的場景我們去探索。

史南勝分成三個部分解析這一問題：第一，事件的觸發處理。第二，數據處理計算。第三，應用後端服務。

在探索和應用的場景裏面主要包含像實時文件處理、圖片裁剪添加水印，這種場景爲什麼適合呢？不是時時刻刻都有用戶在上傳圖片，或者不是時時刻刻都有這樣的事件在處理，這樣的場景是否通過函數計算和Serverless場景去解決？還有數據計算場景，比如說像物聯網網關和P2P裏面的計算等，應用後端服務現在大規模使用的是智能小程序的開發，讓他們通過Serverless的場景快速將自己的技能通過函數計算平臺能夠快速的開發、上線，將產品推向市場，產生收益。這樣的技能又可以在小度音箱上面去產生售賣和調用，在調用支付的時候會給創業者帶來一定的收益。

哪些場景不太適合呢？像延遲敏感高，對於穩定性級別很高的像交易場景、支付場景，還有檢索場景，不太推薦目前在現有的發展技術下去使用Serverless和函數計算的場景。

那麼對於隱私這樣的場景適合用Serverless的架構方案去解決嗎？在這裏通過相應的實踐和證明，隱私不是考量Serverless架構合適和不合適的一個很重要的因素，因爲在任何的場景下都會去確保客戶的隱私和數據（安全）問題。對於隱私高的場景，比如像金融領域我們都會去做私有化的部署。

現在看Serverless從廣義角度來講，按功能分爲FAAS和BAAS上面，常見的可以看到大家老生常談的相對來說是比較狹義的概念，這樣狹義的概念指的是FAAS上面，就是關注於業務場景的邏輯處理。而對於底層的存儲、緩存和對象級別的存儲來說，會依託於雲上面的資源，或者本身自己的一些傳統在微服務化下面的存儲來去處理。

如果要做到真正的Serverless的架構方案，需要將FAAS和BAAS同時支持，這樣支持以後才能真正做到高彈性、高可擴容/可伸縮的優勢，才能真正做到降本增效，不然的話FAAS流量上來以後，後臺的BAAS技術如果跟不上，這樣的彈性擴縮容是需要受到挑戰的。但是今天史南勝主要從狹義的場景來介紹FAAS的基礎，通常講Serverless場景的時候指的是函數計算。

02 百度的Serverless場景解決方案

百度提供了四個終端產品級的計算，爲了滿足客戶和開發者，或者以及百度內部集團所使用的一些場景，包含CFC，在公有云上面面向中小客戶，包括大型客戶的部分場景；CFC-Stack主要在私有化領域專有云版統一的技術棧解決方案；CFC邊緣計算的場景，主要面向的是用戶在加載比較快，對地域要求比較高的一些場景；EasyFaaS是百度的開源產品，這個開源產品是昨天（4月6日）夜裏12點鐘的時候正好百度審批通過，在百度上有開源源代碼，包含了百度在函數計算領域裏面的核心引擎的代碼部分，歡迎大家也可以跟我們一起共建。第五個解決方案是CBD，這是基於小程序，或者一站式的產品解決方案，可以支持開發者在小程序上面進行雲開發、雲調用和雲存儲。

百度經過數年的打磨，在私有化和公有化領域裏面，將開源和公有、私有，以及面向百度其他內部雲支持的產品打磨成統一的公共的底層函數服務支持，這個能夠滿足整個函數計算的編寫、上線、開發和運營，在大部分場景下能夠提供相應的技術支持，並且百度還開發相應的工作鏈，提供了相應的SDK和插件，以及運行時能夠供定製化的業務團隊做二次開發。

史南勝對百度函數計算的整體架構進行了介紹，基於整個雲端實踐進行觸發，整個函數計算的觸發場景包含很多種，此處列舉了6種，包括CDN、BOS、消息通知的觸發，以及小度技能的觸發，這些技能觸發器都可以以同步或者異步的方式調用函數計算，這樣的函數計算遵循CFC的租賃格式，而且跟AWS進行對標沒有障礙。如果有客戶在AWS上面去做的函數計算，也可以很方便的去做遷移和使用。右側部分的配置服務，配置服務是離線管控模塊，這組模塊用來可以支撐代碼的管控、包的上傳，以及包括相應的原數據的管理。

函數的觸發服務是我們的一個關鍵錄用模塊，用來監聽事件的請求、權限的管理、資源的調度申請、路由等等，資源的調度服務用來管控整個函數的運行資源池，函數的整個運行資源池是我們第二大核心部分，函數運行引擎就是剛纔的開源重要的代碼模塊，函數計算引擎提供了我們在運行代碼生命週期的管理。用戶的空間會按照我們在函數代碼功能的執行和空間的大小會動態的調配相應的內存CPU佔用空間。

左側是做資源的釋放，資源池的維護會通過相應的服務模塊架構對資源進行管控。資源的調度服務就是用來去響應事件觸發服務，對整個資源池的管理。函數計算的核心就是基於事件的處理調度，將用戶的代碼和函數的核心功能進行動態的加載空間容器，並且進行動態銷燬的過程。

史南勝就百度準備開源的一個函數引擎——EasyFaaS分三部分進行了介紹，這是一個輕量級運行相對來說比較快的函數計算服務引擎。

第一部分是產品功能，提供了核心的函數信息管理、代碼包管理、版本管理、灰度發佈，通過這樣的能力滿足了大部分場景下函數計算的核心訴求，用戶拿到EasyFaaS就可以快速的去搭建一個基於百度函數計算引擎的計算平臺，能夠滿足他在部分的業務場景下定製化的開發。這樣的開發通過開源的方式能夠讓大家提交相應的功能，將這些功能能夠共建起來；第二部分是請求控制與容器調度；第三部分是容器與網絡技術，進一步將容器的利用資源最大化，並且提供多元的運行池。

EasyFaaS開源的核心請求模式中，函數在請求的時候，冷啓動是需要時間的，黃色的圖標標識了整個事件請求以後過來的響應過程，可以支持用戶自己主動的請求，以及通過雲端事件觸發的方式，原數據的管理對數據的代碼包和信息權限驗證進行管控，通過funclet模塊進行二次容器初始化和管控。一個pod裏面有三個容器，有container和runtime，其中runtime是用來加載多語言運行時的一些鏡像環境，這些鏡像和環境初始化以後它便退出了，所以核心部分是通過funclet管控資源，合理的調配函數計算能力。綠色的部分是熱啓動的，爲了考慮在高併發場景下能夠支撐業務場景的請求，所以支持熱加載的模式，熱加載的模式現在可以做到1毫秒以內。

03 百度函數計算應用實踐與經驗介紹

我們基於這樣的核心引擎，可以在哪些地方去落地？又產生了哪些經驗和教訓呢？史南勝主要舉了三個重要的案例場景。

單體應用，或者微服務應用怎麼遷入到Serverless？對於一些場景，比如說小程序場景通過API網關的模式，然後調度到百度智能雲函數計算處理業務，並且發起相應的業務邏輯去調度相應的後端服務，可以將部分的業務代碼遷移到函數計算平臺。將原來核心的部分業務邏輯代碼仍然以微服務這樣的方式放在後端服務裏面。如果面對中小型企業客戶，本來在雲上產生了相應的存儲和計算資源，可以繼續使用雲數據庫雲緩存的方式使用，百度雲上的資源可以一站式打通。

在微服務架構領域，服務與服務之間除了IDC方式調用以外，函數計算方式可以通過黃色的箭頭去發消息，可以支持和集成，可以提前加載到函數計算平臺，以鏡像的方式進行加載，這個可以讓包降低很多。所以說消息隊列可以監聽完以後，百度函數計算的另一個板塊可以進行相應。大家可以將百度函數計算的方式以微服務化的理念來去開發和運作，並且還可以將這樣的處理方式上傳到雲存儲上面去。

業務方去處理什麼呢？他們只需要聚焦在業務邏輯處理，編寫相應的代碼，百度的代碼和插件層面提供了很好的工具開發，業務方可以在web id，或者相應的代碼id上面去開發，開發完了以後通過打包的方式，或者一站式插件集成的方式提交。對於複雜的場景，百度提供了編排方式，只需要編寫Serverless的壓縮文件就可以處理更復雜的分佈式的業務處理邏輯。

這是一個比較典型的提供給一些相應的私有客戶部署的能力，這個能力是用來做什麼呢？是用來做整個大數據的處理，客戶聚焦在中間這兩部分，就是事件觸發器定義和函數計算邏輯的編寫。百度支持通過流失數據和批量數據鏡像掛載的方式，可以支持afs，並且可以支持消息隊列流式數據的監聽，通過這樣的方式觸發調起函數計算，執行業務，支持業務的邏輯計算，將相應的數據分發到其他的業務部門裏面去。

用戶基於百度的Serverless平臺提交代碼就可以定義事件、配置信息了，這樣帶來的好處架構上面的事情交給了平臺方去做，業務平臺上面的事情交給了業務方去做。

第三個案例，可以通過百度雲的函數計算案例體驗，這個體驗可以給大家包括一些技能的開發者帶來很多的一些像公積金的計算，或者天氣的查詢，史南勝表示自己也通過小程序和OS方式同時開發了兩個技能，以小程序的方式和OS方式發佈出來給別人使用，這樣的技能可以直接調用天氣的方式，比如調用開放接口的墨跡天氣自己使用，並且可以將業務邏輯算法集成。這個產生什麼收益呢？可以按技能付費，做成三步：雲函數創建與自定義、技能創建與綁定技能、運行時請求路由，請求調度的資源統計，以及賬號的掛靠。通過這三步可以迅速的將一個新的家庭小度音箱的智能場景能夠快速的連接起來，PPT裏面紅色的字樣是核心部分。

除了這些場景，還可以在哪些場景去使用呢？包括應用分發的場景領域，像遊戲包，分渠道的打包和運作過程，小程序的開發，以及在集團內部持續的CICD和搜索圖譜，包括百度的搜索阿拉丁卡片，以及在金融領域私有化部署，還有汽車、教育等領域的新技術聯動，以及大數據處理，都可以去用函數計算的方式去處理。

04 未來展望與延伸

百度函數計算今後還會圍繞哪幾個方面去運作呢？Serverless場景以前大家都處於觀望狀態，現在開始在小規模場景使用，之後大規模場景使用。

百度函數計算重點是幫助客戶轉型，還是圍繞降本增效的理念爲大家節省資源，並且提供更穩定的服務。在公有化、私有化和開源生態領域，百度會去形成一個組合拳，開源的部分也希望大家與百度一起來來共建。

百度的雲原生，除了Serverless函數計算，還有容器服務和微服務架構的治理，還有容器調度，以及效率雲的DevOps的計算。百度在今年申請了一站式的技術棧，歡迎大家一起了解一下，不僅提供Serverless的解決方案，還提供容器、微服務架構治理的解決方案，包括效率上面的解決方案。

百度在近幾年在雲原生方面獲得了一系列的獎項和認證，百度是K8S第一批認證廠商，也是在國內第一批和K8S建立起合作，能夠提供服務的第一批公司，百度期待與更多夥伴參與進開源社區的建設。