Spring Cloud 面试题

最新推荐文章于 2024-06-12 23:54:04 发布

路从脚起

最新推荐文章于 2024-06-12 23:54:04 发布

阅读量742

点赞数 28

本文链接：https://blog.csdn.net/weixin_39042870/article/details/139046706

版权

什么是 Spring Cloud ？

Spring Cloud 是一个基于 Spring Boot 的微服务架构开发工具集，它为开发者提供了一系列在分布式系统（如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态）环境中快速构建一些常见模式的工具（例如配置管理、服务发现、断路器等）。Spring Cloud 利用 Spring Boot 的开发便利性，简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器以及分布式会话等。

Spring Cloud 核心功能是什么？

Spring Cloud 主要提供了如下核心的功能：

服务发现与注册：Spring Cloud 提供了服务发现和注册的机制，允许微服务在启动时注册自己，并且可以在运行时发现其他服务。这通常通过 Eureka、Consul 或 Zookeeper 等服务实现。
配置管理：Spring Cloud Config 提供了中心化的配置管理服务，允许您在服务器上管理应用程序配置文件，并可以在运行时动态刷新配置。
路由：Spring Cloud Gateway 提供了一种路由机制，可以根据请求的路径、header等信息将请求路由到不同的微服务上。
断路器：Spring Cloud Circuit Breaker 提供了断路器的实现，如 Netflix Hystrix，用于防止一个微服务的故障影响到整个系统，提高系统的稳定性和弹性。
分布式消息传递：Spring Cloud Stream 支持构建基于消息驱动的微服务，使用 Apache Kafka 或 RabbitMQ 作为消息中间件。
链路追踪：Spring Cloud Sleuth 和 Zipkin 可以用来追踪服务间的请求链路，便于故障排查和性能分析。
分布式事务：Spring Cloud Transaction Manager 提供了在微服务架构中处理分布式事务的能力。
安全性：Spring Cloud Security 提供了在微服务环境中实现安全性的解决方案，例如 OAuth2 和 JWT。
控制总线：Spring Cloud Bus 提供了事件总线，用于在集群中传播状态变化或事件，例如配置更改。
领导选举和集群状态：Spring Cloud Cluster 提供了在分布式系统中选举领导者的机制，以及管理集群状态的功能。

Spring Cloud 有哪些组件？

	Netflix	阿里	其它
注册中心	Eureka	Nacos	Zookeeper、Consul、Etcd
熔断器	Hystrix	Sentinel	Resilience4j
网关	Zuul	暂无	Spring Cloud Gateway
负载均衡	Ribbon	Dubbo(未来)	spring-cloud-loadbalancer

其它组件，例如配置中心、链路追踪、服务引用等等，都有相应其它的实现。

什么是微服务？

微服务是一种软件开发技术，它将应用程序构建为一组小的、独立的、松散耦合的服务，每个服务运行在自己的进程中，并且通过轻量级的通信机制（通常是 HTTP RESTful API）进行协作。这些服务围绕业务功能组织，每个服务都有自己的数据存储和业务逻辑，可以独立部署、扩展和更新。

微服务架构的主要特点和优势包括：

模块化：微服务架构将应用程序分解为小的、自治的模块，每个模块负责应用程序的一部分功能。
独立性：每个微服务可以独立部署和扩展，不会影响到其他服务的运行。
灵活性：微服务可以使用不同的编程语言和技术栈来实现，允许团队根据服务的需求选择最合适的技术。
容错性：由于服务是独立的，一个服务的故障不会导致整个应用程序崩溃，可以通过重试、超时、断路器等机制来处理服务间的故障。
易于维护和更新：可以单独更新和部署每个服务，不需要重新部署整个应用程序。
可扩展性：可以根据需求对单个服务进行扩展，而不需要扩展整个应用程序。
解耦：服务之间通过定义良好的 API 进行通信，降低了服务间的耦合度。

缺点：

分布式系统的负责性。
多服务运维难度，随着服务的增加，运维的压力也在增大。
系统部署依赖。
服务间通信成本。
数据一致性。
系统集成测试。
性能监控。

