微服务架构下的 服务熔断, 降级, 限流
微服务架构下存在的 '雪崩' 问题
在微服务架构中, 一个请求需要调用多个服务是非常常见的. 如客户端访问订单服务, 而订单服务需要调用库存服务, 库存服务需要调用配送服务, 由于网络原因或者自身的原因, 如果订单服务或者配送服务不能及时响应, 订单服 务将处于阻塞状态, 直到库存服务配送服务响应. 此时若有大量的请求涌入, 容器的线程资源会被消耗完毕, 导致服务瘫痪. 服务与服务之间的依赖性, 故障会传播, 造成连锁反应, 会对整个微服务系统造成灾难 性的严重后果, 这就是服务故障的“雪崩”效应.
雪崩效应是微服务架构中一定存在的问题, 雪崩是系统中的蝴蝶效应导致其发生的原因多种多样, 有不合理的容量设计, 或者是高并发下某一个方 法响应变慢，亦或是某台机器的资源耗尽。从源头上我们无法完全杜绝雪崩源头的发生, 但是雪崩的根 本原因来源于服务之间的强依赖, 所以我们可以提前评估, 做好 隔离,熔断, 限流.
服务隔离
顾名思义, 它是指将系统按照一定的原则划分为若干个服务模块, 各个模块之间相对独立, 无强依赖. 当有故障发生时, 能将问题和影响隔离在某个模块内部, 而不扩散风险, 不波及其它模块, 不影响整体 的系统服务.
服务熔断
熔断这一概念来源于电子工程中的断路器(Circuit Breaker). 在互联网系统中, 当下游服务因访问压 力过大而响应变慢或失败, 上游服务为了保护系统整体的可用性, 可以暂时切断对下游服务的调用. 这 种牺牲局部, 保全整体的措施就叫做熔断.
服务降级
所谓降级, 就是当某个服务熔断之后, 服务器将不再被调用, 此时客户端可以自己准备一个本地的 fallback回调, 返回一个缺省值. 也可以理解为兜底~
熔断和降级通常是一起发生的, 两者目的都是为了保持自身服务的可用性, 在其它服务存在问题时而不会发起调用.
服务限流
限流可以认为服务降级的一种, 限流就是限制系统的输入和输出流量已达到保护系统的目的. 一般来说 系统的吞吐量是可以被测算的, 为了保证系统的稳固运行, 一旦达到的需要限制的阈值, 就需要限制流 量并采取少量措施以完成限制流量的目的.比方: 推迟解决, 拒绝解决, 或者者部分拒绝解决又或者使用MQ这种中间件排队解决等等.
SpringCloud Hystrix和阿里的Sentinel可以用来解决上述讨论的服务限流, 熔断, 降级等问题.