如何提高微服务系统的容错性(Fault Tolerance), 并了解如何借助Hystrix开发健壮的微服务.

以往我们在开发单体应用, 或者调用RPC服务的时候, 可能没有考虑太多目标服务调用失败的情况, 经常一个Try/Catch加上打印日志就解决了. 但是在微服务系统中, 这种处理方法会给系统的稳定性带来很大隐患.举个例子, 假设我们系统中下单的功能要依赖50个服务, 每个服务正常响应的概率为99.99%, 如果我们不做容错处理, 只要任意一个服务没有响应下单就失败的话, 我们下单成功的概率为

99.9950 = 99.5%

日订单量为1W的话, 50个会出现下单失败, 这还是建立在依赖服务稳定性很高的情况下(4个9). 但是服务调用失败引起的问题不仅仅是这么简单, 在分布式环境下, 一个服务的调用失败可能会使其他被依赖服务发生延迟和超时, 而且这个影响会很快扩散到其他服务, 从而引发整个系统的雪崩(Avalanche).

hystrix介绍

这篇文章要介绍的Hystrix是一个Java类库, 它提供下面这些功能来帮助我们构建健壮的微服务系统:(对Hystrix已经比较熟悉的同学可以直接跳过这段到下面的Hystrix javanica介绍)
1.断路器机制
断路器很好理解, 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.
2.Fallback
Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.
3.资源隔离
在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池. 例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池. 这样做的主要优点是运行环境被隔离开了. 这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响. 但是带来的代价就是维护多个线程池会对系统带来额外的性能开销. 如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题的话, 可以使用Hystrix的信号模式(Semaphores)来隔离资源.