集群容错:集群服务调用失败后,服务框架需要能够在底层自动容错,容错策略很多,分别适用于不同场景。下面将对集群容错的功能和设计进行详细说明。
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框架
最大的优势。