共計 3679 個字符，預計需要花費 10 分鐘才能閱讀完成。
如何淺析基于 Serverless 的前后端一體化框架，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。
概述
Serverless 是一種“無服務器架構”模式，它無需關心程序運行環境、資源及數量，只需要將精力聚焦到業務邏輯上的技術。基于 Serverless 開發 web 應用，架構師總是試圖把傳統的解決方案移植到 Serverless 上，雖然可以做到既擁有 Serverless 新技術帶來的紅利，又能維持住傳統開發模式的開發體驗。但是，Serverless 技術帶來的改變可能不止這些，可能是顛覆整個傳統 web 應用開發模式的革命性技術。
開發模式
業務應用的開發模式發展是從一體到分裂為前后端，再到前后端融合為一體過程。
注意：后面所說的后端特指后端業務邏輯。
早期，一體
沒有前后端的概念，那時候的應用都是單機版，所有的業務邏輯都寫一起，開發人員不需要關心網絡請求，這個時期的工程師完全專注于業務代碼的開發。隨著業務規模的增長，也暴露了很多問題：
高并發問題
高可用問題
說明：業務應用升級困難等一些問題，不是本篇文章所關心，所以就不一一列舉出來。
現在，分裂
前端 + 高可用高并發運維裹挾著的后端業務邏輯：
說明：現在 Serverless 技術已經出現有一段時間了，不但沒有解決開發體驗的問題，反而帶來更多開發體驗問題，所以，在這里我并沒有突出 Serverless 技術。
解決的問題：
高并發。通過分布式部署和多級負載均衡等技術解決了業務的高并發問題
高可用。通過主從架構等技術解決了業務的高可用問題
解決一個問題，帶來一堆問題：
分裂業務應用。為了解決高可用和高并發，業務應用引入了分布式架構，通過負載均衡和主從模式來保證高可用和高并發問題，但是這種解決方案對業務應用是侵入式的，從而導致原本高內聚一體化的應用分裂成前端和后端
污染業務代碼。與高可用、高并發和運維相關的邏輯與后端業務邏輯交織在一起，讓后端技術門檻變高，導致需要多個后端工程師才能掌握所有后端技術
增加聯調成本。前后端的聯調工作做日益繁重，成了工程開發效率提升的瓶頸。新功能和 BUG 需要前后端工程師配合才能完成，你如果是全棧開發工程師，你肯定深有體會，很多 BUG 一看就知道是前端問題，還是后端問題
不匹配的前后端技術發展速度，前端技術發展迅猛，后端技術相對穩定，前端只能被動的去適配后端，讓前端最新的技術在使用體驗上大打折扣。最理想的方式是前后端通盤考量，整體發展，不要出現本來后端只需要優化一行代碼的事，讓前端寫一百行代碼來實現
限制了代碼抽象。因為實現的是同一個業務需求，所以前后端代碼有高度的相關性，如果我們能在前后端代碼之上抽象代碼邏輯，肯定能有很大的作為。同時，代碼的開發和維護也有質的提升，前后端分裂導致我們不得不局限在前端或者后端進行代碼的抽象，抽象出來的代碼可能是片面而重復的
增加技術復雜度。前后端分裂，前后端工程師各自為營，形成各自的技術棧，包括語言、工具和理念，導致單個工程師維護整個業務應用變得極度困難，也讓前后端工程師排斥彼此的技術棧，隨著時間的推移，技術棧差異越來越大，一個項目，不管多小，至少兩位工程師以上，全棧開發工程師另當別論
增加運維成本。需要專門的運維工程師來運維，雖然，現在通過技術手段降低了運維的成本，但是目前運維成本依然很高，難度依然很大
這也是為什么創業小公司喜歡全棧開發工程師，因為在創業早期，高可用和高并發的需求不是那么迫切，因而運維也相對簡單，使用全棧開發工程師，不僅縮短了項目交付周期，而且也降低了公司的運營成本，這對創業小公司是至關重要的。
未來，融合回到到一體
前端 + 后端 + Serverless + 平臺服務 = 業務應用 + Serverless + 平臺服務：
說明：共享邏輯是前后端的共享邏輯，在過去，由于前后端分裂，是很難做到前后端層面的代碼抽象的，前后端融合后，讓這件事變得簡單自然。
帶來困惑：
前后端分工合作，不是很好嗎? 在過去，將一個復雜的問題分解成多個簡單的子問題，高并發和高可用沒法做到不侵入業務應用，這種確實是一種很好的解法，也是沒辦法中的辦法。前后端分工合作帶來的成本問題，越發凸顯。現在 Serverless 透明的解決了高并發和高可用問題，那么我們為什么還需要從技術維度來劃分，我們不是更加推薦按業務維度來劃分嗎?
后端依然很難，駕馭前后端的門檻依然很高? 后端代碼邏輯雖然沒有了高并發和高可用的裹挾，還是會很難，比如 AI。我相信類似這種很難的業務，現在可能有，未來一定會有相關的開發工具包或者平臺服務為我們解決，讓這些很難的技術平民化。難的技術交給專業的人解決。
找回初心：
回歸業務，前后端一體化。隨著 Serverless 技術的出現，解決了高可用、高并發和運維問題，作為工程師的我們是不是應該回頭看看，找回初心：專注于業務代碼。讓原本在一起的后端業務代碼與前端代碼再次融合。因此，前后端一體化難道不是我們失去已久的應用開發終極解決方案嗎?
現狀
Serverless 已經做到了以下兩點：
工程師只需要關心業務邏輯上的技術
擁有接近于傳統應用開發體驗 (解決歷史遺留問題，可能還有些距離)
傳統應用框架，食之無味，棄之可惜：
目前，很多用戶已經感知到了 Serverless 帶來的高可用、高并發和免運維的好處，用戶能夠很自然的想到如果能將現有的開發框架移植到 Serverless 上，那就太好不過了。Serverless 平臺很自然會提供現有框架的移植方案。解決的問題是將傳統的解決方案移植到 Serverless 上，讓用戶在 Serverless 上擁有傳統的開發體驗
應用框架找回初心：
前后端業務邏輯代碼的融合，即前后端一體化
前后端一體化解決了什么問題：
解決了第二階段開發模式中出現的問題，具體請參考：“解決一個問題，帶來一堆問題”。
實現前后端一體化，欠缺如下：
基于 Serverless 的前后端一體化框架
工具
其中，基于 Serverless 的前后端一體化框架解決前后端一體化問題; 工具屏蔽掉 Serverless 平臺細節，提供一致的部署運維體驗。
未來
未來，開源社區會涌現大量的基于 Serverless 的前后端一體化的框架和工具，webassembly 讓前后端一體化打破了開發語言的限制，可以用任意開發語言開發前后端，如 java、go 等等。由于 javascript 是為前端而生，typescript 是目前做活的前端開發語言，前后端統一用 typescript，其他語言可以通過 webassembly 技術讓 typescript 語言來調用可能是最好的選擇。
想要成為一個流行的基于 Serverless 的前后端一體化框架，需要具備這么幾個特質：
開源不綁定
社區化運營
形成標準
模型簡單
結語
Serverless 技術讓我們向新世界大門邁出了左腳，請讓基于 Serverless 的前后一體化框架幫我們邁出右腳。同時，請別再叫我前端開發工程師，我是業務應用開發工程師。
Q A
Q：前后端一體化需要將前后端代碼發布到同一個地方嗎?
A：不需要，分開發布，通過統一的工具負責前后端發布任務，前端可以發到 CDN，后端可以發布到 Serverless 平臺，如：阿里云函數計算。
Q：未來是不是沒有后端工程師?
A：有的。前端工程師只是把前端和后端的業務邏輯代碼給做了，后端工程師去做真正的后端，那時候的后端工程師將會更加專業，前端工程師可能會變成應用開發工程師 (暫且這么稱呼)。對于中小型企業，可能大部分是應用開發工程，有少量甚至沒有專業的后端工程師。
Q：為什么不做一個類似 expressjs 這樣的 web 應用框架?
A：expressjs 框架是在沒有 Serverless 背景下設計的，沒有考慮 Serverless 給我們帶來的技術架構變革，如果需要類似 expressjs 的這樣的框架，我們完全可以將 expressjs 框架遷移到 Serverless 上運行，沒有必要再造一套。
Q：為什么是 nodejs 框架?
A：nodejs 和 前端 js 使用的同一種語言，可以將前后端一體化做到更加極致，webassembly 也可以讓任何語言在前端運行，也能做到前后端語言一致，但是 js 是為前端而生的，更有親和力。但是其他語言可以通過 webassembly 編譯成中間語言，nodejs 通過 vm 來調用其他語言提供的功能。也不排除未來會有一種新的運行環境來取代 nodejs，更加適配多語言和 Serverless 這種場景。
Q：前后端一體化的極致是一種什么感覺?
A：前后端代碼都在一個項目中用同一種語言來寫，在本地定義一個后端接口方法，前端就像調用本地方法一樣調用后端方法 (不是在本地定義的后端接口也是一樣，比如跨組件、外部服務)，前后端可以抽象更多的公共邏輯，比如工具類等等，一個開發人員就能維護好整個項目，沒有了多項目多語言的切換痛苦。
看完上述內容，你們掌握如何淺析基于 Serverless 的前后端一體化框架的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！
