ASPIRE

Hystrix学习

=Start=

缘由：

整理学习Hystrix相关的资料，方便日常参考和学习。

正文：

参考解答：
Hystrix是什么？

在分布式环境下，系统不可避免地会遇到依赖服务失效的问题，这些问题可能是依赖服务的高延迟，或者依赖服务抛出异常。使用 Hystrix 增加延迟/失败容忍逻辑，能帮助你解决这些服务之间交互的问题。

Hystrix 能使你的系统在出现依赖服务失效的时候，通过隔离系统所依赖的服务，防止服务级联失败，同时提供失败回退机制，更优雅地应对失效，并使你的系统能更快地从异常中恢复。

引入Hystrix的目的

分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况，容易造成服务的雪崩，影响系统的稳定性。为了应对服务雪崩，一种常见的做法是手动服务降级。虽然能够防止服务发生雪崩效应，但是手段服务降级的方式过于粗暴，人工操作也有一定的响应延迟。因此为了更好的应对这种服务雪崩的场景，为系统引入熔断机制。

系统依赖梳理

前期对需要接入Hystrix的系统的依赖服务进行梳理，主要梳理服务的QPS、TP99、TimeOut等指标，还有服务的调用方式、服务对上层的行为。在梳理完这些指标后，结合系统自身情况，对服务进行分级（分级可以按照业务的重要性或者访问量来进行分级）。

Hystrix整体生态

主要分为五个部分：

  • 多语言支持：对多语言的支持，目前github已有的项目支持Java、Golang和C#。
  • Spring体系的支持：可以与当前spring的热门组件spring boot、spring cloud相结合。
  • 对Netflix体系内部组件的支持：
    Servo：     简化JMX MBean的实现,使性能指标数据更容易获取。用于指标的获取，如线程池。
    Eureka：   服务发现，SpringCloud将它集成在自己的子项目spring-cloud-netflix中,实现SpringCloud的服务发现功能。
    Archaius：基于java的配置管理类库，主要用于多配置存储的动态获取。主要功能是对apache common configuration类库的扩展。动态配置靠它。
    Turbine：  监控聚合，使用Hystrix监控，我们需要打开每一个服务实例的监控信息来查看。而Turbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。
  • 对外部项目的融合：主要是项目的捐赠。
    Javanica：使用注解模式接入hystrix需要此jar包。
  • 支持自定义插件：多种类型的自定义插件，可以自研组件集成。
Hystrix设计思想

整体采用舱壁模式的思想来隔离相互之间的依赖关系，并限制对其中任何一个的并发访问。

Hystrix设计原则
  • 防止单个依赖耗尽容器（例如 Tomcat，Jetty）内所有用户线程。
  • 降低系统负载，对无法及时处理的请求快速失败（fail fast）而不是排队。
  • 提供失败回退，以在必要时让失效对用户透明化。
  • 使用隔离机制（例如『舱壁』/『泳道』模式，熔断器模式等）降低依赖服务对整个系统的影响。
  • 针对系统服务的度量、监控和报警，提供优化以满足近实时性的要求。
  • 在 Hystrix 绝大部分需要动态调整配置并快速部署到所有应用方面，提供优化以满足快速恢复的要求。
  • 能保护应用不受依赖服务的整个执行过程中失败的影响，而不仅仅是网络请求。
参考链接：

=END=

Docker

,
,

