赞
踩
java最新面试题(java基础、集合、多线程、jvm、锁、算法、CAS、Redis、数据库、mybatis、spring、springMVC、springBoot、微服务)
分布式,多个模块,每一个模块都是一个单独的系统。
RPC(Remote Procedure Call):远程过程调用。
Dubbo: 国内最早开源的 RPC 框架,由阿里巴巴公司开发并于 2011 年末对外开源。
Spring Cloud: 国外公司 2014 年对外开源的 RPC 框架。
①定位不同: springCloud微服务架构下的一站式解决方案;Dubbo主要用于服务的调用和治理。
②生态环境不同: springCloud依靠spring平台,更完善;Dubbo相对匮乏。
③调用方式不同: springCloud是采用Http协议做远程调用,接口一般是Rest风格,比较灵活;Dubbo是采用Dubbo协议,接口一般是Java的Service接口,格式固定。
简单来说: springCloud是品牌机,Dubbo是组装机。
Spring Cloud Eureka: 服务注册与发现。
Spring Cloud Feign: 服务接口调用。
Spring Cloud Ribbon: 客户端负载均衡。
Spring Cloud Hystrix: 断路器。
Spring Cloud Zuul: 服务网关。
Spring Cloud Config: 分布式统一配置管理。
等等。
Eurake Client(客户端): 负责将这个服务的信息注册到Eureka Server中。
Eureka Server(服务端): 注册中心,里面有一个注册表,保存了各个服务所在的机器和端口号。
原理: 系统中的其他服务使用Eureka的客户端将其连接到Eureka服务端中,并且保持心跳,这样工作人员可以通过Eureka服务端来监控各个微服务是否运行正常。
如果Eureka服务端在一定时间内没有接收到某个微服务的心跳(默认90s),Eureka服务端会进入自我保护模式,在该模式下Eureka服务端会保护服务注册表中的信息,不在删除注册表中的数据,当网络故障恢复后,Eureka服务端节点会自动退出自我保护模式。
CAP原则: 又称CAP定理,指的是在一个分布式系统中,强一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。
强一致性(Consistency): 访问所有的节点,得到的数据结果都是一样的。
可用性(Availability): 保证每个请求不管成功或者失败都有响应。
分区容错性(Partiton tolerance): 系统中任意信息的丢失或失败不会影响系统的继续运作。
在分布式系统中分区容错性是必须要保证的,因此只能保证A或C,只能AP和CP。
我们在服务使用中可以容忍注册中心返回几分钟之前的注册信息,但是不能接受服务直接down掉不可用。
Zookeeper: 保证的是CP,当主机的节点发生网络故障了,会选取新的主节点,响应时间过长。
Eureka: 保证的是AP,Eureka的节点都是平等的,不存在主机从机,因此Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像Zookeeper那样是整个注册中心瘫痪。
共同点
①都支持服务的注册和拉取。
②都支持服务提供者以心跳检测来判断是否健康(临时实例)。
不同点
①nacos支持注册中心主动询问服务提供者的状态(非临时实例)。
②nacos支持注册中心消息变更主动推送。
③心跳不正常会被剔除(临时实例)。
主要功能是提供客户端的软件负载均衡算法,默认是轮询算法。
Ribbon会从注册中心获取到服务的信息,然后通过轮询算法,从中选择一台机器。
nginx: 反向代理实现负载均衡,相当于从nginx服务器进行请求转发。
Ribbon: 客户端负载均衡,全程都是客户端操作。
Feign集成了Ribbon,Feign 是一个声明web服务客户端,这使得编写web服务客户端更容易,远程调用更加简单。
Feign
RestTemplate
Ribbon: 需要我们自己构建http请求,然后通过RestTemplate去发给其他服务,比较繁琐。
Feign: 不需要自己构建Http请求,直接接口调用就行。
服务雪崩:多个服务相互调用时,A调B,B调C,C调D等等更多调用,那么如果中间调用需要很长时间,然后再去调用A,那么占用的资源就越来越多,导致系统崩溃。
防止服务雪崩的一个工具,具有服务降级、服务熔断(@HystrixCommand(fallbackMethod = “hystrixById”) //失败了调用的方法)、服务隔离、监控等防止雪崩的技术。
服务降级: 当出现请求超时、资源不足时(线程或者信号量),会进行服务降级,就是去返回fallback方法的结果。
服务熔断: 当失败率(网络故障或者超时造成)达到阈值自动触发降级,是一种特殊的降级。
服务隔离: 为隔离的服务开启一个独立的线程,这样在高并发情况下,也不会影响该服务。一般使用线程池实现(还有信号量方式实现)。
区别: 降级每个请求都会发送过去,而熔断不一定,达到失败率,请求就不会再去发送了。请求出错时熔断返回的是fallback数据,而熔断则是一段时间不会去访问服务提供者。
比如:
①降级:A调B,发送10个请求,即使每个请求都超时,也会去请求B。
②熔断:A调B,发送10个请求,失败率设置为50%,如果5个请求失败,此时失败率到了50%,那么后面的5个请求就不会走到B。
接收所有的请求,并且将不同的请求转发至不同的微服务模块。
①过滤器
②权限认证
③降级限流
④安全
功能强大丰富,性能好,维护性好,实现异步,可以替代Zuul网关。
集中管理配置文件,不需要每个服务编写配置文件,服务会向配置中心拉取配置。
实时刷新(需要spring cloud bus)。
注册中心和配置中心。
Nacos可以是AP也可以是CP。默认是AP
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。