SpringCloud

一、什么是Spring Cloud？，有哪些组件？

Spring Cloud是基于Spring Boot的分布式系统开发工具，它提供了一系统开箱即用的、针对分布式系统开发的特性和组件，用于帮助开发人员快速构建和管理云原生应用程序。

Spring Cloud的主要目标是解决分布式系统中的常见问题，例如服务发现、负载均衡、配置管理、断路器、消息总线等。

下图是一张Spring Cloud中核心组件起到的作用以及所处的位置：

下面是Spring Cloud常用的一些组件：

1. Eureka：服务发现和注册中心，可以帮助服务消费者自动发现和调用服提供者。

2. Ribbon：负载均衡组件，可以帮助客户端在多个服务提供者之间进行负载均衡。

3. OpenFeign：声明式HTTP客户端，可以帮助开发人员更容易地编写HTTP调用代码。

4. Hystrix：断路器组件，可以帮助应用程序处理服务故障和延迟问题。

5. Zuul：API网关，可以帮助应用程序处理API请求的路由、负载均衡、安全和监控问题。

6. Config：分布式配置管理组件，可以帮助应用程序从远程配资源获取配置信息。

7. Bus：消息总线组件，可以帮助应用程序实现分布式事件传递和消息广播。

8. Sleuth：Sleuth是Spring Cloud生态系统中的一个分布式追踪解决方案，可以帮助开发人员实现对分布式系统中请求链路的追踪和监控。

9. Gateway：Spring Cloud Gateway是Spring Cloud推出的第二代网关框架，取代Zuul网关。提供了路由转发、权限校验、限流控制等作用。

10. Security：用于简化OAuth2认证和资源保护。

以下是一个目前比较主流的Spring Cloud的架构：

 

Spring Cloud Alibaba

Spring Cloud Alibaba则是Alibaba推出的分布式开发框架，它主要针对于微服务和云原生应用的开发和部署。Spring Cloud Alibaba提供了一系列的组件和解决方案，例如服务注册、配置管理、消息驱动等。Spring Cloud Alibaba的组件通常基于阿里巴巴自研的组件，例如Nacos、Sentinel、RocketMQ等。

目前Spring Cloud Alibaba提供了如下功能：

1. 服务限流降级：支持WebServlet、WebFlux、OpenFeign、RestTemplate、Dubbo限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级Metrics监控。

2. 服务注册与发现：适配Spring Cloud服务注册与发现标准，默认集成了Ribbon的支持。

3. 分布式配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新。

4. Rpc服务：扩展Spring Cloud客户端RestTemplate和OpenFeign，支持调用Dubbo的RPC服务。

5. 消息驱动能力：基于Spring Cloud Stream为微服务应用构建消息驱动能力。

6. 分布式事务：使用 @GlobalTransactional 注解，高效并且对业务零侵入地解决分布式事务问题。

7. 阿里云对象存储：阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。

8. 分布式任务调度：提供秒级、精准、高可靠、高可用的定时（基于Cron表达式）任务调度服务。同事提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有Worker（schedulerx-client）上执行。

9. 阿里云短信服务：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。

 

二、Spring Cloud和Dubbo有什么区别？

Spring Cloud和Dubbo都是为了简化分布式系统开发而设计的开源框架，Dubbo和Spring Cloud都侧重在对分布式系统中常见问题模式的抽象（如服务发现、负载均衡、动态配置等）

它们之间有以下几个区别：

① 底层技术不同：Spring Cloud是基于Spring Boot和Spring Framework构建的，编程模型与通信协议绑定HTTP，而Dubbo则是基于Java的RPC框架实现的（Dubbo也支持HTTP协议，但是主要还说以Dubbo协议为主）。

② 主意的用途不同：Spring Cloud是一个完整的微服务框架，它提供了服务注册与发现、负载均衡、熔断器、配置管理等功能。而Dubbo是一个RPC框架，它主要解决分布式服务之间的调用问题，如服务注册与发现、负载均衡、协议转换、服务治理等。

在Spring Cloud中，服务注册与发现主要通过Eureka、负载均衡主要通过Ribbon、限流降级这些操作主要通过Hystrix、网关服务主要依赖于Zuul。

