一、集群容错场景
集群服务调用失败后，服务框架需要能够在底层自动容错，容错策略很多，分别适用于不同场景。
在分布式服务框架中，业务消费者不需要了解服务提供者的具体位置，它发起的调用请求也不包含服务提供者的具体地址信息。因此，某个服务提供者是否可用对消费者无关紧要，最终的服务调用成功才是最重要的。
经过服务路由之后，选定某个服务提供者进行远程调用，但是服务调用可能出错，下面对可能的故障场景进行分析。
1.1、通信链路故障
这里的链路指的是消费者和服务提供者之间的链路（通常为长连接），可能导致链路中断的原因有
1）通信过程中，对方突然宕机导致链路中断。
2）通信过程中，对方因为解码失败等原因Rest掉连接，导致链路中断。
3）通信过程中，消费者write SocketChannel发生IOException导致链路中断。
4）通信过程中，消费者read SocketChannel发生IOException异常导致链路中断。
5）通信双方因为检测心跳超时，主动close SocketChannel导致链路中断。
6）通信过程中，网络出现闪断故障。
7）通信过程中，交换机异常导致链路中断。
8）通信过程中，消费者或者服务提供者因为长时间Full GC导致链路中断。
无论哪种原因导致链路中断，都会导致本次服务调用失败。
1.2、服务端超时
当服务端无法再指定的时间内返回应答给客户端，就会发生超时，导致超时的原因主要有：
1）服务端I/O线程没有及时从网络中读取客户端请求消息，导致该问题的原因通常是I/O线程被意外阻塞或者执行长周 期操作
2）服务端业务处理缓慢，或者长时间阻塞，列如查询数据库，由于没索引导致全表查询，耗时较长。
3）服务端发生长时间Full GC,导致所有业务线程暂停运行，无法及时返回应答给客户端。
1.3、服务端调用失败
有时会发生服务端调用失败，导致服务端调用失败的原因主要有如下几种：
1）服务端解码失败，会返回消息解码失败异常。
2）服务端发生动态流控，返回流控异常。
3）服务消息队列积压率超过最大阈值，返回系统拥塞异常。
4）访问权限校验失败，返回权限相关异常。
5）违反SLA(Service-Level Agreement:服务等级协议)策略，返回SLA控制相关异常。
6）其他系统异常。
需要指出的是服务调用异常不包括业务方面的处理异常，例如数据库异常、用户记录不存在异常等。
二、集群容错策略
服务不同，容错策略也往往不同。下面看看集群容错和路由策略之间的关系。如图1-1所示：
消费者根据配置的路由策略选择某个目标地址之后，发起远程服务调用，在此期间如果发生远程服务调用异常，则需要框架进行集群容错，重新进行选路和调用，集群容错是系统自动执行的，上层用户并不关心底层的服务调用过程。
2.1、失败自动切换（Failover）
服务调用失败自动切换策略指的是当发生RPC调用异常时，重新选路，查找下一个可用的服务提供者。
服务发布的时候，可以指定服务的集群容错策略。消费者可以覆盖服务提供者的通用配置，实现个性化的容错策略。
Failover策略的设计思路如下：消费者路由操作完成之后，获得目标地址，调用通信框架的消息发送接口发送请求，监听服务端应答。如果返回的结果时RPC调用异常（超时、流控、解码失败等系统异常），根据消费者集群容错的策略进行容错路由，如果是Failover，则重新返回到路由Handler的入口，从路由节点继续执行。选路完成之后，对目标地址进行对比，防止重新路由到故障服务节点，过滤掉上次的故障服务提供者之后，调用通信框架的消息发送接口发送请求消息。
分布式服务框架提供Failover容错策略，但是用户在使用时需要自己保证用对地方，下面对应用场景进行总结：
1）读操作，因为通常它是幂等的。
2）幂等性服务，保证调用1次与N次效果相同。
需要特别指出的是，失败重试会增加服务调用时延，因此框架必须对失败重试的最大数做限制，通常默认为3，防止无限制重试导致服务调用时延不可控。
2.2、失败通知（Failback）
很多业务场景中，消费者需要能够获取到服务调用失败的具体信息，通过对失败错误码等异常信息的判断，决定后续的执行策略，例如非幂等性服务调用。
Failback的设计方案如下：服务框架获取到服务提供者返回的RPC异常响应之后，根据策略进行容错。如果是Failback模式，则不再重试其他服务提供者，而是将RPC异常通知给消费者，由消费者捕获异常进行后续处理。
2.3、失败缓存（Failcache）
Failcache策略是失败自动恢复的一种，在实际开发中应用场景如下：
√ 服务状态路由，必须定点发送到指定的服务提供者。当发生链路中断、流控等服务暂时不可用时，服务框架将消息暂时缓存起来，等待周期T，重新发送，回到服务提供者能够正常处理该消息。
√ 对时延要求不敏感的服务。系统服务调用失败，通常是链路暂时不可用、服务流控、GC挂住服务提供者进程等，这种失败不是永久性的，他的失败是可预期的。如果消费者调用对时延不敏感，可以考虑使用自动恢复模式。既先缓存、再等待、最后重试。
√ 通知类服务。对服务调用的实时性不高，可以容忍自动恢复带来的时延增长。
为了保证可靠性，Failcache策略在设计的时候需要考虑如下几个要素：
√ 缓存时间、缓存对象上限数等需要做出限制，防止内存溢出。
√ 缓存淘汰算法的选择，是否支持用户配置。
√ 定时重试的周期T，重试的最大次数等需要做出限制并支持用户指定。
2.4、快速失败（Failfast）
在业务高峰期，对于一些非核心的服务，希望只调用一次，失败也不再重试，为重要的核心服务节约宝贵的运行资源。此时快速失败是个不错的选择。
快速失败策略设计简单，获取到服务异常之后，直接忽略异常，记录异常日志。
2.5、容错策略扩展
无论服务框架支持多少种容错策略，业务在实际使用过程中一定会有不适应的地方，通过开放容错策略接口的方式，可以支持用户自定义扩展容错策略。
在集群容错设计的时候，需要考虑扩展性，主要从以下几方面进行设计：
1）容错接口的开放。
2）屏蔽底层细节，用户定制简单。
3）配置应当支持扩展，不要让用户扩展服务框架Schema。
三、Dubbo服务集群容错
先来介绍一下Dubbo集群容错的所有组件。包含 Cluster、Cluster Invoker、Directory、Router 和 LoadBalance 等。
集群工作过程可分为两个阶段，第一个阶段是在服务消费者初始化期间，集群 Cluster 实现类为服务消费者创建 Cluster Invoker 实例，即上图中的 merge 操作。第二个阶段是在服务消费者进行远程调用时。以 FailoverClusterInvoker 为例，该类型 Cluster Invoker 首先会调用 Directory 的 list 方法列举 Invoker 列表（可将 Invoker 简单理解为服务提供者）。Directory 的用途是保存 Invoker，可简单类比为 List<Invoker>。其实现类 RegistryDirectory 是一个动态服务目录，可感知注册中心配置的变化，它所持有的 Invoker 列表会随着注册中心内容的变化而变化。每次变化后，RegistryDirectory 会动态增删 Invoker，并调用 Router 的 route 方法进行路由，过滤掉不符合路由规则的 Invoker。当 FailoverClusterInvoker 拿到 Directory 返回的 Invoker 列表后，它会通过 LoadBalance 从 Invoker 列表中选择一个 Invoker。最后 FailoverClusterInvoker 会将参数传给 LoadBalance 选择出的 Invoker 实例的 invoker 方法，进行真正的远程调用。
假设我们使用的是单机模式的Dubbo服务，如果在服务提供方（Provider）发布服务以后，服务消费方（Consumer）发出一次调用请求，恰好这次由于网络问题调用失败，那么我们可以配置服务消费方重试策略，可能消费方第二次重试调用是成功的（重试策略只需要配置即可，重试过程是透明的）；但是，如果服务提供方发布服务所在的节点发生故障，那么消费方再怎么重试调用都是失败的，所以我们需要采用集群容错模式，这样如果单个服务节点因故障无法提供服务，还可以根据配置的集群容错模式，调用其他可用的服务节点，这就提高了服务的可用性。
简单地说目前Dubbo支持的集群容错模式，每种模式适应特定的应用场景，可以根据实际需要进行选择。Dubbo内置支持如下6种集群模式：
1、Failover Cluster模式
配置值为failover。这种模式是Dubbo集群容错默认的模式选择，调用失败时，会自动切换，重新尝试调用其他节点上可用的服务。
对于一些幂等性操作可以使用该模式，如读操作，因为每次调用的副作用是相同的，所以可以选择自动切换并重试调用，对调用者完全透明。
可以看到，如果重试调用必然会带来响应端的延迟，如果出现大量的重试调用，可能说明我们的服务提供方发布的服务有问题，如网络延迟严重、硬件设备需要升级、程序算法非常耗时，等等，这就需要仔细检测排查了。
例如，可以这样显式指定Failover模式，或者不配置则默认开启Failover模式，配置示例如下：
<dubbo:service interface="org.shirdrn.dubbo.api.ChatRoomOnlineUserCounterService"
version="1.0.0" cluster="failover" retries="2" timeout="100"
ref="chatRoomOnlineUserCounterService" protocol="dubbo" >
<dubbo:method name="queryRoomUserCount" timeout="80" retries="2" />
</dubbo:service>上述配置使用Failover Cluster模式，如果调用失败一次，可以再次重试2次调用，服务级别调用超时时间为100ms，调用方法queryRoomUserCount的超时时间为80ms，允许重试2次，最坏情况调用花费时间160ms。如果该服务接口org.shirdrn.dubbo.api.ChatRoomOnlineUserCounterService还有其他的方法可供调用，则其他方法没有显式配置则会继承使用dubbo:service配置的属性值。
2、Failfast Cluster模式
配置值为failfast。这种模式称为快速失败模式，调用只执行一次，失败则立即报错。
这种模式适用于非幂等性操作，每次调用的副作用是不同的，如写操作，
比如交易系统我们要下订单，如果一次失败就应该让它失败，通常由服务消费方控制是否重新发起下订单操作请求（另一个新的订单）。
3、Failsafe Cluster模式
配置值为failsafe。失败安全模式，如果调用失败， 则直接忽略失败的调用，
而是要记录下失败的调用到日志文件，以便后续审计。
4、Failback Cluster模式
配置值为failback。失败自动恢复，后台记录失败请求，定时重发。
通常用于消息通知操作。
5、Forking Cluster模式
配置值为forking。并行调用多个服务器，只要一个成功即返回。
通常用于实时性要求较高的读操作，但需要浪费更多服务资源。
6、Broadcast Cluster模式
配置值为broadcast。
广播调用所有提供者，逐个调用，任意一台报错则报错（2.1.0开始支持）。
通常用于通知所有提供者更新缓存或日志等本地资源信息。
上面的6种模式都可以应用于生产环境，我们可以根据实际应用场景选择合适的集群容错模式。
如果我们觉得Dubbo内置提供的几种集群容错模式都不能满足应用需要，
也可以定制实现自己的集群容错模式，因为Dubbo框架给我提供的扩展的接口，只需要实现接口com.alibaba.dubbo.rpc.cluster.Cluster即可。
四、总结
集群容错从功能上看很简单，设计也并不复杂，但是该特性却非常重要，相比于传统的RPC框架，分布式服务框架让用户
开发变得更简单，体验也更好。从功能上看，服务框架需要提供更丰富、更粒度的功能和扩展点，这就是它相比于传统RPC框架
最大的优势。
我的微信公众号：架构真经（id：gentoo666），分享Java干货，高并发编程，热门技术教程，微服务及分布式技术，架构设计，区块链技术，人工智能，大数据，Java面试题，以及前沿热门资讯等。每日更新哦！
参考资料：