其他
最近比较忙,白天上班,晚上还得面试,都没有时间关注新闻。某天晚上刚刚结束一个电话面试,正准备写面试评价,女朋友拿着手机走过来,满脸疑惑的问我:在《如何给女朋友解释为什么双十一无法修改收货地址》中我们介绍过关于QPS、RT、并发用户数以及最大线程数等知识。我们知道,如果一个软件系统的并发请求数目超过了系统的最佳线程数,那么就会导致激烈的资源竞争,随着资源的匮乏甚至枯竭,整个系统也就面临着灾难。所以,很多软件系统为了保证即使在出现并发用户数>最佳线程数时,也不至于导致整个万网站崩溃,都会采用一些技术手段来避免发生系统性灾难。这些技术中比较典型的就是限流、降级和熔断。这次就来讲讲什么是服务熔断,以及如何在微服务架构中做服务熔断。为什么需要熔断现在很多网站的背后都是一个庞大的《分布式》系统,多个系统之间的交互大多数都是采用《RPC》的方式,但是因为是远程调用,所以被调用者的服务的可用情况其实是不可控的。而越是庞大的系统,上下游的调用链就会越长,而如果在一个很长的调用链中,某一个服务由于某种原因导致响应时间很长,或者完全无响应,那么就可能把整个分布式系统都拖垮。以上调用链,如果其中某一个服务由于自身原因导致响应很慢,那么就可能导致上游的服务影响也很慢,这样循环往复,就会导致整个系统全线崩溃,这就是服务雪崩。其实,在分布式系统中,为了保证整体服务可用性和一致性,很多系统都会引入重试机制,在有些情况下,重试其实是可以解决问题的,比如网络问题等,都可以通过重试来解决。但是,有些情况下,重试并不能解决问题,返而会加剧问题的严重性,比如下游系统因为请求量太大,导致CPU已经被打满,说着数据库连接池被占满,这时候上游系统调不通就会不断进行重试,这种重试请求,对于下游系统来说,无疑是雪上加霜,给下游系统造成二次伤害。而分布式系统,大多数的服务雪崩也都是因为不断重试导致的,这种重试有可能是框架级别的自动重试、有可能是代码级别的重试逻辑、还有可能是用户的主动重试。有些重试是无法避免的,而且如果因为防止雪崩,就不设计重试机制,也是一种因噎废食。熔断器模式熔断器模式(Circuit