1、Dubbo是什么?
Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架,现已成为 Apache 基金会孵化项目。
dubbo是一个分布式框架,远程服务调用的分布式框架,其核心部分包含:
集群容错:提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。
远程通讯:提供对多种长连接的NIO框架抽象封装,包括多种线程模型,序列化,以及“请求-响应”模式的信息交换方式。
自动发现:基于注册中心目录服务,使消费提供方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。
2、为什么要用Dubbo?
因为是阿里开源项目,国内很多互联网公司都在用,已经经过很多线上考验。内部使用了 Netty、Zookeeper,保证了高性能高可用性。
使用 Dubbo 可以将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,可用于提高业务复用灵活扩展,使前端应用能更快速的响应多变的市场需求。
透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需要简单配置,没有任何API入侵。软负载均衡及容错机制,可以在内网替代F5等硬件负载均衡器。降低成本,减少单点。服务自动注册与发现,不在需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或删除服务提供者。
3、Dubbo 和 Spring Cloud 有什么区别?
两个没关联,如果硬要说区别,有以下几点。
1)通信方式不同
Dubbo 使用的是 RPC 通信,而 Spring Cloud 使用的是 HTTP RESTFul 方式。
2)组成部分不同
4、dubbo都支持什么协议,推荐用哪种?
- dubbo://(推荐)
- rmi://
- hessian://
- http://
- webservice://
- thrift://
- memcached://
- redis://
- rest://
5、Dubbo需要 Web 容器吗?
不需要,如果硬要用 Web 容器,只会增加复杂性,也浪费资源。
6、Dubbo内置了哪几种服务容器?
- Spring Container
- Jetty Container
- Log4j Container
Dubbo 的服务容器只是一个简单的 Main 方法,并加载一个简单的 Spring 容器,用于暴露服务。
7、Dubbo默认使用什么注册中心,还有别的选择吗?
推荐使用 Zookeeper 作为注册中心,还有 Redis、Multicast、Simple 注册中心,但不推荐。
8、Dubbo有哪几种配置方式?
- Spring 配置方式
- Java API 配置方式
9、Dubbo启动时如果依赖的服务不可用会怎样?
Dubbo 缺省会在启动时检查依赖的服务是否可用,不可用时会抛出异常,阻止 Spring 初始化完成,默认 check="true",可以通过 check="false" 关闭检查。
10、Dubbo支持服务多协议吗?
Dubbo 允许配置多协议,在不同服务上支持不同协议或者同一服务上同时支持多种协议。
11、当一个服务接口有多种实现时怎么做?
当一个接口有多种实现时,可以用 group 属性来分组,服务提供方和消费方都指定同一个 group 即可。
12、Dubbo支持分布式事务吗?
目前暂时不支持,后续可能采用基于 JTA/XA 规范实现,如以图所示。
13、Dubbo 能集成 Spring Boot 吗?
可以的,项目地址如下。
https://github.com/apache/incubator-dubbo-spring-boot-project
14.Dubbo的好处?
- 透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需简单配置,没有任何API侵入。
- 软负载均衡及容错机制,可在内网替代F5等硬件负载均衡器,降低成本,减少单点。
- 服务自动注册与发现,不再需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或删除服务提供者。(下面讲解)
- Dubbo采用全Spring配置方式,透明化接入应用,对应用没有任何API侵入,只需用Spring加载Dubbo的配置即可,Dubbo基于Spring的Schema扩展进行加载。
15.dubbo架构图如下所示:
讲解他的架构图之前,我们先普及下几个概念。
节点角色说明:
- Provider(生产者): 暴露服务的服务提供方。
- Consumer(消费者): 调用远程服务的服务消费方。
如图,我们可以简单理解为web1234需要调用service1234的服务,所以web1234是消费者,service1234是生产者。
你看着晕不晕?晕不晕?晕不晕?反正我是晕了,万一分布式得更多呢?,所以我们需要他:
Registry(注册中心): 服务注册与发现的注册中心。dubbo推荐的是zookeeper。什么是zookeeper?zookeeper是用于分布式中一致性处理的框架。简单的讲,zookeeper就是个中介,卖楼的(生产者)把楼盘信息放在中介(注册中心)那里,想买楼的(消费者)去中介那里获得楼盘资源清单。于是,我们的图变成了这样:
是不是好很多了?还不够, 我们还需要个监控中心(干嘛用的?当然是监控用的,调用失败怎么办?挂了怎么办?):Monitor: 统计服务的调用次调和调用时间的监控中心。(不画图了)
然后,Provider放在容器里运行,就叫做Container服务运行容器。(不画图了)
最终dubbo架构,如图(从0开始看起):
自己脑海里按照上图走了一遍后,看看自己想的是不是和下面说明一样。
- 服务容器负责启动,加载,运行服务提供者。
- 服务提供者(生产者)在启动时,向注册中心注册自己提供的服务。
- 服务消费者在启动时,向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
- 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
- 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心
来源:buchang.blog.csdn.net/article/details/87371150
作者:CSDN砖家