dubbo问题汇总
1.dubbo是什么
dubbo是一个分布式,高性能,透明化的RPC服务框架,提供服务自动注册、自动发现等高效服务治理方案,可以和spring框架无缝集成。(RPC指的是远程过程调用,也就是说两个服务器交互数据)
2.dubbo主要应用场景
透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需简单配置,没有任何API侵入
软负载均衡及容错机制,可在内网替代F5等硬件负载均衡器,降低成本,减少单点
服务自动注册与发现,不再需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或者删除服务提供者
3.dubbo的核心功能
- Remoting:网络通信框架,提供对多种NIO框架抽象封装,包括“同步转异步”和“请求-响应”模式的信息交换方式。
- Cluster:服务框架,提供基于接口方法的透明远程过程调用,包括多协议支持,以及负载均衡,失败容错,地址路由,动态配置等集群支持。
- Registry:服务注册,基于注册中心目录服务,使服务消费方能动态查找服务提供方,使地址透明,使服务提供方可以平滑增加或者减少机器。
4.dubbo的核心组件
- Provider:暴露服务的服务提供方
- Consumer:调用远程服务的服务消费方
- Registry:服务注册与发现的注册中心
- Monitor:统计服务的调用次数和调用时间的监控中心
- Container:服务运行容器
5.dubbo的架构设计
dubbo框架设计一共划分10层:
服务接口层(Service):该层是与实际业务逻辑相关的,根据服务提供方和服务消费方的业务设计对应的接口和实现。
配置层(Config):对外配置接口,以ServiceConfig和ReferenceConfig为中心。
服务代理层(Proxy):服务接口透明代理,生成服务的客户端Stub和服务器端Skeleton。
服务注册层(Registry):封装服务地址的注册与发现,以服务URL为中心。
集群层(Cluster):封装多个提供者的路由及负载均衡,并桥接注册中心,以Invoker为中心。
远程调用层(Protocol):封装RPC调用,以Invocation和Result为中心,扩展接口为Protocol、Invoker和Exporter。
信息交换层(Exchange):封装请求响应模式,同步转异步,以Request和Response为中心。
网络传输层(Transport):抽象mina和netty为统一接口,以Message为中心。
6.dubbo支持哪些协议,每种协议的应用场景
- dubbo:单一长连接和NIO异步通讯,适合大并发小数据量的服务调用,以及消费者远大于提供者。传输协议TCP,异步,Hessian序列化;
- rmi:采用JDK标准的rmi协议实现,传输参数和返回参数对象需要实现Serializable接口,使用java标准序列化机制,使用阻塞式短连接,传输数据包大小混合,消费者和提供者个数差不多,可传文件,传输协议TCP。多个短连接,TCP协议传输,同步传输,使用常规的远程服务调用和rmi互操作。在依赖低版本的Common-Collections包,java序列化存在安全漏洞;
- webservice:基于WebService远程调用协议,集成CXF实现,提供和原生WebService的互操作。多个短连接,基于HTTP传输,同步传输,适用系统集成和跨语言调用;
- http:基于HTTP表单提交的远程调用协议,适用Spring的HttpInvoke实现,多个短连接,传输协议HTTP,传入参数大小混合,提供者个数多余消费者,需要给应用程序和浏览器JS调用;
- hessian:集成Hessian服务,基于HTTP通讯,采用Servlet暴露服务,Dubbo内嵌Jetty作为服务器时默认实现,提供与Hession服务互操作。多个短连接,同步HTTP传输,Hessian序列化,传入参数较大,提供者大于消费者,提供者压力较大,可传文件;
- memcache:基于memcached实现的RPC协议
- redis:基于redis实现的RPC协议
7.dubbo有哪些注册中心
- Multicast注册中心:Multicast注册中心不需要任何中心节点,只要广播地址,就能进行服务注册和发现。基于网络中组播传输实现;
- Zookeeper注册中心:基于分布式协调系统Zookeeper实现,采用Zookeeper的watch机制实现数据变更;
- redis注册中心:基于redis实现,采用key/Map存储,住key存储服务名和类型,Map中key存储服务URL,value服务过期时间。基于redis的发布/订阅模式通知数据变更;
- Simple注册中心
8.dubbo集群提供的负载均衡策略
- Random LoadBalance:随机选取提供者策略,有利于动态调整提供者权重
- RoundRobin LoadBalance:轮询选取提供者策略,平均分布,但是存在请求累积的问题
- LeastActive LoadBalance:最少活跃调用策略,解决慢提供者接收更少的请求
- ConstantHash LoadBalance:一致性Hash策略,使相同参数请求总是发到同一提供者,一台机器宕机,可以基于虚拟节点,分摊至其他提供者,避免引起提供者的剧烈变动
9.dubbo的集群容错方案
- Failover Cluster:失败自动切换,当出现失败,重试其它服务器。通常用于读操作,但重试会带来更长延迟。
- Failfast Cluster:快速失败,只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录。
- Failsafe Cluster:失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作。
- Failback Cluster:失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作。
- Forking Cluster:并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过 forks=”2″ 来设置最大并行数。
- Broadcast Cluster:广播调用所有提供者,逐个调用,任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息。
10.dubbo不同粒度配置的覆盖关系
以 timeout 为例,下图显示了配置的查找顺序,其它 retries, loadbalance, actives 等类似:
- 方法级优先,接口级次之,全局配置再次之。
- 如果级别一样,则消费方优先,提供方次之。
其中,服务提供方配置,通过 URL 经由注册中心传递给消费方。
(建议由服务提供方设置超时,因为一个方法需要执行多长时间,服务提供方更清楚,如果一个消费方同时引用多个服务,就不需要关心每个服务的超时设置)。