springcloud篇（一）

大大应届生

已于 2023-08-31 22:31:56 修改

阅读量99

点赞数 1

分类专栏： JAVA及相关基础文章标签： spring cloud spring 后端

于 2023-07-28 11:34:12 首次发布

本文链接：https://blog.csdn.net/weixin_45913657/article/details/131971454

版权

JAVA及相关基础专栏收录该内容

22 篇文章 0 订阅

订阅专栏

本文介绍了SpringCloud和SpringBoot的关系，SpringCloud的组件如Eureka、Zuul、Feign等在微服务架构中的作用，以及服务注册与发现工具Eureka和Zookeeper的区别，阐述了微服务之间的通信方式和SpringCloud组件的功能。此外，还讨论了服务高可用、服务调用过程以及防止雪崩的策略。

摘要由CSDN通过智能技术生成

1、SpringCloud和SpringBoot的区别和关系？

Spring Boot和Spring Cloud是两个独立的项目，但它们之间有着密切的关系。

Spring Boot： Spring Boot是一个用于简化Spring应用程序开发的框架，它可以快速地搭建一个独立运行的、生产级别的Spring应用程序。Spring Boot提供了自动配置、约定优于配置、快速开发等特性，使得开发者能够更加专注于业务逻辑的实现，而不需要过多关注底层的配置细节。Spring Boot可以独立运行，也可以与其他Spring项目一起使用。
Spring Cloud： Spring Cloud是一个构建分布式系统的工具集，它基于Spring Boot构建，提供了多种分布式系统的解决方案，包括服务注册与发现、配置中心、负载均衡、熔断器、路由等功能。Spring Cloud可以帮助开发者快速构建复杂的微服务架构，并提供了大量的开箱即用的组件，使得构建分布式系统变得更加简单。

关系： Spring Boot和Spring Cloud是紧密相关的，Spring Cloud是建立在Spring Boot之上的。也就是说，Spring Cloud依赖于Spring Boot，并且在Spring Boot的基础上提供了更多的分布式系统的功能。因此，在使用Spring Cloud之前，通常需要先使用Spring Boot搭建基本的Spring应用程序。Spring Boot简化了应用程序的开发过程，而Spring Cloud在此基础上提供了分布式系统的支持，使得构建微服务架构更加方便。

2、SpringCloud由哪些组件组成?

Spring Cloud是一个由多个组件组成的分布式系统开发框架，它提供了丰富的功能和工具，用于构建和管理微服务架构。以下是Spring Cloud的一些主要组件：

Eureka：服务注册与发现组件，用于实现服务的注册和发现，以便各个微服务能够相互调用。
Ribbon：客户端负载均衡组件，用于实现服务的负载均衡，确保请求能够均匀地分发到多个实例。
Feign：声明式服务调用组件，通过注解方式实现服务之间的调用，简化了服务调用的过程。
Hystrix：容错管理组件，用于实现服务的熔断和降级，保障系统在出现故障时仍然可用。
Zuul：API网关组件，用于统一管理和转发请求，提供了路由、过滤、负载均衡等功能。
Config：分布式配置中心，用于集中管理微服务的配置信息。
Bus：消息总线组件，用于在分布式系统中传播配置变化的消息。
Sleuth：分布式链路追踪组件，用于跟踪请求在不同微服务之间的调用链路。

除了上述主要组件，Spring Cloud还包括很多其他有用的工具和组件，用于实现微服务架构的各个方面。通过这些组件的组合和配置，开发者可以快速搭建复杂的分布式系统，并实现高可用、高性能、可扩展的微服务架构。

3、Eureka和Zookeeper的区别？

Eureka和Zookeeper都是分布式系统中常用的服务注册与发现工具，用于实现微服务架构中的服务发现功能，但它们在实现方式和特点上有一些区别。