注册中心
在 Spring Cloud 中，能够使用的注册中心，还是比较多的，如下：

spring-cloud-netflix-eureka-server 和 spring-cloud-netflix-eureka-client ，基于 Eureka 实现。
spring-cloud-alibaba-nacos-discovery ，基于 Nacos 实现。
spring-cloud-zookeeper-discovery ，基于 Zookeeper 实现。
… 等等

以上的实现，都是基于 spring-cloud-commons 的 discovery 的 DiscoveryClient 接口，实现统一的客户端的注册发现。

为什么要使用服务发现？

简单来说，通过注册中心，调用方(Consumer)获得服务方(Provider)的地址，从而能够调用。

当然，实际情况下，会分成两种注册中心的发现模式：

客户端发现模式
服务端发现模式

在 Spring Cloud 中，我们使用前者，即客户端发现模式。

Eureka

作用：实现服务治理（服务注册与发现）
简介：Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。
由两个组件组成：Eureka 服务端和 Eureka 客户端。Eureka 服务端，用作服务注册中心，支持集群部署。Eureka 客户端，是一个 Java 客户端，用来处理服务注册与发现。

在应用启动时，Eureka 客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。

Eureka 原理，整体如下图：

Eureka 如何实现集群？

配置 Eureka 服务器：首先，需要配置多个 Eureka 服务器实例。每个实例都可以是一个独立的 Eureka 服务器，它们通过彼此注册来形成一个集群。在配置文件中，你需要指定 Eureka 服务器的相关配置，例如应用名称、端口、注册中心地址等。
相互注册：在每个 Eureka 服务器的配置中，需要指定其他 Eureka 服务器的地址，以便它们可以相互注册。这通常通过 eureka.client.serviceUrl.defaultZone 属性来实现，该属性包含了其他 Eureka 服务器的 URL。
实例配置：每个 Eureka 服务器实例都需要有一个唯一的实例 ID，这可以通过 eureka.instance.instanceId 属性来设置。同时，需要确保每个实例的 hostName 或 ipAddress 配置正确，以便它们可以在集群中正确地相互识别。
复制数据：Eureka 服务器实例之间会相互复制注册表信息，这样每个实例都会有一份完整的注册表副本。这是通过 Eureka 的内置机制自动完成的。
客户端配置：Eureka 客户端（即微服务应用程序）需要配置 Eureka 服务器的地址列表，以便它们可以注册到集群中的任何一个服务器实例。客户端会从任一服务器获取注册表信息，并与之通信。
高可用性：通过运行多个 Eureka 服务器实例并使它们相互注册，可以实现高可用性。即使某个 Eureka 服务器实例发生故障，其他实例仍然可以提供服务，客户端也可以继续注册和发现服务。
考虑网络分区：在部署 Eureka 集群时，需要考虑网络分区的可能性，并配置适当的心跳和超时参数，以确保集群的稳定性和一致性。

聊聊 Eureka 缓存机制？

Eureka

什么是 Eureka 自我保护机制？

Eureka 自我保护机制是 Netflix Eureka 中的一种特性，用于在面临网络分区或其他故障导致大量服务实例无法正常心跳时，防止注册中心将健康的实例错误地剔除出服务列表。自我保护模式是一种应对网络不稳定性的安全措施，它允许 Eureka 服务器在不确定网络问题是否影响了客户端心跳的情况下，保留那些没有及时心跳的实例信息。

在正常情况下，Eureka 客户端会定期向 Eureka 服务器发送心跳来更新它们的租约。如果 Eureka 服务器在一段时间内没有收到某个实例的心跳，它会将该实例从注册表中移除，认为该实例已经宕机。但是，在网络问题或系统负载过高的情况下，客户端可能无法及时发送心跳，这可能会导致 Eureka 服务器错误地认为大量实例已经宕机，从而将它们从注册表中移除。

当 Eureka 服务器进入自我保护模式时，它会停止移除那些没有及时心跳的实例。这样做是为了避免在网络问题恢复后，实例被错误地认为已经下线，从而避免了服务中断。自我保护模式是一种权衡，它优先保证了系统的可用性而不是一致性。

