【百度云原生導讀】

要做到真正的 Serverless 架構，需同時支持 FaaS 和 BaaS，做到快速上線、高彈性的優勢，真正達成降本增效。

文中提到的函數計算引擎 EasyFaaS 已開源：github.com/baidu/EasyFaaS

Distributed Cloud 2021全球分布式云大會·北京站于4月7日召開，在當天下午舉辦的分布式云報告會上，百度函數計算平臺業務負責人史南勝發表了題為《百度Serverless架構揭秘與應用實踐》的主題演講。

以下為演講概要：

1. 為什么要引入 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 場景的時候指的是函數計算。

2. 百度的 Serverless 場景解決方案

為了滿足客戶和開發者，或者以及百度內部集團所使用的一些場景，百度提供了五個終端級產品對外輸出：

• CFC（Cloud Backend Development）：面向公有云和集團內部云產品
• CFC-Stack：以私有化部署為主的一站式解決方案
• CFC@Edge：旨在將函數計算能力放在離用戶更近的邊緣側，從而提高性能，降低延遲。目前我們實現了集群版和單機版，用于滿足不同的場景。
• EasyFaaS：是一個依賴輕、適配性強、資源占用少、無狀態且高性能的函數計算服務引擎，目前正式對外開源，地址是https://github.com/baidu/EasyFaaS
• CBD（Cloud Backend Development）：面向開發而設計的平臺，比如小程序開發場景

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

史南勝對百度函數計算的整體架構進行了介紹，基于整個云端實踐進行觸發，整個函數計算的觸發場景包含很多種，此處列舉了6種：：HTTP服務請求、消息隊列、定時任務、BOS存儲事件、DuerOS技能、CDN事件。

這些技能觸發器都可以以同步或者異步的方式調用函數計算，這樣的函數計算遵循 CFC 的租賃格式，而且跟 AWS 進行對標沒有障礙。如果有客戶在 AWS 上面去做的函數計算，也可以很方便的去做遷移和使用。右側部分的配置服務，配置服務是離線管控模塊，這組模塊用來可以支撐代碼的管控、包的上傳，以及包括相應的原數據的管理。

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

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

史南勝就百度近期開源的一個函數引擎——EasyFaaS 分三部分進行了介紹，這是一個依賴輕、適配性強、資源占用少、無狀態且高性能的函數計算服務引擎。

【Github地址】：

https://github.com/baidu/EasyFaaS

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

EasyFaaS 開源的核心請求模式中，函數在請求的時候，冷啟動是需要時間的，黃色的圖標標識了整個事件請求以后過來的響應過程，可以支持用戶自己主動的請求，以及通過云端事件觸發的方式，原數據的管理對數據的代碼包和信息權限驗證進行管控，通過funclet 模塊進行二次容器初始化和管控。

EasyFaaS 以單 Pod為最小服務單位，每個Pod中包含3個容器，分別為 controller、funclet 和 runner-runtime。controller 負責流量調度及容器池狀態管理，runtime 是用來加載多語言運行時的一些鏡像環境，這些鏡像和環境初始化以后它便退出了，所以核心部分是通過 funclet 管控資源，合理的調配函數計算能力。綠色的部分是熱啟動的，為了考慮在高并發場景下能夠支撐業務場景的請求，所以支持熱加載的模式，熱加載的模式現在可以做到1毫秒以內。

3. 百度的 Serverless 場景解決方案

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

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

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

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

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

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

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

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

4. 未來展望與延伸

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

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

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

近幾年，百度在云原生方面獲得了一系列的獎項和認證。其中包括：通過了 Kubernetes 一致性認證并且是國內首批 Kubernetes 認證服務提供商（kcsp）；生態方面，百度是國內首批 CNCF 黃金會員，多次高級別的 KubeCon 大會贊助，并參與信通院《云原生應用實踐白皮書》、《無服務器架構技術白皮書》等文件撰寫；上游貢獻方面，百度主導了云原生 AI 工程項目 Paddle EDL；共同主導Kubernetes調度項目 Kube Batch等，百度期待與更多伙伴參與進開源社區的建設。

更多精彩內容歡迎關注百度開發者中心公眾號。

總結

以上是生活随笔為你收集整理的百度 Serverless 架构揭秘与应用实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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