作者：秋雨陳（本文轉載自”函式計算征集令“征文）

前言

隨著 Serverless 架構的不斷發展，各云廠商和開源社區都已經在布局 Serverless 領域，一方面表現在云廠商推出傳統服務/業務的 Serverless 化版本，或者 Serverless 計算平臺，另一方面表現在開源社區中 Serverless 相關專案逐漸豐富起來，無論是平臺類還是工具類的開源專案，再或者是框架類的開源專案，都如雨后春筍般快速成長，

任何技術，在這樣繁榮發展背后，都會快速升級和迭代，Serverless 架構也不例外，從阿里云的 FaaS 產品發展程序中，不難看出 Serverless 架構在提效和降本的道路上不斷的場景化，特色化；在產品形態上也不斷的趨于完整化，統一化，雖然距離“大道至簡”還有一定的距離，但是也只是時間的問題了，

從思想到產品升級

Serverless 架構在不斷發展，無論是產品形態還是技術架構都可以用日新月異來描述，

Serverless 精神的更迭

最初，Serverless 架構指的是 FaaS 與 BaaS 的結合，認為開發者可以不用花費更多的精力在服務器等底層資源上，而是可以將精力放在更具價值的業務邏輯之上，這也是文章《Serverless Architectures》中所強調的觀點，

但隨著時間發展，大家發現，對于 Serverless 架構這樣的描述過于單薄，沒有凸顯出 Serverless 架構為業務帶來的技術紅利，也沒能表現出 Serverless 所交付的心智，所以 UC 伯克利在《Cloud Programming Simplified: A Berkeley View on Serverless Computing》中對 Serverless 架構進一步的定義：對于被認為是Serverless 架構的服務/產品還需要具備按量付費和彈性伸縮的特點，并認為， long-run 的運行模式并不符合 Serverless 精神，

云計算相關技術的發展，往往有一個特點：云廠商的驅動性非常強，因為云廠商往往會最先感知到普遍性的用戶需求，并且有足夠的資料支撐其做出合理的判斷與創新，所以 Serverless 架構的創新很多時候也都是由廠商驅動的；在事件驅動與函式計算的發展下，廠商逐漸發現函式計算的模式“短時運行”沒有辦法滿足更多用戶的訴求，此時一種 long-run 模式的 Serverless 計算服務就逐漸的被范訓出來了，至此，Serverless 架構也從最初的單薄，逐漸完善，通過“自我革新”，完成了新一輪業務能力的自我豐富與產品功能的自我完善，

隨著 long-run 模式逐漸被開發者們認可，傳統 Serverless 架構的定義有點“格格不入”：既不能在模式上覆寫最新的 Serverless 產品緯度，也不能在形態上描述清 Serverless 的特性，此時 Serverless 架構定的義，就自然而然的得以升級，例如：

• Serverless 應該是 FaaS + BaaS + CaaS，
• Serverless 應該是 FaaS + BaaS + Others，
• Serverless 就是 Server+Less，即服務端免運維/低運維的形式就是真正意義上的 Serverless 架構，

至此，Serverless 架構實作了此階段下的產品形態升級與 Serverless 精神的更迭，

從函式到更 Serverless

通過阿里云官網，不難發現其 Serverless 產品形態還是相對完整的：

• 計算平臺：從函式計算到容器鏡像再到微服務形態；
• 基礎產品/服務：存盤產品、資料庫等產品的 Serverless 形態；

Serverless 架構的熱度不斷增加，各產品也需要借著熱度進一步突破和創新，所以 Serverless 這個詞“被亂用”再所難免；每個團隊都有自己的特色，基于 Serverless 架構完善和更迭自身能力，也是產品發展的必經之路，就像資料庫發展到云資料庫，再發展到云原生資料庫，再發展到 Serverless 資料庫一樣；

所以，Serverless 架構需要一個“粘合劑”，將各種 Serverless 產品進行進一步的鏈接，使其不是“混雜在諸多產品中的某些產品”，而是“可以聯合起來解決某個問題的具體功能”，換句話來說將不同的產品聯合到一起，以應用的維度為開發者提供場景化支持，這也是 Serverless 架構從資源朝著應用，再朝著業務發展的必經之路，