自我保护机制可以通过 Eureka 服务器配置中的 `
eureka.server.enable-self-preservation` 属性来启用或禁用。如果禁用自我保护机制，Eureka 服务器将不会考虑网络问题，而是严格按照心跳规则来管理注册表。

自我保护机制的触发条件是，在过去的分钟内，注册的实例数量小于阈值（由 `
eureka.server.renewal-percent-threshold` 配置），并且实例数量的下降比例超过了另一个阈值（由 `eureka.server.renewal-threshold-update-interval-ms` 配置）。如果这些条件满足，Eureka 服务器将进入自我保护模式。

负载均衡

在 Spring Cloud 中，能够使用的负载均衡，如下：

spring-cloud-netflix-ribbon ，基于 Ribbon 实现。
spring-cloud-loadbalancer ，提供简单的负载均衡功能。

以上的实现，都是基于 spring-cloud-commons 的 loadbalancer 的 ServiceInstanceChooser 接口，实现统一的服务的选择。并且，负载均衡组件在选择需要调用的服务之后，还提供调用该服务的功能，具体方法见 LoadBalancerClient 接口的 #execute(...) 方法。

为什么要负载均衡？

简单来说，随着业务的发展，单台服务无法支撑访问的需要，于是搭建多个服务形成集群。那么随之要解决的是，每次请求，调用哪个服务，也就是需要进行负载均衡。

目前负载均衡有两种模式：

客户端模式
服务端模式

在 Spring Cloud 中，我们使用前者，即客户端模式。

负载平衡的意义什么？

在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。

Ribbon

作用：主要提供客户侧的软件负载均衡算法。
简介：Spring Cloud Ribbon 是一个基于 HTTP 和 TCP 的客户端负载均衡工具，它基于 Netflix Ribbon 实现。通过 Spring Cloud 的封装，可以让我们轻松地将面向服务的 REST 模版请求自动转换成客户端负载均衡的服务调用。
注意看上图，关键点就是将外界的 rest 调用，根据负载均衡策略转换为微服务调用。

Ribbon 原理，整体如下图：

Ribbon 有哪些负载均衡算法？

轮询（Round Robin）：这是默认的负载均衡策略，请求会按照时间顺序逐一分配到不同的后端服务器，类似于队列中的先进先出。
加权轮询（Weighted Round Robin）：在这种策略中，可以为每个服务器分配一个权重，权重高的服务器会接收更多的请求。
最少连接（Least Connections）：请求会被分配到当前连接数最少的服务器。这适用于后端服务器处理能力差异不大的情况，可以帮助均衡负载。
随机（Random）：请求会随机分配到后端服务器。这种方法简单，但在高负载下可能效果不佳。
断路器（Zone Avoidance）：这种策略会尝试避免已经断路的服务器区域，选择一个可用区域中的服务器来处理请求。
可用性过滤（Availability Filtering）：这种策略会过滤掉那些被认为不可用的服务器，只将请求路由到健康的服务器。
响应时间加权（Response Time Weighted）：根据服务器的响应时间来分配权重，响应时间越短的服务器权重越高，从而获得更多的请求。

这些负载均衡策略可以通过在客户端应用程序的配置文件中设置 ribbon.NAMESPACE.loadbalancer.rule.class属性来选择，其中 NAMESPACE 是特定服务的名称空间，rule.class 是负载均衡规则的完全限定类名。

例如，如果你想要为名为 myService 的服务使用加权轮询策略，你可以在客户端的配置文件中添加以下设置：

myService:
  ribbon:
    NIWSServerListClassName: com.netflix.loadbalancer.ConfigurationBasedServerList
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.WeightedResponseTimeRule

其中，默认的负载均衡算法是 Round Robin 算法，顺序向下轮询。

聊聊 Ribbon 缓存机制？

Ribbon 是一个客户端负载均衡器，它可以在客户端应用程序内部工作，提供对服务列表的自动更新和负载均衡策略的支持。Ribbon 客户端在使用服务时，会从服务注册中心获取服务列表，并将这些服务列表缓存起来。这样，当客户端需要调用服务时，可以直接从缓存中获取服务列表，而不需要每次都从服务注册中心获取，从而提高了服务调用的性能。

