Serverless 架構應用開發流程

UC Berkeley 認爲 Serverless 架構的出現類似於四十多年前從彙編語言轉向高級語言的過程，在未來 Serverless 架構的使用將會飆升，或許服務器式雲計算不會消失，但是服務器式雲計算將是爲了促進 BaaS，以爲更好的爲 Serverless 架構提供支持，未來十年，Serverless 架構將會逐漸向取代 Serverful 的方向發展。

作爲一種新的計算範式，在逐漸取代 Serverful 的過程中，也意味着新的開發流程在逐漸地興起，隨着時間的發展，基於 Serverless 架構進行應用開發將會形成一套無服務器開發思路，這種應用開發流程將會比傳統架構更簡單。

Serverless 架構下的應用開發流程

由於 Serverless 架構傳遞的 Noserver 的心智，即並不需要開發者付諸更多的精力關心服務器等底層資源，所以在一定程度上，Serverless 架構下的應用開發流程相對來說更簡潔。

圖 1.21 函數部署流水線示意圖

在 Serverless 架構下進行應用開發，通常用戶只需要按照規範編寫代碼，構建產物，然後部署到線上即可。如圖 1.21 所示，CNCF Serverless Whitepaper v1.0 中認爲函數的生命週期從編寫代碼並提供規範元數據開始，一個 “Builder” 實體將獲取代碼和規範，然後編譯並將其轉換爲工件，接下來將工件部署在具有控制器實體的集羣上，該控制器實體負責基於事件流量和 / 或實例上的負載來擴展函數實例的數量。

圖 1.22 函數創建 / 更新流程示意圖

如圖 1.22 所示，函數創建和更新的完整流程爲：

1. 在創建函數時，提供其元數據作爲函數創建的一部分，將對其進行編譯使其 -

   • 具有可發佈的特性。接下來可以啓動、禁用函數。函數部署需要能夠支持以下用例：事件流（Event streaming）：在此用例中，隊列中可能始終存在事件，但是可能需要通過請求暫停 / 恢復進行處理。

   • 熱啓動（Warm startup） ：在任何時候具有最少實例數的函數，使得所接收的 “第一” 事件具有熱啓動，因爲該函數已經部署並準備好爲事件服務（而不是冷啓動），其中函數獲得通過 “傳入” 事件在第一次調用時部署。

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

3. 用戶可能希望直接執行 / 調用函數（繞過事件源或 API 網關）以進行調試和開發過程。用戶可以指定調用參數，例如所需版本，同步 / 異步操作，詳細日誌級別等。

4. 用戶可能想要獲得函數統計（例如調用次數，平均運行時間，平均延遲，失敗，重試等）。

5. 用戶可能想要檢索日誌數據。這可以通過嚴重性級別、時間範圍、內容來過濾。Log 數據是每個函數級別的，它包括諸如函數創建和刪除，警告或調試消息之類的事件，以及可選的函數的 Stdout 或 Stderr。優選每次調用具有一個日誌條目或者將日誌條目與特定調用相關聯的方式（以允許更簡單地跟蹤函數執行流）。

以阿里雲 Serverless 產品爲例，如圖 1.23 所示

• 生產環境中開發 Serverless 應用的流程可以認爲是，當開發者想要開發一個項目的時候，通常只需要根據 FaaS 提供商所提供的 Runtime，選擇一個所熟悉的編程語言，然後進行項目開發、測試（圖中步驟 1）；

• 完成之後將代碼上傳到 FaaS 平臺（圖中步驟 2）；

• 上傳完成之後，只需要通過 API/SDK（圖中步驟 3）或者一些雲端的事件源（圖中步驟 3）觸發上傳到 FaaS 平臺的函數；

• FaaS 平臺就會根據觸發的併發度等彈性執行對應的函數（圖中步驟 4）；

• 最後用戶可以根據實際資源使用量進行按量付費（圖中步驟 5）。

圖 1.23 Serverless 工作流程

