Spring Cloud面试题

1、什么是Spring Cloud? 

Spring Cloud 流应用程序启动器是基于Spring Boot的Spring集成应用程序，提供与外部系统的集成。Spring Cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序。

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

使用Spring Boot开发分布式微服务时，我们面临以下问题

1.与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。
2.服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录的服务。

3、冗余-分布式系统中的冗余问题。

4.负载平衡-负载平衡改善垮多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处理单元，或磁盘驱动器的分布。

5.性能-问题由于各种运营开销导致的性能问题。

6.部署复杂性-Devops技能的要求。

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

当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化，手动更改属性可能会产生问题。Eureka服务注册和发现可以在这种情况下提供帮助。由于所有服务都在Eureka服务器上注册并通过调用Eureka服务器完成查找，因此无需处理服务地点的任何更改和处理。

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

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

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

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

6、什么是微服务

微服务架构师一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分为一组小的服务，每个服务运行在其独立的自己的进程中，服务之间相互协调，互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API），每个服务都围绕着具体的业务进行构建，并且能够被独立的构建在生成环境、类生成环境等。另外，应避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

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

熔断机制是应对雪崩效应的一种微服务链路保护机制。当某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点的微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在Spring Cloud框架里熔断机制通过Hystrix实现，Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内调用20次，如果失败，就会启动熔断机制。

服务降级，一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值，这样做，虽然水平下降，但好歹可用，比直接挂掉强。

Hystrix相关注解

@EnableHystrix ：开启熔断

@HystrixCommand(fallbackMethod=”XXX”)：声明一个失败回滚处理函数XXX ，当被注解的方法执行超时（默认是1000 毫秒），就会执行 fallback 函数，返回错误提示

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

Zookeeper 保证了 CP （ C ：一致性，P ：分区容错性）， Eureka 保证了 AP （ A ：高可用）

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

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

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

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

③、当网络稳定时，当前实例新的注册信息会被同步到其他节点。因此， Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper 那样使整个微服务瘫痪

9、RPC的实现原理

首先需要有处理网络链接通讯的模块，负责连接建立、管理和消息的传输。其次需要有编解码的模块，因为网络通讯都是传输的字节码，需要将我们使用的对象序列化和反序列化。剩下的就是客户端和服务器端的部分，服务器端暴露要开房的服务接口，客户调用服务接口的一个代理实现，这个代理实现负责收集数据、编码并传输给服务器然后等待返回结果。

10、微服务的优点和缺点？

优点：

1.每个服务直接足够内聚，代码容易理解

2.开发效率高，一个服务只做一件事，适合小团队开发

3.松耦合，有功能意义的服务。

4.可以用不同语言开发，面向接口编程。

5.易于第三方集成

6.微服务只是业务逻辑的代码，不会和html，css或其他界面结合。

7.可以灵活搭配，连接公共库/连接独立库

缺点：

1.分布式系统的责任性

2.多服务运维难度加大。

3.系统部署依赖，服务间通信成本，数据一致性，系统集成测试，性能监控。

11、spring cloud 和dubbo的区别

1.服务调用方式，dubbo是rpc  spring cloud 是Rest API

2.注册中心 Dubbo是zookeeper spring cloud 是eureka，也可以是zookeeper

3.服务网关，dubbo本身没有实现，只能通过其他第三方技术整合，springcloud有Zuul路由网关，作为路由服务器，进行消费者的请求分发，spring cloud支持断路器，与git完美集成配置文件支持版本控制，事务总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。

12、Rest和RPC对比

1.RPC主要的缺陷是服务提供方和调用方式之间的依赖太强，需要对每一个微服务进行接口的定义，并通过持续继承发布，严格版本控制才不会出现冲突。

2.REST是轻量级的接口，服务的提供和调用不存在代码之间的耦合，只需要一个约定进行规范。

13、你所知道的微服务技术栈？

维度 (springcloud)

服务开发： springboot spring springmvc

服务配置与管理 :Netfifix 公司的 Archaiusm , 阿里的 Diamond

服务注册与发现 :Eureka,Zookeeper

服务调用 :Rest RPC gRpc

服务熔断器 :Hystrix

服务负载均衡 :Ribbon Nginx

服务接口调用 :Fegin

消息队列 :Kafka Rabbitmq activemq

服务配置中心管理 :SpringCloudConfifig

服务路由（ API 网关） Zuul

事件消息总线 :SpringCloud Bus

