- 1、谈一下分布式架构中的CAP原则,以及BASE理论?
- 2、什么是分布式?什么是微服务?
- 3、微服务中的组件及其作用?
- 4、服务降级和服务熔断的区别?
- 5、Eureka和Nacos的区别?
- 6、Nacos中,服务提供者是如何项Nacos注册中心续约的?
- 7、Nacos如何判定服务实例的状态?
- 8、Nacos中,服务启动时,如何找到服务启动注册配置类?
- 9、Nacos中,服务消费方是如何调用服务提供方的服务的?
- 10、Nacos中的负载均衡底层是如何实现的?
- 11、Ribbon是什么?有哪些负载均衡策略?
- 12、注册中心原理?
- 13、@LoadBalanced的作用是什么?
- 14、Nacos的实现原理?
- 15、Nacos注册中心的原理?
1、谈一下分布式架构中的CAP原则,以及BASE理论?
CAP原则是指:
C:Consistency,数据一致性,所有节点在同一时间具有相同的数据;
A:Availablity,高可用性,保证每个请求不管是成功还是失败,都能够得到响应;
P:partition tolerance,分区容忍性,允许网络间隔,系统中任意信息都丢失或者说失败,都不会影响系统的继续运行;
而我们说的分布式系统中,P,partition toleracne分区容错性,这个是必需的,而CAP原则,这三个是没法完全兼顾的,可以选择AP,也可以选择CP,但不是说选择了AP,C就完全抛弃了,也不是说选择了CP,A就完全抛弃了;
在CAP原则的C,Consistency数据已执行原则中,它表示的事强一致性,也就是说,每个节点的数据都是最新版本,其实一致性还有其他级别:弱一致性和最终一致性。弱一致性是相对强一致性而言的,他不能保证总能得到最新的数据,而最终一致性,放宽了对时间段要求,在被调完成操作响应后的某个时间点,被调多个节点的数据最终达成一致性;
—>所以,CAP原则,其实是在分区容忍性的前提下,数据的强一致性和应用的极致高可用性无法同时达到。
BASE理论:
BASE是基本可用(Basically Available)、软状态(Soft-state)和最终一致性(Eventually Consistent);
BASE理论是对CAP理论中,C数据一致性和A高可用性权衡的结果,基于CAP演变而来;
核心思想是即使无法做到强一致性,那么就根据自身业务特点,采用适当的方式来达到系统的最终一致性;
2、什么是分布式?什么是微服务?
分布式就是把原本的一个项目拆分为多个模块,并且这些模块分开部署,每个模块可以分开部署多个;可以通过多个普通的及其完成单个机器无法完成的计算、存储任务;分布式是分散应用部署的机器的压力;
微服务是非常微小的服务,甚至可能一个服务只做一个微小的功能,这个服务可以单独部署运行。微服务是分散应用各个部分的能力或者说作用;
分布式是属于微服务的。微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。但是微服务不一定是分布式,因为微服务的应用不一定是分散在多个服务器上,他也可以是同一个服务器。这也是分布式和微服务的一个细微差别。
3、微服务中的组件及其作用?
注册中心:Eureka、Nacos;用来负责服务的注册与发现;
负载均衡:Ribbon;会在帮你每次请求时选择一台及其,均匀的 把请求分发到各个机器上;
服务网关:Gateway;是服务调用的入口,所有向微服务中发送的请求,都是通过网关来调用的,可以在这里面实现用户鉴权、动态路由、负载限流等功能;
服务调用:OpenFeign;微服务内部之间调用接口的组件;
熔断器:Hystix、Sentinel;是服务的保护机制,保证在调用了异常服务时,能够快速的返回结果,避免大量的同步等待,常见的手段有熔断、降级、限流等;
配置中心:SpringCloud Config、Nacos;将本地化的配置信息注册道配置中心,统一管理,方便迁移;
4、服务降级和服务熔断的区别?
服务熔断:
当下游的服务因为某种原因突然变得不可用或者响应过慢的时候,就不再允许继续调用目标服务,直接返回;等到目标服务情况恢复后,再恢复调用;
服务降级:
当下游的服务因为某种原因响应过慢时,或者为了预防某些功能出现负荷过载或是响应慢的情况,在目标服务内部舍弃暂时舍弃一些非核心的接口和数据的请求,当访问这些请求时,直接返回一个提前准备好的fallback错误处理信息;
—-> 服务降级每次都会先调用原服务方法,调用失败才会执行服务降级方法;服务熔断状态会直接调用服务降级方法。
5、Eureka和Nacos的区别?
- Eureka需要我们引入其依赖,自己去集成实现它;而Nacos是单独提供出来了一个应用;
- 对于CAP原则,Eureka是选择了AP,而Nacos选择了CP+AP;
- Nacos同时还有配置中心的功能,Eureka没有;
6、Nacos中,服务提供者是如何项Nacos注册中心续约的?
服务提供者启动后, 会每隔一段时间向Nacos发送心跳包,默认是5秒,Nacos收到心跳包就是一种续约;nacos注册中心15秒钟内没有检测到心跳包,会默认认为这个服务处于一种不健康的状态,如果30s还没有收到心跳包,就会判定这个服务不可用,会在nacos服务器上删除这个提供者,并把最新的提供者列表通过udp协议发送给nacos客户端;
7、Nacos如何判定服务实例的状态?
服务提供者启动后, 会每隔一段时间向Nacos发送心跳包,默认是5秒,Nacos收到心跳包就是一种续约;nacos注册中心15秒钟内没有检测到心跳包,会默认认为这个服务处于一种不健康的状态,如果30s还没有收到心跳包,就会判定这个服务不可用,会在nacos服务器上删除这个提供者,并把最新的提供者列表通过udp协议发送给nacos客户端;
8、Nacos中,服务启动时,如何找到服务启动注册配置类?
9、Nacos中,服务消费方是如何调用服务提供方的服务的?
通过远程调用的方式,可以通过RestTemplate,它是Spring提供的,里面封装了httpclient类,模拟http请求; 也可以使用OpenFeign;
10、Nacos中的负载均衡底层是如何实现的?
Nacos中服务间的负载均衡一般都是通过Ribbon,我们通过OpenFiegn调用远程结构,OpenFeign是默认集成了Ribbon的。
Ribbon中有负载均衡算法,就与这些算法,去服务实例中获取一个实例为消费方法提供服务;
11、Ribbon是什么?有哪些负载均衡策略?
Ribbon是一个组件,主要功能是提供客户端的负载均衡策略;
有以下几种负载均衡策略:
- 轮询(默认为此策略):轮询的方式选择服务实例(默认会轮询十轮);
- 随机策略:随机选择一个服务实例;
- 最可用策略:逐个考察实例,选择并发量最小的实例使用;
- 权重相应策略:根据响应时间为服务实例分配权重,响应时间越长,权重越小,被选中的可能性越低;
- 区域(Zone)回避策略:根据服务实例所在区域和实例的可用性,对服务实例进行选择;
- 重试策略:对选定的负载均衡策略加上重试机制;先按照轮询策略获取服务实例,能获取到就返回,获取失败的话,就在指定的时间内重试。(默认视线是500毫秒,可以一直重试,知道找到为止);
- 可用过滤策略:过来不掉处于熔断状态的服务实例和已经超过连接极限的服务实例,对剩下的服务实例采用轮询策略;
12、注册中心原理?
注册中心主要涉及到三个角色:服务提供者、服务消费者和注册中心本身;
微服务在启动时,将自己的信息注册到注册中心,注册中心存储这些数据;
服务消费者从注册中心查询服务提供者的地址,并通过地址调用服务提供者的接口;
微服务与注册中心之间使用一定的机制,比如心跳,进行通信,如果这次中心和某个微服务之间长时间无法通信,就会注销该实例;
微服务的网络地址发生变化时(比如实例增加、减少或者IP变动),会重新注册到注册中心,这样服务消费者就不用人工修改要调用的服务提供者的网络地址了;
13、@LoadBalanced的作用是什么?
作用是让一个东西具有负载均衡的能力,比如配合RestTemplate来使用;
14、Nacos的实现原理?
服务的注册信息,会被保存到servcieMap中,这个servcieMap是一个ConCurrentHashMap类型的Map,
它的key是namespace,value是Map
而service中存放了一个clusterMap,这是一个HashMap,key是clustername,value是cluster对象,在cluster对象中,有存放了两个set集合,一个存放临时服务列表,一个存放持久服务列表;服务注册最后更新的就是这两个set集合;
服务在注册的时候,服务端会通过轮询注册中心集群地址进行注册,失败则请求下一个节点;而服务的消费者,从nacos中读取指定服务名称等实例列表,缓存到本地。
nacos中服务消费者和nacos的关系,与其他注册中心不同的是,采用pull/push同时运作的方式:服务消费者会每隔十秒轮询一次服务列表,此为pull,而nacos又回通过检测心跳,心跳超时则通过UDP协议推送服务实例消息(此为push机制),用UDP不保证连接的安全性,是因为还有pull机制;
15、Nacos注册中心的原理?
注册中心主要涉及到三个角色:服务提供者、服务消费者和注册中心本身;
微服务在启动时,将自己的信息注册到注册中心,注册中心存储这些数据,同时默认每五秒向nacos发送一次心跳,心跳带上了服务名,服务ip服务端口等信息;同时nacos也会向client主动发起健康检查,如果15秒内无心跳且健康检查失败则认为实例不健康,如果30秒内健康检查失败且无心跳,则认为服务失效,剔除实例;