当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的信息，但不能容忍直接down掉不可用。就是说，服务注册功能对高可用性要求比较高，但zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新选leader。问题在于，选取leader时间过长，30 ~ 120s，且选取期间zk集群都不可用，这样就会导致选取期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够恢复，但是漫长的选取时间导致的注册长期不可用是不能容忍的。

（2）Eureka各个节点是平等关系，只要有一台Eureka就可以保证服务可用，而查询到的数据并不是最新的，自我保护机制会导致Eureka不再从注册列表移除因长时间没收到心跳而应该过期的服务。Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点(高可用)，当网络稳定时,当前实例新的注册信息会被同步到其他节点中(最终一致性)

Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像ZooKeeper一样使得整个注册系统瘫痪

Eureka保证了可用性，Eureka各个节点是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点仍然可以提供注册和查询服务。而Eureka的客户端向某个Eureka注册或发现时发生连接失败，则会自动切换到其他节点，只要有一台Eureka还在，就能保证注册服务可用，只是查到的信息可能不是最新的。除此之外，Eureka还有自我保护机制，如果在15分钟内超过85%的节点没有正常的心跳，那么Eureka就认为户端与注册中心发生了网络故障，此时会出现以下几种情况：

①、Eureka不从注册列表中移除因为长时间没有收到心跳而应该过期的服务。

②、Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点仍然可用）

③、当网络稳定时，当前实例新的注册信息会被同步到其他节点。

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样使整个微服务瘫痪。

1.2 ZooKeeper有Leader和Follower角色，Eureka各个节点平等

1.3 ZooKeeper采用过半数存活原则，Eureka采用自我保护机制解决分区问题

1.4 Eureka本质上是一个微服务的一个模块，而ZooKeeper只是一个进程，需要单独安装

2. SpringCloud Config可以实现实时刷新吗?

可以。

2.1 Spring Cloud 默认实现了配置中心动态刷新的功能，在公共模块 spring-cloud-context 包中。目前比较流行的配置中心 Spring Cloud Config 动态刷新便是依赖此模块。

首先 Spring Cloud Config 动态刷新需要依赖 Spring Cloud Bus。

其次，Spring Cloud Config的刷新机制针对所有修改的变量，只要有改动，后台就会获取。

配置中心动态刷新的范围都是以下两种：

@ConfigurationProperties 注解的配置类

@RefreshScope 注解的bean

2.2 如何实现

（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会发布更新消息到消息总线的消息队列中，其他服务订阅到该消息就会信息刷新，从而实现整个微服务进行自动刷新。

3. 什么是 Spring Cloud Bus?

3.1 Spring cloud Bus的本质是用Spring Cloud Stream通过MQ把各个应用连接起来进行数据的传输，但这个传输不同于业务层面的数据传输，更多的是用来做控制层面的指令传输。比如：刷新配置等。

3.2 Spring Cloud Bus就像个分布式执行器，用于扩展的Spring Boot应用程序的配置文件，但也可以用作应用程序之间的通信通道。

3.3 Spring Cloud Bus不能单独完成通信，需要配合MQ支持。

3.4 Spring Cloud Bus一般是配合Spring Cloud Config做配置中心的。

3.5 Spring Cloud：config实时刷新也必须采用Spring Cloud Bus消息总线。

4. 如何实现动态Zuul网关路由转发？

传统方式将路由规则配置在配置文件中，如果路由规则发生了改变，需要重启服务器。

这时候整合SpringCloud Config分布式配置中心，实现动态路由规则。

5. ZuulFilter有哪些常用方法？

Run()：过滤器的具体业务逻辑

shouldFilter()：判断过滤器是否有效

filterOrder()：过滤器执行顺序

filterType()：过滤器拦截位置

6. 什么是服务雪崩效应?

6.1 什么是服务血崩效应

微服务中往往存在多个服务，且服务之间互相调用，当某个服务不可用，导致其他服务可能发生连锁效应，导致整个系统变得不可用，这种现象称之为服务雪崩效应。

