springBoot原理后续和Nginx使用基础

springBoot

1.引入：

上一篇我们学习了如何在maven项目中使用springBoot来实现spring，springMVC，Mybatis构架一个web项目，今天我们就来学习一下springBoot的一些基础原理。

2.相关原理：

在使用springBoot之前，我们使用了大量的xml文件来进行项目配置，这其实是非常不合理的，xml太多了后代码维护更加的困难，使用了springBoot之后，就只需要pom，application，mappers，就可以实现ssm框架的搭建，这其中的原因是什么？我们就来说明一下它的其他注解。

1.@Configuration
使用于类上，被该注解标注的类，就叫配置类，相当于就是一个xml文件。下面是SpringBootConfiguration注解中的配置类。

2.@ComponentScan
在启动类的@SpringBootApplication注解中，点击进去可以看到，下面有该注解，意思就是包扫描，和以前xml中的context:component-scan一样，这也就是为什么我们的启动类要放在最外面的原因，不然扫描不到其他包

3.@bean
使用在方法上，该方法的返回值交由spring来进行管理，之前在学习spring的DI，使用过一个工厂类来进行实例化，其中就用到了@bean。

@Component("MySql")
public class MySql implements dao {
//使用工厂注入user
    @Autowired
    @Qualifier("getInstance")
    User user=null;

    @Override
    public User insert() {
        System.out.println("创建成功");
        return user;
    }
}

@Component("UserFactory")
public class UserFactory {
//通过user类来注入到工厂中，工厂返回
    @Autowired
    @Qualifier("User")
    User user=null;
    @Bean("getInstance")
    public User getInstance(){
        return this.user;
    }
}

4.@conditional
springBoot扩展了很多注解，这些注解和原来的xml中没有对应的关系了，条件注解就是其中之一

conditional的衍生注解@ConditionalOnBean。是否在容器中有这个MyController.class的对象,有则满足条件,没有则不满足条件

    @Bean
    @ConditionalOnBean(MyController.class)

    public Bean1 initBean1(){

        System.out.println("条件满足,initBean1被创建调用");

        return new Bean1();

    }

conditional的其他衍生：
@ConditionalOnMissingBean:容器中没有指定的某些bean对象才会满足条件

@ConditionalOnClass:大量springboot自动配置类使用的条件注解,依赖资源由指定的类才满足条件

@ConditionalOnMissingClass:依赖没有该指定类才满足条件

@ConditionalOnWebApplication:当前进程是web工程满足条件

@ConditionalOnNotWebApplication:当前进程不是web工程满足条件

nginx

1.引入

web项目通常情况下都需要高并发，一个相同的web应用可以被部署在很多服务器上，也可以在一个服务器上开很多个相同的web应用（web项目集群），这就出现了一个问题，当一个请求发送出去的时候，究竟分配给哪个服务器来解决，这就需要使用一个工具nginx。使用nginx来做负载均衡，可以很大程度上的提高了用户的使用感觉。

客户端通过网络,使用域名+80默认端口访问到nginx的服务器,通过nginx的计算可以负载均衡的访问后端服务器集群.

2.nginx访问流程：

要使用nginx作为代理服务器，就需要在nginx中配置相关信息（nginx.conf）：

http {
        server{
            #配置OU系统-8091
            listen 80;
            server_name www.ou.com;
            location / {
                proxy_pass http://127.0.0.1:8091/;
            }
        }
       }

这是我配置的一个项目信息，访问的流程如下：

配置语法：

http{ 内容表示nginx作为http服务器代理运行的所有逻辑

          server{ 每一个server {} 都代表一个虚拟服务器,接收请求,
          配置逻辑不同,到达nginx的请求会分配给不同的server处理
          虚拟服务器内容}

          server{
              虚拟服务器内容
           }
          server{
              虚拟服务器内容
           }
}

**server**
 在http的内容中可以配置多个server,每个server都是一个可以接收http请求的虚拟服务器,和能接受http请求的真实服务器是一样
 
**listen**
 表示该server在nginx中运行时监听的nginx服务器上所有该端口的访问
 
**server_name**
 listen发现请求后,判断请求中的host头,匹配则进入该server.不同的2个server配置中,监听端口和域名名称不能相同
 
**location /**
 负责计算请求uri路径,判断和规则匹配与否,一旦匹配进入到location内部,不匹配则不处理. location /表示所有路径以/开始的都能匹配上
 
**proxy_pass**
 代理路径,一旦进入location,可以通过这个关键字转向后端服务器.

3.location的匹配规则和优先级：

在配置文件中的server中，配置了一个location，其作用其实相当于可以做过滤，把符合匹配条件的请求发送到指定服务器，其他不满足的请求过滤掉。

4.负载均衡：

轮询：
比如说有三个端口8091 8092 8093，使用轮询的话就是轮番寻访这三个端口，比如第一个请求访问8093，第二个访问8092，第三个访问8091.

使用轮询需要引入关键字upstream（也是在配置文件中进行），使用list来进行管理。名为ouservers的list列表：

轮询中的权重配置：
在轮询的基础上，可以加入权重配置。这样就可以根据不同服务器的性能，来分配不同的权重，性能好的权重大，性能差的权重小，权重为0表示不再访问。

upstream ouservers{
        server 127.0.0.1:8091 wegith=1;
        server 127.0.0.1:8092 weight=1;
        server 127.0.0.1:8093 weight=1;
}

5.动静分离

静态资源访问：
所谓的动静分离，实际上就是把web项目中的静态资源（js，html，css，img），从web项目中剥离出来放入nginx中来访问，方法就是把原来web项目static文件夹中的静态资源，放到nginx的根目录下，文件名为easymall。
这样所有的请求和/匹配的，无论后面/xxx/xxx什么什么的，都会与这个location匹配，然后进入到easymall文件中寻找对应的静态资源。

location /{
			#相对于nginx的根目录
			root easymall;
		       }

动态资源的访问：
所谓的动态资源访问，其实就是访问后台代码，从contrller层进入。

location =/user/query/point {
			#转向ouservers集群
			proxy_pass http://ouservers/user/query/point;
		}

流程：前端通过nginx来进行静态资源的访问，当你点击用户积分查询的时候，就需要使用后台代码的动态资源来查询，我们可以看到在controller层中的注解中表明了这个访问路径，所以在location中我们使用精确匹配来执行，就可以找到该动态资源。