Java面试八股文(2023最新)--SpringCloud微服务面试题
目录
1. SpringCloud和SpringBoot的区别和关系？
2. SpringCloud由哪些组件组成?
3. Eureka和Zookeeper的区别？
4. Zookeeper保证的CP和Eureka保证的AP是什么？
5. Eureka的工作原理
6. Feign服务调用的过程
7. 什么是Hystrix？
8. 微服务之间如何通信？
9. SpringCloud和dubbo的区别？
10. Eureka怎么实现高可用？
11. 什么是网关？网关的作用？
12. 什么是SpringCloudZuul（服务网关）
13. 网关与过滤器的区别？
14. 常用网关框架
15. Zuul和Nginx区别?
16. 负载均衡的意义是什么？
17. Ribbon是什么？
18. Ribbon底层实现原理
19. Hystrix防止雪崩的方式？
20. 微服务中，如何保护服务？
21. 什么是服务的雪崩？产生的原因？
22. SpringCloudNetflix
1. SpringCloud和SpringBoot的区别和关系？
- SpringBoot专注于快速方便的开发单个个体微服务。
- SpringCloud关注全局的微服务协调治理框架以及一整套的落地解决方案，它将SpringBoot开发的一个个单体的微服务整合并管理起来，为各个微服务之间提供：配置管理，服务发现，断路器，路由，微代理，事件总线等集成服务。
- SpringBoot是可以离开SpringCloud独立使用，但是SpringCloud离不开SpringBoot，属于依赖关系。
- 总结：SpringBoot专注于快速，方便地开发单个微服务个体，SpringCloud关注全局的服务治理框架。
2. SpringCloud由哪些组件组成?
- Eureka和Nacos：服务注册与发现。
- Zuul和SpringCloudGateway：服务网关。
- Ribbon：客户端负载均衡。
- Feign：声明性的Web服务客户端。
- Hystrix：断路器。
- SpringCloudConfig或Nacos：分布式统一配置管理。
3. Eureka和Zookeeper的区别？
- Zookeeper中的节点服务挂了就要选举，在选举期间注册服务瘫痪，虽然服务最终会恢复，但是选举期间不可以用，选举就是改微服务做了集群，必须有一台主机其他都是从机。
- Eureka各个节点是平等的关系，服务器挂了没关系，只要有一台Eureka就可以保证服务可用，数据都是最新的。如果查询到的数据不是最新的，那是Eureka的自我保护机制导致的。
- Eureka本质上是一个工程，而Zookeeper是一个进程。
- Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，不会像Zookeeper一样使得整个注册系统瘫痪。
- Zookeeper保证的是CP，Eureka保证的是AP。
4. Zookeeper保证的CP和Eureka保证的AP是什么？
这句话是在比较Zookeeper和Eureka两个分布式服务架构的一致性和可用性之间的权衡。
- 一致性：在分布式系统中，所有节点都能够看到相同的数据，并且这些数据会随着时间的推移而同步更新。换句话说，一致性要求所有节点在同一时间看到的应该是相同状态的数据。
- 可用性：分布式系统中，每个请求必须得到响应，并且这个响应必须在有限的时间范围内返回，换句话说，可用性要求系统必须保持能够处理请求的状态。
Zookeeper和Eureka都是提供分布式服务的框架，他们在一致性和可用性做了不同的权衡：
- Zookeeper：保证一致性和分区容错性，也就是所谓的CP。Zookeeper提供了分布式锁，选举算法等功能，通过Zookeeper可以实现高可靠的分布式系统。在Zookeeper集群中，如果某个节点失效或者网络分区，仍然可以保证其余节点的数据一致性。
- Eureka：强调可用性和分区容错性，也就是AP。Eureka提供服务治理，负载均衡等功能，通过Eureka可以方便地实现微服务架构。在一个Eureka集群中，如果某个节点失效或者网络分区，仍然可以保证剩余节点之间的可用性。
因此在选择Zookeeper和Eureka作为分布式服务框架，需要根据具体的场景和需求进行权衡利弊，如果注重数据一致性，并且可以忍受一定的服务不可用，则可以选择Zookeeper；如果需要保证服务高可用，并且接受一定的数据不一致，可以选择Eureka。
5. Eureka的工作原理
Eureka是Netflix开源的基于RESTful API服务发现的框架。它旨在帮助开发者构建更加可靠和可扩展的云端应用，同时也是SpringCloud微服务架构体系中非常重要的一环。
Eureka工作原理可以简单概括为：服务提供者向Eureka注册自己的服务实例，服务消费者从Eureka获取可用的实例列表，并通过负载均衡算法选择其中一个实例进行调用。
工作流程如下：
- 服务提供者启动时，会向Eureka发送注册请求，告知自己的服务实例信息，如IP地址，端口号，服务名等。
- Eureka收到服务提供者的注册请求后，将其存储在自己的注册表中，在心跳检测的机制下，定期检查服务实例的可用性。
- 服务消费者向Eureka发起服务调用请求时，Eureka会返回全部可用的服务实例列表给服务消费者，并根据负载均衡算法选择其中一个实例进行调用，如果发现某个实例不可用，则自动从注册表移除，并告知给消费者。
- 当服务提供者关闭或者网络出现错误，服务实例会自动从注册表删除，并通知Eureka，它会及时更新注册表。
总之Eureka通过心跳检测，服务注册，缓存机制等多种方式，提供了一种可靠的服务发现和负载均衡的解决方案，帮助开发者更好地构建高可用和可扩展的云端应用。
6. Feign服务调用的过程
Feign是一种声明式的，模块化的HTTP客户端，可以轻松地使用Netflix OOS(Ribbon,Hystrix等)实现基于HTTP的服务调用。其调用过程如下：
- 在代码中定义一个接口，并使用@FeignClient注解标记该接口，指定被调用服务的名称和相关配置。
- 通过使用该接口的方法进行服务调用。此时SpringCloud会根据@FeignClient注解中指定的服务名，在服务注册中心查找对应的服务实训，之后再根据Ribboon负载均衡策略选择一个可用的服务实例进行调用。
- Feign会根据接口方法上的请求参数和路径信息生成HTTP请求，再调用远程服务时，可以在请求头部添加自定义的信息(如传递认证信息或用户状态信息)。
- 接着Feign会将HTTP请求发送到选定的服务实例。
- 当服务实例返回响应时，Feign会将相应封装成定义好的接口的返回值类型，返回给调用方。
- 如果远程服务调用失败，Feign能够捕获异常信息并进行处理，如熔断，降级等操作。
总结：使用Feign惊醒服务调用的过程主要包括接口定义，服务选择，HTTP请求转换，响应处理等步骤。它使服务调用更加简明扼要，规范。
7. 什么是Hystrix？
Hystrix是Netflix开源的一款容错框架，主要用于处理复杂分布式系统交互中的延迟和故障，防止因依赖服务的不可用而导致整个系统的崩溃。
在微服务架构中，服务之间的调用是通过HTTP请求完成的。当某个服务因为网络故障或其他原因不能正常响应时，这会导致服务调用方的请求被阻塞，最终可能导致整个系统瘫痪。Hystrix就是为了解决这类问题而诞生的。
Hystrix提供了以下功能：
- 服务熔断：当某个服务出现故障时，Hystrix会将该服务的请求熔断，并且快速返回一个预设好的错误信息，这样就避免了大量请求堆积在不可用的服务上，进而造成更大的故障。
- 线程隔离：可以将每个请求都放到单独的线程中，这样可以防止某个请求耗费更多的时间或资源，导致其他的请求受到影响。
- 请求缓存：使用Hystrix可以快速缓存服务的响应结果，从而减少对服务的请求次数，提高系统的性能。
- 自动降级：当某个服务的响应时间达到一定的阈值，Hystrix会自动降级服务的相应质量，保证系统的可用性。
总之Hystrix是一个非常有用的容错框架，可以有效地提高分布式系统的稳定性和可靠性。而且，Hystrix与SpringCloud等微服务框架紧密集成，使得使用Hystrix在微服务模型中变得更加简单和方便。
8. 微服务之间如何通信？
- 同步通信：Dubbo通过RPC远程过程调用，SpringCLoud通过REST API接口json调用等。
- 同步通信是指调用方发送请求后，必须等待服务端返回响应结果，才能继续执行后面的代码。这种情况下，调用方和服务端之间的通信是实时的，双向的。Dubbo框架通过RPC远程过程调用实现同步通信，而SpringCloud通过REST接口实现同步通信。
- 异步通信：消息队列，如RabbitMq，Kafka，ActiveM等。
- 异步通信是指调用方发送请求后，可以立即返回，并不需要等待服务端响应结果，服务端在处理完请求后再次通知调用方。这种情况下，调用方和服务端之间的通信是间接的，通常采用消息队列方式实现。消息队列是一种典型的异步通信方式，它使用一条消息传递机制，将消息发送到队列中，然后由消费者从队列中取出消息进行处理。常见的消息队列：RabbitMQ，ActiveMQ，Kafka等。
异步通信和同步通信各有优缺点，实际开发根据业务需求选择合适的通信方式。同步通信实用性高，但容易导致调用方阻塞和系统资源消耗过多；异步通信开销小，但是对系统的可靠性较高，需要考虑消息丢失等问题。
9. SpringCloud和dubbo的区别？
SpringCloud和dubbo都是优秀的微服务框架，他们提供了分布式系统开发所需要的核心功能。如：服务注册与发现，负载均衡，服务容错，服务熔断，服务降级等，但是还是存在一些差异：
- 架构设计上的区别：Dubbo采用三层架构：接口层，服务层，实现层。每层都可以配置不通的规则，从而实现更细粒度的控制。SpringCloud采用四层架构，API网关层，服务治理层，控制层，为服务层。
- 通信协议上的区别：Dubbo采用RPC调用方式，支持多种序列化的协议(如Hessian，Protobuf等)，底层通信使用NIO进行封装，具有较高性能；而SpringCloud采用HTTPR ESTful APi接口通信，以json格式进行数据交换。
- 生态系统上的区别：Dubbo生态系统相对单一，基本只有Dubbo自身提供的组件，如注册中心，负载均衡，远程调用等。SpringCloud整合了众多开源组件：Eureka，Zuul，Hystrix等，提供了完整的微服务架构解决方案。
- 配置方式上的区别：Dubbo采用XML配置文件与java注解相结合的方式配置，虽然可读性高，但也导致了配置量庞大，不易维护；而SpringCloud基于SpringBoot的纯Java配置方式，简化了系统配置。
总之，Dubbo主打RPC通信，高性能，多协议支持，灵活拓展等；SpringCloud则以全面的生态系统，灵活的配置方式，集成众多的开源组件，丰富的云原生功能等方面脱颖而出。
10. Eureka怎么实现高可用？
Eureka是一个服务注册与发现的工具，通过Eureka可以将服务提供者的信息注册到EurekaServer并且服务消费者可以从EurekaServer获取可用的服务提供者列表。
保证高可用性，可以采取以下措施：
- EurekaServer集群：通过部署多个EurekaServer实例 组成集群，提高EurekaServer的可用性。再EurekaClint注册时，需要将注册地址设置为多个EurekaServer的地址；这样即使某些EurekaServer宕机，客户端仍然可以发现服务实例。
- 负载均衡：对于EurekaServer集群，可以使用负载均衡分摊请求负载，在请求EurekaServer时自动选择一台可用的服务器进行响应。
- 备份注册中心：可以将EurekaServer注册信息备份到其他存储设备(数据库或文件)，避免注册信息丢失。当EurekaServer宕机，可用快速恢复。
11. 什么是网关？网关的作用？
网关相当于网络服务架构的入口，所有的网络请求必须通过网关转发到具体的服务。网关可用统一管理微服务请求，权限控制，负载均衡，路由转发，监控，安全控制黑名单和白名单等。
12. 什么是SpringCloudZuul（服务网关）
Zuul是对SpringCloud提供的成熟对的路由方案，会根据不同的请求路径，网关会定位到指定的微服务，并代理请求到不同的微服务接口，对外隐蔽了微服务的真正接口地址。
三个重要概念：动态路由表，路由定位，反向代理
- 动态路由表：Zuul支持Eureka路由，手动配置路由，这两种都支持自动更新。
- 路由定位：根据请求路径Zuul有自己的一套定位服务规则以及路由表达式匹配。
- 反向代理：客户端请求到路由网关，网关受理后，再对目标发送请求，拿到响应后再给客户端。
Zuul可用于Eureka，Ribbon，Hystrix等组件配合使用
Zuul使用场景：对外暴露，权限校验，服务聚合，日志审计等
13. 网关与过滤器的区别？
网关是对所有服务的请求进行分析过滤，过滤器是对单个服务而言。
14. 常用网关框架
Nginx，Zuul，Gateway
15. Zuul和Nginx区别?
Zuul是Java语言实现的，主要为java服务提供网关服务，尤其是在微服务架构中可用更加灵活的对网关进行操作。Nginx使用C语言实现，性能高于Zuul，但是实现自定义操作需要熟悉lua语言，对程序员要求较高，可使用Nginx做Zuul集群。
16. 负载均衡的意义是什么？
负载均衡是指将网络流量分发到多个服务器上，以实现系统资源的合理利用和请求处理能力的提高
负载均衡可以改善跨计算机，计算机集群，网络连接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载均衡是指再优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。
17. Ribbon是什么？
Ribbon是Netflix发布的开源项目，主要功能提供客户端的软件负载均衡算法。
Ribbon客户端组件提供一系列完善的配置项，如连接超时，重试等。简单说，就是在配置文件中列出所有的及其，Robbin会自动的帮助你基于某种规则(如轮询，随机等)去连接机器。我们也很容易使用Robbin实现自定义的负载均衡算法。
18. Ribbon底层实现原理
Ribbon使用discoveryClient从注册中心读取目标服务信息，对统一接口请求进行计数。使用%取余算法获取目标服务集群索引，返回获取到的目标服务信息。
19. Hystrix防止雪崩的方式？
- 服务降级：接口调用失败就调用本地方法返回一个空。
- 服务熔断：接口调用失败会进入调用接口提前定义好的熔断方法，返回错误信息。
- 服务隔离：隔离服务之间相互影响。
- 服务监控：在服务发生调用时，会将每秒请求数，成功请求数等运行指标记录下来。
20. 微服务中，如何保护服务？
一般使用Hystrix框架，实现服务隔离来避免出现服务的雪崩效应，从而达到保护服务的效果。当微服务中，高并发的数据库访问量导致服务线程阻塞，使单个服务宕机，服务的不可用会蔓延到其他的服务，引起整体服务灾难性后果，使用服务降级能有效为不同的服务分配资源，一旦服务不可用规则返回友好提示，不占用其他服务资源，从而避免单个服务崩溃引发整体服务的不可用。
21. 什么是服务的雪崩？产生的原因？
雪崩效应使大型互联网项目中，某个服务发生宕机，调用这个服务的其他服务也会发生宕机，大型项目的微服务之间的调用使相通的，这样就会将服务的不可用逐步扩大到各个服务，从而使整个项目的服务宕机崩溃。
发生雪崩的原因：
- 因为Tomcat默认情况只有一个线程池来维护客户端发送的所有请求，这个时候某一接口在某一时刻被大量访问就会占据tomcat线程池的所有线程，其他请求处于等待状态，无法连接到服务接口。
22. SpringCloudNetflix
Netflix OOS开源组件集成，包括Eureka，Hystrix，Ribbon，Feign，Zuul等核心组件。
- Eureka：服务治理组件，包括服务端的注册中心和客户端服务发现的机制。
- Ribbon：负载均衡的服务组件，具有多种负载均衡调用策略
- Hystrix：服务容错组件，实现了断路器模式，为以来服务的出错和延迟提供了容错能力
- Feign：基于Ribbon和Hystrix的声明式服务调用组件。
- Zuul：API网关组件，对请求提供路由以及过滤功能。