阿里云推出“應用的概念”，試圖以計算平臺和核心，通過BaaS 產品的聯動，讓本來“雜亂的花園”，逐漸的變得規矩，有條理起來；讓本來需要開發者“痛苦的選擇”，逐漸的變成場景化推薦，流程化引導，

產品與功能體驗

本次活動是阿里云 Serverless 函式計算評測，所以本文僅對函式計算與其相關產品進行體驗，包括函式計算本身（包括三個主要模塊：基礎模塊服務與函式和上層封裝模塊應用、任務），Serverless 作業流以及開源專案 Serverless Devs，

函式計算

服務與函式

函式與服務的功能如下圖所示：

函式計算產品形態為兩層結構：服務、函式，

• 服務：一種邏輯關系，表示的是一系列函式以及部分公共配置的集合；即帶有特定屬性的函式集合；
• 函式：一種確切的資源或業務邏輯；由代碼，觸發器以及相關的配置組成；

函式計算的兩層概念為開發帶來了一定的便利：

• 業務劃分更清晰：可以讓開發者更清晰的將同型別業務/功能劃分在一個服務下，不僅讓頁面更清晰，也會讓管理（包括資源分配，權限劃分，賬單等）更便利；
• 讓環境劃分更簡單：通過服務將業務進行歸類之后，有助于基于服務進行環境的劃分，通過服務進行不同環境的劃分，相比針對函式進行環境的劃分會更便利和更容易被接受；

函式計算的上手流程相對簡單，通過函式計算檔案，可以看到整體流程：

即，開發者只需要完成代碼的開發和部署，即可實作業務的彈性伸縮和按量付費能力的夾持，這也符合 CNCF 在白皮書中對 Serverless 架構流程定義的規范，通過阿里云函式計算控制臺可以快速進行這個流程的體驗，點擊“服務及函式”選項，就可以看到服務串列：

此時可以根據需要，創建服務和函式：

完成之后，可以在線編輯代碼與在線測驗：

至此，完成了函式計算上手，在整個程序中，有幾個明顯的感覺：

1. 從零上手流程還是比較順利的，只要多關注標注資訊，有一些研發經驗，是可以快速的創建服務與函式的；
2. 函式計算功能相對來說是全面的，包括單實體多并發，預留，版本&灰度，可觀測性等，可以滿足絕大部分的應用場景，即便某些框架因 Serverless 架構喪失了部分特性，也可以通過產品側所提供的能力解決；
3. 可觀測性相對來說很完整，從 trace、log、metrics 等幾個方面入手，可以滿足開發者在可觀測上大部分需求，另外值得好評的是控制臺頁面的實時日志功能，對開發除錯很有幫助；日志搜索功能有待加強，例如若想快速找出日志前后文還需要進一步依賴日志服務等；
4. WebIDE 很強大，通過計算資源的分配可以在線進行代碼撰寫和專案構建，但是 WebIDE 的環境和函式計算的環境依舊是不通的，不仔細研讀和體驗，會被誤會在 WebIDE 中的除錯即是在函式環境下的除錯；
5. 函式計算所特有的 HTTP 函式，可以輕松地將 Web 應用遷移部署到 Serverless 架構，但是 HTTP 函式和時間觸發器沒辦法一同配置；
6. 函式計算的環境變數沒有 Secret 能力；環境變數往往涉及到敏感資訊，能否加密輸出是安全性的一種表現；
7. 函式計算有很多代碼目錄是被限制讀寫的，但是并不是所有運行時都會被限制讀寫，這種不對齊會讓開發者產生比較大的疑惑，盡管其他廠商也多是這樣設計的，但是卻沒人說這樣設計的原因；
8. 函式計算從服務到函式，再到可觀測、自定義域名等模塊，擁有較多功能/配置，目前在使用程序中難以快速找到部分功能，例如經常會找不到預留實體的配置入口等；

任務

除服務與函式，函式計算還有一個模塊：任務，

在任務頁面的描述匯總，不難看出它實際上是函式的一種變形：

通過創建任務的程序，以及創建任務結束頁面：

同樣可以驗證剛剛的想法：任務的本質依舊是函式計算，只不過：

