SpringCloud面试题

最近是不是有好多面试的小伙伴呀，小编就总结一下关于SpringCloud的面试题：

什么是 Spring Cloud？

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

什么是微服务？

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

通俗的来讲：

微服务就是一个独立的职责单一的服务应用程序。在 intellij idea 工具里面就是用maven开发的一个个独立的module，具体就是使用springboot 开发的一个小的模块，处理单一专业的业务逻辑，一个模块只做一个事情。

微服务强调的是服务大小，关注的是某一个点，具体解决某一个问题/落地对应的一个服务应用，可以看做是idea 里面一个 module。

使用 Spring Cloud 解决什么问题？

Spring Cloud规范及实现意图要解决的问题其实就是微服务架构实施过程中存在的⼀些问题，⽐如微服务架构中的服务注册发现问题、⽹络问题（⽐如熔断场景）、统⼀认证安全授权问题、负载均衡问题、链路追踪等问题.

Spring Cloud 和dubbo区别?

（1）服务调用方式 dubbo是RPC springcloud是 Rest Api

（2）注册中心,dubbo 是zookeeper springcloud是eureka，也可以是zookeeper

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

SpringBoot和SpringCloud的区别？

SpringBoot专注于快速方便的开发单个个体微服务。

SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务。

SpringBoot可以离开SpringCloud独立使用开发项目， 但是SpringCloud离不开SpringBoot ，属于依赖的关系.

SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。

Spring Cloud 的核心组件有哪些？

Eureka：服务注册于发现。Feign：基于动态代理机制，根据注解和选择的机器，拼接请求 url 地址，发起请求。Ribbon：实现负载均衡，从一个服务的多台机器中选择一台。Hystrix：提供线程池，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。Zuul：网关管理，由 Zuul 网关转发请求给对应的服务

 Ereka自我保护机制是什么?

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

自我保护机制的工作机制是：如果在15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制，此时会出现以下几种情况：

1.Eureka Server不再从注册列表中移除，因为长时间没收到心跳而应该过期的服务。

2.Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。

3.当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。

因此Eureka Server可以很好的应对因网络故障导致部分节点失联的情况，而不会像Zookeeper那样如果有一半不可用的情况会导致整个集群不可用而变成瘫痪。

 为什么会有自我保护机制？

默认情况下，如果Eureka Server在一定时间内（默认90秒）没有接收到某个微服务实例的心跳，Eureka Server将会移除该实例。但是当网络分区故障发生时，微服务与Eureka Server之间无法正常通信，而微服务本身是正常运行的，此时不应该移除这个微服务，所以引入了自我保护机制。

 常用的服务注册中心有：Eureka、Nacos、Zookeeper、Consul等组件。

Eureka基础架构

Eureka包含两个组件：Eureka Server和Eureka Client，Eureka Client是一个Java客户端，用于简化与Eureka Server的交互；

Eureka Server提供服务发现的能力。各个微服务启动时，会通过Eureka Client向Eureka Server 进行注册自己的信息（例如网络信息），Eureka Server会存储该服务的信息。

 Eureka交互流程及原理

 

1.图中us-east-1c、us-east-1d，us-east-1e代表不同地区，也就是不同的机房。

2.图中每一个Eureka Server都是一个集群。

3.图中Application Service作为服务提供者向Eureka Server中注册服务，Eureka Server接受到注册事件会在集群和分区中进行数据同步，Application Client作为消费端（服务消费者）可以从Eureka Server中获取到服务注册信息，进行服务调用。

4.微服务启动后，会周期性地向Eureka Server发送心跳（默认周期为30秒）以续约自己的信息。

5.Eureka Server在一定时间内没有接收到某个微服务节点的心跳，Eureka Server将会注销该微服务节点（默认90秒）。

6.每个Eureka Server同时也是Eureka Client，多个Eureka Server之间通过复制的方式完成服务注册列表的同步。

7.Eureka Client会缓存Eureka Server中的信息。即使所有的Eureka Server节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者。

Eureka通过心跳检测、健康检查和客户端缓存等机制，提高系统的灵活性、可伸缩性和高可用性。

 Nacos介绍 

Dynamic Naming and Configuration Service，简称Nacos。是阿⾥巴巴开源的⼀个针对微服务架构中服务发现，配置管理和服务管理的平台。

Nacos就是注册中⼼ + 配置中⼼的组合（Nacos = Eureka + Config + Bus）。

 关于负载均衡

 Ribbon是Netfix发布的负载均衡器。Eureka一般配合Riboon进行使用，Ribbon利用从Eureka中读取到服务信息，在调用服务提供者提供服务商，会根据一定的算法进行负载。

 

 Ribbon负载策略

负载均衡策略	类名
轮询策略	RoundRobinRule
随机策略	RandomRule
重试策略	RetryRule
最小连接数策略	BestAvailableRule
可用过滤策略	AvailabilityFilteringRule
区域权衡策略 (默认策略)	ZoneAvoidanceRule