③ 社区生态不同：Spring Cloud是由Spring社区维护的，拥有庞大的社区和丰富的生态系统，能够支持多种云平台。而Dubbo则是由阿里巴巴开发和维护的（后来捐给了Apache），虽然拥有较为活跃的社区和强大的阿里巴巴技术支持，但生态系统相对较小。

④ 语言支持不同：Spring Cloud是基于Java语言实现的，同时也支持其他语言的开发，如Kotlin、Groovy、Scala等。而Dubbo则是一个纯Java实现的Rpc框架，只支持Java语言开发（Dubbo-go框架支持go语言）。

如何选择？

如果项目主要使用Spring Boot和Spring Framework技术栈，可以选择Spring Cloud，如果项目使用Java语言且不依赖于Spring技术栈，可以选择Dubbo。

如果你需要将应用部署到云平台上，Spring Cloud提供了更多的云原生支持，包括Kubernetes和Istio的支持。

如果项目需要强大的服务治理功能，例如多协议支持、多注册中心注册等，那么选择Dubbo可能更合适。Dubbo提供了强大的服务治理能力，可以满足各种不同的需求。

 

三、什么是Zuul网关，有什么用？

Zuul是一个开源的网关服务，主要用于将客户端请求路由到相应的微服务实例。它是Netflix公司开发的，现在成为了Spring Cloud生态系统的一部分。

网关就相当于一个前置的入口，所有的请求都要经过它，然后通过它进行服务转发和路由。

网关能带来几个好处，首先比较容易想到的就是它承担了统一的入口和出口的角色，所有的请求都需要经过它，那么它就很方便的管理这些服务。

其次，因为所有请求都要经过它，所以它可以做负载均衡以及动态路由。根据不同的负载均衡算法，或者根据请求的参数内容，进行决策选择一个合适的后端服务进行调用。

它还有把很多的公共服务集成进来，比如做统一的鉴权、统一的异常处理等。还可以做各种粒度的限流、降级和熔断的操作。

 

四、Ribbon和Nginx的区别是什么？

在对比Ribbon和Nginx的时候，主要对比的是它们在负载均衡方面的区别。

这两者最主要的区别是Nginx是一种服务端负载均衡的解决方案，而Ribbon是一种客户端负载均衡的解决方案。

服务端负载均衡指的是将负载均衡的逻辑集成到服务提供端，通过在服务端对请求进行转发，实现负载均衡。

客户端负载均衡指的是将负载均衡的逻辑集成待服务消费端的代码中，在客户端直接选择需要调用的服务提供端，并发起请求。这样的好处是可以在客户端直接实现负载均衡、容错等功能，不需要依赖于其他组件，使得客户端具有更高的灵活性和可控性。

Nginx是需要单独部署一个Nginx服务的，这样它才能做好服务端负载均衡，而Ribbon是需要在服务消费端的机器代码中引入，和应用部署在一起，这样它才能实现客户端的负载均衡。

 

五、Zuul、Gateway和Nginx有什么区别？

Zuul、Gateway、Nginx都是常用的网关技术，但它们在实现和功能方面有一些区别。

Zuul是Netflix开源的一个服务网关，主要用于构建微服务架构中的边缘服务。它提供了动态路由、负载均衡、请求过滤、身份验证、安全性等功能。Zuul通常于Netflix的Eureka服务发现框架结合使用，并通过配置路由规则将请求路由到适当的后端服务。

Gateway是Spring Cloud的一部分，用于构建基于Spring Boot的微服务网关。它提供了类似于Zuul的功能，如路由、负载均衡、请求过滤、安全性等。Gateway使用Spring WebFlux框架和Reactor库实现了异步非阻塞的处理模型。它可以与Spring Cloud的服务注册与发现（如Eureka或Consul）进行集成。

Nginx是一个高性能的开源的Web服务器和反向代理服务器。虽然Nginx本身并不是专门设计用作网关，但它经常被用作反向代理和负载均衡器，以提高网关功能。Nginx能够处理并转发HTTP、HTTPS、SMTP、POP3和IMAP等协议的请求，具有强大的性能和高并发处理能力。Nginx还支持基于配置的路由和请求过滤功能，它可以根据请求的URL路径或者其他条件将流量路由到后端服务器。

