實戰指南 | Serverless 架構下的應用開發

作者 | 劉宇、田初東、盧萌凱、王仁達

UC Berkeley認為Serverless架構的出現程序類似于40多年前從匯編語言轉向高級語言的程序，在未來Serverless架構的使用會飆升，或許服務器式云計算并不會消失，但是將促進BaaS發展，以更好地為Serverless架構提供支持，

Serverless 架構的應用開發流程

基于 Serverless 架構的應用開發流程將會比基于傳統架構的應用開發更簡單，在 Serverless 架構下進行應用開發，用戶通常只需要按照規范撰寫代碼、構建產物，然后部署到線上即可，

如圖 1 所示，CNCF Serverless Whitepaper v1.0 指出函式的生命周期從撰寫代碼并提供規范元資料開始，一個 Builder 物體將獲取代碼和規范，然后編譯并將其轉換為工件，接下來將工件部署在具有控制器物體的集群上，該控制器物體負責基于事件流量和/或實體上的負載來擴展函式實體的數量，

圖-1 函式部署流水線示意圖

如圖 2 所示，函式創建和更新的完整流程如下，

圖-2 函式創建/更新流程示意圖
1）在創建函式時，提供其元資料作為函式創建的一部分，對其進行編譯使其具有可發布的特性，接下來啟動、禁用函式，函式部署要能夠支持以下用例，

• 事件流（Event Streaming）：在此用例中，佇列中可能始終存在事件，但是可能需要通過請求暫停/恢復進行處理，

• 熱啟動（Warm Startup）：在任何時候，具有最少實體的函式能使所接收的“第一”事件快速啟動，因為該函式已經部署并準備好為事件服務（而不是冷啟動），其中函式通過“傳入”事件在第一次呼叫時部署，

2）用戶可以發布一個函式，這將創建一個新版本（最新版本的副本），發布的版本可能會被標記或有別名，

3）用戶可能希望直接執行/呼叫函式（繞過事件源或 API 網關）以進行除錯和開發程序，用戶可以指定呼叫引數，例如所需版本、同步/異步操作、詳細日志級別等，

4）用戶可能想要獲得函式統計資料（例如呼叫次數、平均運行時間、平均延遲、失敗次數、重試次數等），

5）用戶可能想要檢索日志資料，這可以通過嚴重性級別、時間范圍、內容來過濾，Log 資料是每個函式級別的，它包括諸如函式創建/洗掉、警告或除錯訊息之類的事件，以及可選的函式的 Stdout 或 Stderr，優選每次呼叫具有一個日志條目或者將日志條目與特定呼叫相關聯的方式（以允許更簡單地跟蹤函式執行流），

圖-3 開發 Serverless 應用的流程

如圖 3 所示，以阿里云 Serverless 產品為例，在生產環境中開發 Serverless 應用的流程是：

步驟1：根據 FaaS 供應商所提供的 Runtime，選擇一個熟悉的編程語言，然后進行專案開發、測驗；
步驟2：完成之后將代碼上傳到 FaaS 平臺；
步驟3：上傳完成之后，通過 API/SDK 或者由一些云端的事件源觸發上傳到 FaaS 平臺的函式；
步驟4：FaaS 平臺就會根據觸發的并發度等彈性執行對應的函式；
步驟5：最后用戶根據實際資源使用量按量付費，

與 ServerFul 應用開發流程對比

下面我們將通過生產環境中的案例，對傳統架構下的應用開發與 Serverless 架構下的應用開發進行舉例對比，

以一個 Web 應用為例，如圖 4 所示；

圖-4 傳統三層 C/S 架構下某電子商務網站應用簡圖

通常情況下一些 Web 應用都是傳統的三層 C/S 架構，例如一個常見的電子商務應用，假設它的服務端用 Java，客戶端用 HTML/JavaScript；在這個架構下服務端僅為云服務器，承載了大量業務功能和業務邏輯，例如，系統中的大部分邏輯（身份驗證、頁面導航、搜索、交易等）都在服務端實作，
當把它改造成 Serverless 應用形態時，架構如圖 5 所示，

圖-5 Serverless 架構下某電子商務網站應用架構簡圖

