这些springCloud的问题你知道吗？

关注

原创 2022-04-09 09:06:51 2.5k 阅读 AI 写同款· GEO 优化 ›

【SpringCloud Alibaba-OSS整合问题】 SpringCloud-Alibaba版本：2021.0.5.0。SpringCloud版本：2021.0.5。SpringBoot版本：2.6.13。，不引入会报以下错误，具体可以参考。阅读详情

Eureka和Zookeeper区别？

问题回答

在分布式领域有一个很著名的CAP定理：C：数据一致性。A：服务可用性。P：分区容错性（服务对网络分区故障的容错性）。
Zookeeper取CAP的CP注重一致性，在可用性方面不太好，假如master节点故障，剩余节点会重新leader选举，选举leader的时间太长30～120s，选举期间整个集群都不可用，这就导致在选举期间注册服务瘫痪，漫长选举导致注册不可用，不能容忍。
Eureka看明白了这一点，因此在设计时就优先保证可用性。取CAP的AP，注重可用性。Eureka各个节点都是平等的，只要有一台Eureka还在就能保证注册服务可用（保证可用性），只不过可能查询到的不是最新的。
eureka的自我保护机制，会导致一个结果就是不会再从注册列表移除因长时间没收到心跳而过期的服务。依然能接受新服务的注册和查询请求，但不会被同步到其他节点（保证当前节点可用），当网络稳定时，当前实例新的注册信息会被同步到其它节点中。也就是，不容易瘫痪。
Zookeeper有Leader和Follower角色，Eureka各个节点平等。
Zookeeper采用过半数存活原则，Eureka采用自我保护机制解决分区问题。
eureka本质是一个工程，Zookeeper只是一个进程。
dubbo默认使用zookeeper，spring cloud默认使用eureka。

简要回答

Zookeeper注重一致性。Eureka注重可用性。
Zookeeper有Leader和Follower角色，Eureka各个节点平等。
Zookeeper采用过半数存活原则，Eureka采用自我保护机制。
Eureka是吸取Zookeeper问题的经验，先保证可用性。
dubbo默认使用zookeeper，spring cloud默认使用eureka。

eureka自我保护机制是什么?

问题答案

Eureka在运行期间会统计心跳失败的比例，在15分钟内是否低于85%,如果出现了低于的情况，Eureka Server会将当前的实例注册信息保护起来，同时提示一个警告，表明进入了保护模式
一旦进入保护模式，Eureka Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据。也就是不会注销任何微服务。
我们在开发测试阶段，需要频繁地重启发布，如果触发了保护机制，则旧的服务实例没有被删除，这时请求有可能跑到旧的实例中，而该实例已经关闭了，这就导致请求错误，影响开发测试。所以，在开发测试阶段，我们可以把自我保护模式关闭，只需在eureka server配置文件中加上如下配置即可：

 eureka.server.enable-self-preservation=false

自我保护模式可以让集群更加健壮。故障恢复时，自动退出自我保护模式。
生产环境，不会频繁重启，所以，一定要把自我保护机制打开，否则网络一旦中断，就无法恢复。

简要记忆

Eureka在运行期间根据心跳失败比例决定是否进入保护模式。
保护模式下，会保护服务注册表，不能删除，不会注销。
开发阶段，我们最好关闭。生产环境选择打开。

hystrix配置你了解哪些？

问题回答

所有配置分为7类，一共60多个。
印象比较深刻有是否开启熔断器、是否开启fallback功能、是否开启请求缓存功能，他们默认都是true。
我们绝大多数情况使用默认配置即可。

下面是他的所有配置