6.2 服务雪崩造成的原因（分三阶段分析）：

（1）服务提供者不可用

重试造成流量加大

服务调用者不可用

服务不可用原因：

（2）硬件故障

程序Bug

缓存击穿

用户请求量过大

重试造成的流量加大的原因：

（3）用户的频繁重试

代码逻辑重试

6.3 解决服务雪崩问题方案：

增加硬件设施

流量控制（网关限流，nignx限流，AOP限流，关闭程序重试）

缓存（缓存预加载）

服务的降级、服务的熔断

7. 什么是服务熔断？什么是服务降级？

7.1 服务熔断：

一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护；

服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）

7.2 服务降级：

是在服务器压力陡增的情况下，利用有限资源，根据当前业务情况，关闭某些服务接口或者页面，以此释放服务器资源以保证核心任务的正常运行。

流量控制本质上是减小访问量，而服务处理能力不变；而服务降级本质上是降低了部分服务的处理能力，增强另一部分服务处理能力，而访问量不变。

8. 什么是zuul？

8.1 zuul是什么

Zuul是Netflix开源的API网关，本质上是一个web servlet应用。
API网关，类似于面向对象设计模式中的Facade模式，它的存在就像是整个微服务架构系统的门面一样，所有的外部客户端访问都需要经过它来进行调度和过滤，它除了要实现请求路由，负载均衡，来源合法性检测，权限校验，反爬虫等功能之外，还需要更多能力，比如与服务治理框架的结合，请求转发时的熔断机制，服务的聚合等一系列的高级功能。

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

8.2 zuul能干什么

身份验证和安全 - 识别每个资源的身份验证要求，并拒绝不满足的请求

审查和监测 - 跟踪边缘的有意义的数据和统计数据，以便我们准确地了解生产运行情况

动态路由 - 根据需要将请求动态路由到不同的后端集群

压力测试 - 逐渐增加到集群的流量，以衡量性能

负载分配 - 为每种类型的请求分配容量并删除超出限制的请求

静态响应处理 - 直接在边缘构建一些响应，而不是将它们转发到内部集群

9. 说说Eureka的自我保护机制？

Eureka的自我保护特性主要用于减少在网络分区或者不稳定状况下的不一致性问题

9.1 Eureka自我保护的产生原因

Eureka在运行期间会统计心跳失败的比例，在15分钟内是否低于85%,如果出现了低于的情况，Eureka Server会将当前的实例注册信息保护起来，同时提示一个警告，一旦进入保护模式，Eureka Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据。也就是不会注销任何微服务。

9.2 Kubernetes环境

但在Kubernetes环境下，如果某个节点的Kubelet下线，比较容易造成自我保护。阶段如下：

（1）Kubelet下线，会造成大量的服务处于Unknow状态, Kubernetes为了维持Deployment指定的Pod数量，会在其他节点上启动服务，注册到Eureka,这个时候是不会触发自我保护的。

（2）重新启动Kubelet进行让节点Ready,这时候Kubernetes发现Pod数量超过了设计值，然后Terminate原来Unknown的Pod,这个时候就会出现大量的服务下线状态，从而触发自我保护

（3）而处于自我保护状态的Eureka不再同步服务的信息，同时也不再和另一个实例保持同步。

这个是个比较核心的问题，如果这样的话，只能够手工删除Eureka实例让他重建，恢复正常状况。所以在Kubernetes环境下，关闭服务保护，让Eureka和服务保持同步状态。

9.3 目前的解决办法

（1）Eureka Server端：配置关闭自我保护，并按需配置Eureka Server清理无效节点的时间间隔。

eureka.server.enable-self-preservation# 设为false，关闭自我保护eureka.server.eviction-interval-timer-in-ms # 清理间隔（单位毫秒，默认是60*1000）

（2）Eureka Client端：配置开启健康检查，并按需配置续约更新时间和到期时间。

eureka.client.healthcheck.enabled# 开启健康检查（需要spring-boot-starter-actuator依赖）