步驟1：在 Serverless 應用形態下，移除最初應用中的身份驗證邏輯，換用一個第三方的 BaaS 服務；
步驟2：允許客戶端直接訪問一部分資料內容，這部分資料完全由第三方托管，這里會用一些安全配置來管理客戶端訪問相應資料的權限，
步驟3：前面兩點已經隱含了非常重要的第三點，即先前服務器端的部分邏輯已經轉移到了客戶端，如保持用戶會話、理解應用的 UX 結構、獲取資料并渲染用戶界面等，客戶端實際上已經在逐步演變為單頁應用；
步驟4：還有一些任務需要保留在服務器上，比如繁重的計算任務或者需要訪問大量資料的操作，這里以“搜索”為例，搜索功能可以從持續運行的服務器端拆分出來，以 FaaS 的方式實作，從 API 網關（后文做詳細解釋）接收請求并回傳回應，這個服務器端函式可以和客戶端一樣，從同一個資料庫讀取產品資料，原先的搜索代碼略做修改就能實作這個“搜索”函式；
步驟5：還可以把“購買”功能改寫為另一個 FaaS 函式，出于安全考慮，它需要在服務器端而非客戶端實作，它同樣由 API 網關暴露給外部使用，
傳統云主機架構下應用的開發和上線如圖 6 所示，

圖-6 傳統云主機架構下應用開發和上線流程簡圖

開發者完成代碼開發之后，需要進行上線前的準備，包括但不限于評估資源、購買服務器、安裝作業系統、安裝服務器軟體等，完成之后再進行代碼部署，之后還需要有專業的人或者團隊，對服務器等資源進行持續監控和運維等，例如流量突然提升時需要進行服務器的平滑擴容，流量突然降低時需要進行服務器的平滑縮容等，

但是在 Serverless 架構下，整個開發模式發生了比較大的改變，

圖-7 Serverless 架構下應用開發和上線流程簡圖

結合上面某電子商務網站見圖 7，在上述應用開發和上線流程中，Serverless 架構開發者實際關心的只剩下函式中的業務邏輯，至于身份驗證邏輯、API 網關以及資料庫等原先在服務器端的一些產品和服務統統由云廠商提供，

同時，用戶不需要關注服務器層面的維護，也無須為流量的波峰和波谷進行運維資源的投入，用戶也無須為資源閑置進行額外的支出，Serverless 架構的按量付費以及彈性伸縮能力、服務端低運維/免運維能力，可以讓用戶的資源成本、人力成本降低，整體研發效能大幅提升，讓專案的性能、安全性、穩定性得到極大的保障，

綜上所述，Serverless 架構與傳統架構應用開發流程的明顯區別是，前者讓開發者將更多的精力放在自身業務邏輯上，并強調 Noserver 的心智，將更專業的事情交給更專業的人去做，這有助于業務的創新和效率的提升，降低業務上線及迭代周期等，

面臨的挑戰

雖然 Serverless 架構發展迅速，被更多的人認為是真正意義的云計算，甚至在 2020 年的云棲大會上，Serverless 被再次斷言“將會引領云計算的下一個十年”，但是，Serverless 架構仍然面臨著諸多挑戰，

19年 UC Berkeley 的文章“Cloud Programming Simplified:A Berkeley View on Serverless Computing” ：針對 Serverless 架構總結出了下面五項挑戰，

1）Abstraction Challenge
資源需求（Resource Requirement）：通過 Serverless 產品，開發人員可以指定云功能的記憶體大小和執行時間，而無法指定其他資源需求，這阻礙了那些想要控制更多指定資源的人，例如 CPU、GPU 或其他型別的加速器等資源，
資料依賴（Data dependence）：今天的云功能平臺不了解云功能之間的資料依賴性，更不了解這些功能可能交換的資料量，這可能導致次優放置，從而導致通信模式效率低下，

2）System Challenge
臨時性存盤（Ephemeral Storage）：為 Serverless 應用提供臨時存盤的一種方法是使用優化的網路堆疊構建分布式記憶體服務，以保證微秒級的延遲，

持久性存盤（Durable Storage）：與其他應用程式一樣，Serverless 資料庫應用受到存盤系統的延遲和 IOPS 的限制，需要長期的資料存盤和檔案系統的可變狀態語意，
協調服務（Coordination Service）：功能之間的共享狀態通常使用生產者-消費者設計模式，這需要消費者在生產者獲得資料時立即知道，

最小化啟動時間（Minimize Startup Time）：啟動時間包括 3 個部分，一是調度和啟動資源以運行云功能的時間，二是下載應用軟體環境（例如作業系統、庫）以運行功能代碼的時間，三是執行特定于應用程式的啟動任務的時間，例如加載和初始化資料結構和庫的時間，資源調度和初始化可能會因創建隔離的執行環境以及配置客戶的 VPC 和 IAM 策略而產生顯著的延遲和開銷，

