不懂先後端分離？這篇就夠了

一 傳統的開發模式

先後端分離前咱們的開發協做模式通常是這樣的：

前端寫好靜態的HTML頁面交付給後端開發。靜態頁面能夠本地開發，也無需考慮業務邏輯只須要實現View便可。

後端使用模板引擎去套模板，同時內嵌一些後端提供的模板變量和一些邏輯操做。

而後先後端集成對接，遇到問題，前臺返工，後臺返工。

而後在集成，直至集成成功。

這種模式的問題

在前端調試的時候要安裝完整的一套後端開發工具，要把後端程序徹底啓動起來。遇到問題須要後端開發來幫忙調試。咱們發現先後端嚴重耦合，還要要求後端人員會一些HTML，JS等前端語言。前端頁面裏還嵌入了不少後端的代碼。一旦後端換了一種語言開發，簡直就要重作。

像這種增長了大量的溝通成本，調試成本等，並且先後端的開發進度相互影響，從而大大下降了開發效率。

二 先後端分離的開發模式

先後端分離並不僅是開發模式，而是web應用的一種架構模式。在開發階段，先後端工程師約定好數據交互接口，實現並行開發和測試；在運行階段先後端分離模式須要對web應用進行分離部署，先後端以前使用HTTP或者其餘協議進行交互請求。

1. 客戶端和服務端採用RESTFul API的交互方式進行交互

2. 先後端代碼庫分離

在傳統架構模式中，先後端代碼存放於同一個代碼庫中，甚至是同一工程目錄下。頁面中還夾雜着後端代碼。先後端工程師進行開發時，都必須把整個項目導入到開發工具中。

先後端代碼庫分離，前端代碼中有能夠進行Mock測試(經過構造虛擬測試對 象以簡化測試環境的方法)的僞後端，能支持前端的獨立開發和測試。然後端代碼中除了功能實現外，還有着詳細的測試用例，以保證API的可用性，下降集成風險。

3. 並行開發

在開發期間先後端共同商定好數據接口的交互形式和數據格式。而後實現先後端的並行開發，其中前端工程師在開發完成以後能夠獨自進行mock測試，然後端也可使用Postman等接口測試軟件進行接口自測，而後先後端一塊兒進行功能聯調並校驗格式，最終進行自動化測試。

分離後，開發模式是這樣的

三 先後分離的優勢

爲優質產品打造精益團隊

經過將開發團隊先後端分離化，讓先後端工程師只須要專一於前端或後端的開發工做，是的先後端工程師實現自治，培養其獨特的技術特性，而後構建出一個全棧式的精益開發團隊。

提高開發效率

先後端分離之後，能夠實現先後端代碼的解耦，只要先後端溝通約定好應用所需接口以及接口參數，即可以開始並行開發，無需等待對方的開發工做結束。與此同時，即便需求發生變動，只要接口與數據格式不變，後端開發人員就不須要修改代碼，只要前端進行變更便可。如此一來整個應用的開發效率必然會有質的提高。

完美應對複雜多變的前端需求

若是開發團隊能完成先後端分離的轉型，打造優秀的先後端團隊，開發獨立化，讓開發人員作到專一專精，開發能力必然會有所提高，可以完美應對各類複雜多變的前端需求。

加強代碼可維護性

先後端分離後，應用的代碼再也不是先後端混合，只有在運行期纔會有調用依賴關係。應用代碼將會變得整潔清晰，不管是代碼閱讀仍是代碼維護都會比之前輕鬆。

使用了先後端分離架構後，除了開發模式的變動，咱們在開發的過程當中還會遇到哪些問題呢？咱們接着往下看。

四 JWT實現用戶認證

咱們先來看看傳統開發，咱們是如何進行用戶認證的

前端登陸，後端根據用戶信息生成一個jsessionid，並保存這個 jsessionid 和對應的用戶id到Session中，接着把 jsessionid 傳給用戶，存入瀏覽器 cookie，以後瀏覽器請求帶上這個cookie，後端根據這個cookie值來查詢用戶，驗證是否過時。

HTTP有一個特性：無狀態的，就是先後兩個HTTP事務它們並不知道對方的信息。而爲了維護會話信息或用戶信息，通常可用Cookie和Session技術緩存信息。

- Cookie是存儲在客戶端的

- Session是存儲在服務端的

但這樣作問題就不少，若是咱們的頁面出現了 XSS 漏洞，因爲 cookie 能夠被 JavaScript 讀取，XSS 漏洞會致使用戶 token 泄露，而做爲後端識別用戶的標識，cookie 的泄露意味着用戶信息再也不安全。儘管咱們經過轉義輸出內容，使用 CDN 等能夠儘可能避免 XSS 注入，但誰也不能保證在大型的項目中不會出現這個問題。

