前后端为什么选择了分手？
前后端分离已经逐渐成为互联网项目开发的业界标准使用方式。
通过Nginx+Tomcat的方式（也可以中间加一个Nodejs）有效的进行解耦。
前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。
这个步骤是系统架构从猿进化成人的必经之路。
核心思想是前端HTML页面通过AJAX调用后端的RESTful API接口并使用JSON数据进行交互。
在互联网架构中：
Web服务器：一般指像Nginx，Apache这类的服务器，他们一般只能解析静态资源。
应用服务器：一般指像Tomcat，Jetty，Resin这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有Web服务器好。
一般都是只有Web服务器才能被外网访问，应用服务器只能内网访问。
术业有专攻（开发人员分离）
以前的JavaWeb项目大多数都是Java程序员又当爹又当妈，又搞前端，又搞后端。
随着时代的发展，渐渐的许多大中小公司开始把前后端的界限分的越来越明确，前端工程师只管前端的事情，后端工程师只管后端的事情。
正所谓术业有专攻，一个人如果什么都要做，什么都容易做不精。
大中型公司需要专业人才，小公司需要全才。
但大雄觉得对于个人职业发展来说，在还没有成为全才的时候，精通一个方向更实际。
对于后端Java工程师：
需要把精力放在：
Java基础，设计模式，Jvm原理，Spring+SpringMVC原理及源码，Linux，Mysql事务隔离与锁机制，MongoDB，HTTP/TCP，多线程，分布式架构，弹性计算架构，微服务架构，Java性能优化，以及相关的项目管理等等。
目标追求的是：
三高（高并发，高可用，高性能），安全，存储，业务等等。
对于前端工程师：
需要把精力放在：
HTML5，CSS3，Jquery，AngularJS，Bootstrap，Reactjs，VueJS，Webpack，Less/Sass，Gulp，Nodejs，Google V8引擎，Javascript多线程，模块化，面向切面编程，设计模式，浏览器兼容性，性能优化等等。
前端追求的是：
页面表现，速度流畅，兼容性，用户体验等等。
术业有专攻，核心竞争力会越来越高，因为现在两端的发展都越来越高深，你想什么都精通，难度会越来越大，最后一场空。
通过将team分成前后端team，让两边的工程师更加专注各自的领域，独立治理，然后构建出一个全栈式的精益求精的team。
但是大雄提醒大家：这是工作到一定阶段来说的哈，学习的时候最好还是都学要学，这样才能对业务有整体认识和把握，team才算得上是team。
原始人时代（各种耦合）
曾几何时，我们的JavaWeb项目都是使用了若干后台框架，SpringMVC/Struts + Spring + Spring JDBC/Hibernate/Mybatis 等等。
大多数项目在Java后端都是分了三层，控制层，业务层，持久层。
控制层负责接收参数，调用相关业务层，封装数据，以及路由&渲染到JSP页面。
然后JSP页面上使用各种标签或者手写Java表达式将后台的数据展现出来，其实玩的是MVC那套思路。
我们先看这种情况：需求定完了，代码写完了，测试测完了，然后呢？要发布了吧？
然后咱们需要用Maven或者Eclipse等工具把代码打成一个War包，然后把这个War包发布到生产环境下的Web容器里，对吧？
发布完了之后，要启动Web容器，开始提供服务，这时候通过配置域名，DNS等等相关，网站就可以访问了（假设咱们设计的是个网站）。
那我们来看，前后端代码是不是全都在那个war包里？包括JS，CSS，图片，各种第三方的库，对吧？
好，下面在浏览器中输入网站域名（www.xxx.com），之后发生了什么？（这个问题也是很多公司的面试题！！）
在这里我们就说一些主要的情况，想要更具体的，小伙伴们也可以去自行百度~
浏览器在通过域名通过DNS服务器找到服务器外网IP，将HTTP请求发送到服务器，在TCP3次握手之后（HTTP下面是TCP/IP）
通过TCP协议开始传输数据，服务器得到请求后，开始提供服务，接收参数，之后返回应答给浏览器，浏览器再通过Content-type来解析返回的内容，呈现给用户。
那么我们来看：
我们先假设首页中有100张图片，此时，用户的看似一次HTTP请求，其实并不是一次，用户在第一次访问的时候，浏览器中不会有缓存，咱们的100张图片，浏览器要连着请求100次HTTP请求（可能有人会说HTTP长连短连的问题，就不在这里讨论了哈）
服务器接收这些请求，都需要耗费内存去创建Socket来玩TCP传输(非常消耗服务器上的计算资源）。
重点来了：这样的话，服务器的压力会非常大！！
因为页面中的所有请求都是只请求到这台服务器上，如果1个人还好，如果10000个人并发访问呢（先不聊服务器集群，这里说的是单实例服务器）？
那咱们的服务器能扛住多少个TCP连接？带宽有多大？服务器的内存有多大？硬盘是高性能的吗？能抗住多少IO？给Web服务器分的内存有多大？会不会宕机？
这就是为什么，越是大中型的Web应用，越是要解耦。
理论上可以把数据库+应用服务+消息队列+缓存+用户上传的文件+日志+等等都扔在一台服务器上。
也不用玩什么服务治理，也不用做什么性能监控，什么报警机制等等，就乱成一锅粥好了。
但是这样就像是把鸡蛋都放在一个篮子里，隐患非常大。
如果因为一个子应用的内存不稳定导致整个服务器内存溢出而hung住，那整个网站就挂掉了。
如果出意外挂掉，而恰好这时业务又处于井喷式发展高峰期，那么恭喜，业务成功被技术卡住，会流失大量用户，后果不堪设想。
（注意：技术一定是要走在业务前面的，否则将错过最佳的发展期哟~）
此外，应用全部都耦合在一起，相当于一个巨石，当服务端负载能力不足时，一般会使用负载均衡的方式，将服务器做成集群，这样其实是在水平扩展一块块巨石，性能加速度会越来越低。
正常的互联网架构，是都要拆开的。（Web服务器集群，应用服务器集群+文件服务器集群+数据库服务器集群+消息队列集群+缓存集群等等）。
开发模式
老的方式是：
- 1、产品经理/领导/客户提出需求
- 2、UI做出设计图
- 3、前端工程师做HTML页面
- 4、后端工程师将HTML页面套成JSP页面 （前后端强依赖，后端必须要等前端的HTML做好才能套JSP。如果HTML发生变更，就更痛了，开发效率低）
- 5、集成出现问题
- 6、前端返工
- 7、后端返工
- 8、二次集成
- 9、集成成功
- 10、交付
新的方式是：
- 1、产品经历/领导/客户提出需求
- 2、UI做出设计图
- 3、前后端约定接口&数据&参数
- 4、前后端并行开发 （无强依赖，可前后端并行开发，如果需求变更，只要接口&参数不变，就不用两边都修改代码，开发效率高）
- 5、前后端集成
- 6、前端页面调整
- 7、集成成功
- 8、交付
请求方式
老的方式是：
- 1、客户端请求
- 2、服务端的Servlet或Controller接收请求 （后端控制路由与渲染页面，整个项目开发的权重大部分在后端）
- 3、调用Service,Dao代码完成业务逻辑
- 4、返回JSP
- 5、JSP展现一些动态的代码
新的方式是：
- 1、浏览器发送请求
- 2、直接到达HTML页面 （前端控制路由与渲染页面，整个项目开发的权重前移）
- 3、HTML页面负责调用服务端接口产生数据 （通过AJAX等等，后台返回JSON格式数据，Json数据格式因为简洁高效而取代XML）
- 4、填充HTML，展现动态效果，在页面上进行解析并操作DOM。
总结一下新的方式的请求步骤：
大量并发浏览器请求
↓
Web服务器集群(Nginx)
↓
应用服务器集群(Tomcat)
↓
文件/数据库/缓存/消息队列服务器集群
同时可以分模块，还可以按业务拆成一个个的小集群，为后面的架构升级做准备。
前后分离的优势
- 1、可以实现真正的前后端解耦，前端服务器使用Nginx。 前端/WEB服务器放的是CSS，JS，图片等等一系列静态资源。 （甚至还可以CSS，JS，图片等资源放到特定的文件服务器，例如阿里云的OSS，并使用CDN加速） 前端服务器负责控制页面引用&跳转&路由，前端页面异步调用后端的接口，后端/应用服务器使用Tomcat（把Tomcat想象成一个数据提供者），加快整体响应速度。 （这里需要使用一些前端工程化的框架比如Nodejs，React，Router，Redux，Webpack）
- 2、发现bug，可以快速定位是谁的问题，不会出现互相踢皮球的现象。 页面逻辑，跳转错误，浏览器兼容性问题，脚本错误，页面样式等问题，全部由前端工程师来负责。 接口数据出错，数据没有提交成功，应答超时等问题，全部由后端工程师来解决。 双方互不干扰，前端与后端是相亲相爱的一家人。
- 3、在大并发情况下，可以同时水平扩展前后端服务器。 比如淘宝的一个首页就需要2000+台前端服务器做集群来抗住日均多少亿+的日均pv。
- 4、减少后端服务器的并发/负载压力。 除了接口以外的其他所有HTTP请求全部转移到前端Nginx上，接口的请求调用Tomcat，参考Nginx反向代理Tomcat。 且除了第一次页面请求外，浏览器会大量调用本地缓存。
- 5、即使后端服务暂时超时或者宕机了，前端页面也会正常访问，只不过数据刷不出来而已。
- 6、也许也需要有微信相关的轻应用，那样接口完全可以共用， 如果也有App相关的服务，那么只要通过一些代码重构，也可以大量复用接口，提升效率。（多端应用）
- 7、页面显示的东西再多也不怕，因为是异步加载。
- 8、Nginx支持页面热部署，不用重启服务器，前端升级更无缝。
- 9、增加代码的维护性&易读性。 （前后端耦在一起的代码读起来相当费劲）
- 10、提升开发效率，因为可以前后端并行开发，而不是像以前的强依赖。
- 11、在Nginx中部署证书，外网使用HTTPS访问，并且只开放443和80端口，其他端口一律关闭（防止黑客端口扫描），内网使用HTTP，性能和安全都有保障。
- 12、前端大量的组件代码得以复用，组件化，提升开发效率。
注意事项
- 1、在开需求会议的时候，前后端工程师必须全部参加，并且需要制定好接口文档。 后端工程师要写好测试用例（2个维度），不要让前端工程师充当专职测试，推荐使用Chrome的插件Postman或Soapui或Jmeter，Service层的测试用例拿Junit写。
- 2、上述的接口并不是Java里的Interface，说白了调用接口就是调用Controler里的方法。
- 3、加重了前端团队的工作量，减轻了后端团队的工作量，提高了性能和可扩展性。
- 4、我们需要一些前端的框架来解决类似于页面嵌套，分页，页面跳转控制等功能。（上面提到的那些前端框架）。
- 5、这篇文章主要的目的是说JSP在大型外网JavaWeb项目中位置尴尬，但不是说JSP可以完全不学。 对于学生来说，Jsp/Servlet等相关的JavaWeb基础是必须要掌握牢的。 毕竟你懂：SpringMVC这种框架是基于什么来写的？
总结
前后端分离并非仅仅只是一种开发模式，而是一种架构模式（前后端分离架构）。
千万不要以为只有在撸代码的时候把前端和后端分开就是前后端分离了，其实还需要区分前后端项目。
前端项目与后端项目是两个项目，放在两个不同的服务器，需要独立部署，两个不同的工程，两个不同的代码库，不同的开发人员。
前后端工程师需要约定交互接口，实现并行开发，开发结束后需要进行独立部署，前端通过AJAX来调用HTTP请求调用后端的RESTful API。
前端需要关注页面的样式与动态数据的解析&渲染，而后端专注于具体业务逻辑。