1.Provide端尽量多配置Consumer端属性
<dubbo:service interface="com.alibaba.hello.api.WorldService" version="1.0.0" ref="helloService"
timeout="300" retry="2" loadbalance="random" actives="0" >
<dubbo:method name="findAllPerson" timeout="10000" retries="9" loadbalance="leastactive" actives="5" />
<dubbo:service/>
属性解释:
- timeout 接口超时响应
- retries 失败重试次数
缺省是2(不含第一次),多次重试一般用于读操作,如果是写操作要确保实现幂等性
- loadbalance 负载均衡算法
缺省是随机 random
还可以有轮询 roundrobin
最不活跃优先 leastactive
- actives 消费者端,最大并发调用限制,即当 Consumer 对一个服务的并发调用到上限后,新调用会 Wait 直到超时 在方法上配置 dubbo:method 则并发限制针对方法,在接口上配置 dubbo:service,则并发限制针对服务
actives 表示每客户端并发执行(或占用连接的请求数)
2.合理的 Provider 端属性
<dubbo:protocol threads="200" />
<dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService"
executes="200" >
<dubbo:method name="findAllPerson" executes="50" />
</dubbo:service>
- threads 服务线程池大小
- executes 一个服务提供者并行执行请求上限,即当 Provider 对一个服务的并发调用到上限后,新调用会 Wait,这个时候 Consumer可能会超时。在方法上配置 dubbo:method 则并发限制针对方法,在接口上配置 dubbo:service,则并发限制针对服务
executes 表示服务器端并发执行(或占用线程池线程数)
3. 合理使用集群容错模式
- Failover Cluster:缺省配置,失败自动切换,当出现失败,重试其它服务器,通常用于读操作,但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
- Failfast Cluster:快速失败,只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录。
- Failsafe Cluster:失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作。
- Failback Cluster:失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作。
- Forking Cluster:并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
- Broadcast Cluster:广播调用所有提供者,逐个调用,任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。
4. 多版本使用
可以按照以下的步骤进行版本迁移:
- 在低压力时间段,先升级一半提供者为新版本
- 再将所有消费者升级为新版本
- 然后将剩下的一半提供者升级为新版本
版本通过version配置,Provider 和 Consumer 版本一致才能调用到
<dubbo:service interface="com.foo.BarService" version="1.0.0" />
<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />
5. 协议与序列化
出于兼容性考虑Dubbo2.0默认的序列化方式和1.0 保持一致使用 hessian2
dubbo:// 缺省默认协议
通过多种协议性能测试报告总结
- 如果性能有个更高要求,可以使用dubbo序列化,在处理复杂对象,在大数据量下能获得50%提升(但此时不建议使用Dubbo协议)
- Dubbo的设计目的是为了满足高并发小数据量的rpc调用,在大数据量下的性能表现并不好,建议使用 rmi 或 http 协议
更多配置参考:Dubbo参考手册