【SpringCloud 面试题整理-超级有用】

1、什么是Spring Cloud?

Spring Cloud是一个微服务框架，相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。 
Spring Cloud对微服务基础框架Netflix的多个开源组件进行了封装，同时又实现了和云端平台以及和Spring Boot开发框架的集成。 
 Spring Cloud为微服务架构开发涉及配置管理，服务治理，熔断机制，智能路由，微代理，控制总线，一次性token，全局一致性锁，leader选举，分布式session，集群状态

2、使用Spring Cloud有什么优势？

1.代码耦合度较低，不会影响其他模块的开发
2.极大的减轻了团队开发成本，可并行开发，不用过多关注其他人怎么开发
3.配置比较简单，基本用注解就能实现，不能使用过多的配置文件
4.微服务操作，实现跨平台的，可以使用不同的语言开发
5.每个微服务可以使用自己的数据库，也可以使用公共的数据库

3、服务注册和发现是什么意思？Spring Cloud如何实现？

我理解的是主要三块大功能，分别是服务注册 、服务发现、服务状态监控
我们当时项目采用的eureka作为注册中心，这个也是spring cloud体系中的一个核心组件
服务注册：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等
服务发现：消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用
服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除

4、负载平衡的意义什么？

负载均衡的意义是指将负载的任务进行平衡、分摊到多个操作单元上进行运行，主要是用来避免单一应用由于并发等原因，导致应用宕机从而让系统整体无法使用、多负载同时工作，则使用负载均衡能够解决高并发的问题并实现服务的高可用。

5、什么是Hystrix？它如何实现容错?

Hystrix的容错主要是通过添加容许延迟和容错方法，帮助控制这些分布式服务之间的交互。 还通过隔离服务之间的访问点，阻止它们之间的级联故障以及提供回退选项来实现这一点，从而提高系统的整体弹性。Hystrix主要提供了以下几种容错方法：1. 资源隔离，2. 熔断，3. 降级。
熔断器配置
	Circuit Breaker主要包括如下6个参数：
		（1）circuitBreaker.enabled
			是否启用熔断器，默认是TRUE。

（2）circuitBreaker.forceOpen
　　　　 熔断器强制打开，始终保持打开状态，不关注熔断开关的实际状态。默认值FLASE。
（3）circuitBreaker.forceClosed
　　　　 熔断器强制关闭，始终保持关闭状态，不关注熔断开关的实际状态。默认值FLASE。
　　 （4）circuitBreaker.errorThresholdPercentage
错误率，默认值50%，例如一段时间（10s）内有100个请求，其中有54个超时或者异常，那么这段时间内的错误率是54%，大于了默认值50%，这种情况下会触发熔断器打开。
　　 （5）circuitBreaker.requestVolumeThreshold
　　　　 默认值20。含义是一段时间内至少有20个请求才进行errorThresholdPercentage计算。比如一段时间了有19个请求，且这些请求全部失败了，错误率是100%，但熔断器不会打开，总请求数不满足20。
熔断器工作的详细过程如下：
　　 第一步，调用allowRequest()判断是否允许将请求提交到线程池
　　　　（1）如果熔断器强制打开，circuitBreaker.forceOpen为true，不允许放行，返回。
　　　　（2）如果熔断器强制关闭，circuitBreaker.forceClosed为true，允许放行。此外不必关注熔断器实际状态，也就是说熔断器仍然会维护统计数据和开关状态，只是不生效而已。
　　 第二步，调用isOpen()判断熔断器开关是否打开
　　　　（1）如果熔断器开关打开，进入第三步，否则继续；
　　　　（2）如果一个周期内总的请求数小于circuitBreaker.requestVolumeThreshold的值，允许请求放行，否则继续；
　　　　（3）如果一个周期内错误率小于circuitBreaker.errorThresholdPercentage的值，允许请求放行。否则，打开熔断器开关，进入第三步。
　　 第三步，调用allowSingleTest()判断是否允许单个请求通行，检查依赖服务是否恢复
　　　　（1）如果熔断器打开，且距离熔断器打开的时间或上一次试探请求放行的时间超过circuitBreaker.sleepWindowInMilliseconds的值时，熔断器器进入半开状态，允许放行一个试探请求；否则，不允许放行。
　降级，通常指务高峰期，为了保证核心服务正常运行，需要停掉一些不太重要的业务，或者某些服务不可用时，执行备用逻辑从故障服务中快速失败或快速返回，以保障主体业务不受影响。Hystrix提供的降级主要是为了容错，保证当前服务不受依赖服务故障的影响，从而提高服务的健壮性。要支持回退或降级处理，可以重写HystrixCommand的getFallBack方法或HystrixObservableCommand的resumeWithFallback方法。
　　Hystrix在以下几种情况下会走降级逻辑：
　　　　（1）执行construct()或run()抛出异常
　　　　（2）熔断器打开导致命令短路
　　　　（3）命令的线程池和队列或信号量的容量超额，命令被拒绝
　　　　（4）命令执行超时