数据一致性：
- Eureka：Eureka是一个AP（可用性和分区容忍性）模型的系统，它在出现网络分区时，可以保证部分可用性，即某些节点无法通信，但其他节点仍然可以正常提供服务。在Eureka集群中，数据的一致性不是特别强调，因为Eureka默认会定期（默认每30秒）通过心跳机制进行续约，如果某个节点在一定时间内没有续约，Eureka会将其从注册列表中剔除。
- Zookeeper：Zookeeper是一个CP（一致性和分区容忍性）模型的系统，它在出现网络分区时，会保证一致性，即所有节点都无法通信。Zookeeper采用了ZAB（Zookeeper Atomic Broadcast）协议来保证数据的一致性，当有新的数据写入或修改时，Zookeeper会通过广播的方式将数据同步给所有节点，从而保证所有节点的数据是一致的。
用途：
- Eureka：Eureka是Spring Cloud生态系统中最常用的服务注册与发现组件，特别适用于构建基于Spring Cloud的微服务架构。
- Zookeeper：Zookeeper是一个通用的分布式协调服务，除了用于服务注册与发现外，还可以用于配置管理、分布式锁等场景。
适用场景：
- Eureka：Eureka适用于对高可用性要求不是特别严格的场景，比如内部的企业应用。
- Zookeeper：Zookeeper适用于对一致性和可用性要求较高的场景，比如金融、电商等对系统可靠性要求较高的应用。

总体而言，Eureka和Zookeeper都是非常优秀的分布式系统组件，选择哪个取决于具体的业务场景和对系统可用性、一致性的要求。在Spring Cloud项目中，Eureka通常是首选的服务注册与发现组件，而Zookeeper则更多地应用于其他分布式系统中。

4、Zookeeper保证的CP和Eureka保证的AP是什么？

在分布式系统中，CP和AP是指一致性（Consistency）和可用性（Availability）的不同特性。

Zookeeper保证的是CP模型，即一致性和分区容忍性。在Zookeeper中，当网络分区出现时，所有节点无法通信，但仍然能够保证数据的一致性。Zookeeper采用了ZAB（Zookeeper Atomic Broadcast）协议来保证数据的一致性，当有新的数据写入或修改时，Zookeeper会通过广播的方式将数据同步给所有节点，从而保证所有节点的数据是一致的。这种方式确保了Zookeeper的数据强一致性特性。

而Eureka保证的是AP模型，即可用性和分区容忍性。在Eureka中，当网络分区出现时，Eureka可以保证部分可用性，即某些节点无法通信，但其他节点仍然可以正常提供服务。Eureka通过心跳机制进行续约，如果某个节点在一定时间内没有续约，Eureka会将其从注册列表中剔除。这种方式虽然降低了一致性的要求，但提高了系统的可用性。

综上所述，Zookeeper保证了一致性和分区容忍性，即CP模型，而Eureka保证了可用性和分区容忍性，即AP模型。不同的系统根据业务需求和性能要求可以选择适合自己的一致性和可用性模型。

5、Eureka的工作原理

Eureka是Netflix开源的一款基于RESTful的服务注册与发现组件，主要用于构建分布式系统中的服务注册与发现功能。其工作原理可以简述如下：

Eureka Server：Eureka Server是服务注册中心，所有的微服务都会注册到Eureka Server上。Eureka Server维护了一个服务注册表，用于存储所有已注册的服务信息。
服务注册：当一个微服务启动时，会向Eureka Server发送注册请求，将自己的服务信息注册到服务注册表中。服务信息包括服务名、主机地址、端口号等。
服务续约：注册成功后，微服务会周期性地向Eureka Server发送心跳请求，来表明自己仍然处于运行状态。如果Eureka Server在一定时间内没有收到心跳请求，就会认为该服务不可用，将其从服务注册表中移除。
服务发现：当一个微服务需要调用其他微服务时，它可以向Eureka Server发送服务发现请求，Eureka Server会返回所有可用的服务实例列表，微服务可以根据列表选择一个合适的实例进行调用。
客户端缓存：Eureka Client是一个与Eureka Server进行交互的客户端，每个微服务都需要添加Eureka Client依赖。Eureka Client会从Eureka Server获取服务注册表，并将服务注册表缓存在本地，以便快速查找可用的服务实例。
服务同步：Eureka Server之间可以相互注册，形成Eureka Server集群。当有服务注册或下线时，Eureka Server会相互同步服务注册表，保持所有节点的服务注册表一致性。

