作者說
?
在開始本篇內容前我想與各位開發者達成幾個共識，
?
第一個共識，軟體工程沒有銀彈， Serverless 也不是銀彈，它并不是解決所有問題的萬能公式，
第二個共識，Serverless 能夠解決的是運維域的問題，它是解決特定領域問題的一個技術，并不是無限延伸的，與低代碼沒有關系，
第三個共識是復雜度守恒定律-泰斯勒定律（Tesler’s law）?，典型例子就是蘋果，蘋果的產品很容易上手操作，但本質上它整體的復雜度是守恒的，它其實是把復雜的事情留給了系統開發工程師和軟體開發的工程師，讓用戶可以順滑體驗，同理 Serverless 也是如此，把部署 or 運維應用、網站的煩復轉交給了云服務商，但整體的復雜度是不變的，
第四個共識是鄧寧-克魯格效應（The Dunning-Kruger Effect），大家在認知學習程序中，都會出現這樣的發展曲線：從剛開始一無所知，到對新知識的幻想，再到失望的低谷，緩慢爬坡，我們學習任何一個新事物都會經歷這樣一個曲執行緒序，Gartner采用鄧寧-克魯格曲線，來解釋新技術的發展周期，
?
個人認知曲線
Gartern 技術發展曲線
?
作為開發工程師經常會有這種體感，新的技術層出不窮學的很累，Serverless 剛推出來時也一樣，大家對這個技術充滿了無限的想象，當想象到了一個巔峰以后，會慢慢認識到想象與現實的差距，切身去體會在產品中使用時就會掉到技術的低谷，然后再緩慢的爬坡，
Serverless 正當時
?
本文將會通過三個部分，為各位介紹 Serverless：
?
第一個部分是“復雜化 for 云開發商”
第二個部分是“簡化 for 開發者”
第三個部分，會介紹一些我自己和我們團隊使用 Serverless 時的最佳場景，
?
1、復雜化 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對云開發商來說會有vendor-unlock的危機，當所有云服務作為不可變基礎建設，復雜度下沉到K8s層，架構變得通用，因為CNCF的架構整套框架是根據組態檔去遷移的，可以部署在阿里云、也可以騰訊云、亞馬遜的云上，甚至自己搭建的私有云，
?
另外對云服務商來說，他們以前積累的傳統的優勢(虛擬機 laas 層的運維優勢和 Caas 層的平臺級的優勢）就會漸漸失去，所以如果是 vendor-unlock 云服務商之間就會白熱化地打價格戰，看誰能提供更好更便宜的服務，
廣義的 Serverless 是整個云服務商運維體系的 Serverless 化，如傳統提供一個MySQL 或 Redis，必須讓開發者意識到這是跑在服務器上的，需要提供出來個 ip ，但 Serverless 化（Baas 化）后，開發者不需要再去關心這個服務到底是運行在哪里，只需要申明我需要一個DB，應用就可以自動去鏈接并消費DB，
?
狹義的 Serverless 不僅僅是 Severless Computing，還指一個 FaaS 的應用，是由 trigger（也可以歸并為BaaS） + FaaS+ BaaS 的架構組成的，現在云開發商在 Serverless FaaS 的這一層的核心競爭力是不斷推出新的 BaaS 能力，而 BaaS 主要是跟 FaaS 配套去使用的，
上面講到的云服務商的不可變基礎建設，如下圖所示，開發者在最上面這層去部署應用，根本不用關心底層的這些基礎建設，現在云服務商提供的 Baas SDK實際上已經包含在你的這個 FaaS 的runtime里面，開發者只需要把它當成一個函式介面去直接呼叫，不用關心資料庫部署在什么地方、要不要保持長鏈接等等，
?
2、簡化 for 開發者
?
此圖是 Gartner 在 2017 年推出的新興技術發展狀態，當時Gartner覺得 Serverless 還是一個比較新的概念，大家對它的認知還處于爬坡階段；但實際上到今天2021年，Serverless 已經進入了平緩爬升期了，大家對Serverless 可以解決運維域的問題，有哪些邊界的限制等等這些問題已經有了清晰的認知，
?
為什么最近這幾年沒有什么特別新的東西推出了？原因在于 Serverless 這層沒有特別新的概念誕生，大家更多是在做FaaS應用基礎建設，現有的各種Web應用場景場景是否可以Serverless化，比如近期已經支持了的，資料庫 BaaS 化， websocket 支持 FaaS，另外還有很多Web應用場景都是通過諸位的努力慢慢爬坡實作，使其能夠接近理想中的 Serverless ，
2021 年 Gartner 技術采納建議圖
圖中畫框的位置就是 Serverless，綠色代表已經成熟，可以看出，現在的 Serverless 已經是一個比較成熟的技術了，支持大部分Web應用的場景了，所以各位開發者大家可以放心大膽地去嘗試Serverless，
?
(1) 運維領域的 Serverless
?
國內很多人把 Serverless 翻譯成無服務器或者叫無服務，這都不太準確，Severless的反義詞是 Serverful，Severful 的意思是需要特別關注服務器，Serverless 的本質是為了降低心智負擔，不需要十分關心服務器，只專注部署函式就行，至于它怎么運行、底層有多少容器、底層有多少服務器來支撐它，開發者都不需要關心，
傳統的模式的前后端開發模式是由：后端提供資料服務，以前叫 SOA 是面向服務的編程，現在比較流行的是領域驅動微服務，前端消費組裝資料，后端資料介面傳統的方式是提供 HTTP API，到現在的流行的 BFF (Backend For Frontend) 膠水層函式編排，配合微服務提供全量資料，是目前業界比較流行的做法，那么未來的趨勢將會全部 BaaS 化，理想的狀態是前后端一體化模型驅動，不再需要再寫介面，
?
結合 Serverless 做技術變革
Serverless + = ...
?
當下 Serverless 所處的階段的優勢是跟其他領域的技術結合， Serverless 結合其他領域來引爆許多技術變革，例如，傳統的微服務 + Serverless 結合起來后，可以做成 BaaS 化微服務，以前提供一個微服務，是需要開發者去關心這個微服務部署在哪里，但是加上 Serverless 后，便不用管部署在哪里，只需要關心怎么去呼叫即可，LowCode 加上 Serverless 可以讓搭建出來的頁面快速部署并上線；之前的介面函式編排如傳統的 BFF，在未來都可以 Serverless 化，變成SFF（Serverless for frontend），很適合做前后端一體化方案，
?
（2）開發角色的轉變：前后端一體化
Serverless 出現后，未來還會出現前后端一體化的局面，現在已經出現邏輯編排可視化的工具，例如狼叔的 iMove ，目前已經可以做到后端介面的可視化編排，前端工程師去做一個后端的介面編排變得非常簡單，由此可以預見，前端工程師未來的職責可以往后端去延伸，
?
而原來的后端工程師會從傳統的應用部署逐漸轉化去做 BaaS 化服務級別的開發，而未來運維工程師也會更偏向于向云端遷移，這個就是 Serverless 對研發生產鏈路帶來的一系列變革，
3、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 微信公眾號（ID：serverlessdevs），匯集 Serverless 技術最全內容，定期舉辦 Serverless 活動、直播，用戶最佳實踐，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/418110.html
標籤：其他