3）Networking Challenge
云功能可能會對流行的通信原語（如廣播、聚合和混洗）產生巨大的開銷，

4）Security Challenge
Serverless 架構重新分配了安全責任，將其中許多人從云用戶轉移到云提供商，而沒有從根本上改變它們，但是，Serverless 架構還存在應用程式分解多租戶資源固有的風險，

5）Computer Architecture Challenge
主宰云的 x86 微處理器性能提升速度緩慢，
當然，此處所認為的 Serverless 架構面臨的挑戰相對來說是比較抽象的，就目前的工業界實際情況來看，這些挑戰依舊普遍存在，也是當今眾多云廠商不斷努力的方向，站在 Serverless 開發者角度來說，將上述挑戰與開發者最為關注的幾個問題結合起來，可以認為 Serverless 架構目前所面臨的挑戰包括不限于冷啟動問題、廠商鎖定、配套資源不完善等，

1 冷啟動問題
所謂的冷啟動問題，指的是 Serverless 架構在彈性伸縮時可能會觸發環境準備（初始化作業空間）、下載檔案、配置環境、加載代碼和配置、函式實體啟動完整的實體啟動流程，導致原本數毫秒或數十毫秒可以得到的請求回應需要在數百毫秒或數秒得到，進而影響業務處理速度，

正如前面所說，任何事物都有兩面性，Serverless 架構具備彈性伸縮優勢的同時，相對 ServerFul 架構而言也引入一個新的問題：冷啟動問題，Serverless 架構下，開發者提交代碼之后，平臺一般只會對其持久化并不會為其準備執行環境，所以，當函式第一次被觸發時會有一個比較漫長的準備環境的程序，這個程序包括把網路的環境全部打通、將所需的檔案和代碼等資源準備好，

這個從準備環境開始到函式被執行的程序，被稱為函式的冷啟動，由于 Serverless 架構具有彈性伸縮能力，Serverless 服務的供應商會根據流量波動進行實體的增加或縮減，所以平臺就可能頻繁準備新的環境、下載函式代碼、啟動實體來應對不斷產生的請求，

圖-7 函式計算根據流量進行函式擴縮示意圖
如圖 7 所示，當 Serverless 架構的 FaaS 平臺中某函式被觸發時，FaaS 平臺將會根據具體情況進行實體的復用或者新實體的啟動，

圖-8 FaaS 平臺實體啟動流程簡圖
如圖 8 所示，當有空閑且符合復用要求的實體時，FaaS 平臺將會優先使用，這個程序是所謂的熱啟動程序，否則，FaaS 平臺將啟動新的實體來應對此時的請求，這個程序則是對應的冷啟動程序，

Serverless 架構這種自動的零管理水平縮放，將持續到有足夠的代碼實體來處理所有的作業負載為止，

其中，“新實體的啟動”包括初始化作業空間、下載檔案和配置環境、加載代碼和依賴、函式實體啟動等幾個步驟，相對于熱啟動在數毫秒或者幾十毫秒內的啟動，冷啟動所多出來的這幾個步驟耗時可能是數百毫秒甚至數秒，這種在生產時出現的新實體啟動，并導致業務回應速度受到影響的情況，通常就是大家所關注的冷啟動帶來的影響，如圖 9 所示，

圖-9 函式冷啟動產生示意圖

綜上所述，不難分析和總結出冷啟動問題出現的常見場景，

函式的第一次啟動：函式部署后的第一次啟動，通常是不存在已有實體，所以此時極易出現冷啟動問題，
請求并發：當前一個請求還沒有完成，就收到了新的請求，此時 FaaS 平臺會啟動新的實體來應對新的請求，進而出現冷啟動問題，

前后兩次觸發間隔太久：函式的前后兩次觸發時間間隔超過了實體釋放時間的閾值，也會引發函式的冷啟動問題，目前來看，Serverless 架構所面臨的冷啟動挑戰雖然嚴峻，但并不致命，因為各個云廠商都正在努力推出冷啟動問題的解決方案，包括但不限于實體的預熱、實體的預留、資源池化、單實體多并發等，

