Spring Cloud 面试题（五）

1. Eureka的自我保护模式是什么？

Eureka的自我保护模式是一种应对网络异常的安全保护措施，旨在防止因网络分区或其他异常情况导致服务实例被错误地注销。当Eureka Server在短时间内丢失过多的客户端心跳时，会触发自我保护机制。以下是自我保护模式的几个关键点[⁴⁰][⁴¹][⁴⁶]：

1. 触发条件：

   • 当Eureka Server在一定时间内（默认90秒）没有接收到某个微服务实例的心跳，且这种情况在15分钟内超过85%的客户端节点发生时，Eureka Server将认为出现了网络故障，并自动进入自我保护模式。

2. 行为变化：

   • 在自我保护模式下，Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务实例。

3. 继续服务：

   • Eureka Server仍然能够接受新服务的注册和查询请求，但这些信息不会被同步到其他节点上，保证当前节点依然可用。

4. 网络恢复：

   • 当网络稳定时，当前Eureka Server上新的注册信息会被同步到其他节点中。

5. 设计哲学：

   • 自我保护模式的设计理念是宁可同时保留所有微服务（包括健康的和不健康的），也不盲目注销任何健康的微服务。

6. 退出机制：

   • 一旦网络分区故障恢复，Eureka Server节点会自动退出自我保护模式，并恢复正常的服务注册和注销行为。

7. 参数配置：

   • Eureka Server的自我保护模式默认是开启的，可以通过参数eureka.server.enable-self-preservation=false来关闭。
   • 还有一个参数eureka.server.renewalPercentThreshold用于设置触发自我保护的心跳丢失阈值（默认值为0.85，即85%）。

自我保护模式使得Eureka集群在面对网络异常时能够更加健壮和稳定，避免因网络问题导致的服务不可用。然而，在实际生产环境中，如果网络环境稳定，可以考虑关闭自我保护模式以避免长时间保留不健康的服务实例[⁴¹]。

2. 简述什么是CAP,并说明Eureka包含CAP中的哪些?

CAP定理，又称为布鲁尔定理（Brewer’s theorem），是分布式计算中的一个概念，由计算机科学家埃里克·布鲁尔（Eric Brewer）提出。CAP定理指出，在网络分区发生的情况下，一个分布式系统不可能同时满足以下三个特性：

1. 一致性（Consistency）：在分布式系统中，所有数据的副本始终保持一致的状态。

2. 可用性（Availability）：系统在任何时刻都能够响应客户的请求。

3. 分区容错性（Partition Tolerance）：系统在网络分区（即网络通信不可靠的场景下）仍然能够继续运作。

CAP定理的核心思想是，一个分布式系统在发生分区故障时，只能在一致性和可用性之间选择两个来保证。

Eureka 是Netflix开源的服务发现框架，它是Spring Cloud体系中的核心组件之一。Eureka包含CAP定理中的分区容错性（Partition Tolerance），因为它的主要目的是在分布式系统中提供服务的注册与发现，即使在网络分区发生的情况下，Eureka集群中的节点也能够独立地继续提供服务。

Eureka本身并不强调强一致性（Consistency），而是更倾向于最终一致性。这意味着在正常情况下，Eureka能够保证服务注册信息的一致性，但在网络分区或其他异常情况下，它可能会暂时允许一些不一致性存在，直到系统恢复到正常状态。

Eureka通过以下机制来实现CAP中的分区容错性：

• 服务注册与续约机制：服务实例在启动时向Eureka注册自己，并定期发送心跳（续约）以表明自己的存活状态。

• 服务下线保护：Eureka提供了服务下线保护机制，避免因网络抖动导致的服务下线。

• 区域感知性：Eureka客户端优先访问同一区域的服务实例，增强了系统的可用性。

• 自我保护机制：在网络分区或其他异常情况下，Eureka会启动自我保护机制，避免因过度的网络通信导致系统雪崩。

总的来说，Eureka作为服务发现组件，其设计重点在于保证系统的高可用性和分区容错性，而在一致性方面，它允许一定程度的最终一致性，以适应分布式系统的需求。

3. 什么是Spring Cloud Zuul（服务网关）