eureka.instance.lease-renewal-interval-in-seconds# 续约更新时间间隔（默认30秒）

eureka.instance.lease-expiration-duration-in-seconds # 续约到期时间（默认90秒）

10. Eureka的工作原理？

10.1 Eureka 作为 Spring Cloud 体系中最核心、默认的注册中心组件。

Eureka 是 Netflix 出品的用于实现服务注册和发现的工具。 Spring Cloud 集成了 Eureka，并提供了开箱即用的支持。其中， Eureka 又可细分为 Eureka Server 和 Eureka Client。

10.2 下图是来自eureka的官方架构图，这是基于集群配置的eureka；
- 处于不同节点的eureka通过Replicate进行数据同步
- Application Service为服务提供者
- Application Client为服务消费者
- Make Remote Call完成一次服务调用

服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。

当服务注册中心Eureka Server检测到服务提供者因为宕机、网络原因不可用时，则在服务注册中心将服务置为DOWN状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。

服务提供者在启动后，周期性（默认30秒）向Eureka Server发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间（默认90秒）未收到客户端的心跳，则认为服务宕机，注销该实例。

11. 什么是Netflix Feign？它的优点是什

Feign 是受到 Retrofit，JAXRS-2.0 和 WebSocket 启发的 java 客户端联编程序。

Feign 的第一个目标是将约束分母的复杂性统一到 http apis，而不考虑其稳定性。

在 employee-consumer 的例子中，我们使用了 employee-producer 使用 REST模板公开的 REST 服务。

但是我们必须编写大量代码才能执行以下步骤

（1）使用功能区进行负载平衡。

（2）获取服务实例，然后获取基本 URL。

（3）利用 REST 模板来使用服务。

12. 什么是Hystrix断路器？我们需要它吗？

由于某些原因，employee-consumer 公开服务会引发异常。在这种情况下使用Hystrix 我们定义了一个回退方法。如果在公开服务中发生异常，则回退方法返回一些默认值。

如果 firstPage method() 中的异常继续发生，则 Hystrix 使用者将一起跳过 firstPage 方法，并直接调用回退方法。断路器的目的是给第一方法或第一页方法可能调用的其他方法留出时间，并导致异常恢复。可能发生的情况是，在负载较小的情况下，导致异常的问题有更好的恢复机会。

13. 什么是Hystrix？它如何实现容错？

13.1什么是“雪崩效应”？

多个微服务之间调用的时候，假设A调用B和C，B和C又在调用其他的微服务，这种情况就叫做“扇出”,这个时候有一个微服务出现问题，或这长时间未响应，对A微服务的占用的越来越多的系统资源，这就是所谓的“雪崩效应“；

这时候就出现了Hystrix，他的作用就是：避免了单个调用的微服务导致全局”雪崩”。

Hystrix，是对雪崩效应的一种微服务链路的保护机制。

Hystrix的功能有很多。

1）服务降级

2）服务熔断

3）服务限流

4）实时监控

13.2 什么是Hystrix

Hystrix是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，停止级联故障并在复杂的分布式系统中实现弹性。通常对于使用微服务架构开发的系统，涉及到许多微服务。这些微服务彼此协作。

随着微服务数量的增加，这个问题变得更加复杂。微服务的数量可以高达 1000.这是 hystrix 出现的地方,我们将使用 Hystrix 在这种情况下的 Fallback 方法功能。

Hystrix是熔断机制，使用注解@HystrixCommand可以实现容错，在注解的value属性里指明发生错异常时的执行函数，在该类中定义该函数，并调用该类中的未发生异常的函数或者其他逻辑来实现容错。

14. Spring Cloud由哪些组件组成？

14.1 是基于SpringBoot的一整套实现微服务的框架。他提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。

14.2微服务是可以独立部署、水平扩展、独立访问（或者有独立的数据库）的服务单元，springcloud就是这些微服务的大管家，采用了微服务这种架构之后，项目的数量会非常多，springcloud做为大管家需要管理好这些微服务，自然需要很多组件.

