为什么推荐前后端分离

前后端分离已成为互联网项目开发的业界标准使用方式，通过nginx+tomcat的方式（也可以中间加一个nodejs）有效的进行解耦，
并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。
这个步骤是系统架构从猿进化成人的必经之路。
核心思想是前端html页面通过ajax调用后端的restuful api接口并使用json数据进行交互

（
名词解释：
在互联网架构中，
web服务器：一般指像nginx，apache这类的服务器，他们一般只能解析静态资源。
应用服务器：一般指像tomcat，jetty，resin这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有web服务器好。

一般都是只有web服务器才能被外网访问，应用服务器只能内网访问。
）

原来的传统项目模式
部门之前用的开发模式就是采用传统的mvc模式来进行开发。

我们的JavaWeb项目都是使用了若干后台框架，springmvc/struts + spring + spring jdbc/hibernate/mybatis 等等。
大多数项目在java后端都是分了三层，控制层（controller/action），业务层（service/manage），持久层（dao）。控制层负责接收参数，调用相关业务层，封装数据，以及路由&渲染到jsp页面。然后jsp页面上使用各种标签（jstl/el/struts标签等）或者手写java表达式（<%=%>）将后台的数据展现出来，玩的是MVC那套思路。庆幸的是公司还是有前端工程师（把html静态页面切出来的那种)。所以我们和前端一起合作的开发模式类似下面这种。

采用上面的开发模式，我们遇到一些问题
1.初版本项目完成之后，由于项目的原因客户需求确定也不太清晰，经常改需求很大一部分需求都是对页面样式的修改，甚至是对整个项目的页面进行升级，每一次升级都得麻烦前端去重新设计界面或者修改界面，前端界面把新的html搞好了之后会发一个文件过来，我们把新的样式文件加到原来得项目中，但是以前得页面样式又不敢随便删除也还保留在以前得项目中（谁知道哪天客户又觉得以前得样式好看呢）。随着需求的变更，整个项目的变得越来越大（前端样式和业务接口都在里面），每次修改的时候苦不堪言。
2.由于项目不确定需求太多，项目上线之后。项目的浏览器的兼容性和屏幕分辨率的问题暴露出来了，这时候让前端再去改这些页面也是难上加难，前端也没有实际的调试环境。没办法只能自己去搞，但是说实话这些兼容性问题我们真的不擅长，往往这时候就会发生前后端踢皮球的一幕。。

半分离模式
前后端半分离，前端负责开发页面，通过接口（Ajax）获取数据，采用dom操作对页面进行数据绑定，最终是由前端把页面渲染出来。这也就是其他博客里说的，Ajax与SPA应用（单页应用）结合的方式。其结构图如下
步骤如下:
(1)浏览器请求，cdn返回html页面
(2)html中的js代码以ajax方式请求后台的restful接口
(3)接口返回json数据，页面解析json数据，通过dom操作渲染页面
为什么说是半分离的？
因为不是所有页面都是单页面应用，在多页面应用的情况下，前端因为没有掌握controller层，前端需要跟后端讨论，我们这个页面是要同步输出呢，还是异步json渲染呢？因此，在这一阶段，只能算半分离。
这种方式的优缺点有哪些呢？
首先，这种方式的优点是很明显的。前端不会嵌入任何后台代码，前端专注于html、css、js的开发，不依赖于后端。自己还能够模拟json数据来渲染页面。发现bug，也能迅速定位出是谁的问题，不会出现互相推脱的现象。
然而，在这种架构下，还是存在明显的弊端的。最明显的有如下几点：
(1)js存在大量冗余，在业务复杂的情况下，页面的渲染部分的代码，非常复杂。
(2)在json返回的数据比较大的情况下，渲染的十分缓慢，会出现页面卡顿的情况
(3)seo非常不方便，国内的搜索引擎爬虫只会抓取静态数据，不会解析页面中的js，这使得应用得不到良好的搜索引擎支持。
(4)资源消耗严重，在业务复杂的情况下，一个页面可能要发起多次http请求才能将页面渲染完毕。

最终的前后端分离
在这一时期，扩展了前端的范围。认为controller层也属于前端的一部分。在这一时期
前端：负责View和Controller层。
后端：只负责Model层，业务处理/数据等。
可是前端不懂后台代码呀？controller层如何实现呢？
这就是node.js的妙用了，node.js适合运用在高并发、I/O密集、少量业务逻辑的场景。
这时候的开发模式就是下面的这种了

上面这种模式的‘优势在哪呢？

1. 适配性提升
   我们其实在开发过程中，经常会给pc端、mobile、app端各自研发一套前端。其实对于这三端来说，大部分端业务逻辑是一样的。唯一区别就是交互展现逻辑不同。如果controller层在后端手里，后端为了这些不同端页面展示逻辑，自己维护这些controller，徒增和前端沟通端成本。
   如果增加了node.js层，此时架构图如下
   在该结构下，每种前端的界面展示逻辑由node层自己维护。如果产品经理中途想要改动界面什么的，可以由前端自己专职维护，后端无需操心。前后端各司其职，后端专注自己的业务逻辑开发，前端专注产品效果开发。
2. 响应速度提升
   我们有时候，会遇到后端返回给前端的数据太简单了，前端需要对这些数据进行逻辑运算。那么在数据量比较小的时候，对其做运算分组等操作，并无影响。但是当数据量大的时候，会有明显的卡顿效果。这时候，node中间层其实可以将很多这样的代码放入node层处理、也可以替后端分担一些简单的逻辑、又可以用模板引擎自己掌握前台的输出。这样做灵活度、响应度都大大提升。
3. 性能得到提升
   大家应该都知道单一职责原则。从该角度来看，我们请求一个页面，可能要响应很多看后端接口，请求变多了，自然速度就变慢了，这种现象在mobile端更加严重。采用node作为中间层，将页面所需要的多个后端数据，直接在内网阶段就拼装好，再统一返回给前端，会得到更好的性能。

原文：https://blog.csdn.net/qq_28165595/article/details/80836069