從目前應(yīng)用軟件開(kāi)發(fā)的發(fā)展趨勢(shì)來(lái)看

• 越來(lái)越注重用戶體驗(yàn)击胜，隨著互聯(lián)網(wǎng)的發(fā)展亏狰，開(kāi)始多終端化偶摔。

• 大型應(yīng)用架構(gòu)模式正在向云化、微服務(wù)化發(fā)展辰斋。

傳統(tǒng)的開(kāi)發(fā)模式

前后端分離前我們的開(kāi)發(fā)協(xié)作模式一般是這樣的：

image

image

前端寫好靜態(tài)的HTML頁(yè)面交付給后端開(kāi)發(fā)。靜態(tài)頁(yè)面可以本地開(kāi)發(fā)宫仗，也無(wú)需考慮業(yè)務(wù)邏輯只需要實(shí)現(xiàn)View即可。

后端使用模板引擎去套模板藕夫，當(dāng)年使用最廣泛的就是jsp孽糖，freemarker等等毅贮，同時(shí)內(nèi)嵌一些后端提供的模板變量和一些邏輯操作。

然后前后端集成對(duì)接滩褥，遇到問(wèn)題病蛉，前臺(tái)返工，后臺(tái)返工瑰煎。

然后在集成铺然，直至集成成功。

這種模式的問(wèn)題：

在前端調(diào)試的時(shí)候要安裝完整的一套后端開(kāi)發(fā)工具丢间，要把后端程序完全啟動(dòng)起來(lái)探熔。遇到問(wèn)題需要后端開(kāi)發(fā)來(lái)幫忙調(diào)試。我們發(fā)現(xiàn)前后端嚴(yán)重耦合烘挫，還要要求后端人員會(huì)一些HTML诀艰，JS等前端語(yǔ)言。前端頁(yè)面里還嵌入了很多后端的代碼饮六。一旦后端換了一種語(yǔ)言開(kāi)發(fā)其垄，簡(jiǎn)直就要重做。

像這種增加了大量的溝通成本卤橄，調(diào)試成本等绿满，而且前后端的開(kāi)發(fā)進(jìn)度相互影響，從而大大降低了開(kāi)發(fā)效率窟扑。

前后端分離

前后端分離并不只是開(kāi)發(fā)模式喇颁，而是web應(yīng)用的一種架構(gòu)模式漏健。在開(kāi)發(fā)階段，前后端工程師約定好數(shù)據(jù)交互接口橘霎，實(shí)現(xiàn)并行開(kāi)發(fā)和測(cè)試蔫浆；在運(yùn)行階段前后端分離模式需要對(duì)web應(yīng)用進(jìn)行分離部署，前后端之前使用HTTP或者其他協(xié)議進(jìn)行交互請(qǐng)求姐叁。

1. 客戶端和服務(wù)端采用RESTFul API的交互方式進(jìn)行交互

image

2. 前后端代碼庫(kù)分離

image

在傳統(tǒng)架構(gòu)模式中瓦盛，前后端代碼存放于同一個(gè)代碼庫(kù)中，甚至是同一工程目錄下外潜。頁(yè)面中還夾雜著后端代碼原环。前后端工程師進(jìn)行開(kāi)發(fā)時(shí)，都必須把整個(gè)項(xiàng)目導(dǎo)入到開(kāi)發(fā)工具中处窥。

前后端代碼庫(kù)分離，前端代碼中有可以進(jìn)行Mock測(cè)試(通過(guò)構(gòu)造虛擬測(cè)試對(duì) 象以簡(jiǎn)化測(cè)試環(huán)境的方法)的偽后端柜与，能支持前端的獨(dú)立開(kāi)發(fā)和測(cè)試嵌灰。而后端代碼中除了功能實(shí)現(xiàn)外沽瞭，還有著詳細(xì)的測(cè)試用例城丧，以保證API的可用性亡哄，降低集成風(fēng)險(xiǎn)蚊惯。

3. 并行開(kāi)發(fā)

image

在開(kāi)發(fā)期間前后端共同商定好數(shù)據(jù)接口的交互形式和數(shù)據(jù)格式。然后實(shí)現(xiàn)前后端的并行開(kāi)發(fā)儒溉，其中前端工程師在開(kāi)發(fā)完成之后可以獨(dú)自進(jìn)行mock測(cè)試波闹，而后端也可以使用Postman等接口測(cè)試軟件進(jìn)行接口自測(cè)精堕，然后前后端一起進(jìn)行功能聯(lián)調(diào)并校驗(yàn)格式，最終進(jìn)行自動(dòng)化測(cè)試晌涕。

