Dubbo的几种集群容错方案

它的配置方式是这样的：

1

<dubbo:service cluster="failsafe" />

Dubbo的负载均衡算法有哪些

Dubbo内部提供了4种负载均衡算法。

1. 基于权重随机算法的RandomLoadBalance(默认)
2. 基于最少活跃调用数算法的LeastActiveBalance
3. 基于一致性hash算法的ConsistentHashLoadBalance
4. 基于加权轮询算法的RoundRobinLoadBalance
   基于加权的轮询算法会根据每台服务器的性能为服务器设置一个权值，加权后，每台服务器能够得到的请求数比例，接近或等于他们的权重比。比如服务器 A、B、C 权重比为 5:2:1。那么在8次请求中，服务器 A 将收到其中的5次请求，服务器 B 会收到其中的2次请求，服务器 C 则收到其中的1次请求。

1
2
3
4

<dubbo:service interface="com.alibaba.hello.api.WorldService" version="1.0.0" ref="helloService"
    timeout="300" retries="2" loadbalance="random" actives="0" >
    <dubbo:method name="findAllPerson" timeout="10000" retries="9" loadbalance="leastactive" actives="5" />
<dubbo:service/>

服务化推荐用法

分包

将服务接口、服务模型、服务异常均放在API包中，因为服务模型和异常也是API的一部分，这样做服务分包原则：重用发布等价原则（REP），共同重用原则(CRP)

粒度

服务接口应该尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题，而Dubbo并未提供分布式事务解决方案。

版本

每个接口都应该定义版本号，为后序不兼容升级提供可能。

兼容性

服务接口增加方法，或服务模型增加字段，可向后兼容，删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容，需要通过变更版本号升级。

枚举值

如果是完备集，可以使用Enum
如果后期可能会有变更，建议使用String代替。

序列化

服务参数和返回值建议使用POJO对象。

异常

建议使用异常汇报错误，而不是返回错误码，异常信息能够携带更多信息，并且语义更加友好。

调用

不要只是因为是 Dubbo 调用，而把调用 try...catch 起来。try...catch 应该加上合适的回滚边界上。
Provider 端需要对输入参数进行校验。如有性能上的考虑，服务实现者可以考虑在 API 包上加上服务 Stub 类来完成检验。

Dubbo推荐用法

在Provider端尽可能多配置consumer端属性

因为作为服务的提供方，比服务消费方更清楚服务的性能。在服务提供端配置后，消费端不配置则会使用服务提供端的配置。如果在消费端进行配置，那么对服务端来讲就是不可控的。

一个配置示例：

1
2
3
4
5
6
7

<dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService"
    timeout="300" retries="2" loadbalance="random" actives="0" />
 
<dubbo:service interface="com.alibaba.hello.api.WorldService" version="1.0.0" ref="helloService"
    timeout="300" retries="2" loadbalance="random" actives="0" >
    <dubbo:method name="findAllPerson" timeout="10000" retries="9" loadbalance="leastactive" actives="5" />
<dubbo:service/>

建议在服务提供端配置的消费端属性有：...