6、什么是Hystrix 断路器？我们需要它吗？

1. Hystrix 能使你的系统在出现依赖服务失效的时候，通过隔离系统所依赖的服务，防止服务级联失败，同时提供失败回退机制，更优雅地应对失效，并使你的系统能更快地从异常中恢复。
2. Hystrix 能做什么？
	2.1 防止单个依赖耗尽容器（例如 Tomcat）内所有用户线程
	2.2 降低系统负载，对无法及时处理的请求快速失败（fail fast）而不是排队
	2.3 提供失败回退，以在必要时让失效对用户透明化
	2.4 使用隔离机制（例如『舱壁』/『泳道』模式，熔断器模式等）降低依赖服务对整个系统的影响
	2.5 针对系统服务的度量、监控和报警，提供优化以满足近实时性的要求	
	2.6 在 Hystrix 绝大部分需要动态调整配置并快速部署到所有应用方面，提供优化以满足快速恢复的要求
	2.7 能保护应用不受依赖服务的整个执行过程中失败的影响，而不仅仅是网络请求

7、什么是Netflix Feign？它的优点是什么？

简单地来说，Feign就是一个用于远程调用服务的框架/工具，让开发者可以更少耦合、更少代码、更加快，也更兼容的方法进行远程服务调用。
Feign可插拔的注解支持，包括Feign注解和JAX-RS注解；
Feign与Ribbon负载均衡器、Hystrix或Sentinel熔断器无缝集成；
Feign支持可插拔的HTTP编码器和解码器；
Feign支持HTTP请求和响应的压缩等。

8、什么是Spring Cloud Bus? 我们需要它吗？

Spring Cloud Bus是用来将分布式系统的节点与轻量级消息系统链接起来的框架，它整合了Java的事件处理机制和消息中间件的功能。

9、SpringBoot和Springcloud的区别？

1、含义不同；
	springboot：一个快速开发框架，它简化了传统MVC的XML配置，使配置变得更加方便、简洁。
	springcloud：是建立在SpringBoot上的服务框架，进一步简化了配置，它整合了一全套简单、便捷且通俗易用的框架。
2、作用不同；
	springboot：为了提供一个默认配置，从而简化配置过程。
	springcloud：为了给微服务提供一个综合管理框架。
3、使用方式不同；
	springboot：可以单独使用。
	springcloud：springcloud必须在springboot使用的前提下才能使用。
4、特征不同；
	springboot：
		spring应用：通过调用静态 run（） 方法创建独立的 Spring 应用程序。
		Web应用程序：我们可以使用嵌入式Tomcat，Jetty或Undertow创建HTTP服务器。无需部署 WAR 文件。
		外化配置：弹簧启动也提供基于产品的应用程序。它在不同的环境中也同样有效。
		安全性：它是安全的，内置于所有HTTP端点的基本身份验证中。
		应用程序事件和监听器：Spring Boot必须处理许多任务，应用程序所需的事件。添加用于创建工厂文件的侦听器。
	springcloud：
		智能路由和服务发现：在创建微服务时，有四个服务很重要。服务发现就是其中之一。这些服务相互依赖。
		服务到服务调用：要连接所有具有序列的从属服务，请注册以调用终端节点。
		负载均衡：将网络流量适当分配到后端服务器。
		全局锁定：两个线程不能同时访问同一资源。
		分布式配置和分布式消息传递
5、注释不同；
	springboot：
		@SpringBootApplication：此注释可以找到每个spring引导应用程序。它由三个注释组成：@EnableAutoConfiguration；@Configuration；@ComponentScan。它允许执行Web应用程序而无需部署到任何Web服务器中。
	    @ContextConfiguration：JUnit测试需要它。spring-boot 应用程序需要单元测试来测试其中的服务类。它加载SpringBoot上下文，但未提供完整的SpringBoot处理。
		@SpringApplicationConfiguration：它具有相同的工作@ContextConfiguration但提供完整的springboot处理。它加载 Bean 以及启用日志记录并从 application.properties 文件
		加载属性。@ConditionalOnBoot：它定义了几个条件注释：@ConditionalOnMissingBoot；@ConditionalOnClass；@ConditionalOnMissingClass；@ConditionalOnExpression；@ConditionalOnJav。
	springcloud：Spring Cloud主要遵循5个主要注释：
		@EnableConfigServer：此注释将应用程序转换为服务器，该服务器更多地用于应用程序以获取其配置。
		@EnableEurekaServer：用于 Eureka Discovery Services 的此注释可用于查找使用它的服务。
		@EnableDiscoveryClient：帮助此注释应用程序在服务发现中注册，发现使用它的其他服务。
		@EnableCircuitBreaker：使用断路器模式在相关服务发生故障时继续运行，防止级联故障。此注释主要用于 Hystrix 断路器。
		@HystrixCommand（回退方法=“ fallbackMethodName”）：用于标记回退到另一种方法的方法，它们无法正常成功。
