淺析基於 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：先後端代碼都在一個項目中用同一種語言來寫，在本地定義一個後端接口方法，前端就像調用本地方法同樣調用後端方法（不是在本地定義的後端接口也是同樣，好比跨組件、外部服務），先後端能夠抽象更多的公共邏輯，好比工具類等等，一個開發人員就能維護好整個項目，沒有了多項目多語言的切換痛苦。

---

本文做者：木香丘

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。