Dubbo相关小计

简介：Dubbo是一个分布式服务框架，以及SOA治理方案。其功能主要包括：高性能NIO通讯及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与降级等。

底部NIO基于netty框架

使用Dubbo的RPC来实现服务间调用的一些痛点
1、服务提供方与调用方接口依赖方式太强：REST方式的服务依赖要比RPC方式的依赖更为灵活。

2、在Dubbo中我们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。
若我们每个服务本身就以REST接口方式存在，当要对外提供服务时，
主要在API网关中配置映射关系和权限控制就可实现服务的复用了。

也是为什么当当网在dubbox（基于Dubbo的开源扩展）中增加了对REST支持的原因之一

------------------------RPC-------------------------
全称为 remote procedure call，即远程过程调用
RPC 并不是一个具体的技术，而是指整个网络远程调用过程。
RPC 是一个泛化的概念，严格来说一切远程过程调用手段都属于 RP C范畴。
各种开发语言都有自己的 RPC 框架。Java 中的 RPC 框架比较多，广泛使用的有 RMI、Hessian、Dubbo 等。

------------------------原理-------------------------

服务消费方（client）调用以本地调用方式调用服务。客户端存根（client stub）接收到调用后负责将方法、参数等编码成能在网络中传输的消息体。然后，客户端存根找到服务地址后，将消息发送给服务端。

服务提供方（server）收到序列化后的消息，就按照解码该消息。然后，根据解码结果调用本地服务，执行完毕后，将结果打包发送给消费方。

服务消费方收到执行结果后，也是进行解码后得到结果

-----------------------dubbo过期时间------超时设置----------------
服务调用超时问题怎么解决？
dubbo 在调用服务不成功时，默认是会重试两次的。

Dubbo消费端
全局超时配置
<dubbo:consumer timeout="5000" />
指定接口以及特定方法超时配置
<dubbo:reference interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:reference>

Dubbo服务端
全局超时配置
<dubbo:provider timeout="5000" />
指定接口以及特定方法超时配置
<dubbo:provider interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:provider>

-----------------------核心功能-------------------------

Remoting：远程通讯，提供对多种 NIO 框架抽象封装，包括“同步转异步”和“请求-响应”模式的信息交换方式。
Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
Registry：服务注册中心，服务自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

-----------------------核心组件----------------------

Provider：服务的提供方
Consumer：调用远程服务的服务消费方
Registry：服务注册和发现的注册中心
Monitor：统计服务调用次数和调用时间的监控中心
Container：服务运行容器

Consumer 与 Provider 解偶，双方都可以横向增减节点数。
注册中心对本身可做对等集群，可动态增减节点，并且任意一台宕掉后，将自动切换到另一台
服务提供者无状态，任意一台宕掉后，不影响使用

分布式系统的服务治理框架
Dubbo 是一个分布式、高性能、透明化的 RPC 服务框架，提
供服务自动注册、自动发现等高效服务治理方案， 可以和
Spring 框架无缝集成。

1、透明化的远程方法调用
2、软负载均衡机制：随机（默认的负载均衡策略），轮循，最少活跃调用数，一致性 Hash
3、容错重试机制
4、服务自动注册与发现
5、性能日志监控：Monitor 统计服务的调用次调和调用时间的监控中心
6、服务治理中心：路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等手动配置

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

Dubbo 集群容错有几种方案？                6种
集群容错方案 说明
Failover Cluster 失败自动切换，自动重试其它服务器（默认）
Failback Cluster 失败自动恢复，记录失败请求，定时重发：调用失败，记录日志和调用信息，返回空结果
Failfast Cluster 快速失败，只调用一次，失败立即抛出异常
Failsafe Cluster 失败安全，出现异常时，记录日志不抛出，返回空结果
Forking Cluster 并行调用多个服务器，只要一个成功即返回：通过线程池创建多个线程，并发调用多个provider,结果保存到阻塞队列，只要有一个返回成功，就立即返回结果；
Broadcast Cluster 广播逐个调用所有提供者，任意一个报错则报错；在循环调用结束后，抛出异常