6、优势不同；
	springboot：
		快速开发和运行独立的弹簧Web应用程序。
		默认情况下，它在需要时配置Spring功能。它的豆子被初始化并自动连接。
		它不需要基于 XML 的配置。直接嵌入Tomcat，Jetty以避免复杂的部署。
		没有必要部署 WAR 文件。
	springcloud：
		提供云服务开发。
		它是基于微服务的架构来配置。
		它提供服务间通信。
		it 基于Spring Boot模型。
7、组件不同；
	springboot：spring启动启动器，spring启动自动配置，spring启动执行器，spring启动 CLI，spring启动初始化。
	springcloud：配置、服务发现、断路器、路由和消息传递、API 网关、跟踪、CI 管道和测试。
8、设计目的不同。其中，含义不同指的是springboot是一个快速开发框架，而SpringCloud是建立在SpringBoot上的服务框架。
	springboot：springboot的设计目的是为了在微服务开发过程中可以简化配置文件，提高工作效率。
	springcloud：springcloud的设计目的是为了管理同一项目中的各项微服务，因此二者是完全不同的两个软件开发框架。

10、Spring Cloud和SpringBoot版本对应关系

Spring Boot 2.3.x版本是使用Spring Cloud Hoxton.SR9版本的，这是Spring Cloud的一个非常稳定的版本，而Spring Boot 2.3.x版本又提供了一些有用和有趣的新特性。例如，我们可以使用 EnvironmentPostProcessor 和 EnvironmentPostProcessor 注解来添加自定义的配置属性，可以更加灵活地使用自己的配置。

11、SpringCloud由什么组成

springcloud五大组件为：1、Eureka；2、Ribbon；3、Hystrix；4、Zuul；5、Config。其中，Eureka是一个RESTful服务，用来定位运行在AWS地区中的中间层服务，由Eureka服务器和客户端两个组件组成。
1、Eureka
作用：实现服务治理（服务注册与发现）。
	一个RESTful服务，用来定位运行在AWS地区（Region）中的中间层服务。由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的加权负载均衡。
	在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。
2、Ribbon
	作用：主要提供客户侧的软件负载均衡算法。
		Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Ribbon客户端组件提供一系列完善的配置选项，比如连接超时、重试、重试算法等。Ribbon内置可插拔、可定制的负载均衡组件。
3、Hystrix
	断路器可以防止一个应用程序多次试图执行一个操作，即很可能失败，允许它继续而不等待故障恢复或者浪费 CPU 周期，而它确定该故障是持久的。断路器模式也使应用程序能够检测故障是否已经解决。如果问题似乎已经得到纠正，应用程序可以尝试调用操作。
	为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
4、Zuul
	作用：具有api网关，路由，负载均衡等多种作用。
	类似nginx，反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。
5、Config
	作用：配置管理。
	SpringCloud Config提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。

12、使用Spring Boot开发分布式微服务时，我们面临什么问题？

（1）与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。
（2）服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录中的服务。
（3）冗余-分布式系统中的冗余问题。
（4）负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处理单元，或磁盘驱动器的分布。
（5）性能-问题 于各种运营开销导致的性能问题。
（6）部署复杂性 evops 技能的要求。

13、Spring Cloud和dubbo区别？

dubbo和spring cloud区别有：1、初始定位不同；2、生态环境不同；3、调用方式不同；4、技术选型不同；5、注册服务不同；6、Server集群服务信息同步不同；7、服务更新机制不同；8、服务更新反馈机制不同；9、服务信息回收机制不同；10、文档质量和社区活跃度不同。
1、初始定位不同
dubbo：Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用和治理。
spring cloud：springCloud定位为微服务架构下的一站式解决方案。