总的来说，Eureka的工作原理就是通过服务注册与发现的方式，使得各个微服务能够动态地找到彼此，实现分布式系统中的服务调用与通信。

6、Feign服务调用的过程

Feign是Spring Cloud中提供的一种声明式的服务调用客户端，用于简化微服务之间的通信。Feign的服务调用过程如下：

定义接口：首先，在消费者服务中，需要定义一个Java接口，用于声明要调用的服务的接口。这个接口中的方法就是对目标服务提供的API的描述。

@FeignClient(name = "provider-service") // 指定要调用的服务名
public interface ProviderService {
    @GetMapping("/hello") // 定义调用的具体API
    String hello();
}

启用Feign客户端：在消费者服务的启动类上，添加@EnableFeignClients注解，来启用Feign客户端。

@SpringBootApplication
@EnableFeignClients // 启用Feign客户端
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }
}

注入接口并调用：在消费者服务的业务代码中，可以直接注入上面定义的接口，并调用其中的方法，Feign会根据注解的信息，自动发起服务调用。

@RestController
public class ConsumerController {
    @Autowired
    private ProviderService providerService;

    @GetMapping("/invoke")
    public String invokeProviderService() {
        return providerService.hello();
    }
}

调用过程：当消费者服务调用invokeProviderService()方法时，Feign会根据接口上的注解信息，找到对应的提供者服务（provider-service），然后将请求转发给提供者服务。提供者服务处理完请求后，将结果返回给消费者服务。

总的来说，Feign的服务调用过程就是通过接口的方式来声明服务调用，而实际的服务调用则由Feign自动处理，无需开发者手动编写具体的HTTP请求代码。这样，Feign极大地简化了微服务之间的通信代码，提高了开发效率。

7、微服务之间如何通信？

微服务之间可以通过多种方式进行通信，常见的通信方式有：

HTTP/HTTPS：微服务可以通过HTTP或HTTPS协议来进行通信。这是最常见的通信方式，也是最简单的方式之一。一个微服务可以作为客户端发送HTTP请求到另一个微服务作为服务器，然后服务器处理请求并返回结果。
RPC（Remote Procedure Call）：RPC是一种远程过程调用协议，用于实现不同微服务之间的通信。通过RPC，一个微服务可以像调用本地方法一样调用远程服务的方法，使得服务之间的通信更加简单和透明。
消息队列：微服务可以使用消息队列来进行异步通信。一个微服务可以将消息发送到消息队列，然后其他微服务可以从队列中订阅消息并处理。这样可以实现解耦和异步处理，提高系统的可伸缩性和灵活性。
gRPC：gRPC是一种高性能、开源的RPC框架，可以用于构建跨平台、跨语言的微服务通信。它使用HTTP/2协议作为传输协议，支持多种语言，提供强大的类型定义和序列化机制。
RESTful API：RESTful API是一种基于HTTP协议的API设计风格，可以用于实现微服务之间的通信。通过RESTful API，一个微服务可以暴露自己的接口给其他微服务调用。

不同的通信方式适用于不同的场景，开发者可以根据实际需求和系统架构选择合适的通信方式。在微服务架构中，通信的性能、可靠性和扩展性是非常重要的考虑因素。因此，选择合适的通信方式对于构建高性能和稳定的微服务系统非常关键。

8、SpringCloud和dubbo的区别？

Spring Cloud和Dubbo是两个常用的分布式服务框架，它们有以下主要区别：