分離后重窟，開(kāi)發(fā)模式是這樣的：

image

image

image

image

前后端分離架構(gòu)后的優(yōu)點(diǎn)：

為優(yōu)質(zhì)產(chǎn)品打造精益團(tuán)隊(duì)

通過(guò)將開(kāi)發(fā)團(tuán)隊(duì)前后端分離化，讓前后端工程師只需要專注于前端或后端的開(kāi)發(fā)工作厅翔，是的前后端工程師實(shí)現(xiàn)自治刀闷，培養(yǎng)其獨(dú)特的技術(shù)特性，然后構(gòu)建出一個(gè)全棧式的精益開(kāi)發(fā)團(tuán)隊(duì)徐许。

提升開(kāi)發(fā)效率

前后端分離以后翻默，可以實(shí)現(xiàn)前后端代碼的解耦冰蘑，只要前后端溝通約定好應(yīng)用所需接口以及接口參數(shù)祠肥，便可以開(kāi)始并行開(kāi)發(fā)县恕，無(wú)需等待對(duì)方的開(kāi)發(fā)工作結(jié)束忠烛。與此同時(shí)美尸，即使需求發(fā)生變更师坎，只要接口與數(shù)據(jù)格式不變胯陋，后端開(kāi)發(fā)人員就不需要修改代碼，只要前端進(jìn)行變動(dòng)即可发笔。如此一來(lái)整個(gè)應(yīng)用的開(kāi)發(fā)效率必然會(huì)有質(zhì)的提升鸯旁。

完美應(yīng)對(duì)復(fù)雜多變的前端需求

如果開(kāi)發(fā)團(tuán)隊(duì)能完成前后端分離的轉(zhuǎn)型铺罢，打造優(yōu)秀的前后端團(tuán)隊(duì)韭赘，開(kāi)發(fā)獨(dú)立化泉瞻，讓開(kāi)發(fā)人員做到專注專精袖牙，開(kāi)發(fā)能力必然會(huì)有所提升，能夠完美應(yīng)對(duì)各種復(fù)雜多變的前端需求。

增強(qiáng)代碼可維護(hù)性

前后端分離后坦仍，應(yīng)用的代碼不再是前后端混合繁扎，只有在運(yùn)行期才會(huì)有調(diào)用依賴關(guān)系梳玫。應(yīng)用代碼將會(huì)變得整潔清晰汽纠，不論是代碼閱讀還是代碼維護(hù)都會(huì)比以前輕松。

使用了前后端分離架構(gòu)后钓账，除了開(kāi)發(fā)模式的變更梆暮，我們?cè)陂_(kāi)發(fā)的過(guò)程中還會(huì)遇到哪些問(wèn)題呢啦粹？我們接著往下看唠椭。

用戶認(rèn)證：

我們先來(lái)看看傳統(tǒng)開(kāi)發(fā)贪嫂，我們是如何進(jìn)行用戶認(rèn)證的：

image

前端登錄，后端根據(jù)用戶信息生成一個(gè)jsessionid赢织，并保存這個(gè) jsessionid 和對(duì)應(yīng)的用戶id到Session中于置，接著把 jsessionid 傳給用戶，存入瀏覽器 cookie曹步，之后瀏覽器請(qǐng)求帶上這個(gè)cookie休讳，后端根據(jù)這個(gè)cookie值來(lái)查詢用戶筹麸，驗(yàn)證是否過(guò)期物赶。

HTTP有一個(gè)特性：無(wú)狀態(tài)的酵紫，就是前后兩個(gè)HTTP事務(wù)它們并不知道對(duì)方的信息奖地。而為了維護(hù)會(huì)話信息或用戶信息参歹，一般可用Cookie和Session技術(shù)緩存信息犬庇。

• Cookie是存儲(chǔ)在客戶端的

• Session是存儲(chǔ)在服務(wù)端的

但這樣做問(wèn)題就很多臭挽，如果我們的頁(yè)面出現(xiàn)了 XSS 漏洞埋哟，由于 cookie 可以被 JavaScript 讀取赤赊，XSS 漏洞會(huì)導(dǎo)致用戶 token 泄露抛计，而作為后端識(shí)別用戶的標(biāo)識(shí)吹截，cookie 的泄露意味著用戶信息不再安全波俄。盡管我們通過(guò)轉(zhuǎn)義輸出內(nèi)容捉貌，使用 CDN 等可以盡量避免 XSS 注入趁窃，但誰(shuí)也不能保證在大型的項(xiàng)目中不會(huì)出現(xiàn)這個(gè)問(wèn)題醒陆。

