1.springmvc原理
1.用户发送请求至前端控制器DispatcherServlet(也叫中央处理器).
2.DispatcherServlet收到请求调用HandlerMappering处理器映射器
3.处理器映射器找到具体的处理器（可以根据xml配置、注解进行查找），生成处理器对象及处理器拦截器（如果有则生成）一并返回给DispatcherServlet.
4.DispatcherServlet调用HandlerAdapter处理器适配器。
5.HandlerAdapter经过适配调用具体的处理器（Controller,也叫后端控制器）。
6.Controller执行完成返回ModelAndView.
7.HandlerAdapter将controller执行结果ModelAndView返回给DispatcherServlet.
8.DisPatcherServlet将ModelAndView传给ViewReslover视图解析器。
9.ViewReslover解析后返回具体View.
10.DispatcherServlet根据View进行渲染视图（即将模型数据填充至视图中）。
11.DispatcherServlet响应用户。
3.springboot核心注解，以及项目中常用的注解有哪些？比如@controller、@service等
-
SpringBootConfiguration
-
ComponentScan
-
EnableAutoConfiguration
@Data：实体类不用手动添加get set 方法
@NoArgsConstructor: 自动生成无参数构造函数
@AllArgsConstructor: 自动生成全参数构造函数
@Mapper
KoneLogsMapper文件中使用，标志该文件是mapper文件
@Select 和@SelectProvider的区别
@Select 后直接写SQL语句
@Select("SELECT * FROM ***_logs WHERE cardtype=#{cardType} AND cardid=#{cardId} AND " +
"NOT isdeleted ORDER BY date,fromtime ")
@SelectProvider后引用文件
@SelectProvider(type = ******Provider.class, method = “selectParam”)
KoneLogsData findById(@Param(“id”) Integer id);
@Service
标志该层是Service 文件
@Autowired
自动导入相应文件
@ExceptionCatcher(“添加日志失败!”)
异常提示语抛出
@ApiIgnore
项目继承了查看测试接口的swagger，@ApiIgnore是为了让注解忽略这个API
@Controller和@RestController的区别
@RestController注解相当于@ResponseBody ＋ @Controller合在一起的作用。
-
如果只是使用@RestController注解Controller，则Controller中的方法无法返回jsp页面，或者html，配置的视图解析器 InternalResourceViewResolver不起作用，返回的内容就是Return 里的内容。
-
如果需要返回到指定页面，则需要用 @Controller配合视图解析器InternalResourceViewResolver才行。
如果需要返回JSON，XML或自定义mediaType内容到页面，则需要在对应的方法上加上@ResponseBody注解。
@RequestBody与@RequestParam的区别
@RequestBody主要用来接受前端传递给后端的json字符串中的数据（请求体中的数据）；GET方式无请求体，所以使用@RequestBody接受数据时，前端不能使用GET方式提交数据，而是要用POST方式进行提交。在后端的同一个接收方法里，@RequestBody与@RequestParam()可以同时使用，@RequestBody最多只能有一个，而@RequestParam()可以有多个。
注：如果参数前写了@RequestParam(xxx)，那么前端必须有对应的xxx名字才行(不管其是否有值，当然可以通
过设置该注解的required属性来调节是否必须传)，如果没有xxx名的话，那么请求会出错，报400。
@PostMapping(“addLog”)
Post方式接受请求体，
@GetMapping(“deleteLog”)
Get方式接受参数
@MapperScan (springBoot 启动文件中使用这个注解扫描Mapper文件)
@MapperScan(basePackages = “com.****e.dao”)
@EnableScheduling
spring自带的定时任务功能@EnableScheduling
@Component and @ComponentScan 的区别
@Component 和 @ComponentScan的使用目的不一样 在某个类上使用@Component注解，表明当需要创建类时，这个被注解的类是一个候选类。就像是举手。
@ComponentScan 用于扫描指定包下的类。就像看都有哪些举手了。
@SpringBootApplication
该源码内包含了@ComponentScan,@EnableAutoConfiguration,@SpringBootConfiguration
@EnableAutoConfiguration，这个注解的作用与@Configuration作用相同，都是用来声明当前类是一个配置类．
@EnableAutoConfiguration是springboot实现自动化配置的核心注解，通过这个注解把spring应用所需的bean注入容器中
4.springcloud核心组件
1.Eureka:
1、Eureka服务端：** 也称服务注册中心，同其他服务注册中心一样，支持高可用配置。如果Eureka以集群模式部署，当集群中有分片出现故障时，那么Eureka就转入自我保护模式。它允许在分片故障期间继续提供服务的发现和注册，当故障分片恢复运行时，集群中其他分片会把它们的状态再次同步回来
2、Eureka客户端：** 主要处理服务的注册与发现。客户端服务通过注解和参数配置的方式，嵌入在客户端应用程序的代码中，在应用程序运行时，Eureka客户端想注册中心注册自身提供的服务并周期性地发送心跳来更新它的服务租约。同时，它也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期性地刷新服务状态
3、Eureka Server** 的高可用实际上就是将自己作为服务向其他注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用效果。
2.ribbon
Ribbon是一个基于HTTP和TCP的客户端负载均衡器，它可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到服务均衡的作用。当Ribbon和Eureka联合使用时，Ribbon的服务实例清单RibbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务端列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来去定服务端是否已经启动
在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端的清单来自于服务注册中心（比如Eureka）。在客户端负载均衡中也需要心跳去维护服务端清单的健康性，只是这个步骤需要与服务注册中心配合完成。
通过Spring Cloud Ribbon的封装，我们在微服务架构中使用客户端负载均衡调用只需要如下两步：
1、 服务提供者只需要启动多个服务实例并且注册到一个注册中心或是多个相关联的服务注册中心
2、 服务消费者直接通过调用被@LoadBalanced注解修饰过的RestTemplate来实现面向服务的接口调用
3.feign
Feign的关键机制是使用了动态代理
1、 首先，对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理
2、 接着调用接口的时候，本质就是调用Feign创建的动态代理
3、 Feign的动态代理会根据在接口上的@RequestMapping等注解，来动态构造要请求的服务的地址
4、 针对这个地址，发起请求、解析响应
Feign是和Ribbon以及Eureka紧密协作的
1、 首先Ribbon会从Eureka Client里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口
2、 然后Ribbon就可以使用默认的Round Robin算法，从中选择一台机器
3、 Feign就会针对这台机器，构造并发起请求
4.Hystrix
在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的瘫痪，这样的架构相较传统架构更加不稳定。为了解决这样的问题，产生了断路器等一系列的服务保护机制
在分布式架构中，当某个服务单元发生故障之后，通过断路器的故障监控，向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延
Hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能
Hystrix使用舱壁模式实现线程池的隔离，它会为每一个依赖服务创建一个独立的线程池，这样就算某个依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他的依赖服务
5.Zuul
Spring Cloud Zuul通过与Spring Cloud Eureka进行整合，将自身注册为Eureka服务治理下的应用，同时从Eureka中获得了所有其他微服务的实例信息
对于路由规则的维护，Zuul默认会将通过以服务名作为ContextPath的方式来创建路由映射
Zuul提供了一套过滤器机制，可以支持在API网关无附上进行统一调用来对微服务接口做前置过滤，已实现对微服务接口的拦截和校验。
总结：
Eureka： 各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且EurekaClient还可以反过来从Eureka Server拉取注册表，从而知道其他服务在哪里
Ribbon： 服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台
Feign： 基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求
Hystrix： 发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
Zuul： 如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务
5.单例模式
懒汉式单例、饿汉式单例、登记式单例
单例模式有以下特点：
1、单例类只能有一个实例。
2、单例类必须自己创建自己的唯一实例。
3、单例类必须给所有其他对象提供这一实例。