dubbo基础

1.dubbo是什么？有哪些优点？

是什么？

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用

优点

• 服务注册中心自动注册和配置管理
  它不需要写死服务提供者地址，注册中心基于接口名自动查询提供者ip;
  使用类似zookeeper等分布式协调服务作为服务注册中心，能够将大多数的项目配置移入zookeeper集群;
• 透明化的远程方法调用
  这就好像调用本地方法一样，调用远程方法;
  只需要很简单的配置，没有任何API侵入;
• 服务接口监控和治理
  Dubbo-admin和Dubbo-monitor提供了完善的服务接口管理和监控功能;
  针对不同应用的不同接口，能够进行多版本、多协议、多注册中心管理;
• 软负载均衡及容错机制
  能够在内网替代nginx lvs等硬件负载均衡器;

2.RPC调用与传统HTTP调用的区别？

RPC（即Remote Procedure Call，远程过程调用）和HTTP（HyperText Transfer Protocol，超文本传输协议），,前者是一种方法，后者则是一种协议。两者都常用于实现服务，RPC服务是工作在TCP协议之上的，二http服务工作在http协议，由于http是基于tcp协议的，所以RPC服务天然比HTTP更轻量，效率更高。
详情链接

3.dubbo的服务暴露的基本原理

服务暴露就是提供者（provider）将对应接口的实现类，转化为可调用的invoker（实现者），并导出exporter的过程

• 为什么dubbo，消费者方需要用到动态代理？
  假设现在有A服务器和B服务器，A提供了getUser的服务，B应该如何调用呢？B是不是应该先定义一个A的getUser的一个接口，然后通风动态代理进行调用实现呢？因为B是没有A的getUser实现的，所以B的这个动态代实现的是通过netty网络通信框架进行A中的getUser服务的请求发送。
• 为什么dubbo，提供者方需要用到动态代理？
  当消费者通过动态代理请求到提供方时，提供方接收到消费方传输过来得方法参数，例如方法名，方法参数，版本等，因为提供方可能一个服务下面有多个子服务，所以需要通过传输过来的方法参数动态代理生成具体客户（消费方）需要的具体服务

4.dubbo的服务注册基本原理

我们都知道从理论上来说，其实当provider暴露服务之后comsumer就可以直连然后开始调用服务，注册中心并不是必须的。但是这样的方式不利于服务治理，所以仅在测试环境中可以这样操作，在生产中，注册中心实际上是必不可少的，我们需要依赖注册中心来管理服务的上下线和拉取。

在Dubbo中默认使用Zookeeper作为注册中心，其他类型的注册中心原理也类似。

5.dubbo的服务调用基本原理

首先服务消费者通过代理对象 Proxy 发起远程调用，接着通过网络客户端 Client 将编码后的请求发送给服务提供方的网络层上，也就是 Server。Server 在收到请求后，首先要做的事情是对数据包进行解码。然后将解码后的请求发送至分发器 Dispatcher，再由分发器将请求派发到指定的线程池上，最后由线程池调用具体的服务。这就是一个远程调用请求的发送与接收过程。

6.dubbo的服务容错基本原理

Dubbo容错机制能增强整个应用的健壮性，容错过程对上层用户是完全透明的，但用户也可以通过不同的配置来选择不同的容错机制。每种容错机制又有自己的个性化配置项。Dubbo中现有failover,failfast,failback,failsafe,forking,broadcast,mock,available,mergeable实现

1.Failover
当出现失败时，会重试其他服务器，用户可以通过retries=2设置重试次数，这是dubbo的默认容错机制，会对请求做负载均衡。通常使用在读操作和幂等的写操作上，但重试会导致接口的延迟增大，在下游机器负载已经达到极限时，重试容易加重下游服务的负载。

2.Failfast
快速失败，当请求失败后，快速返回异常结果，不做任何重试，该容错机制会对请求做负载均衡，通常使用在非幂等接口的调用上。该机制受网络波动影响较大

3.Failsafe
当出现异常时，直接忽略异常。会对请求做负载均衡。通常使用在佛系服务，不关心数据是否调用成功，并且不想抛异常影响外层调用，如某些不重要的日志同步，即使出现异常也无所谓

4.failback
请求失败后，会自动记录在失败队列中，并由一个定时线程池定时重试，适用于一些异步或最终一致性的请求。请求会做负载均衡

5.Forking
同时调用多个相同的服务，只要其中一个返回，则立即返回结果，用户可以通过forks来确定最大并行调用数量，使用在对接口实时

6.broadcast
广播调用所有可用的服务，任意一个节点报错则报错，通常用于服务状态更新后的广播

7.mock
提供调用失败时，返回伪造的响应结果，或直接强制返回伪造的结果，不会发起远程调用

8.Available
最简单的方式，请求不会做负载均衡，便利所有服务列表，找到第一个可用的节点，直接请求并返回结果。如果没有可用的节点，则直接抛出异常

9.Mergeable
mergeable可以先把多个请求的结果合并到一起

7.dubbo的服务重试基本原理

Dubbo 服务在尝试调用一次之后，如出现非业务异常(服务突然不可用、超时等)，Dubbo 默认会进行额外的最多2次重试。

重试次数支持两种自定义配置：1、通过注解/xml进行固定配置；2、通过上下文进行运行时动态配置。

1、通过注解/xml进行固定配置
<dubbo:consumer retries="2"></dubbo:consumer>
2、通过RpcContext进行运行时动态配置，优先级高于注解/xml进行的固定配置(两者都配置的情况下，以RpcContext配置为准)
// dubbo服务调用前，通过RpcContext动态设置本次调用的重试次数
RpcContext rpcContext = RpcContext.getContext();
rpcContext.setAttachment("retries", 5);