Java面试问题汇总(SpringCloud、Dubbo+Zookeeper)

1.Spring Cloud 核心功能是什么？

Spring Cloud 主要提供了如下核心的功能：

Distributed/versioned configuration 分布式/版本化的配置管理
Service registration and discovery 服务注册与服务发现
Routing 路由
Service-to-service calls 端到端的调用
Load balancing 负载均衡
Circuit Breakers 断路器
Global locks 全局锁
Leadership election and cluster state 选举与集群状态管理
Distributed messaging 分布式消息

2.Spring Cloud 有哪些组件？

由于 Spring Cloud Netflix 要进入维护模式，下面是一些可以替代组件

	Netflix	阿里	其它
注册中心	Eureka	Nacos	Zookeeper、Consul、Etcd
熔断器	Hystrix	Sentinel	Resilience4j
网关	Zuul	暂无	Spring Cloud Gateway
负载均衡	Ribbon	Dubbo	`spring-cloud-loadbalancer`

3.Spring Cloud 和 Spring Boot 的区别和关系？

Spring Boot 专注于快速方便的开发单个个体微服务。
Spring Cloud 是关注全局的微服务协调整理治理框架以及一整套的落地解决方案，它将 Spring Boot 开发的一个个单体微服务整合并管理起来，为各个微服务之间提供：配置管理，服务发现，断路器，路由，微代理，事件总线等的集成服务。
Spring Boot 可以离开 Spring Cloud 独立使用，但是 Spring Cloud 离不开 Spring Boot ，属于依赖的关系。

总结：

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

4.有哪些可以作为Spring Cloud的注册中心

在 Spring Cloud 中，能够使用的注册中心，还是比较多的，如下：

spring-cloud-netflix-eureka-server 和 spring-cloud-netflix-eureka-client ，基于 Eureka 实现。
spring-cloud-alibaba-nacos-discovery ，基于 Nacos 实现。
spring-cloud-zookeeper-discovery ，基于 Zookeeper 实现。

5.SpringCloud的注册和发现流程，以Eureka为注册中心

服务启动时会生成服务的基本信息对象InstanceInfo，然后再启动时注册到服务治理中心
服务注册完成后，会从服务治理中心拉取所有的服务信息，缓存在本地
之后服务会根据配置的指定间隔时间发送一个心跳信息，续约服务
如果服务治理中心在90s内没有收到一个服务的续约，就会认为服务已经挂了，会把服务注册信息删除
服务停止前，会主动发送一个停止请求，服务治理中心会删除这个服务的信息
如果Eureka收到的心跳包不足正常值的85%（可配置）就会进入自我保护模式，这种模式，Eureka不会删除任何服务信息

6.说说Spring Cloud 的负载均衡,为什么要负载均衡

简单来说，随着业务的发展，单台服务无法支撑访问的需要，于是搭建多个服务形成集群。那么随之要解决的是，每次请求，调用哪个服务，也就是需要进行负载均衡。

目前负载均衡有两种模式：

客户端模式
服务端模式

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

7.Ribbon 有哪些负载均衡算法？

RoundRobinRule：默认轮询的方式
RandomRule：随机方式
WeightedResponseTimeRule：根据响应时间来分配权重的方式，响应的越快，分配的值越大。
BestAvailableRule：选择并发量最小的方式
RetryRule：在一个配置时间段内当选择server不成功，则一直尝试使用subRule的方式选择一个可用的server
ZoneAvoidanceRule：根据性能和可用性来选择。
AvailabilityFilteringRule：过滤掉那些因为一直连接失败的被标记为circuit tripped的后端server，并过滤掉那些高并发的的后端server（active connections 超过配置的阈值）

8.Ribbon 是怎么和 Eureka 整合的？

首先，Ribbon 会从 Eureka Client 里获取到对应的服务列表。
然后，Ribbon 使用负载均衡算法获得使用的服务。
最后，Ribbon 调用对应的服务。

9.Feign 实现原理

Feign的一个关键机制就是使用了动态代理。咱们一起来看看下面的图，结合图来分析：

