【springcloud】常见面试题总结

最新推荐文章于 2024-08-12 22:44:57 发布

liu1002880404

最新推荐文章于 2024-08-12 22:44:57 发布

阅读量517

点赞数 1

分类专栏： sringcloud系统整理

本文链接：https://blog.csdn.net/liuerchong/article/details/108175655

版权

sringcloud系统整理专栏收录该内容

61 篇文章 32 订阅

订阅专栏

【springcloud】常见面试题总结

1.springcloud与dubbo的区别？

　　1.1 springcloud与dubbo支持技术栈比较

	Dubbo	Spring Cloud
服务注册中心	Zookeeper	Spring Cloud Netflix Eureka等
服务调用方式	RPC	REST API
服务网关	无	Spring Cloud Netflix Zuul，gateway
断路器	不完善	Spring Cloud Netflix Hystrix
分布式配置	无	Spring Cloud Config
服务跟踪	无	Spring Cloud Sleuth
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task
……	……	……

　　1.2 springcloud和dubbo的最大区别：springcloud抛弃了dubbo的rpc通信，采用的是基于http的rest方式。

　　1.3 springboot与dubbo就相当于品牌机与组装机的区别。

　　1.4 springcloud与dubbo的社区活跃度对比。

二、整体比较

1、dubbo由于是二进制的传输，占用带宽会更少

2、springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大

3、dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决

4、springcloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级

5、dubbo的注册中心可以选择zk,redis等多种，springcloud的注册中心只能用eureka或者自研

2.ribbon的负载均衡策略

　　2.1 RoundRobinRule: 轮询策略，Ribbon以轮询的方式选择服务器，这个是默认值。所以示例中所启动的两个服务会被循环访问;

　　2.2 RandomRule: 随机策略，也就是说Ribbon会随机从服务器列表中选择一个进行访问;

　　2.3 BestAvailableRule: 最大可用策略，即先过滤出故障服务器后，选择一个当前并发请求数最小的;

　　2.4 WeightedResponseTimeRule: 带有加权的轮询策略，对各个服务器响应时间进行加权处理，然后在采用轮询的方式来获取相应的服务器;

　　2.5 AvailabilityFilteringRule: 可用过滤策略，先过滤出故障的或并发请求大于阈值的一部分服务实例，然后再以线性轮询的方式从过滤后的实例清单中选出一个;

　　2.6 ZoneAvoidanceRule: 区域感知策略，先使用主过滤条件（区域负载器，选择最优区域）对所有实例过滤并返回过滤后的实例清单，依次使用次过滤条件列表中的过滤条件对主过滤条件的结果进行过滤，判断最小过滤数（默认1）和最小过滤百分比（默认0），最后对满足条件的服务器则使用RoundRobinRule(轮询方式)选择一个服务器实例。

3.ribbon和feign的区别

　　3.1 启动类使用的注解不同，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。

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

　　3.3 调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。

Feign则是在Ribbon的基础上进行了一次改进，采用接口的方式，将需要调用的其他服务的方法定义成抽象方法即可，

不需要自己构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法完全一致。

4.ribbon、feign以及hystrix的超时、重试设置

　　4.1 ribbon的设置：

　　　　默认是没有超时，需开启，把ribbon.http.client.enabled设置为true。开启后，而如果不配超时时间，默认超时时间是1秒，超时后默认会重试一次。

　　　　做如下配置，以上配置最多会调用6次（（MaxAutoRetries+1）*（MaxAutoRetriesNextServer+1）），也就是最多会重试5次。

ribbon:

ReadTimeout: 2000

ConnectionTimeout: 2000

OkToRetryOnAllOperations: true

MaxAutoRetriesNextServer: 1 # 当前实例全部失败后可以换1个实例再重试

MaxAutoRetries: 2 # 在当前实例只重试2次

http:

client:

enabled: true

　　4.2 feign设置

　　　　feign默认的超时时间是1秒，重试1次。

　　4.3 hystrix设置

　　　　配置如下：

server:

port: 8002

eureka:

client:

serviceUrl:

defaultZone: http://localhost:5000/eureka/

spring:

application:

name: service-hystrix

feign:

hystrix:

enabled: true # 开启

hystrix:

command:

default:

execution:

isolation:

thread:

timeoutInMilliseconds: 10000 # 断路器的超时时间需要大于ribbon的超时时间，不然重试没有意义

ribbon:

ReadTimeout: 2000

ConnectionTimeout: 2000

OkToRetryOnAllOperations: true

MaxAutoRetriesNextServer: 1

MaxAutoRetries: 0

　　当超时并且重试也超时时，会执行降级逻辑，而不会报错。这里，断路器的超时时间需要大于ribbon的超时时间，不然重试没有意义。比如将一下设置去掉（默认值是1秒）或设置较低。

　　可以看到，第一次超时了并重试一次，第二次没有超时，但是页面已经显示error，执行降级逻辑，是因为远程调用的超时时间已经超过了断路器的超时时间，意思是第一次还没执行完就已经执行降级逻辑返回，虽然后台还在重试。

5.hystrix的隔离策略

　　5.1 隔离策略有两种：

　　　　线程隔离、信号量隔离。

　　5.2 隔离策略的区别

　　　　详见：https://blog.csdn.net/dengqiang123456/article/details/75935122

6.hystrix功能实现的具体方式

　　6.1 服务降级，设置超时时间

　　6.2 服务限流，通过隔离策略进行限流按制。

　　6.3 服务熔断：

　　　　6.3.1 熔断的三种状态：

1 2	`正常状态下，电路处于关闭状态(Closed)，如果调用持续出错或者超时，电路被打开进入熔断状态(Open)，后续一段时间内的所有调用都会被拒绝(Fail Fast)，<br>这个拒绝时间withCircuitBreakerSleepWindowInMilliseconds控制默认是5s` `一段时间以后，保护器会尝试进入半熔断状态(Half-Open)，允许少量请求进来尝试，如果调用仍然失败，则回到熔断状态，如果调用成功，则回到电路闭合状态;`

断路器

（1）hystrix.command.default.circuitBreaker.requestVolumeThreshold（当在配置时间窗口内达到此数量的失败后，进行短路。默认20个）

　　 For example, if the value is 20, then if only 19 requests are received in the rolling window (say a window of 10 seconds) the circuit will not trip open even if all 19 failed.

　　简言之，10s内请求失败数量达到20个，断路器开。

（2）hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds（短路多久以后开始尝试是否恢复，默认5s）

（3）hystrix.command.default.circuitBreaker.errorThresholdPercentage（出错百分比阈值，当达到此阈值后，开始短路。默认50%）
　　　　6.3.2 熔断机制简述：

1	当出现问题时，Hystrix会检查一个一定时长（图中为10s）的一个时间窗（window），在这个时间窗内是否有足够多的请求，如果有足够多的请求，是否错误率已经达到阈值，<br>如果达到则启动断路器熔断机制，这时再有请求过来就会直接到fallback路径。在断路器打开之后，<br>会有一个sleep window（图中为5s），每经过一个sleep window，当有请求过来的时候，断路器会放掉一个请求给remote 服务，<br>让它去试探下游服务是否已经恢复，如果成功，断路器会恢复到正常状态，让后续请求重新请求到remote 服务，否则，保持熔断状态。