少粉丝和客户朋友对于前后端分离怎么部署这个问题有很大的探索欲望。我们都知道,现在前后分离已经是发展趋势和潮流了,不少企业和客户都希望前后端分离,这样就能术业有专攻,前后端工程师能分出精力来专注于做好自己的事情,从而提升效率。本文将分享给大家的是前后端分离如何部署的知识,满满的都是干货,希望您能有所收获。
一、前后端分离怎么部署?分享具体步骤
(一)一起部署:
1.先将前端打包成静态文件:npm run build
2.将dist目录下所有的文件拷贝到后端的static中(resource下的static)
3.在后端框架拦截器中将之前拷贝的所有文件都放行
4.注意修改配置文件里面mysql、redis以及其他的url
5.打包后端在项目父路径(idea后面带ROOT)的lifecycle中点击package
6.找到target中的jar并上传到linux(建议放到一个项目专属文件夹中)
7.切换到项目文件夹执行命令 :nohup java -jar +jar包名称(有几个执行几遍)
8.访问浏览器输入Linux的地址+端口号+index.html
(二)前后端分离部署(使用nginx)
1.先将前端打包成静态文件:npm run build
2.将dist目录拷贝到Linux的文件夹下
3.找到Linux的配置文件
4.将nginx配置文件的指向地址修改为jar包的地址(后端)
5.访问静态资源(第一步拷贝的前端资源)下面修改为项目的文件夹到dist
6.将后端代码打包成jar放入项目目录
7.切换到项目文件夹执行命令 :nohup java -jar +jar包名称
8.启动nginx: …/sbin/nginx
9.访问浏览器输入Linux的地址+index.html
二、看看IBPS微服务架构前后端分离框架特点
正是由于前后端分离的需求越来越被重视,因此IBPS低代码开发平台服务商顺势而为,探索出另一条全新的前后端分离模式。那么,该平台前后端分离框架的特点究竟是什么?一起来探寻。
(一)前端解决方案特点
采用Webpack的模块打包机制;
基于vue构建用户界面的渐进式框架,采用Vue全家桶(vue-router、vuex、vue-cli、axios);
基于vue的Element UI组件库和Vux的前端解决方案;
Easy mock 模拟后端数据结构;
同一套代码多端使用,即PC端、移动端可使用同一套前端代码;
控件组件化;
表单静态化,只需生成的代码其他系统可调用。
(二)后端解决方案特点
采用Spring Cloud的微服务,通过服务注册中心Eureka向外提供注册及访问服务;
支持使用客户自己的注册中心(基于Eureka),公司主动去注册;
稳定的网关服务zuul。提供统一服务调用入口,更精准的对服务进行权限、流量等控制;
同时支持resful接口方式调用公司服务,无需注册中心及网关也可正常使用;
支持集群、分布式服务;
支持多种组件服务,如:消息服务、文件服务、定时任务等基础服务。
经过上文的长篇介绍后,大家知道前后端分离怎么部署了吗?
如果需要体验,可以从这里登录:https://cloud.bpmhome.cn:280/
(部分资料来源于网络,如有侵权,请联系我们删除)
作者:山人行 来源:https://www.cnblogs.com/shanrengo/p/6397734.html
言:分离模式
对前后端分离研究了一段时间,恰逢公司有一个大项目决定尝试使用前后端分离模式进行,便参与其中。该项目从2016年初立项至今,平平稳稳得度过,但也涌现出越来越多的问题,绝对不是说前后端分离模式不好,而是很多公司在尝试前后端分离的时候没有做好充分得准备。
网上对前后端分离介绍的文章已经屡见不鲜,接下来本人用一点粗浅的言语也谈谈这块,献丑了。
为什么要分离?
如果只问“前后端分离的意义大么?”这是废话,因为从软件架构的角度 Web 的前后端从一开始不就一直是分离的么,而且 browser、server 可能将永远分离下去。
为了了解这个问题,我们有必要先了解一下 Web的研发模式演变,关于这个题材,下面这篇博文说得不错,这边就不做搬运工了。
https://github.com/lifesinger/blog/issues/184
我们不能“为了分离而分离”,而应该“为了真正理解web开发、为了更好完成需求而分离”。
前后端分离的误区?
1、前端人员配备是否充足?
由于所在公司以往项目采用传统开发风格,即以后端MVC为主的开发模式,前端人员仅仅提供静态html页面,其余工作皆由后端开发人员完成。采用前后端分离模式可以减后台负担,加快研发效率,当然,前提是前端能做好的话。以往只需要提供静态页面的前端人员,在前后端分离模式中要负责项目的view+controller部分,即除了静态页面,还需要负责页面的所有交互代码、以及nodejs与视图层以及后端API的交互工作,无疑增加了前端人员的学习成本,在没有足够知识和人才储备的情况下,只能让前端人员加班加点。结果是大量前端人员离职(PS:做这么多事,工资总得加吧!)
2、前后端职责分配?
很多公司认为采用前后端分离之后,前后端只需要通过指定API进行交互即可,前端负责页面渲染,Nodejs负责路由分配,后端提供API。忽视了大量关键工作,职责分配和细节处理没有相应文档规定,缓存机制、图片上传下载、数据校验、语言国际化等等并没有出具相应信息。另外,大量忽视了nodejs层的作用,仅仅把nodejs当成一个路由中转,这一方面也是对nodejs技术的不熟悉导致的,其实nodejs能负责很多事,除了复杂业务逻辑处理和数据操作由Java 负责,大量工作完全可以在nodejs层处理。(PS:还是基础不够导致的!)
3、后端API是否Restful风格?
很多公司采用了前后端分离模式后,后端API仍然采用以往的传统风格,这是不合理的,Restful风格的API应该是前后端分离的最佳实践。ResultFul推荐每个URL能操作具体的资源,而且能准确描述服务器对资源的处理动作,通常服务器对资源支持get/post/put/delete/等,用来实现资源的增删改查。前后端分离的话,这些api-url是对接的桥梁,采用resultFul接口地址含义才更清晰、见名知意。(PS:用了Spring4.x 竟然还不用rest风格,说不过去啊)
4、前后端协作模式?
前后端分离后,无论是API接口的对接还是测试工作,都涉及到前后端人员的沟通,很多公司采用前后端分离后,前后端协作模式配合力度底,互相等待,开发效率低下,反而不如传统的开发模式。例如:当后端 API 没有编写完成时,前端无法进行调试,这就导致了前端会被后端阻塞的情况。其实像这种互相等待的模式需要改进, Mock Server 可能可以解决一些问题。
如何前后端分离?
怎么做前后端分离?大方向就是
后端专注于:后端控制层(Restful API) & 服务层 & 数据访问层;
前端专注于:前端控制层(Nodejs) & 视图层
本人认为的前后端分离模式应该是这样,当然这不一定正确:
1、项目设计阶段,前后端架构负责人将项目整体进行分析,讨论并确定API风格、职责分配、开发协助模式,确定人员配备;设计确定后,前后端人员共同制定开发接口。
2、项目开发阶段,前后端分离是各自分工,协同敏捷开发,后端提供Restful API,并给出详细文档说明,前端人员进行页面渲染前台的任务是发送API请(GET,PUT,POST,DELETE等)获取数据(json,xml)后渲染页面。
3、项目测试阶段,API完成之前,前端人员会使用mock server进行模拟测试,后端人员采用junit进行API单元测试,不用互相等待;API完成之后,前后端再对接测试一下就可以了,当然并不是所有的接口都可以提前定义,有一些是在开发过程中进行调整的。
4、项目部署阶段,利用nginx 做反向代理,即Java + nodejs + nginx 方式进行。
编后语
从经典的JSP+Servlet+JavaBean的MVC时代,到SSM(Spring + SpringMVC + Mybatis)和SSH(Spring + Struts + Hibernate)的Java 框架时代,再到前端框架(KnockoutJS、AngularJS、vueJS、ReactJS)为主的MV*时代,然后是Nodejs引领的全栈时代,技术和架构一直都在进步。虽然“基于NodeJS的全栈式开发”模式很让人兴奋,但是把基于Node的全栈开发变成一个稳定,让大家都能接受的东西还有很多路要走。创新之路不会止步,无论是前后端分离模式还是其他模式,都是为了更方便得解决需求,但它们都只是一个“中转站”。
走过的“中转站”可能越来越多,但是不要渐行渐远才是。
注于Java领域优质技术,欢迎关注
作 者:Cherry300
来 源:jianshu.com/p/c86cee16b418
前后端分离已成为互联网项目开发的业界标准使用方式,通过nginx+tomcat的方式(也可以中间加一个nodejs)有效的进行解耦,并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务(多种客户端,例如:浏览器,车载终端,安卓,IOS等等)打下坚实的基础。这个步骤是系统架构从猿进化成人的必经之路。
核心思想是前端html页面通过ajax调用后端的restuful api接口并使用json数据进行交互。
在互联网架构中,名词解释:
Web服务器:一般指像nginx,apache这类的服务器,他们一般只能解析静态资源。
应用服务器:一般指像tomcat,jetty,resin这类的服务器可以解析动态资源也可以解析静态资源,但解析静态资源的能力没有web服务器好。
一般都是只有web服务器才能被外网访问,应用服务器只能内网访问。
以前的JavaWeb项目大多数都是java程序员又当爹又当妈,又搞前端,又搞后端。
随着时代的发展,渐渐的许多大中小公司开始把前后端的界限分的越来越明确,前端工程师只管前端的事情,后端工程师只管后端的事情。正所谓术业有专攻,一个人如果什么都会,那么他毕竟什么都不精。
大中型公司需要专业人才,小公司需要全才,但是对于个人职业发展来说,我建议是分开。
1、对于后端java工程师:
把精力放在java基础,设计模式,jvm原理,spring+springmvc原理及源码,linux,mysql事务隔离与锁机制,mongodb,http/tcp,多线程,分布式架构,弹性计算架构,微服务架构,java性能优化,以及相关的项目管理等等。
后端追求的是:三高(高并发,高可用,高性能),安全,存储,业务等等。
2、对于前端工程师:
把精力放在html5,css3,jquery,angularjs,bootstrap,reactjs,vuejs,webpack,less/sass,gulp,nodejs,Google V8引擎,javascript多线程,模块化,面向切面编程,设计模式,浏览器兼容性,性能优化等等。
前端追求的是:页面表现,速度流畅,兼容性,用户体验等等。
术业有专攻,这样你的核心竞争力才会越来越高,正所谓你往生活中投入什么,生活就会反馈给你什么。并且两端的发展都越来越高深,你想什么都会,那你毕竟什么都不精。
通过将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传输(消耗你服务器上的计四、JSP的痛点
以前的javaWeb项目大多数使用jsp作为页面层展示数据给用户,因为流量不高,因此也没有那么苛刻的性能要求,但现在是大数据时代,对于互联网项目的性能要求是越来越高,因此原始的前后端耦合在一起的架构模式已经逐渐不能满足我们,因此我们需要需找一种解耦的方式,来大幅度提升我们的负载能力。
1、动态资源和静态资源全部耦合在一起,服务器压力大,因为服务器会收到各种http请求,例如css的http请求,js的,图片的等等。一旦服务器出现状况,前后台一起玩完,用户体验极差。
2、UI出好设计图后,前端工程师只负责将设计图切成html,需要由java工程师来将html套成jsp页面,出错率较高(因为页面中经常会出现大量的js代码),修改问题时需要双方协同开发,效率低下。
3、jsp必须要在支持java的web服务器里运行(例如tomcat,jetty,resin等),无法使用nginx等(nginx据说单实例http并发高达5w,这个优势要用上),性能提不上来。
4、第一次请求jsp,必须要在web服务器中编译成servlet,第一次运行会较慢。
5、每次请求jsp都是访问servlet再用输出流输出的html页面,效率没有直接使用html高(是每次哟,亲~)。
6、jsp内有较多标签和表达式,前端工程师在修改页面时会捉襟见肘,遇到很多痛点。
7、如果jsp中的内容很多,页面响应会很慢,因为是同步加载。
8、需要前端工程师使用java的ide(例如eclipse),以及需要配置各种后端的开发环境,你们有考虑过前端工程师的感受吗。
基于上述的一些痛点,我们应该把整个项目的开发权重往前移,实现前后端真正的解耦!
以前老的方式是:
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,react,redux,webpack)
2、发现bug,可以快速定位是谁的问题,不会出现互相踢皮球的现象。页面逻辑,跳转错误,浏览器兼容性问题,脚本错误,页面样式等问题,全部由前端工程师来负责。接口数据出错,数据没有提交成功,应答超时等问题,全部由后端工程师来解决。双方互不干扰,前端与后端是相亲相爱的一家人。
3、在大并发情况下,我可以同时水平扩展前后端服务器,比如淘宝的一个首页就需要2000+台前端服务器做集群来抗住日均多少亿+的日均pv。(去参加阿里的技术峰会,听他们说他们的web容器都是自己写的,就算他单实例抗10万http并发,2000台是2亿http并发,并且他们还可以根据预知洪峰来无限拓展,很恐怖,就一个首页。。。)
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写。ps:前端也可以玩单元测试吗?
2、上述的接口并不是java里的interface,说白了调用接口就是调用你controler里的方法。
3、加重了前端团队的工作量,减轻了后端团队的工作量,提高了性能和可扩展性。
4、我们需要一些前端的框架来解决类似于页面嵌套,分页,页面跳转控制等功能。(上面提到的那些前端框架)。
5、如果你的项目很小,或者是一个单纯的内网项目,那你大可放心,不用任何架构而言,但是如果你的项目是外网项目,呵呵哒。
6、 以前还有人在使用类似于velocity/freemarker等模板框架来生成静态页面,仁者见仁智者见智。
7、这篇文章主要的目的是说jsp在大型外网java web项目中被淘汰掉,可没说jsp可以完全不学,对于一些学生朋友来说,jsp/servlet等相关的java web基础还是要掌握牢的,不然你以为springmvc这种框架是基于什么来写的?
8、如果页面上有一些权限等等相关的校验,那么这些相关的数据也可以通过ajax从接口里拿。
9、对于既可以前端做也可以后端做的逻辑,我建议是放到前端,为什么?因为你的逻辑需要计算资源进行计算,如果放到后端去run逻辑,则会消耗带宽&内存&cpu等等计算资源,你要记住一点就是服务端的计算资源是有限的,而如果放到前端,使用的是客户端的计算资源,这样你的服务端负载就会下降(高并发场景)。类似于数据校验这种,前后端都需要做!
10、前端需要有机制应对后端请求超时以及后端服务宕机的情况,友好的展示给用户。
1、其实对于js,css,图片这类的静态资源可以考虑放到类似于阿里云的oss这类文件服务器上(如果是普通的服务器&操作系统,存储在到达pb级的文件后,或者单个文件夹内的文件数量达到3-5万,io会有很严重的性能问题),再在oss上配cdn(全国子节点加速),这样你页面打开的速度像飞一样, 无论你在全国的哪个地方,并且你的nginx的负载会进一步降低。
2、如果你要玩轻量级微服务架构,要使用nodejs做网关,用nodejs的好处还有利于seo优化,因为nginx只是向浏览器返回页面静态资源,而国内的搜索引擎爬虫只会抓取静态数据,不会解析页面中的js,这使得应用得不到良好的搜索引擎支持。同时因为nginx不会进行页面的组装渲染,需要把静态页面返回到浏览器,然后完成渲染工作,这加重了浏览器的渲染负担。浏览器发起的请求经过nginx进行分发,URL请求统一分发到nodejs,在nodejs中进行页面组装渲染;API请求则直接发送到后端服务器,完成响应。
3、如果遇到跨域问题,spring4的CORS可以完美解决,但一般使用nginx反向代理都不会有跨域问题,除非你把前端服务和后端服务分成两个域名。JSONP的方式也被淘汰掉了。
4、如果想玩多端应用,注意要去掉tomcat原生的session机制,要使用token机制,使用缓存(因为是分布式系统),做单点,对于token机制的安全性问题,可以搜一下jwt。
5、前端项目中可以加入mock测试(构造虚拟测试对象来模拟后端,可以独立开发和测试),后端需要有详细的测试用例,保证服务的可用性与稳定性。
前后端分离并非仅仅只是一种开发模式,而是一种架构模式(前后端分离架构)。千万不要以为只有在撸代码的时候把前端和后端分开就是前后端分离了,需要区分前后端项目。前端项目与后端项目是两个项目,放在两个不同的服务器,需要独立部署,两个不同的工程,两个不同的代码库,不同的开发人员。
前后端工程师需要约定交互接口,实现并行开发,开发结束后需要进行独立部署,前端通过ajax来调用http请求调用后端的restful api。前端只需要关注页面的样式与动态数据的解析&渲染,而后端专注于具体业务逻辑。
4、如果想玩多端应用,注意要去掉tomcat原生的session机制,要使用token机制,使用缓存(因为是分布式系统),做单点,对于token机制的安全性问题,可以搜一下jwt。
最近无意中发现了一个巨牛的人工智能教程,忍不住分享一下给大家。教程不仅是零基础,通俗易懂,而且非常风趣幽默,像看小说一样!觉得太牛了,所以分享给大家。点下面链接可以跳转到教程。
https://www.captainbed.net/suga
*请认真填写需求信息,我们会在24小时内与您取得联系。