1- # 1 导读
2- 3- 高可用性这个topic,然后咱们会用几讲的时间来讲解一下如何用hystrix,来构建高可用的服务的架构
4- 5- 咱们会用一个真实的项目背景,作为业务场景,来带出来在这个特定的业务场景下,可能会产生哪些各种各样的可用性的一些问题
6- 7- 针对这些问题,我们用hystrix的解决方案和原理是什么
8- 9- 带着大家,纯手工将所有的服务的高可用架构的代码,全部纯手工自己敲出来
10- 11- 形成高可用服务架构的项目实战的一个教程
12- 13- # 2 Hystrix是什么
14- 1+ # Hystrix是什么
152在分布式系统中,每个服务都可能会调用很多其他服务,被调用的那些服务就是依赖服务,有的时候某些依赖服务出现故障也是很常见的。
163
174Hystrix可以让我们在分布式系统中对服务间的调用进行控制,加入一些调用延迟或者依赖故障的容错机制。
185
196Hystrix通过将依赖服务进行** 资源隔离** ,进而避免某个依赖服务出现故障的时候,在整个系统所有的依赖服务调用中蔓延,同时Hystrix还提供故障时的fallback降级机制
207
218总而言之,Hystrix通过这些方法帮助我们提升分布式系统的可用性和稳定性
22- 23- - 什么是分布式系统以及其中的故障和hystrix
24- ![ ] ( https://ask.qcloudimg.com/http-save/1752328/d1razflqky.png )
25- 26- # 3 Hystrix的历史
27- 28- hystrix,一种高可用保障的框架,类似于spring(ioc,mvc),mybatis,activiti,lucene,框架,预先封装好的为了解决某个特定领域的特定问题的一套代码库
29- 30- 框架,用了框架之后,来解决这个领域的特定的问题,就可以大大减少我们的工作量,提升我们的工作质量和工作效率,框架,hystrix,就是高可用性保障的一个框架
31- 32- Netflix(可以认为是国外的优酷或者爱奇艺之类的视频网站),API团队从2011年开始做一些提升系统可用性和稳定性的工作,Hystrix就是从那时候开始发展出来的。
9+ # Hystrix的历史
10+ hystrix,一种高可用保障的框架,Netflix API团队从2011年开始做一些提升系统可用性和稳定性的工作,Hystrix就是从那时候开始发展出来的。
3311
3412在2012年的时候,Hystrix就变得比较成熟和稳定了,Netflix中,除了API团队以外,很多其他的团队都开始使用Hystrix。
3513
36- 时至今日,Netflix中每天都有数十亿次的服务间调用,通过Hystrix框架在进行,而Hystrix也帮助Netflix网站提升了整体的可用性和稳定性
37- 38142018 年 11 月,Hystrix 在其 [ Github 主页] ( https://github.com/Netflix/Hystrix/blob/master/README.md#hystrix-status ) 宣布,不再开放新功能,推荐开发者使用其他仍然活跃的开源项目。维护模式的转变绝不意味着 Hystrix 不再有价值。相反,Hystrix 激发了很多伟大的想法和项目,其思想仍值得我们深入学习!
3915
40- # 4 Hystrix的设计原则
41- 16+ # Hystrix的设计原则
4217- 对依赖服务调用时出现的调用延迟和调用失败进行控制和容错保护
4318- 在复杂的分布式系统中,阻止某一个依赖服务的故障在整个系统中蔓延,服务A->服务B->服务C,服务C故障了,服务B也故障了,服务A故障了,整套分布式系统全部故障,整体宕机
4419- 提供fail-fast(快速失败)和快速恢复的支持
4520- 提供fallback优雅降级的支持
4621- 支持近实时的监控、报警以及运维操作5 Hystrix要解决的问题在复杂的分布式系统架构中,每个服务都有很多的依赖服务,而每个依赖服务都可能会故障
4722如果服务没有和自己的依赖服务进行隔离,那么可能某一个依赖服务的故障就会拖垮当前这个服务
4823
49- 举例来说
50- 24+ # 举例
5125某个服务有30个依赖服务,每个依赖服务的可用性非常高,已经达到了99.99%的高可用性
5226
5327那么该服务的可用性就是99.99%的30次方,也就是99.7%的可用性
5428
55- 99.7%的可用性就意味着3%的请求可能会失败,因为3%的时间内系统可能出现了故障不可用了
56- 57- 对于1亿次访问来说,3%的请求失败,也就意味着300万次请求会失败,也意味着每个月有2个小时的时间系统是不可用的
58- 59- 在真实生产环境中,可能更加糟糕
60- 61- 上面也就是说,即使你每个依赖服务都是99.99%高可用性,但是一旦你有几十个依赖服务,还是会导致你每个月都有几个小时是不可用的
62- 63- 画图分析说,当某一个依赖服务出现了调用延迟或者调用失败时,为什么会拖垮当前这个服务?以及在分布式系统中,故障是如何快速蔓延的?
29+ 99.7%的可用性就意味着3%的请求可能会失败,因为3%的时间内系统可能出现了故障不可用了。
6430
65- - 依赖服务的故障导致服务被拖垮以及故障的蔓延示意图
66- ![ ] ( https://ask.qcloudimg.com/http-save/1752328/twu9s9m6xx.png )
67- 68- # 6 Hystrix的更加细节的设计原则
31+ 对于1亿次访问来说,3%的请求失败,也就意味着300万次请求会失败,也意味着每个月有2个小时的时间系统是不可用的。在真实生产环境中,可能更加糟糕。
6932
33+ 上面也就是说,即使你每个依赖服务都是99.99%高可用性,但是一旦你有几十个依赖服务,还是会导致你每个月都有几个小时是不可用的。
34+ ![ ] ( https://img-blog.csdnimg.cn/83a446c51c3e4b27beb3e42560458ca0.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBASmF2YUVkZ2Uu,size_20,color_FFFFFF,t_70,g_se,x_16 )
35+ # Hystrix的更加细节的设计原则
7036- 阻止任何一个依赖服务耗尽所有的资源,比如tomcat中的所有线程资源
7137- 避免请求排队和积压,采用限流和fail fast来控制故障
7238- 提供fallback降级机制来应对故障
@@ -77,8 +43,7 @@ Netflix(可以认为是国外的优酷或者爱奇艺之类的视频网站)
7743
7844调用这个依赖服务的时候,client调用包有bug,阻塞,等等,依赖服务的各种各样的调用的故障,都可以处理
7945
80- # 7 Hystrix如何实现它的目标
81- 46+ # Hystrix如何实现它的目标
8247- 通过HystrixCommand或者HystrixObservableCommand来封装对外部依赖的访问请求,这个访问请求一般会运行在独立的线程中,资源隔离
8348- 对于超出我们设定阈值的服务调用,直接进行超时,不允许其耗费过长时间阻塞住。这个超时时间默认是99.5%的访问时间,但是一般我们可以自己设置一下
8449- 为每一个依赖服务维护一个独立的线程池,或者是semaphore,当线程池已满时,直接拒绝对这个服务的调用
@@ -89,15 +54,5 @@ Netflix(可以认为是国外的优酷或者爱奇艺之类的视频网站)
8954
9055画图分析,对依赖进行资源隔离后,如何避免依赖服务调用延迟或失败导致当前服务的故障
9156
92- - 资源隔离如何保护依赖服务的故障不要拖垮整个系统![ ] ( https://ask.qcloudimg.com/http-save/1752328/0tx22cj2bs.png )
93- 94- # 参考
95- 96- - 《Java工程师面试突击第1季-中华石杉老师》
97- 98- # X 交流学习
99- ![ ] ( https://img-blog.csdnimg.cn/20190504005601174.jpg )
100- ## [ Java交流群] ( https://jq.qq.com/?_wv=1027&k=5UB4P1T )
101- ## [ 博客] ( https://blog.csdn.net/qq_33589510 )
102- 103- ## [ Github] ( https://github.com/Wasabi1234 )
57+ - 资源隔离如何保护依赖服务的故障不要拖垮整个系统
58+ ![ ] ( https://img-blog.csdnimg.cn/b7b99687fdbb4352974f7006f5f5c989.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBASmF2YUVkZ2Uu,size_20,color_FFFFFF,t_70,g_se,x_16 )
0 commit comments