概述
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研發效能的全棧工程師。
本文轉載自雲棲社區。
原文鏈接：