Zuul和Gateway是专门用于构建微服务架构的服务网关，提供了丰富的功能和易于配置的路由规则。而Nginx是一个通用的Web服务器和反向代理服务器，可以用作网关，但不像Zuul和Gateway那样专注于服务器架构。

在微服务架构中，选择一个微服务网关的时候，建议优先考虑Spring Cloud Gateway，主要是因为Gateway的推出就是要替代Zuul的，首先Gateway是Spring官方自己出的，而Zuul是Netflix出的，而且Gateway之所以推出，也是因为Zuul的更新和维护并不理想。而且Gateway使用Spring WebFlux框架和Reactor库，采用异步非阻塞的处理模型，所以性能会更好一些。

 

六、Ribbon是怎么做负载均衡的？

Ribbon是一种客户端负载均衡的解决方案，它通常与Spring Cloud一起使用，以在微服务中实现负载均衡。

客户端负载均衡的实现原理是通过注册中心，如Nacos，将可用的服务列表拉取到本地（客户端），再通过客户端负载均衡器（设置的负载均衡策略）获取到某个服务器的具体ip和端口，然后再通过Http框架请求服务并得到结果。

Ribbon通过在客户端中添加拦截器来实现负载均衡。当客户端发出请求时，拦截器会根据一组预定义的规则选择一个服务实例来处理请求。这些规则可用基于多个因素进行选择，包括服务实例的可用性、响应时间、负载等级等。

Ribbon的核心是负载均衡算法，它决定了如何选择服务实例。Ribbon提供了多种负载均衡算法，包括轮询、随机、加权随机、加权轮询、最少连接数等，它们的具体实现是实现了IRule接口，继承自AbstractLoadBalanceRule实现的：

Ribbon的工作流程：

1. 服务提供者先将自己注册到Nacos、Eureka等注册中心。

2. 客户端向Ribbon发送请求。Ribbon将请求的目标服务名称和API路径解析出来。

3. Ribbon根据服务名称去注册中心（如Eureka、Nacos、Consul等）获取可用的服务实例列表。

4. Ribbon通过负载均衡算法（如轮询、随机、加权随机、最少活跃数等）从实例列表中选择一台服务器，将请求转发给目标服务器。

5. 目标服务器处理请求并返回响应给客户端。

6. 客户端接收到响应后进行处理。

 

七、Hystrix和Sentinel的区别是什么？

Hystrix和Sentinel都是Spring Cloud中可以用来做限流、降级的组件。

Hystrix的关注点在于隔离和熔断为主的容错机制，超时或被熔断的调用将会快速失败，并可以提供fallback机制。而Sentinel的侧重点在于多样化的流量控制、熔断降级、系统负载保护以及实时监控和控制台。

二者的主要差别如下：

 

八、在Spring Cloud中，服务间的通信方式有哪些？

Spring Cloud通常被用来构建分布式架构，而分布式中，就需要解决多个微服务之间的通信问题。多个应用分别部署在不同的机器上，那么想要让它们之间相互通信，有以下几种常见的方法：

RESTful调用

最常见的方式就是使用RESTful API 进行服务间的通信。Spring Cloud利用Spring MVC提供了强大的REST客户端和服务端支持。

比如一个服务通过Spring MVC暴露出一个HTTP接口出来，然后另一个服务通过RestTemplate或WebClient来进行调用。

使用Feign客户端（常用）

Feign是一个声明式的web服务客户端，使得编写web服务客户端更加容易。

通过创建一个接口并用注解来配置请求的细节，Feign可以自动处理请求的发送和结果的映射。Spring Cloud对Feign进行了集成，使其成为在微服务架构中实现服务间调用的一个流行选择。

Spring Cloud Gateway（常用 + 推荐）

Spring Cloud Gateway是基于请求路由的API网关。它允许你根据请求的不同特征（如路径、头部、请求参数等）将请求路由到不同的后端服务上。

