⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 cnblogs.com/xuange306/p/6823479.html 「水车」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注**微信公众号:【芋道源码】**有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

以前的项目大多数都是java程序猿又当爹又当妈,又搞前端(ajax/jquery/js/html/css等等),又搞后端(java/mysql/Oracle等等)。

随着时代的发展,渐渐的许多大中小公司开始把前后端的界限分的越来越明确,前端工程师只管前端的事情,后端工程师只管后端的事情,正所谓术业有专攻,一个人如果什么都会,那么他毕竟什么都不精。

大中型公司需要专业人才,小公司需要全才,但是对于个人职业发展来说,我建议是分开。你要是这辈子就吃java这碗饭,就不要去研究什么css,js等等。

把你的精力专注在java,jvm原理,spring原理,mysql锁,事务,多线程,大并发,分布式架构,微服务,以及相关的项目管理等等,这样你的核心竞争力才会越来越高,正所谓你往生活中投入什么,生活就会反馈给你什么。

(满满的正能量:

一旦你成为了一个行业里的精英,相信我,到时候,车,房,女人,钱,机会就都来找你了,不用着急,真的。

干java程序猿这行,真的很简单的,你懂得知识越多,你的钱就越多,当然了还需要有一定的情商。。。

你的能力越强,你就比别人创造的价值更多,你为公司创造了价值,公司给你各种福利,双赢!)

几曾何时,我们的java web项目都是使用了若干后台框架,springmvc/struts + spring + spring jdbc/hibernate/mybatis 等等

大多数项目在java后端都是分了三层,控制层(controller/action),业务层(service/manage),持久层(dao)。

控制层负责接收参数,调用相关业务层,封装数据,以及路由到jsp页面。然后jsp页面上使用各种标签(jstl/el)或者手写java(<%=%>)将后台的数据展现出来。

对吧?

我们先看这种情况,需求定完了,代码写完了,测试测完了,然后呢?要发布了吧?

你需要用maven或者eclipse等工具把你的代码打成一个war包,然后把这个war包发布到你的生产环境下的web容器(tomcat/jboss/weblogic/websphere/jetty/resin)里,对吧?

发布完了之后,你要启动你的web容器,开始提供服务,这时候你通过配置域名,dns等等相关,你的网站就可以访问了(假设你是个网站)。

那我们来看,你的前后端代码是不是全都在那个war包里?包括你的js,css,图片,各种第三方的库,对吧?

好,下面在浏览器中输入你的网站域名(www.xxx.com),之后发生了什么?(这个问题也是很多公司的面试题)

我捡干的说了啊,基础不好的童鞋请自己去搜。

浏览器在通过ip路由到你的服务,在tcp3次握手之后,通过tcp协议开始访问你的web服务器,你的web服务器得到请求后,开始提供服务,接收请求,之后通过response返回你的应答给浏览器。

那么我们来看,我们先假设你的首页中有100张图片,以及一个单表的查询,此时,用户的看似一次http请求,其实并不是一次,用户在第一次访问的时候,浏览器中不会有缓存,你的100张图片,浏览器要连着请求100次http请求(有人会跟我说http长链短链的问题,不在这里讨论),你的web服务器接收这些请求,都需要耗费内存去创建socket来玩tcp传输。

重点来了,这样的话,你的web服务器的压力会非常大,因为页面中的所有请求都是只请求到你这台服务器上,如果1个人还好,如果10000个人并发访问呢(先不聊web服务器集群,这里就说是单实例web服务器),那你的服务器能扛住多少个tcp链接?你的服务器的内存有多大?你能抗住多少IO?你给web服务器分的内存有多大?会不会宕机?

这就是为什么,越是大中型的web应用,他们越是要解耦。

理论上你可以把你的数据库+应用服务+消息队列+缓存+用户上传的文件+日志+等等都扔在一台主机上,但是这样就好像是你把鸡蛋都放在一个篮子里,隐患非常大。

正常的分布式架构,是都要拆开的,你的应用服务器集群(前,后)+文件服务器集群+数据库服务器集群+消息队列集群+缓存集群等等。

前戏太长了。

下面步入正题,首先以后的java web项目都尽量要避免使用jsp,要搞前后台解耦,玩分布式架构,这样我们的应用架构才更强。


