這些天對前后端做了一個全面的研究，給大家分享下前后端分離應用的倆種模式，以及如何應用到實際場景，以及他落地的注意點；
一定要看后面的：分離模式團隊工作流程，在這我標明了平時工作中要注意的點哦，不然你工作起來一樣會很累的。
這是我在大漢集團任職產出的東西。感謝大大工匠雲平台
現狀
前后端分離開發已經成為行業標准。
他主要是通過web服務器(Nginx || Nodejs ...) + 應用服務器（Tomact ...）前后兩個服務端進行有效解耦而達到前后端分離的效果。
技術核心思想：前端通過js創建HTTP請求調用后端服務的Restful API接口並返回JSON數據進行交互
web服務器：一般指像Nginx，Node這類的服務器，他們一般只適合解析靜態資源和處理一些簡單的控制以及業務邏輯；
應用服務器：一般指像Tomcat，Jetty這類的服務器可以解析動態資源也可以解析靜態資源，但解析靜態資源的能力沒有web服務器好；
他存在的主要目的就是把項目的開發工作做到更細化，更專業化。
前后端分離模式也是讓前端這個職位快速崛起的原因之一。
發展史
以前的程序員沒有前后端之分，所有項目基本都是一個程序員既當爹又當媽的，一把全包了，最多分配一個頁面仔配合后端工作。期間很多企業慢慢發現隨着市場的發展，客戶端的體驗達不到要求。必須要請專人來做客戶端這塊的體驗優化，而那時候還沒這類專業人士（或者說是珍稀物種）那請一個成本可不小。
這時公司領導就找當時的程序員談話了，想要他們接下這活，但發現他們大都嫌棄這活又臟又累，不嫌棄的也是有心無力。
正當領導愁容未展的時候，一回頭正好與我們頁面仔正那雙充滿了愛意，充滿了渴望的小眼神四目相對。就這樣確認過了眼神，遇到了對的人。從此頁面仔就歡樂的開始了他的逆襲之路，前端工程師的職業也就由此而生了。
那前端工程師與后端工程師的職責要區分，工作要解耦，不能有太多的相互依賴，干擾。所以前后端分離模式就以此得到了盛行。
前后端的開發模式
不分離模式
這個模式就不過多分析了；
這個模式有兩個缺點：
代碼耦合嚴重，前端HTML中代碼會出現后台代碼。前端要會后台的模板引擎，且模板多樣化。人員流動成本過高
項目耦合嚴重前后在一個項目里。前端開發完全需要依賴后端項目，如果后台出現問題會導致前端處於等待狀態
半分離模式
工作流程：
1、打開web，加載基本資源，如CSS，JS等；
2、發起一個Ajax請求再到服務端請求數據，同時展示loading；
3、得到json格式的數據后再根據邏輯選擇模板渲染出DOM字符串；
4、將DOM字符串插入頁面中web view渲染出DOM結構；
以上工作流程都是在用戶設備上逐步執行，也就是說客戶端的運行速度完全取決於用戶的設備。如果用戶的設備越低端，打開頁面的速度也就越慢。
為什么說是半分離，主要是因為Controller沒放在前端層，前后端需要溝通頁面是同步輸出呢，還是異步JSON渲染？如果需要同步輸出的頁面，只能放服務端，那又退回去了。所以只能說是半分離。
半分離的優點：
1、代碼不耦合，前端后端代碼不會有任何穿插；
2、前端開發不依賴於后端服務，可以專注客戶端開發。還可以通過模擬數據數據實習前后端並行開發；
3、可以精准定位問題，是前端問題還是后端問題；
半分離的缺點：
1、seo問題，搜索引擎無法爬取到頁面的異步數據
2、客戶端響應速度不可控；在json數據量返回較大時，數據處理邏輯復雜時，渲染慢，會出現卡頓的情況
3、資源消耗嚴重，業務復雜時頁面可能會需要多個請求才能渲染完畢。這個在移動端體現比較突出
全分離模式
全分離，其實就是在web服務器這里添加一層可以做簡單邏輯處理的服務器。
所以全分離的開發模式是：
前端：負責View和Controller層做簡單的參數控制，數據轉換。
后端：負責DB和Service層，做業務/數據處理等。
但是前端怎么寫Controller呢？難道又要前端學JAVA PHP？那不又是成本加高?這時候nodejs就派上用場了，node.js適合運用在高並發、I/O密集、少量業務邏輯的場景。重要的是前端就不需要新學一名新語言可以快速上手了。
其實全分離模式本質只是在工作職責上做了分工。技術層面是又回到了不分離的原點。
增加中間層的工作職責如下圖：
全分離的優點
1、后端服務的適配提升；一個應用要對應輸出pc、mobile、app的時候。后端服務就不需要為各端寫兼容代碼了。統一由前端的web服務器處理即可，維護起來更安全有效率；此時架構應該如下圖：
2、減少在客戶端處理數據的邏輯代碼，提高客戶端響應速度；
3、減少客戶端資源浪費，需要多HTTP才能拼裝好的頁面可以在內網一次拼好，再返回給客戶端
4、可以借助node服務器渲染，解決seo問題。
分離模式的團隊工作流程：
按照流程圖，我們的工作步驟應該如下：
步驟一、我們從需求評審的時候要求就是所有參與成員必須參加。
步驟二、溝通，協議制定階段；（這階段的第1、2小步一定要做好，不然影響第三大步的開發工作）
1、會后前端應該需要先跟UI溝通，設計稿的大概框架，頁面效果實現的注意點；
2、前后端制定契約（接口文檔），這個應該需要詳細到每個字段的描述；
3、測試編寫測試用例
第三步、開發階段
1、前端根據接口文檔，模擬API接口進行前端的開發工作（根據跟UI的溝通寫大概的布局架構的設計，簡單的業務邏輯開發。一定要等UI設計稿完全交互后再進行詳細的業務邏輯編寫）；
2、后端開發后端服務，並按照文檔輸出數據即可；或文檔有修改一定要通知到下游的前端；
3、測試編寫測試代碼，如果后端接口開發完畢，前端還未開發聯調完。測試可以先開始接口測試；
第四步、聯調
第五步、整體測試，第六步、交付上線
從上面看我們的流程在第二，三步都是串聯進行的。這樣會大大提高我們的開發效率。
但這會有一個小缺點，就是：如果改了之前相關約定的東西，一定要通知到相關人員！！
如果改了之前相關約定的東西，一定要通知到相關人員！！
如果改了之前相關約定的東西，一定要通知到相關人員！！
重要的事情說三遍!!!!!
總結
分離模式的缺點：
溝通成本相對增高，需要團隊更緊密和諧的配合，對團隊要求相對增高；
職責精細化，需要的人力成本相對增高；
分離模式的優點
1、提高服務端質量；（服務端不再需要兼顧煩雜的前端處理工作。專心做后台框架和業務開發，進行更精准的單元測試）
2、提高客戶端訪問性能；（騰出空間讓前端做各種專業的性能優化）
3、提高項目可維護性；（前端代碼規范化，模塊化，讓前端邏輯清晰明了）
4、提高開發效率；（項目解耦，減少前后端相互等待時間。實行並行開發）
5、減少重復工作；（如果需支持要多端應用，服務端接口基本可以共用）
6、動靜態資源解耦，減少應用服務器的並發、負載壓力；（所有靜態資源可使用CND分發，提高訪問效率體驗）;
7、提高解決問題效率；（發現bug，可以快速定位是誰的問題，不會出現互相踢皮球的現象。頁面邏輯，跳轉錯誤，瀏覽器兼容性問題，腳本錯誤，頁面樣式等問題，全部由前端工程師來負責。接口數據出錯，數據沒有提交成功，應答超時等問題，全部由后端工程師來解決。雙方互不干擾）
落地注意點
1、需求評審；（前后端，測試，UI必須參加，並提供出測試用例）
2、接口文檔制定；（開發前，前后端必須一起制定出詳細的接口文檔，輸出數據格式，包括字段名，這點非常重要！不然前端會重復返工！）
3、測試工作；（為提高項目進度效率，測試可以在服務端開發完接口后進行一波有效的接口測試。讓開發測試並行，減輕后面整體測試的壓力和時間。）
4、關於選型；(至於選擇全分離還是半分離，完全根據當下業務來判斷，如果需要多端應用的、頁面場景邏輯復雜，並且代碼可放服務端處理多的、要做SEO的又這些業務的都可以采用全分離的模式的。)
這次分享差不多久這些，如有其他疑問或者更好的理解歡迎在評論區留言討論。謝謝！！
這次的分享資料也參考了：https://blog.csdn.net/fuzhongmin05/article/details/81591072