在設(shè)置 cookie 的時(shí)候刨摩，其實(shí)你還可以設(shè)置 httpOnly 以及 secure 項(xiàng)。設(shè)置 httpOnly 后 cookie 將不能被 JS 讀取，瀏覽器會(huì)自動(dòng)的把它加在請(qǐng)求的 header 當(dāng)中边篮，設(shè)置 secure 的話戈轿，cookie 就只允許通過(guò) HTTPS 傳輸。secure 選項(xiàng)可以過(guò)濾掉一些使用 HTTP 協(xié)議的 XSS 注入色乾，但并不能完全阻止暖璧。

httpOnly 選項(xiàng)使得 JS 不能讀取到 cookie澎办，那么 XSS 注入的問(wèn)題也基本不用擔(dān)心了局蚀。但設(shè)置 httpOnly 就帶來(lái)了另一個(gè)問(wèn)題，就是很容易的被 XSRF扶欣，即跨站請(qǐng)求偽造宵蛀。當(dāng)你瀏覽器開(kāi)著這個(gè)頁(yè)面的時(shí)候，另一個(gè)頁(yè)面可以很容易的跨站請(qǐng)求這個(gè)頁(yè)面的內(nèi)容梧宫。因?yàn)?cookie 默認(rèn)被發(fā)了出去塘匣。

解決方案

JWT（Json Web Token）

image

JWT 是一個(gè)開(kāi)放標(biāo)準(zhǔn)(RFC 7519)巷帝，它定義了一種用于簡(jiǎn)潔忌卤，自包含的用于通信雙方之間以 JSON 對(duì)象的形式安全傳遞信息的方法。該信息可以被驗(yàn)證和信任楞泼，因?yàn)樗菙?shù)字簽名的驰徊。JWTS可以使用秘密（使用HMAC算法）或公鑰/私鑰對(duì)使用RSA或ECDSA來(lái)簽名。

• 簡(jiǎn)潔(Compact)：可以通過(guò)URL, POST 參數(shù)或者在 HTTP header 發(fā)送堕阔，因?yàn)閿?shù)據(jù)量小棍厂，傳輸速度快。

• 自包含(Self-contained)：負(fù)載中包含了所有用戶所需要的信息超陆，避免了多次查詢數(shù)據(jù)庫(kù)。

JWT 組成

JWT由3個(gè)子字符串組成，分別為Header，Payload以及Signature仅政，結(jié)合JWT的格式即：Header.Payload.Signature辫封。（Claim是描述Json的信息的一個(gè)Json，將Claim轉(zhuǎn)碼之后生成Payload）。

image

**Header **

Header是由下面這個(gè)格式的Json通過(guò)Base64編碼（編碼不是加密厢洞，是可以通過(guò)反編碼的方式獲取到這個(gè)原來(lái)的Json获枝，所以JWT中存放的一般是不敏感的信息）生成的字符串，Header中存放的內(nèi)容是說(shuō)明編碼對(duì)象是一個(gè)JWT以及使用“SHA-256”的算法進(jìn)行加密（加密用于生成Signature）

{

    "typ":"JWT",

    "alg":"HS256"

}

• 頭部包含了兩部分虚吟，token 類型和采用的加密算法

• Base64是一種編碼，也就是說(shuō)庆捺，它是可以被翻譯回原來(lái)的樣子來(lái)的醉者。它并不是一種加密過(guò)程唱歧。

image

Payload

Payload是通過(guò)Claim進(jìn)行Base64轉(zhuǎn)碼之后生成的一串字符串尖滚，Claim是一個(gè)Json撼唾，Claim中存放的內(nèi)容是JWT自身的標(biāo)準(zhǔn)屬性宇驾，所有的標(biāo)準(zhǔn)屬性都是可選的筝尾，可以自行添加损姜，比如：JWT的簽發(fā)者棒卷、JWT的接收者灾常、JWT的持續(xù)時(shí)間等监徘；同時(shí)Claim中也可以存放一些自定義的屬性，這個(gè)自定義的屬性就是在用戶認(rèn)證中用于標(biāo)明用戶身份的一個(gè)屬性，比如用戶存放在數(shù)據(jù)庫(kù)中的id，為了安全起見(jiàn)萝毛，一般不會(huì)將用戶名及密碼這類敏感的信息存放在Claim中肛根。將Claim通過(guò)Base64轉(zhuǎn)碼之后生成的一串字符串稱作Payload。

