【DUBBO】dubbo的Cluster接口

Directory中的多个Invoker伪装成一个Invoker, 对上层透明，包含集群的容错机制

Cluster可以看做是工厂类， 将目录directory下的invoker合并成一个统一的Invoker，根据不同集群策略的Cluster创建不同的Invoker

1）AvailableCluster: 获取可用的调用。遍历所有Invokers判断Invoker.isAvalible,只要一个有为true直接调用返回，不管成不成功

2）BroadcastCluster: 广播调用。遍历所有Invokers, 逐个调用每个调用catch住异常不影响其他invoker调用

3）FailbackCluster: 失败自动恢复， 对于invoker调用失败， 后台记录失败请求，任务定时重发, 通常用于通知

4）FailfastCluster: 快速失败，只发起一次调用，失败立即保错，通常用于非幂等性操作

5）FailoverCluster: 失败转移，当出现失败，重试其它服务器，通常用于读操作，但重试会带来更长延迟

　　---> 目录服务directory.list(invocation) 列出方法的所有可调用服务获取重试次数，默认重试两次

　　---> 根据LoadBalance负载策略选择一个Invoker

　　--->执行invoker.invoke(invocation)调用

　　--->调用成功返回

       --->调用失败小于重试次数，重新调用。

　　--->调用次数大于等于重试次数抛出调用失败异常

6）FailsafeCluster: 失败安全，出现异常时，直接忽略，通常用于写入审计日志等操作。

7）ForkingCluster: 并行调用，只要一个成功即返回，通常用于实时性要求较高的操作，但需要浪费更多服务资源。

8） MergeableCluster: 分组聚合， 按组合并返回结果，比如菜单服务，接口一样，但有多种实现，用group区分，现在消费方需从每种group中调用一次返回结果，合并结果返回，这样就可以实现聚合菜单项。

这个还蛮有意思，我们分析下是如何实现的

   ---> 根据MERGE_KEY从url获取参数值

   ---> 为空不需要merge， 正常调用

   ---> 按group分组调用，将返回接口保存到集合中

   ---> 获取MERGE_KEY如果是默认的话，获取默认merge策略，主要根据返回类型判断

   ---> 如果不是，获取自定义的merge策略

   ---> Merge策略合并调用结果返回

9）MockClusterWrapper: 具备调用mock功能是其他Cluster包装

获取url的MOCK_KEY属性

（1） 不存在直接调用其他cluster

（2） 存在值startsWith("force") 强制mock调用

（3） 存在值不是startsWith("force") 先正常调用， 出现异常在mock调用