一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第24天，点击查看活动详情
前言
- 每天都能接到运营的反馈系统挂了，这个接口挂了那个服务不正常了。但是往往这些情况很有可能是因为其中一个关节出错，甚至这个节点对整体数据不会起到主体作用。但是却因为他导致整体挂了。
- 在这种情况下我终于发现了hystrix这个好用的东西。这是啥东西呢？他就是用来做备胎的。他负责对服务的代理。代理失败后会立马切换到备胎方案。活着服务出错率达到一定程度后立马将后续的请求拒绝掉，或者一直使用备胎应对。这样就不会让整个系统挂了。比如我们记录日志的服务挂了，从用户的使用角度上来说真的没必要因为日志导致我们的功能不正常。日挣挂了我们修复就行了。所以hystrix必须引入到系统中
功能
- 对网络延迟及故障进行容错
- 阻断分布式系统雪崩
- 快速失败并平缓恢复
- 服务降级
- 实时监控、警报
优点
- 如果我们将hystrix加载payment原生服务就不会出现上面第三条情况。为什么我会放在order上就是想让大家看看雪崩的场景。在并发50的时候因为payment设置的最大线程也是10，他本身也是有吞吐量的。在order#getpyament/id接口虽然在order模块因为hystrix线程隔离有自己的线程运行，但是因为原生服务不给力导致自己调用超时从而影响运行的效果。这样演示也是为了后续引出fallback解决雪崩的一次场景模拟吧。
- 我们可以在payment服务中通过hystrix设置fallback。保证payment服务低延迟从而保证order模块不会因为payment自己缓慢导致order#getpayment这种正常接口异常。
- 还有一点虽然通过hystrix进行线程隔离了。但是我们在运行其他接口时响应时间也会稍长点。因为CPU在进行线程切换的时候是有开销的。这一点也是痛点。我们并不能随心所欲的进行线程隔离的。这就引出我们的信号量隔离了。
