最近看分布式服务容错的相关内容，想起了之前经历过的一次服务器雪崩事件，决定结合这个事件回顾一下微服务的容灾，并简单提一下Hystrix这个大佬
一、雪崩
当山坡积雪内部的内聚力抗拒不了它所受到的重力拉引时，便向下滑动，引起大量雪体崩塌，人们把这种自然现象称做雪崩。
拿错了.jpg
服务的雪崩现象：服务雪崩现象是一种因服务提供者的不可用导致服务调用者的不可用,并将不可用 逐渐放大 的过程
通俗的讲，在分布式系统架构中多个系统之间通常是通过远程RPC调用进行通信，也就是 A 系统调用 B 系统服务，B 系统调用 C 系统的服务。当尾部应用 C 发生故障而系统 B 没有服务降级时候可能会导致 B，甚至系统 A 瘫痪，这种现象被称为雪崩现象。
二、一次教科书式雪崩
-
背景
酒店CRS，订单系统需要依赖库存系统进行扣库存操作，而库存系统同时提供了对外的接口来实时更新酒店房间库存 -
事件过程
这次崩溃事件持续了近一小时，虽然那时候公司体量不大，损失不算严重，但订单系统长达一小时的服务崩溃仍然造成了不小的影响- 大约上午十点开始，业务方反映订单系统无法下单
- 发现库存系统无响应，立即重启服务
- 服务正常，可下单，但数分钟后再次崩溃
- 发现库存推送接口访问量巨大，远超平时
- 联系合作方停止推送，重启服务，业务恢复
-
事后复盘
- 库存数据库压力较大导致了响应变慢
- tomcat服务器超时断开连接，但service逻辑仍然在运转。
- 外部服务接收到超时异常马上重试
- 重复1、2、3步骤，导致库存服务压力增加
- 数据库恢复，但由于请求量暴增，服务已崩溃
- 重启服务后恢复，但外部有大量的重试请求再次压垮系统
三、 Hystrix
也就是在这次事件之后，我们部门开始在服务容灾方面进行努力，并引进了Hystrix这个服务容错框架。Hystrix应该是当下最流行的限流容错框架了，由Netflix开发，现在是springcloud官方使用的容错框架
Hystrix是Netflix解决自己业务不稳定性的一个限流容错框架，可以帮助我们解决微服务架构体系中的限流、降级、熔断等功能，提高系统稳定性。提供了完善的监控实现，并且Hystrix可以根据监控数据动态调整内部处理机制。
Hystrix的功能
- 资源隔离：Hystrix通过舱壁模式来分隔服务提供者，使得某服务提供方失败不会影响整个项目系统的稳定性。
- 熔断：Hystrix可以通过监控一段事件内的异常次数和响应速度来判断当前服务的健康状况，若服务健康状况不佳则进行熔断，熔断之后新的请求将不会调用实际的业务，而是通过快速失败或降级的方式来快速给用户进行响应
- 快速失败：熔断的后续选择之一，直接返回失败
- 降级：熔断的后续选择之一，降级到静态响应或是下级服务
- 监控报警：提供近实时的监控、报警和运维手段
指导这些功能的设计原则
- 防止单个依赖耗尽容器的用户线程
- 降低系统负载，对无法及时处理的请求使用快速失败机制而不是排队
- 通过隔离技术（*舱壁，泳道，断路器）来降低依赖服务对整个系统的影响
- 提供失败回退功能，意在必要时让失效对用户透明化
- 针对系统提供服务的监控、报警、度量，满足近实时性的要求
舱壁模式：在货船运输过程中，为防止某个货仓意外火灾，而导致整船货物的损失，通常会分隔货仓，从而使损失限制在一个货舱内
四、 最后的废话
服务的容错、容灾是分布式系统稳定性中非常重要的一环，Hystrix也是目前相当流行的解决方案，还是建议去阅读一下官方文档进行学习
参考
- Hystrix官方文档 https://github.com/Netflix/Hystrix/wiki
