spring boot基础学习之(二)静态资源存放的位置?为什么该存放在这?从spring boot底层代码进行剖析(webjars)

 本次项目所有能够使用的静态资源可以免费进行下载

静态资源


执着有时是一种错误,放弃有时也是一种美丽。


在架构有很多位置可以放置静态资源可以被访问到,位置不同使它们被访问的优先级顺序也有不同,接下来我们将通过spring boot配置的底层代码进行剖析。

第一个类:WebMvcAutoConfiguration

这个类实现实现的功能有很多,这里就不统一一一进行介绍,只讲解我们需要了解的配置

 静态资源配置类

 路径一:用户自己设置(在配置文件设置访问静态资源)

 如果在配置文件进行了新的配置,那么他就会执行上面的if语句:代码的内容的大体意思就是判断是否能够检测到配置文件中的新的路径配置,如果检测到了,那么就会输出Default resource handling disabled 语句,返回值是一个空值,系统默认就会从新配置路径下进行静态资源的访问。

配置用户访问的路径,创建一个新的文件夹,作为静态资源存放数据的目录,并创建一个js文件看看前端用户能不能访问的到

静态资源目录

在application.yaml配置文件进行静态资源目录进行配置

 几行代码则就表明,web静态的资源目录设为classpath路径下的templates,接下来就是访问目录下创建的demo1.html

网页查看该资源,成功输出,表明静态资源目录设置成功。

在没有上面的配置时,访问一个普通文件看能不不能被访问?

在static目录下创建一个网页文件

去网页访问该文档,看看能不能被访问到? 

 文件正常输出,这是在没有进行上面application.yaml配置文件进行配置时,能够被访问,那如果进行静态资源目录的配置后,该文件还能被访问到吗?答案是否定的

 那该目录下的文件能够被访问,那么其他路径下的资源还能被访问到吗?答案是否定的

那么为什么就加了一个配置文件的路径就不能访问了呢?