开发生态：Spring Cloud是基于Spring生态体系的分布式服务框架，而Dubbo是阿里巴巴开源的分布式服务框架。
通信协议：Spring Cloud通常使用HTTP或RESTful API作为通信协议，而Dubbo使用自定义的RPC协议。
注册中心：Spring Cloud使用Eureka、Consul等作为注册中心，而Dubbo使用Zookeeper作为注册中心。
服务调用：Spring Cloud可以使用Feign或RestTemplate进行服务调用，而Dubbo使用RPC方式进行服务调用。
高可用性：Spring Cloud的服务注册中心和配置中心支持集群部署，提供高可用性。而Dubbo的Zookeeper注册中心也可以进行集群部署，但配置中心需要自行实现。
生态扩展：由于Spring Cloud基于Spring生态，可以很方便地集成其他Spring框架和组件，如Spring Security、Spring Data等。而Dubbo作为一个单独的框架，其生态扩展相对有限。
社区支持：Spring Cloud作为Spring社区的一部分，得到了广泛的支持和贡献。Dubbo也有较大的用户群体和活跃的社区。

总体来说，Spring Cloud更适合于使用Spring生态的项目，尤其是已经使用了Spring Boot的项目。Dubbo则更适合于Java企业级应用，尤其是阿里巴巴等大型互联网企业。选择使用哪个框架取决于项目的实际需求、技术栈和团队的经验。

9、Eureka怎么实现高可用？

要实现Eureka的高可用性，可以采用以下步骤：

启动多个Eureka Server：在不同的机器上启动多个Eureka Server实例，每个实例都是一个独立的注册中心。
注册中心互相注册：在每个Eureka Server的配置文件中，指定其他Eureka Server的地址，使得各个Eureka Server互相注册。
使用集群配置：为了确保Eureka Server的高可用性，需要配置集群信息。在每个Eureka Server的配置文件中，指定相同的服务注册中心名称（eureka.client.service-url.defaultZone属性）。
使用负载均衡：在服务消费者（如Spring Cloud应用）中，通过负载均衡策略来访问Eureka Server，以实现高可用性和服务发现。
使用健康检查：设置合适的心跳和超时时间，Eureka Server可以根据心跳来检测服务的健康状态，当某个Eureka Server超过一定时间未收到心跳时，将其从注册中心中剔除。

通过上述步骤，可以确保Eureka Server的高可用性，即使某个Eureka Server出现故障，其他Eureka Server仍然能够继续提供服务注册和发现功能，保证了整个服务注册中心的可用性。

10、什么是网关？网关的作用？

网关（Gateway）是一个用于转发请求的服务器，它是客户端和后端服务之间的中间层。网关的主要作用是在微服务架构中统一处理请求、路由请求和协调服务。

网关的作用包括：

路由转发：网关根据请求的URL路径将请求转发给相应的后端服务。通过路由转发，可以实现请求的负载均衡和动态路由。
服务聚合：当一个页面需要多个服务的数据时，网关可以将多个服务的请求聚合为一个请求，然后将聚合后的请求发送给后端服务，减少客户端的请求数量。
请求过滤和校验：网关可以对请求进行过滤和校验，例如校验请求的合法性、鉴权等，确保只有合法的请求能够访问后端服务。
限流和熔断：网关可以对请求进行限流和熔断，防止后端服务被过多的请求压垮，保护系统的稳定性。
日志记录：网关可以记录请求和响应的日志，方便后续的监控和分析。
缓存：网关可以对请求的结果进行缓存，提高系统的响应速度。

通过网关，可以实现对微服务架构的统一管理和控制，提高系统的可扩展性、稳定性和安全性。常见的网关技术有Zuul、Spring Cloud Gateway等。

11、什么是SpringCloudZuul（服务网关）

Spring Cloud Zuul是Spring Cloud生态中的服务网关组件，它基于Netflix的Zuul项目进行了封装和增强，用于实现微服务架构中的请求路由、请求过滤、请求转发等功能。