在設置 cookie 的時候，其實你還能夠設置 httpOnly 以及 secure 項。設置 httpOnly 後 cookie 將不能被 JS 讀取，瀏覽器會自動的把它加在請求的 header 當中，設置 secure 的話，cookie 就只容許經過 HTTPS 傳輸。secure 選項能夠過濾掉一些使用 HTTP 協議的 XSS 注入，但並不能徹底阻止。

httpOnly 選項使得 JS 不能讀取到 cookie，那麼 XSS 注入的問題也基本不用擔憂了。但設置 httpOnly 就帶來了另外一個問題，就是很容易的被 XSRF，即跨站請求僞造。當你瀏覽器開着這個頁面的時候，另外一個頁面能夠很容易的跨站請求這個頁面的內容。由於 cookie 默認被髮了出去。

解決方案

JWT（Json Web Token）

JWT 是一個開放標準(RFC 7519)，它定義了一種用於簡潔，自包含的用於通訊雙方之間以 JSON 對象的形式安全傳遞信息的方法。該信息能夠被驗證和信任，由於它是數字簽名的。JWTS可使用祕密（使用HMAC算法）或公鑰/私鑰對使用RSA或ECDSA來簽名。

- 簡潔(Compact)：能夠經過URL, POST 參數或者在 HTTP header 發送，由於數據量小，傳輸速度快。

- 自包含(Self-contained)：負載中包含了全部用戶所須要的信息，避免了屢次查詢數據庫。

JWT 組成

JWT由3個子字符串組成，分別爲Header，Payload以及Signature，結合JWT的格式即：Header.Payload.Signature。（Claim是描述Json的信息的一個Json，將Claim轉碼以後生成Payload）。

Header

Header是由下面這個格式的Json經過Base64編碼（編碼不是加密，是能夠經過反編碼的方式獲取到這個原來的Json，因此JWT中存放的通常是不敏感的信息）生成的字符串，Header中存放的內容是說明編碼對象是一個JWT以及使用「SHA-256」的算法進行加密（加密用於生成Signature）

{
"typ":"JWT",
"alg":"HS256"
}

- 頭部包含了兩部分，token 類型和採用的加密算法

- Base64是一種編碼，也就是說，它是能夠被翻譯回原來的樣子來的。它並非一種加密過程。

Payload

Payload是經過Claim進行Base64轉碼以後生成的一串字符串，Claim是一個Json，Claim中存放的內容是JWT自身的標準屬性，全部的標準屬性都是可選的，能夠自行添加，好比：JWT的簽發者、JWT的接收者、JWT的持續時間等；同時Claim中也能夠存放一些自定義的屬性，這個自定義的屬性就是在用戶認證中用於標明用戶身份的一個屬性，好比用戶存放在數據庫中的id，爲了安全起見，通常不會將用戶名及密碼這類敏感的信息存放在Claim中。將Claim經過Base64轉碼以後生成的一串字符串稱做Payload。

{
"iss":"Issuer —— 用於說明該JWT是由誰簽發的",
"sub":"Subject —— 用於說明該JWT面向的對象",
"aud":"Audience —— 用於說明該JWT發送給的用戶",
"exp":"Expiration Time —— 數字類型，說明該JWT過時的時間",
"nbf":"Not Before —— 數字類型，說明在該時間以前JWT不能被接受與處理",
"iat":"Issued At —— 數字類型，說明該JWT什麼時候被簽發",
"jti":"JWT ID —— 說明標明JWT的惟一ID",
"user-definde1":"自定義屬性舉例",
"user-definde2":"自定義屬性舉例"
}

Signature

Signature是由Header和Payload組合而成，將Header和Claim這兩個Json分別使用Base64方式進行編碼，生成字符串Header和Payload，而後將Header和Payload以Header.Payload的格式組合在一塊兒造成一個字符串，而後使用上面定義好的加密算法和一個密匙（這個密匙存放在服務器上，用於進行驗證）對這個字符串進行加密，造成一個新的字符串，這個字符串就是Signature。

簽名的目的：最後一步簽名的過程，其實是對頭部以及負載內容進行簽名，防止內容被竄改。若是有人對頭部以及負載的內容解碼以後進行修改，再進行編碼，最後加上以前的簽名組合造成新的JWT的話，那麼服務器端會判斷出新的頭部和負載造成的簽名和JWT附帶上的簽名是不同的。若是要對新的頭部和負載進行簽名，在不知道服務器加密時用的密鑰的話，得出來的簽名也是不同的。