{

    "iss":"Issuer —— 用于說(shuō)明該JWT是由誰(shuí)簽發(fā)的",

    "sub":"Subject —— 用于說(shuō)明該JWT面向的對(duì)象",

    "aud":"Audience —— 用于說(shuō)明該JWT發(fā)送給的用戶",

    "exp":"Expiration Time —— 數(shù)字類型性锭，說(shuō)明該JWT過(guò)期的時(shí)間",

    "nbf":"Not Before —— 數(shù)字類型，說(shuō)明在該時(shí)間之前JWT不能被接受與處理",

    "iat":"Issued At —— 數(shù)字類型哩俭，說(shuō)明該JWT何時(shí)被簽發(fā)",

    "jti":"JWT ID —— 說(shuō)明標(biāo)明JWT的唯一ID",

    "user-definde1":"自定義屬性舉例",

    "user-definde2":"自定義屬性舉例"

}

Signature

Signature是由Header和Payload組合而成梆暖，將Header和Claim這兩個(gè)Json分別使用Base64方式進(jìn)行編碼蝗肪，生成字符串Header和Payload苟鸯，然后將Header和Payload以Header.Payload的格式組合在一起形成一個(gè)字符串，然后使用上面定義好的加密算法和一個(gè)密匙（這個(gè)密匙存放在服務(wù)器上瘫析，用于進(jìn)行驗(yàn)證）對(duì)這個(gè)字符串進(jìn)行加密砌梆，形成一個(gè)新的字符串，這個(gè)字符串就是Signature贬循。

簽名的目的：最后一步簽名的過(guò)程咸包，實(shí)際上是對(duì)頭部以及負(fù)載內(nèi)容進(jìn)行簽名，防止內(nèi)容被竄改杖虾。如果有人對(duì)頭部以及負(fù)載的內(nèi)容解碼之后進(jìn)行修改诉儒，再進(jìn)行編碼，最后加上之前的簽名組合形成新的JWT的話亏掀，那么服務(wù)器端會(huì)判斷出新的頭部和負(fù)載形成的簽名和JWT附帶上的簽名是不一樣的忱反。如果要對(duì)新的頭部和負(fù)載進(jìn)行簽名，在不知道服務(wù)器加密時(shí)用的密鑰的話滤愕，得出來(lái)的簽名也是不一樣的温算。

image

三個(gè)部分通過(guò).連接在一起就是我們的 JWT 了：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjU3ZmVmMTY0ZTU0YWY2NGZmYzUzZGJkNSIsInhzcmYiOiI0ZWE1YzUwOGE2NTY2ZTc2MjQwNTQzZjhmZWIwNmZkNDU3Nzc3YmUzOTU0OWM0MDE2NDM2YWZkYTY1ZDIzMzBlIiwiaWF0IjoxNDc2NDI3OTMzfQ.PA3QjeyZSUh7H0GfE0vJaKW4LjKJuC3dVLQiY4hii8s

JWT認(rèn)證

服務(wù)器在生成一個(gè)JWT之后會(huì)將這個(gè)token發(fā)送到客戶端機(jī)器，在客戶端再次訪問(wèn)受到JWT保護(hù)的資源URL鏈接的時(shí)候间影，服務(wù)器會(huì)獲取到這個(gè)token信息注竿，首先將Header進(jìn)行反編碼獲取到加密的算法，在通過(guò)存放在服務(wù)器上的密匙對(duì)Header.Payload 這個(gè)字符串進(jìn)行加密，比對(duì)token中的Signature和實(shí)際加密出來(lái)的結(jié)果是否一致巩割，如果一致那么說(shuō)明該token是合法有效的裙顽，認(rèn)證成功，否則認(rèn)證失敗宣谈。

JWT使用總結(jié)

1. 首先愈犹，前端通過(guò)Web表單將自己的用戶名和密碼發(fā)送到后端的接口。這一過(guò)程一般是一個(gè)HTTP POST請(qǐng)求闻丑。建議的方式是通過(guò)SSL加密的傳輸（https協(xié)議）漩怎，從而避免敏感信息被嗅探。

2. 后端核對(duì)用戶名和密碼成功后嗦嗡，將用戶的id等其他信息作為JWT Payload（負(fù)載）勋锤，將其與頭部分別進(jìn)行Base64編碼拼接后簽名，形成一個(gè)JWT侥祭。形成的JWT就是一個(gè)形同lll.zzz.xxx的字符串叁执。

