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" />