《 “Hystrix学习” 》 有 6 条评论

  1. Spring Cloud与微服务学习笔记-注册与发现
    https://since1986.github.io/blog/17601ed9.html
    `
    1. 前言
    2. 什么是服务注册与发现
    3. 为什么要有“服务注册与发现”
    4. Eureka
    　　4.1. Eureka的概念
    　　4.2. 如何使用Eureka
    　　4.3. 用Eureka来做服务注册与发现的demo
    　　　　4.3.1. 单实例eureka server + 单实例service
    　　　　4.3.2. 多实例eureka server + 多实例service
    　　4.4. 深入了解Eureka
    　　　　4.4.1. Eureka高层架构
    　　　　4.4.2. 了解服务消费端与服务提供端的通讯
    5. 扩展阅读
    6. 总结
    7. 参考资料
    `

    回复

  3. 聊聊Netflix技术那些大胆的创新
    https://mp.weixin.qq.com/s/Zogjk_xl7Q0nWNei1ZAG4g
    `
    注意，Netflix技术本身也在快速的迭代进化中，本文主要基于Netflix在slideshare上的分享总结而成，其中的很多内容目前可能已经过时，但是Netflix的创新文化和精神仍然值得我们学习借鉴。

    一、大规模生产级微服务架构实践

    二、开源整个微服务技术栈
    Netflix为啥热衷于要搞开源？
    1、将自己的解决方案建立为行业标准和最佳实践
    2、建立Netflix技术品牌
    3、雇佣、留住和吸引顶级工程师
    4、从共享生态中获得反馈输入并受益

    三、系统全部迁移AWS公有云

    四、在AWS基础上打造PaaS平台
    Netflix在AWS IAAS的基础上封装打造了自己的PaaS云平台服务(大部分组件开源)，包括：
    1、平台运行时服务(Eureka，Zuul, Edda，Atlas)
    2、平台库和框架(Karyon/Ribbon，Hystrix，RxJava, Governator，Servo, Archaius, Astyanax)
    3、平台大数据和缓存服务(Cassandra/ES/Hadoop Platform as a Service, EVCache，S3)
    4、平台工具和服务(Asgard/Aminator， SimianArmy/ChaosMonkey, ICE)

    五、两地三中心高可用

    六、采用Cassandra NoSql作为主数据库

    七、镜像部署和发布自动刹车

    八、反脆弱架构
    Netflix大胆提出反脆弱架构的理念（架构师受到尼古拉斯·塔勒布《反脆弱》一书的启发，并将其应用到架构领域）：为了让你的系统更加健壮，不是将它们严格保护起来，而是主动随机性地的增加一些破坏性测试，逼迫研发人员做好高可用。

    九、几乎没有流程，没有员工手册
    Netflix是一家高度重视人才密度，重自由和责任文化，轻流程的公司。公司没有正式的员工手册，只有一条简单的指导原则：
    Act in Netflix’s best interest，以Netflix的最佳利益行事。

    十、No CTO, No Ops
    Netflix的技术这么牛逼，但它是没有技术CTO职位的，只有首席产品CPO，工程团队和产品团队的VP都向CPO汇报。这样做更多是为了产品导向，便于技术和产品沟通合作，避免两边扯，避免业务驱动还是技术驱动的悖论，大家都是产品驱动。Netflix把它称为BusDevOps组织架构。

    十一、无论公司兴衰，始终支付市场最高工资
    不用多解释，这大概是Netflix最有霸气底气和牛逼的一点。据我在米国的同学讲，去Netflix基本是硅谷顶薪，博士毕业去给开了超过30万美金的年薪（这还是前几年的行情）。一般进去难，去了留下来也不容易，不胜任的被客客气气劝退的有。能留下来的一般也不跳，因为再跳也没有更高的待遇了。
    `

    回复

  4. 如何健壮你的后端服务
    https://mp.weixin.qq.com/s/LAmPTV0NMGGI5gGY_y8D_g
    `
    对每一个程序员而言，故障都是悬在头上的达摩克利斯之剑，都唯恐避之不及，如何避免故障是每一个程序员都在苦苦追寻希望解决的问题。对于这一问题，大家都可以从需求分析、架构设计、代码编写、测试、code review、上线、线上服务运维等各个视角给出自己的答案。

    我们大部分服务都是如下的结构，既要给使用方使用，又依赖于他人提供的第三方服务，中间又穿插了各种业务、算法、数据等逻辑，这里面每一块都可能是故障的来源。如何避免故障？我用一句话概括 : 怀疑第三方，防备使用方，做好自己。

    1. 怀疑第三方
    1.1 有兜底，制定好业务降级方案
    1.2 遵循快速失败原则，一定要设置超时时间
    1.3 适当保护第三方，慎重选择重试机制

    2. 防备使用方
    2.1 设计一个好的 API（RPC、Restful），避免误用
    2.2 流量控制，按服务分配流量，避免滥用
    2.3 做好自己
    2.3.1 单一职责原则
    2.3.2 控制资源的使用
    2.3.2.1 CPU 资源怎么限制
    2.3.2.2 内存资源怎么限制
    2.3.2.3 网络资源怎么限制
    2.3.2.4 磁盘资源怎么限制
    2.3.3 避免单点
    `

    回复

  5. 谈谈服务雪崩、降级与熔断
    https://mp.weixin.qq.com/s/9w2W6mojhBWGwR9QmGUvvg
    `
    服务雪崩：当一个服务失败，导致整条链路的服务都失败的情形，我们称之为服务雪崩。

    服务熔断：当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。

    服务降级：
    1、当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，增加响应速度！
    2、当下游的服务因为某种原因不可用，上游主动调用本地的一些降级逻辑，避免卡顿，迅速返回给用户！

    服务降级 和 服务熔断 之间的关系：
    服务降级有很多种降级方式！如开关降级、限流降级、熔断降级！服务熔断属于降级方式的一种！
    `

    回复

  6. 一不小心就让Java开发者踩坑的fail-fast是个什么鬼？
    https://mp.weixin.qq.com/s/p1u2f3sw6y2MtsxTaBRkQA
    `
    1、什么是fail-fast
    首先我们看下维基百科中关于fail-fast的解释：

    在系统设计中，快速失效系统一种可以立即报告任何可能表明故障的情况的系统。快速失效系统通常设计用于停止正常操作，而不是试图继续可能存在缺陷的过程。这种设计通常会在操作中的多个点检查系统的状态，因此可以及早检测到任何故障。快速失败模块的职责是检测错误，然后让系统的下一个最高级别处理错误。

    其实，这是一种理念，fail-fast就是在做系统设计的时候先考虑异常情况，一旦发生异常，直接停止并上报。

    这样做的好处就是可以预先识别出一些错误情况，一方面可以避免执行复杂的其他代码，另外一方面，这种异常情况被识别之后也可以针对性的做一些单独处理。

    2、集合类中的fail-fast

    3、异常复现

    4、异常原理

    5、fail-safe
    为了避免触发fail-fast机制，导致异常，我们可以使用Java中提供的一些采用了fail-safe机制的集合类。

    fail-save的集合容器在遍历时不是直接在集合内容上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历。

    java.util.concurrent包下的容器都是fail-safe的，可以在多线程下并发使用，并发修改。同时也可以在foreach中进行add/remove 。

    6、Copy-On-Write
    Copy-On-Write简称COW，是一种用于程序设计中的优化策略。其基本思路是，从一开始大家都在共享同一个内容，当某个人想要修改这个内容的时候，才会真正把内容Copy出去形成一个新的内容然后再改，这是一种延时懒惰策略。
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注