SpringCloud

典型回答 继SpringBoot 3.0和SpringFramework 6.0之后，Spring Cloud 推出了一个重要的新版本——2022.0.0，官网把这个版本命名为Kilburn。 主要有以下几个变化，首先Spring Cloud 2022.0.0是构建在Spring Framework 6.0和Spring Boot 3.0 之上的一个主要版本。所以，他对JDK要求同样是最低需要是Java 17，对J2EE的要求最低需要Jakarta EE 9。 Spring Cloud 2022.0.0中的组件各个版本做了一些升级，并移除了Spring Cloud CLI 和 Spring Cloud Cloudfoundry 这两个模块。 Spring Boot CLI是一个命令行工具，用于使用Spring快速开发。 它允许运行Groovy脚本，Groovy脚本类似于没有任何样板代码的java代码。 Spring CLI有助于引导新项目或编写自定义命令。 Spring Cloud for Cloudfoundry可以轻松地在Cloud Foundry 中运行Spring Cloud应用程序。 Cloud Foundry具有“服务”的概念，即“绑定”到应用程序的中间件，实质上为其提供包含凭据的环境变量。 Spring Boot 3.0 中两个重要的升级就是开始支持AOT编译和引入了Spring Native。 在本次升级的SpringCloud 2022.0.0中，多个组件也都增加了对AOT和Native的支持，如Spring Cloud Function、Spring Cloud Stream、Spring Cloud OpenFeign、Spring Cloud Commons、Spring Cloud Consul以及Spring Cloud Gateway等。 由于Spring现在提供了自己的接口HTTP客户端解决方案，从2022.0.0开始，Spring Cloud OpenFeign将被视为功能完整。这意味着Spring Cloud团队将不再向模块添加新特性。只会修复bug和安全问题。 更新到Eureka 2.0.0，Eureka 2.0.0 是 Eureka 的一个新分支，与 7 年前的旧 2.x-archive 分支实验无关。新的 2.x 分支是为了与 JakartaEE 兼容，这也使得 Spring Cloud Netflix 与 Spring Framework 6.0 和 Spring Boot 3.0 兼容。 ...

典型回答 Feign是Spring Cloud中的一个声明式的HTTP客户端库，用于简化编写基于HTTP的服务调用代码。但是从Spring Cloud 2020版本开始，官方宣布Feign将不再维护和支持，推荐使用OpenFeign作为替代方案。 但是，随着SpringCloud 2022的发布，官方宣布OpenFeign将被视为功能完整。这意味着Spring Cloud团队将不再向模块添加新特性。只会修复bug和安全问题。 但是，在Spring 6.0 发布之后，Spring内置了一个HTTP客户端——@HttpExchange （https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/service/annotation/HttpExchange.html ），建议大家使用这个客户端进行HTTP调用。 扩展知识 @HttpExchange使用 想要使用这个新的HTTP客户端，需要Spring升级到6.0，或者SpringBoot升级到3.0版本，然后再POM中依赖spring-web。以下两个二选一： 1 2 3 4 5 6 7 8 9 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-webflux</artifactId> </dependency> 在 Spring 6.0中，可以让HTTP 服务接口带有@HttpExchange。那么这个接口方法就会被视为 HTTP 端点，目前支持的注解有以下几个： @GetExchange HTTP GET 请求 @PostExchange HTTP POST 请求 @PutExchange HTTP PUT 请求 @PatchExchange HTTP PATCH 请求 @DeleteExchange HTTP DELETE 请求 首先，我们自己定义一个HTTP接口，定义一个实体类： ...

