熔断机制
Spring Cloud构建的微服务系统中, 采用的熔断器(即Hystrix组件的Circuit Breaker)去做熔断
例如在微服务系统中, 有a,b,c,d,e,f,g,h等多个服务, 用户的请求通过网关后, 再到具体的服务, 服务之间相互依赖, 例如服务b依赖于服务f, 那么就需要一个对外暴露的API接口来使服务b和f相互协作完成, 服务之间的相互依赖架构图如下:
如果此时服务b出现网络延迟或故障, 在高并发的情况下, 服务b可能会短时间内堆积大量线程, 造成线程阻塞, 然后在这段时间内线程资源会被耗尽, 导致服务b不可用, 如果服务b是比较底层的服务, 又被其他一些服务依赖, 这时候就会影响到其他的服务, 导致其他服务会一直等待服务b的处理返回, 如果服务b迟迟不处理, 大量的请求不仅会堆积在服务b, 而且还会堆积到依赖于服务b的其他服务中, 这样就会影响层层互相依赖的服务, 最终导致整个系统不可用, 这是一件非常可怕的事情, 在高并发情况下, 稍微有点不靠谱, 就会导致大量的服务不可用, 甚至整个系统崩溃.
为了解决上述的难题, 微服务架构引入了熔断机制, 当服务b出现故障的时候, 请求失败次数超过设定的阈值之后, 服务b开启熔断器, 之后服务b不进行任何的业务逻辑操作, 执行快速失败, 直接返回请求失败信息, 其他依赖于b服务的服务就不会因为得不到相应而导致线程阻塞, 这时候除了服务b和依赖于服务b的部分功能不可用之外, 其他功能正常, 如下:
熔断器还有另外一个机制, 那就是自我修复的机制, 当服务b熔断之后, 经过一段时间, 半打开熔断器, 半打开的熔断器会检查一部分请求是否正常, 其他部分请求依然执行快速失败, 检查的部分请求如果响应成功, 则可以判定服务b正常了, 就会关闭服务b的熔断器, 如果服务b还是不正常, 则继续打开熔断器. 这种自我熔断机制和自我修复机制在微服务架构中有重要的意义, 一方面, 它使程序更加健壮, 另一方面, 为开发和运维减少很多不必要的工作.
最后, 熔断组件往往会提供一系列的监控, 例如服务可用与否、熔断器是否被打开、目前的吞吐量、网络延迟状态的监控等, 从而很容易让开发人员和运维人员实时的谅解服务状况.
