前言

隨著 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 架構流程定義的規範。通過阿里雲函數計算控制檯可以快速進行這個流程的體驗，點選「服務及函數」選項，就可以看到服務列表：

此時可以根據需要，建立服務和函數：

完成之後，可以線上編輯程式碼與線上測試：

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

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

任務

除服務與函數，函數計算還有一個模組：任務。

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

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

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

弱化了服務的概念，可以通過簡單設定，完成任務建立；
本質是函數非同步任務的另一種表達，將非同步任務抽象成一個可以讓開發者快速的建立和釋出任務的功能；

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

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

應用

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

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

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

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

在體驗頁面中，可以體驗當前應用的功能。

應用的出現，無疑是 Serverless 架構多產品逐漸「一起戰鬥」的表現，即開發者對應用進行管理，而不再是對程式碼和資源進行分別的管理。通過應用模組，開發者可以：

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

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

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

Serverless 工作流

Serverless 工作流在一定程度上可以認為是任務模組的一種升級表現。即單純的任務模組是基於函數計算的，是非同步的，Serverless 工作流在此基礎上增加了編排能力：

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

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

在體驗 Serverless 工作流之後，也有一些思考：

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

Serverless Devs

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

工具安裝與設定
專案初始化
專案開發與部署

由於 Serverless Devs 專案是釋出在 Npm 的，所以在安裝之前需要開發者先設定 Node.js 開發環境，再通過 npm 工具進行工具的安裝。安裝完成之後，可以通過 s config命令進行金鑰資訊設定：

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

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

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

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

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

更大的 Scope，留下了更大的想象空間；
是產品聯動的基礎，通過部署編排，元件化模式，讓更多產品聯動；
使用者體驗升級，可以幫助開發體驗阿里雲 Serverless 產品，並基於模板案例，快速上手；

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

所涉及到資源和服務比較多，難以在流水線中進行整體的編排和釋出；
「偽命題：Serverless 不需要使用者關注作業系統等內容」，但是在實際使用過程中，使用者不得不關注系統，因為這會影響專案打包和構建的結果；
由於資源過於零散，環境過於獨立，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：35154841 ），彙集 Serverless 技術最全內容，定期舉辦 Serverless 活動、直播，使用者最佳實踐。

從函數計算到 Serverless 架構

前言