Spring常见问题整理（四）

文章目录

• • 一、SpringMVC
  • • 如何解决 get 和 post 乱码问题
    • Spring MVC的工作流程/DispatcherServlet 的工作流程
    • SpringMvc和AJAX相互调用
    • 实现无XML零配置的SpringMVC
    • SpringMVC的拦截器和过滤器有什么区别？执行顺序？
  • 二、Spring Boot
  • • SpringBoot的特性
    • Spring和SpringBoot的关系和区别
    • SpringBoot的核心注解
    • springboot的自动配置原理？
  • 三、微服务
  • • 微服务架构的优缺点
    • • 优点
      • 缺点
    • SOA、分布式、微服务之间有什么关系和区别？
    • 参考视频链接：

一、SpringMVC 如何解决 get 和 post 乱码问题

解决post请求乱码问题：在web.xml中配置一个CharacterEncodingFilter过滤器，设置成utf­8

CharacterEncodingFilter
org.springframework.web.filter.CharacterEncodingFilter

 
encoding 
utf‐8 

 

CharacterEncodingFilter
/*

get请求中文参数出现乱码解决方法有两个：
①修改tomcat配置文件添加编码与工程编码一致，如下：

②另外一种方法对参数进行重新编码：

  String userName = new String(request.getParamter("userName").getBytes("ISO8859‐1"),"utf‐8")

ISO8859­1是tomcat默认编码，需要将tomcat编码后的内容按utf­8编码

Spring MVC的工作流程/DispatcherServlet 的工作流程

（1）用户发送请求至前端控制器DispatcherServlet；
（2） DispatcherServlet收到请求后，调用HandlerMapping处理器映射器，请求获取Handle；
（3）处理器映射器根据请求url找到具体的处理器，生成处理器对象及处理器拦截器(如果有则生成)一并返回给DispatcherServlet；
（4）DispatcherServlet 调用 HandlerAdapter处理器适配器；
（5）HandlerAdapter 经过适配调用 具体处理器(Handler，也叫后端控制器)；
（6）Handler执行完成返回ModelAndView；
（7）HandlerAdapter将Handler执行结果ModelAndView返回给DispatcherServlet；
（8）DispatcherServlet将ModelAndView传给ViewResolver视图解析器进行解析；
（9）ViewResolver解析后返回具体View；
（10）DispatcherServlet对View进行渲染视图（即将模型数据填充至视图中）
（11）DispatcherServlet响应用户。

SpringMvc和AJAX相互调用

（1）加入Jackson.jar
（2）在配置文件中配置json的消息转换器.(jackson不需要该配置HttpMessageConverter）

（3）在接受Ajax方法里面可以直接返回Object,List等,但方法前面要加上@ResponseBody注解。

springMVC对数据Message的处理操作提供了一个接口,HttpMessageConverter，用来对参数值和返回值的转换处理。
在请求和返回过程中可以进行转换json

实现无XML零配置的SpringMVC

1. 省略web.xml
   a. servlet3.0之后规范中提供了SPI扩展:meta-INF/services/javax.servlet.ServletContainerInitializer
   b. SpringMVC通过实现ServletContainerInitializer接口
   c. 动态注册ContextLoaderListener 和DispatcherServlet并创建子父容器(Application)
2. 省略spring.xml和spring-mvc.xml(只是sprinmvc方式 ，springboot在自动配置类完成) 配置类–xml
   a. 实现一个继承AbstractAnnotationConfigDispatcherServletInitializer的类
   b. 该类就实现了ServletContainerInitializer，它会创建ContextLoaderListener 和DispatcherServlet
   c. 还会创建父子容器， 创建容器时传入父子容器配置类则可以替代spring.xml和spring-mvc.xml

SpringMVC的拦截器和过滤器有什么区别？执行顺序？

拦截器不依赖与servlet容器，过滤器依赖与servlet容器。
拦截器只能对action请求(DispatcherServlet 映射的请求)起作用，而过滤器则可以对几乎所有的请求起作用。
拦截器可以访问容器中的Bean(DI)，而过滤器不能访问（基于spring注册的过滤器也可以访问容器中的bean）。
执行顺序：


多个过滤器的执行顺序跟xml文件中定义的先后关系有关。当然，对于多个拦截器它们之间的执行顺序跟在SpringMVC的配置文件中定义的先后顺序有关。

二、Spring Boot SpringBoot的特性

SpringBoot的用来快速开发Spring应用的一个脚手架、其设计目的是用来简新Spring应用的初始搭建以及开发过程。

1. SpringBoot提供了很多内置的Starter结合自动配置，对主流框架无配置集成、开箱即用。
2. SpringBoot简化了开发，采用JavaConfig的方式可以使用零xml的方式进行开发；
3. SpringBoot内置Web容器无需依赖外部Web服务器，省略了Web.xml，直接运行jar文件就可以启动web应用；
4. SpringBoot帮我管理了常用的第三方依赖的版本，减少出现版本冲突的问题；
5. SpringBoot自带了监控功能，可以监控应用程序的运行状况，或者内存、线程池、Http 请求统计等，同时还提供了优雅关闭应用程序等功能。

Spring和SpringBoot的关系和区别

SpringBoot是Spring生态的产品。
Spring framework是一个容器框架 SpringBoot 它不是一个框架、它是一个可以快速构建基于Spring的脚手架(里面包含了 Spring 和各种框架），为开发Spring生态其他框架铺平道路两个不是一个层面的东西， 没有可比性。

SpringBoot的核心注解

1. @SpringBootApplication注解：这个注解标识了一个SpringBoot工程，它实际上是另外三个注解的组合

2. @SpringBootConfiguration：这个注解实际就是一个@Configuration，表示启动类也是一个配置类

3. @EnableAutoConfiguration：向Spring容器中导入了一个Selector，用来加载ClassPath下SpringFactories中所定义的自动配置类，将这些自动加载为配置Bean

4. @Conditional 也很关键， 如果没有它我们无法在自定义应用中进行定制开发
   @ConditionalOnBean、
   @ConditionalOnClass、
   @ConditionalOnexpression、
   @ConditionalOnMissingBean等。

springboot的自动配置原理？

1. 通过@SpringBootConfiguration 引入了 @EnableAutoConfiguration (负责启动自动配置功能）
2. @EnableAutoConfiguration 引入了 @import
3. Spring 容器启动时：加载Ioc容器时会解析 @import 注解
4. @import 导入了一个deferredimportSelector(它会使 SpringBoot 的自动配置类的顺序在最后，这样方便我们扩展和覆盖？)
5. 然后读取所有的 /meta-INF/spring.factories 文件（SPI)
6. 过滤出所有 AutoConfigurtionClass 类型的类
7. 最后通过 @ConditioOnXXX 排除无效的自动配置类

三、微服务 微服务架构的优缺点 优点

1.分工协作
单体：影响开发效率,发布和迭代性差；项目启动慢， 每个人对整体的项目都要有所把握； 业务缩减后如果语言不一致开发人员面临流失。
拆分：提高开发效率和敏捷性ꞏ；单个服务启动快， 专人处理专事专注自己的服务； 充分利用项目开发人员（哪怕是不同的语言不同框架，不同存储技术，也可以）
2.并发能力
单体：整体集群，易造成系统资源浪费；之前下单功能要去集群无法准确评测最大并发量，因为所有的功能都在一起，无法准确预估扩容的服务器。
拆分：服务集群，充分利用服务器资源； 现在只需要针对下单服务进行压测就可以得到，下单功能具体
能承受的并发量最高水位，从而更准确的进行扩容。
3.维护能力（维护困难）
单体：随着业务量增加，应用慢慢膨胀，后续可能会变得牵一发而动全身，难以维护。
拆分：根据功能垂直拆分，责任更加分明，维护更加精准。
4.容错
单体：单点故障，一个功能OOM导致整个应用都不可用
拆分：弱依赖的服务出现故障，可以进行熔断（隔离） 依然不影响主业务正常使用
5.扩展
单体：难以技术升级
拆分：新的服务采用任意新技术（技术多样性）

缺点

分布式
分布式系统较难编程，因为远程调用速度很慢，并且总是面临失败的风险。对于开发人员的技术要求更高
最终一致性
对于分布式系统而言，保持强一致性非常困难，这意味着每个人都必须管理最终一致性。
运维复杂性
微服务必定带来开发、上线、运维的复杂度的提高，如果说单体应用复杂度为 10，实施了微服务后的复杂度将是 100，配备了相应的工具和平台后，可以将复杂度降低到 50，但仍然比单体复杂的多。
隐式接口
服务和服务之间通过接口来“联系”，当某一个服务更改接口格式时，可能涉及到此接口的所有服务都需要做调整。
重复劳动
在很多服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务
团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则。

SOA、分布式、微服务之间有什么关系和区别？

1. 分布式架构是指将单体架构中的各个部分拆分，然后部署不同的机器或进程中去，SOA和微服务基本上都是分布式架构的。
2. SOA是一种面向服务的架构，系统的所有服务都注册在总线上，当调用服务时，从总线上查找服务信息，然后调用。
3. 微服务是一种更彻底的面向服务的架构，将系统中各个功能个体抽成一个个小的应用程序，基本保持一个应用对应的一个服务的架构

参考视频链接：

https://www.bilibili.com/video/BV15Q4y1m78a?p=46