服务列表缓存：当 Ribbon 客户端启动时，它会从服务注册中心获取服务列表，并将这些服务列表缓存起来。这些服务列表包括服务实例的地址、端口等信息。
缓存更新：Ribbon 客户端会定期从服务注册中心检查服务列表的变化，如果发现服务列表发生了变化，它会更新缓存中的服务列表。同时，当服务实例发生变化时，服务注册中心会通知 Ribbon 客户端，Ribbon 客户端也会更新缓存中的服务列表。
缓存淘汰：Ribbon 客户端会根据一定的策略来淘汰缓存中的服务列表。例如，可以设置一个缓存时间，超过这个时间的服务列表会被淘汰。
缓存一致性：为了保证缓存中的服务列表与服务注册中心中的服务列表的一致性，Ribbon 客户端在从服务注册中心获取服务列表时，会与缓存中的服务列表进行比较，如果发现不一致，它会更新缓存中的服务列表。

聊聊 Ribbon 重试机制？

重试次数：Ribbon 客户端可以配置重试次数，即在调用服务失败时，可以重新调用服务多少次。重试次数可以通过 Ribbon 客户端的配置文件进行设置。
重试间隔：在每次重试之间，Ribbon 客户端会等待一段时间，这个时间间隔称为重试间隔。重试间隔可以通过 Ribbon 客户端的配置文件进行设置。
重试策略：Ribbon 客户端提供了多种重试策略，例如固定间隔重试、指数退避重试等。固定间隔重试是指每次重试之间的间隔是固定的，而指数退避重试是指每次重试之间的间隔逐渐增加，从而降低重试的频率。
重试条件：Ribbon 客户端会根据一定的条件来决定是否进行重试。例如，可以设置只有当服务调用超时或返回错误码时，才进行重试。

通过这种重试机制，Ribbon 客户端可以在调用服务失败时，自动进行重试，从而提高了服务调用的可靠性。同时，通过设置重试次数和间隔，可以控制重试的频率，避免对服务造成过大的压力。

Ribbon 是怎么和 Eureka 整合的？

首先，Ribbon 会从 Eureka Client 里获取到对应的服务列表。
然后，Ribbon 使用负载均衡算法获得使用的服务。
最后，Ribbon 调用对应的服务。

声明式调用

在 Spring Cloud 中，目前使用的声明式调用组件，只有：

spring-cloud-openfeign ，基于 Feign 实现。

Feign

Feign 是受到 Retrofit、JAXRS-2.0 和 WebSocket 启发的 Java 客户端联编程序。Feign 的主要目标是将Java Http 客户端变得简单。

Feign 实现原理？

Feign的一个关键机制就是使用了动态代理。咱们一起来看看下面的图，结合图来分析：

首先，如果你对某个接口定义了 @FeignClient 注解，Feign 就会针对这个接口创建一个动态代理。
接着你要是调用那个接口，本质就是会调用 Feign 创建的动态代理，这是核心中的核心。
Feig n的动态代理会根据你在接口上的 @RequestMapping 等注解，来动态构造出你要请求的服务的地址。
最后针对这个地址，发起请求、解析响应。

Feign 和 Ribbon 的区别？

Ribbon 和 Feign 都是使用于调用用其余服务的，不过方式不同。

启动类用的注解不同。Ribbon 使用的是 @RibbonClient 。Feign 使用的是 @EnableFeignClients 。
服务的指定位置不同。Ribbon 是在 @RibbonClient 注解上设置。Feign 则是在定义声明方法的接口中用 @FeignClient 注解上设置。
调使用方式不同。Ribbon 需要自己构建 Http 请求，模拟 Http 请求而后用 RestTemplate 发送给其余服务，步骤相当繁琐。Feign 采使用接口的方式，将需要调使用的其余服务的方法定义成声明方法就可，不需要自己构建 Http 请求。不过要注意的是声明方法的注解、方法签名要和提供服务的方法完全一致。

聊聊 Feign 重试机制？

