Dubbo

dubbo是什么？

是阿里巴巴开源的基于Java的高性能RPC分布式服务架构

核心能力：面向接口的远程方法调用，智能容错和负载均衡，服务自动注册和发现

 

 

dubbo缺省协议采用单一长连接和nio异步通讯，适合于小数据量大并发的服务调用，以及服务消费机器数远大于服务提供者机器数的情况

特性：1.缺省协议

           2.连接个数：单连接

           3.连接方式：长连接

           4.传输协议：tcp

           5. 传输方式：NIO异步传输

           6.序列化：hessian二进制序列化

          7.适用范围：传入传出参数数据包较小

           8.消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串

          9.适用场景：常规远程服务方法调用

 

       

 

为什么要用Dubbo？

使用dubbo可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可用于提高业务复用，灵活扩展，使前端应用能够响应多变的市场需求

 

dubbo与Spring Cloud的区别？

两个没有关联，区别有几点：

1）通信方式不同 ： dubbo使用RPC通信，Spring Cloud使用Http RestFul通信

2）服务注册中心不同： dubbo使用ZooKeeper   Spring Cloud使用 eureka

 

dubbo内置的服务容器？

Spring Container

Jetty Container

Log4j Container

dubbo的服务容器只是一个简单的main方法，并加载一个简单的spring容器，用于暴露服务

 

dubbo里面的节点角色？

服务提供方 provider

服务消费方 consumer

注册中心 registry

监控中心 monitor

运行容器 container

 

dubbo默认使用ZooKeeper作为注册中心，还有redis，multicast，simple（不推荐）

 

dubbo的配置方式？

1）spring配置

2）java API配置

 

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

1.timeout

2.retries：失败重试次数

3.loadbalance：负载均衡算法（默认随机）

4.actives：消费者端

 

dubbo启动时如果依赖的服务不可用会发生什么？

不可用时会抛出异常，组织Spring初始化

 

dubbo的负载均衡策略？

1）随机，按权重设置随机概率（默认）

2）轮询

3）最少活跃调用数

4）一致性Hash

 

dubbo支持服务多协议吗？

支持，在不同服务上支持不同协议或者在同一服务上同时支持多种协议

 

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

可以用版本号过度，多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用

 

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

dubbo服务默认是同步等待结果阻塞的，支持异步调用

 

容错策略：读操作建议使用failover失败自动切换（默认重试两次其他服务器），写操作建议使用failfast快速失败（失败就报错）

 

dubbo调用过程？

1.服务容器负责启动，加载，运行服务提供者

2.服务提供者在启动时，向注册中心注册自己提供的服务

3.服务消费者在启动时，向注册中心订阅自己所需的服务

4.注册中心返回服务提供者地址列表给服务消费者，如果有变更，将变更数据给消费者

5.服务消费者从提供者地址列表中，基于负载均衡算法，选一台服务器进行调用，调用失败则选另一台

6.服务消费者和提供者，定时发送统计数据到监控中心

 

ZooKeeper宕机与dubbo直连的情况

zookeeper宕机与dubbo直连的情况在面试中可能会被经常问到，所以要引起重视。

在实际生产中，假如zookeeper注册中心宕掉，一段时间内服务消费方还是能够调用提供方的服务的，实际上它使用的本地缓存进行通讯，这只是dubbo健壮性的一种体现。

dubbo的健壮性表现：

1. 监控中心宕掉不影响使用，只是丢失部分采样数据
2. 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
3. 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
4. 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
5. 服务提供者无状态，任意一台宕掉后，不影响使用
6. 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

我们前面提到过：注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。所以，我们可以完全可以绕过注册中心——采用 dubbo 直连 ，即在服务消费方配置服务提供方的位置信息。

 

 

Dubbo在安全机制方面是如何解决的
   通过令牌验证在注册中心控制权限，以决定要不要下发令牌给消费者，可以防止消费者绕过注册中心访问提供者，再通过注册中心灵活改变授权方式，而不需要修改或升级提供者

 

 

为什么ZooKeeper能作为注册中心？

zookeeper就是个分布式文件系统,当你注册服务就是创建了一个znode节点，节点存储了该服务的IP、端口、调用方式。
第一次调用服务，定位服务位置，缓存到本地。再次调用通过负载均衡算法从IP列表中取一个服务提供者的服务器调用服务。
当服务器下线，这个服务也就下线了。再次上线就会缓存新服务ip等信息。

 

 

dubbo的负载均衡

   1.随机：

        按权重设置随机概率，均匀，有利于动态调整提供者权重

  2.轮询：

        按公约后的权重设置轮询比率，存在的问题是慢的提供者累计请求

  3.一致性哈希：

       一致性hash，相同参数的请求总是发到同一提供者，当某台提供者挂掉时，原本发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不会引起剧烈变动
 

 

 

为什么消费者个数要比提供者个数多？

     因为dubbo协议采用单一长连接，假设网络为千兆，理论上一个提供者需要20个服务消费者才能压满网卡

 

为什么采用异步单一长连接？

    因为服务的现状大都是服务提供者少，而服务的消费者多，通过单一长连接，保证单一消费者不会压死提供者，长连接减少了连接握手验证，并且使用异步Io，服务线程池

 

dubbo的隐式传参

   提供方使用RpcContext.getContext().getAttachments()获取参数

    消费方使用RpcContext.getContext().setAttachments()来传递参数

     RpcContext是一个ThreadLocal的临时状态记录器，但是记录时两台机器必须是直接调用，比如A调用B，而不能是A调用C，C调用B，那么B的getStachments（）获取不到任何值

 

dubbo的ref和id？

  service层中引用dubbo服务时，ref的值就是想要暴露的接口的实现类的名字，id的值是要调用的接口的名字

 

分布式服务治理？

  1.比如dubbo有版本号机制，可以用于灰度发布

   2.灵活的负载均衡和路由策略

  3.熔断机制用来避免整个分布式系统产生雪崩

 

为什么服务端尽量多配置消费端的属性？

     1.作为服务的提供者，比消费方更清楚服务性能参数

     2.在提供者端配置后，消费端不配置则会使用服务端的配置

     3.提供端尽量多配置消费端的属性，让提供方实现者能够一开始就思考提供方的服务特点

 

dubbo怎么实现的事务一致性？

   1.通过消息中间件

   2.tcc补偿性事务解决方案

   3.最大努力通知型方案