# Execution相关的属性的配置：
 
 hystrix.command.default.execution.isolation.strategy 隔离策略，默认是Thread, 可选Thread｜Semaphore
 
 hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 命令执行超时时间，默认1000ms
 
 hystrix.command.default.execution.timeout.enabled 执行是否启用超时，默认启用true
 
 hystrix.command.default.execution.isolation.thread.interruptOnTimeout发生超时是是否中断，默认true
 
 hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests 最大并发请求数，默认10，该参数当使用ExecutionIsolationStrategy.SEMAPHORE策略时才有效。如果达到最大并发请求数，请求会被拒绝。理论上选择semaphore size的原则和选择thread size一致，但选用semaphore时每次执行的单元要比较小且执行速度快（ms级别），否则的话应该用thread。semaphore应该占整个容器（tomcat）的线程池的一小部分。
 
 # Fallback相关的属性
 这些参数可以应用于Hystrix的THREAD和SEMAPHORE策略
 
 hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests 如果并发数达到该设置值，请求会被拒绝和抛出异常并且fallback不会被调用。默认10
 hystrix.command.default.fallback.enabled 当执行失败或者请求被拒绝，是否会尝试调用hystrixCommand.getFallback() 。默认true
 
 # Circuit Breaker相关的属性
 
 hystrix.command.default.circuitBreaker.enabled 用来跟踪circuit的健康性，如果未达标则让request短路。默认true
 
 hystrix.command.default.circuitBreaker.requestVolumeThreshold 一个rolling window内最小的请求数。如果设为20，那么当一个rolling window的时间内（比如说1个rolling window是10秒）收到19个请求，即使19个请求都失败，也不会触发circuit break。默认20
 
 hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds 触发短路的时间值，当该值设为5000时，则当触发circuit break后的5000毫秒内都会拒绝request，也就是5000毫秒后才会关闭circuit。默认5000
 
 hystrix.command.default.circuitBreaker.errorThresholdPercentage错误比率阀值，如果错误率>=该值，circuit会被打开，并短路所有请求触发fallback。默认50
 
 hystrix.command.default.circuitBreaker.forceOpen 强制打开熔断器，如果打开这个开关，那么拒绝所有request，默认false
 
 hystrix.command.default.circuitBreaker.forceClosed 强制关闭熔断器 如果这个开关打开，circuit将一直关闭且忽略circuitBreaker.errorThresholdPercentage
 
 #Metrics相关参数
 
 hystrix.command.default.metrics.rollingStats.timeInMilliseconds 设置统计的时间窗口值的，毫秒值，circuit break 的打开会根据1个rolling window的统计来计算。若rolling window被设为10000毫秒，则rolling window会被分成n个buckets，每个bucket包含success，failure，timeout，rejection的次数的统计信息。默认10000
 
 hystrix.command.default.metrics.rollingStats.numBuckets 设置一个rolling window被划分的数量，若numBuckets＝10，rolling window＝10000，那么一个bucket的时间即1秒。必须符合rolling window % numberBuckets == 0。默认10
 hystrix.command.default.metrics.rollingPercentile.enabled 执行时是否enable指标的计算和跟踪，默认true
 
 hystrix.command.default.metrics.rollingPercentile.timeInMilliseconds 设置rolling percentile window的时间，默认60000
 
 hystrix.command.default.metrics.rollingPercentile.numBuckets 设置rolling percentile window的numberBuckets。逻辑同上。默认6
 
 hystrix.command.default.metrics.rollingPercentile.bucketSize 如果bucket size＝100，window＝10s，若这10s里有500次执行，只有最后100次执行会被统计到bucket里去。增加该值会增加内存开销以及排序的开销。默认100
 
 hystrix.command.default.metrics.healthSnapshot.intervalInMilliseconds 记录health 快照（用来统计成功和错误绿）的间隔，默认500ms
 
 Request Context 相关参数
 
 hystrix.command.default.requestCache.enabled 默认true，需要重载getCacheKey()，返回null时不缓存
 hystrix.command.default.requestLog.enabled 记录日志到HystrixRequestLog，默认true
 
 # Collapser Properties 相关参数
 
 hystrix.collapser.default.maxRequestsInBatch 单次批处理的最大请求数，达到该数量触发批处理，默认Integer.MAX_VALUE
 
 hystrix.collapser.default.timerDelayInMilliseconds 触发批处理的延迟，也可以为创建批处理的时间＋该值，默认10
 
 hystrix.collapser.default.requestCache.enabled 是否对HystrixCollapser.execute() and HystrixCollapser.queue()的cache，默认true
 
 # ThreadPool 相关参数
 
 线程数默认值10适用于大部分情况（有时可以设置得更小），如果需要设置得更大，那有个基本得公式可以follow：
 requests per second at peak when healthy × 99th percentile latency in seconds + some breathing room
 每秒最大支撑的请求数 (99%平均响应时间 + 缓存值)
 比如：每秒能处理1000个请求，99%的请求响应时间是60ms，那么公式是：
 1000 （0.060+0.012）
 基本得原则时保持线程池尽可能小，他主要是为了释放压力，防止资源被阻塞。
 当一切都是正常的时候，线程池一般仅会有1到2个线程激活来提供服务
 hystrix.threadpool.default.coreSize 并发执行的最大线程数，默认10
 
 hystrix.threadpool.default.maxQueueSize BlockingQueue的最大队列数，当设为－1，会使用SynchronousQueue，值为正时使用LinkedBlcokingQueue。该设置只会在初始化时有效，之后不能修改threadpool的queue size，除非reinitialising thread executor。默认－1。
 
 hystrix.threadpool.default.queueSizeRejectionThreshold 即使maxQueueSize没有达到，达到queueSizeRejectionThreshold该值后，请求也会被拒绝。因为maxQueueSize不能被动态修改，这个参数将允许我们动态设置该值。if maxQueueSize == -1，该字段将不起作用
 
 hystrix.threadpool.default.keepAliveTimeMinutes 如果corePoolSize和maxPoolSize设成一样（默认实现）该设置无效。如果通过plugin（https://github.com/Netflix/Hystrix/wiki/Plugins）使用自定义实现，该设置才有用，默认1.
 
 hystrix.threadpool.default.metrics.rollingStats.timeInMilliseconds 线程池统计指标的时间，默认10000
 
 hystrix.threadpool.default.metrics.rollingStats.numBuckets 将rolling window划分为n个buckets，默认10