14.3 核心组件：

（1）Spring Cloud Netflix：cloud各项服务依赖与它，与各种Netflix OSS组件集成，组成微服务的核心，它的主要有组成有Eureka, Hystrix, Zuul, Archaius… 太多了

（2）Netflix Eureka：服务中心，云端服务发现，一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。这个可是springcloud最牛鼻的小弟，服务中心，任何小弟需要其它小弟支持什么都需要从这里来拿，同样的你有什么独门武功的都赶紧过报道，方便以后其它小弟来调用；它的好处是你不需要直接找各种什么小弟支持，只需要到服务中心来领取，也不需要知道提供支持的其它小弟在哪里，还是几个小弟来支持的，反正拿来用就行，服务中心来保证稳定性和质量。

（3）Netflix Hystrix：熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。比如突然某个小弟生病了，但是你还需要它的支持，然后调用之后它半天没有响应，你却不知道，一直在等等这个响应；有可能别的小弟也正在调用你的武功绝技，那么当请求多之后，就会发生严重的阻塞影响老大的整体计划。这个时候Hystrix就派上用场了，当Hystrix发现某个小弟不在状态不稳定立马马上让它下线，让其它小弟来顶上来，或者给你说不用等了这个小弟今天肯定不行，该干嘛赶紧干嘛去别在这排队了。

（4）Netflix Zuul：Zuul 是在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。当其它门派来找大哥办事的时候一定要先经过zuul,看下有没有带刀子什么的给拦截回去，或者是需要找那个小弟的直接给带过去。

（5）Netflix Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。可以实现动态获取配置，

原理是每隔60s（默认，可配置）从配置源读取一次内容，这样修改了配置文件后不需要重启服务就可以使修改后的内容生效，前提使用archaius的API来读取。

（6）Spring Cloud Config：俗称的配置中心，配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion。就是以后大家武器、枪火什么的东西都集中放到一起，别随便自己带，方便以后统一管理、升级装备。

（7）Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。相当于水浒传中日行八百里的神行太保戴宗，确保各个小弟之间消息保持畅通。

（8）Spring Cloud for Cloud Foundry：Cloud Foundry是VMware推出的业界第一个开源PaaS云平台，它支持多种框架、语言、运行时环境、云平台及应用服务，使开发人员能够在几秒钟内进行应用程序的部署和扩展，无需担心任何基础架构的问题，其实就是与CloudFoundry进行集成的一套解决方案，抱了Cloud Foundry的大腿。

（9）Spring Cloud Cluster：Spring Cloud Cluster将取代Spring Integration。提供在分布式系统中的集群所需要的基础功能支持，如：选举、集群的状态一致性、全局锁、tokens等常见状态模式的抽象和实现。如果把不同的帮派组织成统一的整体，Spring Cloud Cluster已经帮你提供了很多方便组织成统一的工具。

（10）Spring Cloud Consul：Consul 是一个支持多数据中心分布式高可用的服务发现和配置共享的服务软件,由 HashiCorp 公司用 Go 语言开发, 基于 Mozilla Public License 2.0 的协议进行开源. Consul 支持健康检查,并允许 HTTP 和 DNS 协议调用 API 存储键值对。Spring Cloud Consul 封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。

（11）Spring Cloud Security：基于spring security的安全工具包，为你的应用程序添加安全控制。这个小弟很牛鼻专门负责整个帮派的安全问题，设置不同的门派访问特定的资源，不能把秘籍葵花宝典泄漏了。

（12）Spring Cloud Sleuth：日志收集工具包，封装了Dapper和log-based追踪以及Zipkin和HTrace操作，为SpringCloud应用实现了一种分布式追踪解决方案。

（13）Spring Cloud Data Flow：

1）Data flow 是一个用于开发和执行大范围数据处理其模式包括ETL，批量运算和持续运算的统一编程模型和托管服务。

