本文详细介绍了Hystrix和Sentinel这两个微服务中的流量防卫工具。Hystrix提供熔断、隔离、Fallback等功能，以应对服务间的依赖问题和雪崩效应。Sentinel是阿里巴巴的流量防卫兵，支持丰富的流量控制、熔断降级和系统负载保护。Sentinel具有轻量级、丰富的应用场景和动态规则调整等特性，是Hystrix的潜在替代品。
目录
二、Sentinel 分布式系统的流量防卫兵 SpringCloud alibaba
一、Hystrix SpringCloud
1、Hystrix名字由来？
Hystrix对应的中文名字是“豪猪”，豪猪周身长满了刺，能保护自己不受天敌的伤害，代表了一种防御机制，这与hystrix本身的功能不谋而合，因此Netflix团队将该框架命名为Hystrix，并使用了对应的卡通形象做作为logo。
2、Hystrix是什么？
在一个分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，如何能够保证在一个依赖出问题的情况下，不会导致整体服务失败，这个就是Hystrix需要做的事情。
Hystrix提供了熔断、隔离、Fallback、cache、监控等功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用。
下图是一个Hystrix在微服务系统中的应用及角色：
Eureka/Consul/Zookeeper：服务发现 （根据情况选择一个,eureka已经宣布闭源）
Hystrix：断路器
Zuul：智能路由
Ribbon/Feign：客户端负载均衡 （Feign用的更多）
Turbine&hystrix-dashboard：集群监控
Springcloud-config：远程获取配置文件
3、为什么需要Hystrix ?
在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC） 。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
如下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。
Hystrix语义为“豪猪"，具有自我保护的能力。 Hystrix的出现即为解决雪崩效应。
进一步解释：
在大中型分布式系统中，通常系统很多依赖(HTTP,hession,Netty,Dubbo等)，如下图:
在高并发访问下,这些依赖的稳定性与否对系统的影响非常大,但是依赖有很多不可控问题:如网络连接缓慢，资源繁忙，暂时不可用，服务脱机等.
如下图：QPS为50的依赖 I 出现不可用，但是其他依赖仍然可用.
当依赖I 阻塞时,大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性.如下图:
在复杂的分布式架构的应用程序有很多的依赖，都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。
例如：一个依赖30个SOA服务的系统,每个服务99.99%可用。
99.99%的30次方 ≈ 99.7%
0.3% 意味着一亿次请求 会有 3,000,00次失败
换算成时间大约每月有2个小时服务不稳定.
随着服务依赖数量的变多，服务不稳定的概率会成指数性提高.
解决问题方案：对依赖做隔离，Hystrix就是处理依赖隔离的框架,同时也是可以帮我们做依赖服务的治理和监控.
Netflix 公司开发并成功使用Hystrix,使用规模如下:
The Netflix API processes 10+ billion HystrixCommand executions per day using thread isolation.
Each API instance has 40+ thread-pools with 5-20 threads in each (most are set to 10).
（大致意思是：Netflix 内部API 每天100亿的HystrixCommand依赖请求使用线程隔，每个应用大约40多个线程池，每个线程池大约5-20个线程。（但一般设置为10个线程池）。
4、Hystrix的设计原则是什么？
资源隔离（线程池隔离和信号量隔离）机制：限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其它服务调用。
<
最低0.47元/天 解锁文章
3585
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