2、生态环境不同
dubbo：Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。
spring cloud：SpringCloud依托于Spring平台，具备更加完善的生态体系。
3、调用方式不同
dubbo：Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。但调用时采用Netty的NIO方式，性能较好。
spring cloud：SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活。
4、技术选型不同
dubbo：目前国内的分布式系统选型主要还是Dubbo毕竟国产，而且国内工程师的技术熟练程度高，并且Dubbo在其他维度上的缺陷可以由其他第三方框架进行集成进行弥补。
spring cloud：SpringCloud目前是国外比较流行，国内的市场也会慢慢的偏向SpringCloud，就连刘军作为Dubbo重启的负责人也发表过点,Dubbo的发展方向是积极适应SpringCloud生态，并不是起冲突。
5、注册服务不同
dubbo：Dubbo是基于java接口及Hession2序列化的来实现传输的，Provider对外暴露接口，Consumer根据接口的规则调用。也就是Provider向Zookeeper注册的是接口信息，Consumer从Zookeeper发现的是接口的信息，通过接口的name，group，version来匹配调用。Consumer只关注接口是否匹配，而对此接口属于什么应用不关心。当然接口的注册信息里会包含应用的ip，hostname等。
spring cloud：SpringCloud的服务发现是基于Http协议来实现的，Provider对外暴露的是应用信息，比如应用名称，ip地址等等，Consumer发现的是应用的信息，当调用的时候随机选择一个Provider的IP地址，应用名称，然后依据Http协议发送请求。Consumer关注的是应用名称，根据应用名称来决定调用的是哪个服务集群，然后对此名称对应的服务集群做负载均衡。Provider接受到请求后，根据内置的SpringMVC来匹配路由处理请求。
6、Server集群服务信息同步不同
dubbo：
Dubbo使用Zookeeper做服务发现和治理，Zookeeper是一个分布式协调框架，其有很多很实用的功能，服务发现仅仅是其中的一个。Zookeeper基于著名的CAP理论中的C(一致性)，P(分区可用性)实现，它的ZAB（zookeeper atomic broadcast protocol）协议，保证了集群里状态的一致性。Client的每一个事务操作都由Leader广播给所有Follower，当超过半数的Follower都返回执行成功后，才执行事务的ack。对于因网络崩溃或者宕机等问题而执行失败的zookeeper节点，zookeeper会基于zab的崩溃恢复机制来处理，这里不再讲述。每一个操作都需要过半数的zookeeper节点执行成功才确认成功，那么当zookeeper集群过半数节点出现问题时，服务发现功能就不可用。
spring cloud：SpringCloud使用Eureka做服务发现和治理，它是一个专门用于服务发现和治理的框架，其基于CAP理论中的A(可用性)，P(分区可用性)实现。EurekaServer节点间的服务信息同步是基于异步Http实现的。每隔Server节点在接收Client的服务请求时，立即处理请求，然后将此次请求的信息拷贝，封装成一个Task，存入Queue中。Server初始化时会启动一个线程定期的从TaskQueue中批量提取Task，然后执行。服务同步不保证一定成功，虽然有失败重试，但超过一定时限后就放弃同步。当然其有一个特性，当服务丢失后，同步的操作返回400，404后会立即将最新的服务信息同步过去，因此即使中途同步失败，不会对后续的同步有影响。
7、服务更新机制不同
dubbo：Dubbo使用Zookeeper做服务发现和治理，订阅Zookeeper下相应的znode。当节点发生变化，比如有新的元素增加，或者旧的元素移除，Zookeeper会通知所有订阅此节点的Client，将当前的全量数据同步给各Client，Dubbo里根据最新的数据来做相应处理，移除下线的，初始化新增的。每次更新都同步全量数据。
spring cloud：Eureka在启动时向Server进行一次全量拉取，获取所有的可用服务信息，之后默认情况下都是进行增量拉取。Server会将有变化的服务信息放在一个Queue里，Client每次同步时仅获取增量信息，根据信息里的操作类型，服务信息来对当前持有的服务做相应的处理，移除下线的，初始化新增的等。每次更新仅同步增量数据，也就是更新的数据。
8、服务更新反馈机制不同
dubbo：Dubbo订阅Zookeeper下相应的节点，当节点的状态发生改变时，Zookeeper会立即反馈订阅的Client，实时性很高。
spring cloud：Eureka Server在接收到Client的更新操作，或者移除服务信息时，仅仅会将更新消息存放入recentlyChangedQueue中，不会主动的反馈其他Client。其他Client只有在拉取服务增量信息时才会感知到某个服务的更新，延时最大为30S，也就是拉取周期。
9、服务信息回收机制不同
dubbo：Dubbo Provider初始化时会创建一个Zookeeper Client，专门用于与Zookeeper集群交互。维持与集群间的长连接，定时发送心跳，维护Zookeeper上自身节点的存在。节点类型是临时节点，也就是当心跳超时或者长连接断开时，会立即移除Provider对应的节点。
Dubbo Consumer初始化时也会创建一个Zookeeper Client，专门用于与Zookeeper集群交互。维持长连接，创建EvenetListener，监听Provider节点的变动情况。当Provider节点新增或者移除时，Zookeeper会广播这个事件，然后将此节点的当前值(剩下的所有接口信息)发送给那些注册了此节点监听器的Client。Consumer获取到对应Provider节点下的所有接口信息后，移除已下线的，创建新增的。Zookeeper对服务信息的维护实时性和一致性比较高，但也可能因为网络问题或者集群问题导致服务不可用。
spring cloud：SpringCloud的服务信息回收仅基于心跳超时，与长连接无关。当心跳超时后，EurekaServer回收服务信息，然后将此动作同步给其他Server节点。当然可能一个服务信息会存在多个Server上，多次回收操作的同步具备幂等性。也就是说服务回收只需要通知一个Server节点就可以了，回收动作会通过Server节点传播开来。EurekaServer能够回收服务信息由个重要前提：上一分钟内正常发送心跳的服务的比列超过总数的85%，如果因为网络波动等原因造成大量服务的心跳超时，那么EurekaServer会触发自我保护机制，放弃回收那些心跳超时的服务信息。服务发现组件应该优先保证可用性，Consumer能够发现Provider，即使发现的是非可用的Provider，但因为Conusmer一般具备容错机制，不会对服务的正常调用有太多影响。从这点上看Eureka的服务发现机制要比Zookeeper稍微合理一点的。
10、文档质量和社区活跃度不同
SpringCloud社区活跃度远高于Dubbo,毕竟由于梁飞团队的原因导致Dubbo停止更新迭代五年,而中小型公司无法承担技术开发的成本导致Dubbo社区严重低落,而SpringCloud异军突起,迅速占领了微服务的市场,背靠Spring混的风生水起，Dubbo经过多年的积累文档相当成熟,对于微服务的架构体系各个公司也有稳定的现状。