如以上配置，当我们访问这个gateway网关应用时，如果路径是/user/**，那么它就会把请求路由给user-service应用来处理。

通常也会在网关中配合Spring Cloud LoadBalancer来实现客户端的负载均衡的功能。

RPC调用（常用 + 推荐）

在Spring Cloud中，也可以集成很多RPC框架进行服务间的调用，这也是非常常见的，比如gRPC、Dubbo等。

Spring Cloud Stream（常用 + 推荐）

服务间通信，除了相互调用以外，还可以基于消息的通信，Spring Cloud Stream提供了一个统一的方式来发送和接收消息。它抽象了底层消息中间件（如RabbitMQ、Kafka等），允许开发者使用统一的API来处理消息。

 

九、为什么需要Spring Cloud Gateway，它起到了什么作用？

在如今的Spring Cloud生态中，Spring Cloud Gateway是一个至关重要的组件。Spring Cloud Gateway是在一个Spring生态系统中建立的API网关，它为微服务架构中的服务提供了一个简单有效的方式来请求路由请求、转发和过滤等功能。

网关的作用就是提供统一接入，意味着所有的流量都需要先经过网关，然后再由网关转发出去。所以，一般来说我们用Gateway构建的网关应用中不太有业务逻辑，主要的功能就是做流量的转发。

有了网关之后，就可以基于网关做很多事情，如：

① 路由转发：Spring Cloud Gateway允许我们定义路由规则，把用户路由到对应的服务中，比如用户要访问订单服务，则把它的请求直接路由给订单服务的集群，用户要访问商品访问，则把它的请求直接路由到商品服务的集群。

② 负载均衡：因为网关可以做路由转发，所以借助它也能实现非常方便的负载均衡。一般都是要集成LoadBalancer实现。

比如一个请求要访问商品模块，而商品模块是集群提供的，具体要路由给哪台机器呢？这个就可以给予网关来实现负载均衡了。

③ 统一授权：在Gateway中，我们可以继承OAuth2、JWT等安全协议的集成，来进行统一的登录、授权。

我们可以通过配置实现，如果用户访问任意一个页面，我们都先校验用户是否登录，如果没登录，路由到登录页面进行登录。如果登录了，则把请求路由给对应的服务进行处理。

④ 流量过滤：就像统一授权一样，我们也可以基于Spring Cloud Gateway实现统一的过滤，比如一些黑名单的过滤，一些恶意请求的过滤等。

⑤ 限流降级：我们还可以在Gateway中集成Sentinel等组件，来实现统一的限流。这样我们就可以在网关层面实现一个统一的流量管控，避免下游服务因为流量扛不住而被打挂。

⑥ 跨域支持：在微服务架构中，服务通常分布在不同的域中。Spring Cloud Gateway提供跨域请求支持，使得不同域的服务可以安全、有效地相互通信。

总之，Gateway就是一个流量的统一入口，所以它可以做很多通用的事情，比如路由转发、负载均衡、统一授权等，还可以做流量的过滤、限流降级等保护服务的机制。

 

十、Dubbo和Feign有什么区别？

Dubbo和Feign都是常用于构建分布式系统的技术，主要解决的问题就是多个微服务之间的相互调用。它们之间有一些区别，主要体现在它们所服务的结果、通信协议、性能特点以及集成与使用方式上。

Dubbo

Dubbo是一个高性能、基于Java的开源RPC（远程过程调用）框架。它主要用于构建高性能和透明化的服务间远程调用的微服务架构。Dubbo支持多种通信协议和负载均衡策略，允许服务之间以高效率进行数据交换。

Dubbo的主要特点：

① 高性能的RPC调用：提供基于接口的远程方法调用。

② 多种通信协议支持：支持多种协议Dubbo、HTTP、RMI等。

③ 服务治理：内建的服务治理功能，包括服务发现、负载均衡、故障转移和动态配置等。

④ 依赖Zookeeper、Nacos等注册中心：用于服务注册与发现。

Feign

Feign是一个声明式的Web服务客户端，它使得编写Web服务客户端变得更容易。使用Feign可以通过简单的接口和注解来调用HTTP API。Feign的目标是尽可以简化HTTP API客户端的实现过程。

Feign主要特点：

① 声明式的HTTP客户端：通过Java接口和注解来定义方法与远程服务的绑定关系。

② 集成Ribbon和Hystrix：支持负载均衡（通过集成Ribbon）和服务熔断（通过集成Hystrix）。

③ 主要用于SpringCloud：通常与Spring Cloud组件一起使用，实现服务间的调用。

主要区别：

总结：Dubbo和Feign虽然都用于服务间的调用，但Dubbo更注重于RPC的高性能实现和服务治理，而Feign更侧重于简化HTTP服务的消费和集成Spring Cloud生态。选择哪个工具取决于你的具体需求、架构风格和技术栈。

 

十一、什么是Eureka的自我保护模式？

Eureka的自我保护模式正是一种针对网络异常波动的安全保护措施，使用自我保护模式能使Eureka集群更加的健壮、稳定的运行。

正常情况下，Eureka客户端会定期向Eureka服务器发送心跳，以表明它仍然存活和可用。如果Eureka服务器在配置的时间间隔内未能从某个服务实例接收到心跳。它通常会将该实例从注册列表中移除，认为该实例不可用。

然而，在自我保护模式下， 如果Eureka服务器在短时间内丢失了大量服务实例的心跳（15分钟内超过85%的客户端），它会认为这是一个网络问题，而不是所有者服务实例都突然不可用。因此，服务器将进入自我保护模式。

当进入自我保护模式时，会存在以下行为：

① 停止移除服务实例：Eureka服务器在自我保护模式下不会因为缺少心跳而移除任何服务实例。即使服务实例停止发送心跳，它们仍然会被保留在注册表中。

② 保持服务注册表状态：这可以确保在网络故障恢复后，服务消费者仍然能够发现所有原先注册的服务实例，无需等待这些实例重新注册和检测。

③ 记录状态和警告：Eureka服务器会在其状态页面上显示它是否处于自我保护模式，并显示相关的警告信息。

Eureka的自我保护模式是可配置的。可用通过配置参数来调整何时触发自我保护模式，或者完全关闭该功能。例如，可以通过修改eureka.server.enable-self-preservation的配置值来开启或关闭自我保护模式。

自我保护模式默认是开启的，因为它可以在网络不稳定的环境中提供更稳定的服务发现功能。不建议在生产环境中关闭自我保护机制。

 

十二、Feign第一次调用为什么很慢？可能的原因是什么？

在Spring Cloud中，Feign是一个声明式的Web服务客户端，它使得编写HTTP客户端变得更加容易。经常会有人遇到用于启动之后，第一次的访问通常很慢，甚至有超时的情况，那么可能有哪些原因呢？

① 缓存初始化：很多系统在首次运行时需要建立缓存。初次访问数据可能需要从硬盘、数据库或者远程服务中检索，并在内存中建立缓存，这个过程可能会比较慢。

② JIT编译：对于使用即时编译（JIT）的语言或环境（如Java .NET）来说，首次执行代码时可能需要进行编译优化，这将导致初始延迟，但随后的执行速度会加快。

③ 动态代理的创建：Feign使用动态代理来创建接口的实现。首次调用一个Feign客户端时，Spring Cloud需要构建和配置这个代理，这包括解析接口上的注解并常见相应的HTTP请求模板。这个过程可能比较耗时，特别是在接口定义较为复杂或注解使用较多的情况下。

④ 服务发现：如果Feign客户端配置为Eureka或其他服务发现机制，首次调用可能涉及到查找服务的位置。这可能需要从服务注册中心获取服务实例的信息，尤其是在服务刚启动，或服务列表更新时。

⑤ Hystrix和线程池初始化：如果Feign客户端配合Hystrix使用，首次调用还可能涉及到Hystrix命令的初始化，包括线程池的创建和配置。这些都可能在首次调用时增加额外的延迟。
⑥ 网络延迟和首次连接：首次调用远程服务可能涉及建立网络连接，如TCP握手，在这首次连接时特别明显。

⑦ 冷启动：当服务或应用第一次启动时，可能需要加载到内存中，这被称为冷启动。比如，在微服务架构中，某个服务的首次调用可能需要时间来启动和初始化，尤其是在使用容器化或Serverless架构时更为常见。

要减少这种首次调用的延迟，可以考虑以下几个策略：

① 预热客户端：在应用启动后，可以编写一些预热逻辑来提前调用Feign客户端，以完成初始化过程，确保当真正需要时它已经准备好。

② 优化配置：检查和优化Feign客户端的配置，如连接超时和读取超时设置，以及其他可能影响性能的配置。

③ 服务发现缓存：如果使用服务发现，确保服务实例信息被适当缓存，减少对服务注册中心的依赖。

④ JVM性能调优：调整JVM设置，比如JIT编译策略或内存配置，以优化首次加载性能。

 

十三、Hystrix熔断器的工作原理是什么？

Hystrix熔断器是用来防止级联失败的，并允许系统快速失败和快速恢复。它的原理是通过模拟电路中的断路器（熔断器）来实现的，当某个部分发生故障时，断路器会切断电流，防止故障扩散。

在Hystrix，这种机制用于管理对依赖服务的调用，特别是在这些服务表现不稳定或响应延迟时。

Hystrix断路器有三种状态：

① 关闭：熔断器在默认情况下是呈现关闭的状态，而熔断器本身带有计数功能，每当错误发生一次，计数器也就会进行 “累加” 的动作，到了一定的错误发生数断路器就会被 “开启” ，这个时候亦会在内部启用一个计时器，一旦时间到了就会切换成半开启状态。

② 开启：在开启的状态下任何请求都会“直接” 被居家并且抛出异常信息。

③ 半开启：在此状态下断路器会允许部分的请求，如果这些请求都能成功通过，那么就意味着错误已经不存在，则会被切换关闭状态会重置计数。倘若请求中有“任一”错误发生，则会恢复到“开启”状态，并且重新计时，基于系统一段休息时间。

Hystrix通过一系列指标来确定是否需要开启断路器，主要指标包括：

① 请求的数量：在一定时间窗口内，只有请求数量超过了一定阈值，断路器的状态才会评估是否需要开启。这防止了在请求量很低时因一两个请求失败就触发断路器。

② 错误百分比：计算在过去一段时间内，失败请求占总请求的百分比。如果这一比例超过设定的阈值，断路器将开启。

在代码中，开发者可以使用Hystrix命令来包装对下游服务的调用。这些命令封装了服务调用的细节，包括超时、失败、回退机制等。当断路器开启时，这些命令会自动执行配置的回退逻辑，而不是执行实际的服务调用。

如果在微服务系统的调用过程中，引入熔断器，那么整个系统将天然具备以下能力：

① 快速失败：当因为调用远程服务失败次数过多，熔断器开启时，上游服务对于下游服务的调用就会快速失败，这样可以避免上游服务被拖垮。

② 无缝恢复：因为熔断器可以定期检查下游系统是否恢复，一旦恢复就可以重新回到关闭状态，所有请求便可以注册请求到下游服务。使得系统不需要人为干预。

 

十四、介绍一下Hystrix的隔离策略，你用哪个？

Hystrix提供两种主要的隔离策略来控制服务之间的交互，防止系统中一个组件的失败影响到其他组件。分别是线程池隔离和信号量隔离。基本上大多数场景，都是使用线程池隔离的！

线程池隔离

这是Hystrix的默认隔离策略，也是推荐方式。在这种策略中，每一个依赖服务调用都在一个单独的线程中执行，这个线程从专门为每个Hystrix命令或服务依赖配置的线程池中获取。如果线程池已满，新的请求将会被立即拒绝，不会继续等待或阻塞调用者线程。

优点：

① 提供了真正的任务隔离；如果依赖服务变得缓慢或无响应，只会影响到运行在同一个线程池中的请求。

② 可以限制并发调用的数量，避免系统过载。

信号量隔离

信号量隔离使用Java的信号量来限制并发访问的数量，而不是在不同的线程中执行命令。当请求达到信号量计数的限制时，新的请求会被立即拒绝，而不会导致线程的创建或切换。

优点：

① 开销较小，没有线程切换和创建的成本。

② 适用于执行非常快但需要频繁访问的操作。

适用场景

线程池隔离

适合99%场景，尤其是外部调用的场景，尤其是那些可能会慢或失败的服务（如外部API、数据访问等）

信号量

适合轻量级操作，不太可能导致长时间延迟的服务调用，如内存或缓存服务访问。