SpringCloud面试题

一. 谈谈你对微服务的理解

     微服务就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程，类似进程的概念,能够自行单独启动或销毁，拥有自己独立的数据库。微服务强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用，狭义的看，可以看做IDEA中的一个个微服务工程，或者moudel.

二.  微服务的优缺点？说说在开发项目中遇到的坑。

优点：

      1. 每个服务足够内聚，足够小，能聚焦一个指定业务功能。

      2. 开发简单，开发效率提高，一个服务专一的只干一件事， 易于开发和维护，局部修改容易部署。

      3. 微服务是松耦合的，是具有功能意义的服务，无论是在开发阶段或部署阶段都是独立运行的，启动较快。

      4. 技术栈不受限，微服务能使用不同的语言开发。

      5. 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如bamboo，Hudson

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

      7. 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库，搭配灵活。

缺点：

      1. 运维要求较高(多服务运维难度，随着服务的增加，运维的压力也在增大)

      2. 分布式的复杂性

      3. 接口调整成本高

      4. 系统部署依赖，系统集成测试，性能监控

三. 什么是springcloud？？

     springcloud流应用程序启动器是基于SpringBoot的spring集成应用程序，提供与外部系统的集成。

四. springcloud和dubbo的区别？

    1. 服务调用方式：dubbo是RPC  ，springcloud是Rest API

    2. 注册中心：dubbo是Zookeeper，springcloud是Eureka，也可以是Zookeeper

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

五. Rest和RPC的对比

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

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

六. 你所知道的微服务技术栈有哪些？

    维度(springCloud)

    服务开发：springboot   SpringMVC

    服务配置与管理：Netflix公司的Archaiusm,阿里的Diamond

    服务注册与发现：Eureka，Zookeeper

    服务调用：Rest RPC gRpc

    服务熔断器：Hystrix

    服务负载均衡：Ribbon Nginx

    服务接口调用：Feign

    消息队列：RabbitMQ，activeMQ，Kafka

    服务配置中心管理：SpringCloud Config

    服务路由：Zuul(API网关)

    事件消息总线：SpringCloud Bus

七. 什么是负载均衡

      LB，负载均衡(Load Balance)，是微服务架构中经常使用的一种技术。负载均衡是我们处理高并发，环节网络压力和进行服务端扩容的重要手段之一，简单的说就是将用户的请求平摊的分配到多个服务上，从而实现系统的高可用(HA)性集群。负载均衡旨在优化资源使用，最大吞吐量，最小响应时间并避免任何单一资源的过载。使用多个组件进行负载均衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务进程。

八. 微服务之间是如何独立通讯的？

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

     2.消息中间件

九. springcloud如何实现服务的注册?

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

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

十. Eureka和Zookeeper区别

      1.Eureka取CAP的AP，注重可用性，Zookeeper取CAP的CP注重一致性。

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

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

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

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

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

详解参考博客 https://blog.csdn.net/duan196_118/article/details/104180790

十一. eureka自我保护机制是什么?

       默认情况下，如果EurekaServer在一定时间内没有收到某个服务实例的心跳，EurekaServer将会注销该实例(默认90秒)。但是当网络分区故障发生时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了，因为微服务本身是健康的，此时本不应该注销这个微服务。Eureka通过"自我保护模式"来解决这个问题。当Eureka节点在短时间内丢失过多客户端时(可能发生了网络分区故障)，那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据(不会销毁任何微服务)。当网络故障恢复后，该EurekaServer节点会自动退出自我保护模式。

      在自我保护模式中，EurekaServer会保护注册表中的信息，不再销毁任何服务实例。当它收到心跳数重新恢复到阈值以上时该EurekaServer节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例(好死不如赖活着)。

综上：

       当Eureka Server 节点在短时间内丢失了过多实例的连接时（比如网络故障或频繁启动关闭客户端）节点会进入自我保护模式，保护注册信息，不再删除注册数据，故障恢复时，自动退出自我保护模式。自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务，也不盲目注销任何健康的微服务，使用自我保护模式，可以让Eureka集群更加的健壮，稳定。

在springcloud中，可以使用eureka.server.enable-self-preservation = false禁用自我保护模式。

 

