SpringCloud面试题以及答案

1、SpringCloud是什么？

1、 Spring Cloud是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用SpringBoot的开发风格做到一键启动和部署。

2、 Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

2、网关的作用是什么？

在微服务架构中，网关（API Gateway）扮演着重要的角色，它实现了面向客户端（可能是用户界面UI、外部系统、或其他服务）的请求统一入口。网关的主要作用包括：

请求路由：网关根据请求的内容，如URL路径或请求参数，将请求路由到正确的微服务。这隐藏了微服务架构中服务分布的复杂性，并且当服务实例的位置变化时，客户端无需知道。
负载均衡：网关可以在多个服务实例之间分配请求，以实现负载均衡，提高系统的可用性和容错性。
认证和授权：网关可以在转发请求到后端服务之前进行用户认证和权限校验，确保只有合法的请求可以访问后端服务。
限流和熔断：网关可实现对请求的限流，保护后端服务不被过多的请求压垮。同时，通过熔断机制，可以在后端服务不可用时提供降级服务。
聚合服务：网关可以将多个服务的调用结果聚合后一次性返回给客户端，减少客户端与服务器之间的交互次数。
API适配与转换：网关可以处理客户端与服务之间的API不兼容问题。它可以转换协议、路径、请求和响应格式，使得前后端能够顺畅交互。
协议转换：网关可以将外部的HTTP/HTTPS请求转换为内部服务可能使用的其他通信协议，如WebSocket、RPC等。
跨域请求处理：网关可以处理跨域资源共享（CORS）问题，允许不同域的前端应用调用后端服务。
日志记录与监控：网关可以记录请求和响应的详细信息，用于日志记录、问题诊断、以及监控服务的使用情况。
安全加强：网关可以提供一些安全增强功能，如SSL终端、请求签名的验证等。
缓存：网关可以对常见的请求进行缓存，减少对后端服务的调用，从而提高系统的响应速度。

总结来说，网关提供了一个抽象层，用于隔离、保护、管理和维护微服务系统中的服务。它简化了客户端的实现，并为微服务架构提供了更好的安全性、可伸缩性和可维护性。常见的API网关实现包括Netflix Zuul、Spring Cloud Gateway、Kong、APIGee等。

3、什么是eureka?

Eureka 是 Netflix 开发的服务发现框架，它是 Spring Cloud Netflix 子项目的一部分，经常被用在基于微服务的架构中。服务发现是微服务架构中的一个关键组件，它允许服务实例在启动时注册自己的位置信息，并允许其他服务查找和发现这些实例，从而进行通信。

Eureka 包含两个主要的组件：

Eureka Server：服务注册中心，它提供了一个服务注册的平台，其他服务可以注册自己或找到需要通信的服务。Eureka Server 提供了 REST API，服务实例可以通过这些API进行注册、注销、发送心跳和查询。通常在一个微服务架构中会部署一个或多个 Eureka Server 实例，以实现高可用性。
Eureka Client：服务实例使用 Eureka Client 来与 Eureka Server 交互。Eureka Client 在启动时将自己的信息注册到 Eureka Server，并定期发送心跳以维护其在服务注册表中的状态。此外，Eureka Client 也会缓存所有服务的注册信息，以便即使在Eureka Server 不可用的情况下，也能实现服务间通信。

Eureka遵守AP原则（Availability 可用性和 Partition tolerance 分区容错性）的 CAP 理论。这意味着在网络分区故障发生时，Eureka 依旧可以提供服务发现功能，确保系统整体的高可用性。为了实现这一点，Eureka Server 在某些情况下可能会接受非一致性的注册信息，例如，当网络分区导致 Eureka Client 不能与 Server 正常通信时，Server 会保留这些客户端的注册信息，而不是立即移除。

随着 Spring Cloud 的发展，原生的 Spring Cloud Netflix（包括 Eureka）项目逐渐进入维护模式，并且 Spring Cloud 社区推出了新的服务发现解决方案，如 Spring Cloud Consul、Spring Cloud Zookeeper，以及非 JVM 语言环境下常用的服务发现工具，如 Consul、etcd 和 Apache Zookeeper。此外，Spring Cloud Gateway 等新成员加入了 Spring Cloud 生态，提供了与服务发现相集成的现代化网关解决方案。

4、Ribbon和Feign调用服务的区别

Ribbon 和 Feign 都是 Netflix 提供的开源项目，并且它们都被集成在 Spring Cloud 生态系统中，用于服务之间的调用。尽管它们的目的都是为了简化服务消费者与服务提供者之间的通信，但它们的工作方式和抽象层级有所不同。

Ribbon

