微服务架构之Dubbo集群容错(1)

本篇从大的概念上来介绍集群容错，后续篇章从源码角度解析。

什么是集群容错

当我们使用Dubbo的集群环境，会因为某些原因导致服务调用失败的情况，Dubbo提供了多种容错方案，缺省为failover重试。

各节点关系：

这里的 Invoker 是 Provider 的一个可调用 Service 的抽象，Invoker 封装了 Provider 地址及 Service 接口信息。

Directory 代表多个 Invoker，可以把它看成 List ，但与 List 不同的是，它的值可能是动态变化的，比如注册中心推送变更。

Cluster 将 Directory 中的多个 Invoker 伪装成一个 Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个。

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

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

如何配置使用

首先看看dubbo目前提供哪些集群解决方案

Feature	优点	缺点	实现类
Failover Cluster	失败自动切换，当出现失败，重试其它服务器，通常用于读操作（推荐使用）	重试会带来更长延迟	FailoverClusterInvoker
Failfast Cluster	快速失败，只发起一次调用，失败立即报错,通常用于非幂等性的写操作	如果有机器正在重启，可能会出现调用失败	FailfastClusterInvoker
Failsafe Cluster	失败安全，出现异常时，直接忽略，通常用于写入审计日志等操作	调用信息丢失	FailsafeClusterInvoker
Failback Cluster	失败自动恢复，后台记录失败请求，定时重发，通常用于消息通知操作	不可靠，重启丢失	FailbackClusterInvoker
Forking Cluster	并行调用多个服务器，只要一个成功即返回，通常用于实时性要求较高的读操作	需要浪费更多服务资源	ForkingClusterInvoker
Broadcast Cluster	广播调用所有提供者，逐个调用，任意一台报错则报错，通常用于更新提供方本地状态	速度慢，任意一台报错则报错	BroadcastClusterInvoker

failover集群模式: 默认，但是可以配置重试次数

<dubbo:service  cluster="failover" retries="2" />
<dubbo:reference  cluster="failover" retries="2" />
<dubbo:reference>
    <dubbo:method name="findFoo" retries="2" />
</dubbo:reference>

failfast集群模式：

<dubbo:service cluster="failfast" />
<dubbo:reference cluster="failfast" />
等价于
<dubbo:service  cluster="failover" retries="0" />
<dubbo:reference  cluster="failover" retries="0" />