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 "xxxService" interface = "com.alibaba.xxx.XxxService" url= "dubbo://localhost:20890" /> |
4、负载均衡
当同一个服务有多个提供者在提供服务时。 client怎样正确的选择提供者实现负载均衡dubbo也给我们提供了几种方案
random 随机选提供者,并能够给提供者设置权重
roundrobin 轮询选择提供者
leastactive 最少活跃调用数,同样活跃数的随机。活跃数指调用前后计数差。使慢的提供者收到更少请求,由于越慢的提供者的调用前后计数差会越大。
consistenthash 一致性hash,同样參数的请求发到同一台机器上
5、服务版本号,服务分组
通过服务版本号能够控制服务的不兼容升级, 当同一个服务有多种实现时。能够使用服务分组进行区分
6、多协议
dubbo提供了多种协议给用户选择, 如dubbo、hessian、rmi 。
并可为每一个服务指定不同的传输协议,粒度能够细化到方法。 不同服务在性能上适用不同协议进行传输,比方大数据用短连接协议,小数据大并发用长连接协议。