Ribbon 主要是一个客户端负载均衡器。它可以在服务消费者端对服务提供者的实例进行负载均衡，从而实现对下游服务的调用。Ribbon 通常与 Eureka 服务发现组件结合使用，Ribbon 会从 Eureka 获取服务实例的列表，并根据特定的负载均衡算法（如轮询、随机等）选择一个实例进行调用。Ribbon 是一个库，它提供了一系列的配置项用于 http 请求，比如连接超时、读取超时、重试机制等。

当使用 Ribbon 时，服务消费者通常使用 RestTemplate 或其他 HTTP 客户端来实现请求的发送，而 Ribbon 作为中间层提供负载均衡功能。

Feign

Feign 是一个声明式的 HTTP 客户端。它的目的是简化 HTTP API 客户端的编写。使用 Feign，开发者可以通过创建一个接口并用注解来配置请求的详情，从而实现对 HTTP 请求的封装。Feign 内部集成了 Ribbon，所以也具有客户端负载均衡的能力。Feign 默认集成了 Hystrix，提供了断路器的支持。

Feign 更关注于简化 HTTP 调用过程，使得编写 HTTP 客户端代码像编写普通 Java 接口一样简单。通过注解，开发者可以定义服务接口，然后 Feign 会自动实现这个接口并处理所有的请求发送和异常处理工作。

Ribbon vs Feign

抽象层级：Feign 提供了更高层级的抽象，通过 Java 接口加注解的方式定义服务调用，而 Ribbon 更多是作为库来提供客户端的负载均衡功能。
编码风格：Feign 的编码风格是声明式的，通过接口和注解来定义服务调用；Ribbon 需要开发者自己使用 RestTemplate 构建 HTTP 请求。
集成组件：Feign 默认集成了 Ribbon 和 Hystrix，提供了负载均衡和断路器功能；Ribbon 需要与其他组件如 Eureka 结合使用以提供服务发现和客户端负载均衡。

示例

使用 Ribbon 时可能需要这样的代码：