14、服务注册和发现是什么意思？

服务注册和发现的意思是服务进程在注册中心注册自己的位置，客户端应用进程向注册中心发起查询，来获取服务的位置，服务发现的一个重要作用就是提供一个可用的服务列表。
服务注册与发现作用
服务注册：服务进程在注册中心注册自己的位置。它通常注册自己的主机和端口号，有时还有身份验证信息，协议，版本号，以及运行环境的详细资料。
服务发现：客户端应用进程向注册中心发起查询，来获取服务的位置。服务发现的一个重要作用就是提供一个可用的服务列表

服务注册、服务注册表、服务发现
三者的关系是：通过服务注册机制将启动服务的信息上传至服务注册表，服务发现机制通过服务注册表实时获取可用服务的信息。
服务注册的方式包括：自注册和第三方注册。自注册的意思是当服务启动时，服务自动将信息上传至服务注册表，并通过心跳进行同步。第三方注册的意思是通过一个第三方的服务将启动服务的信息上传至服务注册表，并通过一定机制保持更新。缺点是要保证第三方服务的高可用性。
服务注册表也是一个服务集群，维护了一个数据库，数据库中存储的是可用服务的信息。
服务发现的意思是当需要使用服务时，通过读取服务注册表获取可用的服务信息，客户端可以通过此信息连接服务器。服务发现的方式包括：客户端服务发现和服务端服务发现
Spring Cloud如何实现？

15、什么是Eureka?

Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，主要用于定位运行在AWS域中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。

16、Eureka怎么实现高可用

可以通过运行多个Eureka server实例并相互注册的方式实现，Server节点之间会彼此增量地同步信息，从而确保节点中数据一致。

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

当微服务客户端启动后，会把自身信息注册到Eureka注册中心，以供其他微服务进行调用。一般情况下，当某个服务不可用时（一段时间内没有检测到心跳或者连接超时等），那么Eureka注册中心就会将该服务从可用服务列表中剔除，但是在微服务架构中，因为服务数量众多，可能存在跨机房或者跨区域的情况，因此当某个服务心跳探测失败并不能完全说明其无法正常提供服务而将其剔除，并且服务一旦剔除后，再重新注册将会重新进行负载均衡等等一系列的操作，考虑到性能问题，eureka会将不可用的服务暂时断开，并期望能够在接下来一段时间内接收到心跳信号，而不是直接剔除，同时，新来的请求将不会分发给暂停服务的实例，这就是eureka的保护机制，它保护了因网络等问题造成的短暂的服务不可用的实例，避免频繁注册服务对整个系统造成影响。

18、DiscoveryClient的作用

@EnableDiscoveryClient和@EnableEurekaClient共同点就是：都是能够让注册中心能够发现，扫描到该服务。
@EnableEurekaClient只适用于Eureka作为注册；@EnableDiscoveryClient 可以是其他注册中心。

19、Eureka和Zookeeper都可以提供服务注册与发现的功能，请说说两个的区别？

zookeeper 是CP原则，强一致性和分区容错性。 eureka 是AP 原则 可用性和分区容错性。 zookeeper当主节点故障时，zk会在剩余节点重新选择主节点，耗时过长，虽然最终能够恢复，但是选取主节点期间会导致服务不可用，这是不能容忍的。 eureka各个节点是平等的，一个节点挂掉，其他节点仍会正常保证服务。

ZUUL面试题

1、什么是网关？

Zuul 是 Netflix 开源的一个网关组件 API Gateway 服务器，在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。

2、网关的作用是什么？

3、什么是Spring Cloud Zuul （服务网关）

　三个重要概念：动态路由表，路由定位，反向代理：
　　动态路由表：Zuul支持Eureka路由，手动配置路由，这俩种都支持自动更新
　　路由定位：根据请求路径，Zuul有自己的一套定位服务规则以及路由表达式匹配
　　反向代理：客户端请求到路由网关，网关受理之后，在对目标发送请求，拿到响应之后在给客户端

