dataset的去重计数 g2_去互联网公司面试，面试官问我SpringCloud，附答案

下面整理了一些面试的过程中被问到的Spring相关的题目，只因简历上写了熟练使用SpringBoot，SpringCloud。希望为即将准备面试的胖友提供一些帮助，平时还是要多关注一些细节的地方！

SpringBoot的优势是什么? 自动配置/依赖的原理是什么?

SpringBoot可以快速一键搭建一个基于Spring的生产就绪的应用框架，简化Spring应用的初始搭建以及开发过程：

• 最大的优势在于简化配置和简化编码方面，简化了之前开发Spring应用繁琐的配置，它内部集成了常用的第三方库配置，SpringBoot中这些第三方库几乎可以零配置的开箱即用，大部分SpringBoot应用都只需要非常少量的配置代码和极简的maven pom 文件的配置，使得开发者可以更专注于业务逻辑的开发。
• 简化部署，SpringBoot内置了Tomcat, 我们只需要把项目打成jar包就可以一键启动
• 简化监控，我们可以直接使用spring-boot-start-actuator对服务进行运行期性能和健康的监控

自动配置原理

SpringBoot自动配置自带了很多了配置类，自动配置建立在spring条件化配置基础之上的：

1. 首先SpringBoot的主配置类上的@SpringBootApplication 开启了自动配置功能@EnableAutoConfiguration
2. @EnableAutoConfiguration 利用AutoConfigurationImportSelector将META-INF/spring.factories里面配置的所有xxxAutoConfiguration的配置类都加入容器中，用他们来做自动配置。spring-boot-autoconfiguration的jar 文件里面包含了很多的配置类，比如jpa， mvc，redis,neo4j。用户可以自己选择是否在程序里面使用他们，这些配置类构成了Springboot的自动配置。 尽管这些配置存在与应用程序的ClassPath中，但是在满足某些条件之前应用会忽略这个配置，比如： Spring启动的时候会做几百次这样的检查，比如检查Jdbctemplate是不是在Classpath里面，如果是就会配置一个对应的jdbcTemplate的配置Bean。 所有的这些配置都是尽量的不让开发者自己去写配置。

SpringCloud里你还对哪些组件比较熟悉?

服务注册中心Eureka

服务提供者向服务注册中心进行服务的注册，并周期性的发送心跳来更新服务信息，服务消费者拉取服务注册中心的服务列表并维护在本地，并从服务列表中拉取一个服务进行消费。

Eureka本身支持高可用，可以通过集群的方式部署，Eureka Server之间也可以相互注册，相互同步服务信息。

• 失效服务的剔除： 比如超过30s没有心跳的服务，就会被Eureka标记为不可用
• 自我保护机制： ​ 当Eureka 与其它服务之间的心跳大面积失败的时候，它会认为可能是自己的问题，比如自己网络不好，就会把注册的信息保护起来。这时如果有消费者来访问，可能就会拿到真正过期的服务的情况。

Ribbon负载均衡器

• Ribbon 是一个基于HTTP的客户端负载均衡器，可以在客户端负载均衡访问服务提供者列表提供的服务
• Ribbon 提供了一系列完善的配置项如连接超时，重试等，Ribbon会自动的某种算法去连接机器

Fegin

• 微服务之间声明式的调用，整合了Ribbon和Eureka，关键机制是使用了动态代理，让用户不用自己去写HTTP请求，让客户端觉得调用本地接口就像调用其它服务一样。 首先，对于某个接口定义了@FeginClient 注解，Fegin就会针对这个接口创建一个动态代理 接着，调用接口的时候，本质上是调用Fegin创建的动态代理 Fegin 会根据接口上的@RequestMapping等注解，来动态构造要请求的服务的地址 针对这个地址，发起请求，解析响应

Zuul

Zuul的原理： 通过一个统一的Servlet入口ZuulServlet拦截所有的请求，然后通过ZuulFilter链对请求做拦截和过滤处理。Zuul大部分功能都是通过过滤器来实现的，Zuul中定义了4种标准的过滤器，这些过滤器对应于请求的典型生命周期：

