作者?| 蒲松洋（秦粵）

作者說

在開始本篇內容前我想與各位開發者達成幾個共識。

第一個共識，軟件工程沒有銀彈， Serverless 也不是銀彈，它并不是解決所有問題的萬能公式。

第二個共識，Serverless 能夠解決的是運維域的問題，它是解決特定領域問題的一個技術，并不是無限延伸的，與低代碼沒有關系。

第三個共識是復雜度守恒定律-泰斯勒定律（Tesler’s law）。典型例子就是蘋果，蘋果的產品很容易上手操作。但本質上它整體復雜度是守恒的，它其實是把復雜的事情留給了系統開發工程師和軟件開發的工程師，讓用戶可以順滑體驗。同理 Serverless 也是如此，把部署 or 運維應用、網站的煩復轉交給了云服務商，但整體的復雜度是不變的。

第四個共識是鄧寧-克魯格效應（The Dunning-Kruger Effect），大家在認知學習過程中，都會出現這樣的發展曲線：從剛開始一無所知，到對新知識的幻想，再到失望的低谷，緩慢爬坡。我們學習任何一個新事物都會經歷這樣一個曲線過程。Gartner 采用鄧寧-克魯格曲線，來解釋新技術的發展周期。

個人認知曲線

Gartern 技術發展曲線

作為開發工程師經常會有這種體感，新的技術層出不窮學的很累。Serverless 剛推出來時也一樣，大家對這個技術充滿了無限的想象，當想象到了一個巔峰以后，會慢慢認識到想象與現實的差距，切身去體會在產品中使用時就會掉到技術的低谷，然后再緩慢的爬坡。

Serverless 正當時

本文將會通過三個部分，為各位介紹 Serverless：

第一個部分是 “復雜化 for 云開發商”

第二個部分是 “簡化 for 開發者”

第三個部分，會介紹一些我自己和我們團隊使用 Serverless 的最佳場景。

復雜化?for 云開發商

1) Serverless 架構

Serverless 是一個集大成者，它的整發展歷史是站在巨人的肩膀上的。現在很多云服務商去跑一個函數，底層都是這樣架構。首先 Serverless 的運行底層會有一個 CaaS 層。它是一個 Serverless 化的容器服務，大部分的應用服務都會跑在這一層上面，容器調度現在開源的比較好的解決方案就是 K8s，用 K8s 來調度容器，底層 laaS 就是虛擬機，最底層則是物理機。

CaaS 的實現的方式有很多，Serverless 應用底層必須有 CaaS 服務的支撐。除了Docker 以外，vm 也可以是 CaaS ；例如 Node.js 的 vm 也可以做 CaaS ，webassembly 也可以做 CaaS 等等。另外在做整體架構設計的時候，還需要一個 Component 層去解決網絡東西流量和南北流量的問題，例如 service Mesh 和 ingress 的方案，總體來說 Serverless 背后的架構設計基本都是如此。

2) 云開發商：不可變基礎設施

CNCF 的架構整套框架是根據配置文件去遷移的，可以部署在阿里云、也可以騰訊云、亞馬遜的云上，甚至自己搭建的私有云。當所有云服務作為不可變基礎建設，復雜度下沉到 K8s 層，架構會變得通用。