它可以Eureka,Ribbon,Hystrix等组件配合使用
Zuul的应用场景：对外暴露，权限校验，服务聚合，日志审计等

4、网关与过滤器有什么区别？

网关是对所有服务的请求进行分析过滤，过滤器是对单个服务而言。

5、常用网关框架有那些？

Nginx、Zuul、Gateway

6、Zuul与Nginx有什么区别？

不同点:
1) 首先 , Nginx是C语言开发,而 Zuul 是Java语言开发
2)其次,Nginx负载均衡实现,采用服务器实现负载均衡,而Zuul负载均衡的实现是采用 Ribbon  + Eureka 来实现本地负载均衡.
3) Nginx适合于服务器端负载均衡,Zuul适合微服务中实现网关
4) Nginx相比Zuul功能会更加强大,因为Nginx整合一些脚本语言( Nginx + lua )
5) Nginx 是一个高性能的HTTP 和反向代理服务器, 也是一个 IMAP / POP3 /SMIP 服务器. Zuul是 Spring Cloud  Netflix 中的开源的一个API Gateway 服务器,本质上是一个web servlet 应用, 提供动态路由,监控,弹性,安全等边缘服务的框架. Zuul 相当于是设备和Netflix 流应用的Web 网站后端所有请求的前门

相同点:
1) 可以实现负载均衡 (Zuul使用的是Ribbon实现负载均衡)
2) 可以实现反向代理 (即隐藏真实ip地址)
3) 可以过滤请求,实现网关的效果

7、既然Nginx可 以实现网关？为什么还需要使用zuul框架

8、如何设计一套API接口？

设计一套良好的API接口需要考虑以下几个方面：
1. 定义清晰的业务需求：在着手设计API接口之前，确保你对业务需求有清晰的理解。明确接口的功能、目标和预期结果，这有助于确定所需的操作和数据。
2. RESTful设计原则：采用RESTful设计原则可以使API接口更加可理解和易用。包括使用合适的HTTP方法（如GET、POST、PUT、DELETE等）来表示操作类型，使用URI来标识资源，使用合适的状态码和错误处理机制等。
3. 统一的命名规范：为API接口和资源命名采用一致的规范，使用清晰、简洁、易懂的命名，以提高接口的可读性和可维护性。可以使用动词来表示操作，使用名词来表示资源。
4. 合理的URI设计：URI应该清晰、有意义，能够准确地标识资源。遵循层级结构、使用斜杠（/）分隔路径，可以提供更结构化和可扩展的URI设计。
5. 请求和响应格式：定义清晰的请求和响应格式，包括请求参数、请求头、响应体的结构和内容。可以使用标准的数据交换格式，如JSON或XML，并提供详细的文档说明。
6. 身份验证和安全性：确定API接口的身份验证和安全性需求，并设计相应的认证和授权机制，确保只有授权用户可以访问受限资源。
7. 错误处理：设计良好的错误处理机制，包括使用适当的HTTP状态码和错误消息，以及提供详细的错误信息，方便开发者理解和处理错误情况。
8. 版本控制：考虑到接口的演进和兼容性，可以通过版本控制的方式来管理不同版本的API接口，以确保现有客户端的正常运行，并为后续的修改和扩展留出空间。
9. 接口文档和示例：编写清晰、详细的接口文档，包括接口的说明、使用示例、参数说明等。提供示例代码和演示应用，帮助开发者理解和使用接口。
10. 性能和优化：在设计API接口时，考虑到性

9、ZuulFilter常用有那些方法？

shouldFilter：返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行。
run：过滤器的具体业务逻辑。
filterType：返回字符串，代表过滤器的类型。包含以下4种：
pre：请求在被路由之前执行
route：在路由请求时调用
post：在route和errror过滤器之后调用
error：处理请求时发生错误调用
filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。

10、如何实现动态zuul网关路由转发?

方式一：之前用过自定义路由，在yml文件配置route的方式去做转发，但是必须精确匹配，这就需要大量的重复配置。（略）
方式二：在zuul中自定义url映射filter

11、Zuul网关如何搭建集群？

12、负载平衡的意义什么？

13、Ribbon是什么？

Ribbon客户端组件提供一系列的完善的配置，如超时，重试等。通过Load Balancer获取到服务提供的所有机器实例，Ribbon会自动基于某种规则(轮询，随机)去调用这些服务。Ribbon也可以实现我们自己的负载均衡算法。

14、Nginx与Ribbon的区别？

Nginx与Ribbon同是负载均街器，但是它们也有很大的不同。
(1)Nginx(服务器端负载均街器)
	Nginx的作用是系统将客户端所有请求统一交给Nginx,由Nginx实现负载均街请求转发，即在服务器端实现负载均衡。
