如何分析Serverless的優(yōu)勢、意義與應(yīng)用，針對這個問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
創(chuàng)新互聯(lián)公司從2013年成立，先為鄧州等服務(wù)建站，鄧州等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為鄧州企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
Serverless 是炙手可熱的技術(shù)，被認(rèn)為是云計算發(fā)展的未來方向。尤其是在前端研發(fā)領(lǐng)域，使用 Node 開發(fā)云函數(shù)，可以讓前端工程師更加專注于業(yè)務(wù)邏輯，實現(xiàn)全棧工程師的角色轉(zhuǎn)變。
技術(shù) Leader 和架構(gòu)師在進(jìn)行技術(shù)選型時會關(guān)注很多指標(biāo)， Serverless 貢獻(xiàn)最大的就是 研發(fā)交付速度（Time to Market） 和 成本（Cost）。
研發(fā)交付速度方面，衡量的指標(biāo)是 Time to Market，是從需求產(chǎn)出到上線所用的總時長，Serverless 在這方面的優(yōu)勢在技術(shù)和團(tuán)隊協(xié)作兩個視角上均有體現(xiàn)。
一是技術(shù)視角。有一種觀點稱 Serverless 是一種很簡單的技術(shù)，我對這種觀點并不完全同意。Serverless 架構(gòu)讓用戶和底層架構(gòu)的關(guān)系發(fā)生了變化，之前開發(fā)者需要關(guān)注核心業(yè)務(wù)邏輯、運(yùn)維和底層架構(gòu)的治理，在 Serverless 架構(gòu)中底層的部分由 Serverless 架構(gòu)提供方來解決。從整個應(yīng)用系統(tǒng)的角度來看，系統(tǒng)架構(gòu)的難度和復(fù)雜度并沒有實質(zhì)簡化。
這里我們不展開講 Serverless 架構(gòu)的底層實現(xiàn)細(xì)節(jié)。只需要了解一點：Serverless 底層架構(gòu)做的事情越多，業(yè)務(wù)層面需要關(guān)注的架構(gòu)和運(yùn)維工作就越少，因為做的工作少了，所以交付的時間就更快了。
**二是團(tuán)隊協(xié)作視角。在 Serverless 的模式下，全棧開發(fā)的工作模式會執(zhí)行得更加順暢。**我們知道，前后端分離確實是一種很好的架構(gòu)模式：細(xì)化了分工，降低了耦合，提升了復(fù)用。但隨之而來的問題，是團(tuán)隊間的溝通成本、KPI 目標(biāo)的差異所帶來的各種催排期、接口確認(rèn)以及聯(lián)調(diào)測試。不少技術(shù)團(tuán)隊用全棧開發(fā)的模式來解決這些問題， Serverless 下不需要在架構(gòu)和技術(shù)?；ㄙM(fèi)過多精力，Runtime 和語言也沒有強(qiáng)制依賴，而是完全面向業(yè)務(wù)，每個前端工程師都可以是全棧的。
另一個優(yōu)勢就是 Serverless 會大大降低成本，體現(xiàn)在計算資源和人力兩個層面。
在計算資源的成本方面，主要體現(xiàn)在彈性擴(kuò)縮容量，按需付費(fèi)。在傳統(tǒng)的計算資源預(yù)算時，往往為了能抗住峰值流量，系統(tǒng)容量都有 Buffer，說白了就是日常的浪費(fèi)。
在 Serverless 模式下，當(dāng)業(yè)務(wù)代碼上線后，一分錢都不需要支付。只有當(dāng)真實請求和流量過來了，平臺才會根據(jù)請求量，瞬時拉起對應(yīng)數(shù)量的函數(shù)實例，去接收請求和執(zhí)行業(yè)務(wù)代碼，此時才需要為真正的代碼執(zhí)行所消耗的資源付費(fèi)。**No Pay for Idle ，從會計學(xué)的角度，Serverless 讓計算資源從固定成本變成了可變成本。**這種付費(fèi)模式對于那種流量波動很大的業(yè)務(wù)優(yōu)勢明顯。
還要說明的是人力成本。很多技術(shù) Leader 總抱怨人手不夠，也許真實情況并非如此，只是沒有足夠比例的人投入到業(yè)務(wù)功能的開發(fā)和迭代上，而是去做了架構(gòu)、底層等必要的支撐性工作。我承認(rèn)這些工作確實非常有挑戰(zhàn)、非常必要，也非常重要。在 Serverless 模式下，由于不再需要關(guān)注底層架構(gòu)，所以縮小這部分的工作量和人力占比，就有了更多的工程師可以放在核心業(yè)務(wù)上，多做迭代，從而加速產(chǎn)品功能的研發(fā)。這不是更高的 ROI 嗎？
Serverless 適用于事件觸發(fā)的場景。當(dāng)某個事件發(fā)生時，拉起并調(diào)用 Serverless 云函數(shù)，比如文件上傳、消息隊列中的消息事件、定時器事件，也可以是 IoT 設(shè)備的某個事件。還可以用于一些文件處理，比如圖像處理、音視頻處理和日志分析等場景。
當(dāng)然，這些事件也包括 HTTP 請求事件，這是 Serverless 的一個很大的適用場景—— HTTP Service，主要實現(xiàn)基于 HTTP 應(yīng)用的后端服務(wù)，比如 REST API、BFF 和 SSR 服務(wù)，以及業(yè)務(wù)邏輯的實現(xiàn)。
我主要關(guān)注 Serverless 在 HTTP 場景下的應(yīng)用。這也是和前端工程師結(jié)合最緊密的部分。小到為小游戲、運(yùn)營活動提供后端的支持，大到整個 App 或站點的 REST API、BFF，或是 H5 頁面的 SSR，都是 Serverless 適用的場景。
Serverless 的諸多優(yōu)勢業(yè)內(nèi)有很多討論，也有不少文章談及。我想聚焦到前端開發(fā)者身上來說一說，**Serverless 能夠幫助前端工程師實現(xiàn)真全棧的夢想。**可能有人會質(zhì)疑，為什么你又提出一個真全棧，和之前的全棧有什么區(qū)別嗎？
我先明確一下真全棧的定義：如何判斷一個工程師是真全棧工程師？
當(dāng)公司有了一堆產(chǎn)品功能需求，招了一個程序員張全占，如果他能從 0 到 1 把需求做成產(chǎn)品，那才叫真全棧。如果張全占完成了前端功能開發(fā)、后端開發(fā)以及數(shù)據(jù)庫開發(fā)，實現(xiàn)了所有的需求功能，并且部署到對應(yīng)的服務(wù)上，就完事了，那么問題也就來了：服務(wù)掛了誰來重啟？環(huán)境穩(wěn)定性誰來做？日志把磁盤寫滿了誰來清理？定時任務(wù)怎么搞？產(chǎn)品突然火爆了，流量一夜間突然擴(kuò)大了十幾倍的時候（產(chǎn)品經(jīng)理狂喜中），誰負(fù)責(zé)擴(kuò)容？這些問題雖然不是核心業(yè)務(wù)需求，卻是每一個線上產(chǎn)品都必須考慮的東西，否則只能稱為功能集合，不能稱之為產(chǎn)品。
Serverless 架構(gòu)的出現(xiàn)，將剛才說到的一些非核心業(yè)務(wù)邏輯，以及運(yùn)維相關(guān)的事情給“屏蔽”了。前端工程師張全占只需關(guān)注前臺功能、后臺功能和數(shù)據(jù)這些核心的業(yè)務(wù)邏輯，就可以獨立做出產(chǎn)品。例如目前的微信小程序云開發(fā)就是 Serverless 式的，開發(fā)者完全不用關(guān)注底層架構(gòu)。
Serverless 對前端工程師群體來說是一個機(jī)會。讓一個前端工程師能夠得到獨立負(fù)責(zé)某些產(chǎn)品研發(fā)的機(jī)會，完成某些產(chǎn)品從需求到上線的從 0 到 1 的機(jī)會，一個回歸到互聯(lián)網(wǎng)研發(fā)工程師角色的機(jī)會。我希望所有的前端工程師都有機(jī)會成為 Serverless 工程師，有機(jī)會獨立負(fù)責(zé)研發(fā)整個產(chǎn)品。
總體上來說，采用 Serverless 不需要工程師大量的學(xué)習(xí)和準(zhǔn)備過程。
Serverless 本身就是在現(xiàn)有的架構(gòu)中做減法，減去那些服務(wù)器的管理和配置工作。當(dāng)然在具體落地的時候，還是有一些準(zhǔn)備工作要做：
首先是明確目標(biāo)，開發(fā)者在了解 Serverless 之后，應(yīng)該去思考對于自身業(yè)務(wù)和開發(fā)架構(gòu)，采用 Serverless 是為了解決什么問題？想取得哪方面的提升？沒有一種技術(shù)是為了用而用，都是針對具體場景解決具體問題。這是第一個需要搞明白的。
明確了目標(biāo)之后，接著是 Serverless 模式下架構(gòu)的一些設(shè)計工作。與傳統(tǒng)的開發(fā)模式一樣，系統(tǒng)設(shè)計的工作量是根據(jù)業(yè)務(wù)的復(fù)雜程度決定的。對于復(fù)雜業(yè)務(wù)邏輯來說，在開發(fā)之前需要明確有多少個云函數(shù)，每個云函數(shù)的輸入輸出定義、采用哪些 BaaS 后端服務(wù)，都需要提前設(shè)計規(guī)劃好。
特別要說明的是，這些設(shè)計和非 Serverless 并沒有什么本質(zhì)上的不同，Serverless 云函數(shù)也不是神秘莫測的。簡單理解，它所提供的就是一個語言的 Runtime。在非 Serverless 架構(gòu)下如何執(zhí)行的代碼，Serverless 架構(gòu)下還是那樣執(zhí)行。如果業(yè)務(wù)是基于 Express 或者 koa 這類應(yīng)用框架，那么 Serverless 云函數(shù)下，還是直接使用這些框架即可。
最后是一些實施上的準(zhǔn)備，以騰訊云函數(shù)為例，只要是寫過代碼的，花小半天時間閱讀一些基礎(chǔ)文檔、教程，或者是跟著 Demo 走一遍，就可以立刻開始寫代碼，幾乎沒有什么門檻和不同。要敲黑板強(qiáng)調(diào)的是，別忘記了工程化和 CI/CD 方面的考慮，尤其是和現(xiàn)有研發(fā)流程的結(jié)合。這塊有一些小小的工作量，畢竟是開發(fā)模式的升級，但基于云函數(shù)提供的 CLI 和 SDK 都很容易實現(xiàn)。
Serverless 架構(gòu)由兩部分構(gòu)成，分別是 FaaS（Functions as a Service）和 BasS（Backend as a Sevice）。其中 FaaS 就是指云函數(shù)，它是一種新的算力組織和提供方式，它讓用戶不再需要關(guān)心服務(wù)器的管理和配置，只用專注于核心業(yè)務(wù)邏輯業(yè)務(wù)代碼的編寫。BaaS 指的是一些服務(wù)化的后端功能，包括數(shù)據(jù)庫 / 對象存儲、賬戶權(quán)鑒、消息隊列、社交媒體整合和 AI 能力等，這些服務(wù)和接口在 FaaS 層使用相應(yīng)的 SDK 或 API 來連接和調(diào)用。
FaaS+BaaS 的組合，構(gòu)成了 Serverless 無服務(wù)器架構(gòu)，免除了所有運(yùn)維性操作，讓企業(yè)和開發(fā)者可以更加專注于核心業(yè)務(wù)的開發(fā)，實現(xiàn)快速上線和迭代，把握業(yè)務(wù)發(fā)展的節(jié)奏。
由此可見，云函數(shù)是 Severless 架構(gòu)中的算力部分，是實現(xiàn) Severless 架構(gòu)的基礎(chǔ)計算資源。在 Severless 架構(gòu)下的業(yè)務(wù)系統(tǒng)中，因業(yè)務(wù)功能、需求場景不同，所需的 BaaS 后端服務(wù)也可能各不相同，但業(yè)務(wù)邏輯都需要通過云函數(shù)來實現(xiàn)。
剛才也提到 Serverless 本身有很多很多的應(yīng)用場景，這個問題在不同的 Serverless 的場景下，答案也是不同的。
如果業(yè)務(wù)需求是基于類似于 Express、koa 的應(yīng)用框架來實現(xiàn)的，那么在設(shè)計上，基本沒有任何區(qū)別。Serverless 云函數(shù)可以很好地支持這些應(yīng)用框架，只是部署方式不同而已。
如果需求場景不需要任何應(yīng)用框架，直接使用原生代碼，在 Serverless 架構(gòu)下進(jìn)行設(shè)計時，需要以函數(shù)為粒度來考慮，將函數(shù)作為業(yè)務(wù)中的最小功能單元。
還有一個場景使用 Serverless 和不使用就有很大的不同——企業(yè)上云。
現(xiàn)在很多企業(yè)應(yīng)用都做應(yīng)用上云，上云其實是一件非常有技術(shù)門檻的事情?？赡苄枰显频拇a只有幾百行，但傳統(tǒng)上云絕不是上傳部署幾百行代碼那么簡單（估計很多工程師看到 Kubernetes 那幾本厚書的時候就已經(jīng)快瘋了）。這個過程需要專業(yè)的、有經(jīng)驗的工程師，花費(fèi)大量的工作，才能把業(yè)務(wù)系統(tǒng)遷移到云上。
Serverless 下的體驗就非常不同，因為無服務(wù)器架構(gòu)，所以不需要關(guān)注虛機(jī)或者容器配置和治理工作，基本上只用上傳代碼就完成了上云。
從以往的歷史來看，技術(shù)的演化還是存在一些一般規(guī)律的。
首先我預(yù)測 Serverless 生態(tài)一定會趨于繁榮。一個技術(shù)很有優(yōu)勢，相關(guān)的社區(qū)貢獻(xiàn)，以及周邊的支持就越強(qiáng)大，用的人就越多；用的人越多，這個技術(shù)就越火，類似于經(jīng)濟(jì)學(xué)里的有效市場理論。最近 Serverless 的發(fā)展很快，可能大家看到這篇內(nèi)容的時候，我們的 Serverless DB 產(chǎn)品已經(jīng)發(fā)布了，就是開發(fā)者連數(shù)據(jù)庫的存在都不需要關(guān)注了。Serverless 的使用者會越來越多，同時生態(tài)里的貢獻(xiàn)者也會更多，整個生態(tài)也會更加繁榮。
第二個方向是 Serverless 的標(biāo)準(zhǔn)化。當(dāng)生態(tài)繁榮之后，對于標(biāo)準(zhǔn)化的需求就變得非常強(qiáng)烈了。國內(nèi)外各家云都有了自己的 Serverless 解決方案，對開發(fā)者隱藏了底層基礎(chǔ)設(shè)置。但是各家的接口、實現(xiàn)還是不一樣。試想一下，開發(fā)者在國內(nèi)云上用 Serverless 實現(xiàn)的代碼，在做國際化的時候，要遷移到另一個云廠商，卻發(fā)現(xiàn)完全無法平滑遷移是什么感受？公司內(nèi)兩個技術(shù)團(tuán)隊如何在 Serverless 的架構(gòu)下復(fù)用功能和代碼？如何能夠用統(tǒng)一的標(biāo)準(zhǔn)或者框架來構(gòu)建應(yīng)用？Serverless 開發(fā)需要一些標(biāo)準(zhǔn)，或是某一種框架來適配各個云廠商之間的不同實現(xiàn)和接口，很可能是 Serverless 接下來的發(fā)展方向。
關(guān)于如何分析Serverless的優(yōu)勢、意義與應(yīng)用問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。
重慶分公司
重慶分公司
