1 导读
高可用性这个 topic, 然后咱们会用几讲的时间来讲解一下如何用 hystrix, 来构建高可用的服务的架构
咱们会用一个真实的项目背景, 作为业务场景, 来带出来在这个特定的业务场景下, 可能会产生哪些各种各样的可用性的一些问题
针对这些问题, 我们用 hystrix 的解决方案和原理是什么
带着大家, 纯手工将所有的服务的高可用架构的代码, 全部纯手工自己敲出来
形成高可用服务架构的项目实战的一个教程
2 Hystrix 是什么
在分布式系统中, 每个服务都可能会调用很多其他服务, 被调用的那些服务就是依赖服务, 有的时候某些依赖服务出现故障也是很常见的.
Hystrix 可以让我们在分布式系统中对服务间的调用进行控制, 加入一些调用延迟或者依赖故障的容错机制.
Hystrix 通过将依赖服务进行资源隔离, 进而避免某个依赖服务出现故障的时候, 在整个系统所有的依赖服务调用中蔓延, 同时 Hystrix 还提供故障时的 fallback 降级机制
总而言之, Hystrix 通过这些方法帮助我们提升分布式系统的可用性和稳定性
什么是分布式系统以及其中的故障和 hystrix
image
3 Hystrix 的历史
hystrix, 一种高可用保障的框架, 类似于 spring(IoC,mvc),mybatis,activiti,lucene, 框架, 预先封装好的为了解决某个特定领域的特定问题的一套代码库
框架, 用了框架之后, 来解决这个领域的特定的问题, 就可以大大减少我们的工作量, 提升我们的工作质量和工作效率, 框架, hystrix, 就是高可用性保障的一个框架
Netflix(可以认为是国外的优酷或者爱奇艺之类的视频网站),API 团队从 2011 年开始做一些提升系统可用性和稳定性的工作, Hystrix 就是从那时候开始发展出来的.
在 2012 年的时候, Hystrix 就变得比较成熟和稳定了, Netflix 中, 除了 API 团队以外, 很多其他的团队都开始使用 Hystrix.
时至今日, Netflix 中每天都有数十亿次的服务间调用, 通过 Hystrix 框架在进行, 而 Hystrix 也帮助 Netflix 网站提升了整体的可用性和稳定性
2018 年 11 月, Hystrix 在其 GitHub 主页宣布, 不再开放新功能, 推荐开发者使用其他仍然活跃的开源项目. 维护模式的转变绝不意味着 Hystrix 不再有价值. 相反, Hystrix 激发了很多伟大的想法和项目, 其思想仍值得我们深入学习!
4 Hystrix 的设计原则
对依赖服务调用时出现的调用延迟和调用失败进行控制和容错保护
在复杂的分布式系统中, 阻止某一个依赖服务的故障在整个系统中蔓延, 服务 A-> 服务 B-> 服务 C, 服务 C 故障了, 服务 B 也故障了, 服务 A 故障了, 整套分布式系统全部故障, 整体宕机
提供 fail-fast(快速失败) 和快速恢复的支持
提供 fallback 优雅降级的支持
支持近实时的监控, 报警以及运维操作 5 Hystrix 要解决的问题在复杂的分布式系统架构中, 每个服务都有很多的依赖服务, 而每个依赖服务都可能会故障
如果服务没有和自己的依赖服务进行隔离, 那么可能某一个依赖服务的故障就会拖垮当前这个服务
举例来说
某个服务有 30 个依赖服务, 每个依赖服务的可用性非常高, 已经达到了 99.99% 的高可用性
那么该服务的可用性就是 99.99% 的 30 次方, 也就是 99.7% 的可用性
99.7% 的可用性就意味着 3% 的请求可能会失败, 因为 3% 的时间内系统可能出现了故障不可用了
对于 1 亿次访问来说, 3% 的请求失败, 也就意味着 300 万次请求会失败, 也意味着每个月有 2 个小时的时间系统是不可用的
在真实生产环境中, 可能更加糟糕
上面也就是说, 即使你每个依赖服务都是 99.99% 高可用性, 但是一旦你有几十个依赖服务, 还是会导致你每个月都有几个小时是不可用的
画图分析说, 当某一个依赖服务出现了调用延迟或者调用失败时, 为什么会拖垮当前这个服务? 以及在分布式系统中, 故障是如何快速蔓延的?
依赖服务的故障导致服务被拖垮以及故障的蔓延示意图
image
6 Hystrix 的更加细节的设计原则
阻止任何一个依赖服务耗尽所有的资源, 比如 tomcat 中的所有线程资源
避免请求排队和积压, 采用限流和 fail fast 来控制故障
提供 fallback 降级机制来应对故障
使用资源隔离技术, 比如 bulkhead(舱壁隔离技术),swimlane(泳道技术),circuit breaker(短路技术), 来限制任何一个依赖服务的故障的影响
通过近实时的统计 / 监控 / 报警功能, 来提高故障发现的速度
通过近实时的属性和配置热修改功能, 来提高故障处理和恢复的速度
保护依赖服务调用的所有故障情况, 而不仅仅只是网络故障情况
调用这个依赖服务的时候, client 调用包有 bug, 阻塞, 等等, 依赖服务的各种各样的调用的故障, 都可以处理
7 Hystrix 如何实现它的目标
通过 HystrixCommand 或者 HystrixObservableCommand 来封装对外部依赖的访问请求, 这个访问请求一般会运行在独立的线程中, 资源隔离
对于超出我们设定阈值的服务调用, 直接进行超时, 不允许其耗费过长时间阻塞住. 这个超时时间默认是 99.5% 的访问时间, 但是一般我们可以自己设置一下
为每一个依赖服务维护一个独立的线程池, 或者是 semaphore, 当线程池已满时, 直接拒绝对这个服务的调用
对依赖服务的调用的成功次数, 失败次数, 拒绝次数, 超时次数, 进行统计
如果对一个依赖服务的调用失败次数超过了一定的阈值, 自动进行熔断, 在一定时间内对该服务的调用直接降级, 一段时间后再自动尝试恢复
当一个服务调用出现失败, 被拒绝, 超时, 短路等异常情况时, 自动调用 fallback 降级机制
对属性和配置的修改提供近实时的支持
画图分析, 对依赖进行资源隔离后, 如何避免依赖服务调用延迟或失败导致当前服务的故障
资源隔离如何保护依赖服务的故障不要拖垮整个系统
image
参考
《Java 工程师面试突击第 1 季 - 中华石杉老师》
来源: http://www.jianshu.com/p/f17ee06a4237