隨著微服務技術的盛行，前後端分離體系越來越受到各企業的青睞。
如果你不懂前後端分離技術就出去面試，還真不敢投簡歷。之前的單體項目，一個工程師能把功能從頁面擼到後臺業務邏輯，甚至幹到數據庫層面，簡直就是一個全棧工程師。在前後端分離時代，前端工程師無論從團隊的人員配備上，還是技術框架層面都和後端工程師處在了同一個水平線上。
前後端分離技術催生了前端工程師的需求量
這種前後端分離體系的出現，既在開發模式上發生了改變，又對團隊和項目管理產生了影響，更對系統的架構和技術處理提出了挑戰。
但對於用戶而言，他們根本不明白也不關心繫統的底層實現。不過用戶在日常訪問系統時，常常會遇到頁面雖然可以展示和操作，但是會遇到返回請求失敗、或者操作異常、或者無法連接到服務器的提示！更壞的情況會出現操作無響應，甚至頁面直接報錯誤代碼的問題。這其實就是前後端分離系統中沒能很好處理好一些關鍵的基本技術點，導致系統不夠健壯，從而造成用戶體驗很不友好。
所以作為前後端分離系統的開發人員，我們需要注意和做好哪些最基本的問題才能避免這些常見問題的出現呢？基本的框架平臺又要做好哪幾點才能保證系統的基本運行呢？下面我們一一來介紹下。
通信協議與HTTP狀態碼
前後端分離系統中最核心的問題是什麼？我想前後端的通信交互就是首要問題了。不僅後端間的微服務間涉及到通信，前後端的系統交互更是頻繁。
常用的通信協議有RPC、SOCKET、WEBSOCKET、RMI、HTTP、WEBSERVICE等通信協議。其中RPC、WEBSERVICE又是基於HTTP協議的，前後端的交互一般基於應用層，所以HTTP協議成為其交互的一大選擇。 HTTP協議是前後端交互的首選
如今，基於HTTP協議的一些工具類和程序包已經幫我們封裝好了請求實現，我們可以基於其API來操作前後端的請求和響應。這時系統間交互的狀態和結果就成為我們重點關心的問題，如果處理不好，則無法實現前後端系統的正常交互，那麼系統自然也就無法正確地執行了。
因此，想要做好系統的前後端分離，HTTP的狀態碼就成為必須掌握的知識點！下面我們就來總結下HTTP的幾大狀態碼及其意義，這有助於我們處理系統的響應和排查問題的定位。
常見的狀態碼有：
- 200，這是請求成功的響應，代表了本次請求得到了服務器的成功響應
- 301，這是url重定向，代表你請求的網址被永久的重定向到另一個網址
- 401，這是未授權的響應，一般在有權限控制的系統中需要獲得權限才能訪問
- 403，這是禁止訪問，直接告訴請求者訪問被拒絕，最終還是權限的問題
- 404，這是用戶最常見的一種狀態碼，代表了你所訪問的內容找不到
- 500，這是最頭疼的狀態碼，代表了服務器端的錯誤，服務器端錯了，該功能基本就不能執行了
404錯誤狀態碼
其實，HTTP的狀態碼上面常見的幾種，還有很多更詳細的值代表了更具體的請求響應，但是總體可以概括在以下幾類：
- 1XX，信息類狀態碼，代表請求被接受，需要繼續處理。
- 2XX，成功類狀態碼，代表請求成功並被處理。
- 3XX，重定向類狀態碼，代表需要進一步操作才能完成請求。
- 4XX，請求錯誤類狀態碼，代表客戶端不正確的參數或者請求導致的錯誤。
- 5XX，服務端錯誤類狀態碼，代表了服務器端出現了異常或錯誤，導致請求無法正確響應。
掌握以上HTTP狀態碼的知識點，在前後端分離的系統開發、調試和測試中才能更好更快地定位和處理問題，更重要的是在實際編程中根據狀態碼的返回，合理地處理問題才能保證程序的健壯，友好地提示，才能有更好的用戶體驗。
用戶鑑權是系統中必不可少的知識點
用戶鑑權
在前後端分離的系統中，後端服務開放了API給消費者，消費者根據各種系統接口API完成請求調用，這裡就涉及到後臺API的安全性問題。由於HTTP協議是無狀態的連接，什麼意思呢？就是一次請求結束後斷開連接，下一次服務端接受到新的請求，無法識別出該請求是哪個用戶發過來的，即使該請求依然是同一個用戶。
所以服務端對於消費者的每次請求都要進行權限驗證，只有合法的用戶才能調用後臺服務進行操作，否則一律拒絕響應。那麼，問題就轉化成了系統是如何記錄用戶的登錄狀態呢？也就是系統是如何進行用戶鑑權操作的呢？
傳統的處理方式是基於cookie-session的方式，即在客戶端瀏覽器中存儲cookie值，在服務端存儲session值。客戶端在發送請求的時候加上cookie值，到服務端進行session驗證。但是在微服務模式中，這種情況就出現了弊端。一來是因為需要處理後臺session同步共享的問題，二來還要解決cookie不支持跨域請求的問題。
所以現在基於OAuth Token的認證方式開始流行，因此JWT的token認證方式成為前後端分離模式下用戶鑑權的一種常用方式。這樣只要後端服務基於token來驗證請求者的合法性，就可以避免安全問題的出現。關於Token和JWT的知識，大家可以自行蒐集知識學習，或者後期我專門寫一篇文章來詳細介紹。
前端異步請求ajax
Ajax與CORS跨域請求
上面講到，前端應用會頻繁的請求後端服務，通常採用的都是異步ajax請求，相信大家並不陌生。但是在前後端分離中，前端應用和後端服務經常會單獨部署，甚至在不同的服務器上，所用的端口也靈活可變，這就出現了所謂的跨域問題。
跨域CORS全稱Cross-Origin Resource Sharing，當程序去訪問不同域名或者同域名下的不同端口時，就出現了跨域請求。如果不做跨域處理，則後端請求會拒絕請求訪問，導致操作失敗。
此時可以通過以下方式解決跨域問題：
- JSONP技術，可以通過此方式實現數據的跨域獲取
- Nginx代理方式，通過nginx的反向代理來解決ajax不支持跨域請求的問題
- CORS跨域配置，這種方式需要後臺服務的支持，配置相關跨域參數才行
跨域問題的根本在同源策略，我們解決了跨域訪問，同時又會帶來XSS、CSFR等攻擊的安全問題，所以如何解決此類問題將又是一個課題。關於更多同源策略和跨域問題，大家還需要多瞭解啊。
數據接口與數據封裝
數據接口與數據封裝
解決了以上幾點問題，前後端的通信基本就可以打通了，接下來就是數據交互的環節了。也就是基於ajax請求來操作前後端的交互訪問。
這裡不僅涉及到前後端接口的定義問題，還有請求方式的問題。具體表現在接口名稱、方法、參數、返回值等詳細定義，還要區別HTTP請求中的GET、POST、HEAD、PUT、DETETE等請求方式，良好的數據接口定義是前後端分離系統的基礎。
此外，數據交互的格式也是一個重點，目前常用的有三種格式：
- json：輕量級的文本數據交換格式，一鍵值對的形式存在，組織靈活
- xml：可擴展的標記語言，具有一定的結構性，有規範的節點結構
- yaml：一種數據序列化格式，可讀性高
目前用的最多的還是json方式，基於此也有很多工具類出現，比如fastjson、gson、jackson等處理工具，極大的方便了數據轉換和操作。良好的數據處理和封裝是前後端分離系統，順暢交互的保障。
異常處理也是系統中重要一環
統一異常處理
前後端分離系統中最後一道關就是統一異常處理，在分佈式的前後端分離框架下，由於網絡、設備、服務、操作等各種因素較多，系統更容易出現異常，發生不可預知的情況，這個時候如果沒有做好異常處理，那麼糟糕的情況將直接反饋給用戶，造成預想不到的結果。
因此我們需要在後端服務做好異常的處理，統一好業務異常還是系統環境異常，此外前端程序也要定義好自己的異常接受和處理方式。不然即使後端處理得好，如果前端不能很好的規範，依然會造成很差的用戶體驗！
以上就是前後端分離系統模式下的幾個關鍵知識點，小夥伴兒們掌握了嗎？基於此知識點的一些擴展技術點，大家又明白嗎？
歡迎關注我 ，專注IT技能分享，一起聊聊編程談談生活！
閱讀更多 碼農撩科技 的文章
