Dubbo 相关

Dubbo 相关 一、Dubbo 是什么？

Dubbo 是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，现已成为 Apache 基金会孵化项目，官网：http://dubbo.apache.org。dubbo 是一个分布式框架，远程服务调用的分布式框架，其核心部分包含：
1️⃣集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
2️⃣远程通讯：提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
3️⃣自动发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

二、为什么要用 Dubbo？

因为是阿里开源项目，国内很多互联网公司都在用，已经经过很多线上考验。内部使用了 Netty、Zookeeper，保证了高性能高可用性。

使用 Dubbo 可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可用于提高业务复用灵活扩展，使前端应用能更快速的响应多变的市场需求。透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

下图可以很清楚的诠释，最重要的一点是，分布式架构可以承受更大规模的并发流量：

Dubbo 的服务治理图：

三、dubbo都支持什么协议，推荐用哪种？

dubbo://（推荐）rmi://hessian://http://webservice://thrift://memcached://redis://rest:// 四、在使用过程中都遇到了些什么问题？ 如何解决的？

Dubbo 的设计目的是为了满足高并发小数据量的 RPC 调用，在大数据量下的性能表现并不好，建议使用 rmi 或 http 协议。

1️⃣同时配置了 XML 和 properties 文件，则 properties 中的配置无效
只有 XML 没有配置时，properties 才生效。

2️⃣dubbo 缺省会在启动时检查依赖是否可用，不可用就抛出异常，阻止 spring 初始化完成，check 属性默认为 true。
测试时有些服务不关心或者出现了循环依赖，将 check 设置为 false

3️⃣为了方便开发测试，线下有一个所有服务可用的注册中心，这时，如果有一个正在开发中的服务提供者注册，可能会影响消费者不能正常运行。
解决：让服务提供者开发方，只订阅服务，而不注册正在开发的服务，通过直连测试正在开发的服务。设置 dubbo:registry 标签的 register 属性为 false。

4️⃣spring 2.x 初始化死锁问题。
在 spring 解析到 dubbo:service 时，就已经向外暴露了服务，而 spring 还在接着初始化其他 bean，如果这时有请求进来，并且服务的实现类里有调用 applicationContext.getBean() 的用法。getBean 线程和 spring 初始化线程的锁的顺序不一样，导致了线程死锁，不能提供服务，启动不了。

解决：不要在服务的实现类中使用 applicationContext.getBean(); 如果不想依赖配置顺序，可以将 dubbo:provider 的 deplay 属性设置为 - 1，使 dubbo 在容器初始化完成后再暴露服务。

5️⃣服务注册不上
检查 dubbo 的 jar 包有没有在 classpath 中，以及有没有重复的 jar 包
检查暴露服务的 spring 配置有没有加载
在服务提供者机器上测试与注册中心的网络是否通

6️⃣出现 RpcException: No provider available for remote service 异常

表示没有可用的服务提供者，
a. 检查连接的注册中心是否正确
b. 到注册中心查看相应的服务提供者是否存在
c. 检查服务提供者是否正常运行

7️⃣出现” 消息发送失败” 异常
通常是接口方法的传入传出参数未实现 Serializable 接口。

8️⃣服务找不到。解决思路：检查连接注册中心是否正确；检查服务提供者是否在线。

9️⃣服务调用超时。解决思路：服务端接口调优；调大 timeout 时间。

1️⃣0️⃣连接池满。解决思路：调整连接池大小，增加机器，优化服务端接口提高响应速度。

五、Dubbo 需要 Web 容器吗？

不需要，如果硬要用 Web 容器，只会增加复杂性，也浪费资源。

六、Dubbo内置了哪几种服务容器？

Spring ContainerJetty ContainerLog4j Container

Dubbo 的服务容器只是一个简单的 Main 方法，并加载一个简单的 Spring 容器，用于暴露服务。

七、Dubbo里面有哪几种节点角色？

八、Dubbo服务注册与发现的流程

服务提供者在启动时，向注册中心注册自己提供的服务。服务消费者在启动时，向注册中心订阅自己所需的服务。注册中心返回服务提供者地址列表给消费者。如果有变更，注册中心将基于 TCP 长连接推送变更数据给消费者。服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者基于 TCP 协议进行调用，如果调用失效，再选另一台调用。