首先，如果你对某个接口定义了 @FeignClient 注解，Feign 就会针对这个接口创建一个动态代理。
接着你要是调用那个接口，本质就是会调用 Feign 创建的动态代理，这是核心中的核心。
Feig n的动态代理会根据你在接口上的 @RequestMapping 等注解，来动态构造出你要请求的服务的地址。
最后针对这个地址，发起请求、解析响应。

10.Feign 和 Ribbon 的区别

启动类用的注解不同。
- Ribbon 使用的是 @RibbonClient 。
- Feign 使用的是 @EnableFeignClients 。
服务的指定位置不同。
- Ribbon 是在 @RibbonClient 注解上设置。
- Feign 则是在定义声明方法的接口中用 @FeignClient 注解上设置。
调使用方式不同。
- Ribbon 需要自己构建 Http 请求，模拟 Http 请求而后用 RestTemplate 发送给其余服务，步骤相当繁琐。
- Feign 采使用接口的方式，将需要调使用的其余服务的方法定义成声明方法就可，不需要自己构建 Http 请求。不过要注意的是声明方法的注解、方法签名要和提供服务的方法完全一致。

11.Hystrix 隔离策略？

Hystrix 有两种隔离策略：

线程池隔离
信号量隔离

实际场景下，使用线程池隔离居多，因为支持超时功能。

12.什么是 Hystrix 断路器？

Hystrix 断路器通过 HystrixCircuitBreaker 实现。

HystrixCircuitBreaker 有三种状态：

CLOSED ：关闭
OPEN ：打开
HALF_OPEN ：半开

其中，断路器处于 OPEN 状态时，链路处于非健康状态，命令执行时，直接调用回退逻辑，跳过正常逻辑。

HystrixCircuitBreaker 状态变迁如下图：

红线：初始时，断路器处于CLOSED状态，链路处于健康状态。当满足如下条件，断路器从CLOSED变成OPEN
状态：
- 周期( 可配，HystrixCommandProperties.default_metricsRollingStatisticalWindow = 10000 ms )内，总请求数超过一定量( 可配，HystrixCommandProperties.circuitBreakerRequestVolumeThreshold = 20 ) 。
错误请求占总请求数超过一定比例( 可配，HystrixCommandProperties.circuitBreakerErrorThresholdPercentage = 50% ) 。
绿线：断路器处于 OPEN 状态，命令执行时，若当前时间超过断路器开启时间一定时间( HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds = 5000 ms )，断路器变成 HALF_OPEN 状态，尝试调用正常逻辑，根据执行是否成功，打开或关闭熔断器【蓝线】。

13.为什么要网关服务？

使用网关服务，我们实现统一的功能：

动态路由
灰度发布
健康检查
限流
熔断
认证: 如数支持 HMAC, JWT, Basic, OAuth 2.0 等常用协议
鉴权: 权限控制，IP 黑白名单，同样是 OpenResty 的特性
可用性
高性能

14.熔断和降级区别

熔断是下层服务一旦产生故障就断掉；降级需要对服务进行分级，把产生故障的服务丢掉，换一个轻量级的方案。

15.springcloud跟dubbo的区别

	Dubbo	SpringCloud
服务注册中心	Zookeeper	Spring Cloud Netfilx Eureka
服务调用方式	RPC	REST API
服务监控	Dubbo-monitor	Spring Boot Admin
断路器	不完善	Spring Cloud Netfilx Hystrix
服务网关	无	Spring Cloud Netfilx Zuul
分布式配置	无	Spring Cloud Config
服务跟踪	无	Spring Cloud Sleuth
消息总栈	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task

最大区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。
严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。

解决的问题域不一样：Dubbo的定位是一款RPC框架，Spring Cloud的目标是微服务架构下的一站式解决方案
4.Dubbo 和 SpringCloud 对比
Distributed/versioned configuration （分布式/版本控制配置）
Service registration and discovery（服务注册与发现）
Routing（路由）
Service-to-service calls（服务到服务的调用）
Load balancing（负载均衡配置）
Circuit Breakers（断路器）
Distributed messaging（分布式消息管理）