Spring Cloud Zuul是Netflix开源的一个微服务网关组件，它在Spring Cloud体系中作为服务网关使用，用于在微服务架构中统一处理外部请求。Zuul提供了路由、过滤、监控等功能，是微服务架构中不可或缺的一部分。

Spring Cloud Zuul的主要特点和功能包括：

1. 路由转发：

   • Zuul可以根据路由规则将外部请求转发到后端的特定服务。

2. 过滤器：

   • Zuul拥有一套强大的过滤器机制，可以在请求到达后端服务之前或之后执行过滤逻辑，如身份验证、日志记录、请求头修改等。

3. 服务发现集成：

   • Zuul可以与Eureka等服务发现组件集成，动态地感知服务实例的变化。

4. 负载均衡：

   • Zuul可以与Ribbon等负载均衡器集成，实现请求的负载均衡。

5. 认证和安全：

   • Zuul提供了认证和安全机制，可以拦截请求并进行用户认证、权限校验等。

6. 压力测试：

   • Zuul可以用来模拟高负载情况，对后端服务进行压力测试。

7. 服务降级：

   • 当检测到服务不可用时，Zuul可以返回预定义的错误页面或进行服务降级处理。

8. 弹性和容错：

   • Zuul支持断路器模式，可以提高系统的弹性和容错能力。

9. 简化的服务治理：

   • Zuul作为统一的请求入口，简化了服务治理和请求路由。

10. 统一的跨服务请求处理：

    • Zuul可以统一处理跨服务的请求，如统一添加或删除请求头、参数等。

11. 插件系统：

    • Zuul拥有丰富的插件系统，可以通过插件扩展功能，如日志记录、请求修改等。

12. 配置管理：

    • Zuul支持动态配置，可以实时更新路由规则和过滤器逻辑。

13. 响应式编程支持：

    • Zuul支持响应式编程，与Spring WebFlux等响应式堆栈兼容。

14. 易于集成：

    • Zuul可以轻松地集成到Spring Cloud体系中，与Spring Boot应用无缝协作。

15. 容器化和微服务架构：

    • Zuul适合在容器化和微服务架构中使用，支持服务的快速迭代和持续部署。

16. 请求日志和调试：

    • Zuul可以记录详细的请求日志，方便问题追踪和调试。

17. API版本管理：

    • Zuul可以方便地管理API版本，简化版本迁移和兼容性管理。

使用Zuul作为服务网关，可以为微服务架构带来统一的请求处理、安全认证、服务路由和监控等功能，提高系统的可维护性和可扩展性。

4. Zuul与Nginx有什么区别？

Zuul和Nginx都是流行的网关服务器，它们可以处理HTTP请求的路由、负载均衡、认证等，但它们有一些关键的区别：

1. 开发语言：

   • Zuul是用Java开发的，并且是Spring Cloud体系中的一个开源API Gateway服务器。
   • Nginx是用C语言开发的，是一个高性能的HTTP和反向代理服务器，同时也是IMAP/POP3/SMTP服务器。

2. 负载均衡实现：

   • Nginx实现负载均衡通常是在服务器端进行，通过自身的配置来实现。
   • Zuul实现负载均衡是通过与Spring Cloud的其他组件（如Ribbon和Eureka）结合使用来实现客户端负载均衡。

3. 适用场景：

   • Nginx通常用于服务器端负载均衡，适合处理静态内容和代理大量并发请求。
   • Zuul更适合在微服务架构中作为服务网关，处理动态请求并提供微服务间的路由。

4. 功能丰富性：

   • Nginx功能相对更加强大，可以整合脚本语言如Lua，提供更灵活的扩展。
   • Zuul提供了动态路由、监控、弹性和安全等边缘服务的框架，但相比Nginx可能在某些方面功能上不够强大。

5. 性能：

   • Nginx由于是用C语言编写，性能通常非常高，特别是在处理静态内容和高并发请求时。
   • Zuul的性能可能会受到Java虚拟机（JVM）性能的影响，特别是启动时的加载时间。

6. 异步处理：

   • Zuul 1是基于Servlet框架构建的，采用阻塞和多线程方式处理请求。
   • Nginx通常以同步方式处理请求，但社区版和Plus版提供了一些异步处理能力。

