SpringCloud常见问题

1、什么是Spring Cloud？

Spring Cloud是一款基于Spring Boot框架开发的微服务框架，它为开发人员提供了一系列的组件和工具，可以帮助开发人员快速构建和部署微服务，提高开发效率和项目可维护性。Spring Cloud提供了包括服务注册与发现、配置中心、负载均衡、断路器、分布式跟踪等一系列的功能和组件，可以帮助开发人员快速构建和部署微服务。

2、使用Spring Cloud有什么优势？

1. 简化微服务开发：Spring Cloud提供了一套完整的微服务解决方案，包括服务注册与发现、配置中心、服务网关、智能路由、负载均衡、断路器、监控跟踪、分布式消息队列等，使得开发人员可以快速构建和部署微服务应用。
2. 提高微服务可靠性：Spring Cloud提供了断路器、重试机制、容错机制等功能，可以提高微服务的可靠性和稳定性。
3. 统一管理微服务配置：Spring Cloud提供了配置中心组件，可以将微服务的配置信息集中管理，方便维护和更新。
4. 支持多种微服务生态系统：Spring Cloud集成了多个开源微服务生态系统，如Consul、Eureka、Zookeeper等，可以根据具体需求选择合适的组件。
5. 易于集成：Spring Cloud与Spring Boot集成紧密，开发人员可以充分利用Spring Boot的开发便利性，快速构建和部署微服务应用。

3、Spring Boot与Spring Cloud的区别?

1. 目标不同：Spring Boot的目标是简化Spring应用程序的开发和部署，而Spring Cloud的目标是为微服务提供一套综合性的解决方案。
2. 功能不同：Spring Boot主要提供了自动配置、快速开发、内嵌服务器等功能，而Spring Cloud则提供了服务注册、配置中心、负载均衡、断路器、网关等微服务相关的功能。
3. 集成方式不同：Spring Boot可以作为一个基础框架，用来开发和部署单个应用程序，也可以作为一个模块集成到其他框架中，如Spring Cloud。而Spring Cloud是基于Spring Boot构建的，需要依赖Spring Boot才能使用。
4. 适用场景不同：Spring Boot主要适用于单个应用程序的开发和部署，而Spring Cloud则适用于大规模分布式系统的开发和部署。

4、Spring Cloud与Dubbo由什么区别？

1. 设计理念不同：Spring Cloud基于Spring Boot构建的微服务框架，强调服务之间的解耦和高度灵活性；而Dubbo是阿里巴巴推出的RPC框架，强调服务的高性能和可靠性。
2. 服务注册与发现：Spring Cloud使用Eureka或Consul等服务注册中心来管理服务实例，并提供服务注册和发现的功能；而Dubbo则使用自己的服务注册中心–ZooKeeper来管理服务实例，并提供服务注册和发现的功能。
3. 服务调用方式：Spring Cloud使用HTTP协议进行服务之间的通信，并且支持RESTful API风格；而Dubbo则采用RPC协议进行服务之间的通信，通常采用Java对象来传递数据。
4. 跨语言支持：Spring Cloud支持多种语言（如Node.js、Ruby等），而Dubbo主要支持Java语言。
5. 社区活跃度：Spring Cloud是目前最为流行的微服务框架之一，拥有活跃的开发者社区和丰富的生态系统；而Dubbo的开发者社区相对较小，生态系统也不如Spring Cloud完善。

5、Spring Cloud核⼼组件有哪些？

1. Eureka：服务注册与发现组件，用于管理服务的注册和发现。
2. Ribbon：客户端负载均衡组件，可以在服务间进行负载均衡。
3. OpenFeign：声明式服务调用框架，用于在不同的微服务之间进行服务调用。
4. Gateway：提供新一代API网关的支持，可以实现请求的路由和转发。
5. Hystrix：熔断器组件，用于防止服务雪崩效应，提供了容错和容错能力。
6. Config：配置中心组件，用于管理应用程序的配置信息。
7. Sleuth：分布式追踪组件，用于跟踪服务间的调用链路。
8. Security：提供安全性的支持，可以实现OAuth2和Spring Security的集成。
9. Bus：提供事件、消息总线的支持，可以实现分布式系统中的消息通信。
10. Stream：流式处理组件，用于处理实时数据流。