因为在默认路径它是/**这样的,如果前端用户要去访问,它就会从/目录下开始向下进行寻找,而静态资源原本就在/目录的下面,那么该静态资源自然而然就能够被访问到,但是当我们修改静态目录为其他的文件,那如果用户想要访问的静态资源不在我们设置的静态目录下,那么用户想要访问的静态资源就会查询不到,就会出现上面的页面。

那么默认的静态资源搜索是在哪里呢?

打开类二:WebMvcProperties.java

假设这个类是一个实体类,那么类中的内容都是属性,就是在配置文件application.yaml中进行属性值的注入,默认设置的路径是在/的下面,当然我们也可以进行属性值的注入,去修改用户访问静态资源路径。在配置文件中进行配置。

除了默认的路径还有spring boot项目中默认的几个路径,只要是存在这几个路径下的文档就一定能被用户访问到。

路径在WebProperties.java中配置文件中有设置

 就是上面那四个路径,只要在这几个目录下的静态资源都能被访问到,但是有一点要注意到,那就是当几个目录下存在名字和类型都相同的文件时,不通过目录下的资源优先级顺序不同

看看不同路径的静态资源能不能被前端用户访问到?在上面的四个路径下,创建不同的网页文件,看是否能被访问到?

创建资源文件

 访问结果:

 四个文件都能够被输出,表明四个目录是spring boot能够识别的路径

接下来就是如果四个文件夹下出现相同的静态资源那谁先会被访问呢?

 优先级NO.1

 优先级NO.2

 

优先级NO.3 

 优先级NO.4

 优先级顺序为:

META-INF/resources 》resources》static》public

其实呢,访问路径不光只有这几个?还有一个那就是webjars

Webjars本质就是以jar包的方式引入我们的静态资源 , 我们以前要导入一个静态资源文件,直接导入即可。

使用SpringBoot需要使用Webjars,我们可以去搜索一下:网站:https://www.webjars.org

首先导入依赖:以jquery为例

        <dependency>
            <groupId>org.webjars</groupId>
            <artifactId>jquery</artifactId>
            <version>3.6.4</version>
        </dependency>

 

 依赖被成功导入,接下来我们要尝试尝试看看能不能访问到webjars中的静态文件,就以jquert.js为例,看看能不能被访问到?

 成功被访问,说明这也是一个能够被访问的静态资源目录

  • 2
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
spring-boot-seckill分布式秒杀系统是一个用SpringBoot开发的从0到1构建的分布式秒杀系统,项目案例基本成型,逐步完善中。 开发环境: JDK1.8、Maven、Mysql、IntelliJ IDEA、SpringBoot1.5.10、zookeeper3.4.6、kafka_2.11、redis-2.8.4、curator-2.10.0 启动说明: 1、启动前 请配置application.properties中相关redis、zk以及kafka相关地址,建议在Linux下安装使用。 2、数据库脚本位于 src/main/resource/sql 下面,启动前请自行导入。 3、配置完成,运行Application中的main方法,访问 http://localhost:8080/seckill/swagger-ui.html 进行API测试。 4、秒杀商品页:http://localhost:8080/seckill/index.shtml ,部分功能待完成。 5、本测试案例单纯为了学习,某些案例并不适用于生产环境,大家根据所需自行调整。 秒杀架构: 架构层级 1、一般商家在做活动的时候,经常会遇到各种不怀好意的DDOS攻击(利用无辜的吃瓜群众夺取资源),导致真正的我们无法获得服务!所以说高防IP还是很有必要的。 2、搞活动就意味着人多,接入SLB,对多台云服务器进行流量分发,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 3、基于SLB价格以及灵活性考虑后面我们接入Nginx做限流分发,来保障后端服务的正常运行。 4、后端秒杀业务逻辑,基于Redis 或者 Zookeeper 分布式锁,Kafka 或者 Redis 做消息队列,DRDS数据库中间件实现数据的读写分离。 优化思路 1、分流、分流、分流,重要的事情说三遍,再牛逼的机器也抵挡不住高级别的并发。 2、限流、限流、限流,毕竟秒杀商品有限,防刷的前提下没有绝对的公平,根据每个服务的负载能力,设定流量极限。 3、缓存、缓存、缓存、尽量不要让大量请求穿透到DB层,活动开始前商品信息可以推送至分布式缓存。 4、异步、异步、异步,分析并识别出可以异步处理的逻辑,比如日志,缩短系统响应时间。 5、主备、主备、主备,如果有条件做好主备容灾方案也是非常有必要的(参考某年锤子的活动被攻击)。 6、最后,为了支撑更高的并发,追求更好的性能,可以对服务器的部署模型进行优化,部分请求走正常的秒杀流程,部分请求直接返回秒杀失败,缺点是开发部署时需要维护两套逻辑。 分层优化 1、前端优化:活动开始前生成静态商品页面推送缓存和CDN,静态文件(JS/CSS)请求推送至文件服务器和CDN。 2、网络优化:如果是全国用户,最好是BGP多线机房,减少网络延迟。 3、应用服务优化:Nginx最佳配置、Tomcat连接池优化、数据库配置优化、数据库连接池优化。
spring-boot-seckill分布式秒杀系统是一个用SpringBoot开发的从0到1构建的分布式秒杀系统,项目案例基本成型,逐步完善中。 开发环境: JDK1.8、Maven、Mysql、IntelliJ IDEA、SpringBoot1.5.10、zookeeper3.4.6、kafka_2.11、redis-2.8.4、curator-2.10.0 启动说明: 1、启动前 请配置application.properties中相关redis、zk以及kafka相关地址,建议在Linux下安装使用。 2、数据库脚本位于 src/main/resource/sql 下面,启动前请自行导入。 3、配置完成,运行Application中的main方法,访问 http://localhost:8080/seckill/swagger-ui.html 进行API测试。 4、秒杀商品页:http://localhost:8080/seckill/index.shtml ,部分功能待完成。 5、本测试案例单纯为了学习,某些案例并不适用于生产环境,大家根据所需自行调整。 秒杀架构: 架构层级 1、一般商家在做活动的时候,经常会遇到各种不怀好意的DDOS攻击(利用无辜的吃瓜群众夺取资源),导致真正的我们无法获得服务!所以说高防IP还是很有必要的。 2、搞活动就意味着人多,接入SLB,对多台云服务器进行流量分发,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 3、基于SLB价格以及灵活性考虑后面我们接入Nginx做限流分发,来保障后端服务的正常运行。 4、后端秒杀业务逻辑,基于Redis 或者 Zookeeper 分布式锁,Kafka 或者 Redis 做消息队列,DRDS数据库中间件实现数据的读写分离。 优化思路 1、分流、分流、分流,重要的事情说三遍,再牛逼的机器也抵挡不住高级别的并发。 2、限流、限流、限流,毕竟秒杀商品有限,防刷的前提下没有绝对的公平,根据每个服务的负载能力,设定流量极限。 3、缓存、缓存、缓存、尽量不要让大量请求穿透到DB层,活动开始前商品信息可以推送至分布式缓存。 4、异步、异步、异步,分析并识别出可以异步处理的逻辑,比如日志,缩短系统响应时间。 5、主备、主备、主备,如果有条件做好主备容灾方案也是非常有必要的(参考某年锤子的活动被攻击)。 6、最后,为了支撑更高的并发,追求更好的性能,可以对服务器的部署模型进行优化,部分请求走正常的秒杀流程,部分请求直接返回秒杀失败,缺点是开发部署时需要维护两套逻辑。 分层优化 1、前端优化:活动开始前生成静态商品页面推送缓存和CDN,静态文件(JS/CSS)请求推送至文件服务器和CDN。 2、网络优化:如果是全国用户,最好是BGP多线机房,减少网络延迟。 3、应用服务优化:Nginx最佳配置、Tomcat连接池优化、数据库配置优化、数据库连接池优化。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

不想睡醒的梦

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值