Feign 重试机制可以通过在 Feign 客户端的配置文件中设置 retryer 属性来启用。retryer 属性是一个实现 Retryer 接口的类，该接口定义了重试的策略和方法。默认情况下，Feign 使用 SimpleRetryer 作为重试器，它实现了 Retryer 接口。

SimpleRetryer 提供了以下重试策略：

重试次数：SimpleRetryer 允许你配置重试次数，即在调用服务失败时，可以重新调用服务多少次。重试次数可以通过 Feign 客户端的配置文件进行设置。
重试间隔：在每次重试之间，SimpleRetryer 会等待一段时间，这个时间间隔称为重试间隔。重试间隔可以通过 Feign 客户端的配置文件进行设置。
重试条件：SimpleRetryer 会根据一定的条件来决定是否进行重试。例如，可以设置只有当服务调用超时或返回错误码时，才进行重试。

通过这种重试机制，Feign 客户端可以在调用服务失败时，自动进行重试，从而提高了服务调用的可靠性。同时，通过设置重试次数和间隔，可以控制重试的频率，避免对服务造成过大的压力。

Hystrix

作用：断路器，保护系统，控制故障范围。
简介：Hystrix 是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，停止级联故障并在复杂的分布式系统中实现弹性。

Hystrix 原理，整体如下图：

Hystrix 隔离策略？

Hystrix 有两种隔离策略：

线程池隔离
信号量隔离

实际场景下，使用线程池隔离居多，因为支持超时功能。

聊聊 Hystrix 缓存机制？

Hystrix 提供缓存功能，作用是：

减少重复的请求数。
在同一个用户请求的上下文中，相同依赖服务的返回数据始终保持一致。

Hystrix 缓存机制的几个关键点：

命令缓存：HystrixCommand 支持在执行命令时使用缓存。这可以通过设置 cacheKeyResolver 方法来实现，该方法定义了如何生成缓存的键。一旦命令执行的结果被缓存，后续对相同键的请求将直接从缓存中获取结果，而不需要再次执行命令。
观察者缓存：HystrixObservableCommand 支持在执行命令时使用缓存。这可以通过设置 cacheKeyResolver 方法来实现，该方法定义了如何生成缓存的键。一旦命令执行的结果被缓存，后续对相同键的请求将直接从缓存中获取结果，而不需要再次执行命令。
缓存更新：当命令或观察者的结果发生变化时，缓存中的数据也会被更新。这可以通过设置 cacheResult 方法来实现，该方法定义了是否将结果缓存到本地缓存中。
缓存淘汰：Hystrix 提供了缓存淘汰策略，例如基于时间或基于命中率。这可以通过设置 cacheResult方法来实现，该方法定义了缓存淘汰的策略。

通过这种缓存机制，Hystrix 可以在执行命令或观察者时减少不必要的网络请求和计算开销，从而提高系统的性能和响应速度。同时，通过设置缓存淘汰策略，可以控制缓存的大小和更新频率，避免缓存过载和数据不一致的问题。

需要注意的是，Hystrix 缓存机制主要用于提高系统的性能和响应速度，但它并不能完全替代持久化存储。在实际应用中，需要根据具体的服务场景和需求来决定是否启用缓存机制，以及设置合适的缓存策略和淘汰策略。

什么是 Hystrix 断路器？

Hystrix 断路器通过 HystrixCircuitBreaker 实现。

HystrixCircuitBreaker 有三种状态：

CLOSED ：关闭
OPEN ：打开
HALF_OPEN ：半开

其中，断路器处于 OPEN 状态时，链路处于非健康状态，命令执行时，直接调用回退逻辑，跳过正常逻辑。

HystrixCircuitBreaker 状态变迁如下图：

红线：初始时，断路器处于 CLOSED 状态，链路处于健康状态。当满足如下条件，断路器从 CLOSED 变成 OPEN 状态：

周期( 可配，HystrixCommandProperties.default_metricsRollingStatisticalWindow = 10000 ms )内，总请求数超过一定量( 可配，HystrixCommandProperties.circuitBreakerRequestVolumeThreshold = 20 ) 。
错误请求占总请求数超过一定比例( 可配，HystrixCommandProperties.circuitBreakerErrorThresholdPercentage = 50% ) 。