另外對云服務商來說，他們以前積累的傳統的優勢(虛擬機 laas 層的運維優勢和 PaaS 層的平臺級的優勢）就會漸漸失去。所以如果是 vendor-unlock 云服務商之間就會白熱化地打價格戰，看誰能提供更優質便宜的服務。

廣義的 Serverless 是整個云服務商運維體系的 Serverless 化。如傳統提供一個MySQL 或 Redis，必須讓開發者意識到這是跑在服務器上的，需要提供出來個 ip ，但 Serverless 化（BaaS 化）后，開發者不需要再去關心這個服務到底是運行在哪里，只需要申明需要一個 DB，應用就可以自動去鏈接并消費 DB。

狹義的 Serverless 不僅僅是 Severless Computing，還指一個 FaaS 的應用，是由 trigger（也可以歸并為BaaS） + FaaS + BaaS 的架構組成的。現在云開發商在 Serverless FaaS 的這一層的核心競爭力是不斷推出新的 BaaS （Backend as a Service） 能力，而 BaaS 主要是跟 FaaS 配套去使用的。

上面講到的云服務商的不可變基礎建設，如下圖所示，開發者在最上面這層去部署應用，根本不用關心底層的這些基礎建設。現在云服務商提供的 BaaS SDK 實際上已經包含在你的這個 FaaS 的 runtime 里面，開發者只需要把它當成一個函數接口去直接調用，不用關心數據庫部署在什么地方、要不要保持長鏈接等等。

簡化?for 開發者

此圖是 Gartner 在 2017 年推出的新興技術發展狀態，當時 Gartner 覺得 Serverless 還是一個比較新的概念，大家對它的認知還處于爬坡階段；但實際上到今天，Serverless 已經進入了平緩爬升期了，大家對 Serverless 可以解決運維域的問題，有哪些邊界的限制等等這些問題已經有了清晰的認知。

為什么最近這幾年沒有什么特別新的東西推出了？原因在于 Serverless 這層沒有特別新的概念誕生，大家更多是在做 FaaS 應用基礎建設。現有的各種 Web 應用場景場景是否可以 Serverless 化，比如近期已經支持了的，數據庫 BaaS 化， websocket 支持 FaaS，另外還有很多 Web 應用場景都是通過諸位的努力慢慢爬坡實現，使其能夠接近理想中的 Serverless 。

2021 年?Gartner?技術采納建議圖

圖中畫框的位置就是 Serverless，綠色代表已經成熟，可以看出，現在的 Serverless 已經是一個比較成熟的技術了，支持大部分 Web 應用的場景了，所以各位開發者大家可以放心大膽地去嘗試 Serverless。

1) 運維領域的 Serverless

國內很多人把 Serverless 翻譯成無服務器或者叫無服務，這都不太準確，Severless的反義詞是 Serverful，Serverful 的意思是需要特別關注服務器，Serverless 的本質是為了降低心智負擔，不需要十分關心服務器，只專注部署函數就行，至于它怎么運行、底層有多少容器、底層有多少服務器來支撐它，開發者都不需要關心。

傳統的模式的前后端開發模式是由：后端提供數據服務，以前叫 SOA 是面向服務的編程，現在比較流行的是領域驅動微服務，前端消費組裝數據。后端數據接口傳統的方式是提供 HTTP API，到現在的流行的 BFF (Backend For Frontend) 膠水層函數編排。配合微服務提供全量數據，是目前業界比較流行的做法。那么未來的趨勢將會全部 BaaS 化，理想的狀態是前后端一體化模型驅動，不再需要再寫接口。

2）結合 Serverless 做技術變革

Serverless + = …

當下 Serverless 所處的階段的優勢是跟其他領域的技術結合， Serverless 結合其他領域來引爆許多技術變革。例如，傳統的微服務 + Serverless 結合起來后，可以做成 BaaS 化微服務。以前提供一個微服務，是需要開發者去關心這個微服務部署在哪里，但是加上 Serverless 后，便不用管部署在哪里，只需要關心怎么去調用即可。LowCode 加上 Serverless 可以讓搭建出來的頁面快速部署并上線；之前的接口函數編排如傳統的 BFF，在未來都可以 Serverless 化，變成 SFF（Serverless for frontend），很適合做前后端一體化方案。

3）開發角色的轉變：前后端一體化

Serverless 出現后，未來還會出現前后端一體化的局面。現在已經出現邏輯編排可視化的工具，例如狼叔的 iMove ，目前已經可以做到后端接口的可視化編排，前端工程師去做一個后端的接口編排變得非常簡單。由此可以預見，前端工程師未來的職責可以往后端去延伸。