2）对于在现代运行环境中可组合的微服务程序来说，Spring Cloud data flow是一个原生云可编配的服务。使用Spring Cloud data flow，开发者可以为像数据抽取，实时分析，和数据导入/导出这种常见用例创建和编配数据通道（data pipelines）。

3）Spring Cloud data flow 是基于原生云对 spring XD的重新设计，该项目目标是简化大数据应用的开发。Spring XD 的流处理和批处理模块的重构分别是基于 spring boot的stream 和 task/batch 的微服务程序。这些程序现在都是自动部署单元而且他们原生的支持像 Cloud Foundry、Apache YARN、Apache Mesos和Kubernetes 等现代运行环境。

4）Spring Cloud data flow 为基于微服务的分布式流处理和批处理数据通道提供了一系列模型和最佳实践。

（14）Spring Cloud Stream：Spring Cloud Stream是创建消息驱动微服务应用的框架。Spring Cloud Stream是基于spring boot创建，用来建立单独的／工业级spring应用，使用spring integration提供与消息代理之间的连接。数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。一个业务会牵扯到多个任务，任务之间是通过事件触发的，这就是Spring Cloud stream要干的事了。

（15）Spring Cloud Task：Spring Cloud Task 主要解决短命微服务的任务管理，任务调度的工作，比如说某些定时任务晚上就跑一次，或者某项数据分析临时就跑几次。

（16）Spring Cloud Zookeeper：ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。操作Zookeeper的工具包，用于使用zookeeper方式的服务发现和配置管理，抱了Zookeeper的大腿。

（17）Spring Cloud Connectors：Spring Cloud Connectors 简化了连接到服务的过程和从云平台获取操作的过程，有很强的扩展性，可以利用Spring Cloud Connectors来构建你自己的云平台。便于云端应用程序在各种PaaS平台连接到后端，如：数据库和消息代理服务。

（18）Spring Cloud Starters：Spring Boot式的启动项目，为Spring Cloud提供开箱即用的依赖管理。

（19）Spring Cloud CLI：基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。

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

当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。

Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在Eureka 服务器上注册并通过调用Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理。

16. 使用Spring Cloud有什么优势？

16.1 优点：

1、服务拆分粒度更细，有利于资源重复利用，有利于提高开发效率

2、可以更精准的制定优化服务方案，提高系统的可维护性

3、微服务架构采用去中心化思想，服务之间采用Restful等轻量级通讯，比ESB更轻量

4、适于互联网时代，产品迭代周期更短

16.2 缺点：

1、微服务过多，治理成本高，不利于维护系统

2、分布式系统开发的成本高（容错，分布式事务等）对团队挑战大

总的来说优点大过于缺点，目前看来SpringCloud是一套非常完善的分布式框架，目前很多企业开始用微服务、Spring Cloud 的优势是显而易见的。

17. 什么是 Spring Cloud？

17.1 什么是SpringCloud

是基于SpringBoot的一整套实现微服务的框架。他提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。

17.2 Spring Cloud和Spring Boot的关系：

（1）Spring Boot 是 Spring 的一套快速配置脚手架，可以基于Spring Boot 快速开发单个微服务;

（2）Spring Cloud是基于Spring Boot实现的；

（3）Spring Boot专注于快速、方便集成的单个微服务个体，Spring Cloud关注全局的服务治理框架；

（4）Spring Boot使用了约束优于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置 , Spring Cloud很大的一部分是基于Spring Boot来实现，Spring Boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开Spring Boot，属于依赖的关系。

（5）SpringBoot在SpringClound中起到了承上启下的作用，如果你要学习SpringCloud必须要学习SpringBoot。

17.3 Spring Cloud特点

（1）分布式/版本化配置

（2）服务注册和发现

（3）路由

（4）service - to - service调用

（5）负载均衡

（6）断路器

（7）分布式消息传递

常见面试题和答案汇总（3）：SpringCloud

1. Eureka和zookeeper都可以提供服务注册与发现的功能，两者的区别