6、什么是Eureka？

Eureka是Netflix开源的一种服务发现框架，用于在分布式系统中提供服务注册和发现的功能。服务提供者将自己的信息注册到Eureka Server上，服务消费者从Eureka Server获取服务提供者的信息，从而进行服务调用。

7、Eureka有哪两大组件？

Eureka有两大组件：Eureka Server和Eureka Client。

• Eureka Server：Eureka Server是Eureka的核心组件，提供服务注册和发现功能。它维护了一个注册表，保存了所有Eureka Client实例的信息，并提供RESTful API供其他服务查询实例信息。
• Eureka Client：Eureka Client是Eureka的客户端组件，用于将服务实例信息注册到Eureka Server，同时也负责从Eureka Server中拉取服务实例信息，并缓存到本地。

8、Eureka如何实现高可用？

Eureka通过多个Eureka Server实例和Eureka Client实例的集群部署，当集群中的某个节点发生故障时，其他正常的节点依然可以提供完整的服务。以及自我保护机制和心跳检测等机制，来实现服务注册和发现的高可用性。

9、什么是Eureka的心跳检测机制？

Eureka的心跳检测机制是一种用于维护服务实例的健康状态的机制。每个Eureka Client都会在初始化时向Eureka Server注册自己的信息，并定期发送心跳信号。Eureka Server会在收到服务实例的心跳信号后，更新该实例的信息，并将其标记为“健康状态”。如果Eureka Server在一定时间内没有收到服务实例的心跳信号，就会将该实例的状态标记为“不健康”，并将其从服务注册表中移除，以避免客户端请求失败。

Eureka Client也可以通过配置文件设置心跳间隔时间和重试次数等参数，以保证心跳信号的可靠性和稳定性。同时，Eureka Server也会定期向所有已注册的服务实例发送心跳信号，以确认它们是否仍然处于活动状态。

实际上，心跳检测机制有一定的不确定性，比如服务提供者可能是正常的，但是由于网络通信或者其它的问题，导致在90s内Eureka Server没有收到该服务的心跳请求，那么Eureka Server将会把这个健康的服务误杀。

9、什么是Eureka的自我保护机制？

Eureka的自我保护机制是一种容错机制，主要是为了防止因网络分区而导致数据不一致的情况。当Eureka Server检测到网络分区或其他异常情况时，会进入自我保护模式。在自我保护模式下：

• Eureka Server会保护服务注册表中的信息，不再删除服务注册表中的数据。
• Eureka Server仍然能够接收新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。
• Eureka Server会定期尝试与其他节点通信，当网络恢复稳定时，将当前Eureka Server新的注册信息同步到其它节点中，以恢复服务的数据一致性。

10、为什么Eureka要使用自我保护机制？

通过自我保护机制，Eureka可以保证在网络分区或其他异常情况下，注册中心的高可用性。也因此实现了CAP中的A（高可用性）、P（分区容错性）。

11、如何设置Eureka的自我保护机制？

# 默认为true，开启自我保护机制，设置成false时会关闭自我保护机制
eureka.server.enable-self-preservation=false# 低于85%的客户端节点都没有正常的心跳时，Eureka Server自动进入自我保护状态
eureka.server.renewal-percent-threshold=0.85

12、什么是Ribbon？

Ribbon是一个基于HTTP和TCP的负载均衡客户端组件，它是Netflix OSS框架的一部分。Ribbon可以帮助我们在应用程序中实现负载均衡，使得流量可以被均匀地分配到多个实例上，从而提高应用程序的可用性和可伸缩性。

13、Ribbon底层实现原理是什么？

Ribbon的底层实现原理主要包括服务注册与发现、负载均衡算法、请求重试机制、断路器和缓存机制等方面。通过这些机制的协同作用，Ribbon可以帮助我们在分布式环境中实现负载均衡和容错，提高应用程序的可靠性和可扩展性。

14、Ribbon的负载均衡算法有哪些？

