『壹』 Web項目開發為何要走前後端分離模式
把前端與後端獨立起來去開發，放在兩個不同的伺服器，需要獨立部署，兩個不同的工程，兩個不同的代碼庫，不同的開發人員，前後端工程師需要約定交互介面，實現同步開發，開發結束後需要進行獨立部署，前端通過介面來調用調用後端的API，前端只需要關注頁面的樣式與動態數據的解析和渲染，而後端專注於具體業務邏輯。具體好處有以下幾點：
1.徹底解放前端
前端不再需要向後台提供模板或是後台在前端html中嵌入後台代
2.提高工作效率，分工更加明確
前後端分離的工作流程可以使前端只關注前端的事，後台只關心後台的活，兩者開發可以同時進行，在後台還沒有時間提供介面的時候，前端可以先將數據寫死或者調用本地的json文件即可，頁面的增加和路由的修改也不必再去麻煩後台，開發更加靈活。
3.局部性能提升
通過前端路由的配置，我們可以實現頁面的按需載入，無需一開始載入首頁便載入網站的所有的資源，伺服器也不再需要解析前端頁面，在頁面交互及用戶體驗上有所提升。
4.降低維護成本
通過目前主流的前端MVC框架，我們可以非常快速的定位及發現問題的所在，客戶端的問題不再需要後台人員參與及調試，代碼重構及可維護性增強。
5.實現高內聚低耦合，減少後端（應用）伺服器的並發/負載壓力。
6.即使後端服務暫時超時或者宕機了，前端頁面也會正常訪問，但無法提供數據。
7.可以使後台能更好的追求高並發，高可用，高性能；使前端能更好的追求頁面表現、速度流暢、兼容性、用戶體驗等。
我理解的前後端分離，前端是需要起伺服器的，減少學習成本，可以用node，前端也要有域名的
如果是半分離， 那麼前端提供js文件（css等）這個我也做過，前後端都用node就不說了，如果是兩種語言，
如果一個工程文件下開發，webpack下直接打包進後台語言的靜態目錄下。
如果是兩個工程，那麼前端只提供生成的js（css）文件，git pull後台項目，扔進靜態目錄，這樣又涉及到版本控制的問題，一般我會生成一個配置文件，直接讀取的，內容是xxx.hash.js這種文件名，然後document.wirte動態寫入js/css
前端起伺服器就不需要動態引入了，直接html插件生成文件，更好的控製版本
半分離 還有一個問題，例如首頁同構，如果更改xxx.blade.php文件，這就又動了php文件，甚至包括nginx反向代理啊，ssl這種緩存啊，都比較麻煩，你要是改了點啥，自己的ok了，後台的崩了，那就挺操蛋了，大公司有專門的運維還好，小公司真的是一團糟
後台我們採取全分離，nginx前端管理，至於升級nginx版本，http2，反向代理，https證書，都是前端自己弄，畢竟小公司，每個人水平都不一致，自己負責自己的比較好
但是這個跨域又要稍微處理一下，至今我這邊後台還是*，我也沒法說什麼
阿里雲這么便宜，如果把成本浪費在人力上，會變得很貴
一個人的精力有限，前後端分離有助於我們更專注我們所要注重的技術點，俗話說：「術業有專攻」。
比如我們後端，前後端分離有助於我們把注意力放在java基礎，設計模式，jvm原理，spring+springmvc原理及源碼，linux，mysql事務隔離與鎖機制，mongodb，http/tcp，多線程，分布式架構（bbo，bbox，spring cloud），彈性計算架構，微服務架構（springboot+zookeeper+docker+jenkins），java性能優化，以及相關的項目管理等等。
而前端也可以集中精力在前端的展示上。
總的來說，前後端分離利大於弊。這也是越來越少用jsp的原因。
補充兩點
1.每次請求的數據量變小，也意味著更少的響應時間。
2.也不是每個應用用前後端分離都是最合適的，要根據應用規模，工期綜合判斷。
『貳』 如何實現前後端分離前端如何在訪問後端時避免跨域訪問
前後端分離實現了技術上更大的專一性，並且賦予了前後數據的靈活性！公司現在沿用的阿拍腔尺里系前後端分離，姑且分享下！
前後端分離之前的時代，MVC框架大行其道，通常是前端(後台親切稱呼為寫靜態頁面的)開發HTML頁面，包括CSS等，然後由後端開發人員統一進行動態數據綁定，這樣前端的能力沒有體現出來，而後端也對改樣式，調布局不勝其煩，而且前後端耦合容易引發相互污染，項目笨重等缺點，這時候分離是最好的選擇！
原始的襲高MVC模型圖示:
讀寫分離就是將原來後端的框架MVC分為MC＋V，後端controller只需要控制流程的流轉，許可權認證，業務邏輯等，model層為業務代碼與數據層的連接，整個View層全部作為前端項目的形式拆分，單獨部署在不同的服務節點上，實現分離！
分離之前View與controller的數據傳輸只需圓廳要通過轉發或者重定向，將數據傳遞到頁面，使用特定的EL表達式進行數據接收與顯示，分離之後兩個項目通常在不同的伺服器中，數據的傳輸涉及到網路通信，所以需要在滿足一定的傳輸協議的基礎上進行動態數據的處理！
前後端分離怎麼做的呢？
①，後端:後端設計好數據結構後，根據需求提供一套介面文檔，內容包括遵循b/get)nginx中我通過配置映射將a/b/get映射為a/b/get(後端)實際的暴露地址，實現了數據的獲取！
這樣的一個架構，在用戶看來是完全透明的，實現了整個功能的內聚，前後分離讓前後端的開發人員更加專注的維護自己的代碼，大大提升了開發人員的效率，如果你在開發過程中有疑惑，歡迎在線咨詢
『叄』 微服務架構下，進行前後端分離，前端怎麼寫
分離後的前端，不再是一個簡單的HTML文件，已經是一個獨立的應用系統。除了要考慮頁面的數據渲染展示，還要用工程化的思想來考慮前端的架構，前後端的交互和數據安全等事情。
RESTful介面交互
前後端分離之後，更多的是採用RESTful風格的介面與後端進行數據交互。
REST是「呈現狀態轉移（REpresentational State Transfer）」的縮寫，一種API的架構風格，在客戶端和服務端之間通過呈現狀態的轉移來驅動應用狀態的演進。
在 REST 樣式的 Web 服務中，每個資源都有一個地址。資源本身都是方法調用的目標，方法列表對所有資源都是一樣的。這些方法都是標准方法，包括 HTTP GET、POST、PUT、DELETE，還可能包括 HEADER 和 OPTIONS。
RESTful的API設計，使得後端通過介面向前端傳遞數據，數據的格式通常是JSON這種通用的格式。對前端來說，只要後端返回過來的是RESTful的數據就行，不管後端是用Java寫，還是用python或PHP，拜託對後端的依賴，做到前端系統的獨立。
工程化構建
Nodejs不止可以用來做前端伺服器，在開發階段，它也能發揮很大的作用。
前端生態的發展，是圍繞著Nodejs進行的。用npm來管理項目依賴，可以很好的維護和運行在Nodejs環境上。
打包工具grunt、gulp、webpack和rollup等，都是運行在nodejs上，再結合語法編譯、打包部署等插件，將應用輸入成一個完整的應用。
如果你使用了Angular、React或Vue框架，或者你使用瀏覽器暫時還不兼容的ES6語法，還需要在應用打包前用babel將語法編譯成瀏覽器可識別的ES5的語法。
SPA
SPA是單頁Web應用（single page web application，SPA）的簡寫，就是只有一張Web頁面的應用，是載入單個HTML 頁面並在用戶與應用程序交互時動態更新該頁面的Web應用程序。
像Angular、React或Vue就是為了SPA而設計的，結合前端路由庫（react-router、vue-router）和狀態熱存儲（rex、vuex）等，可以開發出一個媲美Native APP的Web APP，用戶體驗得到了很大的提升。
當然，SPA也不是完美的，也不是適合所有的web應用，需要結合項目和場景來選擇。
SPA有如下缺點：
初次載入耗時增加。可以通過代碼拆分、懶載入來提升性能，減少初次載入耗時。
SEO不友好，現在可以通過Prerender或Server render來解決一部分。
頁面的前進和後端需要開發者自己寫，不過現在一些路由庫已經幫助我們基本解決了。
對開發者要求高，由於做SPA需要了解一整套技術棧，所以，要考慮後期是否有合適的人選進行維護。
『肆』 一個web項目前後端分離,前端工程師需要掌握哪些
如果是問「什麼是正確的前後端分離」，我還真不敢回答，生怕自己的理解有什麼偏差；但是問怎麼「理解前後端分離」，那我可以結合自身的工作，談談我對前後端分離的理解，也歡迎大家提出不同的理解。
我好局帆07年參加工作就是做企業級項目的開發，那時候的一些項目都只有一個包，沒有什麼代碼規范，業務邏臘游輯散落在各處，甚至是JSP中直接訪問資料庫並做業務處理。
後來逐漸有了一些規范，頁面就是頁面，代碼就是代碼，很多項目開始使用Ajax框架。
發展的更進一步，後端代碼有了分層，cotroller/service/，可能每個項目分層策略不同（三層和兩層居多），每層的叫法不同（cotroller還是action），數據從頁面到最後訪問資料庫，需要走到多個分層中。
不過到了此階段，在企業級項目的開發過程中，Java程序員依然要兼顧前後端的開發，所以前端頁面的樣子嘛，達不到美觀的程度，也就是能用。
前後端分離有很多的好處：前端開發和後端開發可以各司其職，約定好介面之後就可以並行開發；後端介面可以友雹復用，如果項目同時有電腦網頁端、移動網頁端、APP端等多個入口的時候，後端可以只有一個；
帶來好處的同時，也會有一些缺點，例如：增加了架構的復雜性，如果技術能力不足的團隊，可以考慮半分離（例如我們部門都是企業級應用，都沒有前端開發人員）；如果是面向互聯網的應用，需要搜索引擎抓取，就需要伺服器端渲染；另外前後端交互的介面，也需要花時間和精力設計。
『伍』 oa系統開發前後端分離前端用什麼技術比較好
目前java語言是最穩定的，高端OA如用友泛微等，都是用java開發的，所有的語言見下面 OA軟體的開發語言很多，目前較為常見的有ASP/PHP/的技術工程師，從這個市場熱度不難看出--JAVA和在擴展、升級、模塊化方面的均衡優勢。第三:還有一個最為簡單的驗證方法，就是可以問問你身邊搞過研發或者懂點計算機語言技術的朋友，他們都會給你一個明確的答案。 .NET語言開發的軟體產品穩定性較高，產品可以模塊化是一個存在的事實優勢，但.NET具有很強的優勢的同時，也存在一定的劣勢，如跨平台、大數據並發。同時.Net與ASP對接時，就會導致產品的安全性變低，.NET平台的安全性會隨著ASP的安全漏洞安全為黑客或者不法分子利用進而破壞，這個也就一直困擾軟體技術工程師的一個最大的問題--.NET語言沒有辦法和ASP對接的最大一個因素之一。當然.NET如果不需要與ASP語言對接，那麼也不存在這樣的風險。 目前國內基於.Net 的OA產品有:金和C6(高端版本) 5. JAVA JAVA是1995年由SUN公司引進到我們這個世界的革命性變成語言，今天我們記住SUN這一全球性大公司的原因就是因為SUN在網路安全系統方面是最為優秀的提供商，JAVA的優秀在於與傳統的軟體比較就是:傳統的軟體往往與具體的視線環境有關，一旦環境有所變化就需要對軟體做一番改動，耗時費力，而JAVA編寫的軟體能在執行碼上兼容，只要伺服器提供JAVA解釋器，JAVA編寫的軟體就能在其上運行(更多解釋可以見清華大學出版社出版JAVA2實用教程(第二版)，在這免費做做廣告o(∩_∩)o…)。 JAVA比.Net相比,可以跨平台，具有非常強的擴展性;可以在LINUX,UNIX上部署。對於超大型的OA系統,這是至關重要的。Windwos平台想實現上千並發不太現實，這是一個絕對的事實。JAVA在擴展性和穩定性上(SUN在網路安全方面的持續支持)的優越表現導致銀行、稅務、公安、政府這樣基於有很高安全要求的公司或者單位在選擇軟體才產品的時候會首先選擇JAVA語言開發的軟體產品。 目前國內基於JAVA的OA軟體:泛微的Ecology;用友致遠;35互聯老闆簽批系統。 由於JAVA和.NET語言開發的產品穩定性和安全性比較高的眾所周之的原因，所以在OA軟體的應用中使用JAVA和.NET語言開發的OA軟體銷售的價格會比ASP和PHP開發的軟體價格通常要高，但是隨著JAVA和.NET的語言技術的大規模使用，一旦JAVA和.NET開發的OA軟體進入中低端市場，PHP和ASP結構的OA軟體也將會面臨全面被取代的局面。 目前國內OA行業中還有一種「功能為王」的聲音，這部分主要是依靠ASP、PHP語言技術為主導的商家，這部分商家通常會強調「功能為王」，主觀上來看這其實並不錯，但是如果站在長期的目標來看，功能為王並不貼切，現有的功能滿足並不等於未來的功能滿足，JAVA和.Net之所以成為主流，這一點是任何技術流派不能阻止的，越老越多的軟體工程師在學習使用這兩種計算機語言，他們當然知道選擇的原因。OA選型人員應該從更加長遠的角度選擇OA產品。找到最適合自己的OA軟體產品最為重要。
『陸』 關於前後端分離
對於前後端分離，認識上有個誤區，那就是很多人自稱：帶洞我們老早就分離了，全AJAX，使用Angular或者什麼什麼就可以了。
這個說法是不合適的，打個比方，別人問的是「如何解決家禽把蛋生在水草邊的問題？」，但實際上人家養的是鴨子，答題的卻是養雞的，所以回答「不讓去水邊就行了」，這顯然不在點子上。
這兩年業界說的前後端分離，是限於偏展示類的系統（用A代替），而不是應用、管控類Web項目（用B代替），在B類項目里，前後端是天然分離的，對此，除了
少部分後端開發人員，基本所有人的認識都是一致的。上一段中這樣回答的人一般都是只做B類項目，在B類項目里，前後端分離是共識，不需要討論。
那麼，剩下的問題就是討論A類項目的前後端分離了。這個問題的核心在什麼地方呢，在於模板的與數據結合的位置，以及，模板的控制權在誰手裡。經過這兩年的討論，基本上我們可以達成的共識就是：模板應當由前端人員去控制，主要原因有兩方面：
-性能優化（尤其是外部資源的管理與發布，請求合並等等）
-協作的順暢性（已形成模板的界面片段的返工等問題）
那麼，模板到底應該在什麼地方跟數據結合？
這個問題就比較折騰了，有部分人嘗試像B類項目那樣，使用js模板，然後在瀏覽器端執行，這是存在一些問題的，比如說seo不友好，首屏性能不夠，尤其對於首頁DOM量很大的電商類網站，差距很明顯。
所以我們還是得把主要的模板放在服務端來執行。在這個過程中，阿里作了一些嘗試，那就是引入Node層，在這一層把模板與數據進行合成，然後瀏覽器拿到的就
是生成好的HTML了，但也不是所有HTML都是這么生成好的，還是會有一些內容等到了瀏覽器之後，再用js去載入和生成。
所以這一定會是一個混合方案，同一個系統中存在兩種模板，一種在服務端執行，一種在瀏覽器中執行，互為補充。
至於說這個方案中，是否中間層一定要是node，我覺得無所謂，只要是能正常做web項目的東西都可以，這個還是要看所在企業的技術積累方向，當然node
做這塊是有一些優勢的，比如對前端人員的語言友好性，前後端模板的通用性等等，但這些都是細節，重點還是整體方案和流程。
這時候回頭看你問題中的這句：
>前後端分離的意思是，前後端只通過JSON來交流，組件化、工程化不需要依賴後端去實現。
我相信你這里對前後端的限定是以瀏覽器返野為準的，但事實上，A類項目中，前後端的分界一定要延伸到伺服器端的模板層，也就是在這一層里，把各種來源的數據整合到模板中，這個數據未必是JSON格式的，會存在有JSON，XML，特定的二進制等等。
組件化這個話題就更復雜了，在剛才組織形式中，很難說出究竟什麼才是組件。是某個商品的模板嗎？是數據嗎？是數據和模板的結合體嗎？沒法回答。在此，我漏行喊說一句自己的看法：像電商這種項目的前端部分，基本不存在組件的概念，甚至不存在組件化的價值，因為這裡面可復用的東西太少了，也不易提取，大多數東西都是不帶邏輯的界面模板。
最近因為ReactJS的流行，帶來了一個Isomorphic的概念，這是一種很有意義的探索，但是否能解決這類問題，尚不得而知，根據我的理解，它對B類項目是較好的補充方案，但對A類項目暫時還缺乏可用性，因為A類項目中，運行期的DOM變更並不多，多是整片的改變，用這個方案去解決的話，有些牛刀殺雞的感覺。
關於B類項目的組件化，我之前那個沒寫完的系列是關於它的，但經過最近一年多的思考，我又覺得需要再重新寫一篇東西了。感謝你的問題提醒了我，這就寫。
『柒』 不懂前後端分離這篇就夠
前後端分離前我們的開發協作模式一般是這樣的：
前端寫好靜態的HTML頁面賀扮交付給後端開發。靜態頁面可以本地開發，也無需考慮業務邏輯只需要實現View即可。
後端使用模板引擎去套模板，同時內嵌一些後端提供的模板變數和一些邏輯操作。
然後前後端集成對接，遇到問題，前台返工，後台返工。
然後在集成，直至集成成功。
這種模式的問題
在前端調試的時候要安裝完整的一套後端開發工具，要把後端程序完全啟動起來。遇到問題需要後端開發來幫忙調試。我們發現前後端嚴重耦合，還要要求後端人員會一些HTML，JS等前端語言。前端頁面里還嵌入了很多後端的代碼。一旦後端換了一種語言開發，簡直就要重做。
像這種增加了大量的溝通成本，調試成本等，而且前後端的開發進度相互影響，從而大大降低了開發效率。
前後端分離並不只是開發模式，而是web應用的一種架構模式。在開發階段，前後端工程師約定好數據交互介面，實現並行開發和測試；在運行階段前後端分離模式需要對web應用進行分離部署，前後端之前使用HTTP或者其他協議進行交互請求。
1. 客戶端和服務端採用RESTFul API的交互方式進行交互
2. 前後端代碼庫分離
在傳統架構模式中，前後端代碼存放於同一個代碼庫中，甚至是同一工程目錄下。頁面中還夾雜著後端代碼。前後端工程師進行開發時，都必須把整個項目導入到開發工具中。
前後端代碼庫分離，前端代碼中有可以消蘆進行Mock測試(通過構造虛擬測試對 象以簡化測試環境的方法)的偽後端，能支持前端的獨立開發和測試。而後端代碼中除了功能實現外，還有著詳細的測試用例，以保證API的可用性，降低集成風險。
3. 並行開發
在開發期間前後端共同商定好數據介面的交互形式和數據格式。然後實現前後端的並行開發，其中前端工程師在開發完成之後可以獨自進行mock測試，而後端也可以使用Postman等介面測試軟體進行介面自測，然後前後端一起進行功能聯調並校驗格式，最終進行自動化測試。
分離後，開發模式是這樣的
為優質產品打造精益團隊
通過將開發團隊前後端分離化，讓前後端工程師只需要專注於前端或後端的開發工作，是的前後端工程師實現自治，培養其獨特的技術特性，然後構建出一個全棧式的精益開發團隊。
提升開發效率
前後端分離以後，可以實現前後端代碼的解耦，只要前後端溝通約定好應用所需介面以及介面參數，便可以開始並行開發，無需等待對方的開發工作結束。與此同時，即使需求發生變更，只要介面與數據格式不變，後端開發人員就不需要修改代碼，只要前端進行變動即可。如此一來整個應用的開發效率必然會有質的提升。
完美應對復雜多變的前端需求
如果開發團隊能完成前後端分離的轉型，打造優秀的前後端團隊，開發獨立化，讓開發人員做到專注專精，開發能力必然會有所提升，能夠完美應對各種復雜多變的前端需求。
增強代碼可維護性
前後端分離後，應用的代碼不再是前後端混合，只有在運行期才會有調用依賴關系。應用代碼將會變得整潔清晰，不論是代碼閱讀還是代碼維護都會比以前輕松。
使用了前後端分離架構後，除了開發模式的變更，我們在開發的過程中還會遇到哪些問題呢？我們接著往下看。
我們先來看看傳統開發，我們是如何進行用戶認證的
前端登錄，後端根據用戶信息生成一個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）
- 頭部包含了兩部分，token 類型和採用的加密演算法
- Base64是一種編碼，也就是說，它是可以被翻譯回原來的樣子來的。它並不是一種加密過程。
Payload
Payload是通過Claim進行Base64轉碼之後生成的一串字元串，Claim是一個Json，Claim中存放的內容是JWT自身的標准屬性，所有的標准屬性都是可選的，可以自行添加，比如：JWT的簽發者、JWT的接收者、JWT的持續時間等；同時Claim中也可以存放一些自定義的屬性，這個自定義的屬性就是在用戶認證中用於標明用戶身份的一個屬性，比如用戶存放在資料庫中的id，為了安全起見，一般不會將用戶名及密碼這類敏感的信息存放在Claim中。將Claim通過Base64轉碼之後生成的一串字元串稱作 Payload 。
Signature
Signature是由Header和Payload組合而成，將Header和Claim這兩個Json分別使用Base64方式進行編碼，生成字元串Header和Payload，然後將Header和Payload以Header.Payload的格式組合在一起形成一個字元串，然後使用上面定義好的加密演算法和一個密匙（這個密匙存放在伺服器上，用於進行驗證）對這個字元串進行加密，形成一個新的字元串，這個字元串就是 Signature 。
簽名的目的： 最後一步簽名的過程，實際上是對頭部以及負載內容進行簽名，防止內容被竄改。如果有人對頭部以及負載的內容解碼之後進行修改，再進行編碼，最後加上之前的簽名組合形成新的JWT的話，那麼伺服器端會判斷出新的頭部和負載形成的簽名和JWT附帶上的簽名是不一樣的。如果要對新的頭部和負載進行簽名，在不知道伺服器加密時用的密鑰的話，得出來的簽名也是不一樣的。
三個部分通過.連接在一起就是我們的 JWT 了：
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伺服器中，監聽同一個域名和埠，不同路徑轉發到客戶端和伺服器，把不同埠和域名的限制通過反向代理，來解決跨域的問題：
『捌』 web 前後端分離 伺服器該如何選擇
前端 和後端 分離攔態 最好 再加一台資料庫 總共3台伺服器 再同一個內網。
前端和後端和資料庫 都分離開。 然後數畝納據庫只對前端和後端 通信迅衡沒