(2)Ribbon(客户端负载均衡器)
	Ribbon的作用是从Eureka服务注册发现中心上获取服务注册信息列表，缓存到本地，然后在本地实现负载均衡策略，即在客户端实现负载均衡。

15、Ribbon底层实现原理？

Hystri

1、什么是断路器？

“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要的占用、从而避免了故障在分布式系统中的蔓延、乃至雪崩。

2、什么是Hystrix?

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能保证在一个依赖出问题的情况下，不会导致整体服务失败、避免级联故障，以提高分布式系统的弹性。

3、谈谈服务雪崩效应？

微服务之间相互调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况。

4、在微服务中，如何保护服务？

 超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待
 舱壁模式：限定每个业务能使用的线程数，避免耗尽整个 tomcat 的资源，因此也叫线程隔离
 熔断降级：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求
 流量控制：限制业务访问的 QPS，避免服务因流量的突增而故障

5、服务雪崩效应产生的原因

1、服务提供者不可用
2.重试加大流量
	在服务提供者不可用后，用户由于忍受不了界面上的长时间等待，而不断刷新页面，甚至提交表单。
	服务的调用端存在大量服务异常后的重试逻辑。
3.服务调用者不可用（服务雪崩效应的每个阶段都可能由不同的原因造成）造成服务不可能的原因如下：
	硬件故障可能为硬件损坏造成的服务器主机死机，网络硬件故障造成的服务提供者的不可访问。
	缓存击穿一般发生在缓存应用重启，所有缓存被清空时，以及短时间内大量的缓存失效时。大量的缓存不命中，使请求直接访问后端，造成服务提供者超负荷运行，引起服务不可用。
	在秒杀和大促开始前，如果准备不充分，使用户发起大量的请求，也会造成服务的不可用。

6、谈谈服务降级、熔断、服务隔离了、服务降级底层是如何实现的？

服务降级：在高并发的情况下，防止用户一直等待，使用服务降级方式进行处理(返回友好的提示给客户端，fallback回调方法)。当服务不可用的时候(正在等待的时候、网络延迟、响应时间过长),客户端会处于一直等待的状态。显然一直等待是不合理的，所以我们应该给客户端返回一个友好的提示，使用fallback(回调方法)进行服务降级处理。
服务降级目的：为了提高用户体验(自定义消息返回给客户端)，防止服务雪崩效应。比如：连接超时、网络延迟、服务器响应时间过长等情况。
服务雪崩效应的产生原因：因为默认情况下，只有一个线程池处理所有的服务接口，所有的请求都会被一个线程池处理。如果大量的请求访问同一个接口，当达到tomcat默认极限(可以自己设置)，可能会导致其他服务接口无法访问。
服务隔离：每个服务接口之间互不影响，服务隔离有2种实现方式，线程池方式、信号量。
	1.线程池方式：相当于每个接口(服务)都有自己独立的线程池，不同的线程池之间互不影响，能够实现服务接口隔离。缺点：CPU内存开销较大。
	2.信号量方式：底层使用原子计数器(atomic)，针对于每个服务都设置自己的独立的限制阈值。比如设置每个服务接口最多同时访问的次数，如果超出缓存队列请求后，自己实现拒绝策略。
服务熔断：在高并发的情况下，如果达到一定的极限(可以自己设置阈值),如果流量超出了设置的阈值，然后拒绝访问，保护当前服务。当服务器达到最大的承受能力的之后，直接拒绝访问服务，然后调用降级方法，返回友好提示。

Feign

1、什么是Feign?

Feign是一个http请求调用的轻量级框架，可以以Java接口注解的方式调用Http请求。Feign通过处理注解，将请求模板化，当实际调用的时候，传入参数，根据参数再应用到请求上，进而转化成真正的请求，封装了http调用流程。

2、SpringCloud有几种调用接口方式?

SpringCloud服务间的调用有两种方式：RestTemplate和FeignClient。不管是什么方式，他都是通过REST接口调用服务的http接口，参数和结果默认都是通过jackson序列化和反序列化。因为Spring MVC的RestController定义的接口，返回的数据都是通过Jackson序列化成JSON数据。

3、Ribbon和Feign调用服务的区别？

Ribbon和Feign都是Netflix公司开发的Java库，用于实现分布式系统中的客户端负载均衡和服务调用。两者的区别如下：
功能不同：Ribbon主要提供了客户端负载均衡的功能，可以在多个服务提供者之间分发请求。Feign则是在Ribbon的基础上提供了一个更高级的抽象层，简化了服务间的调用方式，使得调用方式更加像本地方法调用。
使用方式不同：Ribbon需要手动编写代码来实现负载均衡的功能，需要实现负载均衡器和服务列表的管理。而Feign则是基于注解和接口定义的方式，可以自动根据接口定义生成客户端代码，并且已经集成了Ribbon的负载均衡功能，使用起来更加方便。
可扩展性不同：Ribbon提供了丰富的可定制化选项，可以根据实际情况自定义负载均衡策略、重试机制等。而Feign则相对简单，提供了较少的可扩展性选项，如果需要更高级的功能，则需要自己编写代码实现。