@Service
public class RibbonService {@Autowiredprivate RestTemplate restTemplate;public String findServiceData(String serviceId) {// 使用 Ribbon 进行负载均衡return restTemplate.getForObject("http://" + serviceId + "/data", String.class);}
}

使用 Feign 时的代码：

@FeignClient(name = "serviceId")
public interface FeignService {@GetMapping("/data")String findServiceData();
}

结论

尽管 Ribbon 和 Feign 都用于服务间调用，但 Feign 提供了更简洁易用的方式来进行服务调用。随着 Spring Cloud 的发展，Spring Cloud OpenFeign 项目成为了集成 Feign 功能的首选方式，它提供了对 Spring MVC 注解的支持，并与其它 Spring Cloud 组件（如服务发现、断路器等）紧密集成。开发人员可以根据具体需求和个人偏好，在 Ribbon 和 Feign 之间做出选择。

5、微服务有什么特点？

微服务架构是一种将单个应用程序作为一套小服务的开发方式，每个服务运行在自己的进程中，并通常围绕业务能力组织。这些服务可以独立部署、扩展，并通过轻量级通信机制（通常是 HTTP RESTful API）进行互相协作。以下是微服务架构的一些关键特点：

服务组件化：微服务将应用程序分解为多个组件化服务，每个服务负责单一业务功能。
围绕业务能力组织：服务是围绕业务能力构建的，每个服务代表一个业务领域。
独立部署：每个服务都可以独立部署在不同的服务器或容器中，不会相互影响。
分布式开发：微服务架构天然支持分布式系统开发，可以由不同的团队独立开发和部署服务。
去中心化治理：微服务倾向于使用去中心化的方式来管理服务，包括去中心化的数据库管理和服务治理。
去中心化数据管理：每个服务可以有自己的本地数据存储，不同服务之间不共享数据库。
基础设施自动化：微服务架构通常利用自动化工具来自动化测试、部署和运维过程。
容错性和弹性设计：微服务通过设计来处理失败，利用断路器模式等防止服务间故障的蔓延。
轻量级通信：服务之间通过基于 HTTP 的 RESTful API 或轻量级消息传递进行协作。
可维护性和可测试性：由于服务的规模较小，它们更容易维护和测试。
松耦合：每个服务之间保持松耦合，只通过定义良好的API进行通信。
可观测性：通过日志记录、监控和跟踪，可以观测服务的健康状况和性能指标。
技术多样性：不同的服务可以使用不同的编程语言、框架和数据存储技术。

微服务架构提供了巨大的灵活性和可扩展性，但同时也带来了复杂性。例如，分布式系统固有的复杂性、如何确保服务间数据的一致性、服务的发现和治理、以及如何防止服务间接口变更导致的问题等，这些都是采用微服务架构时需要面对的挑战。因此，对于是否采用微服务架构，企业需要根据自己的业务需求、组织结构和技术能力来决定。

6、什么是CAP原则?

CAP原则：又称CAP定理，指的是在一个分布式系统中，强一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
强一致性(Consistency)：访问所有的节点，得到的数据结果都是一样的。
可用性(Availability)：保证每个请求不管成功或者失败都有响应。
分区容错性(Partiton tolerance)：系统中任意信息的丢失或失败不会影响系统的继续运作。

7、Nacos和Eureka的区别?

共同点
①都支持服务的注册和拉取。
②都支持服务提供者以心跳检测来判断是否健康(临时实例)。

不同点
①nacos支持注册中心主动询问服务提供者的状态(非临时实例)。
②nacos支持注册中心消息变更主动推送。
③心跳不正常会被剔除(临时实例)

8、什么是服务降级、服务熔断、服务隔离

服务降级：当出现请求超时、资源不足时(线程或者信号量)，会进行服务降级，就是去返回fallback方法的结果。
服务熔断：当失败率(网络故障或者超时造成)达到阈值自动触发降级，是一种特殊的降级。
服务隔离：为隔离的服务开启一个独立的线程，这样在高并发情况下，也不会影响该服务。一般使用线程池实现(还有信号量方式实现)。

9、服务降级和服务熔断的区别

区别：降级每个请求都会发送过去，而熔断不一定，达到失败率，请求就不会再去发送了。请求出错时熔断返回的是fallback数据，而熔断则是一段时间不会去访问服务提供者。
比如：
①降级：A调B，发送10个请求，即使每个请求都超时，也会去请求B。
②熔断：A调B，发送10个请求，失败率设置为50%，如果5个请求失败，此时失败率到了50%，那么后面的5个请求就不会走到B。

在Spring Cloud中，使用Hystrix实现断路器模式，以防止服务间的级联失败。断路器在远程服务调用失败时打开，阻断进一步的调用。

@Service
public class ProductService {@HystrixCommand(fallbackMethod = "fallbackRetrieveProduct") public Product retrieveProduct(String productId) { // 远程服务调用逻辑}public Product fallbackRetrieveProduct(String productId) { // 断路器打开时的备用逻辑return new Product("default", "Default Product"); }}

10、@LoadBalanced 什么原理？

在Spring Cloud微服务架构中，@LoadBalanced是一个用于标注在RestTemplate实例上的注解，它使得RestTemplate具有客户端负载均衡的能力。当使用@LoadBalanced注解标注RestTemplate时，这个RestTemplate在发送HTTP请求时，会通过Ribbon（集成在Spring Cloud中的客户端负载均衡器）选取服务实例，并对这些实例进行负载均衡。

以下是@LoadBalanced工作原理的简化说明：

服务发现：首先，当微服务启动并注册到服务注册中心（例如Eureka）时，它们的实例信息（包括服务ID、主机名、端口等）会在注册中心被记录下来。
RestTemplate创建：在Spring应用中，创建一个RestTemplate Bean并使用

@Bean
@LoadBalanced
public RestTemplate restTemplate() {return new RestTemplate();
}

服务调用：当通过@LoadBalanced标注的RestTemplate发出请求时，Ribbon会拦截这些请求。请求中的服务ID（例如http://service-id/endpoint）不是一个常规的域名或IP地址，而是服务注册中心中注册的服务ID。
负载均衡：Ribbon客户端会根据服务ID查询服务注册中心，获取服务实例列表。然后Ribbon会根据配置的负载均衡策略（例如轮询、随机等）从这些实例中选择一个实例。
请求转发：Ribbon会将原始请求转发到选定的服务实例上。这一转发过程对于RestTemplate的调用者是透明的。
响应返回：服务实例处理请求并返回响应，响应会经过Ribbon返回给原始调用者。

综上所述，@LoadBalanced的原理是将Ribbon集成到RestTemplate中，以提供对服务实例的自动请求分发和负载均衡。这种方式使得服务之间的调用不再依赖于硬编码的URL，而是可以通过服务注册中心动态查询实例，提高了微服务架构的灵活性和可扩展性。随着Spring Cloud的发展，除了Ribbon之外，还有其他负载均衡器可以与@LoadBalanced一起使用，例如Spring Cloud LoadBalancer。

如果不显式添加 @LoadBalanced 注解，RestTemplate 会像普通的HTTP客户端一样工作。这意味着它不会具备内置的负载均衡能力，而是会直接根据给定的 URL 发送请求。

在没有 @LoadBalanced 注解的情况下，你需要显式提供完整的服务URL，包括服务的主机名和端口号，RestTemplate 将把请求发送到这个具体的地址。