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参考手册
源码可参考：Dubbo原理解析专栏