- 1、Dubbo是什么?
- 2、为什么要用Dubbo?
- 3、Dubbo 和Spring Cloud 有什么区别?
- 4、dubbo都支持什么协议,推荐用哪种?
- 5、Dubbo需要Web 容器器吗?
- 6、Dubbo内置了哪几种服务容器?
- 7、Dubbo里面有哪几种节点角色?
- 8、服务注册与发现的流程图
- 9、Dubbo默认使用什么注册中心,还有别的选择吗?
- 10、Dubbo有哪几种配置方式?
- 11、Dubbo 核心的配置有哪些?
- 12、在 Provider 上可以配置的Consumer 端的属性有哪些?
- 13、Dubbo启动时如果依赖的服务不可用会怎样?
- 14、Dubbo推荐使用什么序列化框架,还有哪些?
- 15、Dubbo默认使用的是什么通信框架,还有别的选择吗?
- 16、Dubbo有哪几种集群容错方案,默认是哪种?
- 17、Dubbo有哪几种负载均衡策略略,默认是哪种?
- 18、注册了多个同一样的服务,如果测试指定的某一个服务呢?
- 19、Dubbo支持服务多协议吗?
- 20、当一个服务接口有多种实现时怎么做?
- 21、服务上线怎么兼容旧版本?
- 22、Dubbo可以对结果进行缓存吗?
- 23、Dubbo服务之间的调用是阻塞的吗?
- 24、Dubbo支持分布式事务吗?
- 25、Dubbo的telnet 命令能做什么?
- 26、Dubbo支持服务降级吗?
- 27、Dubbo如何优雅停机?
- 28、服务提供者能实现失效踢出是什么原理?
- 29、如何解决服务调用链过长的问题?
- 30、服务读写推荐的容错策略略是怎样的?
- 31、Dubbo必须依赖的包有哪些?
- 32、Dubbo的管理控制台能做什么?
- 33、说说 Dubbo 服务暴露的过程。
- 34、Dubbo 停止维护了吗?
- 35、Dubbo 和Dubbox 有什么区别?
- 36、还了解别的分布式框架吗?
- 37、Dubbo 能集成Spring Boot 吗?
- 38、在使用过程中都遇到了些什么问题?
- 39、用 Dubbo 好还是Spring Cloud 好?
- 40、注册中心挂了,消费者还能调用服务者吗?
- 41、Dubbo的好处?
- 42、Dubbo架构图如下所示:
1、Dubbo是什么?
Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架,现已成为 Apache 基金会孵化项目。
Dubbo是一个分布式框架,远程服务调用的分布式框架,其核心部分包含:
集群容错:提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。
远程通讯:提供对多种长连接的NIO框架抽象封装,包括多种线程模型,序列化,以及“请求-响应”模式的信息交换方式。
自动发现:基于注册中心目录服务,使消费提供方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。
官网:http://dubbo.apache.org
2、为什么要用Dubbo?
因为是阿里巴巴开源项目,国内很多互联网公司都在用,已经过很多线上考验。内部使用了 Netty、Zookeeper,保证了高性能高可用性。
使用 Dubbo 可以将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,可用于提高业务复用灵活扩展,使前端应用能更快速的响应多变的市场需求。
透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需要简单配置,没有任何API入侵。软负载均衡及容错机制,可以在内网替代F5等硬件负载均衡器。降低成本,减少单点。服务自动注册与发现,不在需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或删除服务提供者。
3、Dubbo 和Spring Cloud 有什么区别?
1)通信方式不不同
1、Dubbo 使用的是 RPC 通信,而 Spring Cloud使用的是 HTTP RESTFul 方式。
2、dubbo由于是二进制的传输,占用带宽会更少(基于netty等);springCloud是http协议传输,带宽会比较多,同时使用http协议(http+restful api)一般会使用JSON报文,消耗会更大。
3、dubbo的开发难度较大,原因是dubbo的jar包依赖(存在代码级别的强依赖)问题很多大型工程无法解决;
springcloud的接口协议约定比较自由且松散,需要有强有力的行政措施来限制接口无序升级。
4、dubbo的改进是通过dubbo filter,很多东西没有,需要自己继承,如监控,如日志,如限流,如追踪。
springcloud具有配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等,满足了构建微服务所需的所有解决方案。
2)组成部分不同
核心要素 | Dubbo | Spring Cloud |
---|---|---|
服务注册中心 | Zookeeper、Redis | Spring Cloud Netlix Eureka |
服务调用方式 | RPC | REST API |
服务网关 | 无 | Spring Cloud Netflix Zuul |
断路器 | 不完善 | Spring Cloud Netflix Hystrix |
分布式配置 | 无 | Spring Cloud Config |
消息总线 | 无 | Spring Cloud Bus |
数据流 | 无 | Spring Cloud Stream基于Redis,RabbitKafka实现的消息微服务 |
批量任务 | 无 | Spring Cloud Task |
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里面有哪几种节点角色?
- Provider:暴露服务的服务提供方。
- Consumer:调用远程服务的服务消费方。
- Regitry: 服务注册与发现的注册中心。
- Monitor: 统计服务的调用次调和调用时间的监控中心。
- Container: 服务运行容器。
8、服务注册与发现的流程图
9、Dubbo默认使用什么注册中心,还有别的选择吗?
推荐使用 Zookeeper 作为注册中心,还有 Redis、Multicast、Simple 注册中心,但不推荐。
redis方案需要服务器时间同步,且性能消耗过大。10、Dubbo有哪几种配置方式?
1)Spring 配置方式
2)Java API 配置方式11、Dubbo 核心的配置有哪些?
| 配置 | 配置说明 | | —- | —- | | dubbo. service | 服务配置 | | dubbo.reference | 引用配置 | | dubbo: protocol | 协议配置 | | dubbo: application | 应用配置 | | dubbo: module | 模块配置 | | dubbo.registry | 注册中心配置 | | dubbo.registry | 监控中心配置 | | dubbo: monitor | 监控中心配置 | | dubbo provider | 提供方配置 | | dubbo.consumer | 消费方配置 | | dubbo: method | 方法配置 | | dubbo: argument | 参数配置 |
12、在 Provider 上可以配置的Consumer 端的属性有哪些?
1)timeout:方法调用超时
2)retries:失败重试次数,默认重试 2 次
3)loadbalance:负载均衡算法,默认随机
4)actives: 消费者端,最大并发调用限制
13、Dubbo启动时如果依赖的服务不可用会怎样?
Dubbo 缺省会在启动时检查依赖的服务是否可用,不可用时会抛出异常,阻止 Spring 初始化完成,默认 check="true"
,可以通过 check="false"
关闭检查。
14、Dubbo推荐使用什么序列化框架,还有哪些?
推荐使用Hessian序列化,还有Duddo、FastJson、Java自带序列化。
15、Dubbo默认使用的是什么通信框架,还有别的选择吗?
Dubbo 默认使用 Netty 框架,也是推荐的选择,另外内容还集成有Mina、Grizzly。
16、Dubbo有哪几种集群容错方案,默认是哪种?
17、Dubbo有哪几种负载均衡策略略,默认是哪种?
18、注册了多个同一样的服务,如果测试指定的某一个服务呢?
可以配置环境点对点直连,绕过注册中心,将以服务接口为单位,忽略注册中心的提供者列表。
19、Dubbo支持服务多协议吗?
Dubbo 允许配置多协议,在不同服务上支持不同协议或者同一服务上同时支持多种协议。
20、当一个服务接口有多种实现时怎么做?
当一个接口有多种实现时,可以用 group 属性来分组,服务提供方和消费方都指定同一个 group 即可。
21、服务上线怎么兼容旧版本?
可以用版本号(version)过渡,多个不同版本的服务注册到注册中心,版本号不同的服务相互间不引用。这个和服务分组的概念有一点类似。
22、Dubbo可以对结果进行缓存吗?
可以,Dubbo 提供了声明式缓存,用于加速热门数据的访问速度,以减少用户加缓存的工作量。
23、Dubbo服务之间的调用是阻塞的吗?
默认是同步等待结果阻塞的,支持异步调用。
Dubbo 是基于 NIO 的非阻塞实现并行调用,客户端不需要启动多线程即可完成并行调用多个远程服务,相对多线程开销较小,异步调用会返回一个 Future 对象。
24、Dubbo支持分布式事务吗?
25、Dubbo的telnet 命令能做什么?
dubbo 通过 telnet 命令来进行服务治理
telnet localhost 8090
26、Dubbo支持服务降级吗?
27、Dubbo如何优雅停机?
Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的,所以如果使用 kill -9 PID 等强制关闭指令,是不会执行优雅停机的,只有通过 kill PID 时,才会执行。
28、服务提供者能实现失效踢出是什么原理?
服务失效踢出基于 Zookeeper 的临时节点原理。 (服务机器会在zk上注册一个临时节点,服务失效则临时节点被删除)
29、如何解决服务调用链过长的问题?
Dubbo 可以使用 Pinpoint 和 Apache Skywalking(Incubator) 实现分布式服务追踪,当然还有其他很多方案。
30、服务读写推荐的容错策略略是怎样的?
读操作建议使用 Failover 失败自动切换,默认重试两次其他服务器。写操作建议使用 Failfast 快速失败,发一次调用失败就立即报错。
31、Dubbo必须依赖的包有哪些?
32、Dubbo的管理控制台能做什么?
管理控制台主要包含:路由规则,动态配置,服务降级,访问控制,权重调整,负载均衡,等管理功能。
33、说说 Dubbo 服务暴露的过程。
Dubbo 会在 Spring 实例化完 bean 之后,在刷新容器最后一步发布 ContextRefreshEvent 事件的时候,通知实现了ApplicationListener 的 ServiceBean 类进行回调 onApplicationEvent 事件方法,Dubbo 会在这个方法中调用 ServiceBean 父类ServiceConfig 的 export 方法,而该方法真正实现了服务的(异步或者非异步)发布。
34、Dubbo 停止维护了吗?
2014 年开始停止维护过几年,17 年开始重新维护,并进入了 Apache 项目。
35、Dubbo 和Dubbox 有什么区别?
Dubbox 是继 Dubbo 停止维护后,当当网基于 Dubbo 做的一个扩展项目,如加了服务可 Restful 调用,更新了开源组件等。
36、还了解别的分布式框架吗?
别的还有 Spring cloud、Facebook 的 Thrift、Twitter 的 Finagle 等。
37、Dubbo 能集成Spring Boot 吗?
可以的,项目地址如下。https://github.com/apache/incubator-dubbo-spring-boot-project
38、在使用过程中都遇到了些什么问题?
单一长连接和NIO异步通讯,适合大并发小数据量的服务调用,以及消费者远大于提供者。Dubbo 的设计目的是为了满足高并发小数据量的 rpc 调用,在大数据量下的性能表现并不好,建议使用 rmi 或 http 协议。
39、用 Dubbo 好还是Spring Cloud 好?
扩展性的问题,没有好坏,只有适合不适合,Spring Cloud 版本升级太快,组件更新替换太频繁,配置太繁琐。
40、注册中心挂了,消费者还能调用服务者吗?
- 注册中心对等集群,任意一台宕掉后,会自动切换到另一台
- 注册中心全部宕掉,服务提供者和消费者仍可以通过本地缓存通讯
- 服务提供者无状态,任一台宕机后,不影响使用
- 服务提供者全部宕机,服务消费者会无法使用,并无限次重连等待服务者恢复
41、Dubbo的好处?
- 透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需简单配置,没有任何API侵入。
- 软负载均衡及容错机制,可在内网替代F5等硬件负载均衡器,降低成本,减少单点。
- 服务自动注册与发现,不再需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或删除服务提供者。(下面讲解)
Dubbo采用全Spring配置方式,透明化接入应用,对应用没有任何API侵入,只需用Spring加载Dubbo的配置即可,Dubbo基于Spring的Schema扩展进行加载。
42、Dubbo架构图如下所示:
讲解他的架构图之前,先普及下几个概念。
节点角色说明:Provider(生产者): 暴露服务的服务提供方。
- Consumer(消费者): 调用远程服务的服务消费方。
如图,可以简单理解为web1234需要调用service1234的服务,所以web1234是消费者,service1234是生产者。
如果按照上面,消费者调用生产者的服务,就会如下图:
看着晕不晕?万一分布式得更多呢?,所以需要他:
Registry(注册中心): 服务注册与发现的注册中心。dubbo推荐的是zookeeper。什么是zookeeper?zookeeper是用于分布式中一致性处理的框架。简单的讲,zookeeper就是个中介,卖楼的(生产者)把楼盘信息放在中介(注册中心)那里,想买楼的(消费者)去中介那里获得楼盘资源清单。于是图变成了这样:
是不是好很多了?还不够, 我们还需要个监控中心(干嘛用的?当然是监控用的,调用失败怎么办?挂了怎么办?):Monitor: 统计服务的调用次调和调用时间的监控中心。(不画图了)
然后,Provider放在容器里运行,就叫做Container服务运行容器。(不画图了)
最终dubbo架构,如图(从0开始看起):
- 服务容器负责启动,加载,运行服务提供者。
- 服务提供者(生产者)在启动时,向注册中心注册自己提供的服务。
- 服务消费者在启动时,向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
- 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
- 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心