SpringCloud五大组件原理
1. Eureka原理Eureka作为微服务中的注册中心,其服务注册于发现的原理如下:首先有两个角色,一个服务端和客户端,服务端就是Eureka本身,客户端就是服务提供者和消费者,当服务提供者启动会将自己的信息注册到Eureka去,消费者启动会去注册中心拉取服务列表缓存到本地,消费者就可以远程调用服务提供者。客户端会与注册中心保持心跳来证明自己存活,每隔30s客户端会发送心跳给注册中心,默认情况下
springcloud入门demo:https://gitee.com/Linging241/springcloud-demo.git
其他
1. Eureka原理
- Eureka作为微服务中的注册中心,其服务注册与发现的原理如下:
首先有两个角色,一个服务端和客户端,服务端就是Eureka本身,客户端就是服务提供者和消费者,当服务提供者启动会将自己的信息注册到Eureka去,消费者启动会去注册中心拉取服务列表缓存到本地,消费者就可以远程调用服务提供者。客户端会与注册中心保持心跳来证明自己存活,每隔30s客户端会发送心跳给注册中心,默认情况下,每隔90s注册中心会检查是否有收到心跳,如果没有收到心跳会将客户端从服务列表剔除。 - 但是由于服务之间的调用常常会受网络延迟的影响导致心跳没有及时的收到,从而误将客户端剔除,所以Eureka会有自我保护机制来应对这种情况。
- 默认情况下,Eureka的自我保护机制是开启的。
- 自我保护机制的触发:在15分钟内,Eureka收到的心跳总数低于总数的85%,就会开启。
- 自我保护机制的退出:当收到心跳数达到阈值之后,会自动退出自我保护机制。
面试题:
1.Eureka与Zookeeper的区别在哪?
- zookeeper保证的是CP,在Zookeeper集群中,当发生网络故障导致master节点和slave节点失联时,剩余的slave节点会进行leader选举,而在选举的过程中,zookeeper集群不可用,不能对外提供注册和查询的服务。主从节点数据同步的时候不能对外提供服务。
- Eureka保证的是AP,在Eureka集群中,某些节点挂掉,只要有一个Eureka节点存在,就可以对外提供注册和查询服务,但是可能注册信息不是最新的(不保证强一致性)。
2 .Eureka与Nacos的区别?
- Nacos既支持AP也支持CP,默认使用AP和Eureka一样。
https://blog.csdn.net/weixin_43776652/article/details/120874245
2.Ribbon与Feign
- Ribbon是一个Http和Tcp的客户端负载均衡工具,它可以在客户端配置服务端列表,,它使用RestTemplate模拟客户端请求,过程相对繁琐。
- Feign继承了Ribbon,使用接口的方式进行服务调用。
面试题:
1.负载均衡算法有哪些?
随机、轮询、响应时间权重、重试等,还可以实现IRule接口,自定义负载均衡算法。
2.Ribbon和Feign的区别?
- 启动类上加的注解不同,Ribbon用的是@RibbonClients;Feign用的是@EnableFeignClients
- 服务的指定位置不同,Ribbon是在@RibbonClient上指定服务名称;Feign是在接上的@FeignClient上指定。
- 调用方式不同,Ribbon需要自己构建http请求,模拟http请求,然后使用RestTempate进行调用;Feign采用接口的方式调用。
3.Ribbon原理
先去本地获取从Eureka缓存下来的服务列表,然后使用负载均衡算法选取一个服务,使用HttpClient进行调用。
4.Feign的原理
在配置类上,加上@EnableFeginClients,那么该注解是基于@Import注解,注册有关Fegin的解析注册类,这个类是实现 ImportBeanDefinitionRegistrar 这个接口,重写registryBeanDefinition 方法。他会扫描所有加了@FeginClient 的接口,然后针对这个注解的接口生成动态代理,然后你针对fegin的动态代理去调用他方法的时候,此时会在底层生成http协议格式的请求,使用HttpURLConnection进行调用。
5.Feign和OpenFeign的区别?
OpenFeign在feign的基础上支持了SpringMVC的注解,如@RequestMapping等等,OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口,并通过动态代理的方式产生实现类,实现类中做负载均衡并调用其他服务。
3.Hystix
Hystix是分布式系统的一个延迟和容错的开源库,它可以进行熔断、降级、限流、监控,可以避免分布式系统的级联故障和雪崩效应。
服务熔断:熔断是直接调用降级方法。不调用目标方法,无需等待接口调用超时才返回结果。
服务降级:降级是调用目标方法,由于目标方法调用超时或者异常,才调用降级方法。
使用:服务降级是在消费端和feign一起使用,默认降级的配置不是开启的(feign.hystrix.enabled=false),服务熔断是在服务端使用,对服务端的controller进行熔断,默认熔断的配置是开启的(spring.cloud.circuit.breaker.enabled=true)。
面试题:
1、什么是服务雪崩?
服务雪崩就是服务A调用服务B,服务B调用服务C,服务C挂掉了,导致服务B、C超时受影响,导致服务A也超时,对服务造成级联的影响。即下游服务挂掉或者超时,导致上游调用服务大面积受到影响,阻塞、超时,进而导致雪崩效应。
2、Hystix和Sentinel的区别?
3、Hystix的限流两种方式
线程池和信号量,信号量没有timeout机制。
4、限流算法有几种?
计数器、滑动窗口计数器、漏桶法、令牌桶
4.Zuul
Zuul作为微服务的网关,对微服务的访问进行控制,它可以进行路由、过滤、鉴权、代理请求,
面试题:
1、Zuul和gateway的区别?
- Zuul1.0是阻塞式的api,不支持长连接,而gateway支持异步。
- Zuul没有提供限流、负载均衡等支持,而gateway支持。
- 它们都是web网关,处理http请求,底层都是servlet。
5.Config
SpringcloudConfig是微服务中的配置中心,对微服务中多个自服务的配置进行统一的管理,可以对配置的读取、加密、解密等操作。
面试题:
1、Config和Nacos的区别?
- Config大部分集合git使用,配置动态变更需要依赖SpringCloudBus消息总线来通知所有Client变化;并且没有可视化界面。
- Nacos采用长连接,一旦配置变更,会迅速通知Client进行变更,速度较快;提供可视化界面。
6.SpringCloud升级对比图
7.分布式理论CAP及base理论
C(Consistence):一致性,集群节点数据的一致。
A(Availability):可用性,集群节点只要存在一个节点就能对外提供服务,那就是可用。
P(Partition tolerance):分区容错性,即当分布式系统发生网络分区故障时,依然能对外提供一致性或者可用性的服务。
分布式系统多个服务节点部署在网络中的不同机器上,通过网络连接在一起,那么由于网络不稳定,所以一定会存在分区故障,导致网络分区,形成多个不连通的区域,那么不连通的区域,分布式系统中的节点就不能进行数据同步,就会导致数据的不一致,但是系统还要对外提供服务,对外提供服务有两种方式,要么等待网络恢复正常,数据同步完之后再对外提供服务,一致性,要么只要存在一个节点就可以对外提供服务,虽然节点间可能数据不一致,可用性。
Base理论是CAP理论的延伸,它抛弃强一致性,来了个最终一致性。
- 基本可用(Basically Available): 基本可用是指分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用。电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务。这就是损失部分可用性的体现。
- 软状态(Soft State): 软状态是指允许系统存在中间状态,而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。MySQL Replication 的异步复制也是一种体现。
- 最终一致性(Eventual Consistency): 最终一致性是指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。
更多推荐
所有评论(0)