典型回答 Ribbon是Netflix推出的负载均衡组件，但是从2020年开始，Netflix推出的很多SpringCloud组件都宣布不再更新维护了，所以，SpringCloud就自己推出了Spring Cloud LoadBalancer 来代替Ribbon，所以，在Spring Cloud 2020.0版本中，Ribbon已经被标记为过时，官方推荐使用Spring Cloud LoadBalancer。 LoadBalancer是Spring Cloud官方提供的负载均衡组件，可用于替代Ribbon。其使用方式与Ribbon基本兼容，可以从Ribbon进行平滑过渡。 其实LoadBalancer就是Ribbon的替代品，二者在功能和使用上没什么太大的差别，如果一定要说一说他们之间的差别的话，主要有这几个： 实现方式：Ribbon是一个独立的第三方的库，需要单独引入。而Spring Cloud LoadBalancer是Spring Cloud的一个组件，集成在Spring Cloud中，可以直接使用。 易用性：Ribbon是一个较为底层的负载均衡器，需要开发人员手动配置负载均衡策略和服务发现机制。而Spring Cloud LoadBalancer提供了一个更高层次的抽象，将负载均衡策略和服务发现机制的实现进行了封装，使开发人员更容易使用。 生态完整：Spring Cloud LoadBalancer与Spring Cloud的其他组件紧密集成，具有更好的易用性和稳定性，而且与Ribbon相比，更加轻量级，性能更好。 扩展知识 使用示例 在项目的pom.xml文件中添加以下依赖： 1 2 3 4 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-loadbalancer</artifactId> </dependency> 创建一个RestTemplate对象，并使用@LoadBalanced注解进行标记： 1 2 3 4 5 6 7 8 @Configuration public class AppConfig { @Bean @LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); } } 实现服务调用： ...

典型回答 Spring Cloud通常被用来构建分布式架构，而分布式中，就需要解决多个微服务之间的通信问题。多个应用分别部署在不同的机器上，那么想要让他们之间互相通信，有以下几种常见的办法（这里只介绍下有哪些以及主要的区别，各自原理后续会单独章节展开。） RESTful 调用 最常见的方式是使用RESTful API进行服务间的通信。Spring Cloud利用Spring MVC提供了强大的REST客户端和服务端支持。 比如我们的一个服务通过Spring MVC暴露出一个HTTP接口出来，然后另一个服务通过RestTemplate或WebClient来进行HTTP调用。 1 2 3 4 5 6 @Autowired private RestTemplate restTemplate; public MyObject callOtherService() { return restTemplate.getForObject("http://other-service/api/data", MyObject.class); } 使用Feign客户端（常用） Feign是一个声明式的Web服务客户端，使得编写Web服务客户端更加容易。 通过创建一个接口并用注解来配置请求的细节，Feign可以自动处理请求的发送和结果的映射。Spring Cloud对Feign进行了集成，使其成为在微服务架构中实现服务间调用的一个流行选择。 1 2 3 4 5 @FeignClient("other-service") public interface OtherServiceClient { @GetMapping("/api/data") MyObject getData(); } Spring Cloud Gateway（常用+推荐） Spring Cloud Gateway是基于请求路由的API网关。它允许你根据请求的不同特征（如路径、头部、请求参数等）将请求路由到不同的后端服务上。 ...

