代码编织梦想

springcloud的组件有哪些

注册中心:euraka、nacos、zookeeper
注册中心及配置中心:nacos
远程调用:feign、dubbo
负载均衡:ribbon
服务熔断:hystrix、sentinel
网关:zuul、gateway
在这里插入图片描述
eureka注册中心的作用
在这里插入图片描述

△面试题:服务注册和发现是什么意思?springcloud是如何实现服务注册和发现的?

我们当时项目采用的eureka作为注册中心,这个也是spring cloud体系中的一个核心组件。

服务注册:服务提供者需要把自己的信息注册到eureka,由eureka来保存这些信息,比如服务名称、ip、端口等等。

服务发现:消费者向eureka拉取服务列表信息,如果服务提供者有集群,则消费者会利用负载均衡算法,选择一个发起调用。

服务监控:服务提供者会每隔30秒向eureka发送心跳,报告健康状态,如果eureka服务90秒没接收到心跳,从eureka中剔除

△面试题:nacos和eureka的区别

nacos和eureka的共同点

  • 都支持服务注册和服务拉取
  • 都是注册中心
  • 都支持服务提供者心跳方式做健康方式
    如果是临时实例,那么nacos和eureka的工作流程基本一致

nacos和eureka的不同点

  • nacos支持服务端主动检测提供者状态,临时实例采用心跳模式,非临时实例采用主动检测模式
  • 临时实例心跳不正常会被剔除,非临时实例心跳不正常不会被剔除
  • nacos支持服务列表变更的消息推送模式,服务列表能够及时更新
  • nacos集群默认采用AP模式,当集群中存在非临时实例时,才采用CP模式;eureka采用AP模式
  • nacos还支持配置中心;eureka仅仅是注册中心

nacos默认是临时实例,ephemeral配置默认为true
在这里插入图片描述

CAP理论

CAP即

  • Consistency(一致性)
  • Availability(可用性)
  • Partition tolerance(分区容忍性)
    轻松理解CAP理论

ribbon负载均衡是如何实现的?
微服务的负载均衡主要使用了一个组件Ribbon,比如,我们在使用feign远程调用的过程中,底层的负载均衡就是使用了ribbon。

ribbon执行流程
在这里插入图片描述

ribbon负载均衡策略有哪些?

  • RoundRobinRule:简单轮询服务列表来选择服务器
  • WeightedResponseTimeRule:按照权重来选择服务器,响应时间越长,权重越小
  • RandomRule:随机选择一个可用的服务器
  • BestAvailableRule:忽略那些短路的服务器,并选择并发数较低的服务器
  • RetryRule:重试机制的选择逻辑
  • AvailabilityFilteringRule:可用性敏感策略,先过滤非健康的,再选择连接数较小的实例
  • ZoneAvoidanceRule: ribbon默认策略,以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类,这个Zone可以理解为一个机房、一个机架等。再对Zone内的多个服务做轮询

如何指定负载均衡策略?
通过实现IRule接口,然后再通过配置类或配置文件配置即可,有两种方式
在这里插入图片描述
什么是服务雪崩?怎么解决这个问题?
服务雪崩是指一个服务失败导致整条链路的服务都出现问题的情形。
在这里插入图片描述

服务降级
服务降级是服务自我保护或者保护下游服务的一种方式。用于确保服务不会受请求突增从而影响导致不可用。一般在实际开发中调用feign组件整合,实现服务降级逻辑。

feign示例
在这里插入图片描述
Hystrix熔断机制

Hystrix熔断机制,用于监控微服务调用情况,默认是关闭的。
开启需要在引导类上添加注解:@EnableCircuitBreaker,若默认检测到10秒内请求的失败率超过50%,就触发熔断机制。之后每隔5秒重新尝试请求微服务,如果微服务不能响应,继续走熔断机制。如果微服务可达,则关闭熔断机制,恢复正常请求。
在这里插入图片描述

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/m0_46267375/article/details/130891133