• 榷訓了服務的概念，可以通過簡單配置，完成任務創建；
• 本質是函式異步任務的另一種表達，將異步任務抽象成一個可以讓開發者快速的創建和發布任務的功能；

由于任務往往是異步的，所以從上游經過函式的處理再傳遞到下游，整個鏈路的串聯是非常重要的，這也是對云廠商服務一致性與可觀測性的一種考驗，

通過對任務的體驗，整體感覺是比較順暢的，通過抽象出來的產品化能力，讓任務的創建流程和步驟更加精簡，可以幫助“特定的開發者快速使用”；但是也會對一些新手用戶產生困擾：應用、任務、服務及函式是什么關系？任務和函式有什么區別？

應用

與任務相同的是，應用也是建立在服務與函式之上的；與任務不同的是，應用不僅僅是函式計算，可以認為，應用是函式計算中，聯動其他產品的入口或者 Serverless 應用的管理平臺，

通過應用創建頁面，可以快速體驗 Serverless 應用：

可以看到，應用與任務，服務及函式的很大區別在于，應用是場景化非常明確的一個模塊，所有的創建程序和匯入的程序均是在建設“場景化”的心智，通過應用創建頁面，可以看到目前已經有框架、音視頻處理等多個場景的應用，以其中的圖片壓縮為例進行體驗：

可以通過引導快速完成應用創建，整個流程最為精簡，創建完成之后，可以得到最終的體驗頁面：

在體驗頁面中，可以體驗當前應用的功能，
應用的出現，無疑是 Serverless 架構多產品逐漸“一起戰斗”的表現，即開發者對應用進行管理，而不再是對代碼和資源進行分別的管理，通過應用模塊，開發者可以：

1. 快速體驗 Serverless 架構；便于學習和調研 Serverless 架構；
2. 可以進行資源聯動，并以應用緯度對資源進行管理，對權限進行劃分，對業務進行運維；

值得注意的是，應用功能默認有一套標準的 GitOps 配置，通過基于代碼倉庫進行應用部署之后可以發現應用本身是基于 Serverless Devs 開發者工具實作的，這也充分的將線上平臺與線下工具進行聯動，在一定程度上可以進一步保證開發者使用體驗的一致性，另外，在體驗應用模塊之后，會產生一些想法：

1. 作為產品聯動入口，應用模塊需要牽扯其他資源投入，如何保證應用模塊的資源可以逐漸的“自運營”將會成為應用模塊能否成功的關鍵點之一（所謂自運營指的是不需要某固定團隊主動提升應用數量、質量，而是可以由更多參與者自發的去做這項作業）；
2. 應用模塊在一定程度上應該屬于 Serverless 而不僅僅是函式計算，否則過小的 Scope 會限制該模塊的持續發展與生態演進；
3. 作為擁有標準 GitOps 配置的應用，目前 CI/CD 能力過于單薄；
4. 功能不完善，創建后的使用體驗有待加強，例如，部署后的“如何應用”的引導、可觀測要如何去做 ......

Serverless 作業流

Serverless 作業流在一定程度上可以認為是任務模塊的一種升級表現，即單純的任務模塊是基于函式計算的，是異步的，Serverless 作業流在此基礎上增加了編排能力：

通過 Serverless 作業流夾持的任務將會：

• 具有服務的編排能力；
• 支持長時間運行流程；
• 可進行流程狀態管理；

在體驗 Serverless 作業流之后，也有一些思考：

1. 與應用模塊一樣，如果 Serverless 作業流定義的 Scope 過小，可能只是函式計算的編排，會讓這個功能喪失很大的競爭力；
2. 作業流的整體體驗是比較順暢的，如果可以將功能持續優化，作業流的易用性會更高；

Serverless Devs

關于阿里云 Serverless  Devs 上手，可分為三個流程：

1. 工具安裝與配置
2. 專案初始化
3. 專案開發與部署

由于 Serverless Devs 專案是發布在 Npm 的，所以在安裝之前需要開發者先配置 Node.js 開發環境，再通過 npm 工具進行工具的安裝，安裝完成之后，可以通過 s config命令進行密鑰資訊配置：

可以通過s init命令，進行案例代碼的初始化：

完成初始化之后，可以直接進行業務的部署：