Spring Cloud Config的作用是什么？

问题回答

可以方便微服务配置文件统一管理，实时更新。
它支持配置服务放在本地，也支持放在远程Git仓库中。
在spring cloud config 组件中，分两个角色，一是config server，二是config client， server端配置服务器，管理配置信息， client端获取配置信息。

spring cloud 和dubbo区别?

问题回答

Dubbo 定位服务治理、Spirng Cloud 是一个生态。
Dubbo基于Tcp协议。SpringCloud基于Http协议+rest接口，更灵活。
Dubbo主要服务注册中心，服务提供者，服务消费者，还有管控中心，SringCloud则有各个组件。
注册中心,dubbo 是zookeeper，springcloud是eureka，也可以是zookeeper。
一些政府金融项目还用着dubbo；也有很多项目往springCloud项目转型；新开的项目优先就是用springCloud了。

SpringBoot和SpringCloud的区别？

问题答案

SpringBoot专注于快速方便的开发单个个体微服务。
SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot ，属于依赖的关系
SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。

SpringCloud的主要组件（主要项目）有哪些？

问题答案

注册中心：Eureka
远程调用：Feign，后续Spring Cloud OpenFeign
网关：Zuul或者Spring Cloud Gateway
集中配置管理：Spring Cloud Config
熔断器：Hystrix
动态刷新集群中的服务配置：Spring Cloud Bus
负载均衡：Ribbon

介绍一下Spring Cloud里面Ribbon组件？

ribbon是一个负载均衡客户端。
feign默认集成了ribbon；SpringCloud-GateWay、restTemplate也会选择集成Ribbon。
ribbon，具有多种负载均衡策略；默认是简单轮询服务列表。

介绍下Spring Cloud Gateway？

问题回答

是Spring Cloud GateWay 是Spring官方推出的第二代网关框架，取代Zuul网关
是spring官方基于Spring 5.0、Spring Boot2.0和Project Reactor等技术开发的网关
基于Filter链提供网关功能：路由、重试、认证、负载、限流、熔断等功能。
它重要的概念是路由（route）、断言（Predicate）、过滤器（Filter）
网关过滤器（GatewayFilter ）有 20 多个实现类；网关过滤器工厂（GatewayFilterFactory）有22个实现类；
全局过滤器（GlobalFilter ）有11个实现类，全局过滤器是特殊的过滤器，会根据条件应用到所有路由中；

