4
System Protection
Calvin Xiao edited this page 2013-12-18 22:27:35 -08:00
This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

1. 系统保护的目标

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

2. 在系统入口进行限流。

限流有助于目标2和3可以控制并发如Http线程数也可以控制TPS。也应该有开关量可以快速的关闭某个功能入口。

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

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

另外有时候服务并不知道自己所依赖的全部资源列表或者入口处无法得知某个请求的执行路径有的会访问服务B有的访问服务C服务C又访问服务D有的命中缓存有的要访问数据库算出来的TPS/平均响应时间可能是很粗旷的,也可能错杀了一些其实不进入出错/繁忙节点的请求。

但入口限流的优势是在入口就拒绝服务不会先访问了服务B再访问服务D才发现服务不可用一是浪费了资源二是可能要回退操作。

详见Rate Limiter章节。

3.对服务/资源访问的保护。

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

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

详见Hystrix章节。