1. 轮询（Round Robin）：轮询是最简单的负载均衡策略，将请求依次分配给每个实例，循环进行。
2. 随机（Random）：随机算法随机选择一个实例处理请求，可以通过增加实例数来提高负载均衡效果。
3. 权重（Weight）：权重算法可以给每个实例分配一个权重值，根据权重值来决定请求分配给哪个实例。
4. 最少活跃连接（Least Connection）：最少活跃连接算法将请求分配给活跃连接数最少的实例，可以有效避免热点问题。
5. 一致性哈希（Consistent Hash）：一致性哈希算法可以将请求分配给与请求参数一致性哈希值最近的实例，可以避免数据不均衡问题。
6. 响应时间（Response Time）：响应时间算法将请求分配给响应时间最短的实例，可以提高请求的响应速度。

15、Ribbon客户端负载均衡与Nginx服务端负载均衡有什么区别？

• Ribbon是正向代理，它的作用范围仅限于客户端应用程序内部。主要用于将客户端的请求分发到多个服务实例上，以实现负载均衡的效果。
• Nginx则是一个反向代理服务器，它的作用范围是整个服务端应用程序。主要用于接收来自客户端的请求并发送到后端的多个服务实例上，以实现负载均衡的效果。

16、什么是OpenFeign？

OpenFeign是一个非常方便和易用的声明式Web服务客户端。它可以让开发人员以一种简单而优雅的方式创建可重用的HTTP客户端，可以大大简化Web服务调用的编写和管理。OpenFeign在Feign的基础上支持了SpringMVC的注解，如@RequestMapping等等。OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。

17、OpenFeign和Feign有什么区别？

1. 所属框架不同：OpenFeign是Spring Cloud生态系统中的一部分，而Feign是Netflix开源的一个组件。
2. 编码和解码器不同：OpenFeign支持可拔插式的编码和解码器，可以根据需要自定义编码和解码器，而Feign使用了Netflix自己的编解码器。
3. 集成方式：OpenFeign可以与Spring Cloud生态系统中的其他组件进行无缝集成，如Spring MVC、Spring Cloud HTTP Client等，而Feign可以与Netflix的其他组件进行集成，如Eureka、Zuul等。
4. 支持的注解不同：OpenFeign支持Spring MVC的注解，如@RequestMapping和@GetMapping等，而Feign支持JAX-RS的注解，如@GET和@Path等。
5. 社区支持：OpenFeign是Spring Cloud的一部分，受到Spring社区的广泛支持，而Feign则是Netflix框架的一部分，目前已经停止维护。

18、OpenFeign与Ribbon的区别？

1. 功能不同：OpenFeign是一个声明式Web服务客户端，可以通过注解的方式来定义服务调用；而Ribbon是一个负载均衡器，可以通过负载均衡算法来选择合适的服务提供者。
2. 使用方式不同：OpenFeign可以直接通过注解的方式来定义服务调用，非常方便；而Ribbon需要通过代码来调用服务，相对来说比较繁琐。
3. 集成方式不同：OpenFeign可以与Spring Cloud生态系统中的其他组件进行无缝集成，如Spring MVC和Spring Cloud HTTP Client等；而Ribbon则需要自己编写代码来进行集成。
4. 适用场景不同：OpenFeign适合用于编写服务消费端的代码，可以通过注解的方式来定义服务调用；而Ribbon适合用于负载均衡的场景，可以通过负载均衡算法来选择合适的服务提供者。

19、OpenFeign的超时控制是什么？

在使用OpenFeign进行服务调用时，默认等待时长为1秒钟，超过后报错。当我们调用的接口耗时较长时，往往1秒之内无法获取到响应结果，为了防止因为网络或服务端问题导致请求一直等待或者超时报错，可以设置延长OpenFeign接口的请求等待时间来解决这一问题。OpenFeign的超时控制主要涉及以下几个参数：

1. timeout：表示OpenFeign的全局超时时间，单位为毫秒。可以在OpenFeign的配置中进行设置，也可以在每个接口方法上使用注解进行设置。
2. readTimeout：表示OpenFeign的读取超时时间，单位为毫秒。表示在读取响应内容时的超时时间。
3. connectTimeout：表示OpenFeign的连接超时时间，单位为毫秒。表示在建立连接时的超时时间。
4. retryOnTimeout：表示在超时后是否进行重试。默认情况下，OpenFeign会在超时时进行重试。

20、什么是Gateway？