部署完成后，可以通過瀏覽器打開專案，進行預覽：

同樣基于這三個流程，Serverless Devs 也是可以快速的與常見的流水線進行集成，目前官方提供的案例包括Github Action，Gitee Go，Jenkins，以及云效等，但是閱讀過相關檔案后，不難發現，即便是其他的流水線，也是同樣的操作流程，

Serverless Devs 開發者工具針對阿里云 Serverless 架構來說，其最大的意義和價值，應該就在于：

1. 更大的 Scope，留下了更大的想象空間；
2. 是產品聯動的基礎，通過部署編排，組件化模式，讓更多產品聯動；
3. 用戶體驗升級，可以幫助開發體驗阿里云 Serverless 產品，并基于模板案例，快速上手；

從開發角度來看，Serverless Devs 開發者工具解決了 Serverless 領域常見的幾個痛點：

1. 所涉及到資源和服務比較多，難以在流水線中進行整體的編排和發布；
2. “偽命題：Serverless 不需要用戶關注作業系統等內容”，但是在實際使用程序中，用戶不得不關注系統，因為這會影響專案打包和構建的結果；
3. 由于資源過于零散，環境過于獨立，Serverless 架構除錯復雜度非常高；

下一代Serverless探索

用戶體驗相關

進一步的“統一”

天下大同也許是不可能的，但是技術發展的結局，趨于同質化卻是一種趨勢，
Serverless 架構同樣如此，在云原生技術日益發展的今天，Serverless 架構已經不再是單純的某個產品或者某種形態，他應逐漸的發展成為一種思想，
基于 Serverless 架構所傳遞的精神，已經有越來越多的 Serverless 產品出現，盡管如今，他們依舊是“單打獨斗”的多，但隨著時間的發展，這些產品注定會以一種”粘合劑“為核心，統一的，一致的為開發者提供服務，

從加法到減法

雖然 Serverless 架構并沒有確切的定義，但他所要傳達的心智卻一定不是更復雜，
所以在未來的發展程序中，Serverless架構的發展方向之一，就是做減法，減掉那些”看似合理，卻又沒有道理的能力“，例如，為什么要透露出各種實體型別（彈性實體、GPU實體、性能實體、按量實體等）？為什么需要配置預留，需要配置彈性策略？
也許，很多為什么現在看來是合情合理，但是站在另一個維度上，他可能就是不合理的，所以做減法，不僅僅是一種勇氣，更是一種對技術的挑戰，對產品抽象能力的挑戰，

功能探索

云開發模式

Serverless 架構的下一站是什么？這是一個很多人思考的問題，
函式計算僅僅是一個計算平臺，可以單打，但也不能獨斗，想要更容易被接受，資源的聚合、聯動是必不可少的，盡管函式計算的應用模塊，在一定程度上正在聯動更多資源，但是這也僅僅是管理層面的，開發者所接觸Serverless 架構后，開發也是非常重要的一環節，那么云開發模式就值得考慮，

低代碼模式

Serverless 架構在一定程度上是可以讓很多功能模塊化的，而模塊化的進一步發展，就可能是低代碼模式，
基于 Serverless 架構的低代碼有望將 Serverless 思想應用到產品建設思想上，模塊化的快速部署、更新，平穩發布與下線也都是符合 Serverless 思想的，

總結

Serverless架構，在未來將會像云主機，容器服務一樣，成為云計算時代新的基礎設施；在對基礎設施的維護的基礎上，為開發者提供更為場景化的服務有望成為 Serverless 架構突破自我瓶頸的突破口，

在未來，Serverless 將會是一種“形態不統一，但是目標很統一”的技術架構思想，開發者可以以一種更為一致性的體驗，快速使用 Serverless 架構構建自己的場景化應用，當然這里的Serverless包括了不同形態的服務，例如資料庫、網關、函式計算等，

綜上所述，Serverless 架構在不斷的發展，Serverless 架構的精神也在不斷的更迭，從函式計算到應用，從開發、運維到全生命周期，Serverless架構要回答的問題很多，要做的事情更多，

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

標籤：其他

上一篇：強烈推薦一款優秀且通用的后臺管理系統

下一篇：API 與 SDK 之間的區別