十二.  什么是服务熔断？什么是服务降级?

      服务直接的调用，比如在高并发情况下出现进程阻塞，导致当前线程不可用，慢慢的全部线程阻塞，导致服务器雪崩。

      服务熔断：相当于保险丝，出现某个异常，直接熔断整个服务，而不是一直等到服务超时。是应对雪崩效应的一种微服务链路保护机制。通过维护一个自己的线程池，当线程到达阈值的时候就启动服务降级，如果其他请求继续访问就直接返回fallback的默认值。

服务降级：整体的资源快不够了，忍痛将某些服务先关掉，待渡过难关再进行开启。

十三. 什么是Ribbon？

     ribbon是一个客户端负载均衡的工具，可以很好的控制http和tcp的一些行为。feign默认集成了ribbon。简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简而言之，就是在配置文件中列出Load Balancer (LB)后面所有的机器，Ribbon会自动的帮助你基于某种规则去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。

十四.  什么是feigin？它的优点是什么？

   Feign是一个声明式WebService客户端。使用Feign能让编写Web Service客户端更加简单，它的使用方法就是定义一个接口并在上面添加注解，SpringCloud对Feign进行了封装，使其支持了SpringMVC标准注解和HTTPMessageConverters。Feign可以与Eureka和Ribbon组合使用以支持负载均衡。

    1.feign采用的是基于接口的注解，使编写java Http客户端变得更容易

    2.feign整合了ribbon，具有负载均衡的能力，简化了开发

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

使用:

    1.添加pom依赖。

    2.启动类添加@EnableFeignClients

   3.定义一个接口@FeignClient(name=“xxx”)指定调用哪个服务

 

十五. Ribbon和Feign的区别

  Ribbon添加maven依赖 spring-starter-ribbon 使用@RibbonClient(value="服务名称")使用RestTemplate调用远程服务对应的方法。

  feign添加maven依赖 spring-starter-feign服务提供对外接口 ，调用方法使用在接口上加注解@FeignClient("指定服务名")

区别：

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

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

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

    4.调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。Feign需要将调用的方法定义成抽象方法即可，需要注意的是抽象方法的注解，方法签名要和提供服务的方法完全一致。

十六. 什么是Spring Cloud Bus?

     spring cloud bus 将分布式的节点用轻量的消息代理连接起来，它可以用于广播配置文件的更改或者服务直接的通讯，也可用于监控。如果修改了配置文件，发送一次请求，所有的客户端便会重新读取配置文件。

使用:

      1.添加依赖

      2.配置rabbimq

十七. springcloud断路器作用?

    当一个服务调用另一个服务由于网络原因或自身原因出现问题，调用者就会等待被调用者的响应 当更多的服务请求到这些资源导致更多的请求等待，发生连锁效应（雪崩效应）。

断路器有完全打开状态:    一段时间内达到一定的次数无法调用并且多次监测没有恢复的迹象 断路器完全打开 那么下次请求                                          就不会请求到该服务

半开:    短时间内 有恢复迹象 断路器会将部分请求发给该服务，正常调用时 断路器关闭

关闭：  当服务一直处于正常状态 能正常调用

十八. 什么是SpringCloudConfig?

      在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，一是config server，二是config client。

使用：

      1、添加pom依赖

      2、配置文件添加相关配置

      3、启动类添加注解@EnableConfigServer

十九. 为什么要使用路由网关?

      1.作为分布式架构中调用微服务统一入口，方便前端调用

      2. 集中处理权限问题等

二十. 架构?

在微服务架构中，需要几个基础的服务治理组件，包括服务注册与发现、服务消费、负载均衡、断路器、智能路由、配置管理等，由这几个基础组件相互协作，共同组建了一个简单的微服务系统

在Spring Cloud微服务系统中，一种常见的负载均衡方式是，客户端的请求首先经过负载均衡（zuul、Ngnix），再到达服务网关（zuul集群），然后再到具体的服。，服务统一注册到高可用的服务注册中心集群，服务的所有的配置文件由配置服务管理，配置服务的配置文件放在git仓库，方便开发人员随时改配置。

二十一.什么是Hystrix?

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
防雪崩利器，具备服务降级，服务熔断，依赖隔离，监控（Hystrix Dashboard）
“断路器”本身是一种开关装置，当某个服务单元发生故障后，通过断路器的故障监控(类似熔断保险丝)，向调用方返回一个符合预期的，可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。