與 Serverful 應用開發流程對比

在上文中，通過對 Serverless 架構的特點以及其所交付的心智分析，得到結論 “在一定程度上，Serverless 架構下的應用開發流程相對來說更簡潔”，本節將會通過生產環境下的案例，對傳統架構下應用開發與 Serverless 架構下應用開發具體區別進行舉例對比。以一個 Web 應用爲例：

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

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

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

• 在 Serverless 應用形態下，移除了最初應用中的身份驗證邏輯，換用一個第三方的 BaaS 服務（步驟 1）；

• 允許客戶端直接訪問一部分數據庫內容，這部分數據完全由第三方託管，這裏會用一些安全配置來管理客戶端訪問相應數據的權限（步驟 2）；

• 前面兩點已經隱含了非常重要的第三點：先前服務器端的部分邏輯已經轉移到了客戶端，如保持用戶 Session、理解應用的 UX 結構、獲取數據並渲染出用戶界面等等。客戶端實際上已經在逐步演變爲單頁應用（步驟 3）；

• 還有一些任務需要保留在服務器上，比如繁重的計算任務或者需要訪問大量數據的操作。這裏以 “搜索” 爲例，搜索功能可以從持續運行的服務端中拆分出來，以 FaaS 的方式實現，從 API 網關（後文做詳細解釋）接收請求返回響應。這個服務器端函數可以和客戶端一樣，從同一個數據庫讀取產品數據。原先的搜索代碼略作修改就能實現這個搜索函數（步驟 4）；

• 還可以把 “購買” 功能改寫爲另一個 FaaS 函數，出於安全考慮它需要在服務器端，而非客戶端實現。它同樣經由 API 網關暴露給外部使用（步驟 5）；

圖 1.26 傳統雲主機架構下進行應用的開發和上線流程簡圖

在傳統雲主機架構下進行應用的開發和上線，可以認爲是如圖 1.26 所示，當開發者完成代碼開發之後，需要進行上線前的準備，包括不限於資源評估、服務器購買、操作系統安裝、服務器軟件安裝等，完成之後再進行代碼部署，部署完成之後還需要有專業的人或者團隊，對服務器等資源進行持續監控和運維等，例如流量突然提升，需要進行服務器的平滑擴容，流量突然降低，需要服務器的平滑縮容等。但是在 Serverless 架構下，整個開發模式卻發生了比較大的改變。

圖 1.27 Serverless 架構下進行應用的開發和上線流程簡圖

結合上文某電子商務網站與圖 1.27 爲例，在上述應用開發上線流程中，Serverless 架構開發者實際關心的也就只剩下函數中的業務邏輯，至於身份驗證邏輯，API 網關以及數據庫等原先在服務端的一些產品 / 服務統統交給雲廠商提供。在整個項目開發、上線以及維護的過程中，用戶並不需要關注服務器層面的維護，也無需爲流量的波峯波谷進行運維資源的投入，這一切的安全性、彈性能力以及運維工作都交給雲廠商來統一處理 / 調度，用戶所需要關注的就是自己的業務代碼是否符合自己的業務要求，同時 Serverless 架構下，用戶也無需爲資源閒置進行額外的支出，Serverless 架構的按量付費模型以及彈性伸縮能力、服務端低運維 / 免運維能力，可以讓 Serverless 的用戶的資源成本、人力成本、整體研發效能得到大幅度提升，讓項目的性能、安全性、穩定性得到極大地保障。

綜上所述，與傳統架構應用開發流程的區別有明顯區別的是，Serverless 架構所主張的讓開發者將更多精力關心自身的業務邏輯，並強調 Noserver 的心智，可以在一定程度上讓應用的開發、部署流程縮短，將更專業的事情交給更專業的人去做，有助於業務的創新效率提升，降低業務上線、迭代週期等。

文章來源：Go Serverless（ID：go-serverless）

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/_qqOegQzaBJ6WQRgcLSUXA