Hystrix：构建高可用电商详情页缓存服务的容错框架-优快云博客

本文链接：https://blog.youkuaiyun.com/u013720069/article/details/111272048

Hystrix是什么

在分布式系统中，每个服务都可能会调用很多其他服务，被调用的那些服务就是依赖服务，有的时候某些依赖服务出现故障也是很正常的。
Hystrix可以让我们在分布式系统中对服务间的调用进行控制，加入一些调用延迟或者依赖故障的容错机制。
Hystrix通过将依赖服务进行资源隔离，进而组织某个依赖服务出现故障的时候，避免这种故障在整个系统所有的依赖服务调用中进行蔓延，同时Hystrix还提供故障时的fallback降级机制
总而言之，Hystrix通过这些方法帮助我们提升分布式系统的可用性和稳定性

Hystrix的历史

hystrix，就是一种高可用保障的一个框架，类似于spring（ioc，mvc），mybatis，activiti，lucene，框架，预先封装好的为了解决某个特定领域的特定问题的一套代码库框架，用了框架之后，来解决这个领域的特定的问题，就可以大大减少我们的工作量，提升我们的工作质量和工作效率，框架
hystrix，高可用性保障的一个框架
Netflix（可以认为是国外的优酷或者爱奇艺之类的视频网站），API团队从2011年开始做一些提升系统可用性和稳定性的工作，Hystrix就是从那时候开始发展出来的。
在2012年的时候，Hystrix就变得比较成熟和稳定了，Netflix中，除了API团队以外，很多其他的团队都开始使用Hystrix。
时至今日，Netflix中每天都有数十亿次的服务间调用，通过Hystrix框架在进行，而Hystrix也帮助Netflix网站提升了整体的可用性和稳定性

Hystrix的设计原则

hystrix为了实现高可用性的架构，设计hystrix的时候，一些设计原则是什么？？？

对依赖服务调用时出现的调用延迟和调用失败进行控制和容错保护
在复杂的分布式系统中，阻止某一个依赖服务的故障在整个系统中蔓延，服务A->服务B->服务C，服务C故障了，服务B也故障了，服务A故障了，整套分布式系统全部故障，整体宕机
提供fail-fast（快速失败）和快速恢复的支持
提供fallback优雅降级的支持
支持近实时的监控、报警以及运维操作

完全描述了hystrix的功能，提供整个分布式系统的高可用的架构

Hystrix要解决的问题

说到Hystrix的作用不得不提一下服务雪崩
服务雪崩是分布式系统都会面临的问题，如果处理不好会导致很严重的生产事故。
复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。
在这里插入图片描述
多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”.
对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
在这里插入图片描述
在复杂的分布式系统架构中，每个服务都有很多的依赖服务，而每个依赖服务都可能会故障，
如果服务没有和自己的依赖服务进行隔离，那么可能某一个依赖服务的故障就会拖垮当前这个服务
举例来说，某个服务有30个依赖服务，每个依赖服务的可用性非常高，已经达到了99.99%的高可用性
那么该服务的可用性就是99.99%的30次方，也就是99.7%的可用性
99.7%的可用性就意味着3%的请求可能会失败，因为3%的时间内系统可能出现了故障不可用了
对于1亿次访问来说，3%的请求失败，也就意味着300万次请求会失败，也意味着每个月有2个小时的时间系统是不可用的
在真实生产环境中，可能更加糟糕
上面也就是说，即使你每个依赖服务都是99.99%高可用性，但是一旦你有几十个依赖服务，还是会导致你每个月都有几个小时是不可用的
画图分析说，当某一个依赖服务出现了调用延迟或者调用失败时，为什么会拖垮当前这个服务？以及在分布式系统中，故障是如何快速蔓延的？
在这里插入图片描述

Hystrix的更加细节的设计原则

（1）阻止任何一个依赖服务耗尽所有的资源，比如tomcat中的所有线程资源
（2）避免请求排队和积压，采用限流和fail fast来控制故障
（3）提供fallback降级机制来应对故障
（4）使用资源隔离技术，比如bulkhead（舱壁隔离技术），swimlane（泳道技术），circuit breaker（短路技术），来限制任何一个依赖服务的故障的影响
（5）通过近实时的统计/监控/报警功能，来提高故障发现的速度
（6）通过近实时的属性和配置热修改功能，来提高故障处理和恢复的速度
（7）保护依赖服务调用的所有故障情况，而不仅仅只是网络故障情况
调用这个依赖服务的时候，client调用包有bug，阻塞，等等，依赖服务的各种各样的调用的故障，都可以处理