三個部分經過.鏈接在一塊兒就是咱們的 JWT 了：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjU3ZmVmMTY0ZTU0YWY2NGZmYzUzZGJkNSIsInhzcmYiOiI0ZWE1YzUwOGE2NTY2ZTc2MjQwNTQzZjhmZWIwNmZkNDU3Nzc3YmUzOTU0OWM0MDE2NDM2YWZkYTY1ZDIzMzBlIiwiaWF0IjoxNDc2NDI3OTMzfQ.PA3QjeyZSUh7H0GfE0vJaKW4LjKJuC3dVLQiY4hii8s

JWT認證

服務器在生成一個JWT以後會將這個token發送到客戶端機器，在客戶端再次訪問受到JWT保護的資源URL連接的時候，服務器會獲取到這個token信息，首先將Header進行反編碼獲取到加密的算法，在經過存放在服務器上的密匙對Header.Payload 這個字符串進行加密，比對token中的Signature和實際加密出來的結果是否一致，若是一致那麼說明該token是合法有效的，認證成功，不然認證失敗。

JWT使用總結

1. 首先，前端經過Web表單將本身的用戶名和密碼發送到後端的接口。這一過程通常是一個HTTP POST請求。建議的方式是經過SSL加密的傳輸（https協議），從而避免敏感信息被嗅探。

2. 後端覈對用戶名和密碼成功後，將用戶的id等其餘信息做爲JWT Payload（負載），將其與頭部分別進行Base64編碼拼接後簽名，造成一個JWT。造成的JWT就是一個形同lll.zzz.xxx的字符串。

3. 後端將JWT字符串做爲登陸成功的返回結果返回給前端。前端能夠將返回的結果保存在Cookie或localStorage或sessionStorage上，退出登陸時前端刪除保存的JWT便可。

4. 前端在每次請求時將JWT放入HTTP Header中的Authorization位。(解決XSS和XSRF問題)

5. 後端檢查是否存在，如存在驗證JWT的有效性。例如，檢查簽名是否正確；檢查Token是否過時；檢查Token的接收方是不是本身（可選）。

6. 驗證經過後後端使用JWT中包含的用戶信息進行其餘邏輯操做，返回相應結果。

JWT和Session方式存儲id的差別

Session方式存儲用戶id的最大弊病在於Session是存儲在服務器端的，因此須要佔用大量服務器內存，對於較大型應用而言可能還要保存許多的狀態。通常而言，大型應用還須要藉助一些KV數據庫和一系列緩存機制來實現Session的存儲。

而JWT方式將用戶狀態分散到了客戶端中，能夠明顯減輕服務端的內存壓力。除了用戶id以外，還能夠存儲其餘的和用戶相關的信息，例如該用戶是不是管理員、用戶所在的分組等。雖然說JWT方式讓服務器有一些計算壓力（例如加密、編碼和解碼），可是這些壓力相比磁盤存儲而言可能就不算什麼了。

單點登陸

Session方式來存儲用戶id，一開始用戶的Session只會存儲在一臺服務器上。對於有多個子域名的站點，每一個子域名至少會對應一臺不一樣的服務器，例如：

www.taobao.com，nv.taobao.com，nz.taobao.com，login.taobao.com。因此若是要實如今login.taobao.com登陸後，在其餘的子域名下依然能夠取到Session，這要求咱們在多臺服務器上同步Session。使用JWT的方式則沒有這個問題的存在，由於用戶的狀態已經被傳送到了客戶端。

五 跨域問題解決

當客戶端和服務端分開部署到不一樣服務器的時候，就會遇到跨域訪問的問題，是由瀏覽器同源策略限制的一類請求場景。

跨域解決方案有不少種，下面使用Nginx反向代理的方案

反向代理

代理訪問其實在實際應用中有不少場景，在跨域中應用的原理作法爲：經過反向代理服務器監聽同端口，同域名的訪問，不一樣路徑映射到不一樣的地址，好比，在nginx服務器中，監聽同一個域名和端口，不一樣路徑轉發到客戶端和服務器，把不一樣端口和域名的限制經過反向代理，來解決跨域的問題：

server {
listen       80;
server_name  domain.com;
#charset koi8-r;
#access_log  logs/host.access.log  main;
location /client { #訪問客戶端路徑
proxy_pass http://localhost:81;
proxy_redirect default;
    }
location /apis { #訪問服務器路徑
rewrite  ^/apis/(.*)$ /$1 break;
proxy_pass   http://localhost:82;
    }
}