‘壹’ 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台服务器 再同一个内网。
前端和后端和数据库 都分离开。 然后数亩纳据库只对前端和后端 通信迅衡没