九、Dubbo默认使用什么注册中心，还有别的选择吗？

推荐使用 Zookeeper 作为注册中心。ZooKeeper 的节点是通过像树一样的结构来进行维护的，并且每一个节点通过路径来标示以及访问。除此之外，每一个节点还拥有自身的一些信息，包括：数据、数据长度、创建时间、修改时间等等。还有 Redis、Multicast、Simple 注册中心，但不推荐。

十、Dubbo有哪几种配置方式？

Spring 配置方式Java API 配置方式

十一、Dubbo 核心的配置有哪些？

配置之间的关系见下图：

十二、在 Provider 上可以配置的 Consumer 端的属性有哪些？

timeout：方法调用超时retries：失败重试次数，默认重试 2 次loadbalance：负载均衡算法，默认随机actives 消费者端，最大并发调用限制

十三、Dubbo启动时如果依赖的服务不可用会怎样？

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，默认 check=“true”，可以通过 check=“false” 关闭检查。

十四、Dubbo推荐使用什么序列化框架，还有哪些？

默推荐使用 Hessian 序列化，还有 Duddo、FastJson、Java 自带序列化。 hessian是一个采用二进制格式传输的服务框架，相对传统soap web service，更轻量，更快速。

Hessian原理与协议简析：
http的协议约定了数据传输的方式，hessian也无法改变太多：
1️⃣hessian中client与server的交互，基于http-post方式。
2️⃣hessian将辅助信息，封装在http header中，比如“授权token”等，我们可以基于http-header来封装关于“安全校验”“meta数据”等。hessian提供了简单的”校验”机制。
3️⃣对于hessian的交互核心数据，比如“调用的方法”和参数列表信息，将通过post请求的body体直接发送，格式为字节流。
4️⃣对于hessian的server端响应数据，将在response中通过字节流的方式直接输出。

hessian的协议本身并不复杂，在此不再赘言；所谓协议(protocol)就是约束数据的格式，client按照协议将请求信息序列化成字节序列发送给server端，server端根据协议，将数据反序列化成“对象”，然后执行指定的方法，并将方法的返回值再次按照协议序列化成字节流，响应给client，client按照协议将字节流反序列话成”对象”。

十五、Dubbo默认使用的是什么通信框架，还有别的选择吗？

Dubbo 默认使用 Netty 框架，也是推荐的选择。还有Mina、Grizzly。

十六、Dubbo有哪几种集群容错方案，默认是哪种？

读 *** 作建议使用 Failover 失败自动切换，默认重试两次其他服务器。写 *** 作建议使用 Failfast 快速失败，发一次调用失败就立即报错。

十七、Dubbo有哪四种负载均衡策略，默认是哪种？

十八、一致性Hash算法的原理是什么？

将对应的key哈希到一个具有2^32次方的环上，形成一个闭环将机器通过hash算法映射到环上，把数据通过一定的hash算法处理后映射到环上，然后顺时针找到离自己最近的机器节点

十九、注册了多个同样的服务，如果测试指定的某一个服务呢？

可以配置环境点对点直连，绕过注册中心，将以服务接口为单位，忽略注册中心的提供者列表。也可以通过 telnet 直接某个服务。

二十、Dubbo支持服务多协议吗？

默认使用 dubbo 协议。Dubbo 允许配置多协议，在不同服务上支持不同协议或者同一服务上同时支持多种协议。

二十一、当一个服务接口有多种实现时怎么做？

当一个接口有多种实现时，可以用 group 属性来分组，服务提供方和消费方都指定同一个 group 即可。

二十二、服务上线怎么兼容旧版本？

可以用版本号(version)过渡，多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用。这个和服务分组的概念有一点类似。

二十三、Dubbo可以对结果进行缓存吗？

可以，Dubbo 提供了声明式缓存，用于加速热门数据的访问速度，以减少用户加缓存的工作量。

二十四、Dubbo服务之间的调用是阻塞的吗？

默认是同步等待结果阻塞的。支持异步调用，没有返回值的可以这么做。