服务网关是微服务架构中的一个关键组件，它作为系统的入口，接收所有的客户端请求，并将请求转发给后端的微服务。服务网关的作用主要有以下几个方面：

路由转发：服务网关根据请求的URL路径将请求转发给相应的后端微服务。通过路由转发，可以实现请求的负载均衡和动态路由。
请求过滤和校验：服务网关可以对请求进行过滤和校验，例如校验请求的合法性、鉴权等，确保只有合法的请求能够访问后端微服务。
负载均衡：服务网关可以通过负载均衡算法将请求分发到不同的微服务实例上，从而实现请求的负载均衡。
熔断和限流：服务网关可以对请求进行熔断和限流，防止后端微服务被过多的请求压垮，保护系统的稳定性。
请求聚合：当一个页面需要多个微服务的数据时，服务网关可以将多个微服务的请求聚合为一个请求，然后将聚合后的请求发送给后端微服务，减少客户端的请求数量。

Spring Cloud Zuul提供了丰富的功能和配置选项，可以灵活地配置和定制网关的行为。它与Spring Cloud的其他组件集成良好，可以与Eureka、Ribbon、Hystrix等组件无缝协作，为微服务架构提供了强大的网关能力。

12、网关与过滤器的区别？

网关和过滤器都是微服务架构中的关键组件，但它们的作用和职责有一些区别。

网关（Gateway）：
- 网关是整个系统的入口，所有的外部请求都通过网关进入系统。
- 网关负责将请求路由到相应的微服务，实现请求的转发和负载均衡。
- 网关可以进行请求的过滤、校验、认证和鉴权，确保只有合法的请求能够访问后端微服务。
- 网关还可以实现请求的聚合和分割，将多个请求合并成一个请求或者将一个请求拆分成多个请求发送给不同的微服务。
过滤器（Filter）：
- 过滤器是在网关或者微服务内部对请求进行拦截和处理的组件。
- 过滤器可以对请求进行预处理和后处理，实现请求的验证、鉴权、日志记录等功能。
- 过滤器可以分为全局过滤器和局部过滤器，全局过滤器对所有的请求都生效，而局部过滤器只对特定的路由或服务生效。
- 过滤器可以根据自定义的规则对请求进行拦截，例如限制请求频率、鉴权验证、日志记录等。

总的来说，网关是整个系统的入口，负责请求的路由和转发，并进行全局性的请求处理和控制；而过滤器是在网关或者微服务内部对请求进行拦截和处理，实现针对性的请求处理和控制。两者在微服务架构中都扮演着重要的角色，协同工作，确保系统的安全、稳定和高效运行。

13、常用网关框架

常用的网关框架包括：

Spring Cloud Gateway：Spring Cloud官方推出的网关组件，基于Spring WebFlux框架，支持异步非阻塞的请求处理，可以与Spring Cloud生态无缝集成。
Netflix Zuul：Netflix开源的网关框架，是Spring Cloud Gateway之前的主要网关组件，在Spring Cloud生态中有很广泛的应用。
Nginx：不仅是一个高性能的Web服务器，还可以作为反向代理和负载均衡器使用，也常被用作网关。
Kong：基于Nginx和OpenResty的API网关，支持插件扩展，提供了丰富的功能和配置选项。
Apache APISIX：由Apache基金会孵化的API网关，提供了高性能和灵活的路由规则和插件系统。
Istio：服务网格中的一部分，提供了全面的流量管理、请求路由和安全控制功能，支持Kubernetes等平台。

这些网关框架都具有强大的功能和灵活的配置选项，可以根据实际需求选择合适的网关框架来实现对微服务的路由、负载均衡、安全控制和请求处理等功能。

14、Zuul和Nginx区别?

Zuul和Nginx是两种不同的网关框架，它们都可以用于实现反向代理和请求路由等功能，但在一些方面有一些区别：