都有哪些负载均衡策略？    4种
1、加权随机
2、最小活跃数，说明性能好，处理速度快
3、一致性hash：通过hash算法，把provider的invoke和随机节点生成hash,并将这个hash映射到[0, 2^23-1]的圆环上，查询的时候根据key进行md5然后进行hash,
4、加权轮询

-------------工作流程---------------
整体流程：
第一步：provider 向注册中心去注册
第二步：consumer 从注册中心订阅服务，注册中心会通知 consumer 注册好的服务
第三步：consumer 调用 provider
第四步：consumer 和 provider 都异步通知监控中心

------------------Dubbo的工作原理--------------------
1、服务启动的时候，provider和consumer根据配置信息，连接到注册中心register,分别向注册中心注册和订阅服务
2、register根据服务订阅关系，返回provider信息到consumer,同时consumer会把provider信息缓存到本地，如果信息有变更，consumer会受到来自register的推送
3、consumer生成代理对象，同时根据负载均衡策略，选择一台provider,同时定时向monitor记录接口的调用次数和时间信息
4、拿到代理对象后，consumer通过代理对象发起接口调用
5、provider收到请求后对数据进行反序列化，然后通过代理调用具体的接口实现

为什么要通过代理对象通信
主要是为了实现接口的透明代理，封装调用细节，让用户可以像调用本地方法一样调用远程方法，同时还可以通过代理实现一些其他的策略，
1、调用的负载均衡策略
2、调用失败，超时，降级和容错机制
3、做一些过滤操作，比如加入缓存，mock数据
4、接口调用数据统计

Dubbo SPI机制？没有使用Java原生的spi,而是对其进行了增强和改进
是一种服务发现机制，本质是将接口实现类的全限定名配置在文件中，由服务加载器读取配置文件，加载实现类，这样可以在运行时，动态为接口替换实现类，

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

一般使用什么注册中心？还有别的选择吗？
推荐使用 Zookeeper 作为注册中心，还有 Redis、Multicast、Simple 注册中
心，但不推荐

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

如何解决服务调用链过长的问题？
可以结合 zipkin 实现分布式服务追踪。

、说说核心的配置有哪些？
配置 配置说明
dubbo:service 服务配置
dubbo:reference 引用配置
dubbo:protocol 协议配置
dubbo:application应用配置
dubbo:module 模块配置
dubbo:registry 注册中心配置
dubbo:monitor 监控中心配置
dubbo:provider 提供方配置
dubbo:consumer 消费方配置
dubbo:method 方法配置
dubbo:argument 参数配置

Dubbo 服务降级，失败重试怎么做？
可以通过 dubbo:reference 中设置 mock="return null"。mock 的值也可以修
改为 true，然后再跟接口同一个路径下实现一个 Mock 类，命名规则是 “接口
名称+Mock” 后缀。然后在 Mock 类里实现自己的降级逻辑

Dubbo 支持分布式事务吗？
目前暂时不支持，可与通过 tcc-transaction 框架实现

Dubbo 可以对结果进行缓存吗？

为了提高数据访问的速度。Dubbo 提供了声明式缓存，以减少用户加缓存的工作
量
<dubbo:reference cache="true" />
其实比普通的配置文件就多了一个标签 cache="true"

Dubbo 必须依赖的包有哪些？
Dubbo 必须依赖 JDK，其他为可选。

Dubbo telnet 命令能做什么？
dubbo 服务发布之后，我们可以利用 telnet 命令进行调试、管理。
Dubbo2.0.5 以上版本服务提供端口支持 telnet 命令

Dubbo 和 Spring Cloud 的区别？
根据微服务架构在各方面的要素，看看 Spring Cloud 和 Dubbo 都提供了哪些支持。
Dubbo             Spring Cloud
服务注册中心 Zookeeper     Spring Cloud Netflix Eureka
服务调用方式 RPC         REST API
服务网关 无     Spring Cloud Netflix Zuul
断路器 不完善     Spring Cloud Netflix Hystrix
分布式配置 无     Spring Cloud Config
服务跟踪 无     Spring Cloud Sleuth
消息总线 无     Spring Cloud Bus
数据流 无         Spring Cloud Stream
批量任务 无     Spring Cloud Task

使用 Dubbo 构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但
是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，
但是如果你是一名高手，那这些都不是问题；而 Spring Cloud 就像品牌机，在
Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，
但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解