2 廠商鎖定
所謂的廠商鎖定，指的是不同廠商開發的 Serverless 架構的表現形式是不同的，包括產品的形態、功能的維度、事件的資料結構等，所以一旦使用了某個廠商的 Serverless 架構，通常意味著 FaaS 部分和相對應的配套后端基礎設施也都要使用該廠商的，若想進行多云部署、專案跨云廠商遷移等將會困難重重，成本極高，

眾所周知，函式是由事件觸發的，所以 FaaS 平臺與配套的基礎設施服務所約定的資料結構往往決定了函式的處理邏輯，如果每個廠商相同型別的觸發器所約定的事件結構不同，那么在進行多云部署、專案跨云廠商遷移時就會產生巨大的成本，

當開發者開發一個功能，在不同云廠商所提供的 Serverless 架構中實作時，涉及的代碼邏輯、產品能力均是不同的，甚至業務邏輯、運維工具等也是完全不同的，
所以想要跨廠商進行業務遷移、業務的多云部署，企業將面臨極高的兼容成本、業務邏輯改造成本、多產品的學習成本、資料遷移風險等，

由于目前沒有完整、統一的且被各云廠商所遵循的規范，不同廠商的 Serverless 架構與自身產品、業務邏輯系結嚴重，開發者的跨云容災、跨云遷移非常困難，目前來看，各云廠商對 Serverless 架構鎖定嚴重的問題也是開發者抱怨最多、擔憂最多的問題之一，

當然就該問題而言，無論 CNCF 還是其他一些組織、團隊都努力在上層通過更規范、更科學的方法進行完善和處理，

3 配套資源不完善
所謂的配套資源不完善，指的是 Serverless 架構的核心思想之一是將更多、更專業的事情交給云廠商來做，但是在實際程序中，云廠商會礙于一些需求優先以及自身業務素質等問題，沒有辦法做更多“在 Serverless 架構中該做的事情”，導致開發者對基于 Serverless 架構開發專案、運維應用程序中困難重重，抱怨不斷，

在 Serverless 架構飛速發展的程序中，各個廠商也在努力完善自身的配套資源和設施，盡管如此，Serverless 架構還是有很多配套資源不完善，并不能讓開發者更順利地完成 Serverless 應用的開發、更輕松地對 Serverless 應用進行運維，主要表現在以下幾個方面，

1）配套的開發者工具復雜多樣，且功能匱乏

一方面表現在市面上開發者工具鏈匱乏，這導致開發和部署難度大，進而增加成本；另一方面表現在缺乏相關的工具鏈在體驗層對 Serverless 體驗進一步提升，優質工具鏈的匱乏導致本來就擔心被廠商系結的 Serverless 開發者變得更難與廠商解綁，

2020 年信通院發布的國內首個《云原生用戶調查報告》明確指出在使用 Serverless 架構之前，49% 的用戶考慮部署成本，26% 的用戶考慮廠商系結情況，24% 的用戶考慮相關工具集完善程度，

這些資料背后透露的實際是：開發者對于完善工具鏈的強烈需求，就目前情況來看，并沒有絕對統一、一致的 Serverless 開發者工具，每個廠商都有自己的開發者工具，而且使用形式、行為表現并不相同，這就導致開發者在開發前的調研、開發中的除錯、部署后的運維等多個層面面臨很嚴峻的挑戰，

另外，絕大部分的 Serverless 開發者工具更多是資源編排、部署工具，并不能真正稱為開發工具、運維工具，尤其在除錯中不能保證線上和線下環境的一致；在運維時不能快速對業務進行除錯，不能保證更簡單地排查錯誤；在定位問題等方面并沒有統一、完整的方案，這就導致 Serverless 架構的學習成本、使用成本對開發者來說會變得非常高，

2）配套的幫助檔案、學習資源并不完善，學習成本過高
就目前情況來看，Serverless 架構的學習資源相對來說是匱乏的，無論從文字、視頻、實驗等角度，還是從廠商提供的案例、教程、最佳實踐等角度，都沒有完善的學習資源和參考案例，正是由于 Serverless 學習資源比較少，開發經驗案例比較少，開發者在學習階段很難找到適合自己的學習資源，開發程序中經常會遇到未知錯誤，嚴重阻塞了 Serverless 架構在開發者側的心智建設，

當然，上述幾個方面也只是 Serverless 架構在配套資源、設施層面不完善的部分表現，除此之外，Serverless 架構如何與傳統框架更緊密地結合；傳統業務如何更容易地遷移到 Serverless 架構；Serverless 架構如何做監控、告警；如何管理 Serverless 應用與 Serverless 資源；Serverless 架構的科學發布、運維的最佳實踐是什么樣子的……這些問題也都是需要研究與探索的，