开发框架：Zuul是Spring Cloud生态中的组件，基于Spring WebFlux框架，而Nginx是一个独立的高性能Web服务器和反向代理，基于C语言开发。
功能丰富程度：Nginx是一个成熟的、功能丰富的Web服务器和反向代理，支持负载均衡、缓存、Gzip压缩等功能，可以应用于各种场景。而Zuul主要用于微服务架构中的服务路由、请求转发和负载均衡，集成了Eureka等Spring Cloud组件，更适合于Spring Cloud环境下的微服务架构。
配置语言：Nginx使用自己的配置语言，配置文件相对复杂，但功能强大。而Zuul使用Spring Cloud的配置方式，配置相对简单，可以与其他Spring Cloud组件无缝集成。
插件扩展：Nginx支持通过Lua脚本等方式进行插件扩展，可以实现一些定制化功能。而Zuul也支持通过Filter进行定制化处理，但相对于Nginx的插件扩展能力略有限制。
生态支持：Nginx拥有广泛的用户和社区支持，应用非常广泛，已经成为一个成熟的解决方案。Zuul则是Spring Cloud生态中的一部分，与Spring Cloud的其他组件集成紧密，适合于Spring Cloud环境下的微服务架构。

综上所述，Nginx适用于各种场景的反向代理和负载均衡需求，功能强大，配置相对复杂；而Zuul更适用于Spring Cloud环境下的微服务架构，配置简单，集成Spring Cloud组件方便。在选择网关框架时，可以根据实际需求和项目架构来选择合适的方案。

15、负载均衡的意义是什么？

负载均衡是一种用于分配和管理网络流量的技术，其主要意义在于解决服务器或网络设备的性能瓶颈和单点故障问题，提高系统的稳定性、可用性和性能。具体来说，负载均衡的意义包括以下几点：

提高性能：负载均衡将客户端请求均匀地分发到多台服务器上，避免某一台服务器过载，从而提高了系统的整体性能和吞吐量。
高可用性：通过负载均衡，即使某一台服务器发生故障，其他服务器仍然可以继续处理客户端请求，从而保证系统的高可用性，降低了系统宕机的风险。
扩展性：通过增加服务器数量，可以轻松扩展系统的容量和处理能力，满足不断增长的用户访问需求。
节约成本：通过合理分配和利用服务器资源，减少服务器的空闲时间，从而节约了硬件和能源成本。
优化网络流量：负载均衡可以根据服务器的负载情况选择最优的服务器来处理请求，从而减少了网络拥塞，提高了网络传输效率。

总的来说，负载均衡是提高系统性能、可用性和扩展性的重要手段，特别是在高并发、大流量的网络环境下，负载均衡可以有效地分担服务器的压力，保障系统的稳定运行。

16、Hystrix防止雪崩的方式？

Hystrix是一种用于处理分布式系统中的故障和延迟问题的库，可以防止服务雪崩效应。为了防止雪崩效应，Hystrix采取了以下几种方式：

服务隔离：Hystrix使用线程池来隔离服务调用，不同的服务调用被分配到不同的线程池中，避免某个服务调用的问题影响到其他服务调用。
服务降级：当某个服务出现问题或延迟较高时，Hystrix可以提供一个备用的降级服务，以保证系统的稳定性和可用性。
熔断器：Hystrix会根据服务调用的失败率和延迟情况来判断服务是否处于故障状态，当服务故障超过一定阈值时，熔断器会打开，停止向该服务发起请求，避免对该服务造成进一步的压力。
请求缓存：Hystrix可以缓存服务调用的结果，避免重复的请求对服务造成额外的压力。
请求合并：Hystrix可以将多个并发的请求合并为一个请求，减少了对服务的并发访问，降低了系统的压力。

通过以上方式，Hystrix能够有效地防止服务雪崩效应，保障了系统的稳定性和可用性。同时，Hystrix还提供了实时的监控和报警功能，可以帮助开发人员及时发现和解决服务故障，保障系统的正常运行。