7. 版本更新：

   • Zuul 2在设计上运行在异步和非阻塞框架上，每个CPU核一个线程，处理所有的请求和响应，这可以显著提升性能。

8. 社区和生态：

   • Nginx拥有一个非常活跃的社区，并且有许多第三方模块可供扩展。
   • Zuul作为Spring Cloud生态的一部分，与Spring Boot、Spring Cloud Config等组件紧密集成。

总的来说，选择Zuul还是Nginx取决于具体的应用场景、技术栈以及性能要求。如果项目已经基于Spring Cloud，Zuul可能会更自然地融入整个技术生态；而对于需要高性能、处理大量静态内容或需要高度定制化的场景，Nginx可能是更好的选择。

5. ZuulFilter常用有哪些方法？

在Spring Cloud Zuul中，ZuulFilter是一个过滤器的抽象类，开发者可以通过继承这个类来创建自定义的过滤器。ZuulFilter中定义了一些方法，这些方法可以在请求的不同阶段执行特定的逻辑。以下是一些常用的ZuulFilter方法：

1. init():

   • 过滤器初始化方法，Zuul会在过滤器实例化时调用此方法一次。

2. run():

   • 过滤器执行方法，包含过滤器的主要逻辑。此方法必须被实现，并且会针对每个请求调用。

3. shouldFilter():

   • 决定是否执行过滤器的方法。如果返回false，则run()方法不会被调用。

4. preRoute():

   • 在路由请求之前调用，在请求被发送到后端服务之前进行前置处理。

5. postRoute():

   • 在路由请求之后调用，在请求已经被发送到后端服务并且响应返回之后进行后置处理。

6. onError():

   • 当请求处理过程中发生错误时调用，可以用于错误处理和记录。

7. filterType():

   • 定义过滤器的类型，常见的类型有pre、route、post和error。

8. filterOrder():

   • 返回过滤器的顺序值，决定过滤器链中各个过滤器的执行顺序。

9. isAsync():

   • 标识过滤器是否异步执行，默认为同步。

通过实现ZuulFilter类并覆盖这些方法，开发者可以插入自己的逻辑来处理请求，例如身份验证、日志记录、请求修改、响应修改、异常处理等。自定义过滤器可以注册为Spring Bean，并配置它们的顺序和类型，以便在Zuul的过滤器链中按照预期的方式执行。

使用ZuulFilter时，需要考虑过滤器的执行顺序和类型，以确保过滤器逻辑的正确性和高效性。开发者可以根据需要选择性地实现这些方法，构建满足特定业务需求的过滤器。

6. Ribbon是什么？

Ribbon是一个客户端负载均衡器，它提供了一种在客户端应用中实现负载均衡的机制。Ribbon通常与服务发现组件（如Eureka）结合使用，在Spring Cloud体系中，它被广泛用于微服务架构中各个服务之间的调用。

Ribbon的主要特点包括：

1. 负载均衡：Ribbon能够在多个服务实例之间分配请求，以实现负载均衡。

2. 服务发现集成：Ribbon可以与Eureka、Consul等服务发现组件集成，动态地感知服务实例的变化。

3. 多种负载均衡策略：Ribbon支持多种负载均衡算法，如轮询、随机、权重响应等。

4. 可扩展性：Ribbon允许开发者自定义负载均衡策略，以满足特定的业务需求。

5. 与Spring Cloud集成：Ribbon与Spring Cloud紧密集成，提供了对Spring Cloud应用的原生支持。

6. 客户端功能：Ribbon作为一个客户端组件，可以与任何客户端库一起工作，如RestTemplate、FeignClient等。

7. 配置灵活性：Ribbon可以通过配置文件或编码方式进行灵活配置。

8. 监控和度量：Ribbon提供了对服务调用的监控和度量支持，有助于性能优化。

9. 容错性：Ribbon可以与断路器模式（如Hystrix）结合使用，提高系统的容错性。

Ribbon的设计目标是简化客户端的负载均衡实现，使得开发者可以专注于业务逻辑，而不必担心后端服务的负载均衡和故障转移等问题。通过Ribbon，开发者可以很容易地为Spring Cloud应用添加负载均衡功能，提高系统的可用性和伸缩性。