而原來的后端工程師會從傳統的應用部署逐漸轉化去做 BaaS 化服務級別的開發，而未來運維工程師也會更偏向于向云端遷移。這個就是 Serverless 對研發生產鏈路帶來的一系列變革。

Serverless 的最佳場景實踐

對于 Serverless 使用最近場景的判定，最便捷的方式就是去看云開發商支持哪些 Trigger 事件觸發。

所以目前這個階段，各個云開發商都在不停的增加新的 Trigger。如圖所示，開發人員在寫 FaaS 時，是將 HTTP request 包裝成了 Trigger，可以把 FaaS 函數想象成在封閉的一個包裹里面，要如何喚醒這個包裹，怎么打開這個包裹呢？其實就是通過 Trigger 來喚醒。

另外 Serverless 的現階段，開發語言的重要性沒那么高了，語言只是去實現功能所需要的工具。CNCF 推出來以后 FaaS 就已經是與語言無關的了，那么其實到底是 Node.js，PHP，Python 亦或是其他主流語言的代碼 FaaS 都可以，你甚至可以自建一個鏡像自定義語言和執行環境。因此在 Serverless 后，多語言的優勢我們都可以借用，比如用 Python 去處理 AI 數據，Node.js 去處理高并發網絡 I/O 等等。

1）SFF 數據編排

最佳實踐就是 BFF + Serverless，這在阿里集團內部是十分常見的。由于阿里內部的大多場景后端都是 Java 工程師，前端團隊需要跟工程師去對接，而后端工程師提供的就是 HSF 微服務，可以把它理解為一堆 RPC 接口。以前就是部署一個 Node.js 應用去調接口，拿到數據后對這些數據進行是清洗、處理，放到前端頁面去渲染。但是采用 Serverless 部署 BFF 的 Node.js 應用后，基本不需要考慮跟進流量擴縮容、節省成本等問題。

2）GitOps 模型

GitOps 對于小企業來說，是非常適用的場景，相當于可以自建一套自動發布上線的管道，不再需要像以前一樣，修改一個版本便要測試一遍，目前整個方案已經十分成熟了。Git 本身支持大量的 hook 函數，所以打造這樣一個流程也是非常容易的。需要關注的是要結合云開發商的能力，比如阿里云發布流程便十分自動化，在云下平臺發布上線后可以支持線上的流量錄制、回放。

3）小而美的技術團隊

最后一點是打造小而美的團隊。在我的認知中，技術架構有個強大制約就是：組織架構會決定我們的技術架構。

就像前后端分離，大多是因為組織架構定義了：前端有前端的領導，后端有后端的領導，所以就會產生前端由前端的開發，后端由后端的開發，需要中間去聯調基于 API溝通。那我們如果要想打造一個小而美的團隊怎樣打破這個隔閡呢？

Serverless 一個比較適合的場景就是，通過前端的服務編排 SFF 將解決掉中間 API溝通的問題，后端去提供全量的服務即可。這種變革會迫使后端去做微服務化，甚至后端研發采用 Serverless 去做 BaaS 化，這是反向的導推過程。如果我們的前端團隊掌握了 Serverless， 有三個優勢：前端的數據編排便不再需要再找后端工程師了；GitOps 解決部署運維，可以降低前端心智負擔；前端同學能夠專心抽象業務模型。

講師簡介：

蒲松洋，花名秦粵。極客時間《Serverless 入門課》作者。Serverless 和 Node.js 布道者，目前負責阿里巴巴前端委員會標準化小組，低代碼小組–中后臺搭建，Node.js 應用微服務架構。在微服務、Serverless 以及中臺項目中有著豐富經驗。

戳??此處??，可觀看 Serverless Meetup 深圳站回放！

總結

以上是生活随笔為你收集整理的从运维域看 Serverless 真的就是万能银弹吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。