14、微服务之间是如何独立通讯的？

1.远程调用，比如feign调用，直接通过远程过程调用来访问别的service。

2.消息中间件

15、springcloud如何实现服务的注册？

1.服务发布时，指定对应的服务名，将服务注册到注册中心（eureka zookeeper）

2.注册中心加@EnableEurekaServer，服务用@EnableDiscoveryClient,然后用ribbon或feign进行服务之间的调用发现。

16、Eureka和Zookeeper区别

1.Eureka取CAP（一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾）的AP，注重可用性，Zookeeper取CAP的cp注重一致性。

2.zookeeper在选举期间注册服务瘫痪，虽然服务最终会恢复名单选举期间不可用。

3.eureka的自我保护机制，会导致一个结果就是不会在注册列表移除因长时间没收到心跳而过期的服务。依然能接受新服务的注册和查询请求，但不会被同步到其他节点。不会服务瘫痪。

4。zookeeper有Leader和Follower角色，Eureka各个节点平等。

5.zookeeper采用过半数存活原则，Eureka采用自我保护机制解决分区问题。

6.eureka本质是一个工程，Zookeeper只是一个进程。

17、eureka自我保护机制是什么？

当Eureka Server节点在短时间内丢了过多实例的连接时（比如网络故障或频繁启动关闭客户端）节点会进入自我保护模式，保护注册信息，不在删除注册数据，故障恢复时，自动退出自我保护模式。

18、什么是Ribbon?

ribbon是一个负载均衡客户端，可以很好的控制htt和tcp的一些行为。feign默认集成了ribbon.

19、什么是feigin？它的优点是什么？

1.feign采用的是基于接口的注解

2.fegin整合了ribbon，具有负载均衡的能力，

3.整合了Hystrix，具有熔断的能力

使用：

1.添加pom依赖

2.启动类添加@EnableFeignClients

3.定义一个接口@FeignClient（name="XXX"）指定调用哪个服务

20、Ribbon和Feign的区别？

1.Ribbon都是调用其他服务的，但方式不同。

2.启动类注解不同，Ribbon是@RibbonClient feign的是@EnableFeignClients

3.服务指定的位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。

4.调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤箱单繁琐。Feign需要将调用的方法定义成抽象方法即可。

21、什么是Spring Cloud Bus？

spring cloud bus将分布式的节点用轻量的消息代理连接起来，它可以用于广播配置文件的更改或者服务直接的通讯，也可以用于监控。

如果修改了配置文件，发送一次请求，所有的客户端便会重新读取配置文件。

22、作为服务注册中心，Eureka比Zookeeper好在哪里？

1.Eureka保重的是可用性和分区容错性，Zookeeper保证的是一致性和分区容错性。

2.Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障。而不会像zookeeper那样使整个注册服务瘫痪。

23、什么是Ribbon负载均衡？

1.Spring cloud Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具。

2. Ribbon 客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer （简称 LB ）后面所有的机器， Ribbon 会自动的帮助你基于某种规则（如简单

轮询，随机连接等）去连接这些机器。我们也很容易使用 Ribbon 实现自定义的负载均衡算法。

24、Ribbon负载均衡能干什么？

1.将用户的请求平摊的分配到多个服务上

2.集中式LB 即在服务的消费方和提供方之间使用独立的 LB 设施 ( 可以是硬件，如 F5, 也可以是软件，如 （nginx), 由该设施负责把访问请求通过某种策略转发至服务的提供方；

3.进程内LB 将 LB 逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。

注意： Ribbon 就属于进程内 LB ，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址

 25、什么是zuul路由网关

1.Zuul 包含了对请求的路由和过滤两个最主要的功能 : 其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础、

2.Zuul 和 Eureka 进行整合，将 Zuul 自身注册为 Eureka 服务治理下的应用，同时从 Eureka 中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。

 注意： Zuul服务最终还是会注册进Eureka 提供=代理+路由+过滤三大功能。

26、分布式配置中心能干嘛？

1. 集中管理配置文件不同环境不同配置，动态化的配置更新，分环境部署比如

dev/test/prod/beta/release

2. 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息

3. 当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置将配置信息以 REST 接口的形式暴露

27、Hystrix相关注解

@EnableHystrix ：开启熔断

@HystrixCommand(fallbackMethod=”XXX”) ：声明一个失败回滚处理函数 XXX ，当被注解的方法执行超时（默认是1000 毫秒），就会执行 fallback 函数，返回错误提示。