典型回答 Dubbo 和 Feign 都是常用于构建分布式系统的技术，主要解决的问题就是多个微服务之间的相互调用。他们之间有一些区别，主要体现在它们所服务的架构、通信协议、性能特点以及集成与使用方式上。 Dubbo 是一个高性能的、基于 Java 的开源RPC（远程过程调用）框架。它主要用于构建高性能和透明化的服务间远程调用的微服务架构。Dubbo 支持多种通信协议和负载均衡策略，允许服务之间以高效率进行数据交换。 Dubbo的主要特点： 高性能的RPC调用：提供基于接口的远程方法调用。 多种通信协议支持：支持多种协议如 Dubbo、HTTP、RMI 等。 服务治理：内建的服务治理功能，包括服务发现、负载均衡、故障转移和动态配置等。 依赖Zookeeper、Nacos等注册中心：用于服务的注册与发现。 Feign 是一个声明式的Web服务客户端，它使得编写Web服务客户端变得更容易。使用 Feign 可以通过简单的接口和注解来调用HTTP API。Feign 的目标是尽可能简化HTTP API客户端的实现过程。 Feign主要特点： 声明式的HTTP客户端：通过Java接口和注解来定义方法与远程服务的绑定关系。 集成Ribbon和Hystrix：支持负载均衡（通过集成Ribbon）和服务熔断（通过集成Hystrix）。 主要用于Spring Cloud：通常与Spring Cloud组件一起使用，实现服务间的调用。 主要区别： Dubbo Feign 设计哲学 RPC HTTP 通信协议 支持多种协议，如Dubbo、HTTP等 HTTP 服务治理 支持 支持较少 调用性能 强 没那么强 负载均衡 内置 依赖Ribbon提供 注册中心 依赖Nacos、Zookeeper等 依赖Nacos、Eureka等 服务发现 内置 依赖Nacos、Eureka等 生态 SpringCloudAlibaba SpringCloud 停止更新 未停止 已停止 总结来说，Dubbo 和 Feign 虽然都用于服务间的调用，但Dubbo 更注重于RPC的高性能实现和服务治理，而Feign 更侧重于简化HTTP服务的消费和集成Spring Cloud生态。选择哪个工具取决于你的具体需求、架构风格和技术栈。

典型回答 Zookeeper是最早流行的开源分布式协调服务框架之一，同时也提供了分布式配置中心的功能。Zookeeper以高可用、一致性和可靠性著称，但是需要用户自己来开发实现分布式配置的功能。 Eureka是Netflix开源的服务注册中心，被广泛应用在Spring Cloud微服务架构中。它提供了易于使用的REST API和Web界面，并支持基于Region和Zone的服务分组和负载均衡。 设计哲学： Zookeeper 的设计哲学是 “CP”，即保证一致性和分区容错性。使用了 ZAB协议来保证集群中的数据强一致性。因为他是一个分布式协调组件，一致性很重要， Eureka的 设计哲学是 “AP”，即保证可用性和分区容错性。他采用了一种更为宽松的一致性模型，支持最终一致性。因为他就是为了做注册中心的，可用性更重要。 ✅什么是CAP理论，为什么不能同时满足？ 性能： Eureka: 由于其设计重点放在高可用性和可伸缩性上，对于大规模的服务发现场景，Eureka 可以更快地响应服务注册和发现请求。 Zookeeper: 他主要是分布式协调组件，最终保证的是一致性，那势必就会牺牲一部分的性能（可用性）。 客户端交互： Eureka: 客户端需要定期向 Eureka 发送心跳来维持注册状态，并从 Eureka 获取服务列表。 Zookeeper: 客户端可以设置监听器来监控数据节点的变化，当这些节点发生变化时，Zookeeper 会通知客户端。 以上是主要区别，还有些其他区别如下： Eureka Zookeeper CAP AP CP 健康检查 Client Beat Keep Alive 负载均衡 Ribbon — 一致性算法 Gossip ZAB 雪崩保护 有 无 访问协议 HTTP TCP Spring Cloud集成 支持 支持 Dubbo集成 不支持 支持 K8s集成 不支持 支持 说这么多，该怎么选择呢？ ...

