System Protection

Overview

系统保护有几种目标：

• 防止某一个系统内部或外部的节点出错导致雪崩效应，使整个系统挂掉，而不只是某些依赖了出错节点的功能不能使用。
• 保护远程或本地的公共资源不会因为某个功能有海量请求或发生了异常行为而被占用，导致其他功能不能使用。
• 保证系统在正常或非正常的海量请求发生时，能正常完成(如保持原有的响应时间)设计范围内的请求，而拒绝过量的请求。

在实现上可以有很多方式与层次，比如：

1. 在系统入口进行限流。
限流有助于目标2和3，可以控制并发如Http线程数，也可以控制TPS比如Google Guava中的RateLimiter。也应该有开关量，可以快速的关闭某个功能入口。

更高级是根据系统运行情况的反馈动态改变阀值，但如何获取与度量反馈源，阀值更改的算法，公共资源的互相影响，项目的具体需求等都制约着设计。

• 反馈源可以是所依赖的关键资源的状态如CPU/IO/网络/内存/线程数，或远程服务/数据库的状态，也可以是请求的平均响应时间。
• 获取方式可以是第三方监控关键资源，或入口自行计算平均响应时间/失败率(异步流程需要更特殊处理)，或由后面的资源访问控制模块传递节点失效/繁忙信息。

另外，有时候服务并不知道自己所依赖的全部资源列表，或者入口处无法得知某个请求的执行路径，有的会访问服务B，有的访问服务C，服务C又访问服务D，有的命中缓存，有的要访问数据库，算出来的TPS/平均响应时间可能是很粗旷的，也可能错杀了一些其实不进入出错/繁忙节点的请求。
但入口限流的优势是在入口就拒绝服务，不会先访问了服务B，再访问服务D才发现服务不可用，一是浪费了资源，二是可能要回退操作。

2. 在有Queue的地方都要对Queue的长度进行限制保护。
Queue本身也是一个削峰填谷的对系统保护有益的做法。

3.对服务/资源访问的保护。
数据库连接池及类似的池策略是对目标2中的远程资源保护的一个常用手段。但连接池的共享与独立限制也是个两难的选择，如果功能间的访问高峰不同步，那用一个共享的大连接池显然更高效，但就没有了保护。

NetFlix的Hystrix项目则提供更多的功能，也更为通用，为目标1和目标2中的远程资源保护提供了良好支持，使得这一层保护的实现方式是最具有通用性的。

Details

• Hystrix，见Hystrix章节