你们好,我是Java最全面试题库
的提裤姐,今天这篇是JavaEE面试题系列的第九篇,主要总结了Dubbo
相关的问题;在后续,会沿着第一篇开篇的知识线路一直总结下去,作到日更!若是我能作到百日百更,但愿你也能够跟着百日百刷,一百天养成一个好习惯。java
Dubbo 是一个分布式、高性能、透明化的 RPC 服务框架
,提供服务自动注册
、自动发现
等高效服务治理
方案。mysql
接口服务层(Service)
:该层与业务逻辑相关,根据 provider 和 consumer 的业务设计对应的接口和实现配置层(Config)
:对外配置接口,以 ServiceConfig 和 ReferenceConfig 为中心服务代理层(Proxy)
:服务接口透明代理,生成服务的客户端 Stub 和 服务端的 Skeleton,以 ServiceProxy 为中心,扩展接口为 ProxyFactory服务注册层(Registry)
:封装服务地址的注册和发现,以服务 URL 为中心,扩展接口为 RegistryFactory、Registry、RegistryService路由层(Cluster)
:封装多个提供者的路由和负载均衡,并桥接注册中心,以Invoker 为中心,扩展接口为 Cluster、Directory、Router和LoadBlancce监控层(Monitor)
:RPC调用次数和调用时间监控,以 Statistics 为中心,扩展接口为 MonitorFactory、Monitor和MonitorService远程调用层(Protocal)
:封装 RPC 调用,以 Invocation 和 Result 为中心,扩展接口为 Protocal、Invoker和Exporter信息交换层(Exchange)
:封装请求响应模式,同步转异步。以 Request 和 Response 为中心,扩展接口为 Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer网络传输层(Transport)
:抽象 mina 和 netty 为统一接口,以 Message 为中心,扩展接口为Channel、Transporter、Client、Server和Codec数据序列化层(Serialize)
:可复用的一些工具,扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPoolDubbo 的客户端和服务端有三种链接方式,分别是:web
一、ServiceConfig 类拿到对外提供服务的实际类 ref(如:HelloWorldImpl)
二、经过 ProxyFactory 类的 getInvoker 方法使用 ref 生成一个 AbstractProxyInvoker 实例,到这一步就完成具体服务到 Invoker 的转化
三、接下来就是 Invoker 转换到 Exporter 的过程:面试
一、随机模式
。按权重设置随机几率。在一个截面上碰撞的几率较高,但调用越大分布越均匀
二、轮询模式
。按公约后的权重设置轮询比例。但存在响应慢的服务提供者会累积请求
三、最少活跃调用数
。响应快的提供者接受越多请求,响应慢的接受越少请求
四、一致hash
。根据服务提供者ip设置hash环,携带相同的参数老是发送的同一个服务提供者,若服务挂了,则会基于虚拟节点平摊到其余提供者上redis
一、Failover Cluster:失败重试
当服务消费方调用服务提供者失败后自动切换到其余服务提供者服务器进行重试
二、Failfast Cluster:快速失败
当服务消费方调用服务提供者失败后,当即报错,也就是只调用一次。一般这种模式用于非幂等性的写操做。
三、Failsafe Cluster:失败安全
当服务消费者调用服务出现异常时,直接忽略异常。这种模式一般用于写入审计日志等操做。
四、Failback Cluster:失败自动恢复
当服务消费端用服务出现异常后,在后台记录失败的请求,并按照必定的策略后期再进行重试。这种模式一般用于消息通知操做。
五、Forking Cluster:并行调用
当消费方调用一个接口方法后,Dubbo Client会并行调用多个服务提供者的服务,只要一个成功即返回。这种模式一般用于实时性要求较高的读操做,但须要浪费更多服务资源
六、Broadcast Cluster:广播调用
当消费者调用一个接口方法后,Dubbo Client会逐个调用全部服务提供者,任意一台调用异常则此次调用就标志失败。这种模式一般用于通知全部提供者更新缓存或日志等本地资源信息。sql
jdk SPI SPI :
全称为 (Service Provider Interface) ,是JDK内置的一种服务提供发现机制。SPI是一种动态替换发现的机制, 好比有个接口,想运行时动态的给它添加实现,你只须要添加一个实现。咱们常常遇到的就是java.sql.Driver接口,其余不一样厂商能够针对同一接口作出不一样的实现,mysql和postgresql都有不一样的实现提供给用户,而Java的SPI机制能够为某个接口寻找服务实现。
在jdk6里面引进的一个新的特性ServiceLoader,从官方的文档来讲,它主要是用来装载一系列的service provider。并且ServiceLoader能够经过service provider的配置文件来装载指定的service provider。当服务的提供者,提供了服务接口的一种实现以后,咱们只须要在jar包的META-INF/services/目录里同时建立一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候,就能经过该jar包META-INF/services/里的配置文件找到具体的实现类名,并装载实例化,完成模块的注入缓存
dubbo SPI:
Dubbo对JDK SPI进行了扩展,对服务提供者配置文件中的内容进行了改造,由原来的提供者类的全限定名列表改为了KV形式的列表,这也致使了Dubbo中没法直接使用JDK ServiceLoader,因此,与之对应的,在Dubbo中有ExtensionLoader,ExtensionLoader是扩展点载入器,用于载入Dubbo中的各类可配置组件安全
能够通讯;
启动 dubbo时,消费者会从zk拉取注册的生产者的地址接口等数据,缓存在本地。每次调用时,按照本地存储的地址进行调用;
注册中心对等集群,任意一台宕机后,将会切换到另外一台注册中心;所有宕机后,服务的提供者和消费者仍能经过本地缓存通信。服务提供者无状态,任一台宕机后,不影响使用;服务提供者所有宕机,服务消费者会没法使用,并没有限次重连等待服务者恢复;挂掉是没关系的,但前提是你没有增长新的服务,若是你要调用新的服务,则是不能办到的。服务器