典型回答 在 Spring Cloud 中，Feign 是一个声明式的 Web 服务客户端，它使得编写 HTTP 客户端变得更加容易。经常会有人遇到应用启动之后，第一次的访问通常很慢，甚至有超时的情况， 那么可能有哪些原因呢？ 缓存初始化 很多系统在首次运行时需要建立缓存。初次访问数据可能需要从硬盘、数据库或远程服务中检索，并在内存中建立缓存，这个过程可能会比较慢。 JIT 编译 对于使用即时编译（JIT）的语言或环境（如 Java, .NET）来说，首次执行代码时可能需要进行编译优化，这将导致初始延迟，但随后的执行速度会加快。如下面这个实际排查案例： ✅Load飙高问题排查过程 动态代理的创建 Feign 使用动态代理来创建接口的实现。首次调用一个 Feign 客户端时，Spring Cloud 需要构建和配置这个代理，这包括解析接口上的注解并创建相应的 HTTP 请求模板。这个过程可能比较耗时，特别是在接口定义较为复杂或注解使用较多的情况下。 服务发现 如果你的 Feign 客户端配置为使用 Eureka 或其他服务发现机制，首次调用可能涉及到查找服务的位置。这可能需要从服务注册中心获取服务实例的信息，尤其是在服务刚启动，或服务列表有更新时。 Hystrix 和线程池初始化 如果 Feign 客户端配合 Hystrix 使用，首次调用还可能涉及到 Hystrix 命令的初始化，包括线程池的创建和配置。这些都可能在首次调用时增加额外的延迟。 网络延迟和首次连接 首次调用远程服务可能涉及建立网络连接，例如 TCP 握手，这在首次连接时特别明显。 冷启动 当服务或应用第一次启动时，可能需要加载到内存中，这被称为冷启动。比如，在微服务架构中，某个服务的首次调用可能需要时间来启动和初始化，尤其是在使用容器化或Serverless架构时更为常见。 要减少这种首次调用的延迟，你可以考虑以下几个策略： 预热客户端：在应用启动后，你可以编写一些预热逻辑来提前调用 Feign 客户端，以完成初始化过程，确保当真正需要时它已经准备好。 优化配置：检查和优化 Feign 客户端的配置，如连接超时和读取超时设置，以及其他可能影响性能的配置。 服务发现缓存：如果使用服务发现，确保服务实例信息被适当缓存，减少对服务注册中心的依赖。 JVM 性能调优：调整 JVM 设置，比如 JIT 编译策略或内存配置，以优化首次加载性能。 通过这些策略，你可以改善 Feign 客户端的响应时间，特别是在应用刚启动时的表现。这些方法也有助于提升整体的系统性能和用户体验。

典型回答 Eureka的自我保护模式正是一种针对网络异常波动的安全保护措施，使用自我保护模式能使Eureka集群更加的健壮、稳定的运行。 在正常情况下，Eureka客户端会定期向Eureka服务器发送心跳，以表明它仍然存活和可用。如果Eureka服务器在配置的时间间隔内未能从某个服务实例接收到心跳，它通常会将该实例从注册列表中移除，认为该实例不可用。 然而，在自我保护模式下，如果Eureka服务器在短时间内丢失了对大量服务实例的心跳（15分钟内超过 85% 的客户端），它会认为这是一个网络问题，而不是所有这些服务实例都突然不可用。因此，服务器将进入自我保护模式。 当进入自我保护模式时，会存在以下行为： 停止移除服务实例： Eureka服务器在自我保护模式下不会因为缺少心跳而移除任何服务实例。即使服务实例停止发送心跳，它们仍然会被保留在注册表中。 保持服务注册表状态： 这可以确保在网络故障恢复后，服务消费者仍然能够发现所有原先注册的服务实例，无需等待这些实例重新注册和检测。 记录状态和警告： Eureka服务器会在其状态页面上显示它是否处于自我保护模式，并显示相关的警告信息。 Eureka的自我保护模式是可配置的。可以通过配置参数来调整何时触发自我保护模式，或完全关闭此功能。例如，可以通过修改eureka.server.enable-self-preservation的配置值来开启或关闭自我保护模式。 1 2 3 eureka: server: enable-self-preservation: true 自我保护模式默认是开启的，因为它可以在网络不稳定的环境中提供更稳定的服务发现功能。不建议在生产环境中关闭自我保护机制。 当Eureka进入自我保护模式之后，我们可以做一下几个事情解除这种自我保护： 确保客户端可用性： 确保所有客户端实例都运行正常，并且网络连接正常，无阻塞或延迟过高。 检查客户端与 Eureka Server 之间的网络连接是否稳定。 等待自动恢复： 正常的情况下，等待网络恢复后，Eureka Server 会自动关闭自我保护模式。 重启 Eureka Server： 如果问题仍然存在，尝试重启 Eureka Server。有时候，重启可以解决暂时的问题或状态不一致。 调整自我保护模式的阈值： 检查 eureka.server.enableSelfPreservation 配置项，确保它被设置为 true，这是自我保护模式的开启开关。 你可以调整 eureka.server.renewalPercentThreshold 配置来改变触发自我保护模式的阈值。 查看日志排查问题： 查看 Eureka Server 和客户端的日志，找出可能导致问题的具体原因。 关闭自我保护模式： 使用eureka.server.enable-self-preservation=false来禁用自我保护模式，测试环境可以配置，生产不建议。

