服务容错模式

2017-03-09 20:01 90人阅读 评论(0) 收藏 举报

 分类：

命名待定（9） 

目录(?)[+]

转载自：http://tech.meituan.com/service-fault-tolerant-pattern.html

  所谓模式，其实就是某种场景下一类问题及其解决方案的总结归纳，往往可以重用。模式可以指导我们完成任务，作出合理的系统设计方案，达到事半功倍的效果。而在服务容错这个方向，行业内已经有了不少实践总结出来的解决方案。

超时与重试（Timeout and Retry）

  超时模式，是一种最常见的容错模式。常见的有设置网络连接超时时间，一次RPC的响应超时时间等。在分布式服务调用的场景中，它主要解决了当依赖服务出现建立网络连接或响应延迟，不用无限等待的问题，调用方可以根据事先设计的超时时间中断调用，及时释放关键资源，如Web容器的连接数，数据库连接数等，避免整个系统资源耗尽出现拒绝对外提供服务这种情况。 
  重试模式，一般和超时模式结合使用，适用于对于下游服务的数据强依赖的场景（不强依赖的场景不建议使用！），通过重试来保证数据的可靠性或一致性，常用于因网络抖动等导致服务调用出现超时的场景。与超时时间设置结合使用后，需要考虑接口的响应时间分布情况，超时时间可以设置为依赖服务接口99.5%响应时间的值，重试次数一般1-2次为宜，否则会导致请求响应时间延长，拖累到整个系统。

限流(Rate Limiting/Load Shedder)

  限流模式，常用于下游服务容量有限，但又怕出现突发流量猛增（如恶意爬虫，节假日大促等）而导致下游服务因压力过大而拒绝服务的场景。常见的限流模式有控制并发和控制速率，一个是限制并发的数量，一个是限制并发访问的速率。 
  控制并发：属于一种较常见的限流手段，在工程实践中可以通过信号量机制（如Java中的Semaphore）来控制。举个例子：假如有一个需求，要读取几万个文件的数据，因为都是IO密集型任务，可以启动几十个线程并发的读取，但是如果读到内存后，还需要存储到数据库中，而数据库的连接数只有10个，这时必须控制只有十个线程同时获取数据库连接保存数据，否则会报错无法获取数据库连接。这个时候就可以使用Semaphore来控制并发数。 
  控制速率：在工程实践中，常见的是使用令牌桶算法来实现这种模式，其他如漏桶算法也可以实现控制速率。
  令牌桶算法是这么描述的：每秒会有r个令牌放入桶中，或者说，每过1/r秒桶中增加一个令牌；桶中最多存放b个令牌，如果桶满了，新放入的令牌会被丢弃；当一个n字节的数据包到达时，消耗n个令牌，然后发送该数据包；如果桶中可用令牌小于n，则该数据包将被缓存或丢弃。 
  令牌桶控制的是一个时间窗口内通过的数据量，在API层面常说的QPS、TPS，正好是一个时间窗口内的请求量或者事务量，只不过时间窗口限定在1s罢了。以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。令牌桶的另外一个好处是可以方便的改变速度，一旦需要提高速率，则按需提高放入桶中的令牌的速率。 
  在的工程实践中，通常使用Guava中的Ratelimiter来实现控制速率。

电路熔断器(Circuit Breaker)

  在工程实践中，偶尔会遇到一些服务由于网络连接超时，系统有异常或load过高出现暂时不可用等情况，导致对这些服务的调用失败，可能需要一段时间才能修复，这种对请求的阻塞可能会占用宝贵的系统资源，如：内存，线程，数据库连接等等，最坏的情况下会导致这些资源被消耗殆尽，使得系统里不相关的部分所使用的资源也耗尽从而拖累整个系统。在这种情况下，调用操作能够立即返回错误而不是等待超时的发生或者重试可能是一种更好的选择，只有当被调用的服务有可能成功时再去尝试。 
  熔断器模式可以防止我们的系统不断地尝试执行可能会失败的调用，使得我们的系统继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器模式也可以使我们系统能够检测错误是否已经修正，如果已经修正，系统会再次尝试调用操作。 
  在熔断器内部，往往有以下几种状态： 
  1）闭合（closed）状态：该状态下能够对目标服务或方法进行正常的调用。熔断器类维护了一个时间窗口内调用失败的次数，如果某次调用失败，则失败次数加1。如果最近失败次数超过了在给定的时间窗口内允许失败的阈值(可以是数量也可以是比例)，则熔断器类切换到断开(Open)状态。此时熔断器设置了一个计时器，当时钟超过了该时间，则切换到半断开（Half-Open）状态，该睡眠时间的设定是给了系统一次机会来修正导致调用失败的错误。 
  2）断开(Open)状态：在该状态下，对目标服务或方法的请求会立即返回错误响应，如果设置了fallback方法，则会进入fallback的流程。 
  3）半断开（Half-Open）状态：允许对目标服务或方法的一定数量的请求可以去调用服务。如果这些请求对服务的调用成功，那么可以认为之前导致调用失败的错误已经修正，此时熔断器切换到闭合状态（并且将错误计数器重置）；如果这一定数量的请求有调用失败的情况，则认为导致之前调用失败的问题仍然存在，熔断器切回到断开方式，然后开始重置计时器来给系统一定的时间来修正错误。半断开状态能够有效防止正在恢复中的服务被突然而来的大量请求再次拖垮。 
  在工程实践中，熔断器模式往往应用于服务的自动降级，在实现上主要基于Netflix开源的组件Hystrix来实现。

舱壁隔离(Bulkhead Isolation)

  在造船行业，往往使用此类模式对船舱进行隔离，利用舱壁将不同的船舱隔离起来，这样如果一个船舱破了进水，只损失一个船舱，其它船舱可以不受影响，而借鉴造船行业的经验，这种模式也在软件行业得到使用。 
  线程隔离(Thread Isolation)就是这种模式的常见的一个场景。例如，系统A调用了ServiceB/ServiceC/ServiceD三个远程服务，且部署A的容器一共有120个工作线程，采用线程隔离机制，可以给对ServiceB/ServiceC/ServiceD的调用各分配40个线程。当ServiceB慢了，给ServiceB分配的40个线程因慢而阻塞并最终耗尽，线程隔离可以保证给ServiceC/ServiceD分配的80个线程可以不受影响。如果没有这种隔离机制，当ServiceB慢的时候，120个工作线程会很快全部被对ServiceB的调用吃光，整个系统会全部慢下来，甚至出现系统停止响应的情况。 
  这种Case在实践中经常遇到，如某接口由于数据库慢查询，外部RPC调用超时导致整个系统的线程数过高，连接数耗尽等。我们可以使用舱壁隔离模式，为这种依赖服务调用维护一个小的线程池，当一个依赖服务由于响应慢导致线程池任务满的时候，不会影响到其他依赖服务的调用，它的缺点就是会增加线程数。