共计 4533 个字符，预计需要花费 12 分钟才能阅读完成。
1、背景
前后端拆散已成为互联网我的项目开发的业界规范应用形式，通过 nginx+tomcat 的形式（也能够两头加一个 nodejs）无效的进行解耦，并且前后端拆散会为当前的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS 等等）打下松软的根底。这个步骤是零碎架构从猿进化成人的必经之路。
核心思想是前端 HTML 页面通过 AJAX 调用后端的 RESTFUL API 接口并应用 JSON 数据进行交互。
- Web 服务器：个别指像 Nginx，Apache 这类的服务器，他们个别只能解析动态资源；
- 应用服务器：个别指像 Tomcat，Jetty，Resin 这类的服务器能够解析动静资源也能够解析动态资源，但解析动态资源的能力没有 web 服务器好；
个别都是只有 web 服务器能力被外网拜访，应用服务器只能内网拜访。
以前的 Java Web 我的项目大多数都是 Java 程序员又当爹又当妈，又搞前端，又搞后端。随着时代的倒退，慢慢的许多大中小公司开始把前后端的界线分的越来越明确，前端工程师只管前端的事件，后端工程师只管后端的事件。正所谓术业有专攻，一个人如果什么都会，那么他毕竟什么都不精。大中型公司须要专业人才，小公司须要全才，然而对于集体职业倒退来说，前后端须要拆散。
2、未分离时代（各种耦合）
晚期次要应用 MVC 框架，Jsp+Servlet 的结构图如下：
大抵就是所有的申请都被发送给作为控制器的 Servlet，它承受申请，并依据申请信息将它们分发给适当的 JSP 来响应。同时，Servlet 还依据 JSP 的需要生成 JavaBeans 的实例并输入给 JSP 环境。JSP 能够通过间接调用办法或应用 UseBean 的自定义标签失去 JavaBeans 中的数据。
须要阐明的是，这个 View 还能够采纳 Velocity、Freemaker 等模板引擎。应用了这些模板引擎，能够使得开发过程中的人员分工更加明确，还能进步开发效率。
那么，在这个期间，开发方式有如下两种：
形式一
形式二
形式二曾经逐步淘汰。次要起因有两点：
- 前端在开发过程中重大依赖后端，在后端没有实现的状况下，前端根本无法干活；
- 因为趋势问题，会 JSP，懂 velocity，freemarker 等模板引擎的前端越来越少；
因而，形式二逐步不被采纳。然而，不得不说一点，形式一，其实很多小型传统软件公司至今还在应用。那么，形式一和形式二具备哪些独特的毛病呢?
1、前端无奈独自调试，开发效率低；
2、前端不可避免会遇到后盾代码，例如：
<body>
<%
request.setCharacterEncoding("utf-8")
String name=request.getParameter("username");
out.print(name);
%>
</body>这种形式耦合性太强。那么，就算你用了 freemarker 等模板引擎，不能写 Java 代码。那前端也不可避免的要去重新学习该模板引擎的模板语法，无谓减少了前端的学习老本。正如咱们后端开发不想写前端一样，你想想如果你的后盾代码里嵌入前端代码，你是什么感触？因而，这种形式非常不妥。
3、JSP 自身所导致的一些其余问题 比方，JSP 第一次运行的时候比拟迟缓，因为外头蕴含一个将 JSP 翻译为 Servlet 的步骤。再比方因为同步加载的起因，在 JSP 中有很多内容的状况下，页面响应会很慢。
3、半拆散时代
前后端半拆散，前端负责开发页面，通过接口（Ajax）获取数据，采纳 Dom 操作对页面进行数据绑定，最终是由前端把页面渲染进去。这也就是 Ajax 与 SPA 利用（单页利用）联合的形式，其结构图如下：
步骤如下：
- 浏览器申请，CDN 返回 HTML 页面；
- HTML 中的 JS 代码以 Ajax 形式申请后盾的 Restful 接口；
- 接口返回 Json 数据，页面解析 Json 数据，通过 Dom 操作渲染页面；
后端提供的都是以 JSON 为数据格式的 API 接口供 Native 端应用，同样提供给 WEB 的也是 JSON 格局的 API 接口。
那么意味着 WEB 工作流程是：
- 关上 web，加载根本资源，如 CSS，JS 等；
- 发动一个 Ajax 申请再到服务端申请数据，同时展现 loading；
- 失去 json 格局的数据后再依据逻辑抉择模板渲染出 DOM 字符串；
- 将 DOM 字符串插入页面中 web view 渲染出 DOM 构造；
这些步骤都由用户所应用的设施中逐渐执行，也就是说用户的设施性能与 APP 的运行速度分割的更紧换句话说就是如果用户的设施很低端，那么 APP 关上页面的速度会越慢。
为什么说是半拆散的？因为不是所有页面都是单页面利用，在多页面利用的状况下，前端因为没有把握 controller 层，前端须要跟后端探讨，咱们这个页面是要同步输入呢，还是异步 Json 渲染呢？而且，即便在这一时期，通常也是一个工程师搞定前后端所有工作。因而，在这一阶段，只能算半拆散。
首先，这种形式的长处是很显著的。前端不会嵌入任何后盾代码，前端专一于 HTML、CSS、JS 的开发，不依赖于后端。本人还可能模仿 Json 数据来渲染页面。发现 Bug，也能迅速定位出是谁的问题。
然而，在这种架构下，还是存在显著的弊病的。最显著的有如下几点：
- JS 存在大量冗余，在业务简单的状况下，页面的渲染局部的代码，非常复杂；
- 在 Json 返回的数据量比拟大的状况下，渲染的非常迟缓，会呈现页面卡顿的状况；
- SEO（Search Engine Optimization，即搜索引擎优化）十分不不便，因为搜索引擎的爬虫无奈爬下 JS 异步渲染的数据，导致这样的页面，SEO 会存在肯定的问题；
- 资源耗费重大，在业务简单的状况下，一个页面可能要发动屡次 HTTP 申请能力将页面渲染结束。可能
- 有人不服，感觉 PC 端建设屡次 HTTP 申请也没啥。那你思考过挪动端么，晓得挪动端建设一次 HTTP 申请须要耗费多少资源么？
正是因为如上毛病，咱们才亟需真正的前后端拆散架构。
4、拆散时代
在前后端彻底拆散这一时期，前端的范畴被扩大，controller 层也被认为属于前端的一部分。在这一时期：
- 前端：负责 View 和 Controller 层。
- 后端：只负责 Model 层，业务 / 数据处理等。
可是服务端人员对前端 HTML 构造不相熟，前端也不懂后盾代码呀，controller 层如何实现呢？这就是 node.js 的妙用了，node.js 适宜使用在高并发、I/ O 密集、大量业务逻辑的场景。最重要的一点是，前端不必再学一门其余的语言了，对前端来说，上手度大大提高。
能够就把 Nodejs 当成跟前端交互的 api。总得来说，Nodejs 的作用在 mvc 中相当于 C（控制器）。Nodejs 路由的实现逻辑是把前端动态页面代码当成字符串发送到客户端（例如浏览器），简略了解能够了解为路由是提供给客户端的一组 api 接口，只不过返回的数据是页面代码的字符串而已。
用 NodeJs 来作为桥梁架接服务器端 API 输入的 JSON。后端出于性能和别的起因，提供的接口所返回的数据格式兴许不太适宜前端间接应用，前端所需的排序功能、筛选性能，以及到了视图层的页面展示，兴许都须要对接口所提供的数据进行二次解决。这些解决虽能够放在前端来进行，但兴许数据量一大便会节约浏览器性能。因此现今，减少 Node 中间层便是一种良好的解决方案。
浏览器 (webview) 不再间接申请 JSP 的 API，而是：
- 浏览器申请服务器端的 NodeJS；
- NodeJS 再发动 HTTP 去申请 JSP；
- JSP 仍然原样 API 输入 JSON 给 NodeJS；
- NodeJS 收到 JSON 后再渲染出 HTML 页面；
- NodeJS 间接将 HTML 页面 flush 到浏览器；
这样，浏览器失去的就是一般的 HTML 页面，而不必再发 Ajax 去申请服务器了。
淘宝的前端团队提出的中途岛 (Midway Framework) 的架构如下图所示：
减少 node.js 作为中间层，具体有哪些益处呢？
1、适配性晋升；
咱们其实在开发过程中，常常会给 PC 端、mobile、app 端各自研发一套前端。其实对于这三端来说，大部分端业务逻辑是一样的。惟一区别就是交互展示逻辑不同。
如果 controller 层在后端手里，后端为了这些不同端页面展现逻辑，本人保护这些 controller，模版无奈重用，徒增和前端沟通端老本。如果减少了 node.js 层，此时架构图如下：
在该构造下，每种前端的界面展现逻辑由 node 层本人保护。如果产品经理中途想要改变界面什么的，能够由前端本人专职保护，后端无需操心。前后端各司其职，后端专一本人的业务逻辑开发，前端专一产品成果开发。
2、响应速度晋升；
咱们有时候，会遇到后端返回给前端的数据太简略了，前端须要对这些数据进行逻辑运算。那么在数据量比拟小的时候，对其做运算分组等操作，并无影响。然而当数据量大的时候，会有显著的卡顿成果。这时候，node 中间层其实能够将很多这样的代码放入 node 层解决、也能够替后端分担一些简略的逻辑、又能够用模板引擎本人把握前台的输入。这样做灵便度、响应度都大大晋升。
3、性能失去晋升；
大家应该都晓得繁多职责准则。从该角度来看，咱们，申请一个页面，可能要响应很多个后端接口，申请变多了，天然速度就变慢了，这种景象在 mobile 端更加重大。采纳 node 作为中间层，将页面所须要的多个后端数据，间接在内网阶段就拼装好，再对立返回给前端，会失去更好的性能。
4、异步与模板对立；
淘宝首页就是被几十个 HTML 片段（每个片段一个文件）拼装成，之前 PHP 同步 include 这几十个片段，肯定是串行的，Node 能够异步，读文件能够并行，一旦这些片段中也蕴含业务逻辑，异步的劣势就很显著了，真正做到哪个文件先渲染完就先输入显示。
前端机的文件系统越简单，页面的组成片段越多，这种异步的提速成果就越显著。前后端模板对立在无线畛域很有用，PC 页面和 WIFI 场景下的页面适宜前端渲染（后端数据 Ajax 到前端），2G、3G 弱网络环境适宜后端渲染（数据随页面吐给前端），所以同样的模板，在不同的条件下走不同的渲染渠道，模板只需一次开发。
减少 NodeJS 中间层后的前后端职责划分：
5、总结
从经典的 JSP+Servlet+JavaBean 的 MVC 时代，到 SSM（Spring + SpringMVC + Mybatis）和 SSH（Spring + Struts + Hibernate）的 Java 框架时代，再到前端框架（KnockoutJS、AngularJS、vueJS、ReactJS）为主的 MV* 时代，而后是 Nodejs 引领的全栈时代，技术和架构始终都在提高。尽管“基于 NodeJS 的全栈式开发”模式很让人兴奋，然而把基于 Node 的全栈开发变成一个稳固，让大家都能承受的货色还有很多路要走。
翻新之路不会止步，无论是前后端拆散模式还是其余模式，都是为了更不便得解决需要，但它们都只是一个“中转站”。前端我的项目与后端我的项目是两个我的项目，放在两个不同的服务器，须要独立部署，两个不同的工程，两个不同的代码库，不同的开发人员。前端只须要关注页面的款式与动态数据的解析及渲染，而后端专一于具体业务逻辑。
起源：blog.csdn.net/fuzhongmin05/article/details/81591072