使用jsp的痛点:

  1. 动态资源和静态资源全部耦合在一起,无法做到真正的动静分离。服务器压力大,因为服务器会收到各种http请求,例如css的http请求,js的,图片的,动态代码的等等。一旦服务器出现状况,前后台一起玩完,用户体验极差。
  2. 前端工程师做好html后,需要由java工程师来将html修改成jsp页面,出错率较高(因为页面中经常会出现大量的js代码),修改问题时需要双方协同开发,效率低下。
  3. jsp必须要在支持java的web服务器里运行(例如tomcat等),无法使用nginx等(nginx据说单实例http并发高达5w,这个优势要用上),性能提不上来。
  4. 第一次请求jsp,必须要在web服务器中编译成servlet,第一次运行会较慢。
  5. 每次请求jsp都是访问servlet再用输出流输出的html页面,效率没有直接使用html高。
  6. jsp内有较多标签和表达式,前端工程师在修改页面时会捉襟见肘,遇到很多痛点。
  7. 如果jsp中的内容很多,页面响应会很慢,因为是同步加载。

基于上述的一些痛点,我们应该把整个项目的开发权重往前移,实现前后端真正的解耦!


以前老的方式是:

  1. 客户端请求
  2. 服务端的servlet或controller接收请求(路由规则由后端制定,整个项目开发的权重大部分在后端)
  3. 调用service,dao代码完成业务逻辑
  4. 返回jsp
  5. jsp展现一些动态的代码

新的方式是:

  1. 浏览器发送请求
  2. 直接到达html页面(路由规则由前端制定,整个项目开发的权重前移)
  3. html页面负责调用服务端接口产生数据(通过ajax等等)
  4. 填充html,展现动态效果。

(有兴趣的童鞋可以访问一下阿里巴巴等大型网站,然后按一下F12,监控一下你刷新一次页面,他的http是怎么玩的,大多数都是单独请求后台数据,使用json传输数据,而不是一个大而全的http请求把整个页面包括动+静全部返回过来)


这样做的好处是:

  1. 可以实现真正的前后端解耦,前端服务器使用nginx。前端服务器放的是css,js,图片等等一系列静态资源(甚至你还可以css,js,图片等资源放到特定的文件服务器,例如阿里云的oss,并使用cdn加速),前端服务器负责控制页面引用,跳转,调用后端的接口,后端服务器使用tomcat。(这里需要使用一些前端工程化的框架比如nodejs,react,router,react,redux,webpack)
  2. 发现bug,可以快速定位是谁的问题,不会出现互相踢皮球的现象。页面逻辑,跳转错误,浏览器兼容性问题,脚本错误,页面样式等问题,全部由前端工程师来负责。接口数据出错,数据没有提交成功,应答超时等问题,全部由后端工程师来解决。
  3. 双方互不干扰,前端与后端是相亲相爱的一家人。
  4. 在大并发情况下,我可以同时水平扩展前后端服务器,比如淘宝的一个首页就需要2000台前端服务器做集群来抗住日均多少亿+的日均pv。(去参加阿里的技术峰会,听他们说他们的web容器都是自己写的,就算他单实例抗10万http并发,2000台是2亿http并发,并且他们还可以根据预知洪峰来无限拓展,很恐怖,就一个首页。。。)
  5. 减少后端服务器的并发压力,除了接口以外的其他所有http请求全部转移到前端nginx上。
  6. 即使后端服务暂时超时或者宕机了,前端页面也会正常访问,只不过数据刷不出来而已。
  7. 也许你也需要有微信相关的轻应用,那样你的接口完全可以共用,如果也有app相关的服务,那么只要通过一些代码重构,也可以大量复用接口,提升效率。
  8. 页面显示的东西再多也不怕,因为是异步加载。

注意:

  1. 在开需求会议的时候,前后端工程师必须全部参加,并且需要制定好接口文档,后端工程师要写好测试用例,不要让前端工程师充当你的组专职测试,推荐使用chrome的插件postman,service层的测试用例拿junit写。
  2. 上述的接口并不是java里的interface,说白了调用接口就是调用你controler里的方法。
  3. 加重了前端团队的工作量,减轻了后端团队的工作量,提高了性能和可扩展性。
  4. 我们需要一些前端的框架来解决类似于页面嵌套,分页,页面跳转控制等功能。(上面提到的那些前端框架)。
  5. 如果你的项目很小,或者是一个单纯的内网项目,那你大可放心,不用任何架构而言,但是如果你的项目是外网项目,呵呵哒。
  6. 以前还有人在使用类似于velocity/freemarker等模板框架来生成静态页面,现在这种做法也被淘汰掉了。
  7. 这篇文章主要的目的是说jsp在大型外网java web项目中被淘汰掉,可没说jsp可以完全不学,对于一些学生朋友来说,jsp/servlet等相关的java web基础还是要掌握牢的,不然你以为springmvc这种框架是基于什么来写的?
文章目录