前后端分离开发架构设计
一、为什么要使用前后端分离
1.理解 MVC
MVC是一种经典的设计模式,Model-View-Controller,即模型-视图-控制器。M主要负责数据与模型,V主要负责显示,C主要负责交互与业务
- 模型是用于封装数据的载体,其本质是一个普通的Java Bean,包含一系列的成员变量及其getter/setter方法; 2)
视图而言,更加偏重于展现,在Java中可通过JSP来充当视图,或通过纯HTML进行展现,目前的主流是纯HTML;
模型和视图需要通过控制器来进行粘合,如用户发送一个HTTP请求,此时该请求首先会进入控制器,然后控制器去获取数据并将其封装为模型,最后将模型传递到视图中进行展现。
2.MVC的缺点
- 每次请求必须经过“控制器->模型->视图”流程,用户才能看到展现的界面; 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来访问这些资源。
![在这里插入图片描述](https://img-blog.csdnimg.cn/8e9575e3f50849c291a8e52fe63f2446.png)
二、优势
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接口文档
附:前后台交互使用的接口模版