4、为什么选择 Feign

如果不使用rpc框架，那么调用服务需要走http的话，无论是使用 JDK 自带的 URLConnection，还是使用Http工具包 Apache 的httpclient， 亦或是 OkHttp， 都需要自行配置请求head、body，然后才能发起请求。获得响应体后，还需解析等操作，十分繁琐。而Feign 只需要定义一个接口，并且通过注解的形式定义好请求模板，就可以项使用本地接口一样，使用Http请求。

Bus

1、什么是Spring Cloud Bus?

spring cloud是按照spring的配置对一系列微服务框架的集成，spring cloud bus是其中一个微服务框架，用于实现微服务之间的通信。

spring cloud bus整合 java的事件处理机制和消息中间件消息的发送和接受，主要由发送端、接收端和事件组成。针对不同的业务需求，可以设置不同的事件，发送端发送事件，接收端接受相应的事件，并进行相应的处理。
目前 Spring Cloud Bus 支持两种消息代理：RabbitMQ 和 Kafka
需要配合springcloud config使用
Confifi

1、什么是Spring Cloud Confifig?

简单来说，Spring Cloud Config就是能将各个 应用/系统/模块 的配置文件存放到统一的地方然后进行管理(Git 或者 SVN),客户端通过接口去获取这些配置文件。

2、分布式配置中心有那些框架？

ZooKeeper：一个高性能的分布式协调服务，可以用作配置中心、命名服务等。
Consul：也是一个分布式协调服务平台，支持服务注册与发现、健康检查、KV存储等功能。
Etcd：一个分布式可靠的键值存储系统，支持分布式锁和通知机制。
Apollo：携程开源的企业级配置中心，提供管理界面、版本控制、灰度发布等功能。
Spring Cloud Config：基于Spring Cloud的配置中心，支持Git和SVN作为后端存储，并提供RESTful API和Web UI。
Nacos：阿里巴巴开源的新一代服务发现和配置管理平台，支持动态配置、服务发现和流量管理等功能。

3、分布式配置中心的作用？

1、对配置文件进行集中管理，在不同的环境下或者不同配置中，可以对配置文件进行更新和部署。
2、在程序的运行期间，可以对程序中的配置文件进行动态性调整。使用分布式配置中心，就不需要在每一台服务器上都进行配置文件的修改，只需要在总服务器中进行修改，系统就会向其他的服务器进行统一的修改配置。
3、如果系统程序的配置发生了变动，无需要重新重启服务器，就能够自动感知相应的变化，并将新的变化统一发送到相应程序上。
分布式配置中心作用有很多，上面指出了，大家简单罗列了几个最为常见的作用。
分布式配置中心优点有哪些
	1、效率高。分布式配置中心能够对系统配置文件进行相应的修改和管理，即使系统文件产生了一定变化，也无需重启服务器，这样就大大提高了系统运行的效率。
	2、管理方便。使用分布式配置中心后可以直接对系统的配置文件进行统一的管理，而不需要逐一对单个的服务器进行管理。
	3、能够和云技术等其他互联网新兴技术结合使用。分布式配置中心是基于分布式技术和互联网进行技术结合而产生的，它可以和云技术等互联网基金技术一起配合使用。

4、SpringCloud confifig 可以实现实时刷新吗？

1、ConfigServer(配置中心服务端)从远端git拉取配置文件并在本地git一份，ConfigClient（微服务）从ConfigServer端获取自己对应 配置文件；
2、当远端git仓库配置文件发生改变，ConfigServer如何通知到ConfigClient端，即ConfigClient如何感知到配置发生更新？
	Spring Cloud Bus会向外提供一个http接口，即图中的/bus/refresh。我们将这个接口配置到远程的git的webhook上，当git上的文件内容发生变动时，就会自动调用/bus-refresh接口。Bus就会通知config-server，config-server会发布更新消息到消息总线的消息队列中，其他服务订阅到该消息就会信息刷新，从而实现整个微服务进行自动刷新。

Gateway

1、什么是Spring Cloud Gateway?

Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，Spring Cloud Gateway 旨在为微服务架构提供一种简单而有效的统一的 API 路由管理方式。Spring Cloud Gateway 作为 Spring Cloud 生态系中的网关，目标是替代 Netflix ZUUL，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。

2、SpringCloud主要项目

Spring Cloud的子项目，大致可分成两类，一类是对现有成熟框架"Spring Boot化"的封装和抽象，也是数量最多的项目；第二类是开发了一部分分布式系统的基础设施的实现，如Spring Cloud Stream扮演的就是kafka, ActiveMQ这样的角色。