Dubbo 提供了常见的集群策略实现，并预扩展点予以自行实现。
 Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀；
 RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，但是存在请求累积的问题；
 LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求；
 ConstantHash LoadBalance: 一致性 Hash 策略，使相同参数请求总是发到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动；

Dubbo 的核心功能？
主要就是如下 3 个核心功能：
1、Remoting：网络通信框架，提供对多种 NIO 框架抽象封装，包括
“同步转异步”和“请求-响应”模式的信息交换方式。
2、Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多
协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群
支持。
3、Registry：服务注册，基于注册中心目录服务，使服务消费方能动态
的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少
机器。

设计的原因：
 Consumer 与 Provider 解偶，双方都可以横向增减节点数。
 注册中心对本身可做对等集群，可动态增减节点，并且任意一台宕掉后，将自动切换到另一台
 去中心化，双方不直接依懒注册中心，即使注册中心全部宕机短时间内也不会影响服务的调用
 服务提供者无状态，任意一台宕掉后，不影响使用

Dubbo 在安全机制方面是如何解决？
Dubbo 通过 Token 令牌防止用户绕过注册中心直连，然后在注册中
心上管理授权。Dubbo 还提供服务黑白名单，来控制服务所允许的调
用方。

集群容错怎么做？
答：读操作建议使用 Failover 失败自动切换，默认重试两次其他服务器。
写操作建议使用 Failfast 快速失败，发一次调用失败就立即报错。

Dubbo 和 Spring Cloud 的关系？

Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流
量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时
代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、
Spirng Boot 的优势之上，两个框架在开始目标就不一致，Dubbo
定位服务治理、Spirng Cloud 是一个生态。

最大的区别：
Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于
TCP 协议传输的，配合以 Hession 序列化完成 RPC 通信。

而 SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的通信，
相对来说，Http 请求会有更大的报文，占的带宽也会更多。但是
REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契
约，不存在代码级别的强依赖。

 dubbo 通信协议 dubbo 协议为什么采用异步单一长连接：
因为服务的现状大都是服务提供者少，通常只有几台机器，
而服务的消费者多，可能整个网站都在访问该服务，
比如 Morgan 的提供者只有 6 台提供者，却有上百台消费者，每天有 1.5 亿次调用，
如果采用常规的 hessian 服务，服务提供者很容易就被压跨，
通过单一连接，保证单一消费者不会压死提供者，
长连接，减少连接握手验证等，
并使用异步 IO，复用线程池，防止 C10K 问题。

dubbo 通信协议 dubbo 协议适用范围和适用场景
适用范围：传入传出参数数据包较小（建议小于 100K），消费者比提供者个数
多，单一消费者无法压满提供者，尽量不要用 dubbo 协议传输大文件或超大字
符串。
适用场景：常规远程服务方法调用
dubbo 协议补充：
连接个数：单连接
连接方式：长连接
传输协议：TCP
传输方式：NIO 异步传输
序列化：Hessian 二进制序列化

Dubbo 协议(官方推荐协议)
优点：采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好（推荐使用）
缺点：大文件上传时,可能出现问题(不使用 Dubbo 文件上传)

动态代理策略
默认使用 javassist 动态字节码生成，创建代理类。也可以通过 spi 扩展机制配置自己的动态代理策略

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

集群容错方案
配置说明，方案配置方式，优先使用消费端配置

<!--服务端配置-->
<dubbo:service cluster="failover"/>
<!--消费端配置-->
<dubbo:reference cluster="failover"/>

etries:重试次数，不包括第一次，默认2次
-->
<dubbo:service cluster="failover" retries="3"/>

@EnableDubbo

@DubboReference

@DubboService

@EnableDubbo整合了三个注解@EnableDubboConfig、@DubboComponentScan、@EnableDubboLifecycle。@EnableDubbo的功能都是由这三个注解完成的。

@EnableDubboConfig引入类DubboConfigConfigurationRegistrar，将用于解析配置相关的类注册到spring容器；
@DubboComponentScan引入类DubboComponentScanRegistrar，用于指定@Service扫描路径；
@EnableDubboLifecycle引入类DubboLifecycleComponentRegistrar，注册了两个监听器到spring容器。