dubbo官方文档:https://dubbo.apache.org/zh/docs/
负载均衡
- RandomLoadBalance:随机负载均衡,随机的选择一个,可以进行加权。是Dubbo的默认负载均衡策略。
- RoundRobinLoadBalance:轮询负载均衡。按公约后的权重设置轮询比率,循环调用节点。
- LeastActiveLoadBalance:最少活跃调用数,相同活跃数的随机。活跃数越低,越优先调用,相同活跃数的进行加权随机。活跃数指调用前后计数差(针对特定提供者:请求发送数 - 响应返回数),表示特定提供者的任务堆积量,活跃数越低,代表该提供者处理能力越强。使慢的 Provider 收到更少请求,因为越慢的 Provider 的调用前后计数差会越大。
- ShortestResponseLoadBalance:最近一个滑动窗口中,响应时间越短,越优先调用。相同响应时间的进行加权随机。
- ConsistentHashLoadBalance:一致性哈希负载均衡。相同参数的请求总是落在同一台机器上。
集群容错策略
Failover Cluster:失败重试
失败自动切换:当我们在调用Dubbo服务时出现失败,容错策略会重试其它服务器 。一般用于幂等性操作,可以通过配置retries="?"设置重试次数。
<dubbo:reference>
<dubbo:method name="method001"retries="2"/>
</dubbo:reference>
Failfast Cluster:快速失败
当服务消费方调用服务提供者失败后,立即报错,也就是只调用一次。通常用于非幂等性的写操作。
Failsafe Cluster:安全失败
当服务消费者调用服务出现异常时,直接忽略异常。通常用于写入日志等操作。
Failback Cluster:失败自动恢复
服务消费端调用服务出现异常后,在后台记录失败的请求,并按照一定的策略后期再进行重试。这种模式通常用于消息通知操作。
Forking Cluster:并行调用
当消费方调用一个接口方法后,Dubbo Client 会并行调用多个服务提供者的服务,只要一个成功即返回。这种模式通常用于实时性要求较高的读操作,但需要浪费更多服务资源。如下代码可通过 forks=“?” 来设置最大并行数。
<dubbo:reference id="userService"
interface="com.test.UserServiceBo"group="dubbo"version="1.0.0"cluster="forking">
<dubbo:parameter key="forks"value="4"/>
</dubbo:reference>
Broadcast Cluster:广播调用
循环调用所有Dubbo服务提供者,任意一台报错则报错。
使用场景:通用用于向多个实例通知消息,例如:更新集群中所有应用缓存或日志。
Available Cluster
调用目前可用的实例(只调用一个),如果当前没有可用的实例,则抛出异常。通常用于不需要负载均衡的场景。
Mergeable Cluster
将集群中的调用结果聚合起来返回结果,通常和group一起配合使用。通过分组对结果进行聚合并返回聚合后的结果,比如菜单服务,用group区分同一接口的多种实现,现在消费方需从每种group中调用一次并返回结果,对结果进行合并之后返回,这样就可以实现聚合菜单项。
ZoneAware Cluster
多注册中心订阅的场景,注册中心集群间的负载均衡。
多协议
引用参考:https://blog.csdn.net/xiaojin21cen/article/details/79834222
dubbo支持九种协议:
- dubbo协议(默认)
采用单一长连接和NIO异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。
不适合传送大数据量的服务,比如传文件,传视频等,除非请求量很低。
使用Hessian 二进制序列化。 - rmi协议
采用JDK标准的java.rmi.*实现,采用阻塞式短连接和JDK标准序列化方式 。 - Hessian协议
Hessian 协议用于集成 Hessian 的服务,Hessian 底层采用 Http 通讯,采用 Servlet 暴露服务,Dubbo 缺省内嵌 Jetty 作为服务器实现。 - http 协议: 基于http表单的远程调用协议,使用Json序列化。
- webservice 协议:基于 WebService 的远程调用协议,基于 Apache CXF的 frontend-simple 和 transports-http 实现。
- thrift 协议:当前 dubbo 支持的 thrift 协议是对 thrift 原生协议 [2] 的扩展,在原生协议的基础上添加了一些额外的头信息,比如 service name,magic number 等。
- memcached 协议:基于 memcached实现的 RPC 协议。
- redis 协议:基于 Redis实现的 RPC 协议。
- rest ( RestFul)
基于标准的Java REST API——JAX-RS 2.0(Java API for RESTful Web Services的简写)实现的REST调用支持 。
多协议配置
<dubbo:application name="world" />
<dubbo:registry id="registry" address="10.20.141.150:9090" username="admin" password="hello1234" />
<!-- 多协议配置 -->
<dubbo:protocol name="dubbo" port="20880" />
<dubbo:protocol name="rmi" port="1099" />
<!-- 指定使用 dubbo协议 -->
<dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" protocol="dubbo" />
<!-- 指定使用 rmi协议 -->
<dubbo:service interface="com.alibaba.hello.api.DemoService" version="1.0.0" ref="demoService" protocol="rmi" />
<!-- 使用多个协议暴露服务 -->
<dubbo:service id="helloService" interface="com.alibaba.hello.api.HelloService" version="1.0.0" protocol="dubbo,hessian" />
</beans>
注册中心
Dubbo支持的注册中心:
Zookeeper(官方推荐)
- 优点:支持分布式
- 缺点:受限于Zookeeper的特性
Multicast:组播协议
允许将一台主机发送的数据通过网络路由器和交换机复制到多个加入此组播的主机,是一种一对多的通讯方式。每一台服务提供方和服务消费方都可以看作是注册中心的一部分。
- 优点:去中心化,不需要单独安装软件
- 缺点:Provider和Consumer和Registry?不能跨机房(路由)
不需要启动任何中心节点,只要广播地址一样,就可以互相发现,组播受网络结构限制,只适合小规模应用或开发阶段使用。
Redis
- 优点:支持集群,性能高
- 缺点:要求服务器时间同步,否则可能出现集群失败问题
Simple
- 优点:标准RPC服务没有兼容问题
- 缺点:不支持集群