Dubbo 是基于 NIO 的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小，异步调用会返回一个 Future 对象。

异步调用流程图：

二十五、Dubbo支持分布式事务吗？

目前暂时不支持，后续可能采用基于 JTA/XA 规范实现，如图：

二十六、Dubbo telnet 命令能做什么？

dubbo 通过 telnet 命令来进行服务治理，具体使用看这篇文章《dubbo服务调试管理实用命令》。

二十七、Dubbo支持服务降级吗？

Dubbo 2.2.0 以上版本支持。

二十八、Dubbo如何优雅停机？

Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的，所以如果使用 kill -9 PID 等强制关闭指令，是不会执行优雅停机的，只有通过 kill PID 时，才会执行。

二十九、服务提供者能实现失效踢出是什么原理？

服务失效踢出基于 Zookeeper 的临时节点原理。

三十、如何解决服务调用链过长的问题？

Dubbo 可以使用 Pinpoint、Apache Skywalking(Incubator) 或者zipkin实现分布式服务追踪，当然还有其他很多方案。

三十一、服务读写推荐的容错策略是怎样的？

读 *** 作建议使用 Failover 失败自动切换，默认重试两次其他服务器。

写 *** 作建议使用 Failfast 快速失败，发一次调用失败就立即报错。

三十二、Dubbo必须依赖的包有哪些？

Dubbo 必须依赖 JDK，其他为可选。

三十三、Dubbo的管理控制台能做什么？

管理控制台主要包含：路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等管理功能。

三十四、说说 Dubbo 服务暴露的过程。

Dubbo 会在 Spring 实例化完 bean 之后，在刷新容器最后一步发布 ContextRefreshEvent 事件的时候，通知实现了 ApplicationListener 的 ServiceBean 类进行回调 onApplicationEvent 事件方法，Dubbo 会在这个方法中调用 ServiceBean 父类 ServiceConfig 的 export 方法，而该方法真正实现了服务的(异步或者非异步)发布。

三十五、Dubbo 和 Dubbox 有什么区别？

Dubbox 是继 Dubbo 停止维护后，当当网基于 Dubbo 做的一个扩展项目，如加了服务可 Restful 调用，更新了开源组件等。

三十六、注册中心挂了，服务能否正常调用？(PS：dubbo有缓存)

能。启动 dubbo 时，消费者会从 zookeeper 拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用。(dubbo服务调用是消费者与提供者直接TCP连接调用，不经过zookeeper。)

三十七、Dubbo 能集成 Spring Boot 吗？

可以的，项目地址如下。

https://github.com/apache/incubator-dubbo-spring-boot-project

三十八、Dubbo 和 Spring Cloud 有什么区别？

两个没关联，如果硬要说区别，有以下几点。

通信方式不同
Dubbo 使用的是 RPC 通信，而 Spring Cloud 使用的是 HTTP RESTFul 方式。

组成部分不同

三十九、Dubbo 好还是 Spring Cloud 好？

扩展性的问题，没有好坏，只有适合不适合。个人倾向 dubbo，Spring Cloud 版本升级太快，组件更新替换太频繁，配置太繁琐，还有很多没有 Dubbo 顺手的地方。

四十、dubbo 在安全机制方面如何解决的？

dubbo 通过 token 令牌防止用户绕过注册中心直连，然后在注册中心管理授权，dubbo 提供了黑白名单，控制服务所允许的调用方。

四十一、服务调用超时问题怎么解决

dubbo 在调用服务不成功时，默认是会重试两次的。这样在服务端的处理时间超过了设定的超时时间时，就会有重复请求，比如在发邮件时，可能就会发出多份重复邮件，执行注册请求时，就会插入多条重复的注册数据，那么如何解决超时问题呢？

对于核心的服务，去除 dubbo 超时重试机制，并重新评估设置超时时间。 业务处理代码必须放在服务端，客户端只做参数验证和服务调用，不涉及业务流程处理全局配置实例：

当然 Dubbo 的重试机制其实是非常好的 QOS 保证，它的路由机制，是会把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo 的重试机制也能一定程度的保证服务的质量。但是请一定要综合线上的访问情况，给出综合的评估。