時至今日，對于 Serverless 架構盡管還有很多的挑戰需要面對，但是大家都在努力希望通過更好的體驗助力用戶將業務代碼更簡單、更快速地部署到 Serverless 架構，例如阿里云 Serverless 團隊開源的??Serverless Devs就是一款無廠商鎖定的 Serverless 應用全生命周期管理工具，

如圖所示，Serverless Devs 可參與到專案的創建、開發、除錯、部署與運維的全流程，以阿里云函式計算組件為例，

圖-10 Serverless Devs 專案全生命周期管理 Serverless 應用示意圖

• 在專案的創建環節，可通過開發者工具或者應用中心進行專案的最初創建，

• 在專案開發環節，可以通過本地開發、除錯等能力來驗證本地開發的正確性，

• 在專案除錯環節，可以通過本地除錯與遠程呼叫、日志查詢等能力進行專案的最終除錯，

• 在專案部署環節，可以先通過依賴安裝、專案構建等流程構建完整的部署包，再進行專案的部署，

• 在后期運維環節，可以通過指標查詢進行專案健康度檢查，通過日志查詢等進行問題定位，通過專案發布等能力進行版本發布、別名發布以及灰度發布等，

除此之外，在學習資源層面也有大力扶持，圖 11 是阿里云開發者社區提供的大量 Serverless 課程，（??2021版技術圖譜）

圖-11 阿里云開發者社區提供的大量 Serverless 課程
后面我們還籌備了“Serverless 實戰攻略”等系列課程，歡迎大家持續關注，

4 其它挑戰
Serverless 架構如今已經非常熱門，各個廠商也都在付諸更大的努力完善自身的 Serverless 產品，推動 Serverless 生態和心智建設，但是客觀地說，Serverless 架構所暴露出的挑戰，并不只有前面所描述的，

1）Serverless 架構在某些安全層面會有更大的挑戰？

把更專業的事情交給更專業的人，讓 Serverless 架構在安全層面有了更大的保障，但是由于 Serverless 架構的極致彈性能力讓開發者產生了更多的擔心，“如果有人惡意對我的業務進行流量攻擊，Serverless 架構的極致彈性和按量付費會不會讓我迅速產生巨大的損失？”這與傳統云主機所表現出的“無法提供服務”是不同的，但是更讓開發者擔憂，

盡管現在很多廠商都在通過 API 網關的白名單與黑名單功能、函式計算的實體資源上限配置等相關功能解決該問題，但仍有很多開發者會有擔憂和顧慮，

2）出現錯誤-難以感知也難以排查？

由于 Serverless 架構相對傳統云主機架構更有“黑盒”即視感，所以在 Serverless 架構下進行應用的開發，往往會出現一些難以感知的錯誤，

例如某些經驗不足的 Serverless 應用開發者在使用物件存盤觸發器時就可能會面臨嚴重的回圈觸發問題，具體為“客戶端上傳圖片到物件存盤，物件存盤觸發函式執行圖片壓縮操作，之后將結果圖片回寫到物件存盤，如果這里的觸發條件設定不清晰，就可能導致回圈觸發壓縮、回寫操作”，除了描述的錯誤難以感知之外，Serverless 架構還存在錯誤難以排查的挑戰，常見的情況是，用戶在本地進行業務邏輯開發并除錯完成，將代碼部署到線上后出現偶然性錯誤，此時由于無法登錄機器進行除錯，并且實體可能在觸發之后被釋放，出現了問題難以定位、難以溯源等挑戰，

綜上所述，與 Serverless 架構的優勢一樣，雖然在前文中已經舉例說明很多 Serverless 架構所面臨的挑戰，但其實一些挑戰也已經有了很好的解決方案，我們這系列文章也會詳細為大家介紹如何解決這些，Serverless 架構雖然面臨的挑戰很多，但也會因為這些挑戰給更多組織、團隊帶來新的機會！

更多內容關注 Serverless 微信公眾號（ID：serverlessdevs），匯集 Serverless 技術最全內容，定期舉辦 Serverless 活動、直播，用戶最佳實踐，

標籤：其他

上一篇：leetcode 1110. Delete Nodes And Return Forest 刪點成林(中等)

下一篇：C語言與嵌入式C語言的區別？