dubbo服务的集群扩展、目录服务、路由规则、负载均衡

1. Cluster-集群扩展

当有多个服务提供方时，将多个服务提供方组织成一个集群，并假装成一个提供方。已知的实现以下，

1-1. FailoverCluster（默认的）

失败转移，当出现失败，重试其它服务器，一般用于读操做，但重试会带来更长延迟。

1-2. AvailableCluster

获取可用的调用。遍历全部Invokers判断Invoker.isAvalible,只要一个有为true直接调用返回，无论成不成功。

1-3. BroadcastCluster

挨个调用集群中全部的providers，一般用于通知全部的服务提供者更新某些资源，例如缓存、日志。

1-4. FailbackCluster

失败自动恢复，后台记录失败请求，定时重发，一般用于消息通知操做。

1-5. FailfastCluster

快速失败，只发起一次调用，失败当即报错，一般用于非幂等性的写操做。

1-6. ForkingCluster

并行调用，只要一个成功即返回，一般用于实时性要求较高的操做，但须要浪费更多服务资源。

1-7. MergeableCluster

按组合并返回结果，好比菜单服务，接口同样，但有多种实现，用group区分，如今消费者需从每种group中调用一次返回结果，合并结果返回，这样就能够实现聚合菜单项。

2. Directory-目录服务

Directory.java的头部注释中，引用http://en.wikipedia.org/wiki/... service作了一个介绍。directory service有点陌生，可是name service应该比较熟悉吧，就是命名服务。 每个name service都映射了网络中的一种资源。
这里面一个Directory就表明一个provider提供的List<Invoker>，可是这个List<Invoker>多是动态变化的，好比注册中心的推送变动。
Cluster将Directory中的多个Invoker假装成一个Invoker，对上层透明，假装过程包含了容错逻辑，调用失败后，重试另外一个。

2-1. RegistryDirectory

注册目录服务，它的Invoker集合是从注册中心获取的，好比消费方要调用某远程服务，会向注册中心订阅这个服务的全部服务提供方，订阅时和服务提供方数据有变更时，会回调消费方的回调接口并传入服务的全部提供方的url地址，而后将urls地址转为为invokers，也就是refer远程服务。

2-2. StaticDirectory

静态目录服务， 它的全部Invoker经过构造函数传入。

3. Router-路由规则

Router 负责从多个Invoker中按路由规则选出子集，好比按照读写分离、应用隔离等。

4. LoadBalance-负载均衡

LoadBalance 负责从多个Invoker中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，须要重选。

4-1. RandomLoadBalance（默认的）

随机，按权重设置随机几率。
在一个截面上碰撞的几率高，但调用量越大分布越均匀，并且按几率使用权重后也比较均匀，有利于动态调整提供者权重。

4-2. RoundRobinLoadBalance

轮循，按公约后的权重设置轮循比率。
存在慢的提供者累积请求问题，好比：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，长此以往，全部请求都卡在调到第二台上。

4-3. LeastActiveLoadBalance

最少活跃调用数，相同活跃数的随机，活跃数指调用先后计数差，使慢的机器收到更少。
例如，每一个服务维护一个活跃数计数器。当A机器开始处理请求，该计数器加1，此时A还未处理完成。若处理完毕则计数器减1。而B机器接受到请求后很快处理完毕。那么A,B的活跃数分别是1，0。当又产生了一个新的请求，则选择B机器去执行(B活跃数最小)，这样使慢的机器A收到少的请求。

4-4. ConsistentHashLoadBalance

一致性Hash，相同参数的请求老是发到同一提供者。
当某一台提供者挂时，本来发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引发剧烈变更。
算法参见：http://en.wikipedia.org/wiki/...。缺省只对第一个参数Hash，若是要修改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />缺省用160份虚拟节点，若是要修改，请配置 <dubbo:parameter key="hash.nodes" value="320" />