Gateway是Netflix开源的一款功能强大、灵活可靠的API网关，它提供了路由、负载均衡、熔断、监控等功能，可以帮助开发人员轻松地构建和管理微服务应用程序。在微服务架构中，由于存在大量的小型服务，因此需要一种机制来统一管理和路由这些服务。这就是API网关的作用。API网关是一个中央节点，可以将所有的客户端请求转发到相应的服务，同时还可以提供一些额外的功能，如身份验证、监控等。

21、Gateway有哪些特点？

1. 基于Netty的高性能：Gateway是基于Netty框架开发的，因此具有很高的性能和扩展性。
2. 支持多种协议：Gateway支持多种协议，包括HTTP、TCP、WebSocket等。
3. 动态路由：Gateway可以根据请求的信息动态地将请求路由到相应的服务。
4. 内置负载均衡：Gateway内置了负载均衡功能，可以根据不同的负载均衡算法进行请求分发。
5. 熔断器：Gateway内置了熔断器功能，可以在服务发生故障时，快速地将请求转移到备用服务，从而保证系统的可用性。
6. 监控：Gateway提供了丰富的监控功能，可以实时地监控服务的状态和性能指标。

22、Gateway与Zuul有哪些区别？

Gateway和Zuul都是Netflix开源的API网关，它们都具有路由、负载均衡、熔断等功能，但是它们在设计理念、架构和功能上还是有一些区别的。

1. 设计理念不同：Gateway强调的是基于Spring生态圈的开发，它的设计理念是通过简单而强大的抽象来简化复杂的问题，而Zuul则更注重于提供强大的功能和配置选项，它的设计理念是让用户可以通过配置来实现各种复杂的路由逻辑。
2. 架构不同：Gateway采用了基于Spring Boot的自动配置和约定大于配置的理念，它的架构更加简单和轻量级，而Zuul则采用了更加复杂的架构，包括多个模块和组件，例如Zuul Core、Ribbon、Hystrix等等。
3. 功能不同：Gateway的功能相对于Zuul来说更加简单，它只提供了基本的路由、负载均衡和熔断等功能，而Zuul则提供了更多的高级功能，例如动态路由、服务发现、安全策略、监控等等。
4. 性能不同：Gateway采用了基于Netty的高性能架构，它的性能比Zuul更加优秀，而Zuul则是基于Java的传统IO模型，它的性能相对较差。

23、Gateway的核心流程是什么？

Gateway的核心流程可以简单地概括为以下几个步骤：

1. 客户端发送请求到Gateway的前端网关。
2. Gateway的前端网关将请求转发到对应的路由，并根据路由的配置进行负载均衡和容错处理。
3. 路由将请求转发到相应的服务实例。
4. 服务实例处理请求，并将结果返回给Gateway的后端网关。
5. Gateway的后端网关将结果返回给前端网关。
6. 前端网关将结果返回给客户端。

24、GateWay的核心思想有哪些？

GateWay的三个核心思想是Route、Predicate和Filter，这三个核心思想相互协作，实现了请求的路由、过滤和转发等功能，使得服务的请求可以更加高效和可靠地被处理。

1. Route：表示路由，它指定了请求应该被转发到哪个服务实例。在GateWay中，可以通过配置路由来实现请求的负载均衡和请求转发。
2. Predicate：表示断言，它用于匹配请求并决定是否路由到相应的服务实例。在GateWay中，可以通过配置断言来实现请求的路由控制和请求过滤。
3. Filter：表示过滤器，它用于在请求被路由到服务实例之前或之后进行一些处理，如身份验证、请求转发、日志记录等。在GateWay中，可以通过配置过滤器来实现请求的拦截和处理。

25、GateWay常用的Predicate断言有哪些？

1. Path：用于匹配URL路径，可以使用Ant风格的路径表达式进行匹配。
2. Method：用于匹配HTTP请求方法，可以匹配GET、POST、PUT、DELETE等请求方法。
3. Header：用于匹配请求头，可以匹配请求头的名称和值。
4. Host：用于匹配请求的主机名，可以匹配请求的完整主机名或者主机名的前缀。
5. Weight：用于匹配请求的权重，可以将请求路由到不同的服务实例，根据不同的权重进行负载均衡。
6. Regex：用于使用正则表达式匹配请求的URL路径、请求头等。
7. And、Or：用于将多个Predicate组合起来，实现复杂的断言逻辑。