绿线：断路器处于 OPEN 状态，命令执行时，若当前时间超过断路器开启时间一定时间( HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds = 5000 ms )，断路器变成 HALF_OPEN 状态，尝试调用正常逻辑，根据执行是否成功，打开或关闭熔断器【蓝线】。

什么是 Hystrix 服务降级？

在 Hystrix 断路器熔断时，可以调用一个降级方法，返回相应的结果。

熔断（Circuit Breaking）：

概念：熔断是断路器模式的核心机制，用于保护系统免受因某个依赖服务不可用或响应缓慢而导致的连锁故障。当某个服务在一定时间内出现过多异常时，Hystrix 会自动打开断路器，不再向该服务发送请求，直到断路器重新闭合。
作用：熔断可以防止系统因为一个依赖服务的故障而完全瘫痪，从而提高系统的可用性和稳定性。
触发条件：Hystrix 断路器的打开和关闭是由故障率（Error Rate Threshold）决定的。如果一个服务在一定时间内（例如，10秒内）有超过指定比例的请求失败，Hystrix 会打开断路器。如果故障率降低到指定比例以下，Hystrix 会逐渐关闭断路器，并开始允许少量请求通过，以检查服务是否恢复正常。如果服务恢复正常，Hystrix 会完全关闭断路器，恢复正常请求。

降级（Fallback）：

概念：降级是当服务不可用或响应缓慢时，为了保持系统的基本功能，Hystrix 提供的另一种保护机制。它允许开发者定义一个后备逻辑，当主逻辑失败时，后备逻辑会被执行。
作用：降级可以确保系统在主逻辑失败时仍然能够提供基本的功能，从而提高系统的可用性和用户体验。
触发条件：降级可以由多种条件触发，例如，服务不可达、响应超时、服务调用失败等。当这些条件发生时，Hystrix 会自动执行降级逻辑。
实现方式：在 Hystrix 中，降级可以通过实现 HystrixCommand 或 HystrixObservableCommand 的 run 方法来定义主逻辑，并通过实现 HystrixCommand 或 HystrixObservableCommand 的 getFallback 方法来定义降级逻辑。

通过 Hystrix 的熔断和降级机制，可以在服务不可用或响应缓慢时保护系统免受连锁故障的影响，从而提高系统的整体弹性和稳定性。同时，开发者可以根据具体的服务场景和需求来定制熔断和降级的触发条件、后备逻辑等，以实现更加灵活和细粒度的控制。

网关服务

在 Spring Cloud 中，能够使用的网关服务，主要是两个，如下：

spring-cloud-netflix-zuul ，基于 Zuul1 实现。

spring-cloud-gateway ，基于 Spring Webflux 实现。

为什么要网关服务？

使用网关服务，我们实现统一的功能：

动态路由
灰度发布
健康检查
限流
熔断
认证: 如数支持 HMAC, JWT, Basic, OAuth 2.0 等常用协议
鉴权: 权限控制，IP 黑白名单，同样是 OpenResty 的特性
可用性
高性能

Zuul

作用：API 网关，路由，负载均衡等多种作用。
简介：类似 Nginx ，反向代理的功能，不过 Netflix 自己增加了一些配合其他组件的特性。
在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个 API网关根据请求的 url ，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。

Zuul 原理，整体如下图：

Spring Cloud Gateway

Spring Cloud Gateway 的主要特点包括：