3. 后端將JWT字符串作為登錄成功的返回結(jié)果返回給前端。前端可以將返回的結(jié)果保存在Cookie或localStorage或sessionStorage上矮冬，退出登錄時(shí)前端刪除保存的JWT即可徒恋。

image

4. 前端在每次請(qǐng)求時(shí)將JWT放入HTTP Header中的Authorization位。(解決XSS和XSRF問(wèn)題)

5. 后端檢查是否存在欢伏，如存在驗(yàn)證JWT的有效性入挣。例如，檢查簽名是否正確硝拧；檢查Token是否過(guò)期径筏；檢查Token的接收方是否是自己（可選）。

6. 驗(yàn)證通過(guò)后后端使用JWT中包含的用戶信息進(jìn)行其他邏輯操作障陶，返回相應(yīng)結(jié)果滋恬。

image

JWT和Session方式存儲(chǔ)id的差異

Session方式存儲(chǔ)用戶id的最大弊病在于Session是存儲(chǔ)在服務(wù)器端的，所以需要占用大量服務(wù)器內(nèi)存抱究，對(duì)于較大型應(yīng)用而言可能還要保存許多的狀態(tài)恢氯。一般而言，大型應(yīng)用還需要借助一些KV數(shù)據(jù)庫(kù)和一系列緩存機(jī)制來(lái)實(shí)現(xiàn)Session的存儲(chǔ)鼓寺。

而JWT方式將用戶狀態(tài)分散到了客戶端中勋拟，可以明顯減輕服務(wù)端的內(nèi)存壓力。除了用戶id之外妈候，還可以存儲(chǔ)其他的和用戶相關(guān)的信息敢靡，例如該用戶是否是管理員、用戶所在的分組等苦银。雖說(shuō)JWT方式讓服務(wù)器有一些計(jì)算壓力（例如加密啸胧、編碼和解碼）赶站，但是這些壓力相比磁盤存儲(chǔ)而言可能就不算什么了。

單點(diǎn)登錄

Session方式來(lái)存儲(chǔ)用戶id纺念，一開(kāi)始用戶的Session只會(huì)存儲(chǔ)在一臺(tái)服務(wù)器上贝椿。對(duì)于有多個(gè)子域名的站點(diǎn)，每個(gè)子域名至少會(huì)對(duì)應(yīng)一臺(tái)不同的服務(wù)器陷谱，例如：

www.taobao.com烙博，nv.taobao.com，nz.taobao.com叭首，login.taobao.com习勤。所以如果要實(shí)現(xiàn)在login.taobao.com登錄后踪栋，在其他的子域名下依然可以取到Session焙格，這要求我們?cè)诙嗯_(tái)服務(wù)器上同步Session。使用JWT的方式則沒(méi)有這個(gè)問(wèn)題的存在夷都，因?yàn)橛脩舻臓顟B(tài)已經(jīng)被傳送到了客戶端眷唉。

跨域問(wèn)題

當(dāng)客戶端和服務(wù)端分開(kāi)部署到不同服務(wù)器的時(shí)候，就會(huì)遇到跨域訪問(wèn)的問(wèn)題囤官，是由瀏覽器同源策略限制的一類請(qǐng)求場(chǎng)景冬阳。

image

跨域解決方案--終極版，這篇文章講了大概9種解決跨域問(wèn)題党饮，但是我推薦使用Nginx反向代理的方案：

反向代理

代理訪問(wèn)其實(shí)在實(shí)際應(yīng)用中有很多場(chǎng)景肝陪，在跨域中應(yīng)用的原理做法為：通過(guò)反向代理服務(wù)器監(jiān)聽(tīng)同端口，同域名的訪問(wèn)刑顺，不同路徑映射到不同的地址氯窍，比如，在nginx服務(wù)器中蹲堂，監(jiān)聽(tīng)同一個(gè)域名和端口狼讨，不同路徑轉(zhuǎn)發(fā)到客戶端和服務(wù)器，把不同端口和域名的限制通過(guò)反向代理柒竞，來(lái)解決跨域的問(wèn)題：

server {

    listen      80;

    server_name  domain.com;

    #charset koi8-r;

    #access_log  logs/host.access.log  main;

    location /client { #訪問(wèn)客戶端路徑

        proxy_pass http://localhost:81;

        proxy_redirect default;

    }

    location /apis { #訪問(wèn)服務(wù)器路徑

        rewrite  ^/apis/(.*)$ /$1 break;

        proxy_pass  http://localhost:82;

    }

}