26、什么是Hystrix？

Hystrix是一种开源的延迟和容错库，可以应用于分布式系统中，用于解决分布式系统中的服务雪崩效应和容错问题。在分布式系统中，由于服务之间的依赖关系，一个服务的故障可能会导致整个系统的故障。Hystrix通过引入断路器模式，在服务调用失败时自动进行故障转移，避免了级联故障的发生，提高了系统的可用性和稳定性。

27、Hystrix的特性有哪些？

1. 服务熔断：当某个依赖服务出现问题时，Hystrix会自动切断对该服务的请求，防止故障扩散。
2. 服务降级：当依赖服务响应时间过长或者超时时，Hystrix会返回一个默认的响应，以保证服务的可用性。
3. 线程和信号隔离：Hystrix使用线程池隔离和信号量隔离两种方式，将不同的依赖服务请求隔离在不同的线程池或信号量中，避免相互影响。
4. 请求缓存：Hystrix可以缓存依赖服务的响应，避免重复请求，减轻依赖服务的压力。
5. 请求合并：Hystrix可以将多个请求合并为一个请求，减少网络开销和依赖服务的压力。
6. 监控和报警：Hystrix提供了丰富的监控和报警功能，可以实时监控依赖服务的状态和性能指标，并在出现故障时发送报警通知。

28、Hystrix工作流程？

Hystrix的工作流程可以简单概括为以下几个步骤：

1. 命令请求：客户端通过Hystrix发起一个请求，将请求包装成一个HystrixCommand或HystrixObservableCommand对象。
2. 线程池准备：Hystrix将请求发送到线程池中，并等待线程池分配可用线程。
3. 命令执行：线程分配成功后，HystrixCommand或HystrixObservableCommand对象开始执行请求，执行过程中可以进行一些操作，如请求缓存、请求合并、请求缓存等。
4. 错误处理：如果请求执行过程中发生异常，Hystrix会根据配置的容错策略进行处理，如重试、切换备用依赖、请求降级等。
5. 请求完成：如果请求成功完成，Hystrix会将响应结果返回给客户端。
6. 统计信息：Hystrix会对请求的执行情况进行统计和监控，包括请求次数、响应时间、错误率等，以便开发人员进行性能分析和故障排查。

29、Hystrix中服务降级和服务熔断有什么区别？

• 服务熔断：是一种预防性策略，用于在服务出现故障或异常时，防止故障进一步扩大。当服务调用失败次数达到一定阈值时，Hystrix会直接返回一个预设的默认值或者错误提示，避免故障在系统中传播。

• 服务降级：是一种应急性策略，用于在服务出现故障或异常时，尽可能保持系统的可用性和稳定性。当服务调用失败次数达到一定阈值时，Hystrix会将请求转发到备用服务或者直接返回一个默认值，以保证系统的正常运行。

30、Hystrix的服务熔断有哪几种状态

1. 关闭状态（Closed State）：在此状态下，熔断器不执行任何服务降级，请求将直接发送到依赖服务。
2. 半关闭状态（Half-Open State）：在此状态下，熔断器允许有限数量的请求发送到依赖服务，如果这些请求成功完成，则熔断器将切换回关闭状态。如果这些请求中有一个失败，则熔断器将再次切换到打开状态。
3. 打开状态（Open State）：在此状态下，所有请求将被服务降级，不会发送到依赖服务。

31、Hystrix断路器的三个重要参数是什么？

1. requestVolumeThreshold：该参数表示在一个给定的时间窗口内，需要至少执行多少个请求，才会启用Hystrix断路器。如果在该时间窗口内，请求的数量低于该阈值，则Hystrix断路器不会被启用。
2. errorThresholdPercentage：该参数表示在一个给定的时间窗口内，请求的错误率超过多少百分比，才会启用Hystrix断路器。如果在该时间窗口内，请求的错误率低于该阈值，则Hystrix断路器不会被启用。
3. sleepWindowInMilliseconds：该参数表示在断路器打开后，需要等待多久才会关闭。该时间窗口称为“睡眠窗口”，在此期间，所有请求都将被拒绝，直到窗口结束，断路器才会关闭。