zoukankan      html  css  js  c++  java
  • 云时代架构阅读笔记十六——Hystrix理解

    背景

    分布式系统环境下,服务间类似依赖非常常见,一个业务调用通常依赖多个基础服务。如下图,对于同步调用,当库存服务不可用时,商品服务请求线程被阻塞,当有大批量请求调用库存服务时,最终可能导致整个商品服务资源耗尽,无法继续对外提供服务。并且这种不可用可能沿请求调用链向上传递,这种现象被称为雪崩效应。

    雪崩效应应对策略

    针对造成雪崩效应的不同场景,可以使用不同的应对策略,没有一种通用所有场景的策略,参考如下:

    • 硬件故障:多机房容灾、异地多活等。
    • 流量激增:服务自动扩容、流量控制(限流、关闭重试)等。
    • 缓存穿透:缓存预加载、缓存异步加载等。
    • 程序BUG:修改程序bug、及时释放资源等。
    • 同步等待:资源隔离、MQ解耦、不可用服务调用快速失败等。资源隔离通常指不同服务调用采用不同的线程池;不可用服务调用快速失败一般通过熔断器模式结合超时机制实现。

    综上所述,如果一个应用不能对来自依赖的故障进行隔离,那该应用本身就处在被拖垮的风险中。 因此,为了构建稳定、可靠的分布式系统,我们的服务应当具有自我保护能力,当依赖服务不可用时,当前服务启动自我保护功能,从而避免发生雪崩效应。本文将重点介绍使用Hystrix解决同步等待的雪崩问题。

    初探Hystrix

    Hystrix [hɪst'rɪks],中文含义是豪猪,因其背上长满棘刺,从而拥有了自我保护的能力。本文所说的Hystrix是Netflix开源的一款容错框架,同样具有自我保护能力。为了实现容错和自我保护,下面我们看看Hystrix如何设计和实现的。

    Hystrix设计目标:

    • 对来自依赖的延迟和故障进行防护和控制——这些依赖通常都是通过网络访问的
    • 阻止故障的连锁反应
    • 快速失败并迅速恢复
    • 回退并优雅降级
    • 提供近实时的监控与告警

    Hystrix遵循的设计原则:

    • 防止任何单独的依赖耗尽资源(线程)
    • 过载立即切断并快速失败,防止排队
    • 尽可能提供回退以保护用户免受故障
    • 使用隔离技术(例如隔板,泳道和断路器模式)来限制任何一个依赖的影响
    • 通过近实时的指标,监控和告警,确保故障被及时发现
    • 通过动态修改配置属性,确保故障及时恢复
    • 防止整个依赖客户端执行失败,而不仅仅是网络通信

    Hystrix如何实现这些设计目标?

    • 使用命令模式将所有对外部服务(或依赖关系)的调用包装在HystrixCommand或HystrixObservableCommand对象中,并将该对象放在单独的线程中执行;
    • 每个依赖都维护着一个线程池(或信号量),线程池被耗尽则拒绝请求(而不是让请求排队)。
    • 记录请求成功,失败,超时和线程拒绝。
    • 服务错误百分比超过了阈值,熔断器开关自动打开,一段时间内停止对该服务的所有请求。
    • 请求失败,被拒绝,超时或熔断时执行降级逻辑。
    • 近实时地监控指标和配置的修改。
  • 相关阅读:
    ZeptoLab Code Rush 2015
    UVa 10048 Audiophobia【Floyd】
    POJ 1847 Tram【Floyd】
    UVa 247 Calling Circles【传递闭包】
    UVa 1395 Slim Span【最小生成树】
    HDU 4006 The kth great number【优先队列】
    UVa 674 Coin Change【记忆化搜索】
    UVa 10285 Longest Run on a Snowboard【记忆化搜索】
    【NOIP2016提高A组模拟9.28】求导
    【NOIP2012模拟10.9】电费结算
  • 原文地址:https://www.cnblogs.com/guo-xu/p/11052450.html
Copyright © 2011-2022 走看看