Hystrix是如何实现它的目标

（1）通过HystrixCommand或者HystrixObservableCommand来封装对外部依赖的访问请求，这个访问请求一般会运行在独立的线程中，资源隔离
（2）对于超出我们设定阈值的服务调用，直接进行超时，不允许其耗费过长时间阻塞住。这个超时时间默认是99.5%的访问时间，但是一般我们可以自己设置一下
（3）为每一个依赖服务维护一个独立的线程池，或者是semaphore，当线程池已满时，直接拒绝对这个服务的调用
（4）对依赖服务的调用的成功次数，失败次数，拒绝次数，超时次数，进行统计
（5）如果对一个依赖服务的调用失败次数超过了一定的阈值，自动进行熔断，在一定时间内对该服务的调用直接降级，一段时间后再自动尝试恢复
（6）当一个服务调用出现失败，被拒绝，超时，短路等异常情况时，自动调用fallback降级机制
（7）对属性和配置的修改提供近实时的支持
画图分析，对依赖进行资源隔离后，如何避免依赖服务调用延迟或失败导致当前服务的故障
在这里插入图片描述

电商网站的商品详情页缓存服务业务背景以及框架结构

我们这个课程，基于hystrix，如何来构建高可用的分布式系统的架构，项目实战
模拟真实业务的这么一个小型的项目，来全程贯穿，用这个项目中的业务场景去一个一个的讲解hystrix高可用的每个技术
纯讲hystrix，脱离实际的业务背景，听起来有点枯燥，大家学完了hystrix以后，可能没法完全感受到技术是如何融入我们的项目中的
大背景：电商网站，首页，商品详情页，搜索结果页，广告页，促销活动，购物车，订单系统，库存系统，物流系统
小背景：商品详情页，如何用最快的结果将商品数据填充到一个页面中，然后将页面显示出来
分布式系统：商品详情页，缓存服务，+底层源数据服务，商品信息服务，店铺信息服务，广告信息服务，推荐信息服务，综合起来组成一个分布式的系统

小型电商网站的商品详情页系统架构

（不是我们要讲解的）
在这里插入图片描述
页面模板
举个例子
将数据动态填充/渲染到一个html模板中，是什么意思呢？

<html>
    <title>#{name}的页面</title>
    <body>
         商品的价格是：#{price}
         商品的介绍：#{description}
    </body>
</html>

上面这个就可以认为是一个页面模板，里面的很多内容是不确定的，#{name}，#{price}，#{description}，这都是一些模板脚本，不确定里面的值是什么？
将数据填充/渲染到html模板中，是什么意思呢？
{
“name”: “iphone7 plus（玫瑰金+32G）”,
“price”: 5599.50
“description”: “这个手机特别好用。。。。。。”
}

<html>
    <title>iphone7 plus（玫瑰金+32G）的页面</title>
    <body>
         商品的价格是：5599.50
         商品的介绍：这个手机特别好用。。。。。。
    </body>
</html>

上面这个就是一份填充好数据的一个html页面

大型电商网站的商品详情页系统架构

在这里插入图片描述

缓存服务

缓存服务，订阅一个MQ的消息变更，如果有消息变更的话，那么就会发送一个网络请求，调用一个底层的对应的源数据服务的接口，去获取变更后的数据
将获取到的变更后的数据填充到分布式的redis缓存中去
高可用这一块儿，最可能出现说可用性不高的情况，是什么呢？就是说，在接收到消息之后，可能在调用各种底层依赖服务的接口时，会遇到各种不稳定的情况
比如底层服务的接口调用超时，200ms，2s都没有返回; 底层服务的接口调用失败，比如说卡了500ms之后，返回一个报错
在分布式系统中，对于这种大量的底层依赖服务的调用，就可能会出现各种可用性的问题，一旦没有处理好的话
可能就会导致缓存服务自己本身会挂掉，或者故障掉，就会导致什么呢？不可以对外提供服务，严重情况下，甚至会导致说整个商品详情页显示不出来
缓存服务接收到变更消息后，去调用各个底层依赖服务时的高可用架构的实现