简要回答

Spring Cloud官方推出的第二代网关框架，取代Zuul网关
基于Filter链提供网关功能：路由、重试、认证、负载、限流、熔断等功能
重要的概念是路由（route）、断言（Predicate）、过滤器（Filter）
包含很多的网关过滤器、网关过滤器工厂、全局过滤器

介绍下Zuul？

问题回答

Zuul是Spring Cloud全家桶中的微服务API网关
Zuul是API网关组件，对请求提供路由及过滤功能。
Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul网关。Zuul已经停止更新。
Netflix OSS 开源组件集成，包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心组件
Zuul底层利用各种filte实现功能。

简要回答

Zuul是API网关组件，对请求提供路由及过滤功能
Zuul网关用的比较少，现在用Spring Cloud Gateway比较多。
实现网关的常见功能，认证和安全，路由和过滤

说一下Spring Cloud Bus？

问题回答

更新git仓库上面的配置以后，可以发送一个Post请求，让各个微服务重新获取配置。
各个微服务不用重启。
其实本质是利用了MQ的广播机制在分布式的系统中传播消息，目前常用的有Kafka和RabbitMQ。利用bus的机制可以做很多的事情，其中配置中心客户端刷新就是典型的应用场景之一
通过将所有微服务连接到单个消息代理来实现的。无论何时刷新实例，此事件都会订阅到侦听此代理的所有微服务，并且它们也会刷新。

简要回答

修改了配置，不用重启服务器，发一个post请求，通知各个微服务拉取最新配置。
本质是利用了MQ的广播机制

说一下springcloud里面hystrix ？

问题回答

Netflix开源了Hystrix组件，实现了断路器模式，SpringCloud对这一组件进行了整合。
主要功能分为4大板块隔离、限流、熔断、降级。我们常用的是请求熔断和服务降级。
涉及注解@EnableHystrix和@Hystrixcommand(fallbackMethod=“xxx”)
Feign默认集成了Hystrix。RestTemplate、springCloud GateWay在时候的时候都会考虑集成Hystrix。
服务熔断，指的是服务故障，再让新的请求去访问根本没有意义，这个时候选择暂时断开请求。
服务熔断依靠hystrix的断路器，它有全开、半开、关闭3种状态。
服务降级，指断路打开后，为了避免连锁故障，使用 fallback 方法返回当前不可用的友好提示。
总而言之，hystrix它是为了解决，由于单个服务故障，导致其他依赖服务不可用的“雪崩”效应。比如有服务A，假设A1·A100都依赖了A，假如A出现了问题，那A1·A100这100个服务也跟着出现了问题

谈谈你对springCloud理解？

问题回答
是什么？

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。

主要作用？

协调各个微服务，简化分布式系统开发。

优缺点？

优点：

产出于Spring大家族，Spring在企业级开发框架中无人能敌，来头很大，可以保证后续的更新、完善
组件丰富，功能齐全。Spring Cloud 为微服务架构提供了非常完整的支持。例如、配置管理、服务发现、断路器、微服务网关等；
Spring Cloud 社区活跃度很高，教程很丰富，遇到问题很容易找到解决方案
服务拆分粒度更细，耦合度比较低，有利于资源重复利用，有利于提高开发效率
可以更精准的制定优化服务方案，提高系统的可维护性
减轻团队的成本，可以并行开发，不用关注其他人怎么开发，先关注自己的开发
微服务可以是跨平台的，可以用任何一种语言开发
适于互联网时代，产品迭代周期更短
缺陷：
微服务过多，治理成本高，不利于维护系统
分布式系统开发的成本高（容错，分布式事务等）对团队挑战大
总结
总的来说优点大过于缺点，目前看来Spring Cloud是一套非常完善的分布式框架，目前很多企业开始用微服务、Spring Cloud的优势是显而易见的。