典型回答 Spring Boot 3.x 移除了对 Java EE（Jakarta EE）旧 API（如 javax 包）的支持，而 Eureka 仍然依赖 javax.xml.bind 等 API，**因此官方不再维护 Eureka，并推荐其他方案。 ** Eureka的主要功能是实现服务注册中心，所以其实他的替代产品还挺多的，比如nacos、zk、consul等 。 ✅注册中心如何选型？ Nacos ✅什么是Nacos，主要用来作什么？ Nacos是阿里巴巴开源的服务注册中心和配置中心。与Zookeeper不同的是，Nacos自带了配置中心功能，并提供了更多的可视化配置管理工具。Nacos的目标是成为一个更全面的云原生服务发现、配置和管理平台。 Consul Consul是HashiCorp开源的服务注册中心和配置中心，提供了服务发现、健康检查、KV存储和多数据中心功能。Consul提供了更丰富的健康检查和路由功能，同时也提供了丰富的API和Web UI。 Zookeeper Zookeeper是最早流行的开源分布式协调服务框架之一，同时也提供了分布式配置中心的功能。Zookeeper以高可用、一致性和可靠性著称，但是需要用户自己来开发实现分布式配置的功能。 对比如下： Nacos Eureka Consul Zookeeper CAP CP+AP AP CP CP 健康检查 TCP/HTTP/MYSQL/Client Beat Client Beat TCP/HTTP/gRPC/Cmd Keep Alive 负载均衡 权重/ metadata/Selector Ribbon Fabio — 一致性算法 Raft/Distro Gossip Raft ZAB 雪崩保护 有 有 无 无 访问协议 HTTP/DNS HTTP HTTP/DNS TCP 跨注册中心同步 支持 不支持 支持 不支持 Spring Cloud集成 支持 支持 支持 支持 Dubbo集成 支持 不支持 支持 支持 K8s集成 支持 不支持 支持 支持

典型回答 Spring Cloud LoadBalancer 内置其实只提供了以下2种默认策略： 策略 类 描述 轮询 (Round-Robin) RoundRobinLoadBalancer 默认策略，每个请求依次分配到不同的实例 随机 (Random) RandomLoadBalancer 随机选择一个可用实例 默认情况下，Spring Cloud LoadBalancer 使用RoundRobinLoadBalancer 进行轮询调度（向下兼容了Ribbon的轮询策略），即请求会依次轮流分配到可用的服务实例。 定义在LoadBalancerClientConfiguration 中： 1 2 3 4 5 6 7 8 9 10 11 12 13 @Configuration(proxyBeanMethods = false) @ConditionalOnDiscoveryEnabled public class LoadBalancerClientConfiguration { @Bean @ConditionalOnMissingBean public ReactorLoadBalancer<ServiceInstance> reactorServiceInstanceLoadBalancer(Environment environment, LoadBalancerClientFactory loadBalancerClientFactory) { String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME); return new RoundRobinLoadBalancer( loadBalancerClientFactory.getLazyProvider(name, ServiceInstanceListSupplier.class), name); } } 以上，就可以看到，这里是使用了RoundRobinLoadBalancer来作为默认的负载均衡策略的。 ...