【百度雲原生導讀】
1. 要作到真正的 Serverless 架構，需同時支持 FaaS 和 BaaS，作到快速上線、高彈性的優點，真正達成降本增效。git
2. 文中提到的函數計算引擎 EasyFaaS 已開源：github.com/baidu/EasyFaaSgithub
Distributed Cloud 2021全球分佈式雲大會·北京站於4月7日召開，在當天下午舉辦的分佈式雲報告會上，百度函數計算平臺業務負責人史南勝發表了題爲《百度Serverless架構揭祕與應用實踐》的主題演講。web
如下爲演講概要：算法
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等，百度期待與更多夥伴參與進開源社區的建設。
更多精彩內容歡迎關注百度開發者中心公衆號。