集群容错

集群容错：集群服务调用失败后，服务框架需要能够在底层自动容错，容错策略很多，分别适用于不同场景。下面将对集群容错的功能和设计进行详细说明。

1、集群容错场景

    在分布式服务框架中，业务消费者不需要了解服务提供者的具体位置，它发起的调用请求也不包含服务提供者的具体地址信息。因此，某个服务提供者是否可用对消费者无关紧要，最终的服务调用成功才是最重要的。

    经过服务路由之后，选定某个服务提供者进行远程调用，但是服务调用可能出错，下面对可能的故障场景进行分析。

    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）、其他系统异常。
        需要指出的是服务调用异常不包括业务方面的处理异常，例如数据库异常、用户记录不存在异常等。

2、容错策略

    服务不同，容错策略也往往不同。下面看看集群容错和路由策略之间的关系。如图1-1所示：
     
                                        图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。

总结：集群容错从功能上看很简单，设计也并不复杂，但是该特性却非常重要，相比于传统的RPC框架，分布式服务框架让用户开发变得更简单，体验也更好。从功能上看，服务框架需要提供更丰富、更粒度的功能和扩展点，这就是它相比于传统RPC框架最大的优势。

转载于:https://my.oschina.net/u/4185276/blog/3096483