springboot面试

springboot架构图

1.springboot的优势

Spring Boot 的最大的优势是“约定优于配置“。“约定优于配置“是一种软件设计范式，开发人员按照约定的方式来进行编程，可以减少软件开发人员需做决定的数量，获得简单的好处，而又不失灵活性。

2.springboot中 “约定优于配置“的具体产品体现

SpringBoot Starter、SpringBoot Jpa 都是“约定优于配置“的一种体现。都是通过“约定优于配置“的设计思路来设计的，Spring Boot Starter 在启动的过程中会根据约定的信息对资源进行初始化；SpringBoot Jpa 通过约定的方式来自动生成Sql ，避免大量无效代码编写。

3.SpringBoot自动配置原理

注解 @EnableAutoConfiguration, @Configuration, @ConditionalOnClass 就是自动配置的核心。
@EnableAutoConfiguration 给容器导入META-INF/spring.factories 里定义的自动配置类。筛选有效的自动配置类。

4.Spring Boot Starter 的工作原理

Spring Boot 在启动的时候会干这几件事情：① Spring Boot 在启动时会去依赖的 Starter 包中寻找 resources/META-INF/spring.factories 文件，然后根据文件中配置的 Jar 包去扫描项目所依赖的 Jar 包。② 根据 spring.factories 配置加载 AutoConfigure 类。③ 根据 @Conditional 注解的条件，进行自动配置并将 Bean 注入 Spring Context。

5.springboot核心配置文件

bootstrap.properties 和 application.properties是核心配置文件。
单纯做 Spring Boot 开发，可能不太容易遇到 bootstrap.properties 配置文件，但是在结合 SpringCloud时，这个配置就会经常遇到了，特别是在需要加载一些远程配置文件的时侯。
spring boot 核心的两个配置文件：bootstrap (. yml 或者 . properties)：boostrap 由父 ApplicationContext 加载的，比 applicaton 优先加载，配置在应用程序上下文的引导阶段生效。一般来说我们在 SpringCloudConfig 或者Nacos 中会用到它。且boostrap 里面的属性不能被覆盖。application (. yml 或者 . properties)由ApplicatonContext加载，用于springboot项目的自动化配置。

6.微服务同时调用多个接口，怎么支持事务

支持分布式事务，可以使用SpringBoot集成Aatomikos来解决，但是我一般不建议这样使用，因为使用分布式事务会增加请求的响应时间，影响系统的TPS。一般在实际工作中，会利用消息的补偿机制来处理分布式的事务。

7.springboot安全框架，权限是如何设计。

SpringSecurity是专门针对基于Spring项目的安全框架，充分利用了依赖注入和AOP来实现安全管控。

OAuth是一个关于授权的开放网络标准，在全世界得到的广泛的应用，目前是2.0的版本。OAuth2在“客户端”与“服务提供商”之间，设置了一个授权层(authorization layer)。“客户端”不能直接登录“服务提供商”，只能登录授权层，以此将用户与客户端分离。“客户端”登录需要OAuth提供的令牌，否则将提示认证失败而导致客户端无法访问服务。

JWT是一种用户双方之间传递安全信息的简洁的、URL安全的表述性声明规范。JWT（Json Web Token）作为一个开放的标准（RFC 7519），定义了一种简洁的、自包含的方法用于通信双方之间以Json对象的形式进行安全性信息传递，传递时有数字签名所以信息时安全的，JWT使用RSA公钥密钥的形式进行签名。

Shiro是 pache旗下开源的一款强大且易用的Java安全框架，身份验证、授权、加密、会话管理。 相比Spring Security而言Shiro 更加轻量级，且 API 更易于理解。Shiro 主要分为 安全认证 和 接口授权 两个部分，其中的核心组件为 Subject、SecurityManager、Realms，公共部分 Shiro 都已经为我们封装好了，我们只需要按照一定的规则去编写响应的代码即可。

8.Spring Profiles配置

Spring Profiles允许用户根据配置文件（dev，test，prod等）来注册 bean。因此，当应用程序在开发中运行时，只有某些bean可以加载，而在 prod中，某些其他 bean 可以加载。假设我们的要求是Swagger文档仅适用于QA环境，并且禁用所有其他文档，这可以使用配置文件来完成。

9.微服务中session共享

在微服务中，一个完整的项目被拆分成多个不相同的独立的服务，各个服务独立部署在不同的服务器上，各自的session被从物理空间上隔离开了。但是经常，我们需要在不同微服务之间共享 session，常见的方案就是Spring Session + Redis 来实现 session 共享。将所有微服务的 session 统一保存在 Redis 上，当各个微服务对 session 有相关的读写操作时，都去操作 Redis 上的 session 。这样就实现了 session 共享，Spring Session 基于 Spring 中的代理过滤器实现，使得 session 的同步操作对开发人员而言是透明的，非常简便。

10.设计无状态服务

对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。