前后端分离开发架构设计
一、为什么要使用前后端分离
1.理解 MVC
MVC是一种经典的设计模式，Model-View-Controller，即模型-视图-控制器。M主要负责数据与模型，V主要负责显示，C主要负责交互与业务1) 模型是用于封装数据的载体，其本质是一个普通的Java Bean，包含一系列的成员变量及其getter/setter方法； 2)
视图而言，更加偏重于展现，在Java中可通过JSP来充当视图，或通过纯HTML进行展现，目前的主流是纯HTML；
模型和视图需要通过控制器来进行粘合，如用户发送一个HTTP请求，此时该请求首先会进入控制器，然后控制器去获取数据并将其封装为模型，最后将模型传递到视图中进行展现。
2.MVC的缺点
1) 每次请求必须经过“控制器->模型->视图”流程，用户才能看到展现的界面； 2)
视图是依赖于模型的，如果没有模型，视图也无法呈现出最终的效果； 3)
渲染视图的过程是在服务端来完成的，最终呈现给浏览器的是带有模型的视图页面，性能无法得到很好的优化。
3.改进的MVC模式 为了使数据展现过程更加直接，提供更好的用户体验，对MVC做了改进：首先从浏览器发送Ajax请求，然后服务端接受该请求并返回JSON数据返回给浏览器，最后在浏览器中进行界面渲染。
也就是说输入的是 AJAX 请求，输出的是 JSON 数据，有这样的技术来实现这个功能吗？答案是 REST。
4.前端渲染和后端渲染 前端渲染: 指的是后端返回JSON数据，前端利用预先写好的html模板，循环读取JSON数据，拼接字符串，并插入页面。
好处：网络传输数据量小。不占用服务端运算资源（解析模板），模板在前端（很有可能仅部分在前端），改结构变交互都前端自己来，改完自己调就行。
坏处：前端耗时较多，对前端工作人员水平要求相对较高。前端代码较多，因为部分以前在后台处理的交互逻辑交给了前端处理。占用少部分客户端运算资源用于解析模板。
后端渲染: 前端请求，后端用后台模板引擎直接生成html，前端接受到数据之后，直接插入页面。
好处：前端耗时少，模板统一在后端。前端省事，不占用客户端运算资源（解析模板） 坏处：占用服务器资源。 前端渲染与后端渲染对比: 后端渲染：
页面呈现速度：快，受限于用户的带宽 流量消耗：少一点（可以省去前端框架部分的代码）
可维护性：差（前后端东西放一起，掐架多年，早就在闹分手啦） seo友好度：好 编码效率：低（这个跟不同的团队不同） 前端渲染：
页面呈现速度：主要受限于带宽和客户端机器的好坏，优化的好，可以逐步动态展开内容，感觉上会更快一点。
流量消耗：多一点（一个前端框架大概50KB）当然，有的用后端渲染的项目前端部分也有在用框架。
可维护性：好，前后端分离，各施其职，代码一目明了。 SEO友好度：差，大量使用ajax，多数浏览器不能抓取ajax数据。
编码效率：高，前后端各自只做自己擅长的东西，后端最后只输出接口，不用管页面呈现，只要前后端人员能力不错，效率不会低。
5.前后端分离模式 REST 全称是 Representational State Transfer（表述性状态转移），习惯将其称为 RESTful Web Services或简称 REST 服务。 如果将浏览器这一端视为前端，而服务器那一端视为后端的话，可以将以上改进后的
MVC 模式简化为以下前后端分离模式：
可见有了 REST 服务，前端关注界面展现，后端关注业务逻辑，分工明确，职责清晰。
6.REST REST本质上是使用URL来访问资源种方式。比较常见的URL请求方式是GET与POST，但在REST中又提出了几种其它类型的请求方式，总共有6种：POST、DELETE、PUT、GET、HEAD、OPTIONS。前四种正好与CRUD（Create-Retrieve-Update-Delete，增删改查）四种操作相对应。
REST是面向资源的，这里提到的资源，实际上就是我们常说的领域对象，在系统设计过程中，我们经常通过领域对象来进行数据建模。
REST是一个无状态的架构模式，因为在任何时候都可以由客户端发出请求到服务端，最终返回自己想要的数据，当前请求不会受到上次请求的影响。也就是说，服务端将内部资源发布REST服务，客户端通过URL来访问这些资源。
二、优势
1.可以实现真正的前后端解耦，前端服务器使用nginx，apache web服务器只能处理静态资源，tomcat web应用服务器不擅长处理静态，擅长处理动态资源
前端/WEB服务器放的是css，js，图片等等一系列静态资源（甚至还可以将css，js，图片等资源放到特定的文件服务器，例如阿里云的oss，并使用cdn加速），前端服务器负责控制页面跳转&路由，前端页面异步调用后端的接口，后端/应用服务器使用tomcat（把tomcat想象成一个数据提供者），加快整体响应速度。
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.前端大量的组件代码得以复用，组件化，提升开发效率。
三、前后端分离开发使用场景
对于前后端分离的应用场景，不是所有的场景都适合，但是大多数项目都能够通过前后端分离来实现。
大多数后台应用我们都可以做成SPA应用（单页应用），而单页应用最主要的特点就是局部刷新，这通过前端控制路由调用AJAX，后台提供接口便可以实现，而且这样的方式用户体验更加友好，网页加载更加快速，开发和维护成本也降低了不少，效率明显提升。
在展示类网站和移动APP页面中前后端分离也同样试用。前后端不分离的情况下，服务端要单独针对Web端做处理，返回完整HTML，这样势必增加服务端的复杂度，可维护性差，而web端需要加载完整的HTML，一定程度上影响网页性能，这对于移动端性能为王的地方非常的不友好。
随着前端技术的发展和迭代，前端MVC框架应运而生，利用目前主流的前端框架，如React、Vue、Angular等我们可以轻松的构建起一个无需服务器端渲染就可以展示的网站，同时这类框架都提供了前端路由功能，后台可以不再控制路由的跳转，将原本属于前端的业务逻辑全部丢给前端，这样前后端分离可以说是最为彻底。
四、请求方式
以前的方式是:
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.后端Java工程师
把精力放在Java基础，设计模式，jvm原理，spring+springmvc原理及源码，linux，mysql事务隔离与锁机制，nosql，http/tcp，多线程，分布式架构，弹性计算架构，微服务架构，Java性能优化，以及相关的项目管理等等。
后端追求的是：三高（高并发，高可用，高性能），安全，存储，业务等等。
2.前端工程师
把精力放在html5，css3，jquery，angularjs，bootstrap，reactjs，vuejs，webpack，less/sass，gulp，nodejs，Google V8引擎，javascript多线程，模块化，面向切面编程，设计模式，浏览器兼容性，性能优化等等。
前端追求的是：页面表现，速度流畅，兼容性，用户体验等等。
术业有专攻，这样你的核心竞争力才会越来越高，两端的发展都越来越高深，你想什么都会，那你毕竟什么都不精。
通过将team分成前后端team，让两边的工程师更加专注各自的领域，独立治理，然后构建出一个全栈式的精益求精的team。
六、前后台开发人员如何交互
推荐使用API接口文档
附：前后台交互使用的接口模版
