内容简介:大部分老铁都没用过hystrix,一般来说能用到hystrix的公司都是比较大型的互联网公司, 服务的限流,降级,熔断,超时这些东西很多老铁经常听说,在一些技术演讲技术大会上,听一些大牛演讲常说服务限流,熔断,降级这些东西,很多公司的流量,性能,并发达不到那么大,对于高可用没有高的要求,用到这些技术机会很少,所以老铁对今天的内容很陌生,非常的感兴趣,确实这是技术BAT用到最多的技术。所以今天一起探秘,看起来很牛逼的技术让他技术的落地,能彻底的了解掌握这门技术。
大部分老铁都没用过hystrix,一般来说能用到hystrix的公司都是比较大型的互联网公司, 服务的限流,降级,熔断,超时这些东西很多老铁经常听说,在一些技术演讲技术大会上,听一些大牛演讲常说服务限流,熔断,降级这些东西,很多公司的流量,性能,并发达不到那么大,对于高可用没有高的要求,用到这些技术机会很少,所以老铁对今天的内容很陌生,非常的感兴趣,确实这是技术BAT用到最多的技术。所以今天一起探秘,看起来很牛逼的技术让他技术的落地,能彻底的了解掌握这门技术。
(一)分布式系统中,会出现哪些问题?
-
雪崩效应
>分布式系统集群系统中一定会遇到的一个问题:服务雪崩效应 或者叫级联效应
那么什么是服务雪崩效应呢?
在一个高度服务化的系统中,我们实现的一个业务逻辑通常会依赖多个服务,比如:
商品详情展示服务会依赖商品服务, 价格服务, 商品评论服务.
调用三个依赖服务会共享商品详情服务的线程池. 如果其中的商品评论服务不可用, 就会出
现线程池里所有线程都因等待响应而被阻塞, 从而造成服务雪崩.
服务雪崩效应:因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过
程,就叫服务雪崩效应。
- 导致服务不可用的原因总结有几点:程序Bug,大流量请求,硬件故障,缓存击穿
- 【大流量请求】:在秒杀和大促开始前,如果准备不充分,瞬间大量请求会造成服务提供者的
不可用。 - 【硬件故障】:可能为硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的
不可访问。 - 【缓存击穿】:一般发生在缓存应用重启, 缓存失效时高并发, 所有缓存被清空时,以及短
时间内大量缓存失效时. 大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运行,引
起服务不可用。
- 在服务提供者不可用的时候,会出现重试的情况:用户重试、代码逻辑重试
- 【用户重试】:在服务提供者不可用后, 用户由于忍受不了界面上长时间的等待,会不断刷新页面
甚至提交表单。 - 【代码逻辑重试】:服务调用端的会存在大量服务异常后的重试逻辑.
这些重试最终导致:进一步加大请求流量。
-
根本原因:
>大量请求线程同步等待造成的资源耗尽,当服务调用者使用同步调用 时, 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了。
(二)解决方案
- 超时机制
- 服务限流
- 服务熔断
- 服务降级
- 超时机制
服务级联失败(服务雪崩效应)的最根本原因是:大量请求线程同步等待造成的资源耗尽那么,在不做任何处理的情况下,服务提供者不可用会导致消费者请求线程强制等待,而造成系统资源耗尽,而且,既然服务提供者已经不可用了,还在作死的请求的话,是毫无意义的。那么,如果我们加入超时机制,例如2s,那么超过2s就会直接返回了,那么这样是不是一定程度上可以抑制消费者资源耗尽的问题。
- 服务限流(资源隔离)
限制请求核心服务提供者的流量,使大流量拦截在核心服务之外,这样可以更好的保证核心服务提供者不出问题,对于一些出问题的服务可以限制流量访问,只分配固定线资源访问,这样能使整体的资源不至于被出问题的服务耗尽,进而整个系统雪崩那么服务之间怎么限流,怎么资源隔离了?例如通过线程池+队列的方式,通过信号量的方式。当商品评论服务不可用时, 即使商品服务独立分配的20个线程全部处于同步等待状态,也不会影响其他依赖服务的调用.
-
服务熔断
> 远程服务不稳定或网络抖动时暂时关闭,就叫服务熔断。举个通俗易懂的例子,就跟我们现实生活中的“跳闸”一样,跳闸应该都听说过吧,比如说家里有点短路了,那是不是闸会跳掉,等你把短路的问题找到并且修复后,然后你把这个闸一送,是不是整个家庭的电路又恢复了正常。这就是熔断器。
所以,同样的道理,当依赖的服务有大量超时时,在让新的请求去访问根本没有意义,只会无畏的消耗现有资源。比如我们设置了超时时间为1s,如果短时间内有大量请求在1s内都得不到响应,就意味着这个服务出现了异常,此时就没有必要再让其他的请求去访问这个依赖了,这个时候就应该使用熔断器避免资源浪费。
-
服务降级
> 有服务熔断,必然要有服务降级。所谓降级,就是当某个服务熔断之后,服务将不再被调用,此时客户端可以自己准备一个本地的fallback(回退)回调,返回一个缺省值。 例如:(备用接口/缓存/mock数据)这样做,虽然服务水平下降,但好歹可用,比直接挂掉要强,当然这也要看适合的业务场景。
PS:这次说了雪崩的解决方案和这几种方案的介绍,下次讲讲如何通过springclud技术完成技术的落地。
>>原创文章,欢迎转载。转载请注明:转载自,谢谢!>>原文链接地址:上一篇:
已是最新文章
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 微服务分布式系统熔断实战-为何我们需要API级别熔断?
- 接口请求熔断处理机制
- 聊聊微服务的隔离和熔断
- [译] Istio 熔断器解析
- Spring cloud(4)-熔断(Hystrix)
- 分布式熔断降级平台aegis
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
产品经理必懂的技术那点事儿
唐韧 / 电子工业出版社 / 2017-1 / 59
《产品经理必懂的技术那点事儿》以非技术背景产品经理了解技术为主题,将技术知识以简单并且易于理解的方式讲述出来,帮助非技术背景产品经理了解技术、学习技术,旨在帮助产品经理高效地与技术人员进行沟通与合作。 《产品经理必懂的技术那点事儿》的主要内容围绕产品经理需要了解的互联网基础技术知识展开,涉及客户端、服务器端、数据库及一些数据处理知识。同时,还就产品经理需具备的一些软实力,例如沟通能力和解决问......一起来看看 《产品经理必懂的技术那点事儿》 这本书的介绍吧!