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调用
