Dubbo亮点总结

Posted 2020-06-21 lcchuguo

Dubbo是阿里巴巴的一个开源RPC项目，可在http://dubbo.io进行訪问

类似的产品有Hessian、spring httpinvoke 等。  

Dubbo的亮点总结例如以下：

1、服务注冊中心

      相比Hessian类RPC框架，Dubbo有自己的服务中心。 写好的服务能够注冊到服务中心。 client从服务中心寻找服务。然后再到对应的服务提供者机器获取服务

      通过服务中心能够实现集群、负载均衡、高可用(容错) 等重要功能

      服务中心一般使用zookeeper实现。 也有redis和其它一些方式 。 以使用zookeeper作为服务中心为例。 服务提供者启动后会在zookeeper的 /dubbo节点下创建提供的服务节点。包括服务提供者ip、port等信息。 服务提供者关闭时会从zookeeper中移除相应的服务。

     服务使用者会从注冊中心zookeeper中寻找服务，同一个服务可能会有多个提供者， Dubbo会帮我们找到合适的服务提供者

2、集群容错

      当服务调用失败时（比方响应超时），依据我们的业务不同，能够使用不同的策略来应对这样的失败。 

      比方我们调用的服务是一个查询服务，不会改动数据库，那么能够给该服务设置容错方式为failover 。 当调用失败时。自己主动切换到其它服务提供者去调用，当失败次数超过指定重试次数，那么就抛出错误。

     假设服务是更新数据的服务，那就不能使用失败重试的方式了。 由于这样可能产生数据反复改动的问题，比方调用提供者A的插入用户方法，可是该方法业务逻辑复杂，运行过程非常慢，导致响应超时， 那么此时假设再去调用另外一个服务提供者的插入用户方法。将会又反复插入同一个用户。

  对于这样的类型的服务，能够使用容错方式为failfast。假设第一次调用失败，马上报错。不须要重试。

    另外还有以下几种容错类型

    failsafe 出现错误。直接忽略。不重试也不报错

    failback 失败后不报错。会将该失败请求，定时重发。适合消息通知类型的服务

   forking    并行调用多个server，仅仅要在某一台提供者上面成功。那么方法返回。 适合实时性要求较高的查询服务， 可是要牺牲性能。由于每台server会做同一个操作

   broadcast 广播调用全部服务提供者，逐个调用，随意一台报错则报错。

 适合与更新每台提供者上面的缓存  这泓类型的服务

3、直连提供者

   在开发阶段为了方便測试。通常系统client能指定调用某个服务提供者，那么能够在引用服务时加一个url參数去指定服务提供者

<dubbo:reference id="xxxService"interface="com.alibaba.xxx.XxxService"url="dubbo://localhost:20890"/>

4、负载均衡

    当同一个服务有多个提供者在提供服务时。 client怎样正确的选择提供者实现负载均衡dubbo也给我们提供了几种方案

    random  随机选提供者，并能够给提供者设置权重

    roundrobin  轮询选择提供者

    leastactive  最少活跃调用数，同样活跃数的随机。活跃数指调用前后计数差。使慢的提供者收到更少请求，由于越慢的提供者的调用前后计数差会越大。

   consistenthash 一致性hash，同样參数的请求发到同一台机器上

5、服务版本号，服务分组

   通过服务版本号能够控制服务的不兼容升级， 当同一个服务有多种实现时。能够使用服务分组进行区分

6、多协议

   dubbo提供了多种协议给用户选择， 如dubbo、hessian、rmi 。

并可为每一个服务指定不同的传输协议，粒度能够细化到方法。 不同服务在性能上适用不同协议进行传输，比方大数据用短连接协议，小数据大并发用长连接协议。