前後端分離為什麼出現？本質上是什麼？前後端分離運動對 web 應用的架構帶來了怎麼樣的變化？前後端分離怎麼分離？為什麼是 Node.js? 前後端分離的未來怎樣？
阿里前端技術專家剪巽老師在今年 7 月 ArchSummit 大會深圳站上探討了這個話題。
前後端分離走過了一段歷程，最根本的原因是傳統的後段服務支撐不了現代化的前端開發。平時工作中用到的工具鏈、開發框架、規範協議、瀏覽器等在不斷湧現，這些新的技術在給開發環境、開發流程提了更多新需求。Node.js 在這個背景下能夠把這些工具串聯起來。
前後端分離的 3 個階段
1.模板層的分工
最早的 Java 開發階段需要一個包含所有內容的 war 包，整個前端的編排，像 HTML 頁面、CSS、JS 很多時候包含在 HTML 頁面，也會出現腳本複用、樣式複用抽離出來。所以前端開發當時是圍繞著名的 velocity 模版。這一層最大的問題是，後端的同學看前端資源像看天書，前端同學看後端
模版也像是看天書，融合效率非常低。2.靜態資源獨立部署
Web 2.0 之後，大量的前端資源需求出現，Web 前端體驗最大的改進就是副客戶端，客戶端資源非常龐大，代碼不再是直接發佈到線上，而是要編譯，做預處理，可能還要做 CDN 的加速。整個應用被分割成兩部分，後端服務發佈之後，前端服務要獨立更新，這樣就給應用的更新帶來了便利。這裡存在一個問題是接口的協調，前端的需求變更，數據的要求也會變化，需要後端去協調資源的編排。另外一個問題是測試，前端持有腳本，樣式資源，而模版卻在應用層，應用層的開發、發佈也是很複雜的。
3.獨立應用層
這一層的變化在於，Node.js 可以提供工具能力之外，還具備很強的服務能力，從 mock 數據開始，到前端代碼的預編譯，資源編排，這些動作都合併到一個應用裡面，前端形成 UI 應用層。後端相關的接口回退到 API，或者雲端。在這一層，前端具備了更靈活、強大的能力，在數據編排這一層，Node.js 可以做輕量的粘合，服務端的開發也在往微服務方向發展，提升了開發效率。
為什麼是 Node.js
在語言特性方面，Node.js 無需切換，整個開發、工具、日常工作中 Node.js 一種語言就可以滿足所有需求。此外 Node.js 還有優異的性能，一直在迭代。
其次是在社區生態上，在語言模塊包上的貢獻數據，NPM 庫的數據量很高。Node.js 能從服務端框架去鏈接服務，整合成前端所需數據資源。
另外在生產周邊，Node.js 的語言成熟度很有優勢，社區裡關於洩漏、性能調優的工具也有很多研究，對前端開發更友好。
產品中的實踐：
通常大數據服務裡，需要解決計算和存儲能力。業務曾有很多的需求，從數據接入，到離線處理，到實時分析，所以它的特點是有很多的依賴，而前端無法做到相應每一個需求，大量需要 mock。
另外就是業務的需求很多，在流程控制、數據轉換、數據安全、分析展現等方面需要有大量的組件沉澱。最大的特點是有眾多獨立的功能模塊。
而要想讓這些模塊和功能實現有什麼解法呢？就需要這三個方法：制定框架，微應用分割，運維工程化。
1. 定製應用框架就是來解決前端的編譯，工程管理，數據 mock 等問題。
面向應用的時候，更多的是在第二層和第三層做定製化封裝，把業務插件都封裝起來。應用層在運行過程中，前端會託管所有權限相關的事情，包括登錄系統，中間件等等。此外還會連接很多服務和驅動，把前端框架集成起來，這是一個完整的開發環境。
2. 把各自獨立的模塊應用切割成微應用，一個微應用解決一個問題，便於分工和隔離處理。
具體做法是微服務拆分，搭建微應用服務，承載大量的小服務，同時也會出現很多域名的問題，很多訪問入口。這裡做了一些小創新，在入口可以定義端口，sever name，訪問 path，當把一個場景分成 10 個應用發佈，發佈之後再根據不同的路徑拼接成一個應用，對體驗沒有影響。
除了路由自動化規劃之後，對應用的發佈做到上下平滑，不會影響流量。前端人員自己打包發佈就可以了。
3. 當這些應用被分割的很細緻之後，隨之而來的是如何管理這些小應用。
比如有兩臺機器做互備，把所有小 App 都發布到上面之後，由一個個小顆粒組成一個大應用，看上去很像一個蜂巢，因此命名 honeycomb，這些蜂巢組成一個大蜂窩，完成一個主功能。在應用推進過程中，有些應用壓力大，需要把應用集群隔離開，把有不同業務需求場景環境，例如開發環境、預發環境、線上環境隔離開來，不同環境配置的集群資源和機器數量都不一樣。隨著業務發展，隔離的事情會教給容器去執行。
分層設計解決 Node.js 密集計算問題
社區裡有一個討論，Node.js 是否適合密集計算？密集計算分成兩層，綠色部分會接收用戶請求，第二層淺藍色會處理用戶請求，寫很多的 processor，提供大量的進程去提供密集計算。主要問題在於 CPU 容量是恆定的，當有很多併發請求的時候，如何保證在服務層去很好的分配計算任務。拆成兩層之後，保證用戶請求不會被 block 掉。如果第一層大量的密集計算，會導致用戶的請求或者連接的需求被擋住，接收不到響應，所以要往後堆，做成隊列，可擴容的大集群。整個結果在 Java 裡就可以理解為 Java 龐大線程的處理過程。
社區裡在線程庫裡還有一些嘗試，Napa.js 是微軟開源的線程庫，前端同構的需求可以探索使用 Napa.js 這個工具。
DataV 場景使用案例
DataV 是一個可視化產品，類似於 PPT，有編輯器，最主要的功能是把各種組件掛到瀏覽器屏幕上，組件和組件之間形成事件綁定，事件驅動組件去調用數據服務，數據從計算層返回。
它的特點之一是，數據請求量非常多，請求排隊之後，要把數據合併起來，在服務器端請求太多數據源會出現慢的情況，導致請求駐留在服務器端，內存的波動會很嚴重。這裡的解決方案是先到先返回。另外一個是在提供組件自定義開發功能的時候會遇到代碼轉換的需求，我們是在線幫助用戶轉代碼，這裡存在很多動態編譯的過程，以及數據處理。
Node.js 應用層帶來的便捷
Node.js 在這個場景下是有很多優勢的，例如在 server 層可以更便捷的去完成這些開發以及支持，Babeljs 可以做代碼轉換的事情，Bigpipe 可以優化服務端的內存，可以縮減渲染時間，提升體驗優化。在前面的數據流裡有很多的 filter，給數據鏈中插入 processor，來定義處理微小的數據。用戶在原始的數據到完整的可視化展現不需要再搭建一個產品去支持，只需要搭幾個 filter，配幾個數據源，拖幾個組件就可以完成。Node.js 在這一層提供了很多便捷之處，例如創新實現。
所以，Node.js 在微應用體系裡有很多優勢，開發、測試、運維可維護性上有獨立性。Node.js 給前端帶來創新的便利性也體現在另外一點，那就是在雲端的一些服務上，前端有能力在 service 集成、改變使用流程做很多事情。
前端接下來的變化
尤其是協議上，HTTP2/WebSocket 會在更多的場景裡帶來不同的體驗。
還有前後端同構、WebGL、WebWorker、工具鏈的繼續進化，前端的工具、資源編排、框架等都在快速變化。
而服務端趨勢：
- 雲化（更細粒度的虛擬化）
- 服務化（API、可編程）
- 智能化（數據智能普及）
- 編排（微服務、微應用運維便捷）
閱讀更多 程序猿猩球 的文章
