专栏首页编程坑太多『互联网架构』软件架构-服务限流降级熔断机制详解(95)

『互联网架构』软件架构-服务限流降级熔断机制详解(95)

大部分老铁都没用过hystrix,一般来说能用到hystrix的公司都是比较大型的互联网公司, 服务的限流,降级,熔断,超时这些东西很多老铁经常听说,在一些技术演讲技术大会上,听一些大牛演讲常说服务限流,熔断,降级这些东西,很多公司的流量,性能,并发达不到那么大,对于高可用没有高的要求,用到这些技术机会很少,所以老铁对今天的内容很陌生,非常的感兴趣,确实这是技术BAT用到最多的技术。所以今天一起探秘,看起来很牛逼的技术让他技术的落地,能彻底的了解掌握这门技术。

(一)分布式系统中,会出现哪些问题?

  • 雪崩效应

分布式系统集群系统中一定会遇到的一个问题:服务雪崩效应 或者叫级联效应 那么什么是服务雪崩效应呢?在一个高度服务化的系统中,我们实现的一个业务逻辑通常会依赖多个服务,比如: 商品详情展示服务会依赖商品服务, 价格服务, 商品评论服务.

调用三个依赖服务会共享商品详情服务的线程池. 如果其中的商品评论服务不可用, 就会出 现线程池里所有线程都因等待响应而被阻塞, 从而造成服务雪崩.

服务雪崩效应:因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过 程,就叫服务雪崩效应。

  • 导致服务不可用的原因总结有几点:程序Bug,大流量请求,硬件故障,缓存击穿
  1. 【大流量请求】:在秒杀和大促开始前,如果准备不充分,瞬间大量请求会造成服务提供者的 不可用。
  2. 【硬件故障】:可能为硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的 不可访问。
  3. 【缓存击穿】:一般发生在缓存应用重启, 缓存失效时高并发, 所有缓存被清空时,以及短 时间内大量缓存失效时. 大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运行,引 起服务不可用。
  • 在服务提供者不可用的时候,会出现重试的情况:用户重试、代码逻辑重试
  1. 【用户重试】:在服务提供者不可用后, 用户由于忍受不了界面上长时间的等待,会不断刷新页面 甚至提交表单。
  2. 【代码逻辑重试】:服务调用端的会存在大量服务异常后的重试逻辑. 这些重试最终导致:进一步加大请求流量。
  • 根本原因:

大量请求线程同步等待造成的资源耗尽,当服务调用者使用同步调用 时, 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了。

(二)解决方案

  1. 超时机制
  2. 服务限流
  3. 服务熔断
  4. 服务降级
  • 超时机制

服务级联失败(服务雪崩效应)的最根本原因是:大量请求线程同步等待造成的资源耗尽那么,在不做任何处理的情况下,服务提供者不可用会导致消费者请求线程强制等待,而造成系统资源耗尽,而且,既然服务提供者已经不可用了,还在作死的请求的话,是毫无意义的。那么,如果我们加入超时机制,例如2s,那么超过2s就会直接返回了,那么这样是不是一定程度上可以抑制消费者资源耗尽的问题。

  • 服务限流(资源隔离)

限制请求核心服务提供者的流量,使大流量拦截在核心服务之外,这样可以更好的保证核心服务提供者不出问题,对于一些出问题的服务可以限制流量访问,只分配固定线资源访问,这样能使整体的资源不至于被出问题的服务耗尽,进而整个系统雪崩那么服务之间怎么限流,怎么资源隔离了?例如通过线程池+队列的方式,通过信号量的方式。当商品评论服务不可用时, 即使商品服务独立分配的20个线程全部处于同步等待状态,也不会影响其他依赖服务的调用.

  • 服务熔断

远程服务不稳定或网络抖动时暂时关闭,就叫服务熔断。举个通俗易懂的例子,就跟我们现实生活中的“跳闸”一样,跳闸应该都听说过吧,比如说家里有点短路了,那是不是闸会跳掉,等你把短路的问题找到并且修复后,然后你把这个闸一送,是不是整个家庭的电路又恢复了正常。这就是熔断器。 所以,同样的道理,当依赖的服务有大量超时时,在让新的请求去访问根本没有意义,只会无畏的消耗现有资源。比如我们设置了超时时间为1s,如果短时间内有大量请求在1s内都得不到响应,就意味着这个服务出现了异常,此时就没有必要再让其他的请求去访问这个依赖了,这个时候就应该使用熔断器避免资源浪费。

  • 服务降级

有服务熔断,必然要有服务降级。所谓降级,就是当某个服务熔断之后,服务将不再被调用,此时客户端可以自己准备一个本地的fallback(回退)回调,返回一个缺省值。 例如:(备用接口/缓存/mock数据)这样做,虽然服务水平下降,但好歹可用,比直接挂掉要强,当然这也要看适合的业务场景。

本文分享自微信公众号 - 编程坑太多(idig88),作者:诸葛阿明

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-06-30

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 『互联网架构』软件架构-zuul微服务网关(上)(100)

    1. 客户端会多次请求不同微服务,增加客户端的复杂性。2. 存在跨域请求,在一定场景下处理相对复杂。(有的公司服务比较微服务都是通过内部的域名的方式,分类的微服...

    IT故事会
  • 『高级篇』docker之微服务架构带来的问题(五)

    IT故事会
  • 『互联网架构』软件架构-分布式架构(14)

    那时候的容器之间都没有进行物理的隔离,都是部署在同一个jvm上的。所以久而久之,它们之间互相的耦合互相的依赖,业务之前有千丝万缕的,添加和修改增加新的业务的时候...

    IT故事会
  • 从既有系统到微服务架构

    微服务近年来可谓炙手可热,合理的使用微服务架构可以解耦系统、提供更好的软件伸缩性以及提高组织的敏捷性。然而现实中较少有项目一开始就会选择使用微服务架构,绝大多数...

    后端技术探索
  • 从既有系统到微服务架构

    微服务近年来可谓炙手可热,合理的使用微服务架构可以解耦系统、提供更好的软件伸缩性以及提高组织的敏捷性。然而现实中较少有项目一开始就会选择使用微服务架构,绝大多数...

    纯洁的微笑
  • 7个点说清楚spring cloud微服务架构

    spring cloud作为当下主流的微服务框架,让我们实现微服务架构简单快捷,spring cloud中各个组件在微服务架构中扮演的角色如下图所示,黑线表示注...

    程序员追风
  • 一张图带你了解 Spring Cloud 微服务架构!

    Spring cloud中各个组件在微服务架构中扮演的角色如下图所示,黑线表示注释说明,蓝线由A指向B,表示B从A处获取服务。

    搜云库技术团队
  • 一张图了解 Spring Cloud 微服务架构

    Spring cloud作为当下主流的微服务框架,让我们实现微服务架构简单快捷,Spring cloud中各个组件在微服务架构中扮演的角色如下图所示,黑线表示注...

    芋道源码
  • 金融行业微服务架构解析

    对于微服务,每个人都有自己的理解,与互联网企业的大量落地相比,微服务在传统金融行业还没有普及,这首先是传统金融行业线上系统需求更新和版本迭代没有互联网公司那么频...

    yuanyi928
  • ServiceMesh实战——什么是服务网格

    牛顿有曰:如果说我看得比别人更远些,那是因为我站在巨人的肩膀上。 学习前人的成果,就是先努力站到巨人的肩膀上;掌握前人的成果是前进的必要过程。有些人不学就懂了,...

    秦始皇2.0

扫码关注云+社区

领取腾讯云代金券