收集一些關于前后端分離的資料菱魔，并做出一些總結，如有不正確之處請指出蝇棉。
前言：
什么樣的場景下讨阻，應該使用前后端分離
? ? ? ? ?很簡單〈垡螅“不需要SEO的場景下钝吮，都應該使用前后端分離”。
? ? ? ? ? 所以在后臺管理中，沒有任何理由不使用前后端分離奇瘦，代指SPA棘催。
? ? ? ? ? 而在前臺頁面中，要認真考慮链患，不支持SEO的代價巧鸭，不止幾百萬。
? ? ? ? ? 前后需要用戶登錄的頁面麻捻，往往是不需要有SEO的纲仍，這里也可以拆解出來。
轉自：https://www.zhihu.com/question/267014376/answer/444793972
什么導致的前后端分離：
實際上是先有了單頁面應用贸毕，才會出現(xiàn)前后端分離郑叠。
單頁面應用可以讓用戶不需要下載 APP，就可以擁有相似的體現(xiàn)明棍。并且與早期的移動網頁相比乡革，擁有更好的體驗，當頁面加載完后摊腋，每打開一個新的鏈接時沸版，不再需要等網絡返回給我結果；我也能快速的回到上一個頁面兴蒸，像一個 APP 一樣的體現(xiàn)這樣的應用视粮。整個過程里，我們只是不斷地從后臺去獲取數(shù)據(jù)橙凳，不需要重復地請求頁面——因為這些頁面的模板已經存在本地了蕾殴，我們所缺少的只是實時的數(shù)據(jù)
什么是前后端分離：
前后端之間使用 JSON 來交流，兩個開發(fā)團隊之間使用 API 作為契約進行交互岛啸。
即后臺選用的技術棧不影響前臺钓觉。當后臺開發(fā)人員選擇 Java 的時候，我可以不用 JSP 來編寫前端頁面坚踩，繼續(xù)使用我的 React 又或者 Angular荡灾。而我使用 React 時，也不影響后臺使用某一個框架瞬铸。前后端分離和微服務一樣卧晓，漸漸地影響了新的大型系統(tǒng)的架構。微服務和前后端分離要解決是類似的問題赴捞，解耦——可以解耦復雜的業(yè)務邏輯，解耦架構郁稍∩庹可要是說相像吧，消息隊伍和前后端便相似一些，通過傳遞數(shù)據(jù)的形式來解耦組件恢着。
前后端分離的助力：
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 前端mv時代：
? ? ? ? ? ? ? ? ? ? ? 1.瀏覽器提供可能性：
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 局部刷新： ajax
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 前端路由： hashchange/history
? ? ? ? ? ? ? ? ? ? ? ? 2.框架及工具支持：
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?框架：vue/react
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 前端路由 vue-router/react-router
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?前端數(shù)據(jù)存儲: vuex/redux
? ? ? ? ? ? ? ? ? ? ? ? ?3.中間層：Node.js
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?環(huán)境：前端開發(fā)者不需要本地起后端環(huán)境
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?聯(lián)調：清晰的對接方式，JSON 實現(xiàn)前后端來說都是比較純粹的
? ? ? ? ? ? ? ? ? ? ? ? ? ? 效益：可漸進式掰派，前期可以將請求全部轉發(fā)后端服務器从诲，而后可以逐步將 Node.js 層作為用戶的直接數(shù)據(jù)交換層
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?職責分明，后端服務化靡羡，Node.js 層處理接口用戶相關的頁面響應 及 數(shù)據(jù)交換
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?可組合性系洛，后端服務化，Node.js 負責組合拼裝略步，實現(xiàn)接口可復用率
? ? ? ? ? ? ? ? ? ? ? ? 4.前后端分工調整為：
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 前端：接收數(shù)據(jù)/返回數(shù)據(jù)描扯，處理渲染邏輯
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?后端：提供數(shù)據(jù)，處理業(yè)務邏輯
轉自：實踐中的前后端分離
前后端分離的好處:
關注點分離? ? ? ? ? ? ? ? ?職責分離? ? ? ? ? ? ? ? ? ?對的人做對的事? ? ? ? ? ? ? ? ? ? ? 更好的共建模式? ? ? ? ? ? ? ? ?快速的反應變化
淘寶前后端分離的實戰(zhàn)歷史：
情景：老子一個人全包了啊啊啊..（獨自搞定哦趟薄，牛逼）
Roles: PM, DBA, RD, FED, Designer, ...
Skills: Linux, MySQL, JAVA, JavaScript, HTML, CSS, ...
Tools: phpmyadmin, photoshop, powerpoint, ...
結果：產品上線了→代碼維護時候就難受呀绽诚。。杭煎。
于是乎：重構恩够！為了更好的未來
下面來，WEB SERVER的架構改造：
后端MVC時代：
前端：那羡铲。蜂桶。我呢？
這時的PM：前端你去套頁面吧犀勒。（恩屎飘，完美的分工。贾费。钦购。）
到了互聯(lián)網時代：根本頂不住了呀
沒辦法呀，前后端一起合作吧褂萧。押桃。
好了，前端的代碼出來了：
項目搞定了导犹，可是前端的問題來了：
? ? ?①前端代碼越來越復雜
? ? ?②無法統(tǒng)一協(xié)作模式唱凯，代碼充滿了約定
? ? ?③JS跟CSS，依賴於後端產出的HTML
? ? ?④有的數(shù)據(jù)來自AJAX谎痢，有的數(shù)據(jù)印在DOM上
? ? ?⑤有的業(yè)務邏輯在前端磕昼，有的在Model層，更多的是在View層
好了节猿，現(xiàn)在揭露本質：
? ? ? ①前后端依舊高度耦合
? ? ? ②前端依賴服務端開發(fā)環(huán)境
? ? ? ③在服務端View層高度耦合
? ? ? ④溝通成本高
? ? ? ⑤職責不清晰
VIEW層誰來維護票从？
? ? ?①前端寫Demo漫雕，后端套頁面
? ? ? ? ? ? ? 后端需要寫HTML
? ? ? ? ? ? ? ?前端仍然確認后端寫的HTML
? ? ? ②前端寫View層，后端只管數(shù)據(jù)
? ? ? ? ? ? ? ?前端需要熟悉后端語言
? ? ? ? ? ? ? ? 前端需要了解后端架構
可是還有問題呢：
? ? ?① 無法良好的支持跨終端
? ? ? ②業(yè)務邏輯散落在應用中
? ? ? ③渲染邏輯強依賴后端頁面
? ? ? ④只能用responsive design硬來
好吧峰鄙，沒什么好的辦法浸间，只能繼續(xù)硬鋼咯。吟榴。魁蒜。。
? ??高度耦合的前后端分工
? ? ? ?①?溝通成本上升
? ? ? ?②維護成本上升
? ? ? ?③無法正確且快速的響應變化
? ? ? ?④代碼的腐爛只是遲早的問題
恩恩吩翻。兜看。
第一次前後端分離大戰(zhàn)爆發(fā)
? 客戶端mv時代出來了：
好了 ，分工吧仿野。铣减。。接口分離, 後端提供數(shù)據(jù), 前端自己搞
MODEL層 - JavScript Object
VIEW層 - JavScript Template
業(yè)界滿坑滿谷的優(yōu)秀方案
Backbone, EmberJS, KnockoutJS, AngularJS, React, etc.
好了脚作，前后端職責清晰了：
后端：提供數(shù)據(jù)? ??處理業(yè)務邏輯? ??Server-side MVC架構??
前端：接收數(shù)據(jù)葫哗，返回數(shù)據(jù)? ?處理渲染邏輯? ?Client-side MV* 架構??代碼跑在瀏覽器上
分離乾淨了，分工明確了球涛，但是：
各層職責重疊劣针，并且各玩各的
Client-side Model 是 Server-side Model?的加工
Client-side View 跟 Server-side是?不同層次的東西
Client-side的Controller 跟 Sever-side的Controller?各搞各的
Client-side的Route 但是 Server-side?可能沒有
性能問題
? ? ?渲染，取值都在客戶端進行亿扁，有性能的問題
? ? 需要等待資源到齊才能進行捺典，會有短暫白屏與閃動
? ? ?在移動設備低速網路的體驗奇差無比
重用問題
? ? ?模版無法重用，造成維護上的麻煩與不一致
? ? 邏輯無法重用从祝，前端的校驗后端仍須在做一次
? ? 路由無法重用襟己，前端的路由在后端未必存在
跨終端問題
? ? 業(yè)務太靠前，導致不同端重復實現(xiàn)
? ? 邏輯太靠前牍陌，造成維護上的不易
SEO問題
? ? ?渲染都在客戶端擎浴，模版無法重用，SEO實現(xiàn)?麻煩
好了毒涧，再來贮预，
第二次前后端分離大戰(zhàn)爆發(fā)。契讲。仿吞。
探討：
重新定義前后端
傳統(tǒng)認知的前后端
是依照?工作職責來劃分的前后端
還是依照?硬體環(huán)境劃分的前后端？
因為有了NODEJS
? ? 我們有機會從工作職責上
? ? ?重新定義前后端的分層
重新定義的前后端
在服務器(JAVA) 與 瀏覽器(JS)的中間
架了一個中間層(NODEJS)
到底什么是node.js呢捡偏？唤冈？？银伟？
? ? ?前端熟悉的語言你虹，學習成本低
? ? 都是JS凉当，可以前后端復用
? ? 體質適合：事件驅動、非阻塞I/O
? ? 適合IO密集型業(yè)務
? ? 執(zhí)行速度也不差
好了好了售葡，開始職責劃分：
實例展示：
淘寶首頁優(yōu)化
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?需求
? ? ? ? ? ? ? ? ? ? 靜態(tài)資料展示，方便運營管理
? ? ? ? ? ? ? ? ? ? ?更好的承載密集且龐大的流量
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?解決方案
? ? ? ? ? ? ? ? ? ? 頁面緩存與定時刷新忠藤，返回緩存資料
? ? ? ? ? ? ? ? ? ? NodeJS產出靜態(tài)頁面到CDN挟伙，定時刷新
淘寶詳情頁優(yōu)化
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?需求
? ? ? ? ? ? ? ? ? ? ? ? ?單日四億PV，頁面數(shù)據(jù)來自各個不同接口
? ? ? ? ? ? ? ? ? ? ? ? ?為了不影響體驗模孩，先產生頁面框架后
? ? ? ? ? ? ? ? ? ? ? ? ?在發(fā)起多個異步請求取數(shù)據(jù)更新頁面
? ? ? ? ? ? ? ? ? ? ? ? ? 這些多出來的請求帶來的影響不小尖阔，尤其在無線端
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?解決方案
? ? ? ? ? ? ? ? ? ? ? ? ? ?在NodeJS端使用?Bigpiper?技術
? ? ? ? ? ? ? ? ? ? ? ? ? 合并請求，降低負擔
? ? ? ? ? ? ? ? ? ? ? ? ? ? 分批輸出榨咐，不影響體驗
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 接口性能優(yōu)化
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?拆分大接口為獨立小接口介却，并發(fā)請求
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?串行 => 并行叔营，大幅縮短請求時間
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 部屬優(yōu)化
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 一臺NodeJS對多臺JAVA服務器
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 合理的分配服務器帶來最大的產出
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 頁面渲染優(yōu)化
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?前后端共享模版? ??首屏服務器渲染
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?次屏瀏覽器渲染? ? ?局部刷新瀏覽器渲染
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?單頁面應用優(yōu)化
? ? ? ? ? ? ? ? ? ? ? 前后端共享路由與模版? ? ? ?前端換頁辩诞，瀏覽器端渲染
? ? ? ? ? ? ? ? ? ? ?直接輸入網址，服務器渲染? ? ?SEO問題迎刃而解
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 可靠性優(yōu)化
? ? ? ? ? ? ? ? ? ? ? ? ? ? 單元測試初斑，頁面測試数焊，回歸測試永淌，持續(xù)集成
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 更多的可能
注：以上內容均為方便個人學習所做的總結筆記，詳情請看原鏈接佩耳，有好建議歡迎留言遂蛀，后續(xù)繼續(xù)補充。干厚。
覺得好的資料：