1. PRE: 请求路由到某个服务之前调用，可以实现身份验证等
2. ROUTING: 用于构建发送给微服务的请求，并通过HttpClient 或 Ribbon 请求微服务
3. POST: 在请求路由到微服务以后执行，可以为响应结果添加Http Header, 将结果发送给客户端
4. ERROR: 在其它阶段发生错误的时候执行该过滤器

• 客户端只需要请求Zuul网关就可以了，无需要调用特定微服务,由Zuul网关负责转发请求，这样开发就可以得到简化，易于做监控，易于安全认证(比如不需要再每一个微服务上都进行认证)负载均衡等。

Config

微服务数量比较多的时候，配置管理就比较复杂了，SpringCloud Config通过分布式配置中心来统一管理配置文件并可以实时更新。Config Server用于配置属性的存储，Config Client用于服务属性的读取。

Bus

当配置文件需要动态更新的时候，可以通过Bus在不关闭服务的情况下更新我们的配置。

Hystrix 熔断限流降级

• 防止因服务提供者的不可用导致服务调用者的不可用，并将不可用逐渐放大雪崩的过程。

Hystrix熔断过程讲一下? Hystrix实现原理讲一下? 线程池和信号量熔断区别?

• 熔断过程：当用户请求量大或者缓存击穿，会照成后端服务提供者的瞬间超负荷允许，引起服务不可用，当Hystrix检查到超时或者出现异常的时候，就会执行fallback方法而不是让client一直等待或重试。
• 服务降级过程： 当服务压力剧增时，可以根据流量情况对一些服务的页面做降级，比如返回一个默认值或者返回一个提示，让用户稍后重试之类。如果目标服务情况好转则恢复正常调用。

Hystrix的实现可以基于线程池或信号量的方式：

• 基于线程池： 在服务和请求之间增加了一个线程池，用户的请求将不再直接访问服务，而是先经过熔断器，然后通过线程池中空闲线程来访问服务，如果这个时候熔断器是打开的，说明已经熔断了，直接进行降级处理。 当线程池饱和并且请求队列阻塞的时候，可以提前拒绝服务。
• 基于信号量：当请求进入熔断器时，会有一个计数的信号量，每来一个请求数，计数器加1，结果大于最大请求的时候，就返回false，发生信号量拒绝事件，执行降级逻辑。当请求离开熔断器时，执行release()，计数器减1。信号量模式下，接收请求和执行下游依赖在同一个线程内完成，不存在线程上下文切换带来的性能开销。

线程池和信号量熔断区别?

• 资源消耗方面，信号量只是个计数器，资源消耗小，如果有数百个服务实例，线程池做隔离的开销过大，会有上下文的切换开销
• 信号量的调用时同步的，每次调用都会阻塞调用方的线程直到结果返回，不支持异步，不支持超时，线程池支持超时返回
• 信号量是达到最大请求量阈值时熔断，线程池时达到最大线程数熔断

Hystrix/Feign/Ribbon之间如何配合的, 代码上架构是怎样的?

Fegin 通过代理模式自动将所有的方法用Hystrix进行了包装，目的是在调用方实施针对被调用微服务的熔断逻辑，针对被调用服务设置超时时间，一旦超时就会进入熔断逻辑，而这个故障指标信息也会返回给Hystrix组件，hystrix根据故障信息打开断路器，之后所有针对该微服务的请求都会直接进入熔断逻辑，直到故障恢复关闭断路器为止。

• 首先Ribbon从Eureka Client 里面获取对应的服务注册表，比如服务的ip 和 端口
• 然后Ribbon使用默认的的Round Robin算法，从中选择一台机器
• Fegin就会针对这台机器，构造代理并发起http请求

总结

SpringCloud SpringBoot 这套技术栈，大家平时自己使用的过程，可能觉得比较简单，不过了解其底层实现细节，对我们写出高性能的服务架构肯定大有裨益。比如在了解原理后，我们知道Hystrix在有大量的请求时，如果默认使用线程池可能会频繁的线程切换，更加重系统性能，这时候可以考虑切换了。

2020年最新源码分析课程资料，关注私信【555】获取，还可领取更多Java面试题资料和Java架构学习资料