基于 WebFlux：Spring Cloud Gateway 是基于 Spring WebFlux 构建的，这是一个响应式编程框架，支持非阻塞的 I/O 和更高效的内存使用。
路径匹配：Spring Cloud Gateway 使用 Path Pattern 进行路由匹配，这比传统网关（如 Zuul）使用的 Servlet 过滤器更加灵活和强大。
断路器集成：Spring Cloud Gateway 集成了 Hystrix 或 Resilience4j，允许你在网关层实现断路器模式，从而提高系统的弹性。
过滤器链：Spring Cloud Gateway 提供了过滤器链（Filters）的概念，允许你在请求到达下游服务之前对其进行预处理和后处理。过滤器链包括预定义的过滤器，如安全过滤器、响应缓存过滤器等。
服务发现与动态路由：Spring Cloud Gateway 支持从服务注册中心（如 Eureka）动态获取服务列表，并根据服务列表动态地创建路由规则。
全局过滤器：你可以定义全局过滤器，这些过滤器将在所有请求到达网关时执行，从而提供统一的安全、日志记录、监控等功能。
集成 Spring Cloud Config：Spring Cloud Gateway 可以与 Spring Cloud Config 集成，允许你在网关层动态地刷新配置。
支持各种协议：Spring Cloud Gateway 支持多种协议，包括 HTTP、WebSocket、STOMP、SockJS 等。
与 Spring Cloud 组件集成：Spring Cloud Gateway 可以与 Spring Cloud 的其他组件如 Ribbon、Feign、Eureka 等无缝集成。

通过 Spring Cloud Gateway，你可以构建一个高性能、可扩展、响应式的微服务网关，它能够处理大量的并发请求，同时提供灵活的路由和过滤机制。Spring Cloud Gateway 特别适合于需要处理高并发和异步响应式系统的情况。

配置中心

在 Spring Cloud 中，能够使用的配置中心，如下：

spring-cloud-config ，基于 Git、SVN 作为存储。
spring-cloud-alibaba-nacos-config ，基于 Nacos 实现。
Apollo ，携程开源的配置中心。

Spring Cloud Config

作用：配置管理
简介：Spring Cloud Config 提供服务器端和客户端。服务器存储后端的默认实现使用 Git ，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。
这个还是静态的，得配合 Spring Cloud Bus 实现动态的配置更新。

Apollo

Apollo 的一些关键特点包括：

集中式管理：Apollo 提供了一个中心化的配置管理平台，可以集中管理和维护应用程序的配置。
多环境支持：Apollo 支持多种环境，如开发、测试、预发布、生产等，允许你为不同的环境设置不同的配置。
版本控制：Apollo 提供了版本控制功能，允许你跟踪配置的变更历史，并在需要时回滚到旧版本。
发布与回滚：Apollo 允许你轻松地发布新版本的配置，并在需要时回滚到旧版本，这有助于减少配置变更带来的风险。
权限控制：Apollo 提供了细粒度的权限控制，允许你为不同的用户或角色设置不同的权限，确保配置的安全性。
实时更新：Apollo 支持实时配置更新，当配置发生变化时，客户端可以立即获取到最新的配置信息。
客户端 SDK：Apollo 提供了一系列客户端 SDK，支持多种编程语言，如 Java、.NET、Node.js 等。
服务端集成：Apollo 可以与其他服务端系统集成，如 CI/CD 工具、日志系统等，以实现更全面的配置管理。

Apollo 的客户端 SDK 通常会在应用程序启动时加载配置信息，并在运行时动态地获取和应用配置变更。这使得应用程序可以更加灵活地处理配置变更，而不需要重启服务。

链路追踪

在 Spring Cloud 中，能够使用的链路追踪，主要是两个，如下：

skywalking ，已经进入 Apache ，不仅仅能够透明的监控链路，还可以监控 JVM 等等。
spring-cloud-sleuth ，基于 Zipkin 实现。

Spring Cloud Sleuth

Spring Cloud Sleuth 原理，整体如下图：

路从脚起

关注

28
点赞
踩
23

收藏

觉得还不错? 一键收藏
打赏
0
评论
Spring Cloud 面试题

微服务是一种软件开发技术，它将应用程序构建为一组小的、独立的、松散耦合的服务，每个服务运行在自己的进程中，并且通过轻量级的通信机制（通常是 HTTP RESTful API）进行协作。这些服务围绕业务功能组织，每个服务都有自己的数据存储和业务逻辑，可以独立部署、扩展和更新。模块化：微服务架构将应用程序分解为小的、自治的模块，每个模块负责应用程序的一部分功能。独立性：每个微服务可以独立部署和扩展，不会影响到其他服务的运行。灵活性。
复制链接

扫一扫